If all goes well, LLVM 3.5 will be released today. While we have already delivered some LLVM/Clang benchmarks of the 3.5 SVN code, over the days ahead we will be delivering more benchmarks of the updated compiler stack -- including looking at its performance against the in-development GCC 5.0. For getting this latest series of compiler benchmarking at Phoronix started, here's some fresh numbers of LLVM Clang 3.4 compared to a recent release candidate of LLVM Clang 3.5.
This article is using a CompuLab Intense-PC with Intel Core i7 3517UE Ivy Bridge processor for LLVM Clang 3.4 vs. LLVM Clang 3.5 benchmarking. The host system was Ubuntu 14.04 x86_64 and was running off the Linux 3.17 development kernel. Both compilers were built in their optimized release mode (--disable-assertions --enable-optimized) for the core-avx-i CPU. Aside from switching out LLVM Clang 3.4 for LLVM Clang 3.5 RC4, no other system changes were made.
GhostBSD is a desktop distribution that’s based on FreeBSD. The project started out with support for several desktop environments (Gnome, Mate, XFCE, LXDE, and Openbox), but has since become a MATE-only distribution.
The next stable version will be GhostBSD 4, which should be released within the next few months. Meanwhile The second release candidate was made available for download a few days ago. This article shows what the distribution has to offer, which, at this stage of its development, is not a whole lot.
GhostBSD has its own graphical package manager, but compared to the graphical installer of PC-BSD, another FreeBSD-based desktop distribution, it is very lite, feature-wise.
PfSense is a free network firewall distribution based on the FreeBSD, it comes with a custom kernel, and a few quite powerful applications that should make its users’ life a lot easier. Most of the firewall distros are Linux-based, but PfSense is a little bit different and is using FreeBSD. Regular users won't feel anything out of the ordinary, but it's an interesting choice for the base.
The developers of PfSense are also saying that their distro has been successful in replacing a number of commercial firewalls such as Check Point, Cisco PIX, Cisco ASA, Juniper, Sonicwall, Netgear, Watchguard, Astar, and others.
Linux and *BSD have completely changed the storage market. They are the core of so many storage products, allowing startups and established vendors alike to bring new products to the market more rapidly than previously possible.
Almost every vendor I talk to these days has built their system on top of these and then there are the number of vendors who are using Samba implementations for their NAS functionality. Sometimes they move on from Samba but almost all version 1 NAS boxen are built on top of it.
With each kernel revision, LLVM Clang gets closer to being able to build the mainline Linux kernel. There's now just a few dozen patches outstanding for LLVMLinux to be a mainline success.
Behan Webster gave his usual talk at LinuxCon in Chicago this week about the state of LLVMLinux -- building the Linux kernel with Clang rather than GCC. There's been many Phoronix articles about the topic so there isn't too much more to share beyond that many developers want to use Clang to compile the Linux kernel to lead to better code portability of the kernel, faster compilation times of Clang, potential performance differences, LLVM and Clang are more liberally licensed, and there's a host of other development extras with Clang.
While Broadwell is right around the corner and Intel's open-source Linux developers are already working on Skylake graphics support, the DragonFlyBSD crew has just managed Haswell graphics support for their DRM driver ported from FreeBSD that in turn was ported from an earlier version of the Linux kernel.
DragonFlyBSD 3.8 brought Intel DRM support but that only covered the Intel Ivy Bridge graphics hardware and was a port from the Linux 3.8 kernel era. Hitting DragonFlyBSD mainline Git for its kernel is now the Haswell support. While the i915 DRM driver's infrastructure was ported to DragonFly interfaces, adding Haswell support required extra work and still isn't fully operational.
Clang is finally co installable on Debian. 3.4, 3.5 and the current trunk (snapshot) can be installed together.
So, just like gcc, the different version can be called with clang-3.4, clang-3.5 or clang-3.6.
/usr/bin/clang, /usr/bin/clang++, /usr/bin/scan-build and /usr/bin/scan-view are now handled through the llvm-defaults package.
llvm-defaults is also now managing clang-check, clang-tblgen, c-index-test, clang-apply-replacements, clang-tidy, pp-trace and clang-query.
Changes are also available on llvm.org/apt/.
The next step will be to manage also llvm-defaults on llvm.org/apt to simplify the transition for people using these packages.
Last month in Cambridge was the 2014 GNU Tools Cauldron where GCC as a JIT compiler and other interesting topics were discussed by developers. One of the topics discussed was surrounding better collaboration between GCC and LLVM developers.
While in my earlier 2014 GNU Tools Cauldron coverage I commented on the session about GCC+LLVM collaboration, after the past Phoronix article on the event some additional information was published. The purpose of the GCC and LLVM/Clang compiler teams collaborating is to reach common defaults between compilers, avoid confusion with architecture flags and other compiler switches, and make other improvements to better the interoperability between the compilers to make a better end-user/developer experience. The focus isn't on merging GCC+LLVM, debating licensing differences, fighting over who as the faster compiler, or other such heated topics.
The Unified Extensible Firmware Interface (UEFI) provides boot- and
run-time services for x86 and other computers. For the x86 architecture
it replaces the legacy BIOS. This project will adapt the FreeBSD loader
and kernel boot process for compatibility with UEFI firmware, found on
contemporary servers, desktops, and laptops.
Ed and Nathan completed a number of integration tasks over the past
three months. Nathan added a first-stage loader, boot1.efi, to support
chain-loading the rest of the system from a UFS filesystem. This allows
the UEFI boot process to proceed in a similar fashion as with BIOS
boot. Nathan also added UEFI support to the FreeBSD installer and
release image creation script.
The EFI framebuffer requires the vt(4) system console -- a framebuffer
driver is not implemented for the legacy syscons(4) console. Ed added
automatic vt(4) selection to the UEFI boot path.
Snapshots are now built as dual-mode images, and should boot via both
BIOS and UEFI. Our plan is to merge the UEFI and vt(4) work to
stable/10 to appear in FreeBSD 10.1-RELEASE.
This project is sponsored by The FreeBSD Foundation.