TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Exploiting Undefined Behavior in C/C++ Programs: The Performance Impact [pdf]

97 pointsby luu27 days ago

7 comments

pcwalton24 days ago
I notice that the paper doesn&#x27;t claim to eliminate <i>all</i> reasoning about undefined behavior for optimizations. For example:<p><pre><code> int f() { int arr[3], i = 0; arr[3] = 5; return i; } </code></pre> Optimizing this to &quot;return 0&quot; is relying on UB, because it&#x27;s assuming that i wasn&#x27;t laid out directly after arr in the stack frame. I believe this is what the paper calls &quot;non-guardable UB&quot;.<p>I don&#x27;t agree with the claim in the paper that their semantics offers a &quot;flat memory model&quot;. A flat memory model would rule out the optimization above. Rather, the memory model still has the notion of object bounds; it&#x27;s just simplified in some ways.
评论 #43797059 未加载
评论 #43797614 未加载
评论 #43796814 未加载
jonstewart24 days ago
&gt; The results show that, in the cases we evaluated, the performance gains from exploiting UB are minimal. Furthermore, in the cases where performance regresses, it can often be recovered by either small to moderate changes to the compiler or by using link-time optimizations.<p>_THANK YOU._
评论 #43796359 未加载
评论 #43798569 未加载
评论 #43794903 未加载
nikic24 days ago
One peculiar thing about the benchmark results is that disabling individual UB seems to fairly consistently reduce performance without LTO, but improve it with LTO. I could see how the UB may be less useful with LTO, but it&#x27;s not obvious to me why reducing UB would actually help LTO. As far as I can tell, the paper does not attempt to explain this effect.<p>Another interesting thing is that there is clearly synergy between different UB. For the LTO results, disabling each individual UB seems to be either neutral or an improvement, but if you disable all of them at once, then you get a significant regression.
mwkaufma24 days ago
Reading e.g. the 13% perf regression in simdjson from disabling UB:<p><pre><code> A simpler alternative is to compile the program with LTO. We confirmed that LLVM’s inter-procedural analyses can propagate both alignment and dereferenceability information for this function, which allows the LTO build to recover the performance loss. </code></pre> &quot;can&quot; is doing a lot of heavy-lifting here. Guaranteeing expected optimizations &quot;will&quot; be applied are hard-enough, without leaving it entirely to an easily-derailed indirect side-effect.
评论 #43796294 未加载
评论 #43797876 未加载
hnaccountme21 days ago
You don&#x27;t program C. You program your OS using C.<p>If you look at it this way, does most complaints about undefined behavior go away?
gitroom24 days ago
perfect, this is right up my alley - honestly i keep wondering if teams avoid optimizations like lto just because build pain sucks or if theres some deeper trust issues around letting the toolchain be clever. you think peopled deal with slow builds if it bought way more speed for the final product?
imtringued22 days ago
Amazing that the pain of C is unnecessary and offers few benefits.
评论 #43812029 未加载