TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Mid-stack inlining in the Go compiler

241 点作者 dcu大约 8 年前

11 条评论

throwawayish大约 8 年前
In case someone else is wondering: What is being called "mid-stack inlining" here is what is generally understood by the term "inlining".
评论 #13804039 未加载
zamalek大约 8 年前
This is absolutely fantastic work.<p>Since I&#x27;ve learned about continuation passing style (which Go channels could <i>probably</i> be formally transformed into), I&#x27;ve been convinced that there&#x27;s a better way to do codegen. Better calling convention, better stack representation, better instruction architecture; I&#x27;m not yet sure - it&#x27;s a nag continuously at the back of my mind, almost as though it&#x27;s at the tip of my tongue. In this specific case, it must <i>surely</i> be possible to inline a continuation with some foreign architecture. I&#x27;d <i>love</i> to see some literature on the more experimental end of this stuff, if anyone has it.
评论 #13804716 未加载
评论 #13806787 未加载
sheeshkebab大约 8 年前
Jvm&#x2F;java had that for a while in its JIT - it&#x27;s nice to see it to coming to Golang.<p>Byproduct of that could be little hacky things like this below that make code faster by restructuring code a little<p><a href="https:&#x2F;&#x2F;techblug.wordpress.com&#x2F;2013&#x2F;08&#x2F;19&#x2F;java-jit-compiler-inlining&#x2F;" rel="nofollow">https:&#x2F;&#x2F;techblug.wordpress.com&#x2F;2013&#x2F;08&#x2F;19&#x2F;java-jit-compiler-...</a>
chillydawg大约 8 年前
9% faster, 15% bigger. I&#x27;ll take that!
评论 #13805035 未加载
评论 #13806014 未加载
micah_chatt大约 8 年前
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?
评论 #13804963 未加载
YesThatTom2大约 8 年前
The presentation redacted the stats about how this affects Google performance. I bet it saves enough CPU hours to pay the author&#x27;s salary many many many times over. Good job!
评论 #13804176 未加载
ainar-g大约 8 年前
Whoah, nine percent? That&#x27;s a lot! Now I wonder if the improvement better or worse on non-x86 platforms?
评论 #13805013 未加载
dap大约 8 年前
This is interesting work!<p>That said, it&#x27;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&#x27;t rely on runtime support for help.
评论 #13804813 未加载
评论 #13804754 未加载
snovv_crash大约 8 年前
It looks like most of the improvements are in string formatting problems. I&#x27;m curious if better heuristics will help other areas as well.
cetinsert大约 8 年前
As someone who now professionally uses go on a range of mips devices, I, for one, do care about any binary size increases!
spullara大约 8 年前
It doesnt look like this solves inlining library calls?
评论 #13804853 未加载
评论 #13804221 未加载