<div dir="ltr"><span>Hi,</span><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 31, 2018, 20:30 Theodore Omtzigt <<a href="mailto:theo@stillwater-sc.com" target="_blank">theo@stillwater-sc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Tue, Jul 31, Mark Abraham wrote:<div><br></div><div>
<span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">One of our supercomputer center customers want to enable GROMACS with this</span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> new number system, and I am looking for subject matter experts that we</span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> should work with to enable GROMACS with the C++ posit arithmetic library</span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> that has been developed for the posit-based hardware accelerators.</span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">></span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">What advantage has that center identified?</span>
<br></div><div><br></div></div><div dir="ltr"><div>Memory and MPI communication bandwidth. </div></div></blockquote></div></div><div><br></div><div>At scale, on CPU machines, GROMACS runs inside L1 cache, and is limited by network latency of the messages sent (mostly a few KB each). So there's no free win there.</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Posits typically compete with IEEE floating point twice their size. So 32bit posits tend to beat 64bit doubles in terms of numerical accuracy.</div></div></blockquote><div><br></div><div>GROMACS already makes extensive use of mixed precision - essentially all computation is done in single and some aspects of reduction are in double. So e.g. if a 16-bit posit could reduce cache pressure vs a 32-bit float, then some simulation system that used to be L2 bound could become L1 bound. That would only be a benefit on hardware that can handle operations on the posit type natively.</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><div><div class="m_5198021466735265996m_788198320967468932m_214660192006177210gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Secondly, posits with their reproducibility create pure identity transformations when using forward/inverse transforms. We have FFT/iFFT kernels using16bit posits that beat 64bit double implementations in terms of numerical accuracy.</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Great, but as I mentioned we're not aware of cases where the existing numerical accuracy of a float-based FFT implementation is insufficient at a given set of FFT parameters (e.g. grid size and spline interpolation order). Reproducibility is a nice attribute for debugging, but otherwise there's no strong requirement for the trajectories to be reproducible. Observing a specific rare event is sometimes useful, but if you only see it in one trajectory, then it is difficult to defend such observations as relevant.</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><div><div class="m_5198021466735265996m_788198320967468932m_214660192006177210gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>The FFT in particular was the first kernel we were going to enable with posits to improve the performance of the communication.</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Typical 3D FFT grids used in biomolecular MD simulations are between 64 cubed and 256 cubed. Those are down the small end for most people doing computations on FFTs, or development work to improve those computations. Optimizations that reduce the number of messages (or data movement generally) are likely useful, but bandwidth is not a problem.</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><div class="m_5198021466735265996m_788198320967468932m_214660192006177210gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Given this additional information, do you think that they are mistaken in thinking that posits would be a net benefit to performance?</div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>It does sound like a generic hope, rather than one based on extensive understanding of how high performance MD codes work. :-) I don't mean to be negative, but MD codes are probably not the low hanging fruit for demonstrating the benefits of this approach.</div><div><br></div><div>Mark</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>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div></div><span>
</span>
</div>