[Dune-devel] Explicit template instantiation

[Dominic Kempf]

Hey Simon,

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.
I guess that the Python bindings community will also profit very much from
this.

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?

Best,
Dominic

On Tue, Feb 16, 2021 at 4:34 PM Simon Praetorius <
simon.praetorius at tu-dresden.de> wrote:

> 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
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20210216/5a3d02fe/attachment.htm>