[Dune-devel] Explicit template instantiation

Simon Praetorius simon.praetorius at tu-dresden.de
Tue Feb 16 16:34:42 CET 2021


Hi Community,

Recently, I have experimented with explicit template instantiation of 
some grid types leading to a reasonable speedup of compile processes. In 
a few applications I have compile times for a single target > 5min on a 
decent machine and was wondering how to to reduce that time.

In summary: explicit template instantiation is a way to enforce an 
instantiation of a template in a translation unit and to prevent from 
implicit instantiations of that same template.

See: https://en.cppreference.com/w/cpp/language/class_template

So, when I write a class template I can specify types for which it 
should be explicitly instantiated without preventing from instantiation 
with other types

In header file a.hh
```
template <class T>
class A {
   void memfunc(T const&);
};

extern template class A<double>;

template <class T>
void A<T>::memfunc(T const&) { ... }
```

In source file a.cc
```
include "a.hh"
template class A<double>;
```

This creates the corresponding symbols for `A<double>::memfunction(T 
const&)` in the object file. If an application requests that same 
member-function, it does not need to be instantiated again and simply 
uses the symbol. If a different type for T is requested in an 
application, the compiler has to instantiated that class and 
member-function for the new type.

I was thinking that this technique could be used in several places of 
the dune core modules, to reduce the compile times of the all-in-all 
heavy template code.

Examples:
- dune-grid: YaspGrid for common dimensions
- dune-istl: BCRSMatrix for double and FieldMatrix<double,1,1>, Maybe 
even some solvers and preconditioners. There are even solver templates 
that can only be instantiated with a small set of types, e.g. external 
solvers like UMFPack or SuperLU
- dune-localfunctions: Many of the local bases are used with double type 
and dim=1,2,3 only.

See https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/481 
and 
https://gitlab.dune-project.org/extensions/dune-foamgrid/-/merge_requests/77 
for some implementations of that.

What do you think about this idea? It would increase the compile time of 
the core modules - since now something actually needs to be compiled - 
but would reduce the compile time in applications, tests, and downstream 
modules that use all these classes. Also, it would be an additional test 
that all these classes can actually be instantiated with the given 
types. (in dune-istl several errors showed up when I first tried this 
out - many are fixed now)

Best,
Simon

-- 
Dr. Simon Praetorius
Technische Universität Dresden
Institute of Scientific Computing
phone: +49 351 463-34432
mail: simon.praetorius at tu-dresden.de
web: https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius





More information about the Dune-devel mailing list