16 ms·

From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in un

by melle 11y ago

From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. This seems quite a drastic change. I thought compilation speed was one of the pilars of go. In that light, why did they decide to release this anyway?

vruiz 11y ago
2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon. https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle
- melling 11y ago
  Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.
  - vruiz 11y ago
    The compilation time is slower, not the resulting compiled binary. > On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.
    - melling 11y ago
      I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.
      - vruiz 11y ago
        Meh, most people will never notice it, and if for someone is an issue, you can continue to develop using 1.4 locally until 1.6 comes in 6 months.
      - peterfirefly 11y ago
        There is a compilation-to-bytecode stage + lots of file look ups during start up of the Python interpreter and during every module import.
        zurn 11y ago
        Python caches the bytecode in .pyc files, so the compilation happens only the first time you import a module. In a typical Python start-up only the main source file is byte-compiled.
  - Twirrim 11y ago
    How often do you compile a code versus run it? Particularly in cases where speed matters?
    - melling 11y ago
      Why do you think projects like LightTable and Apple's Playgrounds exist? http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/ http://www.chris-granger.com/2012/02/26/connecting-to-your-c... http://www.objc.io/issues/16-swift/rapid-prototyping-in-swift-playgrounds/ http://www.objc.io/issues/16-swift/rapid-prototyping-in-swif... Rapid prototyping doesn't work as well if you need wait for compilation. JRebel exists for Java to improve redeployment times: http://zeroturnaround.com/software/jrebel/ http://zeroturnaround.com/software/jrebel/
    - tyho 11y ago
      You could argue lots of long running server software has been compiled more times through development than it has been started in prod.
bsdetector 11y ago
Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is. And it's not just the compiler, the linker didn't even know if a package is used or not, which is why you have to manually remove unused imports (otherwise they would be linked in, bloating the binary).
- zackbloom 11y ago
  This is the nature of a priority. They are saying they value compilation speed more than the maintainers of C might, and are willing to sacrifice other things (like runtime speed) in that interest.
- tyho 11y ago
  This is plain wrong, the main reason the compiler is fast according to the authors[1] is because it handles dependencies more sanely than C/C++. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
  - codemac 11y ago
    You're more than welcome to write C in the fashion that the go compiler enforces, and get much faster builds. Their compiler is young and immature relative to things like GCC and stating that it may be missing expensive optimization features is not "plain wrong".
    - tyho 11y ago
      That suggestion is not really practical as you need to make the same requirement from all your third party libraries. While gcc will spend more time optimizing than go, the main reason for the speed difference at the moment IS unnecessary work done by the preprocessor because of the primitive importing.
JulianMorrison 11y ago
They are porting to self-hosted in Go only. And they are willing to trade off compilation speed, temporarily, for getting there at all. Machine translated code will be full of low hanging fruit to get the old speed back.

by melle 11y ago

vruiz 11y ago

2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon. https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle

melling 11y ago
Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.
- vruiz 11y ago
  The compilation time is slower, not the resulting compiled binary. > On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.
  - melling 11y ago
    I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.
    - vruiz 11y ago
      Meh, most people will never notice it, and if for someone is an issue, you can continue to develop using 1.4 locally until 1.6 comes in 6 months.
    - peterfirefly 11y ago
      There is a compilation-to-bytecode stage + lots of file look ups during start up of the Python interpreter and during every module import.
      - zurn 11y ago
        Python caches the bytecode in .pyc files, so the compilation happens only the first time you import a module. In a typical Python start-up only the main source file is byte-compiled.
- Twirrim 11y ago
  How often do you compile a code versus run it? Particularly in cases where speed matters?
  - melling 11y ago
    Why do you think projects like LightTable and Apple's Playgrounds exist? http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/ http://www.chris-granger.com/2012/02/26/connecting-to-your-c... http://www.objc.io/issues/16-swift/rapid-prototyping-in-swift-playgrounds/ http://www.objc.io/issues/16-swift/rapid-prototyping-in-swif... Rapid prototyping doesn't work as well if you need wait for compilation. JRebel exists for Java to improve redeployment times: http://zeroturnaround.com/software/jrebel/ http://zeroturnaround.com/software/jrebel/
  - tyho 11y ago
    You could argue lots of long running server software has been compiled more times through development than it has been started in prod.

bsdetector 11y ago

Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is. And it's not just the compiler, the linker didn't even know if a package is used or not, which is why you have to manually remove unused imports (otherwise they would be linked in, bloating the binary).

zackbloom 11y ago
This is the nature of a priority. They are saying they value compilation speed more than the maintainers of C might, and are willing to sacrifice other things (like runtime speed) in that interest.
tyho 11y ago
This is plain wrong, the main reason the compiler is fast according to the authors[1] is because it handles dependencies more sanely than C/C++. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
- codemac 11y ago
  You're more than welcome to write C in the fashion that the go compiler enforces, and get much faster builds. Their compiler is young and immature relative to things like GCC and stating that it may be missing expensive optimization features is not "plain wrong".
  - tyho 11y ago
    That suggestion is not really practical as you need to make the same requirement from all your third party libraries. While gcc will spend more time optimizing than go, the main reason for the speed difference at the moment IS unnecessary work done by the preprocessor because of the primitive importing.

JulianMorrison 11y ago

They are porting to self-hosted in Go only. And they are willing to trade off compilation speed, temporarily, for getting there at all. Machine translated code will be full of low hanging fruit to get the old speed back.