Gentoo Optimizations Benchmarked

Gentoo is a source based distribution which lets the user decide how to optimize their system in many ways. Linux Magazine benchmarks three of the most common GCC optimizations; -Os, -O2 and -O3, and throws in Ubuntu for good measure.

Compilation
Compiling applications is something you rarely have to do on a binary system, but it’s obviously commonplace on a source based distro!

Naturally the systems with less optimization for the compiler to do takes less time.

Gaming

When it comes to gaming, everyone wants higher frame rates. These systems were all using NVIDIA’s proprietary video driver, and some of the games such as ut2004 were pre-compiled binaries.

There’s not much difference to be seen here between the GCC optimized systems, although the Gentoo system did generally perform better than Ubuntu.

Graphics
When it comes to graphics, the arena is fairly broad. First up is manipulation of images.

In these tests -O3 is generally the most efficient, however the “resizing” results show -Os with its smaller memory footprint coming out on top. Once again there is not a whole lot of difference between them, however Ubuntu is consistently in last place.

Next in Graphics is ray tracing.

The standout result here is -Os in the POV-Ray test, which was almost one and a half times faster than its nearest rival.

Next it’s benchmarking GTK operations with GtkPerf.

Ubuntu was the clear loser in these tests, with -O3 out performing all contenders.

Comments on "Gentoo Optimizations Benchmarked"

ewildgoose

Gentoo seems (incorrectly) synonymous with this idea that you can fiddle with your gcc flags and make things faster. This may or may not be the case, after all it\’s a piece of cake for Ubuntu to take the output of this test and then make sure that next time all packages are rebuilt with O2/Os, etc as appropriate for best performance

In fact the magic of gentoo is it\’s great dependency system, massive software library and very flexible configuration system. The downside of that is complexity in use and sometimes slower speed of installation – definitely gentoo is NOT for everyone.

However, like all tools they have their place. Some people like a potato peeler and others prefer a knife. Knives are very flexible, but also can cause you much grief and require a greater skill to learn to use. Which is the \”best\” tool is really a function of the desired task and needs of the operator

We use Gentoo to manage all our servers (many of them virtualised). This gives us the following advantages:

- No need to ever re-install because a new version is released. Instead we have a continuous rolling upgrade which keeps the servers always up to date with the latest software (risk of breakage while upgrading is largely mitigated by virtualisation which makes it easy to test an upgrade first and software versions can be pegged if you want to prevent an upgrade)

- We set gentoo to create binary packages as it compiles – this means that the first server can be somewhat slow to upgrade, but thereafter the other servers (which are set to identical compile settings) all pull the binary packages

- Gentoo has very flexible options to avoid pulling in a wadge of dependencies. This means you can easily create small virtual servers without a ton of bloat. For example we ask all packages which have bash-completion options to install their scripts for our ease while using the command line, but conversely largely we ask packages on our virtual servers not to install their bulky documentation, python/perl/ruby/snmp, etc dependencies – this keeps the package sizes small

- Near end to dependency hell!! No more thrashing around trying to solve a dependency nightmare! I am literally in the middle of upgrading 20 servers from GCC 3.4 to gcc 4.3, at the same time – no breakage whatsoever. Try upgrading major versions of readline/gcc/libhistory/mysql, etc on any RPM/Deb distro and you are in for a big headache (or more likely it\’s a major OS update), but on gentoo you can just pick a package version, then a script (revdep-rebuild) will rebuild any affected packages and correct the dependencies for you.. Cool!

So in conclusion it\’s entirely possible that our servers run a touch faster because we use gentoo, but I personally would still use it if they ran only 3/4 the speed of some other distro… Never having to re-install a server and the huge flexibility when installing packages (and having all appropriate dependencies resolved and built correctly) is the main win for me

However, please don\’t rush out and assume it works for you – I think gentoo is a complex tool and will likely only suit the more technically minded users. For everyone else I suspect that Arch/Sabayon, etc are probably more appropriate…

