If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Intel Ultrabook: Fedora 18 vs. Ubuntu 13.04 Tests

04-04-2013, 11:20 AM

Phoronix: Intel Ultrabook: Fedora 18 vs. Ubuntu 13.04 Tests

Our latest benchmarks from the ASUS S56CA-WH31 Intel Ultrabook is comparing the performance of this Ivy Bridge laptop between Fedora 18 and a recent Ubuntu 13.04 development snapshot under various workloads...

Comment

What's with that crazy performance diff between Fedora and Ubuntu on Apache?

I had that same question.... possibly different apache versions, and the one in fedora has a bug. Different default configurations FOR apache, SELinux on fedora may be getting in the way. If Rahul or any of the other RedHat / Fedora guys could weigh in, itd be appreciate because that is a serious regression in comparison

Comment

I don't know why anybody would care about static web page performance. It's essentially a test to see who could be the fastest at doing nothing. Either of them are going to be plenty fast enough.

There could be a lot of good reasons why Fedora would be slower at that. Default threading model, for example. Maybe Ubuntu has it setup so that more processes and threads are started by default or something like that.

I'd look at the obvious differences first before I'd start speculating about compile options or selinux getting in the way. SElinux overhead should only be a few percentages at most.

Comment

Our latest benchmarks from the ASUS S56CA-WH31 Intel Ultrabook is comparing the performance of this Ivy Bridge laptop between Fedora 18 and a recent Ubuntu 13.04 development snapshot under various workloads...

Comment

I don't know why anybody would care about static web page performance. It's essentially a test to see who could be the fastest at doing nothing. Either of them are going to be plenty fast enough.

There could be a lot of good reasons why Fedora would be slower at that. Default threading model, for example. Maybe Ubuntu has it setup so that more processes and threads are started by default or something like that.

I'd look at the obvious differences first before I'd start speculating about compile options or selinux getting in the way. SElinux overhead should only be a few percentages at most.

Yeah, I'd guess it's just not a realistic comparison - possibly Fedora uses the upstream defaults for Apache config, while Ubuntu ship a pre-tuned version. If so, it's a meaningless benchmark, since nobody is going to run a real server on the default configuration. It'd be more interesting to see a tuned vs tuned comparison, to show up any differences in the actual OS (like the other benchmarks are doing).

Comment

So, we're testing yet to be released Ubuntu with the current release of Fedora?
F19 has branched, why not use that?

Fedora builds before Beta are very slow due to the use of debug-enabled kernels (a few other packages have performance-impacting debug stuff enabled early in the build cycle too, IIRC).

These kinds of comparisons are usually of pretty limited value, though; the basic answer is that any major difference in performance between two mainstream Linux distributions is almost always the result of some kind of specific, transient bug that will get fixed, an error in the test, or some configuration setting (in which case it'd make much more sense just to tweak your configuration for whatever distro you wind up picking than pick your distro based simply on what it picks for a default configuration for some component or other). These kinds of comparisons are sometimes useful for turning up bugs, but that's about it. Linux distributions are ultimately built in much the same way from most of the same source code; it's just to be expected they'll usually perform about the same at the same workload, if you organize your test correctly. Some kind of idea of 'general performance' is not a good factor to consider in choosing a Linux distribution; it makes much more sense to choose your distribution based on the things that actually differ between distros, and then optimize performance of your particular workload once you've picked a distro.

Comment

Fedora builds before Beta are very slow due to the use of debug-enabled kernels (a few other packages have performance-impacting debug stuff enabled early in the build cycle too, IIRC).

These kinds of comparisons are usually of pretty limited value, though; the basic answer is that any major difference in performance between two mainstream Linux distributions is almost always the result of some kind of specific, transient bug that will get fixed, an error in the test, or some configuration setting (in which case it'd make much more sense just to tweak your configuration for whatever distro you wind up picking than pick your distro based simply on what it picks for a default configuration for some component or other). These kinds of comparisons are sometimes useful for turning up bugs, but that's about it. Linux distributions are ultimately built in much the same way from most of the same source code; it's just to be expected they'll usually perform about the same at the same workload, if you organize your test correctly. Some kind of idea of 'general performance' is not a good factor to consider in choosing a Linux distribution; it makes much more sense to choose your distribution based on the things that actually differ between distros, and then optimize performance of your particular workload once you've picked a distro.

I hesitate to say this, but for most users it is safer to stick to defaults than to try to tweak things.
For one thing, you need to know what tweaks are available, then you need to know what it is they do. Next you need to be able to reliably test these changes to see if they actually make a difference in what you care about (this later one is the biggie, IMHO).
I know you are aware of these things, but I wanted to explain why I think it is safer to stick with the defaults for most users, and why benchmarking can be useful, even if that which is done on phoronix isn't of the most useful kind.
Your point about debugging is fair, though.