Submitted by This release supports a much larger variety of hardware and multiprocessor systems than previous releases, thanks to updates of ACPI and APIC and ACPI interrupt routing support. Hammer volumes can now deduplicate volumes overnight in a batch process and during live operation. The ‘hammer dedup-simulate’ command can be used to estimate space savings for existing data. DragonFly now uses gcc 4.4 as the default system compiler, and is the first BSD to take that step. DragonFly now offers significant performance gains over previous releases, especially for machines using AHCI or implementing swapcache(8).
It is nice to see that DragonFly BSD makes steady progress.
I am glad to see DragonFly BSD taken huge steps forward: the SMP work is very important, and Hammerfs continues to progress.
I think the comment about Dragonfly being the first BSD to update to gcc 4.4 makes little sense though: the other BSDs have taken a stance against the GPLv3 so Dragonfly may very well be the *only* BSD to take that step. But then, Debian GNU/kFreeBSD was probably there first?
In any case the real race seems to be who will be the first BSD to use CLANG as it’s default compiler.
I think we’ll see FreeBSD and NetBSD default to llvm, OpenBSD and MirBSD use pcc. DragonFly might win some benchmarks for a while because of this choice.
I haven’t decided with MidnightBSD yet, but I’m leaning toward migrating to llvm. The GPLv3 has a few provisions that make me nervous.
Side note: DragonFly BSD was the first BSD booting with an llvm/clang compiled Kernel and Userland or at least one of these two things
Edited 2011-04-30 00:06 UTC
Uhm… I am not sure of that, but I would think Apple Darwin has beat all the other BSD variants there
.
FreeBSD ( http://lists.freebsd.org/pipermail/freebsd-current/2009-February/00… ) beat DragonFlyBSD ( http://leaf.dragonflybsd.org/mailarchive/kernel/2009-03/msg00067.ht… ) to a self-hosting clang-built kernel by about 3 weeks. Both of which were well ahead of Linux ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html ). Apple made the transition to Clang with the Snow Leopard release in June of 2009. While it may seem reasonable to assume that Apple had internal builds going well before 4-5 months in advance, the blockers that were fixed in Clang and allowed these BSD derived kernels to build and boot were fixed in early 2009 — OSX was probably building and booting in the same timeframe as FreeBSD and DragonFly.
Thanks for the report: yes, FreeBSD seems to be more active with clang than the other BSDs but I don’t follow much the other BSDs so I tend to give them the benefit of the doubt in such body-part-size type of claims.
One issue for a complete system was the lack of C++ compiler support: FreeBSD’s devd and groff needed it. Now the big issue, that all the BSDs have to work on, is completely replacing libgcc (compiler_rt and libunwind) and libstdc++ (with libc++ and something else yet unwritten).
Oh .. and binutils is a completely different issue.
GNU/kFreeBSD does not qualify as a BSD system. That’s almost (but not quite) like mentioning a hypotetical FreeBSD/Linux as a variant of the GNU operating system.
In the DragonFly camp we are very excited about clang (and pcc), but there is an astounding amount of work to be done without massaging our codebase and toolchain to support the latest compiler-of-the-week. Committing to recent GCC releases yields performance improvements as well as better / more thorough warnings and errors, etc., without committing to the huge amount of work required to switch base system compilers. I am sure the DragonFly project will one day switch to one of Clang or pcc, but probably not until one of those compilers has proven itself as the system compiler of another BSD for a period of time, at which time we will be able to weigh the benefits against the pain of their experience in switching.
Currently, the only MAJOR benefit in switching to one of these alternatives is the license. The DragonFly project is simply taking a bit of a pragmatic approach toward this issue. It is perhaps because DragonFly BSD does not support any commercial derivatives that we have this luxury.
Well it’s not ready for release yet but the performance benefit derived from the new gcc wrt clang is just about 10% (and clang sometimes beats gcc).
The warning and bug detection facilities in clang are way better, but there is another advantage: blocks support. FreeBSD supports GCD out of the box.
That said, I don’t complain about Dragonfly adopting gcc4.4 … I just find it amusing that they take so much pride on it when there’s no technical merit just because the other BSDs chose not to do it. As I wrote before, for Debian it was apparantly not a big deal to ship FreeBSD’s kernel with a newer gcc.