(This doesn\’t make it a bad distro – it\’s just that Ubunutu solves the needs of most users and therefore only those who need *more* flexibility in package management than Ubunutu brings are likely to want to investigate further)

Reply
pattakosn

I would like to see a similar comparison to Slackware and Arch. Other major distributions (RedHat,SuSE,Debian) would also be interesting, but the first ones are (supposed to be?) faster because they are \”simpler\”

Reply
evardsson

I have to agree with ewildgoose. I have been using Gentoo for production servers for several years now, and I much prefer the maintenance routines on Gentoo over RedHat and Debian.

In my current position our servers are hosted by an outside company and they won\’t do any hands-on for any system that isn\’t Debian so I am forced to work with that. Unfortunately, that means that sometimes security updates require a complete system rebuild to a new version. This does not amuse me.

My personal server has been running Gentoo since 2006 with reboots only for new kernels, power outages and physical moves. And even with new kernels those outages are very short. Rebuilding the Debian machines on the other hand …

Reply
ewildgoose

evardsson – we don\’t require hands-on support for our servers and we use a hosting service which gives us serial port access to our machine. This means we can see everything from the end of the bios boot onwards, including accessing grub. Additionally our host provides a \”rescue boot\”, but this can be simulated by a boot CD left in a drive. This together allows us to do remotely format the machine, install gentoo and manage everything including failed kernel upgrades, bootloader issues, etc

pattakosn – you are like many people debating whether 10% speed difference between two distros is relevant – for most purposes it\’s not. The key features for most users is how well the distro works for you and fits your needs. So evaluate Arch/Gentoo/Slackware/Ubuntu in terms of \”how much work you can get done over the next week\”, and then performance, ease of management, etc all effectively get boiled down to a much more objective benchmark – for me and my servers Gentoo lets me get stuff done and not spend time managing packages – for a desktop machine I may have different priorities though…

Slackware and Arch are kind of gentoo\’esque, but have headed in different directions. Arch (which I don\’t know that well) is a mostly binary packaging system, but the source to generate the packages is more available than it is if say you decided you wanted to recompile Redhat from the RPMS (source) – also the default compile architecture is a bit more aggressive (i686 I think?). Slackware is kind of even less user friendly than gentoo, and where gentoo effectively is a bunch of scripts which pull down all your source and compile it and basically do all the hardwork for you, slack is really a very nice manual on how to do all this yourself.

Personally slack doesn\’t work for me because there doesn\’t appear to be a strong package manager which watches files and can remove them or manage them for you (with gentoo, rpm/deb you can ask the package manager who installed any file, files are cleaned up when the package is uninstalled and config files are treated differently to binaries).

Arch could probably suit me nicely, but I don\’t have much experience with it…

Reply
lescoke

I stumbled on a forum post pointing out that gentoo does not use the make.conf optimizations when building the kernel.

The biggest reasons I run Gentoo besides my use of older hardware are:

1. I can build the system from the ground up on whatever convoluted file-system I can create with the live CD (Raid, EVMS, Luks,…). Many of the other distro\’s require you install a working system first, then, rearrange things to your liking.

2. Like ewildgoose said above, Gentoo\’s portage provides a rolling upgrade to the latest system. You can upgrade as time allows. But be prepared for blocked and circular dependencies if you allow too much time between updates. Definitely test updates on non-production machines first.

3. You can still install binaries instead of compiling from source if the optimizations are not critical.

Reply
redmumba

I\’m a huge Ubuntu fan, but having tried my hand at Gentoo as well, I have to note that these benchmarks have the potential to be inaccurate. For example, prelink–a third party program–is enabled on Ubuntu, which would certainly speed up certain actions. And what about compiler flags? How was the kernel compiled–with the generic \”world\” install or was it built specifically for the system?

Even using different kernel versions could make for huge variations–probably in Gentoo\’s favor. In fact, I know for a fact 2.6.28 is in portage, so why wasn\’t that used…? Being an nVidia user, I can also tell you that the binary nVidia drivers can be day and night between versions, with one version tying up resources or causing unnecessary processor load, and even a slightly minor version in either direction eliminating it.

