> Online, this number varies widely. The most exaggerated figure I recall is a 26x improvement in project compilation speed after a module-based refactoring.
> Furthermore, if a project uses extensive template metaprogramming and stores constexpr variable values in Modules, the compilation speed can easily increase by thousands of times, though we generally do not discuss such cases.
> Apart from these more extreme claims, most reports on C++20 Modules compilation speed improvements are between 10% and 50%.
I'd like to see references to those claims and experiments, size of the codebase etc. I find it hard to believe the figures since the bottleneck in large codebases is not a compute, e.g. headers preprocessing, but it's a memory bandwidth.
source? language? what exactly does memory bandwidth have to do with compilation times in your example?
NUMA (non-unifrom memory access - basically give each CPU a serpate bank of RAM, and if you need something that is in the other bank of RAM you need to ask the other CPU) exists because of this. I don't have access to a NUMA to see how they compare. My understanding (which could be wrong) is OS designers are still trying to figure out how to use them well, and they are not expected to do well for all problems.
Edit: I think I misunderstood what you meant by memory bandwidth at first? Modules reduce the amount of work being done by the compiler in parsing and interpreting C++ code (think constexpr). Even if your compilation infrastructure is constrained by RAM access, modules replace a compute+RAM heavy part with a trivial amount of loading a module into compiler memory so it's a win.
SSD bandwidth: 4-10GB/s RAM bandwidth: 5-10x that, say 40GB/s.
If compute was not a bottleneck, the entire linux kernel should compile in less than 1 second.
So why does it take minutes to compile?
Compilation is entirely compute bound, the inputs and outputs are minuscule data sizes, in the order of megabytes for typical projects - maybe gigabytes for multi million line projects, but that is still only a second or two from an SSD.
Of course the above is specific to the machines I did my testing on. A different machine may have other differences from my setup. Still my experience matches the claim: at 40 cores memory bandwidth is the bottleneck not CPU speed.
Most people don't have 40+ core machines to play with, and so will not see those results. The machines I tested on cost > $10,000 so most would argue that is not affordable.
I’m not claiming anything about it being I/O or compute bound, but you are missing some sources of I/O:
- the compiler reads many source files (e.g. headers) multiple times
- the compiler writes and then reads lots of intermediate data
- the OS may have to swap out memory
Also, there may be resource contention that makes the system do neither I/O nor compute for part of the build.
clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm
clang++ -std=c++20 use.cpp -fmodule-file=Hello=Hello.pcm Hello.pcm -o Hello.out
./Hello.out
I'm used to:
g++ -o hello hello.cpp
I recommend skimming over this issue from Meson:
https://github.com/mesonbuild/meson/issues/5024
Reading the last few blog posts from a developer of Meson, providing some insights why Meson doesn't support modules until now:
I'm eager to gather info but the weak spots of headers (and macros) are obvious. Probably holding a waiting position for undefined time. At least as long Meson doesn't support them.
Wikipedia contains false info about toolings: https://en.wikipedia.org/wiki/Modules_(C%2B%2B)#Tooling_supp...
Meson doesn't support modules as of 2025-09-11.
PS: I'm into new stuff when it looks stable and the benefits are obvious. But this looks complicated and backing out of complicated stuff is painful, when necessary.
That is simple, because C++ inherited C's simplistic, primitive, and unsafe compilation and abstraction model of brute-force textual inclusion. When you scale this to a large project with hundreds of thousands of translation units, every command-line invocation becomes a huge list of flag soup that plain Makefiles become inscrutably complicated.
Every other reasonably-recent programming language and ecosystem that isn't a direct superset of C has some description of a directed acyclic graph of dependencies, whether it be requirements.txt, cargo.toml, Maven, dotnet and Nuget .csproj files, Go modules, OPAM, PowerShell gallery, and more.
C++20 modules are a very good thing. There are two problems with it: we didn't have a working and correct compiler implementation before the paper was accepted into C++20, and secondly, the built/binary module interface specification is not fixed, so BMIs aren't (yet) portable across compilers.
The Meson developer is notorious for stirring the pot with respect to both the build system competition, and C++20 modules. The Reddit thread on his latest blog post provides a searing criticism for why he is badly mistaken: https://www.reddit.com/r/cpp/comments/1n53mpl/we_need_to_ser...
triknomeister•2h ago
People keep saying this and yet I do not know of a good example from a real life project which did this which I can test. This seems very much still an experimental thing.
Kelteseth•1h ago
> C++ 26 reflections have now been voted in. This would get rid of moc entirely, but I really do not see how this will become widely available in the next 5-10 Years+. This would require Qt to move to C++ 26, but only if compiler support is complete for all 3 compilers AND older Linux distros that ship these compilers. For example, MSVC still has no native C++ 23 flag (In CMake does get internally altered to C++ latest aka. C++ 26) , because they told me that they will only enable it is considered 100% stable. So I guess we need to add modules support into moc now, waiting another 10 years is not an option for me .
pjmlp•55m ago
https://github.com/pjmlp/RaytracingWeekend-CPP
Also shows how to use static libraries alongside modules.
wild_pointer•44m ago
> can haz real life project?
> sure, here's X in a Weekend
pjmlp•41m ago
bluGill•32m ago
There are still some features that are missing from compilers, but enough is there that you can target all 3 major compilers and still get most of modules and benefit from them. However if you do this remember you are an early adopter and you need to be prepared to figure out the right way to do things - including fixing things that you get wrong once you figure out what is right.
Also, if you are writing a library you cannot benefit from modules unless you are willing to force all your consumers to adopt modules. This is not reasonable for major libraries used by many so they will be waiting until more projects adopt modules.
Still modules need early adopters and they show great promise. If you write C++ you should spend a little time playing with them in your current project even if you can't commit anything.
juliangmp•19m ago
A while ago I made a small example to test how it would work in an actual project and that uses cmake (https://codeberg.org/JulianGmp/cpp-modules-cmake-example). And while it works™, you can't use any compiler provided modules or header modules. Which means that 1) so you'll need includes for anything from the standard library, no import std 2) you'll also need includes for any third party library you want to use
When I started a new project recently I was considering going with modules, but in the end I chose against it because I dont want to mix modules and includes in one project.