<html>#2410: compiling Baikal with gcc >= 9.3 is very slow
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</td></tr>
<tr><td style='text-align:right'>   Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'>  Version:</td><td></td></tr>
<tr><td style='text-align:right'>     Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>

<p>Comment (by Zach Etienne):</p>
<p><span class="ap-mention" data-atlassian-id="557058:56049c54-f8c2-4b6c-9b88-ab697c967495">@Erik Schnetter</span> : Thanks for the tip! I have just refactored NRPy+'s finite-difference generating code so that it generates CCTK_ATTRIBUTE_NOINLINE finite difference functions as well. </p>
<p>The net result is far faster compiles (&gt;10x faster for gcc 10.1 on a Linux machine), and far faster codegens (~2.4x faster to generate Baikal* thorns using NRPy+). Further, in early tests, I have found no degradation in runtime performance (same performance within error bars).</p>
<p>I confirmed that the updated Baikal* thorns still pass the testsuite, so I have replaced the Baikal* thorns in WVUThorns master with the updated ones. <span class="ap-mention" data-atlassian-id="557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22">@Roland Haas</span>  will be retrying on the same machine used to produce the original benchmarks for this ticket.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2410/compiling-baikal-with-gcc-93-is-very-slow'>https://bitbucket.org/einsteintoolkit/tickets/issues/2410/compiling-baikal-with-gcc-93-is-very-slow</a></p>
</html>