Slashdot Mirror
2.4 vs 2.6 Linux Kernel Shootout
FyRE666 writes "Infoworld are currently running an interesting comparison of the 2.4 series kernel against the new 2.6 release on Xeon, Opteron and Itanium CPUs with some surprising benchmark results for common server-related tasks. Basically the new scheduler helps the 2.6 kernel to cream the old 2.4: Samba tests showing up to 73% speed increases, MySQL showing up to 29% and Apache serving dynamic content up to 47% faster!"
Those benchmarks are nice, but who runs kernel 2.6 on production servers that need every speed they can get? It will be a few more 2.6.x releases until I consider running one of my servers with a 2.6 kernel.
Pain is merely failure leaving the body
Caching is controlled completely by the CPU, transparent of the programmer.
:).
Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.
However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.
In other words, just trust the CPU. It knows what it's doing
I guess it's important to ask the following question: was 2.4 ever designed to run on those kinds of processors? I mean, the O(1) scheduler is a pretty cool, processor independant change; but was 2.6 designed with specific optimizations for newer processors (and newer instructions) in mind? I'd be interested to see benchmarks from old hardware -- i.e., stuff like I've got sitting around. (If only I had a bit more time. Maybe I can borrow some cycles from 2.6 Linux boxen.)
Actually, it wouldn't suprise me if this is correct. If you notice, he was reading the 500MB file while a continuous streaming write was going on in the background. On 2.4.x, a write streamout will kill read performance drastically. Mostly due to the way the I/O scheduler schedules the read. Which, most of the time, is to stash it at the end of the writes.
The two new I/O schedulers in 2.6.x help to resolve this. For more info, check here.
Its my experience that "highly trained technical professionals" would have enough real world experience to know the sort of crap code that can come out of any company...no matter how much money you throw at it, and that there's nothing inherently better about a product that costs money. In fact, it's been my experience that the more you pay for something, the crappier it is *cough*legato*cough*
Also, professional you may be (as in you get payed to do it), but you have very little professionalism if you have to resort to using terms like "open sores", not to mention the fact that you haven't got a clue what you're talking about due to your use of terms like "the Linux 7.0 webserver", "LinuxOS", and reference to RedHat as a web server, as well as referring to J2EE as an open source product, instead of the specification implemented by many proprietry application servers by companies such as IBM, Oracle, Borland and BEA.
I'm not even sure why I'm replying to this...it might as well have been generated by a script...
Advanced users are users too!
The comparisons won't make much real-world sense until the evaluation is done using Intel's compiler for the Itanium tests. The GNU compiler is just not up to snuff at optimizing for Itanium's EPIC instruction set.
I would like to see Intel contribute Itanium optimizations to GNU, but I doubt this will happen since they sell a competing product.
the growth in cynicism and rebellion has not been without cause
I wonder what the response would be if someone posted similar numbers about Microsoft's next OS. I'm sure they'd find creative ways to diminish the results.
One thing I've learned is not to take tech writers too seriously. Most of them are writers for a reason.
-- You see, there would be these conclusions that you could jump to
Most of it has to do with the algorithms. For example I can write a really optimized bubble search but if you write an un optimized quick sort it will still be faster than my optimized bubble search. That being said any newbie programmer can do a bubble search but you have to know what you're doing to do a quick/merge sort.
So while 2.4 wasn't using the best solutions it was better than nothing. It's always better to have bad working code than great code that doesn't work. Hurd is a great example. It may be batter but it doesn't work (well enough for me anyway) yet so who cares.
IDE is another example. If I remember correctly 2.2 didn't have DMA support but it worked adding DMA makes it much faster but it would have made it more unstable if they added it at the beginning.
The last thing that you have to remember is that lots of the changes were taking advantage of features in the newer hardware. If you ran the same test on 486 you wouldn't get the same results as you'd have different bottlenecks. In another 10 years we'll get the same thing again. The might make it so that the bus to the memory is as faster as the level 2 cache on the CPU. If they do that they'll have to make big changes to the OS to get rid of the new bottle necks and you'd increase the speed by another 50% or maybe even 100%
Anyway that's enough ranting.
A kernel is much more complex than a single program. A program usually does one thing, and once you've optimized that, that's all there really is. In contrast, a kernel does all sorts of things. 2.2 was good for small-scale servers. 2.4 was good for mid-range servers. 2.6 is good for larger servers and desktop machines. 2.8 is supposed to get improvements to make it better on desktops and on huge NUMA machines. Linux has always been a fast kernel for what it did, its just that its doing a lot more today than it did a few years ago.
A deep unwavering belief is a sure sign you're missing something...
The old kernel had a lot of room for improvement on the systems they tested; but that's primarily due to the fact that the systems are substantially newer than the 2.4 series. A 2 GB dual Xeon system running 2.4 isn't going to use the processors efficiently (hyperthreading, imprecise locks), and isn't going to deal with the memory effectively. It was in part to take advantage of the availablity of such systems that the changes for 2.6 were made.
New conditions require new optimizations and new designs; a good program optimized for a set of inputs which are common at one time may be really inefficient at handling inputs that become common later. Sure, you can make a program that's good for both sorts of input, but it doesn't make sense to try to do so until someone actually has such an input to test with.
Sarcasm just goes WAY over your head, doesn't it?