Benchmarks Of The Gentoo-based Sabayon

[smitty3268]

The biggest speed improvements you get from Gentoo are the fact that the bare minimum of services tend to be running, just like you get on other distros like Arch and Slackware.

I think the biggest feature Gentoo has going for it are the USE flags. Setting up a couple of those during setup and leaving the rest out can dramatically slim down an installation compared to most distros which tend to compile in support for everything.

As others have mentioned, the compile times are no big deal. They usually take maybe 15 minutes a weekend, and while it's going you are free to do other stuff like surf the web, so you hardly even notice it. And they provide binaries for a couple of large projects, like OpenOffice. Upgrading KDE can take a few hours, and if you switch to a newer version of GCC you're supposed to recompile the whole system which can take all night, but those are exceptions and not the rule. More commonly I did have to spend some time every now and then merging config files and figuring out emerge conflicts. They're usually quite simple, but certainly nothing I would want to show the "average" user, who would be much happier with Ubuntu/OpenSuse/etc.

Oh, and you really should just use march=native now with gcc4.4. No need to try and specify the architecture manually.

[deanjo]

From gcc flags you are not going ofcourse to get 25% boost. But the small advantage you get in combination with the lean system which means less CPU and memory usage you get a bonus which is obvious in some applications, especially games, Firefox etc, boot times, start up times and your desktop in general feels faster.
The best always is to find a formula to apply different system flags for different parts of the system. For example while I build my system with Gentoo's defaults, my encoders are compiled with O3.

I run a similar test with lame. Gcc 4.4.2 and Kernel 2.6.32.
SUSE defaults = 0m35.996s
Gentoo defaults = 0m35.080s
Gentoo with O3 = 0m34.928s

The difference finally is about 3% better performance. Not something exceptional, but why not since I can have it easily? In games the FPS are even higher, especially in opensource games that I compiled myself.
Also, my system boots in 22 seconds (grub to gdm) plus 8 secs for KDE. Not bad for a 5 years old CPU.
Also, with Gentoo is easy to use ICC. The results are even better, but I can't since I avoid proprietary apps.

I'm not denying that there are small gains to be had nor am I saying nobody should use Gentoo as everybody has different needs. Heck I used to do LFS but PITA factor outweighed the small, almost non existent gains over a "in the can" solution. For those libs that did see an appreciable gain it was just as easy to recompile them from the src rpm after changing rpmbuilds default flags for my arch if I wanted a more permanent rebuild flags. In a network environment gentoo amounts to even more work where the system configs could be very wide spread.

[deanjo]

The biggest speed improvements you get from Gentoo are the fact that the bare minimum of services tend to be running, just like you get on other distros like Arch and Slackware.

Bare minimum services running are just as easily done on other distro's, openSUSE for example even has a YaST module to do just that.

[Apopas]

For those libs that did see an appreciable gain it was just as easy to recompile them from the src rpm after changing rpmbuilds default flags for my arch if I wanted a more permanent rebuild flags.

Yep but you can't do this system wide, since you won't be able to update your system through yast, or yum or apt, but donload the source rpms or debs manually and again compile them manually. Plus is impossible to disable features, since that needs to edit every rpm spec by hand and pray you didn;t forget something.

In a network environment gentoo amounts to even more work where the system configs could be very wide spread.

Depends. If the machines have similar hardware then the configs are the same as well. But even if they are not, then you just make a general stage4 and put it everywhere. Like this you don't get advantage over tthe binary distros, but still you can have as a lean system you want, which is a valuable advantage as well. but still as smitty3268 pointed, with gcc-4.4 you can use march=native, which helps a lot.
Also, the rolling nature of Gentoo, helps to keep every server and client moden for ever, unlike the conventional distros.
But for sure Gentoo isn't a distro which can be used in your machines in dt time unlike OpenSUSE etc.

Bare minimum services running are just as easily done on other distro's, openSUSE for example even has a YaST module to do just that.

