Announcement

Collapse
No announcement yet.

Go 1.7 Is Trading Much Slower Compile Times For Better Generated Code

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

  • Go 1.7 Is Trading Much Slower Compile Times For Better Generated Code

    Phoronix: Go 1.7 Is Trading Much Slower Compiler Times For Better Generated Code

    Go developers are warning that with the upcoming Go 1.7 release the compiler could be as much as two times slower, but will yield better quality -- and hopefully faster -- generated code...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wonder if this new generated code will produce smaller binaries? always a plus on embedded devices

    Comment


    • #3
      Originally posted by boxie View Post
      I wonder if this new generated code will produce smaller binaries? always a plus on embedded devices
      Most likely yes, but only by a small amount. Instructions make up a pretty small amount of a typical binary.

      Comment


      • #4
        Exactly the opposite of Rust compiler, started slow and sped up and the last couple of releases

        Comment


        • #5
          Go 1.4 used to compile so fast. I'm a bit sad at all this slowing down. On the other hand, the new garbage collector and the race detector in 1.5 is pretty great.

          Comment


          • #6
            Personally I think compile time traded for run time and efficiency is a good trade off. However, many developers I know have looked at GWT and decided otherwise.

            Comment


            • #7
              It's only a good thing if there are 2 compile modes:
              1) slow & super optimized
              2) super fast & not optimized

              If there's only one mode, they obviously need to find the holy grail in between, so that devs don't have to wait for too long and the performance is still okay.

              Comment


              • #8
                Originally posted by boxie View Post
                I wonder if this new generated code will produce smaller binaries? always a plus on embedded devices

                You can get pretty small binaries by using gcc-go instead of the standard gc compiler for x86_64. You can also pass -O optimizations too it.
                With -O3 the code can be many times faster somtimes.

                Comment


                • #9
                  Originally posted by VanCoding View Post
                  It's only a good thing if there are 2 compile modes:
                  1) slow & super optimized
                  2) super fast & not optimized

                  If there's only one mode, they obviously need to find the holy grail in between, so that devs don't have to wait for too long and the performance is still okay.

                  I had the same thought, but dismissed it because:
                  1) different compile modes means different bugs can appear at different optimisation levels. 1 single compile mode means less chance of things tripping you up
                  2) goes against Go's Simplicity
                  3) Most things do not need to be recompiled every time you compile (at least in my experience)

                  Comment


                  • #10
                    Though the article mentions this, people seem to be missing the fact that 1.7 is early, and the changes were about improvements that ignored speed optimization. The developer quoted said he hopes to gain most of the speed back before release. This isn't news about 1.7 but rather news about a particular build in a very early stage (before release of the previous version), so it doesn't yet have a lot of relevance. This build is trading compiler time for better code. Go is not. Go might, but that's far off still.

                    Comment

                    Working...
                    X