2 ms·
Is there any new reason to believe that? What I had seen--and which I would have thought would be obvious--is that the C++ module design only helps at lower lev
by saurik 4y ago
Is there any new reason to believe that? What I had seen--and which I would have thought would be obvious--is that the C++ module design only helps at lower levels of parallelism and actually slows down the build dramatically at the higher levels of parallelism used by people who actually care about build performance; this is apparently because the inherent design of modules causes the same kind of pervasive coupling seen with Rust, destroying the inherent scalability of the classic C++ separate compilation model.
https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://vector-of-bool.github.io/2019/01/27/modules-doa.html
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1441r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
> Expectedly, as hardware parallelism increases, headers’ lead over modules becomes more and more pronounced. There is also a relationship between the DAG-depth (i.e. The length of the chain of modules that import each other). As this depth increases, modules grow slower and slower, while headers remain fairly constant for even “extreme” depths approaching 300).
- pjmlp 4y agoOld outdated news. In C++23 it takes less time to import the whole standard library than a single major include like iostreams. Currently only available in VC++ preview, though.
- saurik 4y agoI totally believe that would be true for the standard library--code which itself has no dependencies, is always unchanged by the user, and could frankly come first in essentially any build--but... is that also true versus a precompiled header, which always seemed to work fine for the standard library? The entire concept behind modules for your code seemed like it would limit, not improve, scalability. Put differently: what changed?