<div dir="ltr"><div>Hey Simon,</div><div><br></div><div>I am very much in favor of this, especially in the YaspGrid case. As the requirements regarding compilation speed (set up cost vs. repeating costs) will vary greatly throughout the community, I would opt for this to be an optional feature though.</div><div>I guess that the Python bindings community will also profit very much from this.<br></div><div><br></div><div>A technical question: What happens to member templates of pre-instantiated class templates? Do you need to somehow explicitly provide their possible values? Are they excluded from the pre-instantiation?</div><div><br></div><div>Best,</div><div>Dominic<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 16, 2021 at 4:34 PM Simon Praetorius <<a href="mailto:simon.praetorius@tu-dresden.de">simon.praetorius@tu-dresden.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Community,<br>
<br>
Recently, I have experimented with explicit template instantiation of <br>
some grid types leading to a reasonable speedup of compile processes. In <br>
a few applications I have compile times for a single target > 5min on a <br>
decent machine and was wondering how to to reduce that time.<br>
<br>
In summary: explicit template instantiation is a way to enforce an <br>
instantiation of a template in a translation unit and to prevent from <br>
implicit instantiations of that same template.<br>
<br>
See: <a href="https://en.cppreference.com/w/cpp/language/class_template" rel="noreferrer" target="_blank">https://en.cppreference.com/w/cpp/language/class_template</a><br>
<br>
So, when I write a class template I can specify types for which it <br>
should be explicitly instantiated without preventing from instantiation <br>
with other types<br>
<br>
In header file a.hh<br>
```<br>
template <class T><br>
class A {<br>
   void memfunc(T const&);<br>
};<br>
<br>
extern template class A<double>;<br>
<br>
template <class T><br>
void A<T>::memfunc(T const&) { ... }<br>
```<br>
<br>
In source file a.cc<br>
```<br>
include "a.hh"<br>
template class A<double>;<br>
```<br>
<br>
This creates the corresponding symbols for `A<double>::memfunction(T <br>
const&)` in the object file. If an application requests that same <br>
member-function, it does not need to be instantiated again and simply <br>
uses the symbol. If a different type for T is requested in an <br>
application, the compiler has to instantiated that class and <br>
member-function for the new type.<br>
<br>
I was thinking that this technique could be used in several places of <br>
the dune core modules, to reduce the compile times of the all-in-all <br>
heavy template code.<br>
<br>
Examples:<br>
- dune-grid: YaspGrid for common dimensions<br>
- dune-istl: BCRSMatrix for double and FieldMatrix<double,1,1>, Maybe <br>
even some solvers and preconditioners. There are even solver templates <br>
that can only be instantiated with a small set of types, e.g. external <br>
solvers like UMFPack or SuperLU<br>
- dune-localfunctions: Many of the local bases are used with double type <br>
and dim=1,2,3 only.<br>
<br>
See <a href="https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/481" rel="noreferrer" target="_blank">https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/481</a> <br>
and <br>
<a href="https://gitlab.dune-project.org/extensions/dune-foamgrid/-/merge_requests/77" rel="noreferrer" target="_blank">https://gitlab.dune-project.org/extensions/dune-foamgrid/-/merge_requests/77</a> <br>
for some implementations of that.<br>
<br>
What do you think about this idea? It would increase the compile time of <br>
the core modules - since now something actually needs to be compiled - <br>
but would reduce the compile time in applications, tests, and downstream <br>
modules that use all these classes. Also, it would be an additional test <br>
that all these classes can actually be instantiated with the given <br>
types. (in dune-istl several errors showed up when I first tried this <br>
out - many are fixed now)<br>
<br>
Best,<br>
Simon<br>
<br>
-- <br>
Dr. Simon Praetorius<br>
Technische Universität Dresden<br>
Institute of Scientific Computing<br>
phone: +49 351 463-34432<br>
mail: <a href="mailto:simon.praetorius@tu-dresden.de" target="_blank">simon.praetorius@tu-dresden.de</a><br>
web: <a href="https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius" rel="noreferrer" target="_blank">https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius</a><br>
<br>
<br>
_______________________________________________<br>
Dune-devel mailing list<br>
<a href="mailto:Dune-devel@lists.dune-project.org" target="_blank">Dune-devel@lists.dune-project.org</a><br>
<a href="https://lists.dune-project.org/mailman/listinfo/dune-devel" rel="noreferrer" target="_blank">https://lists.dune-project.org/mailman/listinfo/dune-devel</a></blockquote></div>