Re:Rust – Faster compilation with the parallel front-end in ...
by rayiner on Friday November 10, 2023 @12:36PM
(#38221816)
The front end is time-consuming enough where replacing the backend with something lightweight like Go’s wouldn’t get you a 5-10x improvement, which is what I think you’d need to really move the needle on user perception. Moreover, a lot of the backend slowdown is due to front end choices monomophization which generates large amounts of intermediate code that must then be optimized away.
[ Parent
| on HN ]
Re:Rust – Faster compilation with the parallel front-end in ...
by pcwalton on Friday November 10, 2023 @04:44PM
(#38224941)
I doubt that a hypothetical version of Rust that avoided monomorphization would compile any faster. I remember doing experiments to that effect in the early days and found that monomorphization wasn't really slower. That's because all the runtime bookkeeping necessary to operate on value types generically adds up to a ton of code that has to be optimized away, and it ends up a wash in the end. As a point of comparison, Swift does all this bookkeeping, and it's not appreciably faster to compile than Rust; Swift goes this route for ABI stability reasons, not for compiler performance.
What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics).
Re:Rust – Faster compilation with the parallel front-end in ...
by mirashii on Saturday November 11, 2023 @01:01AM
(#38227976)
Just wanted to note Go does only a partial monomorphization, only monomorhpizes for gcshapes and not for all types. This severely limits the optimization potential and adds a runtime cost to dispatch, at least in its initial implementation.
https://github.com/golang/proposal/blob/master/design/generi...