As the article says in the ifrst page: "The x86_64 builds of both Fedora 11 and Ubuntu 9.04 were used."

Arrg, how lame of me, thanks for pointing it out. Then it would be nice to add the 32 bit ;-) Seriously, this is the most FAQ I see in forums from people who just bough a 64 bit system (namely: "Does 64 bit perform better?").

06-11-2009, 09:13 PM

kxmas

Quote:

Originally Posted by mendieta

I agree with the objections, but I think compilation of a rather large project has historically been used as an overall system benchmark because it exercises CPU, memory and disk read/writes. So, besides the caveats you all provided, it's still a nice benchmark if taken with a grain of salt

In summary, it's the best benchmark ever, except that it doesn't mean anything.

Other than the kernel related performance differences, Ubuntu kicks Fedora anal. Time to switch.

Just disable SELinux and performance should be better.

06-12-2009, 06:03 AM

chronomatic

You guys are overlooking the biggest reason Fedora performs worse in some of these tests (and frankly I am disappointed no one has mentioned it).

Fedora's performance is impacted by the fact that many of its binaries are compiled with options like FORTIFY_SOURCE and -fstack-protector as well as ASLR hardening. Further, exec-shield and Selinux are on by default. All of these protections will put a small hit on performance (SELinux alone can sometimes result in as much as 7% overhead on some benchmarks) Bottome line: when all of these protections are combined, the results in this benchmark seem about right. You can read about Fedora's security features here.

No other desktop Linux distro I am aware of offers the security that Fedora does out of the box. So, really, we're comparing apples to oranges here. Essentially, it's a trade off (just like many things are when choosing a distro), and in this case it happens to be performance vs. security. Personally, I am willing to give up some performance in some areas for the increased security.

06-12-2009, 06:11 AM

chronomatic

(I already posted my reply once and it didn't show up, so if it does show up later, I apologize for the double post).

I had a long reply as to why this benchmark showed the results it did, but I will summarize:

Fedora has increased security that can only be achieved through some compiler options like FORTIFY_SOURCE, -fstack-protector, PIE, and exec-shield. Most of these options will result in a performance hit. And that doesn't even count SELinux, which in itself has shown overhead as high as 5-7% in some tests. It's obvious to me that (especially in the Apache tests) this is why Ubuntu performed so much better. Ubuntu is not protected like Fedora is! (AppArmor on Ubuntu only protects CUPS by default and has no impact on overall system performance).

All of that data is easily available and clear through the Phoronix Test Suite.

Ok, but it would be good to see the error bars on the graphs in the report as well then, to give people a better idea visually of the nuances.

John

06-12-2009, 12:29 PM

Kano

@chronomatic

Usally all apps are compiled from source if they are not binary only. That usally does not affect it, but you might have installed more build-deps on one system that would enable additionally features and compile longer for example.

06-12-2009, 02:54 PM

bjrosen

Please try to figure out the reasons for the differences

Just reporting benchmark results isn't all that useful, please try to figure out the reasons for the discrepancies in performance. For CPU bound programs the differences in performance between Fedora and Ubuntu should be in the noise, when you find large differences it's worth digging deeper to find out the reason. Are the CPU Speed Governors set the same? Is it SeLinux? are there background processes that are running on one and not the other. Is it compiler switches? Is it the kernel rev? It's easy to enable/disable/change SeLinux, daemons, speed governor modes, firewall and even file systems. It's also easy to compile a standard kernel using identical switches for both distros, that would allow you to isolate the effects of the kernels.

06-12-2009, 08:35 PM

highlandsun

Or just run the benches with the CPU governor set to powersave, and lock it at the lowest speed. This will reduce the influence of peripheral device speed, and focus on CPU/software efficiency.

I sometimes have to do that when testing/debugging multithreaded code, because problems that don't occur on a fast multicore test can sometimes be revealed on a slower system...