GCC 4.8.2 vs. GCC 4.9.0 Benchmarks On Intel's Core i7 Haswell

[phoronix]

Phoronix: GCC 4.8.2 vs. GCC 4.9.0 Benchmarks On Intel's Core i7 Haswell

With GCC 4.9 likely being released in the next few weeks, here are some benchmarks comparing the GCC 4.8.2 stable release against the latest GCC 4.9 snapshot...

http://www.phoronix.com/vr.php?view=MTY0Nzg

[Brane215]

Meh, like usual. A few slight improvements on a synthetic test, with other results all over the place.

Significant info would be how well is -flto optimisation performing and how many bugs were killed there.

For start, here is a rough list of packages that I just couldn't compile with

CFLAGS="-march=native -O3 -flto -pipe"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,-flto -Wl,--as-needed"

on any gcc, up to 4.8.2

So try to compile with -flto basic libraries etc stuff ( glibc, elfutils etc etc) and then try to do the same with:

libcmis aspell sysvinit gawk coreutils hdparm shadow sandbox audacious-plugins mesa libcdr libpostproc alsa-lib flac libvisio fltk clang
llvm db gpm sudo dialog ffmpeg libav mplayer vlc mplayer2 cups-filters upower e2fsprogs libburn libdaemon elfutils boost spidermonkey
perl erlang python ruby wavpack git cvs libreoffice xorg-server nfs-utils linphone sane-backends imagemagick rawstudio inkscape qtcore qtdbus
qtxmlpatterns qtsvg qt3support qtscript qtsql qtgui qemu brltty

[hubicka]

There was significant amount of work put into LTO support. 4.9 will switch from fat to slim object files, so things won't get compile twice. LTO builds are now faster than non-LTO for many pakcages (not all, it depends on how heavily the package uses static libraries linked into many DSOs). Firefox build now fits bellow 3GB of RAM. Oerall a lot of focus is now put into making large applications to load&run fast. I will try to get some benchmarks done next month.

[Szpadel]

A typo in article:

"While there wasn't much change to see over GCC 4.9.2 for these benchmarks on the latest-generation Intel platform with Ubuntu Linux"
it should be GCC 4.8.2

[curaga]

There was significant amount of work put into LTO support. 4.9 will switch from fat to slim object files, so things won't get compile twice.

Is that merely a default switch change, or does it completely remove support for fat objects (ie, support for non-gold linker)?

[curaga]

Is that merely a default switch change, or does it completely remove support for fat objects (ie, support for non-gold linker)?

It's merely a default switch, and even seems to be automagicly detected depending on one's linker. Great.

[hubicka]

It's merely a default switch, and even seems to be automagicly detected depending on one's linker. Great.

Yep, it is a change of default value of -ffat-lto-objects switch along with number of changes to make this work well. I am now building openoffice/firefox/chromium with LTO and regularly test mainline GCC while Richard Biener made quite a progress on building a distribution with LTO.

Note that glibc won't safely build with LTO, because it implements the runtime that may be autogenerated by compiler. LTOing these is not supported yet (libgcc, libgomp, glibc are main libraries you can't LTO for this, but also you should not get too much benefits from doing so). Getting other packages to build with LTO should be easier now. You need to convince it to use gcc-nm/gcc-ld/gcc-ar wrappers to handle linker plugin (I do that by my own wrappers called nm/ld/ar earlier on the search path) and make sure you get right optimization flags at link-time. You also need reasonably up-to-date libtool. Some of configure scripts needs fixing since they rely on compiler not being able to do cross-module optimization.

[carewolf]

Meh, like usual. A few slight improvements on a synthetic test, with other results all over the place.

Significant info would be how well is -flto optimisation performing and how many bugs were killed there.

For start, here is a rough list of packages that I just couldn't compile with

CFLAGS="-march=native -O3 -flto -pipe"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,-flto -Wl,--as-needed"

Unless your remove the -O1 and add -O3 to the LDFLAGS that will give you terrible performance. Remember all the optimizations with lto happens at linktime, so you need to pass march=native and -O3 at linktime, anything that happens at "compile" time only affect non-lto linking.

[hubicka]

Unless your remove the -O1 and add -O3 to the LDFLAGS that will give you terrible performance. Remember all the optimizations with lto happens at linktime, so you need to pass march=native and -O3 at linktime, anything that happens at "compile" time only affect non-lto linking.

Actually GCC does "early optimizations" that happen at compile time. So both compile time and link time optimization flags are relevant. This is done to reduce the link-time overhead. Unless I am mistaken, Clang/LLVM does optimization twice; once at compile time and once again at link-time.