I really, really appreciate the effort, and I\’m not trying to be a troll, but the fact that Ubuntu does a lot for you and Gentoo does nothing means that trying to compare them is a very difficult process. For example, if I were benchmarking a Windows program, would you consider the output from Windows 2000 to be comparable to Windows XP Professional, even though they\’re largely similar? Or between XP and XP SP3?

EDIT: Kudos to everyone praising Gentoo; I agree that portage is the best package manager out there, binary, source, or otherwise!

@ewildgoose: In my opinion, if you\’re already on Gentoo, you\’ve surpassed the need for Arch. I tried Arch for a few months, and while it does give you the \”compile from source\” aspect, it just doesn\’t compare with Gentoo\’s user and community base. What I usually recommend is for people who are looking to branch out from Ubuntu (or a similar distro) and start diving into behind-the-scenes Linux, Arch is a good stepping stone.

Reply
a9k

The author\’s computers have spent a ton of time compiling to give us this report. Thanks.

So how did -Os beat all in some tests? I suspect two possible causes: one, cache hits in the intel chip would be higher with a smaller program; two, disk reading time is overwhelming the test time — so smaller programs appear slightly faster.

Might be interesting to re-run the encoder tests with everything in a ram disk.

Reply

add -march=native optimization flag and be impressed

Reply

    #TRUTH
    -O2 -march=native -mtune=native -mno-aes -mvzeroupper -pipe = Corei7-AVX or any new Xeon …

    extreme performance, sadly these benchmarks are not accurate as simply using “O2 -O3 -Os” does not leverage the capabilities of GCC.
    Besides that, you can if you read the GCC manual use in fact ANY GCC options besides the standard which are introduced in the newer versions. Of course use your discretion to test, however you can if you are looking for these optimizations (Gentoo documentation does not make this clear) edit /usr/portage/eclass/toolchain.eclass and /usr/portage/eclass/toolchain-binutils.eclass (for binutils)…

    Here you can edit linker build-id options, enable ESP/ESPF hardening, libssp, GO, graphite opts, advanced C++ compilation options (GCC 4.8.x) and the list goes on. Essentially, anything you can find here : http://gcc.gnu.org/install/configure.html and here: http://gcc.gnu.org/install is at your disposal.

    I write this as a 13-year Gentoo user, on a Corei7 3930K with SSD RAID arrays, 32GB DDR3 Quad-Channel ram on a Gentoo system compiled with GCC 4.8.2, latest svn-src binutils, and -O2 -march=native -mtune=native -mno-aes -mvzeroupper -pipe for C/CXXFLAGS (pretty conservative) and I dare say I’d put this machine up against any single-proc server or even dual proc….

    Reply

-Os, -O1, -O2, -O3, it’s only the basics.

You need to set -march=native and -mtune=native, and optionally -fomit-frame-pointer if arch is x86.

Reply

    -march overwrites -mtune also -fomit-frame-pointer is not supported by manny packages when reporting bugs

    Reply

      -march overwrites -mtune on most packages, -fomit-frame-pointer breaks debugging but can easily be circumvented by adding “FEATURES=”splitdebug” to /etc/make.conf to place debugging info in a seperate file (if you use Valgrind on Gentoo or any platform Glibc needs to be compiled with debugging symbols, emerge glibc with FEATURES=”splitdebug” and your entire system and you’ll eliminate the binary bloat but have the debug info still..)

      Reply

Kernel can take different CFLAGS as well, you need to edit the kernel makefile. Users of Gentoo are, and I say this in the nicest way possible, “usually” more advanced users than deb/RPM based distro users. Not always the case of course …

Reply

The year 2013 ending – the actual twelve-monthly adviser coloring “Emerald Silpada In . and we’ll point out farewell . Coloration expert Pantone (Pantone) organization straight away reported your 2014 once-a-year adviser shade ( space ) “Radiant Orchid Orchid Green ” ( Virtually no. 18-3224 ) , made from violet colors will become common shade inside 2014 . You continue program trends , it’s time to stockpile this!

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>