Results 1 to 10 of 18

Thread: GCC 4.7 Link-Time Optimization Performance

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,369

    Default GCC 4.7 Link-Time Optimization Performance

    Phoronix: GCC 4.7 Link-Time Optimization Performance

    With the recent interest regarding Link-Time Optimization support within the Linux kernel by GCC, here are some benchmarks of the latest stable release of GCC (v4.7.1) when benchmarking several common open-source projects with and without the performance-enhancing LTO compiler support.

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

  2. #2
    Join Date
    Jan 2008
    Location
    South Africa
    Posts
    228

    Default

    The GCC developers always mention building Firefox with LTO now uses less ram, etc.

    But, what differences are there with large and complicated software like Firefox?

  3. #3
    Join Date
    Jul 2009
    Posts
    221

    Default

    PHP takes three times as long to compile? Someone made a bad assumption there, or else something's wrong.

    But I thought the kernel generally had pretty low CPU usage anyway (I guess the BYTE benchmark being an exception). I'm unsure as to why big speed ups in general software usage would be expected from optimisations the compiler can do to the kernel.

  4. #4
    Join Date
    Feb 2012
    Posts
    70

    Default some PGO benchmarks

    Along with LTO, i am interested in seeing some PGO benchmarks.

  5. #5

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    Along with LTO, i am interested in seeing some PGO benchmarks.
    PGO is trickier. for any given app that you want to compile with PGO then you must write a script that runs the program with some representative task, in order to make a profile. If the profile tasks are not representative you may end up optimising the wrong paths.

  6. #6
    Join Date
    Aug 2011
    Posts
    27

    Default

    Quote Originally Posted by Cyborg16 View Post
    PHP takes three times as long to compile? Someone made a bad assumption there, or else something's wrong.

    But I thought the kernel generally had pretty low CPU usage anyway (I guess the BYTE benchmark being an exception). I'm unsure as to why big speed ups in general software usage would be expected from optimisations the compiler can do to the kernel.
    Where did you get the kernel stuff from? The test is about using -lto compile flag on application performance (and compile time).



    I wish the apache benchmark had more infomration. Although it may be good enough for relative performance gain it says very lilttle.
    On one of my machines I got from 5000req/s to 26000req/s on 6KB file by using different options like keepalive and concurrecncy level.

    Moreover there is lettle lto can do if apache uses dynamic modules. All the hooks and codepaths still need to be there in case a module needs them.
    It would be more interesting to benchmark apache compiled with static-modules option.

  7. #7
    Join Date
    Jul 2009
    Posts
    221

    Default

    Quote Originally Posted by orome View Post
    Where did you get the kernel stuff from? The test is about using -lto compile flag on application performance (and compile time).
    Ah. Speed-reading and noticing the first link in the article. Thanks for pointing out my mistake!

  8. #8
    Join Date
    Jan 2012
    Posts
    151

    Default

    I could be wrong, but...

    If you are going to be using LTO, I don't think you are suppose to care about how long it takes to compile. Of course it's going to take longer because you are optimizing the code on a global rather than local scale. If you use LTO, you are already saying you care more about the speed of the binary rather than how long it takes to compile. It is good to know the compile time hit that LTO takes, but I don't think it's really that relevant when using LTO. It is definitely a finished build option and not a debugging/develop option.

    I'd be very interested in how the binary size changes when using LTO. While there is more in-lining, there may be some dead-code drop and other GCC magic. Just curious if you can say: "when using LTO, the binary size will in general (in/de)crease".

  9. #9
    Join Date
    Aug 2012
    Posts
    39

    Default

    Quote Originally Posted by grigi View Post
    The GCC developers always mention building Firefox with LTO now uses less ram, etc.

    But, what differences are there with large and complicated software like Firefox?
    Firefox gets a lot smaller, not much smaller on common benchmarks it is hand optimized for. See
    http://arxiv.org/abs/1010.2196

  10. #10
    Join Date
    Aug 2012
    Posts
    39

    Default

    Quote Originally Posted by grigi View Post
    The GCC developers always mention building Firefox with LTO now uses less ram, etc.

    But, what differences are there with large and complicated software like Firefox?
    See http://arxiv.org/abs/1010.2196 . Firefox gets a lot smaller (it is easy to build -O3 binary with LTO that has size of -Os binary w/o LTO) and performance is pretty much the same on common benchmarks since they are hand optimized (and spend a lot of time in JIT optimized code). Things got better since 2010, but the overall picture is still similar.

    http://http://gcc.opensuse.org/ has some SPEC results with normal compilation, LTO and LTO+FDO. This gives you some more idea on what kind of speedups you can expect. LTO can be big hit when codebase is not really hand tuned or it is too complex to hand tune for all workloads. It is smaller performance hit for hand tuned programs (such as those in SPEC . This is not much of surprise though: most of optimizations enabled by LTO can be also done manually by the developers so you can think of LTO as a tool making development easier.

    Code size is harder to hand tune than speed, since you need to optimize whole program, not just hot spot. Consequently LTO is almost always big win for code size, unless you enable a lot of inlining or other code expanding optimizations.

Tags for this Thread

Posting Permissions

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