Results 1 to 9 of 9

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,419

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

    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

  2. #2
    Join Date
    Jul 2012
    Posts
    148

    Default

    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

  3. #3
    Join Date
    Aug 2012
    Posts
    40

    Default

    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.

  4. #4
    Join Date
    Jul 2013
    Posts
    1

    Default

    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

  5. #5
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,283

    Default

    Quote Originally Posted by hubicka View Post
    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)?

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,283

    Default

    Quote Originally Posted by curaga View Post
    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.

  7. #7
    Join Date
    Aug 2012
    Posts
    40

    Default

    Quote Originally Posted by curaga View Post
    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.

  8. #8
    Join Date
    Nov 2012
    Posts
    192

    Default

    Quote Originally Posted by Brane215 View Post
    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.

  9. #9
    Join Date
    Aug 2012
    Posts
    40

    Default

    Quote Originally Posted by carewolf View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •