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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Tail Call Improvements in .NET Framework 4

50 点作者 budu大约 15 年前

4 条评论

CWuestefeld大约 15 年前
<i>on x64 you should see shorter call stacks in optimized code because the JIT generated more tail calls (don’t worry this optimization is turned off for debug code)</i><p>I think it used to be that there was little perf difference between DEBUG and RELEASE builds, so for simplicity, with internal apps we always just build to DEBUG.<p>The above quote suggests that these days, they really are doing worthwhile optimizations in RELEASE builds. Does anybody know more about that?
评论 #1179331 未加载
rubyrescue大约 15 年前
<i>However the stack space is ‘recycled’ such that if you have a tail recursive algorithm, the first tail call that isn’t ‘easy’ will erect the TailCallHelper stack frame, and subsequent non-easy tail calls may need to grow that frame to accommodate all the arguments. Hopefully once the algorithm has gone through a full cycle of recursion the TailCallHelper stack frame has grown to the maximum sized needed by all the non-easy calls involved in the recursion, and then never grows, and thus prevents a stack overflow.</i><p>- does this mean that it's possible to use TailCallHelper but still not be able to guarantee no stack overflow?
评论 #1179230 未加载
评论 #1179263 未加载
评论 #1179454 未加载
trezor大约 15 年前
If I'm reading this correctly this only applies to the .NET 4 runtime and not the old .NET 2.0 runtime (also powering .NET 3.0 and 3.5 solutions).<p>In that case I guess if you are running tail-recursion heavy algorithms on x64, just recompiling the same old code for the .NET 4 runtime should yield runtime improvements.<p>Would be interesting if someone had any actual measurements for this.
评论 #1179564 未加载
topbanana大约 15 年前
Filed under: BetIWontNoticeAnyDifference