There are a lot of superfluous details in this article. After doing a few initial benchmarks it should have been obvious that the largest performance decline occurs between the 7.04 and 7.10 releases. The article should have answered that question first before throwing 8.x into the mix.
Also, don't use a laptop for benchmarking operating systems!
In my experience I have found that XP boots and runs faster than Ubuntu 8.10 on my laptop. This was not the case on the same machine back in the 7.04 days.
That's a different type of test. You're talking about testing the performance of your laptop with various configurations. This article is comparing the performance of several versions of Ubuntu and the reason you don't want to use a laptop for that is because laptops have significantly slower hard drives than desktop models (even at the same RPM). Also the laptop they're using has a 5400 RPM drive which doesn't help.
This can simply be answered by looking at the number of start-up scripts that are being executed. If that number has increased relative to 7.04, then of course your boot time is going to be slower. There are not too many things inherently different between the past few releases in terms of booting.
You're right. It's valid and necessary when you want to compare the performance of different machines. When you're comparing software to software, hardware should not be a limiting factor unless you're testing for specific cases.
Does Linux perform poorly on laptops? I've never looked into it.
I'm not suggesting that performance tests should not be run on laptops. As I said in my reply to palish, When you're comparing software to software, hardware should not be a limiting factor unless you're testing for specific cases.
I still don't understand. Hardware will always be a limiting factor in the sense that if you had better hardware, the software would run faster. So what's wrong with running tests on laptops, one of the main platforms operating systems are needed for.
To clarify, a specific piece of hardware should not knowingly be a limiting factor unless you're testing for a specific case (for example, specifically testing for performance with a slow hard drive). I'm advocating a balance across all pieces of hardware.
Yeah. I have a simple way to find out if Ubuntu is getting slower:
1. How many people are assigned to adding features and making upgrades? What level of authority do they have?
2. Same questions, but assigned to performance monitoring and enhancement.
Software is such a product of the culture that produced it that sometimes you don't even need to run benchmarks.
Seeing benchmarks conducted by Phoronix always fills me with emptiness on the inside. While I really welcome the idea of benchmarking Linux, their methodology always seem lacking for me.
All we get are a bunch of numbers, without any actual investigation of what those numbers should represent, what can be the reason of the outcome, and sometimes the measurements make simply no sense.
For example, according to these benchmarks, Ubuntu 7.04 reads memory twice as fast as newer versions. There is no possible way it can be a valid result. At least assuming that the exact same compiled code was used on every installation. Which brings us to another problem: no information on the tests. All we get is a software name, a version number and the result numbers. Which would be almost fine if they were prepackaged binaries, but with FOSS different compile time options and compiler flags can make quite a difference in the results too.
About the nonsensical tests: RAM speed should be the same regardless of the OS. So dedicating a full page to RAM speed tests should be senseless. No. It's actually a nice control to the tests, and the numbers show that there's a problem somewhere. Either the tests, the measurements are off significantly, or there is something flawed in either the 7.04 configuration or the others that cause almost 50% difference in such test.
Also, measuring compile times. They managed to measure the time it takes to compile 3 software written in C using an unspecified compiler with unspecified options.
At the end, no conclusion were drawn, just the results summaried in English instead of plain numbers. The whole thing gives me the feeling that they don't really know that they are testing, they're just running a bunch of programs and reporting the numbers they output.
I'm sorry if it seems like I'm just ranting, but I've tried a couple times sending emails that point out the flaws in their methodology, to no use.
I've always found that benchmarks are not good at showing OS performance for desktop applications. Why? I don't really need raw speed. What I need is something that will allow me to switch tasks and use other applications while one is locking up/doing a ton.
BeOS was great at that. I'm guessing the new Comlpetely Fair Scheduler that is debuting in Intrepid is better in that way too. My use of Intrepid shows it to be noticably faster in my daily usage. However, I'm not compressing video. I'm running several apps at a time and need to switch between them a lot.
When slashdot ran this story, the readers commented that the results seem suspicious. Misconfigured power saving settings are likely the cause of the speed difference.
19 comments
[ 3.9 ms ] story [ 43.3 ms ] threadAlso, don't use a laptop for benchmarking operating systems!
Why not? Laptops are poised to overtake desktop PCs. It seems valid (even necessary) to test your product on popular consumer configurations.
In my experience I have found that XP boots and runs faster than Ubuntu 8.10 on my laptop. This was not the case on the same machine back in the 7.04 days.
That is exactly the kind of thinking that results in Linux's poor performance on laptops.
I'm not suggesting that performance tests should not be run on laptops. As I said in my reply to palish, When you're comparing software to software, hardware should not be a limiting factor unless you're testing for specific cases.
1. How many people are assigned to adding features and making upgrades? What level of authority do they have? 2. Same questions, but assigned to performance monitoring and enhancement.
Software is such a product of the culture that produced it that sometimes you don't even need to run benchmarks.
All we get are a bunch of numbers, without any actual investigation of what those numbers should represent, what can be the reason of the outcome, and sometimes the measurements make simply no sense.
For example, according to these benchmarks, Ubuntu 7.04 reads memory twice as fast as newer versions. There is no possible way it can be a valid result. At least assuming that the exact same compiled code was used on every installation. Which brings us to another problem: no information on the tests. All we get is a software name, a version number and the result numbers. Which would be almost fine if they were prepackaged binaries, but with FOSS different compile time options and compiler flags can make quite a difference in the results too.
About the nonsensical tests: RAM speed should be the same regardless of the OS. So dedicating a full page to RAM speed tests should be senseless. No. It's actually a nice control to the tests, and the numbers show that there's a problem somewhere. Either the tests, the measurements are off significantly, or there is something flawed in either the 7.04 configuration or the others that cause almost 50% difference in such test.
Also, measuring compile times. They managed to measure the time it takes to compile 3 software written in C using an unspecified compiler with unspecified options.
At the end, no conclusion were drawn, just the results summaried in English instead of plain numbers. The whole thing gives me the feeling that they don't really know that they are testing, they're just running a bunch of programs and reporting the numbers they output.
I'm sorry if it seems like I'm just ranting, but I've tried a couple times sending emails that point out the flaws in their methodology, to no use.
BeOS was great at that. I'm guessing the new Comlpetely Fair Scheduler that is debuting in Intrepid is better in that way too. My use of Intrepid shows it to be noticably faster in my daily usage. However, I'm not compressing video. I'm running several apps at a time and need to switch between them a lot.
http://linux.slashdot.org/comments.pl?sid=1008879&cid=25...