Is Ubuntu Getting Slower? 544
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.'"
Re:Performance isn't its raison detre (Score:5, Interesting)
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.
Re:What hardware? (Score:1, Interesting)
For once I agree with a Gentoo/Slackware zealot who posted "This is what happens when you put out pre-compiled kernels, it makes it too easy for stupid people." And this is how questions like this arise. If you want performance, compile your own kernel with only your optimizations, then come back to us.
Re:Performance isn't its raison detre (Score:1, Interesting)
Complete and utter crap.
Most likely the performance decrease is to do with some unoptimized kernel feature. That kernel feature should be identified and optimized. Linux actually has a nice history of maintaining status quo or getting faster between releases. Atleast when you track it over say 10 releases.
I don't understand this, quite frankly, Windows user mentality of just accepting the state of things.
I would love to see Phoronix do a retest with some of the major patchsets removed and see if they can find the one or ones that cause performance decreases.
Look carefully at the power management (Score:5, Interesting)
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...
Re:Performance isn't its raison detre (Score:2, Interesting)
I'm not convinced they know what they're doing (Score:5, Interesting)
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.
I see what you did there.... (Score:2, Interesting)
Re:What hardware? (Score:2, Interesting)
Re:Maybe (Score:1, Interesting)
Re:Look carefully at the power management (Score:5, Interesting)
Mod parent up.
Many of the benchmarks (such as the lame, Java and RAM bandwidth benchmarks) are CPU-bound, and will run the majority of time in userspace. As the kernel should only be invoked for timer ticks, interrupts, TLB misses, etc (which would probably account for less than 1% of the CPU time), and change to the kernel should have minimal impact on the benchmarks.
The parent's comment that power settings have been misconfigured sounds spot-on.
Re:Ubuntu isn't getting slower, no. (Score:5, Interesting)
Performance Problems AREN'T Where You Think... (Score:5, Interesting)
... 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.
Re:Performance isn't its raison detre (Score:5, Interesting)
Re:Security Patching? (Score:5, Interesting)
Good follow up would be to figure out specifically where - is it due to kernel changes? Then the problem may not be Ubuntu...
Ghostview/Postscript? (Score:4, Interesting)
I hadn't noticed any general slowness when I upgraded from Feisty to Hardy (if anything, it was slightly faster), but I have noticed that when I run a document (even a short one) through groff, the resulting postscript file takes a lot longer to refresh in gv and evince. Alas, lots of googling revealed no similar situations, so it may just be something idiosyncratic with my set up.
Re:Security Patching? (Score:5, Interesting)
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?
Well, hurra for choice. (Score:3, Interesting)
I'm sure some people here are going to be comparing Ubuntu to Vista in regards of getting slower with release, but because it's Linux we have a few more choices.
They make distros that are meant to be lightweight- Anyone with a machine that's a little old, I urge you to try one of them. You'll be pleasantly surprised and maybe find a new favorite window manager/desktop environment in the process. Before you start talking about how joe sixpack doesn't want to try another distro or learn anything about Linux- I'm not talking to Joe sixpack here, I'm talking to you, a slashdot lurker.
Try one of these distros and be amazed at how fast everything is:
Crunchbang Linux [crunchbang.org]
KMandla's GTK 1.5 Remix [wordpress.com]
Or, if you want to be more adventurous, get Arch Linux [archlinux.org] and grab a window manager like Openbox or PekWM. If you go that route, take a look at this Openbox guide that'll show you a nice panel to use, file navigator, and generally hold your hand through the process, here [wordpress.com]. But if you want your hand held even more, someone packaged a panel and file navigator and theme chooser and stuff like that together with Openbox already- Called LXDE. You can just grab that too, should be in any repository.
I do think it's unfortunate for joe sixpack that it's getting a little slower- But for them it's still faster than Vista and XP, right?
You know what they should make? They compile pretty much everything in the kernel as a module, and then they probe hardware and load the right modules each time you boot... It would be cool to be able to do a "Speed up my computer" boot where it loads the modules, and then compiles a kernel with the modules for the hardware it finds compiled into it. Disable things that it hasn't seen their computer use, etc., and then just still probe the hardware to fall back on another kernel if things have changed.
OR, how about loading modules when you actually need them..? And this goes for daemons, too. When you go to listen to something, and it returns that there's no module loaded for sound, how about loading the module then, and then starting the alsa daemon. Have you ever looked at the daemon list for Ubuntu? It's huge. I know I don't need all of those- I know because on the distro I'm on now I only run 3 daemons on boot, and everything works fine.
I don't know. Maybe that's not the solution. But those guys are clever, I'm sure they can come up with something to get rid of the extra daemons and modules running without sacrificing usability. Anyone here have any good ideas..?
Re:Flexibility and freedom are its raison d'Ã (Score:5, Interesting)
Is PIE the primary cause? (Score:5, Interesting)
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.
Re:GCC is getting slower (Score:3, Interesting)
From those benchmarks the one thing that stuck out was that GCC is getting slower.
That's a well-known fact for us source-based distributions/OS users. Compiling everything from source on Gentoo, or the BSDs took a severe performance hit since GCC got more and more slow (for no apparent reason), esp. the C++ backend... But what's slowing Ubuntu down is probably the quality of ASM code generated by GCC, as well as programs being writting more and more sloppily by developers with very fast machines.
Maybe the source of the problem is actually GCC getting slower. This forces developers to use faster machines to shorten the compile runs; but those faster machines also hide the problem of software getting slower. Many devs simply don't care anymore for slower machines, because they simply don't see the problem on their own boxes. To them, the software is "fast enough."
Re:Performance isn't its raison detre (Score:3, Interesting)
I'd bet almost all of it is the effect of the scheduler. The benchmarks all show single tasks taking longer, but that's not taking into account multi-process performance. Is the desktop still responsive now even with a high-intensity background task running? I'd take that over the task finishing 5% faster any day.
Re:Flexibility and freedom are its raison d'Ã (Score:3, Interesting)
Indeed. I might have to go install something like XPLite or create my own installation media with nlite/vlite. It's really taxing firing up a GUI and unticking a few boxes.
Yes, unticking boxes is easy. So's deleting a file. But what happens after the fact?
Those utilities do look like a step in the right direction. Pity they're from a third party and a complete hack (albiet a very cool looking one). What happens when Microsoft releases a service pack? What happens if you change your mind and want to install a component?
I know with Ubuntu I'm removing a package using the very same tools provided by the base distro. When I update, I only update whats installed. And I know I can always install / re-install anything missing at a later time.
Re:I'm not convinced they know what they're doing (Score:3, Interesting)
Indeed, but supposedly the rest of the system was mostly idle, it shouldn't have slowed down a CPU-bound calculation by 50%, otherwise it's a scheduler regression.
The supposition is not part of the facts. My point was there are some benchmark number that should have remained constant but showed variability.
The benchmark is utterly useless until they can explain the variability in tests that should be constant.