<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Dominic and Christian,<br>
</p>
<div class="moz-cite-prefix">Am 16.02.21 um 17:06 schrieb Dominic
Kempf:<br>
</div>
<blockquote type="cite"
cite="mid:CA+Cg7M5Eh7H47xsR9XgYdKXNMD+71YXq+=-62u7d-F0_XcRHBQ@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<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>
</blockquote>
<p>If the runtimes might be influenced by this explicit
instantiation, probably some would like the possibility to opt
out. Currently, the configuration times nearly dominate the
compile times in the core modules, so an additional compile target
would not cost too much. But this needs to be weighted.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CA+Cg7M5Eh7H47xsR9XgYdKXNMD+71YXq+=-62u7d-F0_XcRHBQ@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
<p>If a member template is not implicitly instantiated by some other
non-template member function, it is not automatically instantiated
at all. But you could explicitly instantiate template member
functions as well.</p>
<p><br>
</p>
<p>Am 16.02.21 um 17:17 schrieb Christian Engwer:<br>
> we have made good experience wir explicit instantiations for
several application modules. Still there is one aspect I'm
concerned about.<br>
><br>
> We only used it for coarse grained interfaces. How is the
situation for fine grained interfaces like most dune-grid
interfaces? We rely on inlining for reducing the overhead. How
does inlining play with explicit instantiation?<br>
><br>
> In particular for yaspgrid we might experience a significant
performance penalty. Do you have some tests?</p>
<p>This could indeed be a valid argument against it. And I would
also not instantiate all template in the dune code base. So, one
has to balance and benchmark this. I have done some initial
benchmarks with YaspGrid. I get a speedup of factor 10 for compile
times. And for runtimes I see nearly no difference (even sometimes
the explicit-template-instantiation code is slightly faster).
These tests need to be extended, for sure.</p>
<p>
<a class="moz-txt-link-freetext" href="https://gitlab.dune-project.org/simon.praetorius/benchmark-grids">https://gitlab.dune-project.org/simon.praetorius/benchmark-grids</a><br>
</p>
<p>Best wishes,<br>
Simon<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+Cg7M5Eh7H47xsR9XgYdKXNMD+71YXq+=-62u7d-F0_XcRHBQ@mail.gmail.com">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Dune-devel@lists.dune-project.org</a><br>
<a
href="https://lists.dune-project.org/mailman/listinfo/dune-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.dune-project.org/mailman/listinfo/dune-devel</a></blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Dr. Simon Praetorius
Technische Universität Dresden
Institute of Scientific Computing
phone: +49 351 463-34432
mail: <a class="moz-txt-link-abbreviated" href="mailto:simon.praetorius@tu-dresden.de">simon.praetorius@tu-dresden.de</a>
web: <a class="moz-txt-link-freetext" href="https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius">https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius</a></pre>
</body>
</html>