Announcement

Collapse
No announcement yet.

LTO'ing Mesa Is Getting Discussed For Performance & Binary Size Reasons

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LTO'ing Mesa Is Getting Discussed For Performance & Binary Size Reasons

    Phoronix: LTO'ing Mesa Is Getting Discussed For Performance & Binary Size Reasons

    Enabling compiler Link-Time Optimizations (LTO) by default for Mesa in non-debug builds is being discussed in the name of performance and binary size...

    http://www.phoronix.com/scan.php?pag...a-LTO-May-2016

  • #2
    great idea
    Last edited by CochainComplex; 05-31-2016, 12:17 PM. Reason: edit

    Comment


    • #3
      LTO is always great. It' suprising how long it still takes to utilize all the compiler optimizations from the last 50 years in off-the-shelf compilers.

      Comment


      • #4
        I have tried compiling mesa with lto recently and didn't have any problems - except compilation takes a lot longer. And the worst of it is that for incremental builds, it takes that long every time it links mesa. Is there something gcc can do to cache lto optimizations? Or does it already do that and it's just a high chance that any of the stuff linked together has changed so it needs to relink everything?

        Comment


        • #5
          Originally posted by haagch View Post
          I have tried compiling mesa with lto recently and didn't have any problems - except compilation takes a lot longer. And the worst of it is that for incremental builds, it takes that long every time it links mesa. Is there something gcc can do to cache lto optimizations? Or does it already do that and it's just a high chance that any of the stuff linked together has changed so it needs to relink everything?
          Are you using -flto=$(nproc) ?

          Comment


          • #6
            Originally posted by caligula View Post
            LTO is always great. It' suprising how long it still takes to utilize all the compiler optimizations from the last 50 years in off-the-shelf compilers.
            I am hoping that somebody finally writes a C/C++ JIT compiler that needs to be passed the source code once and all subsequent optimizing recompilations are fully automatic.

            Comment


            • #7
              Originally posted by haagch View Post
              I have tried compiling mesa with lto recently and didn't have any problems - except compilation takes a lot longer. And the worst of it is that for incremental builds, it takes that long every time it links mesa. Is there something gcc can do to cache lto optimizations? Or does it already do that and it's just a high chance that any of the stuff linked together has changed so it needs to relink everything?
              It is called lto (link time optimization) for a reason. If you have to recompile that often disable it.

              Comment


              • #8
                Originally posted by atomsymbol View Post

                I am hoping that somebody finally writes a C/C++ JIT compiler that needs to be passed the source code once and all subsequent optimizing recompilations are fully automatic.
                Define "recompilations".

                With lto enabled gcc produces GIMPLE (intermediate language) object files, which are then compiled to binaries at link time.

                Comment


                • #9
                  Originally posted by log0 View Post
                  It is called lto (link time optimization) for a reason. If you have to recompile that often disable it.
                  In my opinion, in the case of small modifications to previously compiled files GCC is in general quite slow because it isn't automatically reusing results from its previous invocations. wikipedia.org/wiki/Memoization

                  Comment


                  • #10
                    Originally posted by log0 View Post
                    Define "recompilations".
                    For example: Conversion of position-independent code to fixed-position code when the JIT determines the code is used very often. The latter code is slightly faster than the former.

                    Comment

                    Working...
                    X