Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go in Go

talks.golang.org

Post reply on HN
Print view View original

31–40 of 156 posts

Re: Go in Go

#31

Post by Spiritus »

andrewchambers wrote: post #12

I am most excited for the new SSA backend in go. I have been following commits to it here: https://github.com/golang/go/tree/dev.ssa No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.

SSA?

Re: Go in Go

#32

Post by bgaluszka »

andrewchambers wrote: post #12

I am most excited for the new SSA backend in go. I have been following commits to it here: https://github.com/golang/go/tree/dev.ssa No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.

Just for those who are wondering what SSA is: https://en.wikipedia.org/wiki/Static_single_assignment_form

Re: Go in Go

#33

Post by imslavko »

andrewchambers wrote: post #29
bla2 wrote: post #22

"How to sell a rewrite of your compiler that made it slower"

This is a fair criticism presented in a poor way. Hopefully the performance will improve with the new dev.ssa branch eventually. I will note that go programs still seem to build orders of magnitude faster than C++ programs, even after this change.

Can you please explain what dev.ssa branch is implementing and how is it going to change the performance of the compiler?

Re: Go in Go

#34

Post by imslavko »

andrewchambers wrote: post #29
bla2 wrote: post #22

"How to sell a rewrite of your compiler that made it slower"

This is a fair criticism presented in a poor way. Hopefully the performance will improve with the new dev.ssa branch eventually. I will note that go programs still seem to build orders of magnitude faster than C++ programs, even after this change.

Can you please explain what dev.ssa branch is implementing and how is it going to change the performance of the compiler?

Re: Go in Go

#35

Post by narsil »

It would be nice to see benchmarking stats to gauge the significance of the performance problems mentioned in the slides. For users, I'd imagine the ease of developing the Go language is less important than its performance.

Re: Go in Go

#36

Post by andrewchambers »

Spiritus wrote: post #31
andrewchambers wrote: post #12

I am most excited for the new SSA backend in go. I have been following commits to it here: https://github.com/golang/go/tree/dev.ssa No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.

SSA?

Internal graph representation the compiler uses for programs. llvm uses SSA form of programs as its main low level representation. The benefits of SSA is that it enables some analysis and optimization techniques.

Re: Go in Go

#37

Post by andrewchambers »

imslavko wrote: post #33
andrewchambers wrote: post #29

Earlier quoted context omitted.

This is a fair criticism presented in a poor way. Hopefully the performance will improve with the new dev.ssa branch eventually. I will note that go programs still seem to build orders of magnitude faster than C++ programs, even after this change.

Can you please explain what dev.ssa branch is implementing and how is it going to change the performance of the compiler?

It is a program representation that a few modern compiler optimization techniques rely on. It just mean there is potential for the compiler to emit better assembly code.

Because the compiler is now written in Go, compiler optimization will affect how fast programs compile.

The compiler may speed up or slow down because it is doing more advanced code analysis, but is generating better assembly. I do not know if this will cancel itself out or not.

Re: Go in Go

#38

Post by seanmcdirmid »

andrewchambers wrote: post #36
Spiritus wrote: post #31

Earlier quoted context omitted.

SSA?

Internal graph representation the compiler uses for programs. llvm uses SSA form of programs as its main low level representation. The benefits of SSA is that it enables some analysis and optimization techniques.

It is basically a simplification that makes optimizations easier by eliminating re-assignment of local variables (where possible, for loops and conditions, merging phi values might be necessary). It has been awhile since I played with this, but it made CSE (common sub-expression elimination) really easy.

Re: Go in Go

#39

Post by scscsc »

bottled_poe wrote: post #30

Can we trust the go compiler? edit: This is the link I meant - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

i.e. can a bug that existed early in the toolchain history propagate in the binaries but not the sources?

c_i is the i'th version of the compiler.

    c1 c2 // c1 compiles c2

    c2 c3 // c2 compiles c3
Source code of c1 has bug, source code of c2 and c3 is fixed. Bug in c1 causes binary of c2 to have bug. Binary bug in c2 causes binary bug in c3.
Post reply on HN