4 ms·
Imagine you have 16 cores available. Allowing parallel compilation where it is sequential at the moment, you get 16 times speedup on such a machine. 32 cores ma
by acqq 6y ago
Imagine you have 16 cores available. Allowing parallel compilation where it is sequential at the moment, you get 16 times speedup on such a machine. 32 cores machine -- 32 times speedup etc. Or even 10 such machines -- 320 times speedup.
On the other side, imagine you can even reduce the "ton of IR" tenfold but if the compilation is sequential, the tenfold speedup is fixed even if you have 32 or 320 cores.
In general, allowing for parallel compilation is much more important topic, and it's worth even redesigning language to make that more achievable.
Which also doesn't mean that producing "ton of IR" is a good thing. But working on allowing maximum parallelism is more fundamental. Also, discovering algorithms to allow all compiler passes as effective as possible is important for something to reach wider usability. But Rust must also get to achieve its promises of being "safer" in the scenarios where C is otherwise used, and I time and again see a lot of "unsafe" keywords in the sources wherever I see some implementation of anything fundamental.
- rayiner 6y agoExcept Amdahl’s law.
- dllthomas 6y agoModulo the necessarily sequential (as mentioned by rayiner), you are correct in terms of absolute speed achievable. But you achieve that speedup at a roughly linear increase in $$$ cost. When you have idle cores sitting around, maybe it was opportunity cost you were already paying, but that's bounded. On the other hand, reductions in the amount of computation needed mean you get a faster build for the same resources, or a similar speed build for cheaper. Depending on your circumstances, one of these things (speed vs. cost) might be much more important than the other. We cannot forget about either.