[Dune-devel] Explicit template instantiation

[Simon Praetorius]

Hi everyone,


Thanks for all the feedback. I see the arguments. Initially, I thought 
it could be beneficial to reduce the compile times for all users by 
default. But I also understand the "do not pay for what you don't use" 
philosophy that is standard for c++.


Maybe, one could at least add some tests with explicit template 
instantiation, to check that this is possible. (Currently YaspGrid 
cannot be instantiated that way, but a fix is not too complicated). In 
dune-istl this has shown several bugs in the implementation, probably in 
other modules this improves the code as well.


I thought about a simple cmake function that instead generates the 
explicit instantiation source and a corresponding header on request for 
an application target. Something along the lines:


dune_instantiate_templates(<target>
TYPES "Dune::YaspGrid<2>;Dune::YaspGrid<3>"
HEADERS "dune/grid/yaspgrid.hh")


This is absolutely non-intrusive and can be used on a per-target base in 
the application module.


Best,
Simon


Am 17.02.21 um 13:14 schrieb Dedner, Andreas:
> Hi,
> I'm probably missing what this proposal is about - but wouldn't this 
> increase build time for everyone even if I don't use this 
> instantiation? So if I'm not interested in YaspGrid then I pay the 
> instatiation cost while building dune-grid?
>
> Why is this actually needed in the core modules? If someone wants 
> speedup for yaspgrid for the executables in their own 'dune-foo' 
> module. they can instantiate in a 'libdunefoo' and will also have it 
> downstream from dune-foo? They could even have a `dune-yaspgrid` 
> module with only this library in it and have `dune-foo` depend on or 
> suggest `dune-yaspgrid` with exactly the same effect but without 
> changing anything in dune-grid and requiring opt-in/opt-out in the 
> configuration.
>
> Best
> Andreas
> ------------------------------------------------------------------------
> *From:* Dune-devel <dune-devel-bounces at lists.dune-project.org> on 
> behalf of Carsten Gräser <graeser at mi.fu-berlin.de>
> *Sent:* 17 February 2021 12:04
> *To:* dune-devel at lists.dune-project.org 
> <dune-devel at lists.dune-project.org>
> *Subject:* Re: [Dune-devel] Explicit template instantiation
> Am 16.02.21 um 23:53 schrieb Simon Praetorius:
> >> 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
> I don't understand this argument:
>
> * If the template was implicitly instantiated in the library before,
>    doing it explicitly now should not increase library build time.
> * If the template was not implicitly instantiated in the library before,
>    you must instantiate it explicitly now, which increases library build
>    time. Otherwise you can't use it downstream. At some place you have
>    to do the instantiation. The whole purpose of the proposal seems to
>    be, to move this cost upward in the build hierarchy in order to prevent
>    paying it multiple times downstream.
>
> > (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.
> If there is some performance penalty, introducing this silently
> is IMO a no-go. Hence I would prefer an opt-in approach.
> An alternative to the fully manual approach I proposed before,
> would be to provide a single header (per module) with all the
> `extern template...` declarations for the instances contained
> in the library. Then the user can opt-in by including this header.
>
> Best,
> Carsten
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20210217/82c73110/attachment.htm>