True, but why we see so large differences in the benchmarks between binary distros even if they use the same DE, graphics and kernel?

[deanjo]

Yep but you can't do this system wide, since you won't be able to update your system through yast, or yum or apt, but donload the source rpms or debs manually and again compile them manually. Plus is impossible to disable features, since that needs to edit every rpm spec by hand and pray you didn;t forget something.

That's the power of having a personal build service. All of that is easily done automated.

Depends. If the machines have similar hardware then the configs are the same as well. But even if they are not, then you just make a general stage4 and put it everywhere. Like this you don't get advantage over tthe binary distros, but still you can have as a lean system you want, which is a valuable advantage as well. but still as smitty3268 pointed, with gcc-4.4 you can use march=native, which helps a lot.
Also, the rolling nature of Gentoo, helps to keep every server and client moden for ever, unlike the conventional distros.
But for sure Gentoo isn't a distro which can be used in your machines in dt time unlike OpenSUSE etc.

Again these issues are easily dealt with a build service where optimized packages can be built for pretty much any arch. openSUSE's public build service for example is pretty much next day releases when dealing with items such as X11, kernel, alsa, gcc and the various other quick changing projects.

True, but why we see so large differences in the benchmarks between binary distros even if they use the same DE, graphics and kernel?

That's the thing, I don't know where you see these huge differences. As far as the game tests in the above article goes again this can be done on any distro if you wish to compile from scratch or setup a build service to do so automatically. At work for example I run a build server there and separate packages are built for pentium 4, amd64, ia32e and ppc (distributed among various machines, some old workstations to newer machines that are just not used alot using icecream) . When a update comes out from the update service (or a upgrade version from watched projects) it goes out and retrieves the src rpm and builds updates for all of them utilizing the specific optimizations. Set and forget.

[Apopas]

That's the power of having a personal build service. All of that is easily done automated.

You are telling you can set USE flags in an automated way in openSUSE and as easy as Gentoo?

Again these issues are easily dealt with a build service where optimized packages can be built for pretty much any arch. openSUSE's public build service for example is pretty much next day releases when dealing with items such as X11, kernel, alsa, gcc and the various other quick changing projects.

So after 5 years, an OpenSUSE installation is gonna be as modern as Gentoo's one?

That's the thing, I don't know where you see these huge differences. As far as the game tests in the above article goes again this can be done on any distro if you wish to compile from scratch or setup a build service to do so automatically. At work for example I run a build server there and separate packages are built for pentium 4, amd64, ia32e and ppc (distributed among various machines, some old workstations to newer machines that are just not used alot using icecream) . When a update comes out from the update service (or a upgrade version from watched projects) it goes out and retrieves the src rpm and builds updates for all of them utilizing the specific optimizations. Set and forget.

That's a different thing.
You said that "Bare minimum services running are just as easily done on other distro's". So if I install Ubuntu and disable the running services, I will see a speed equal to Gentoo minus the 3% gcc-flags gains?
I have done it, but it still was much more than 3% slower.

[hdas]

