[cfe-dev] yet another question about modules

[mobi phil]

>
> I'm not sure what you're trying to investigate here. You've forced the
> majority of the compile time to be used while processing the .cpp file
> rather than its includes, so modules is not going to help you much
> here.
>

What I try to investigate: if there is a way to fool the modules cache to
cache template instantiation. I understand that the modules system is about
taking the ast of the headers and saving it to a file. During compilation
of a unit the compiler glues that AST to the ast of the compilation unit.
Again intuitively if I have template instantiation in the cache, that
should be just "glued". For me if I have a

map8 a1;
map8 a2;
.....
.....

one hundreds of times, compilation should be almost equally fast as i would
have only once, and should be equally fast if the instantiation is found in
the modules cache.

But, whatoever hard I try to cache both libcxx and my header, no
improvement. The cache is created, I can walk through the ast inside the
cache, but no speedup.

For instance I created a simple header:
#include <string>
#include <map>

using namespace std;

typedef map<string, string> mymap0;
typedef map<mymap0, mymap0> mymap1;
typedef map<mymap1, mymap1> mymap2;
typedef map<mymap2, mymap2> mymap3;
typedef map<mymap3, mymap3> mymap4;
typedef map<mymap4, mymap4> mymap5;
typedef map<mymap5, mymap5> mymap6;
typedef map<mymap6, mymap6> mymap7;
typedef map<mymap7, mymap7> mymap8;

mymap0 m0;
mymap1 m1;
mymap2 m2;
mymap3 m3;
mymap4 m4;
mymap5 m5;
mymap6 m6;
~





BTW: is there any other trick to force instantiation, without generating
any text?


and the module.map:

  module g2 {
    header "g2.h"
    export *
  }

cat g2.cpp

#include "g2.h"

int main() {
mymap5 m0;
mymap5 n0;
m0=n0;
mymap5 m1;
mymap5 n1;
......
}

tried different variations with different typems mymap etc..



> > for "one level" instantiation, without modules, clang seems to be a
> little
> > faster than gcc, but for i > 3. With modules compilation is much longer.
>
> Including or excluding the one-time cost of building the module for
> your standard library? I'm seeing a speedup in this testcase by
> enabling modules (with an appropriately-modularized standard library);
> the proportion speedup decreases as i increases, as expected, since
> more of the time is outside the headers.
>
are you talking about libcxx or standard C? Copied also the system headers
into a separate directory and created the module file. I have also the
modules map file for libcxx and I see the cache created for it. Building
the cache I agree shall take time, but once the cache is built, for me even
subsequent compilations take longer than without the modules system.

What does your test case contain?


> This is more interesting. I'd imagine that GCC is avoiding some of the
> exponential-time costs here; in particular, its overload resolution
> short-circuits template argument deduction if it gets an exact match
> from a non-template candidate, and that's probably happening in the
> map assignments.
>

Well, I am afraid once people stretch a bit the dimensions of templates,
might be bit disappointed.

>
> No; modules is intended to reduce the costs of including headers. It
> does not reduce costs associated with template instantiations that are
> performed locally to your .cpp file. (If you instantiated map0, map1,
> and so on in a header, then it would help.)
>

That is what I tried, but does not seem to work.


> In principle, we could extend the modules system with a template
> instantiation repository to cache the results of instantiating
> templates from modules, but I don't think anyone is working on, or
> planning, such a system for Clang at the moment.
>

bit pity... from my experience, it was rather the template instantiation
that was causing long build times and not the preprocessing.





rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150123/f9e4cd67/attachment.html>