[Dune-devel] Explicit template instantiation
Simon Praetorius
simon.praetorius at tu-dresden.de
Tue Feb 16 19:23:58 CET 2021
Hi Dominic and Christian,
Am 16.02.21 um 17:06 schrieb Dominic Kempf:
> 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.
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.
> 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?
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.
Am 16.02.21 um 17:17 schrieb Christian Engwer:
> we have made good experience wir explicit instantiations for several
application modules. Still there is one aspect I'm concerned about.
>
> 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?
>
> In particular for yaspgrid we might experience a significant
performance penalty. Do you have some tests?
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.
https://gitlab.dune-project.org/simon.praetorius/benchmark-grids
Best wishes,
Simon
> On Tue, Feb 16, 2021 at 4:34 PM Simon Praetorius
> <simon.praetorius at tu-dresden.de
> <mailto: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
> <mailto: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
> <mailto:Dune-devel at lists.dune-project.org>
> https://lists.dune-project.org/mailman/listinfo/dune-devel
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20210216/4468fa09/attachment.htm>
More information about the Dune-devel
mailing list