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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

CPU registers and OCaml

117 点作者 dodders将近 10 年前

8 条评论

pcwalton将近 10 年前
I talked with Chris Lattner a few years ago about register allocation and he had an interesting perspective. In his view (from what I remember; my recollection could be somewhat incorrect) most of the classical academic research on it is solving the wrong problem. Most formulations of register allocation are graph coloring algorithms designed to answer the question &quot;is this function colorable using K registers without spilling?&quot; The algorithms for handling the case when you <i>do</i> spill usually don&#x27;t have as much thought put into them. But this is emphasizing the wrong aspect of the problem in practice; for almost any interesting function on the commonly used architectures (x86&#x2F;ARM), the answer to the theoretical question is trivially &quot;no&quot; (because there are relatively few registers), and the most important practical problem is how to spill effectively (including deciding whether to spill versus split versus rematerialize, etc.) As I understand it, that&#x27;s the idea behind LLVM&#x27;s (relatively) new greedy allocator [1]: the graph-coloring part of the problem is simple, and the focus is on spilling and splitting, problems that the classical academic literature has tended to put less emphasis on.<p>[1]: <a href="http:&#x2F;&#x2F;blog.llvm.org&#x2F;2011&#x2F;09&#x2F;greedy-register-allocation-in-llvm-30.html" rel="nofollow">http:&#x2F;&#x2F;blog.llvm.org&#x2F;2011&#x2F;09&#x2F;greedy-register-allocation-in-l...</a>
评论 #9754055 未加载
评论 #9755843 未加载
评论 #9755071 未加载
DannyBee将近 10 年前
&quot;If the code has more than that many variables, OCaml compiler has to park the extra variables in memory and this parking is called spilling.&quot;<p>This is just wrong. It would be accurate to say &quot;If the code has more than that number of variables live at the same time&quot;.<p>If the computations are not live at the same time, they can share a register.
gct将近 10 年前
The notion that there&#x27;s only 13&#x2F;16 registers (assuming x86) hasn&#x27;t been true for a long time. There&#x27;s hundreds in the latest cores from Intel. It&#x27;s true there&#x27;s only 13&#x2F;16 names for them, but with register renaming there&#x27;s way more places to actually put data than that.
评论 #9754549 未加载
tempodox将近 10 年前
Those are interesting observations. When doing something like `let rec loop ...`, I got into the habit of using parameters for only those entities that might change from one iteration to the next. The rest (as being constant &#x2F; invariant across iterations) dwells in the closure env, if only for the sake of making the source code shorter. The article shows nicely how this obvious mental shortcut has its (equally obvious) costs.<p>It&#x27;s also a nice practical demonstration of how reading disassemblies is still an integral part of understanding a language, even this relatively abstract ML descendant.
cosmicexplorer将近 10 年前
Why wouldn&#x27;t the OCaml compiler optimize away the variable usage in the first example? It seems an easy optimization to make if they&#x27;re only used once.
评论 #9753964 未加载
lispm将近 10 年前
There is &lt;&gt; missing in line 3 of the first code snippet.
a-dub将近 10 年前
Does OCaml generate code that makes use of SIMD?
froh42将近 10 年前
Use a better algorithm instead of worrying about processor registers.<p>And if you start considering the computer architecture think about caches, memory latency and bursting first. Use a cache-conscious data structure.<p>Optimizing at the register level is ridiculous, this is the least place where you get significant returns for the effort you spend.<p>Oh, and make it correct first, make it fast second. Use a profiler.
评论 #9754024 未加载