Slashdot Mirror
Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux
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."
I am TheRaven on Soylent News
Yep, because we ALL KNOW speed is EVERYTHING when running a computer.
Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.
So what's left? User friendliness? These systems use the same apps - tie there too.
We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.
Still though, to dismiss speed as a criteria is just being naive.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
I think speed is everything when you're writing an article for a benchmark site. Note that I'm not disagreeing with your ironic implication that there are other things to look at, but obviously it's a lot easier to churn out some graphs than to try to compare two OSes/suites/whatever on other important metrics, such as security or usability. Leave that to the media troll sites--there's no shortage of them.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Where many is ~20% of them.
And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.
Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.
Stick 8 or 12 GB of RAM in and things might be different
64-bit data structures can take up more space in the L1/L2/L3 caches which may cause code to run somewhat slower.
What about a performance comparison with original FreeBSD?
The Tao of math: The numbers you can count are not the real numbers.
On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.
Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.
For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.
I am TheRaven on Soylent News
The speed difference is a few percent. For most people, that's not noticeable. My kernel CPU usage stays well below 10% most of the time, even when the CPU is busy, so even a 50% difference in kernel performance wouldn't be particularly important. Much less important, for example, than things like ZFS, DTrace, a decent kernel sound system, and so on.
I am TheRaven on Soylent News
> Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.
I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)
Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...
What do you think ?
Everything I write is lies, read between the lines.
In theory, perhaps.
On that web page I see this: "The ports and doc trees use tags whose names begin with RELEASE tags." Excuse me, WTF? You're only going to tell me how the name begins and leave me to guess the end?
Can I go back 15 years? Can I do this for versions 1, 2, or 3?
What about all the stuff it drags in? Is the old source code actually there, or just the build system?
I sure hope that a CVS checkout isn't going to drag a bunch of old history with it. Gigabytes would be unfriendly.
I can go to Red Hat or Debian's site and just download the packages I want, either binary or source. Why does FreeBSD makes things so unusable?
Why even swap the kernel out? The Linux kernel supports more hardware and has better stock performance then the FreeBSD kernel. In fact most friends I have that use FreeBSD are snotty to Linux users anyway. I say give them there OS and it's sorry performance (at least I've never seen anything comparable) and I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.
Sorry if this offends any FreeBSD user as that's not my point but I've installed it a ton of times to try it out and I'm still waiting for an install that lets me say "Woah" from the get go. Sure you can optimize after the fact but that's not the point, fast out of the box, faster after the tweak! that's what I want and FreeBSD has never given that to me .
If your a FreeBSD user great and if you a Linux user great, but lets not mix the two please!
I can see a really good usage case for this.
You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.
You have a few options:
1) Run Solaris
2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
3) Run Debian w/ ZFS in Fuse
4) Run Debian kFreeBSD
Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.
Yes, your slackware from 1994 is full of security holes. The FAIL here is you trying to install an unsupported version of the OS and then complaining about it when it doesn't work.
Never did I suggest that I was running a random server exposed to the Internet. The box could be running some lab equipment that costs millions of dollars to replace, using a proprietary control program that won't run on a more modern OS. The box could be running a legacy app, with a modern system controlling things over a serial line. Shit happens.
The fact that an unsupported OS suffers bit rot is disgusting. The bits should just sit there forever, as they do for every Linux distribution except Gentoo.
I will never voluntarily put myself or my future successor in such a terrible position. Software needs to be available forever.
No excuses!!!