DragonFlyBSD Improves Performance Against Linux

[phoronix]

Phoronix: DragonFlyBSD Improves Performance Against Linux

Benchmarks coming out of the BSD camp are showing that the soon-to-be-released DragonFlyBSD 3.2 is almost as fast as Scientific Linux (RHEL) 6.2 in at least one real-world workload...

http://www.phoronix.com/vr.php?view=MTIwNjA

[DaemonFC]

So they came in second to an aging Enterprise Linux distribution and didn't even use the current version of that... but I'll let that slide because......FreeBSD....and NetBSD.. . ouch.

I know their performance is bad (partially because they hate the GPL 3 imposing all of that horrible Freedom and don't want to use a recent version of GCC), but I didn't know it had decayed to this point.

[dfcat]

Disclaimer: I am a df dev.

"""

So they came in second to an aging Enterprise Linux distribution and didn't even use the current version of that... but I'll let that slide because......FreeBSD....and NetBSD.. . ouch.
"""


Scientific linux is based on RHEL - which also means that kernel/c library etc. versions are almost identical from release to release. So 6.2.x vs 6.3.x is practically irrelevant.

And how is this "aging" since it is the latest one? Or are you saying that the test should have picked a non-enterprise distribution in general, like fedora or ubuntu or something?


"""
I know their performance is bad (partially because they hate the GPL 3 imposing all of that horrible Freedom and don't want to use a recent version of GCC), but I didn't know it had decayed to this point.

"""

This statement is just incorrect in so many ways. Due to the high level of parallelism in the test (many core machines), this is less
of a indicator of 'performance decaying' as 'how far the different systems have advanced to take advantage of SMP & chip level SMT, etc'
recall at one point, they did not support these things, and have all required major modifications (aka years of hard work) by all involved
to get to their respective levels of advancement at present, with much to go for all involved.

And being a database test, this has much more to do with scheduler algorithms, IO and virtual memory subsystems etc. than compiler optimization - eg. the test is system/IO/memory bound, and not compute bound, so compiler is less of a factor.

The benchmarking was initially prompted by a major change in how postgres handles its memory structures - a change which
has an extremely negative impact on how many unix virtual memory systems have traditionally been implemented - aka
a questionable change to make - and some of the other non-dragonfly OS's have not been adapted to cope with this.
This was a very recent change in postgres, so that is not a 'omg bsds are so old and not shiny' thing. So while it is good to
see dragonfly competitive with Linux, this should be kept in mind. IIRC FreeBSD had a different workaround to avoid this problem
but not 100%.

R.e. GCC: firstly: dragonfly uses GCC4.4 - which is the same GCC major release as in RHEL6.. and 4.7 has been imported to switch
over after this release. Also - performance tests indicate that clang (which FreeBSD will be switching to in 10.x) - is superior to gcc
in some performance tests, but slower in others - so in other words, they are extermely competitive:

http://www.phoronix.com/scan.php?pag...tem&px=MTE5OTM

So really, I'm not sure what your compiler / gpl3 statements are in reference to here.

[enjolras]

Yes you're right. Linux rox, and has no scalability issue, it's well known. And postgresql scales easily on latest linux kernels. Oh wait !
http://http://lwn.net/Articles/518329/

[staalmannen]

I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.

A "coBSD" kernel (or a BSD syscall compatibility module for the Linux kernel) would be fun to play with on a Linux host (or perhaps am I rather alone in this) - especially the theoretical posibility to be able to run a BSD system in a chroot on a Linux host without full virtualization.

[dfcat]

"
[QUOTE=staalmannen;290857]I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.
"

The vkernel requires some host-side support - specifically ability to create 'vmspaces' which are separate virtual memory maps,
and also a some minor hooks to interface to hardware / host side resources. Doable, but alot of work. Someone interested in knowing
this level of detail would be better of giving DF hardware assisted virtualization so you could run DF and virtualize the 'other' os where
needed

UML iirc also required same.

Probably the best bet right now to run dragonfly on another OS is virtualization e.g. via KVM / QEMU / VirtualBox.
I am personally, other than on several native dragonfly machines, running df on VirtualBox/Linux, with some devs using KVM.

[soupbowl]

Nice to see dragonfly bsd doing well, I have been watching it for years.

[Sergio]

So DragonFlyBSD is very interesting and definitely not a waste of time...

[staalmannen]

[QUOTE=dfcat;290858]"

I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.
"

The vkernel requires some host-side support - specifically ability to create 'vmspaces' which are separate virtual memory maps,
and also a some minor hooks to interface to hardware / host side resources. Doable, but alot of work. Someone interested in knowing
this level of detail would be better of giving DF hardware assisted virtualization so you could run DF and virtualize the 'other' os where
needed

UML iirc also required same.

Probably the best bet right now to run dragonfly on another OS is virtualization e.g. via KVM / QEMU / VirtualBox.
I am personally, other than on several native dragonfly machines, running df on VirtualBox/Linux, with some devs using KVM.

Thanks for the clarifications

Personally I just find chroots/jails in directories so much more convenient than typical virtualization and disk images and I think it would be really cool to be able to boot a BSD system directly on top of a Linux kernel (for all that pesky hardware that may not want to work otherwise)

Just another question - how does the vkernel compare to NetBSD RUMP? It can be run on different OSes (although I have failed building it on my Linux system) but on the other hand, it does not support running applications but rather provides various kernel features like file systems etc.

[XorEaxEax]

Also - performance tests indicate that clang (which FreeBSD will be switching to in 10.x) - is superior to gcc
in some performance tests, but slower in others - so in other words, they are extermely competitive:

http://www.phoronix.com/scan.php?pag...tem&px=MTE5OTM

I someone who regularly benchmarks clang/llvm vs GCC I can say I've not seen any results (atleast not as recent as this year, before that my memory may fail me) where clang/llvm beats GCC where I use -O3, which is the optimization level where the compilers strive to produce the fastest code. And as we can see from the results you linked to, whenever -O3 is used GCC is 'superior' to clang/llvm, and also in most of the cases where no optimization level is set (which really doesn't count though as it is worthless) and the only times clang/llvm beats GCC is when there is no -O optimization level which means GCC defaults to -O0 which is 'no optimization' and aimed for debugging.

Typically my tests results in 5-20% better performance with GCC versus clang/llvm, and when I've tried the GCC 4.8 versus LLVM 3.2 snapshots GCC has actually increased the performance gap (that said, snapshots are anything but conclusive). It should be noted that my benchmarks are all on x86_64, I have no idea of how x86 or for example ARM architectures compare.

On another note I find Dragonfly most interesting from a technical standpoint, keep up the good work!