←back to thread

Converting a large mathematical software package written in C++ to C++20 modules

(arxiv.org)
141 points vblanco | 2 comments | 01 Jul 25 13:46 UTC | HN request time: 0.397s | source
Show context
barchar ◴[02 Jul 25 00:37 UTC] No.44439255[source]▶
A few points

1) modules only really help address time spent parsing stuff, not time spent doing codegen. Actually they can negatively impact codegen performance because they can make more definitions available for inlining/global opts, even in non-lto builds. For this reason it's likely best to compare using thin-lto in both cases.

2) when your dependencies aren't yet modularized you tend to get pretty big global module fragments, inflating both the size of your BMIs and the parsing time. Header units are supposed to partially address this but right now they are not supported in any build systems properly (except perhaps msbuild?). Also clang is pretty bad at pruning the global module fragment of unused data, which makes this worse again.

replies(1): >>44440057 #
1. boris ◴[02 Jul 25 03:38 UTC] No.44440057[source]▶
> Header units are supposed to partially address this but right now they are not supported in any build systems properly (except perhaps msbuild?).

They are supported in build2 when used with GCC (via the module mapper mechanism it offers). In fact, I would be surprised if they were supported by msbuild, provided by "properly" we mean without having to manually specify dependencies involving header units and without imposing non-standard limitations (like inability to use macros exported by header units to conditionally import other header units).

replies(1): >>44441411 #
2. pjmlp ◴[02 Jul 25 08:46 UTC] No.44441411[source]▶
VC++ has support header units for quite some time, in fact I had to revert back to global module fragments, because CMake/clang still don't have a plan for how to support header units, and I wanted to have my demo code work in more than just VC++.