21–30 of 76 posts
It doesnt look like this solves inlining library calls?
Go statically links to all Go libraries, and only dynamically links when interfacing with C code. (As of the last time I used it, a couple years ago; this may have changed since then.)
This is interesting work! That said, it's a little disappointing when runtimes require custom algorithms or metadata to walk the stack and construct a stack trace. It makes it harder to build debuggers that grok the state of multiple runtimes (e.g., the Go code and the C code in the same program). This also affects runtime tracing tools like DTrace, which by construction can't rely on runtime support for help.
This is interesting work! That said, it's a little disappointing when runtimes require custom algorithms or metadata to walk the stack and construct a stack trace. It makes it harder to build debuggers that grok the state of multiple runtimes (e.g., the Go code and the C code in the same program). This also affects runtime tracing tools like DTrace, which by construction can't rely on runtime support for help.
It doesnt look like this solves inlining library calls?
What impact would that have on build times? I know a lot of work has gone into getting back to 1.4 build times, but would the added work of inlining prolong builds?
https://github.com/golang/go/issues/19386
Those numbers are just for my CLs that fix stack traces but with mid-stack inlining still off. Turning it on makes builds noticeably slower:
$ time ./make.bash
real: 45.32s user: 118.67s cpu: 5.85s
$ time GO_GCFLAGS='-l=4' ./make.bash
real: 64.51s user: 167.04s cpu: 7.12s
Whoah, nine percent? That's a lot! Now I wonder if the improvement better or worse on non-x86 platforms?
9% faster, 15% bigger. I'll take that!
You should be able to get about 15-20% with about 3-5% binary increase size.
In fact, with ThinLTO, we often see that gain with binary size decrease from smart inlining choices.
(The heuristics for inlining take a very very long time to get right and tune)
The issue they will next hit is that inlining is going to make the compiler slower until they tune the heuristics well.
What impact would that have on build times? I know a lot of work has gone into getting back to 1.4 build times, but would the added work of inlining prolong builds?
The compiler got a bit slower: https://github.com/golang/go/issues/19386 Those numbers are just for my CLs that fix stack traces but with mid-stack inlining still off. Turning it on makes builds noticeably slower: $ time ./make.bash real: 45.32s user: 118.67s cpu: 5.85s $ time GO_GCFLAGS='-l=4' ./make.bash real: 64.51s user: 167.04s cpu: 7.12s We'll need to tweak the inlining heuristic to find a good balance between…
This is absolutely fantastic work. Since I've learned about continuation passing style (which Go channels could probably be formally transformed into), I've been convinced that there's a better way to do codegen. Better calling convention, better stack representation, better instruction architecture; I'm not yet sure - it's a nag continuously at the back of my mind, almost as though it's at the tip of my tongue. In t…
Are you aware of "Compiling with Continuations? https://www.amazon.com/Compiling-Continuations-Andrew-W-Appe...
More recently though I heard someone proved mathematically that CPS can be transformed one-for-one into one of the more conventional models. That doesn't mean it might not still be easier for the humans to deal with however.