Most C/C++ projects require parallel make because they lack modules. I work on medium-large projects in C++, for which we use Boost as well as about a hundred custom middleware components. A "simple" source file of ~1000 lines ends up generating a preprocessed file in the order of between 100,000 lines and 1,000,000 lines. Each and every TU. This is what makes them so amenable to parallelization.
On the other hand, for languages with modules, a ~1000 lines file is a ~1000 lines file; it may depend on ~50 various other modules, but those need not be reparsed each time (a serialized version of the produced AST/ABT can be generated once and for all) and they can also be cached by the compiler (which unlike typical C compilers processes several modules in one pass). As such, there is much less gain here. On the other hand, I do agree with your command, it could possibly be better (temporarily) to run LLVM to cleanup each and every module before combining them into a single crate for optimization; however I feel that in the long term this will be useless once codegen itself is reviewed so that first and foremost a leaner IR is emitted that do not require so much cleanup to start with. -- Matthieu On Fri, Aug 23, 2013 at 10:16 PM, Bill Myers <bill_my...@outlook.com> wrote: > > - We essentially always do whole-program / link-time optimization > > in C++ terminology. That is, we run a whole crate through LLVM at > > once. Which _would_ be ok (I think!) if we weren't generating > > quite so much code. It is an AOT/runtime trade but one we > > consciously designed-in to the language. > > > time: 33.939 s LLVM passes > > Maybe this should be changed to optionally do codegen and LLVM passes in > parallel, producing an LLVM or native module for each Rust file, and then > linking the modules together into the compiled crate. > > Alternatively, there seems to be some work on running LLVM FunctionPasses > in parallel at > http://llvm.1065342.n5.nabble.com/LLVM-Dev-Discussion-Function-based-parallel-LLVM-backend-code-generation-td59384.htmlbut > it doesn't seem production-ready. > > Most large C/C++ projects rely on parallel make and distcc to have > reasonable build times, and it seems something that Rust needs to support > (either via make/distcc or internally) to be a viable replacement for large > projects. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
