Mid-stack inlining in the Go compiler
docs.google.com
Mid-stack inlining in the Go compiler
1–10 of 76 posts
Re: Mid-stack inlining in the Go compiler
#2Whoah, nine percent? That's a lot! Now I wonder if the improvement better or worse on non-x86 platforms?
Re: Mid-stack inlining in the Go compiler
#39% faster, 15% bigger. I'll take that!
Re: Mid-stack inlining in the Go compiler
#4Would they get this for free if the go compiler was just a llvm frontend?
Re: Mid-stack inlining in the Go compiler
#5Jvm/java had that for a while in its JIT - it's nice to see it to coming to Golang.
Byproduct of that could be little hacky things like this below that make code faster by restructuring code a little
https://techblug.wordpress.com/2013/08/19/java-jit-compiler-...
Re: Mid-stack inlining in the Go compiler
#6In case someone else is wondering: What is being called "mid-stack inlining" here is what is generally understood by the term "inlining".
Re: Mid-stack inlining in the Go compiler
#7What 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?
Re: Mid-stack inlining in the Go compiler
#8It doesnt look like this solves inlining library calls?
Re: Mid-stack inlining in the Go compiler
#9In case someone else is wondering: What is being called "mid-stack inlining" here is what is generally understood by the term "inlining".
The presentation makes a distinction between mid-stack and leaf inlining, and apparently it was only done on leaf calls before because this is less confusing in backtraces.
Re: Mid-stack inlining in the Go compiler
#10The presentation redacted the stats about how this affects Google performance. I bet it saves enough CPU hours to pay the author's salary many many many times over. Good job!