Re: So.... what are we going to do about modules?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2022-04-05 15:24:40

On 05/04/2022 15:37, René Ferdinand Rivera Morell wrote:

>     To be specific here, what are the gains of Modules over Precompiled
>     Headers, which Boost.Build already supports?
> 
>     Niall's fairly confident answer: little to none, and perhaps even a
>     regression as ODR resolution is time expensive.
> 
> 
> It depends :-) Assuming that you smartly organize and engineer your 
> modules they will end up with shorter compile performance for certain 
> compile contexts. I think that's sufficiently qualified ;-) ... The real 
> answer is that precompiled headers need to reparse the entire TU context 
> at any change in that TU context. While modules isolate the reparse to 
> the "headers" specific to the modules. Hence if properly used there will 
> be less reparsing with modules. But it's definitely not trivial or 
> straightforward to implement that proper module structure.

You're right that Modules could and should do that optimisation. But I 
believe that none of the current three major implementations do do that 
optimisation i.e. they're no more efficient than their own precompiled 
header implementation, which has received many years of optimisation. 
Just to be clear, I'm saying that some precompiled headers 
implementations pre-instantiate final templates etc, and for those 
compilers whose precompiled headers don't do that then neither does 
their Modules implementation (yet).

Re: ODR resolution stage, you're right that that is highly dependent on 
how much ODR needs resolving. However I remember talking to somebody in 
a WG21 meeting where they were telling me that their final binary 
production times rose by about 20% with Modules. They reckoned it was 
because in their TUs they reuse the same names for non-extern types but 
with different definitions, and it is O(N^2) or worse complexity for the 
compiler to resolve those. They apparently can't enable LTO either, 
because link times go through the roof.

Future Modules implementations will become better if and only if enough 
people adopt Modules and report performance pathologies. Me personally, 
I suspect anybody who cares deeply about build times will probably stick 
with whatever techniques they currently are using, as the gain from 
adopting Modules over those techniques is currently not great for most 
codebases.

I'd like to hope WG21 will propose a Modules v2 in years to come which 
improves the cost benefit proposition.

Niall