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."
We can't start a holy war now! My armor is at the cleaners.
Cue nerd rage
Sheldon
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
While they're really the only group that does a lot of linux benchmarking, I'd put a *large* grain of salt in their results.
They have no problem blindly accepting something like this without investigating why it is so much faster and seeing if there's a problem with their testing.
Your hair look like poop, Bob! - Wanker.
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
I don't use BSD, I just wanted to see if the "BSD is dying" troll still posted. It has been years, eh?
It does also seem to me that the FreeBSDk thing is meant to make certain features available to developers, maybe be more reliable, and "faster, faster" isn't being sold as part of the bill of goods. Yet, the talk returns to speed, speed, speed.
But what do I know... I work as a nurse. Although... I DO love a fast computer.
As a long time debian user who also has to work with freebsd sometimes I don't get it. Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd? What is the advantage in using the freebsd-kernel instead of the linux-kernel? I have access to every linux app when I use freebsd and to be honest, if I knew my way around bsd as I do under debian I would probably switch. But I am missing the improvement for Debian here. Can someone please clear this up for me a bit?
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.
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? :)
"People who think they know everything are very annoying to those of us who do."-Mark Twain
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
So can I run Flash-enabled browser on this port?
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
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..
This is wrong. the Ports system is based on CVS, so in essence, you can go back version by version, back to the beginning, and select version numbers of the software to install at will, without having to depend on precompile binaries. You use the supfile to select the port version you need http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html Gives you all the branch tags that you can check out via historical cvs. But Alter Relationship obviously didn't read the handbook, and started complaining without even reading the man pages.
> 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?
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...)
Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests?
For most, its generally considered a wash. Larger data structures require more cache and more memory and more memory to be accessed. On the other hand, you also get more registers in 64-bit mode. As a result, some things run slower and some things run faster, depending on the nature of the application. On average its likely to be a wash.
The big exception are those that use the PAE 32-bit extensions. Generally speaking, 64-bit is going to be a lot faster. Even still, there are some odd exceptions which will hopefully fuel the imagination of possibilities.
One such exception comes from the PostgreSQL guys. For example, on Windows, they strongly recommend running 32-bit PostgreSQL on 64-bit Windows. This seems really non-obvious at first but there is a good reason for it. If you use 64-bit OS, that means you get large pointers which can access large quantities of memory without using PAE tricks. But, since PostgreSQL spawns processes for each back-end, that means you can run more heavy hitting (very large data sets, heavy queries, etc), concurrent back-ends without taking a performance hit. Additionally, PostgreSQL relies heavily on the OS to cache files. With a 64-bit OS cache, large data sets can be readily cached by the OS and quickly return results to the 32-bit PostgreSQL. This means PostgreSQL directly benefits from 64-bit size file caches; despite running as a 32-bit application. And best of all, a 32-bit PostgreSQL means smaller data structures and more efficient cache use, with twice the available cache a 64-bit application would require. Its almost the best of both worlds.
As the above example illustrates, sometimes a mix can provide ideal results, but on average, consider it a break even unless you plan on having 4GB or more in your box. And even then... ;)
But on x86, you are only guaranteed 4 *real* general purpose registers. x86_64 increases this number. With a good compiler, the register allocator would use all of these, and you would have much fewer loads from main memory, which can take on the order of 75+ cpu cycles on a cache miss, or 5+ cycles on a cache hit.
I fear the Y2038 bug
Whoa, wait just a second. Before asking if the operating system support this, shouldn't we first ask "does the hardware support this?" or more specifically "does Intel's implementation support this?" because as far as I can tell from Wikipedia, it doesn't.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I wish Alter Relationship would stop replying to himself.
He's almost as bad as that other troll, Friend of a Friend.
If moderation could change anything, it would be illegal.
> so the only advantage of a 128-bit architecture would be for
supporting the full length of a message on /. ?? ;-))
Thanks for your reply anyway,
Cheers,
Everything I write is lies, read between the lines.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
I am TheRaven on Soylent News
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.
``Why even swap the kernel out?''
It's good to have choices. Even if Linux is the best choice for you today, you can never know that it will be the best choice for you forever. Providing Debian GNU/kFreeBSD not only offers Debian users the option of using the FreeBSD kernel instead of Linux, but also offers FreeBSD users a way to use the GNU userland instead of FreeBSD's.
Moreover, in making different kernels and userlands work together, areas where this is problematic are identified and improved, so that other projects besides Debian can benefit, too.
The end result is that you gain more options to mix and match parts to build the system exactly the way you want it.
``I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.''
And you still have that option, too, of course.
Please correct me if I got my facts wrong.
I'm a Linux fan, but there's a first. A linux user complaining that he needs to tweak the OS to get the most out of it!
Here's a tip, ALL OS's require tweaking to get the most out of them.
It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.
Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?
As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.
All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.
Please correct me if I got my facts wrong.
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!!!