9 ms·

So... not been closely following development on Go. What does this mean?

fintler 11y ago
Just a guess: it's probably static single assignment for the IR. https://www.cs.cmu.edu/~fp/courses/15411-f08/lectures/09-ssa.pdf https://www.cs.cmu.edu/~fp/courses/15411-f08/lectures/09-ssa...
- iofj 11y ago
  It appears it's a new way to do code generation. So any adding of new architectures is dead in the water until this is resolved. https://groups.google.com/forum/#!topic/golang-dev/zz-gWGXFZr4 https://groups.google.com/forum/#!topic/golang-dev/zz-gWGXFZ...
  - enneff 11y ago
    Actually, the opposite. The merging of the branch means that people are now free to continue work on adding new architectures.
    - mattetti 11y ago
      Did the compiler get even slower on tip? I know that was a concern with this change
      - grey-area 11y ago
        10% slower, which isn't too bad, let's hope they can now focus on improving compilation speed, I miss go 1.4 having recently upgraded. It would be really nice to see that actually improve for 1.7 instead of regressing.
  - zamalek 11y ago
    SSA, once you understand it, is easier to work with than almost all other forms of instruction sets. I'd argue that it would only accelerate new architecture in the long-run. I'm interested in why LLVM was disqualified. Was it simply never considered or is it incompatible with the Go type system, calling convention, etc.?
    - vruiz 11y ago
      > I'm interested in why LLVM was disqualified. They simply used what they knew best: > If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two. > Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly I'd probably have left the project years ago. https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
      - enneff 11y ago
        Even today we can still re-build the entire tool chain and standard library in one minute on a modest machine. If we were using LLVM...
    - tinco 11y ago
      It's rather easy to add a calling convention to LLVM. If I would have to guess it would be that they thought LLVM was too slow for them. They said from the start compilation speed was a big point for them. Also LLVM requires you to either write your IR in SSA or add another expensive optimisation pass to make it SSA (mem2reg). Perhaps they thought writing an SSA generator would be too much of a headache.
      - witty_username 11y ago
        The LLVM docs say that clang uses mem2reg for mutable local variables, so it can't be very slow. From the end of http://llvm.org/docs/tutorial/LangImpl7.html#memory-in-llvm http://llvm.org/docs/tutorial/LangImpl7.html#memory-in-llvm > Proven and well tested: clang uses this technique for local mutable variables. As such, the most common clients of LLVM are using this to handle a bulk of their variables. You can be sure that bugs are found fast and fixed early.
    - alexanderstocko 11y ago
      In addition to what others said, support for precise garbage collection in LLVM was not ideal at the time. The experimental gc statepoint extension spearheaded by the Azul guys is trying to change that. They've been working on it publicly since late 2014.
vastbinderj 11y ago
It is the new backend for the Go Compiler See: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0 https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...
- gansai 11y ago
  So, currently Stage1 is complete. 2 more to go
  - tux1968 11y ago
    From the referenced doc: I’m not entirely convinced that stages 2 & 3 are necessary, maybe we stop at stage 1. It all depends on what optimizations we’d like to do that can’t be done because the IR is in the wrong form. Proceeding with stages 2 and 3 might gain some efficiency in the compiler itself because then we don’t have to generate the old IR at all. I suspect that effect will be small, however.
