<div dir="ltr">On Mon, Mar 20, 2017 at 11:19 AM, Roland Haas <span dir="ltr">&lt;<a href="mailto:rhaas@illinois.edu" target="_blank">rhaas@illinois.edu</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Present: Frank, Eloisa, Erik, Steve, Roland, Peter, Vassili, Ian,<br>
Roberto<br>
<br>
Failing tests:<br>
* boostedpuncture failure likely due to code change<br>
* GRHydro tests shows different behaviour depending on options, the<br>
  test seems to fail only with new enough compiler, and -ffast-math<br>
* affected hydro tests are very sensitive to data, it may be sufficient<br>
  to use a mild increase in resolution<br>
* as a general approach we need to decide if we want -ffast-math or if<br>
  removing it does not affect results too much. It may be sufficient<br>
  for gcc to specify options that allow the same subset of fast-math<br>
  that icc uses by default<br>
* if fast-math is needed for good performance, then we have to relax<br>
  test constraints for these tests<br></blockquote><div><br></div><div>I just recall that there is another issue: Modern CPUs support fused multiply-add instructions that may provide a different (but more accurate!) result. By default, GCC will use these instructions if they are available on the hardware. Exact reproducibility would require us to avoid such instructions, unless they give identical results. As Ian mentioned, we probably do not want to exact reproducibility, though.</div><div><br></div><div>-erik</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* action items:<br>
** run production benchmark with and without -fast-math on a modern<br>
machine (Erik), use GW150914<br>
** check if higher resolution helps for hydro tests (Roland)<br>
<br>
piraha parser:<br>
* Steve has an experimental version that produces multiple syntax<br>
  errors for ccl files<br>
* Ian would be happy with one good syntax error per ccl file and then<br>
  an abort, Roland would prefer multiple ones. Most importantly<br>
  multiple errors for par files<br>
* if parsing speed is slow (Steve obtained a speedup for parallel<br>
  parsing in a stand-alone parser but not with the integrated parser).<br>
  May consider c++ parser with perl fallback if speed is an issue<br>
<br>
KNL:<br>
* can compile on stampede2, but fail to run with a segfault at startup<br>
* Frank managed to compile in an interactive job and run<br>
* Roland notes that NERSC&#39;s cori has custom modules/code to allow<br>
  compilation of KNL code on the login nodes, what works on cori does<br>
  not work for example on a different Cray machine (internal)<br>
* wiki for progress<br>
  <a href="https://docs.einsteintoolkit.org/et-docs/Running_Cactus_on_Knights_Landing" rel="noreferrer" target="_blank">https://docs.einsteintoolkit.<wbr>org/et-docs/Running_Cactus_on_<wbr>Knights_Landing</a><br>
* Eloisa could obtain similar performance on KNL (~80%) for vacuum<br>
  simulation as on Broadwel node<br>
* CINECA has seminar on KNL, someone from Trento joined and we could try<br>
  and ask them to give an ET seminar and report back<br>
<br>
Yours,<br>
Roland<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu" rel="noreferrer" target="_blank">http://pgp.mit.edu</a> .<br>
</font></span><br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.<wbr>org/mailman/listinfo/users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Erik Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>&gt;<br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div></div>