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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Source Code Optimization (2009) [pdf]

20 点作者 dodders超过 10 年前

1 comment

nkurz超过 10 年前
I like that this article shows the generated assembly for the same source with different compilers, and the same compiler with different optimization levels. Even with C programmers, there&#x27;s a discouraging trend of treating the compiler&#x27;s decisions as unimpeachable. Occasionally it does a great job, but if you make a habit of looking at generated code you will quickly realize it&#x27;s anything but ideal.<p>What this article implies, but doesn&#x27;t really concentrate on, is that while one can write portable code that will produce correct results when compiled with different compilers, it&#x27;s very difficult to write code that will have portable performance. A code construct that produces a 100% speedup with one compiler might just as well yield a 50% slowdown on another.<p>Even in C, optimizing code is largely an act of faith. One way around this, which I&#x27;m surprised is not more used, is to &quot;lock the code down&quot; to assembly after it is written. This doesn&#x27;t mean you have to actually write anything in assembly. Rather, after you finally manage to get a compiler to produce the level of performance you want for the function that most impacts performance, you can extract the generated assembly and paste it into file, leaving your C code for portability to different processors. Given the stable x64 assembly ABI, you can usually even mix and match between compilers --- try several, and copy the code generated by the one that does best.<p>While this obviously won&#x27;t work for different instruction sets, it works quite well for different generations of processors. CPU makers are properly concerned about making their new chips faster than the old, and thus do a fairly good job of avoiding regressions in performance. While there might be a faster method for the new chip, it&#x27;s not that common find that the new chip executes identical code substantially slower. I&#x27;d usually rather bet on this than on assuming that future generations of the compiler will keep the same magic combination of instructions for the old chip while simultaneously generating new magic for the new chip.
评论 #8398362 未加载
评论 #8399165 未加载