<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 2:01 PM, Brian Van Straalen <span dir="ltr"><<a href="mailto:bvstraalen@lbl.gov" target="_blank">bvstraalen@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I’ve been wondering about how to automate some level of correctness testing in HPGMG.   I’m trying figure out if there are some computable limits to how much a compliant implementation *could* deviate from other compliant implementations.  </div><div><br></div><div>The concern is not trivial.  I’ve spent some time re-reading Precimonious paper (<a href="http://eecs.berkeley.edu/~rubio/includes/sc13.pdf" target="_blank"><span>eecs.berkeley.edu</span><span>/~rubio/includes/sc13.pdf</span></a>) and I realize that it would not be hard to make a faster version of FMG using mixed precision.  There have been papers over the last few years using 4-byte AMG as a preconditioner and that seems to work well for many applications.  </div></div></blockquote><div><br></div><div>I have been thinking that we would legislate double precision everywhere.  We need to legislate things like order of prolongation, smoother algorithm.  It is a design decision as to what spaces we allow to be optimized.  HPGMG is so simple that we need to defend against optimizations (games if you like) that are not readily available to most apps.  I am thinking that mixing precision is not a space that we want to open up.</div><div><br></div><div>Also, I have always wanted the math to be precisely defined so that the CS people, including center staff that are running and optimizing, do not have to think about math and can just think about making stuff run fast. (HPCG does not share this philosophy so perhaps I am in the minority here.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>FPGA computing platforms or accelerators also will want to push this envelope. </div><div><br></div><div>This is added to the other issues like faster FMAs that might not be totally standard, or fast division.    Our initial condition is also based on trig functions, which have the Table Maker’s Dilemma. The older x86 fsin instruction had a wide variability.   We could try to mitigate these effects (supply the trig function code expressed as in basic operations ie. Hart and Cheney, replace divisions in the reference code with multiplications when we know they are correct replace 1/(h*h) with DIM*DIM).  Or perhaps we do none of these things and see what kind of results people dare to submit.</div><div><br></div><div>I would guess the TOP500 effort is aware of this with the introduction of mixed-precision LINPACK in the last few years (like GHPL).</div><div><br></div><div>So, thoughts?</div><div><br></div><div>Brian</div><div><br></div><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div><div><font face="'Courier New'">Brian Van Straalen         Lawrence Berkeley Lab</font></div><div><font face="'Courier New'"><a href="mailto:BVStraalen@lbl.gov" target="_blank">BVStraalen@lbl.gov</a>         Computational Research</font></div><div><font face="'Courier New'"><a href="tel:%28510%29%20486-4976" value="+15104864976" target="_blank">(510) 486-4976</a>             Division (<a href="http://crd.lbl.gov" target="_blank">crd.lbl.gov</a>)</font></div></div><div><br></div><div><br></div></span><br>
</div>
<br></div><br>_______________________________________________<br>
HPGMG-Forum mailing list<br>
<a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
<a href="https://hpgmg.org/lists/listinfo/hpgmg-forum" rel="noreferrer" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
<br></blockquote></div><br></div></div>