<div dir="ltr">Hi,<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 10, 2016 at 4:56 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 9, 2016 at 4:43 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><br></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Wed, Mar 9, 2016 at 3:42 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>No, I don&#39;t. I triggered it the other day because I did not know the main 5.1 matrix does the job already.</div></div></blockquote><div><br></div></span><div>OK, I&#39;ll delete it tomorrow.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>What about master, additional releng support is needed I guess? Also, is there anything holding us back from adding pre- and post-submit configs to admin//builds/*matrix.txt.</div></div></blockquote><div><br></div></span><div>See my other email to gmx-developers just now. I think pre-submit should cover only the highest-value targets. Post-submit for lower-value targets and/or tests that take more time.</div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"></div></blockquote><div><br></div><div>I agree. A dozen or so configs to cover the most common software/parallelization configurations should be enough. Having looked at the Gromacs_Gerrit_master_nrwpo configs,</div></div></div></div></blockquote><div><br></div><div>Don&#39;t, that&#39;s just an example set so people can run a custom config if they have a need to do so. I have now clarified that in the Jenkins parameter description text. Per my other email, the matrix lives in the source repo at admin/builds/pre-submit-matrix.txt</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> I propose the following additions/tweaks:</div><div>- OpenCL (I suggest using AMD GPUs and adding both release and debug, error handling is rather poor and OpenCL API erros are mostly handled with assert&#39;s)</div></div></div></div></blockquote><div><br></div><div>Sure, but first we have to make the build work (there were mysterious failures last time I tried it).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- an SSE4.1 (i.e. 4-wide SIMD) build unless  - AFAICT VM-based builds are not already doing that;</div></div></div></div></blockquote><div><br></div><div>Plausible, but why is it a &quot;highest-value target?&quot; That and SSE2 seem like candidates for post-submit testing. If some patch fails to break other kinds of SIMD, it&#39;s pretty unlikely to break precisely these, unless the patch is somehow aimed at them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- some runs that execute tests with 2D/3D DD (if 3D is hw resource-wise an issue could be left for post-submit),</div></div></div></div></blockquote><div><br></div><div>I don&#39;t remember whether this still happens automagically. Running some multi-rank tests seems wise, but yeah 3D can probably take a lower priority if 2D is covered.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Additionally:</div>- Has valgrind testing been discontinued? (Teemu mentioned on #1815 that valgrind configs got accidentally removed at some point?) <br></div></div></div></blockquote><div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">AFAICR it&#39;s currently disabled with at least Windows, icc, gcc-5 and clang builds, for issues including those caused by</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px"><a href="http://valgrind.org/docs/manual/faq.html#faq.reports" target="_blank">http://<span class="lG">valgrind</span>.org/docs/manual/faq.html#faq.reports</a></div><div style="font-size:13px;line-height:19.5px"><a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.memory" target="_blank">https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.memory</a><br></div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">If we want to use it in Jenkins in future, then I think we need to commit to running it with a C++ standard library in &quot;always free memory mode,&quot; which is going to be even slower to run and/or harder to maintain on &quot;real&quot; build slaves. <span class="lG">Valgrind</span> is approximately superseded by MemorySanitizer, for which we have a build type and a probably-not-badly-broken build at <a href="http://jenkins.gromacs.org/job/Gromacs_Gerrit_master-test-MSan/">http://jenkins.gromacs.org/job/Gromacs_Gerrit_master-test-MSan/</a>. These kinds of tools are particularly brittle with respect to dependencies, etc. so I think they make sense to run regularly in Jenkins only if we implement them in a Docker environment, built with a script (Google suggests some people might have done this for us already), rather than on some build slave whose setup details nobody can remember and will break upon upgrades :-)</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">- How about TSAN? I&#39;ve seen no confgis use it (but we&#39;ve been using it for 5.1, right?)</div></div></div></blockquote><div><br></div><div>It&#39;s in the actual matrix already. In the longer term, I think it also makes sense on a Docker image.</div><div><br></div><div>Mark</div></div></div>