Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux 143
An anonymous reader writes "The Debian Squeeze release is going to be accompanied by a first-rate kFreeBSD port and now early benchmarks of this port have started coming out using daily install images. The Debian GNU/kFreeBSD project is marrying the FreeBSD kernel with a GNU userland and glibc while making most of the Debian repository packages available for kfreebsd-i386 and kfreebsd-amd64. The first Debian GNU/kFreeBSD benchmarks compare the performance of it to Debian GNU/Linux with the 2.6.30 kernel while the rest of the packages are the same. Results are shown for both i386 and x86_64 flavors. Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."
Re:Please educate me a bit. (Score:3, Informative)
'Because we can' is the answer you are looking for I think.
Considering what they've done (most of it anyway) can be accomplished with a few flags to make.conf anyway, its not exactly impressive. Tell the system to use glibc instead of its native libc, then rebuild world (to rebuild the built in GNU tools with glibc) and build the ports for other GNU tools you want and you've got what they made.
You could probably write a fairly trivial sh script to do this on a generic FBSD install.
This is just a typical 'We did it because we can and we wanted to' type of thing the way I see it.
You use the FBSD kernel because its going to have the largest driver base compared to the other two for hardware that people care about, although NetBSD can't be far behind it. OpenBSD is just a bitch thats not worth the effort to deal with for any reason since it has no real advantage over a FBSD 'Minimal' install, possibly with some config tweaks but it won't be many.
The one shining thing you can get, is a native ZFS implementation, though by using an old kernel they've kinda killed that idea since the version in that kernel is not really production ready. You get jails, which are nice for some purposes, but with paravirtualized linux on linux and enough ram its really not that big of a deal. They also claim that you get the advantage of the debian package system, but other than a gui I see no outstanding advantage over the FBSD package system, with the exception that I think they still don't make a screen package due to some kernel interface issues that break it when used with a kernel compiled with slightly different options, its never been a problem for me, I build and distribute screen internally to our BSD boxes without 'noticing' a problem.
TFA has more reasons why you might want to do it, but they all seem pretty weak to me, but I'm a FBSD person, and don't care for Linux that much, so my bias is probably not helping.
Re:Please educate me a bit. (Score:5, Informative)
Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?
They actually have a NetBSD port [debian.org] as well as a Hurd port [debian.org]. They also have a nifty why NetBSD [debian.org] section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.
Re:Holy moley ! (Score:5, Informative)
As others have said, 64-bit programs take more memory to run. There's nothing inherently faster about 64-bit registers and operations unless you're dealing with integers that get that big (which in most everyday programs, they don't). What makes 64-bit faster isn't just "more bits", but optimizations. 32-bit code is typically compiled for the lowest common denominator: i386. However, x86-64 CPU's are guaranteed to be at least i686 compatible (you're also guaranteed up to a certain level of SSE compatibility and such). In that regard, it's the code optimization that we can rely on and not "more bits" (which due to extra memory usage, will typically make things SLOWER, not faster) to make things faster.
However, not every app or test really benefits that much from i686 optimizations. For those that don't, and don't deal in larger numbers (AND that don't use so much memory that a 64-bit chip is needed to address it), 32-bit processors will typically be faster.
As to stability, x86-64 is well past the "new" stage. The specification is 10 years old and processors based on it 7 years old - Linux support was almost immediate. Just how long does it take for you to consider it not bleeding edge anymore? :)
Re:Please educate me a bit. (Score:4, Informative)
Why use freebsd with GNU apps, when you can just run freebsd?
Then you'd be stuck with freebsd apps instead of GNU apps.
If you have a mighty herd of servers, desktops, and kiosks, all sharing various automation scripts, supporting both freebsd and GNU command line apps could be a pain, due to subtle differences in command line options, etc. Its possible to create a blizzard of "if then" to work around, but why bother.
But I am missing the improvement for Debian here.
Overall, none really. The way ports work on Debian, is if enough people volunteer to maintain a port, and they are successful, then we have a new port. Heck, that is the way everything works in the Debian project, if something meets a certain standard of excellence, its in, no matter if its a package, docs, artwork, shared VCS, human language translation, a network service, a mirror, or in this case, a port. Debian is thankfully not a deletionist stronghold like that dumpy embarrassment known as wikipedia.
This link provides a one page summary of each attempted Debian port, successful and ... not so successful :
http://www.debian.org/ports/ [debian.org]
Re:Please educate me a bit. (Score:5, Informative)
but other than a gui I see no outstanding advantage over the FBSD package system
As a gauge of relative activity level in each package system:
The weekly list of UPDATED (and possibly NEW) BSD packages at
http://www.freshports.org/ports-new.php?interval=week [freshports.org]
is roughly equal in size to the weekly list of NEW Debian packages at
http://packages.debian.org/unstable/main/newpkg [debian.org]
So, each week, there is about as much new stuff added to Debian as there is updated preexisting stuff in BSD.
Re:Holy moley ! (Score:5, Informative)
You missed out on the fact that there are more registers on 64 bit than the famously register starved 32 bit x86. More places to put things can't hurt even if your not dealing in 64 bit values.
The problem with 64 bit is that a lot of code is still hand tuned to the maximum possible performance on 32 bit arches and in at least a couple of the cases listed in the benchmarks I wouldn't be shocked if there was some hand done assembler involved. I have also noticed GCC has some performance tweaks that work around the lack of registers on 32 bit that also tend to get enabled in 64 bit..
Re:Mod Article Flamebait (Score:4, Informative)
Linux 2.6.30 is from Jun 9 2009. The latest patchset 2.6.30.10 though is from December 3rd.
Re:Please educate me a bit. (Score:4, Informative)
The FreeBSD kernel gives you a few nice things. ZFS, DTrace, and a high-performance in-kernel sound system that eliminates the need to mess about with things like PulseAudio just to get half a dozen applications going 'bing' at the same time while another one plays music (although this got a lot of improvements in the FreeBSD 8 kernel, which isn't in Debian yet, as did ZFS). It also gives you the ULE scheduler, which has had several years of testing and refinement (unlike Linux's scheduler-of-the-week) and performs very well (was outperforming Linux by a large margin on 8+ cores, now they're pretty similar). It includes Jails, which are like chroot but with a complete environment inside so you can have a different IP, different users, and so on in a jail (and you can create them with a complete clone of a skeleton system almost instantly with ZFS clones).
As to why you'd use Debian rather than FreeBSD, the big difference is glibc rather than BSD libc. When people talk about Linuxisms in code, they most often really mean GNUisms and the code depends on something weird in glibc, rather than on anything specific to the kernel. It will therefore work with glibc on kFreeBSD just as it would with glibc on Linux. You may also prefer the GNU userland utilities. Some people install these on FreeBSD anyway, but with Debian they are the default ones. This means that a few other common GNUisms (e.g. assuming that /bin/sh is bash and that POSIX utilities accept GNU arguments in shell scripts) will work.
This means that it's easier to port crappy code (and there is a lot of it about) from GNU/Linux to GNU/kFreeBSD than to FreeBSD. I've written a bit about which bits are GNU and which bits are Linux [informit.com] before: most of what the user or developer interacts with is GNU.
Re:FreeBSD ports can't be relied upon (Score:3, Informative)
Re:Holy moley ! (Score:3, Informative)
Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !
I'm not so surprised to see that somebody didn't read the graphs very well. 32 bit was faster in only 4 out of 25 tests (16%). Further, 2 of those were only marginally faster to the point where they barely count as a clear lead. Conversely in the majority of cases, 64 bit was not only faster but significantly faster. To the point where I wonder if there were other configuration differences -- for example I don't understand why you'd see a much higher hard drive TPS rate under 64 bit (something like 4x) -- unless they're using a different IO scheduler...
All that said, is it really so unreasonable to ask for results to be laid out in a simple grid for all tests? Raw data is what we like here... (To answer my own question - of course it is. That would mean fewer page hits...)
Re:Holy moley ! (Score:1, Informative)
The extra registers do help, but x86 has register renaming going on in microcode, and it's pretty good at it. It's only some very specific kinds of code that see dramatic benefit from the extra visible registers.
Mind you any app that uses 64-bit ints, like databases, usually sees dramatic improvements.
Why so ?!? (Score:4, Informative)
No, not necessary.
It's not because your CPU is running a 64bits OS that suddenly every data format has to be replaced with one using 64bit integers.
It's not because your CPU is running a 32bits OS that you aren't allowed to manipulate anything bigger 32bits.
The OS bittage has almost no impact on what data format can be used. Only how fast those format will be processed, and how many memory can easily be addressed in a straight-forward way.
A 256 x 256 bitmap, RGBA, with 8bits per channel, will always take the same amount of memory wherever the OS is running 32bits or 64bits code. Only with a 64bits OS it will be much more easy to store more than 3GiB worth of textures.
And even a 32bits OS can manipulate 1024bit data structures like crypto key (only a little bit slower, because the CPU internally won't be able to do 64bit operations).
Also most OSes are LLP64 or LP64, meaning that the default "int" still is 32bits. Thus code recompiled in 64bits will tend to approximately use the same amount of data as original code in 32bits.
Re:Holy moley ! (Score:3, Informative)
The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.
Correction: The C ABI says that, and the C ABI is defined on a per-platform basis (for example, FreeBSD and Linux use slightly different calling conventions on IA32). It's up to the operating system to define the ABI or ABIs that it supports. Solaris, IRIX, and most other commercial UNIX variants have been happily supporting 32-bit and 64-bit ABIs on 64-bit platforms for a couple of decades.