gillianseed 11y ago
Improved optimizations which will also be easier to implement, with the result being faster and also typically smaller code.
- rurban 11y ago
  And typically longer compile times. Most variables are split into ("phi") variants, for each assignment, and many more costly optimization steps are now possible.
  - gillianseed 11y ago
    True, an increase in optimizations will likely mean longer compile times, on the other hand, with better optimized code, the compiler itself (as it's written in Go) will also perform better, which may negate some of the increase in compile time.
    - jlouis 11y ago
      One of the alluring things of SSA form is that many optimizations are much faster to execute on the form. The costly part is to raise the SSA form in the first place which in the standard implementation requires one to build a costly dominator tree. You don't need to add every optimization known to man to a compiler, so you can sometimes keep a few of the important ones and then skip every other optimization. A priori, I'd guess SSA would speed up the compiler, which means you end up having a better budget for the more expensive optimizations.
      - UniQP 11y ago
        As stated in [1] they use a variant of "Simple and Efficient Construction of Static Single Assignment Form" [2], which does not require a dominator tree (or a liveness analysis). [1] https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/ssa.go#L3473 https://github.com/golang/go/blob/master/src/cmd/compile/int... [2] http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun1...

Just a guess: it's probably static single assignment for the IR. https://www.cs.cmu.edu/~fp/courses/15411-f08/lectures/09-ssa.pdf https://www.cs.cmu.edu/~fp/courses/15411-f08/lectures/09-ssa...

iofj 11y ago
It appears it's a new way to do code generation. So any adding of new architectures is dead in the water until this is resolved. https://groups.google.com/forum/#!topic/golang-dev/zz-gWGXFZr4 https://groups.google.com/forum/#!topic/golang-dev/zz-gWGXFZ...
- enneff 11y ago
  Actually, the opposite. The merging of the branch means that people are now free to continue work on adding new architectures.
  - mattetti 11y ago
    Did the compiler get even slower on tip? I know that was a concern with this change
    - grey-area 11y ago
      10% slower, which isn't too bad, let's hope they can now focus on improving compilation speed, I miss go 1.4 having recently upgraded. It would be really nice to see that actually improve for 1.7 instead of regressing.
- zamalek 11y ago
  SSA, once you understand it, is easier to work with than almost all other forms of instruction sets. I'd argue that it would only accelerate new architecture in the long-run. I'm interested in why LLVM was disqualified. Was it simply never considered or is it incompatible with the Go type system, calling convention, etc.?
  - vruiz 11y ago
    > I'm interested in why LLVM was disqualified. They simply used what they knew best: > If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two. > Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly I'd probably have left the project years ago. https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
    - enneff 11y ago
      Even today we can still re-build the entire tool chain and standard library in one minute on a modest machine. If we were using LLVM...
  - tinco 11y ago
    It's rather easy to add a calling convention to LLVM. If I would have to guess it would be that they thought LLVM was too slow for them. They said from the start compilation speed was a big point for them. Also LLVM requires you to either write your IR in SSA or add another expensive optimisation pass to make it SSA (mem2reg). Perhaps they thought writing an SSA generator would be too much of a headache.
    - witty_username 11y ago
      The LLVM docs say that clang uses mem2reg for mutable local variables, so it can't be very slow. From the end of http://llvm.org/docs/tutorial/LangImpl7.html#memory-in-llvm http://llvm.org/docs/tutorial/LangImpl7.html#memory-in-llvm > Proven and well tested: clang uses this technique for local mutable variables. As such, the most common clients of LLVM are using this to handle a bulk of their variables. You can be sure that bugs are found fast and fixed early.
  - alexanderstocko 11y ago
    In addition to what others said, support for precise garbage collection in LLVM was not ideal at the time. The experimental gc statepoint extension spearheaded by the Azul guys is trying to change that. They've been working on it publicly since late 2014.

vastbinderj 11y ago

It is the new backend for the Go Compiler See: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0 https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...

gansai 11y ago
So, currently Stage1 is complete. 2 more to go
- tux1968 11y ago
  From the referenced doc: I’m not entirely convinced that stages 2 & 3 are necessary, maybe we stop at stage 1. It all depends on what optimizations we’d like to do that can’t be done because the IR is in the wrong form. Proceeding with stages 2 and 3 might gain some efficiency in the compiler itself because then we don’t have to generate the old IR at all. I suspect that effect will be small, however.

gillianseed 11y ago

Improved optimizations which will also be easier to implement, with the result being faster and also typically smaller code.

rurban 11y ago
And typically longer compile times. Most variables are split into ("phi") variants, for each assignment, and many more costly optimization steps are now possible.
- gillianseed 11y ago
  True, an increase in optimizations will likely mean longer compile times, on the other hand, with better optimized code, the compiler itself (as it's written in Go) will also perform better, which may negate some of the increase in compile time.
  - jlouis 11y ago
    One of the alluring things of SSA form is that many optimizations are much faster to execute on the form. The costly part is to raise the SSA form in the first place which in the standard implementation requires one to build a costly dominator tree. You don't need to add every optimization known to man to a compiler, so you can sometimes keep a few of the important ones and then skip every other optimization. A priori, I'd guess SSA would speed up the compiler, which means you end up having a better budget for the more expensive optimizations.
    - UniQP 11y ago
      As stated in [1] they use a variant of "Simple and Efficient Construction of Static Single Assignment Form" [2], which does not require a dominator tree (or a liveness analysis). [1] https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/ssa.go#L3473 https://github.com/golang/go/blob/master/src/cmd/compile/int... [2] http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun1...