[Dune-devel] Explicit template instantiation

[Dominic Kempf]

Hey everybody,

Another, less invasive, option comes to my mind:
* In a first step, make sure that relevant templates like YaspGrid *can* be
explicitly instantiated (there might be subtle bugs that prevent it)
* Write user documentation how explicit template instantiation can be
achieved
* Adjust the duneproject script to include a module library that is readily
available for explicit instantiations

This way, the additional set up costs are shifted towards the user module
and other use cases of the core are not affected.
Also, everybody can decide for themselves whether or not explicit template
instantiation comes at a significant const.

Best,
Dominic

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

> Hi Carsten
>
> Am 16.02.21 um 20:46 schrieb Carsten Gräser:
> >
> >> 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.
> > this sounds like a good idea. While link time optimization
> > may help to do inlineing, unrolling, ... across translation
> > until boundaries, this potential runtime penalty could be
> > a valid reason against this.
> >
> > Maybe this could be done in an opt-in fashion:
> >
> > * Do not use `extern template` in the header.
> > * Do some documented explicit instantiation in the library.
> > * Users may (but don't have to) prohibit implicit instantiation
> >   by using `extern template ...` in their application after
> >   including the header. For sure this can only be done for
> >   those well-documented instantiations contained in the lib.
> > * If the user does not use `extern template ...` she will
> >   get implicit instantiation as usual.
>
> I don't know what is the best way to go. But I'm afraid that not writing
> the "extern termplate" in the headers would be more irritating than
> helping. We would just gain longer compile times for the libraries - not
> the opposite. And then the explicit instantiation (with prevented
> implicit instantiation) would mostly not be used. But it is something
> very positive for the user. I think just "well documentation" is not
> enough.
>
> However, I'm aware of the potential problems e.g. that we limit the
> inline-abilty of some functions by explicit instantiation. Whether this
> comes of a performance penalty I don't want to judge without
> benchmarking. Initial tests showed that there is not necessary any
> performance difference. This clearly depends on the application and on
> the template that is instantiated.
>
> An alternative to let the user manually write `extern template class
> ...` with the correct template parameters that are already instantiated
> would be a simple compile flag, something along the line:
>
> in the header:
>
> #if ENABLE_TEMPLATE_INSTATIATION
> extern template class YaspGrid<2,EquidistantCoordinate<double,2>>;
> extern template class YaspGrid<3,EquidistantCoordinate<double,3>>;
> #endif
>
> in the source:
>
> #if ENABLE_TEMPLATE_INSTATIATION
> template class YaspGrid<2,EquidistantCoordinate<double,2>>;
> template class YaspGrid<3,EquidistantCoordinate<double,3>>;
> #endif
>
> Or even conditionally add the source to the library target:
>
> in the CMakeLists.txt
>
> option(ENABLE_TEMPLATE_INSTATIATION "Enable explicit template
> instantiation" ON/OFF)
> if(ENABLE_TEMPLATE_INSTATIATION)
>    target_sources(dunegrid PRIVATE yaspgrid.cc)
> endif()
>
> with a corresponding entry in the config.h file
>
> #cmakedefine ENABLE_TEMPLATE_INSTATIATION 1
>
> Whether it is turned ON or OFF by default could be discussed, though.
>
> Best,
> Simon
>
>
> >
> > _______________________________________________
> > Dune-devel mailing list
> > 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
>
>
> _______________________________________________
> 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/20210217/0be775d4/attachment.htm>