4 ms·

My understanding is just the opposite, they will decrease compilation times as "included files" are processed just once. We can see them as a better version of

My understanding is just the opposite, they will decrease compilation times as "included files" are processed just once. We can see them as a better version of precompiled headers (although they are more than that).

Kranar 5y ago
Yes except that includes are usually not the performance bottleneck, it's the semantic analysis that consumes the bulk of the compile times. Modules inhibit parallelism because modules are ordered along a DAG and must be compiled from the root of the DAG down to the leafs in order. So consider a traditional setup as follows: A.cpp <- A.h <- B.h <- C.h <- D.h B.cpp <- B.h <- C.h <- D.h C.cpp <- C.h <- D.h D.cpp <- D.h All four of those cpp files can be built in parallel, even though you're right that all of the header files are being reparsed multiple times. My claim is that parsing header files is incredibly cheap, it's translating the .cpp files that's expensive because cpp files are where the bulk of the semantic analysis and type checking is performed. With modules, the same compilation model looks like this: A.mxx <- B.mxx <- C.mxx <- D.mxx There's no longer header/source and there's no longer redundancy, but I can't build this in parallel anymore. I have to first build D.mxx, then C.mxx, then B.mxx then A.mxx in serial.
- deleted 5y ago
  [deleted]
- dbaupp 5y ago
  Parsing a single header file in isolation is cheap, but each header will include others, and templates mean many headers contain large amounts of code inline. For instance, just including <vector> results in the compiler having to look at almost 30kloc, on my system: $ clang -x c++ -E - <<<"#include <vector>" | wc -l 27378 Other headers are similar: algorithm 23103 array 23450 memory 15909 random 52107 thread 31424 tuple 9240 (Of course, a bunch of this code is shared, e.g. including both thread and vector is “only” 35713 loc total, not 60kloc.) I believe C++ compilers have SIMD-accelerated lexers/parsers because of the sheer explosion of code due to headers and templates.

Kranar 5y ago

Yes except that includes are usually not the performance bottleneck, it's the semantic analysis that consumes the bulk of the compile times. Modules inhibit parallelism because modules are ordered along a DAG and must be compiled from the root of the DAG down to the leafs in order. So consider a traditional setup as follows: A.cpp <- A.h <- B.h <- C.h <- D.h B.cpp <- B.h <- C.h <- D.h C.cpp <- C.h <- D.h D.cpp <- D.h All four of those cpp files can be built in parallel, even though you're right that all of the header files are being reparsed multiple times. My claim is that parsing header files is incredibly cheap, it's translating the .cpp files that's expensive because cpp files are where the bulk of the semantic analysis and type checking is performed. With modules, the same compilation model looks like this: A.mxx <- B.mxx <- C.mxx <- D.mxx There's no longer header/source and there's no longer redundancy, but I can't build this in parallel anymore. I have to first build D.mxx, then C.mxx, then B.mxx then A.mxx in serial.

deleted 5y ago
[deleted]
dbaupp 5y ago
Parsing a single header file in isolation is cheap, but each header will include others, and templates mean many headers contain large amounts of code inline. For instance, just including <vector> results in the compiler having to look at almost 30kloc, on my system: $ clang -x c++ -E - <<<"#include <vector>" | wc -l 27378 Other headers are similar: algorithm 23103 array 23450 memory 15909 random 52107 thread 31424 tuple 9240 (Of course, a bunch of this code is shared, e.g. including both thread and vector is “only” 35713 loc total, not 60kloc.) I believe C++ compilers have SIMD-accelerated lexers/parsers because of the sheer explosion of code due to headers and templates.