Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Link-Time Optimizing Improved, But Still Takes A While On GCC 4.9

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

    Default Link-Time Optimizing Improved, But Still Takes A While On GCC 4.9

    Phoronix: Link-Time Optimizing Improved, But Still Takes A While On GCC 4.9

    The GCC 4.9 compiler that's about to be released has many improvements, including in the area of LTO (Link-Time Optimizations), but you must still have a fair amount of patience to compile with LTO support...

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

  2. #2
    Join Date
    Jun 2012
    Posts
    18

    Default

    It would be interesting to compare compiles of Firefox, Chromium, Libreoffice, and Perl, including their memory usage.

  3. #3
    Join Date
    Jan 2013
    Location
    Sweden
    Posts
    6

    Default

    You should also pass -fno-fat-lto-objects to GCC to make sure that LTO is used all the way. You generally want to use -fuse-linker-plugin too.

  4. #4
    Join Date
    Aug 2012
    Posts
    39

    Default

    GCC 4.9 now defaults to -fno-fat-lto-files when plugin enabled linker is available. This should be visible in the benchmarks by about halving the LTO compile time. Also w/o plugin the LTO performance improvements are much smaller than with.

    Michael, can you, please, repeat the benchmarks with plugin support?

  5. #5
    Join Date
    Aug 2012
    Posts
    39

    Default

    Also forgot to add, if you use parallel make (-j=N), you probably also want to pass -flto=n to parallelize the LTO build process.

  6. #6
    Join Date
    Aug 2012
    Posts
    39

    Default

    Quote Originally Posted by STrRedWolf View Post
    It would be interesting to compare compiles of Firefox, Chromium, Libreoffice, and Perl, including their memory usage.
    I am slowly working on this, the first three are hard to benchmarks. Perl is an interesting candidate indeed.
    So far I tested firefox at Dromaeo (that is rather poor benchmark for compiler generated code by spending a lot of time either in JIT generated code or tight string manipulation loops). Still the benefits are measurable http://dromaeo.com/?id=219677,219672,219877

    It compares normal build, LTO build and LTO profiledbuild. So 7% for LTO and 14% for LTO+PDO (I repreated the tests to check it is off noise)

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

    hubicka, will we see the icf/semantic function/duplicate function removal in gcc 4.10?

  8. #8

    Default

    Quote Originally Posted by hubicka View Post
    I am slowly working on this, the first three are hard to benchmarks. Perl is an interesting candidate indeed.
    So far I tested firefox at Dromaeo (that is rather poor benchmark for compiler generated code by spending a lot of time either in JIT generated code or tight string manipulation loops). Still the benefits are measurable http://dromaeo.com/?id=219677,219672,219877

    It compares normal build, LTO build and LTO profiledbuild. So 7% for LTO and 14% for LTO+PDO (I repreated the tests to check it is off noise)
    Can the Kernel be profiled? I think that is where it could gain some speed.

  9. #9
    Join Date
    Aug 2012
    Posts
    39

    Default

    Quote Originally Posted by toyotabedzrock View Post
    Can the Kernel be profiled? I think that is where it could gain some speed.
    Kernel needs custom profiling runtime (libgcov). Google is definitely using it and they recently submitted patches to make GCC's libgcov bit more modular. I did not try it myself though. http://ltp.sourceforge.net/archive/o...-kernel.readme seems to have some docs.

  10. #10
    Join Date
    Aug 2012
    Posts
    39

    Default

    Quote Originally Posted by curaga View Post
    hubicka, will we see the icf/semantic function/duplicate function removal in gcc 4.10?
    Most probably. The patch needs review, but that is scheduler for early stage 1. (Among quite few other changes related to LTO).

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
  •