Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Is Ubuntu Getting Slower?

Posted by CmdrTaco on Mon Oct 27, 2008 08:31 AM
from the slow-like-a-fox dept.
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.'"
+ -
story

Related Stories

[+] Technology: Ubuntu 8.10 vs. Mac OS X 10.5.5 Benchmarks 328 comments
An anonymous reader writes "As a sequel to their Is Ubuntu Getting Slower? Phoronix now has out an article that compares the performance of Ubuntu 8.10 to Apple's Mac OS X 10.5.5. They tested both the x86 and x86_64 spins of Ubuntu and threw at both operating systems a number of graphics, disk, computational, and Java benchmarks, among others. With the Mac Mini used in some of the comparisons, 'Leopard' was faster, while in others it was a tight battle."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • What hardware? (Score:5, Insightful)

    by el_chupanegre (1052384) on Monday October 27 2008, @08:40AM (#25525481)

    Were they testing each distribution on exactly the same hardware?

    If so, that sounds completely fair to me that it would be slower. Go and (try to) install Vista on a machine that originally came with XP (pre-SP1) and see how much slower it is. Is that a fair test either? I think not.

    As software gets more useful (and Ubuntu has, Vista not so much) it gets bigger and thus gets slower on the same hardware. Hardware advances at the same time though, so in real terms they keep about equal. When you test new software on old hardware of course it's going to be slower though.

    • Re:What hardware? (Score:5, Insightful)

      by lolocaust (871165) <sage> on Monday October 27 2008, @08:50AM (#25525571) Homepage Journal
      Read the article, please. The exact same releases of software (such as the LAME encoder) shouldn't have a 2-3x decrease in performance.
    • Re:What hardware? (Score:5, Informative)

      by gbjbaanb (229885) on Monday October 27 2008, @09:00AM (#25525689)

      When you test new software on old hardware of course it's going to be slower though.

      That's hardly a given, lots of software gets better as it ages - new features are added, but also performance tweaks get added.

      The problem is that software should be getting quicker on the same hardware, the alternative is bloaty apps that no-one wants to use. See Vista for the ultimate conclusion to that. You don;t want Ubuntu to end up the same, so its good that someone is pointing out performance issues. Hopefully the next release will have a few of these issues looked at and improved.

    • Re:What hardware? (Score:5, Insightful)

      by blind biker (1066130) on Monday October 27 2008, @09:07AM (#25525739) Journal

      I heard this argument a wee too often. Maybe software should be more useful while at the same time NOT getting slower? Maybe that would be a good thing, as it would then run well on netbooks as well, what do you think?

    • Re:What hardware? (Score:5, Insightful)

      by RAMMS+EIN (578166) on Monday October 27 2008, @09:08AM (#25525751) Homepage Journal

      You make it sound like it is inevitable and acceptable that newer software is slower than older software. I disagree. For one thing, one way to improve software is to make it faster. This is actually done sometimes. Secondly, even if you add features to software (which is another way to improve software), that doesn't have to make the software slower. In some cases, this may be inevitable, but in many cases it is not.

      I personally see computers, and software, as tools for making life more efficient. When software becomes slower, efficiency is actually lost. When this isn't offset by providing me with a more efficient work flow, I lose efficiency. Since efficiency is the main reason I use computers in the first place, this is a big deal.

      • by Sockatume (732728) on Monday October 27 2008, @08:54AM (#25525613) Homepage
        Indeed, it is common knowledge amoungst Real Programmers that you can run an arbitrarily large number of instructions per clock, allowing you to introduce entirely new functionality with zero performance hit. You just need to write everything in asssembler and have the right enchanted oils to annoint the heat sinks. By such a scheme CowboyNeal famously calculated the highest possible prime and now lives forever in a magic castle full of unicorns which shit rainbows.

        (Hey, he used an absolute, I'm entitled to extrapolate it to its logical implications.)
  • Security Patching? (Score:5, Informative)

    by Ironsides (739422) on Monday October 27 2008, @08:51AM (#25525585) Homepage Journal
    Ok, the article completely ignores this (as do most of the above posters it appears). Each version of Ubuntu tested seemed to have different kernel builds. How much of the slowdown is due to the kernel being patched for security and bugs and how much is due to the software that has been added?
  • by Peter Desnoyers (11115) on Monday October 27 2008, @08:52AM (#25525597) Homepage

    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...

    • by trumplestone (820102) on Monday October 27 2008, @09:15AM (#25525829)

      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.

  • by mlwmohawk (801821) on Monday October 27 2008, @08:54AM (#25525617)

    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.

  • by Anonymous Coward on Monday October 27 2008, @09:16AM (#25525841)

    ... 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.

    • Complete bullshit article, doesn't offer any useful information beyond a completely obvious conclusion -- the more features that are added to a given piece of software, the higher the demands on your PC.

      I would think that those increased demands should be mostly in the form of slightly (a few MB) higher memory requirements to store the extra code for those features. Adding new functionality should not impact existing functionality. Haven't you heard of the zero-cost principle (idea from C++ and apparently Perl, "you don't pay for (as in take a performance hit from) what you don't use")?

    • by Sockatume (732728) on Monday October 27 2008, @09:16AM (#25525835) Homepage
      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.
    • by liquidpele (663430) on Monday October 27 2008, @09:17AM (#25525875) Homepage Journal
      Insightful? Seriously?

      They ran the tests on a modern laptop, and noticed a perceived slowdown. It would be idiotic to ignore that just because new features were added.
    • Re:xubuntu (Score:5, Informative)

      by Mr.Ned (79679) on Monday October 27 2008, @09:15AM (#25525823)

      Xubuntu's performance targeting appears limited to choice of desktop environment, which was a small component of what these benchmarks tested. The big performance increases the article talks about were in databases, compilers, encryption, memory access, and audio/video encoding/decoding, none of which really have much to do with the desktop environment.

    • Re:Ubuntu? No way. (Score:5, Insightful)

      by thatskinnyguy (1129515) on Monday October 27 2008, @09:16AM (#25525857)

      "Ubuntu" -- an African word, meaning "I'm sick of fucking with Linux in order to get it to do what I want but I really don't like the alternatives."

      Yeah, I rocked Gentoo for a couple of years. I just want something that is fast, easy to use and gives me as little of a headache as possible. Linux is Linux and most of the knowledge learned in one distro will carry-over to another.