<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi everyone,</p>
<p><br>
</p>
<p>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++. <br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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:</p>
<p><br>
</p>
<div style="color: #000000;background-color: #ffffff;font-family: 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback';font-weight: normal;font-size: 14px;line-height: 19px;white-space: pre;"><div><span style="color: #000000;"> dune_instantiate_templates(</span><target></div><div><span style="color: #000000;"> TYPES </span><span style="color: #a31515;">"Dune::YaspGrid<2>;Dune::YaspGrid<3>"</span></div><div><span style="color: #000000;"> HEADERS </span><span style="color: #a31515;">"dune/grid/yaspgrid.hh"</span><span style="color: #000000;">)</span></div></div>
<p><br>
</p>
<p>This is absolutely non-intrusive and can be used on a per-target
base in the application module.</p>
<p><br>
</p>
<p>Best,<br>
Simon<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 17.02.21 um 13:14 schrieb Dedner,
Andreas:<br>
</div>
<blockquote type="cite"
cite="mid:DB6PR01MB39603243A4D9ED30462251F79A869@DB6PR01MB3960.eurprd01.prod.exchangelabs.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
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?</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);" data-keeper-edited="yes">
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.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Best</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Andreas<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Dune-devel <a class="moz-txt-link-rfc2396E" href="mailto:dune-devel-bounces@lists.dune-project.org"><dune-devel-bounces@lists.dune-project.org></a>
on behalf of Carsten Gräser <a class="moz-txt-link-rfc2396E" href="mailto:graeser@mi.fu-berlin.de"><graeser@mi.fu-berlin.de></a><br>
<b>Sent:</b> 17 February 2021 12:04<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:dune-devel@lists.dune-project.org">dune-devel@lists.dune-project.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:dune-devel@lists.dune-project.org"><dune-devel@lists.dune-project.org></a><br>
<b>Subject:</b> Re: [Dune-devel] Explicit template
instantiation</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt;">
<div class="PlainText">Am 16.02.21 um 23:53 schrieb Simon
Praetorius:<br>
>> Maybe this could be done in an opt-in fashion:<br>
>><br>
>> * Do not use `extern template` in the header.<br>
>> * Do some documented explicit instantiation in
the library.<br>
>> * Users may (but don't have to) prohibit implicit
instantiation<br>
>> by using `extern template ...` in their
application after<br>
>> including the header. For sure this can only be
done for<br>
>> those well-documented instantiations contained
in the lib.<br>
>> * If the user does not use `extern template ...`
she will<br>
>> get implicit instantiation as usual.<br>
> <br>
> I don't know what is the best way to go. But I'm
afraid that not<br>
> writing the "extern termplate" in the headers would
be more<br>
> irritating than helping. We would just gain longer
compile times for<br>
> the libraries - not the opposite. And then the
explicit instantiation<br>
I don't understand this argument:<br>
<br>
* If the template was implicitly instantiated in the
library before,<br>
doing it explicitly now should not increase library
build time.<br>
* If the template was not implicitly instantiated in the
library before,<br>
you must instantiate it explicitly now, which increases
library build<br>
time. Otherwise you can't use it downstream. At some
place you have<br>
to do the instantiation. The whole purpose of the
proposal seems to<br>
be, to move this cost upward in the build hierarchy in
order to prevent<br>
paying it multiple times downstream.<br>
<br>
> (with prevented implicit instantiation) would mostly
not be used. But<br>
> it is something very positive for the user. I think
just "well<br>
> documentation" is not enough.<br>
If there is some performance penalty, introducing this
silently<br>
is IMO a no-go. Hence I would prefer an opt-in approach.<br>
An alternative to the fully manual approach I proposed
before,<br>
would be to provide a single header (per module) with all
the<br>
`extern template...` declarations for the instances
contained<br>
in the library. Then the user can opt-in by including this
header.<br>
<br>
Best,<br>
Carsten<br>
<br>
_______________________________________________<br>
Dune-devel mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dune-devel@lists.dune-project.org">Dune-devel@lists.dune-project.org</a><br>
<a
href="https://lists.dune-project.org/mailman/listinfo/dune-devel"
moz-do-not-send="true">https://lists.dune-project.org/mailman/listinfo/dune-devel</a></div>
</span></font></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dune-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune-devel@lists.dune-project.org">Dune-devel@lists.dune-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.dune-project.org/mailman/listinfo/dune-devel">https://lists.dune-project.org/mailman/listinfo/dune-devel</a></pre>
</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>