Is Ubuntu Getting Slower?
An anonymous reader writes "Phoronix has a new article where they provide Ubuntu 7.04, 7.10, 8.04, and 8.10 benchmarks and had ran many tests. In that article, when using an Intel notebook they witness major slowdowns in different areas and ask the question, Is Ubuntu getting slower? From the article: 'A number of significant kernel changes had went on between these Ubuntu Linux releases including the Completely Fair Scheduler, the SLUB allocator, tickless kernel support, etc. We had also repeated many of these tests to confirm we were not experiencing a performance fluke or other issue (even though the Phoronix Test Suite carries out each test in a completely automated and repeatable fashion) but nothing had changed. Ubuntu 7.04 was certainly the Feisty Fawn for performance, but based upon these results perhaps it would be better to call Ubuntu 7.10 the Gooey Gibbon, 8.04 the Hungover Heron, and 8.10 the Idling Ibex.'"
Let's see how that statement works in this situation:
It shouldn't be getting slower, but then again, performance isn't the reason Vista exists.
If you really want performance, run FreeDOS. Otherwise, shut up and get used to progress.
If you look closely you'll notice that (a) the benchmarks were run on a Thinkpad T60 laptop, and (b) there were significant differences on some benchmarks like RAM bandwidth that should have little or no OS components.
This sounds to me like the power management was dialing down the CPU on the later releases...
Some of the benchmarks were hardware testing, and those showed variation. They should not, unless the compiler changed the algorithms used to compile the code between distros.
Benchmarking a multi-tasking system like Linux is a tough thing to quantify. The Linux kernel recently had a big scheduler change, this alone could account for shifting benhmark numbers. It may not actually "slowing down," but running multiple programs more evenly. The effective work is the same or better, which would mean "faster," but an almost useless benchmark would look slower.
It's not quite that simple. Performance in Java and media encoding was almost halved in the two newest versus the older versions of the OS. It's hard to imagine why that would be the case unless "more features" in Heron and Ibex are using up half the CPU time (and based on the other benchmarks, they ain't). I'd suspect test methodology rather than some oddity of OS performance but it's still something that needs to be addressed.
No kidding!!! What do you say at this point?
... they are.
Seriously.
I can see several problems with the testing methodology as is:
* The test suite itself: The Phoronix test suite runs on PHP. That in itself is a problem-- the slowdowns measured could most likely be *because* of differences in the distributed PHP runtimes. You can't just say "hey, version Y of distro X is slower than version Z! LOLZ" because, WTF. You're pretty much also running different versions of the *test suite* itself (since you have to consider the runtime as part of the test suite). Unless you remove that dependency, then sorry, you can't measure things reliably. Which brings me to my second point...
* What exactly are they testing? The whole distro? The compiler (since most of the whole of each distro version is compiled with different versions of GCC)? The kernel? If they're testing the released kernel, then they should run static binaries that *test* the above, comparing kernel differences. If they're testing the compiler, then they should build the *same* compiled code on each version and run said compiled code (which is pretty much what I gather they're doing). If they're testing the utilities and apps that came with the distro, then they should have shell scripts and other tools (which run on a single runtime, not depending on the runtime(s) that came with the distro version). Because if you don't, you have no fucking clue what you're testing.
Honestly, I was unimpressed by the benchmarks. I happen to do performance benchmarking as part of my job, and I can tell you, you have to eliminate all the variables first -- isolate things to be able to say "X is slow". If you rely on a PHP runtime, use *exactly* the same PHP runtime for all your testing; otherwise, you'll get misleading results.
A project gets late one day at a time. There's probably a similar proverb for this too.
Good follow up would be to figure out specifically where - is it due to kernel changes? Then the problem may not be Ubuntu...
Comment removed based on user account deletion
I would like to see if this is an Ubuntu issue or Linux in general.
What about Fedora, OpenSuse, and Debian? How do they compare to Ubuntu?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Apart from XP Embedded, where you can choose which parts of the OS are installed. It's not designed for home-use, but I've used it to make a 140MB version of XP that is blazingly fast. It can play media, has internet access, games, everything I need.
I believe that PIE (position independent executable) along with some other security enhancements were turned on in Ubuntu around the time the slowndowns showed up. This would definitely cause at least some slowdown on the 32bit version since there aren't enough registers to begin with. I'm not sure if it causes any noticeable slowdown on the 64bit version, since the amd64 architecture has a lot more available registers, which would correlate with the person mentioning earlier that the 64bit version seemed fast.