3 ms·
Not the OP here, but AFAIK LLVM has been struggling with parallelizing compilation of independent functions due to some shared global context that ideally would
by tom_mellior 6y ago
Not the OP here, but AFAIK LLVM has been struggling with parallelizing compilation of independent functions due to some shared global context that ideally wouldn't be there. A full rewrite would allow a redesign of this part in a more concurrency-friendly way. So it's conceivable that a concurrency-oriented rewrite would bring nice speedups in wall time, not total CPU time. And Rust might give some more guarantees that there really aren't any hidden shared corners.
- gizmondo 6y agoGiven that parallelizing rustc is also kinda struggling, it seems unfair to think that C++ is necessarily the culprit in LLVM case.
- est31 6y agoIn Firefox there've been two failed attempts to make css styling parallel while using C++. Only the parallel rust rewrite, stylo, succeeded. Rust doesn't replace careful planning of parallel infrastructure or performance optimization, but it makes it possible to maintain the parallel system.
- CyberDildonics 6y agoRust isn't going to make fast, lock free, shared memory data structures magically appear.
- ninkendo 6y agoI’m already running make in -j8 and running multiple invocations of clang in parallel, why would I want each one of them using up 800% CPU? Effort spent making a single invocation of clang saturate all my CPU cores is misguided IMO, and the wrong place to be doing parallelization.
- brandmeyer 6y agoWhole-program optimization at link time (cooperating with the Make jobserver protocol, preferably).