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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Bringing Faster Exceptions to Rust

103 点作者 stpn7 个月前

5 条评论

weinzierl7 个月前
Great analysis of unwinding overhead in Rust. The framing of exceptions as &quot;alternate returns&quot; is enlightening - they <i>should</i> be cheap in theory, which makes the current ~2.3μs overhead particularly interesting to dissect. The optimization journey from removing unnecessary type erasure to using thread-locals is well explained. While the 4.3x speedup is impressive, I think the bigger takeaway isn&#x27;t about replacing Result with panics, but rather identifying where non-local control flow genuinely makes sense. Looking forward to the deep dive into unwinder implementations.
评论 #42078863 未加载
Joker_vD7 个月前
Well, unwinding can be as simple (and as fast) as<p><pre><code> MOV SP, [installed_handler] JMP [installed_handler+WORD] </code></pre> but it only works if you don&#x27;t need to run the defers&#x2F;Drop&#x27;s&#x2F;destructors&#x2F;etc. for stuff that&#x27;s on the stack between the current frame and the handler&#x27;s frame. Which you do, most of the time.
评论 #42075396 未加载
评论 #42075362 未加载
lesuorac7 个月前
This isn&#x27;t benchmarked against returning a Result right?<p>Like wouldn&#x27;t bypassing any unwinding be faster than improving unwinding. You already seem to have control over the code as the thrown and caught exception have to be the same so might as well just write the code as a `Result&lt;T, Exception&gt;` in the first place no?
评论 #42076803 未加载
codeflo7 个月前
&gt; Returning to an alternate address shouldn’t be significantly more expensive than returning to the default address, so this has to be cheap.<p>Modern CPUs add complications to arguments like this. Branches stall the execution pipeline, so branch prediction was invented to keep the pipeline flowing. Return instructions are <i>perfectly</i> predicted, which makes them literally free. At the very least, any alternate return scheme has to pay for a full misprediction. That can be expensive.
评论 #42074899 未加载
评论 #42087983 未加载
评论 #42075564 未加载
mmaniac7 个月前
The most interesting part of this article for me is at the beginning.<p>&gt; Now imagine that calls could specify alternate return points, letting the callee decide the statement to return to:<p><pre><code> &#x2F;&#x2F; Dreamed-up syntax fn f() { g() alternate |x| { dbg!(x); &#x2F;&#x2F; x = 123 }; } fn g() -&gt; () alternate i32 { return_alternate 123; } </code></pre> This sort of nonlocal control flow immediately calls to mind an implementation in terms of continuation passing style, where the return point is given as a function which is tail called. Nonlocal returns and multiple returns are easy to implement in this style.<p>Does there exist a language where some function<p><pre><code> fn foo() -&gt; T throws U </code></pre> is syntactic sugar for something more like?<p><pre><code> fn foo(ifOk: fn(T) -&gt; !, ifExcept: fn(U) -&gt; !) -&gt; !</code></pre>
评论 #42081846 未加载
评论 #42078319 未加载