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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

How to speed up the Rust compiler

185 点作者 nnethercote超过 8 年前

5 条评论

keyle超过 8 年前
I&#x27;ve never used rust but seeing it&#x27;s so oriented towards correctness and type checking, I&#x27;m not surprised it&#x27;s a little slow to compile!<p>From someone stuck with dynamic languages, mark my words, it&#x27;s best for your compiler to be a bit slow, than your brain being the compiler! :-)
评论 #12707090 未加载
评论 #12706718 未加载
评论 #12706948 未加载
评论 #12706756 未加载
nickpsecurity超过 8 年前
I still think they should investigate doing the LISP solution to the problem where you combine several options:<p>1. Interpreter (eg REPL) that executes it instantly with dynamic checks for rapid prototyping of logic.<p>2. Fast, non-optimizing compile that at least does the safety checks.<p>3. Fully-optimizing compile that can be done in background or overnight while programmer works on other things like tests or documentation.<p>4. Incremental, per-function version of 2 or 3 for added boost. Rust is already adding something like that.<p>This combo maximizes mental flow of programmer, lets them tinker around with algorithms, quickly produces executables for test deployments, and will often do full compiles without interrupting flow with wait times. It&#x27;s the workflow available in a good LISP. It doesn&#x27;t have to be exclusive to LISP. Other languages should copy it. I&#x27;ll go further to say they should even design the language and compiler to make it easy to pull that off.
评论 #12711103 未加载
评论 #12710496 未加载
acqq超过 8 年前
As far as I know, the Rust compiler is written in Rust? That should mean that if the features of the language are used, a lot of &quot;small&quot; allocations shouldn&#x27;t happen at all, instead, the language is supposed to allow that the short lived variables (and objects) exist only on the stack, costing effectively nothing to allocate them?<p>Moreover, the compilers in general have an advantage to know that most of the objects are needed only during specific times, allowing optimized allocation and bundled deallocation. I see &quot;a lot&quot; of &quot;arena&quot; allocators are mentioned, so it seems there is something like that, just maybe too fine grained?<p>In short, there&#x27;s no need for the Rust compiler to have any measurable overhead due to the allocations.<p>Then only the changes in the compiling algorithms and the underlying data structures (how often is what traversed and why, is something kept or recalculated, sometimes it&#x27;s even more expensive to produce too much data to be kept in memory, and sometimes the data structures aren&#x27;t optimal for the most of the uses) should have the potential of changing the compilation speed.
评论 #12707563 未加载
pjmlp超过 8 年前
In conclusion, allocating memory is expensive, regardless how it is done. :)
评论 #12707349 未加载
评论 #12706964 未加载
评论 #12706887 未加载
评论 #12709959 未加载
eridius超过 8 年前
&gt; <i>malloc and free are still the two hottest functions in most benchmarks. Avoiding heap allocations can be a win.</i><p>This is a non-sequitur. If you see a hot function in a profile, that is an indication that you should optimize that function if you can. But it does not mean that you should try to reduce calls to that function elsewhere (unless you can cut out a lot in one go). As a trivial example, if you have a super-fast function that cannot be optimized any further, but it&#x27;s called millions of times, that function may appear hot, but any individual invocation of the function might be taking just a few microseconds. Getting rid of a handful of calls to this function (or even a few hundred) isn&#x27;t going to make an appreciable difference. Of course, if you can cut the number of calls in half, then that would be good.<p>I guess another way of saying this is, if you&#x27;re trying to optimize a hot function by reducing the number of times it&#x27;s called, you need to reduce it by a significant percentage of the total calls rather than reducing it by a specific number of times. No matter how many times it&#x27;s called, if you reduce the number of calls by 50%, the overall time taken by the function drops by 50%. But if you reduce the number of calls by 50, then whether that&#x27;s meaningful or not depends entirely on how long each individual call to the function takes.<p>Edit: Why am I being downvoted for this? I&#x27;m speaking a factually correct statement. It&#x27;s not like this is some sort of controversial opinion. If I&#x27;m wrong, please tell me why.
评论 #12710935 未加载
评论 #12711139 未加载