As a Gentoo user i can tell you that "Sheer Compilation Time" is a myth
For example, it takes 56 seconds to install Firefox from source.
To recompile the whole thing with over 1K packages is less then 7 hours (I don't measure it usually and the "emerge -j 5 -vuNDe world" executed once something severely broken or something like GCC updated)
Again, the average package installation takes same time is precompiled binary.
And i'm talking about Q9300 with 4GB RAM... It's not fastest computer in any way. But you do need a lot of RAM. The trick is to use RAM disk (autofs) for portage work folder. But, RAM is cheap

Oh come on, 56 seconds for firefox is a joke. The main time goes into emerging the underlying xulrunner engine (which is 8 minutes on my core 2 duo e8400 @ 3.6 ghz - still fast enough). Not to mention gtk and such. How about gcc? evolution? Yes, it does not take too much time to compile, but it is not zero. Defintiely time consuming. And to tell you, the biggest problem is not compile time. It is the default settings and use flags and tinkering on and on with the config files. Things don't come polished out of the box - just raw and simple close to upstream. They by and large do in a 15-minute install of Ubuntu (and possibly openSuse and Fedora).

Yet of course, I don't ever think of ever changing from Gentoo to anything else just because of compile times (and in fact, I have only become more patient). For one simple reason that I like complete control and Gentoo gives me that in a clean elegant way. And it is not just USE flags and package versions. Unfortunately though, mere benchmarks like this article completely miss that point. Optimization is a bonus of course, but from my experience, even debian i386 works almost as well (or even faster and lighter) than my cflags "-march=core2 -O2").

Aside, Sabayon is a great distro and I appreciate the efforts of Fabio Erculani and co . I remember the days (early 2006) when RR64 was one of the first live dvd's to show case xgl and compiz. However, I find default package collection and the distro itself to be too multimedia and gaming oriented. Plus the themes, desktop effects and the catchy logos and the bootup music seem too flashy, gaudy. I would love something subtle and professional like Red Hat or SuSe. I can't say much about the package collection - but games like nexuiz and saurbraten on a default live dvd is outrageous for me. Doesn't seem to be meant for a development machine or workstation out of the box. May be I am a little biased, being more into academics, but that's my opinion.

[deanjo]

You are telling you can set USE flags in an automated way in openSUSE and as easy as Gentoo?

Compared to having to read extensive documentation to setup a Gentoo system most definitely.

So after 5 years, an OpenSUSE installation is gonna be as modern as Gentoo's one?

In place upgrades are nothing new in many distros. In openSUSE's case building against factory will suffice. Up until a few months ago I had a system that was upgraded with each release since SuSE 9.1 (which is about 5 years ago)

That's a different thing.
You said that "Bare minimum services running are just as easily done on other distro's". So if I install Ubuntu and disable the running services, I will see a speed equal to Gentoo minus the 3% gcc-flags gains?
I have done it, but it still was much more than 3% slower.

Not sure about ubuntu but with openSUSE it is very possible which is why it is pleasure to use for JEOS systems.

[XorEaxEax]

Those libraries are the same libraries that pretty much every encoding application out there uses.

Yes, but that doesn't make them any better for comparing compiler options unless you _explicitly_ turn off any hand optimized assembly, like Multimedia Mike does for instance:
http://multimedia.cx/eggs/last-perfo...wn-for-awhile/

Also to note that over aggressive optimizations often result in slower binaries.

Yes, otherwise they wouldn't be 'over aggressive' would they?

My tests were to simply show that going from a base optimizations in x86-64 to "tweaker" flags certianly do not yield a 25% increase in speed and that one set of flags is not universal for best performance system wide.

No, not universally. But I've had alot of great improvements on programs like raytracers, emulators, compression etc by tailoring my cflags.

for instance, I recently downloaded sdlmame via pacman on my Arch machine. The standard makepkg.conf was something like '-O2 -mtune=athlon64'

I benchmarked a number of games and then I compiled it again using tailored flags (I believe they were -O3 -march=k8-sse3 -fomit-frame-pointer -mfpmath=sse -ffast-math), now the greatest increase was a game that became 29% faster and the smallest increase was 11%. So depending on application there can definitely be great gains. Also I did another build where I also added profile-guided optimization and the greatest increase then was 35%.

[bnolsen]

Well I've been running gentoo for probably 8 years now. My patience wears thin with some of the compilation, especially firefox & Qt. The last dual core I had was 2GB would run out of ram during qt compilation and would annoyingly lock the system. Considering I had access to a couple of gentoo dual quads which chewed through compilations, well the dual superbly sucks in comparison.

gentoo has 2 problems.

- init & configuration are grossly over engineered. arch does them much better.
- use flags are a mess. They should be refactored down into classes, reducing the number by 10-50x. Good example: i just want all the multimedia codecs. I shouldn't have to go hunt down and pick every single one, nor have to keep on top of manually adding new codecs. The class should pick them up.