<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 8:27 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">I would probably be more inclined to leave HPGMG to be purely C-code reference implementation with MPI and/or/without OpenMP.   The range of input values for the dot product are well characterized. If we think we need it, it is not complicated to site the relevant literature and provide the reference implementation in C (fast arbitrary-precision floating-point was my graduate project with Shewchuk ;-) ).   We don’t currently know anything about how sensitive the final residual is to the bottom solve dot product.   External dependencies, however slight, make a benchmark less attractive.   <div><br></div><div>I suspect Jed is right and there is not much wiggle room in FMG for precision gaming.  I was wondering if there was a way to prove it and hence impose a reasonably tight error tolerance for an acceptable benchmark submission.  </div></div></blockquote><div><br></div><div>I have always liked to use the rate (and not absolute value) of convergence in the error (not residual).  Sam is writing the first submission guidelines now, and I have not see it.  The nice thing about looking at convergence rates in error is that it can work in any precision.  We do have the problem that 4th order will hit double precision limit soon, but we can look at rates before it hits the wall and ignore the inevitable (sharp) stagnation.  We have yet to design this and it would require its own tolerances of what is 4th (eg, > 3.99) order exactly.</div><div><br></div><div>Sam is writing the submission guidelines now.  </div><div><br></div><div>Sam: perhaps you could circulate your guidelines on the forum and get some quick feedback.  </div><div><br></div><div>We really need to get this out the door soon so that we can get data for SC15.  I expect this spec will "evolve", a lot, and as Brian pointed out we can react to issues if they arise and not try to be perfect.  And centers will give us feedback and we will get experience with what is not clear, etc.</div><div><br></div><div><br></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>The nice thing about the 4th-order FV code is that almost any shortcuts results in breaking 4th-order truncation error.<span class="HOEnZb"><font color="#888888"><br><div><br></div><div>Brian</div></font></span><div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Jul 31, 2015, at 6:41 PM, JOHN SHALF <<a href="mailto:jshalf@me.com" target="_blank">jshalf@me.com</a>> wrote:</div><br><div><div dir="auto"><div>Brian,</div><div>George Michelogiannakis implemented a reproducible dot product (published 2years ago in SC).  We demonstrated only 3% slowdown over a conventional double precision dot prod.  Jim Demmel's postdoc implemented something similar last year and added it to ReproBLAS.</div><div><br></div><div>My recommendation is to just link against ReproBLAS since it is a released, tuned, and professionally supported reproducible blas implementation.</div><div><br></div><div>-john<br><br>Sent from my iPhone</div><div><br>On Jul 31, 2015, at 5:04 PM, Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov" target="_blank">bvstraalen@lbl.gov</a>> wrote:<br><br></div><blockquote type="cite"><div>Once you reach the bottom solver for full multigrid you should not be in the network at all anymore.  You would be computing a dot product over a few hundred doubles in L1 memory.  I’m just guessing here but I don’t think the cost of a reproducible dot product would be that bad to implement in software as a compensated sum or distillation.   There was a talk at ISC this year showing some results.  From DRAM compensated summation is about the same, and gets more expensive in faster memory levels.  The impact was not 50x ever though. <div><br><div><br><div><br><div><blockquote type="cite"><div>On Jul 31, 2015, at 4:38 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>> wrote:</div><br><div><div dir="ltr">If by 128b floats, you mean IEEE754 quad precision implemented in SW, then the associated dot product will run ~50x slower on conventional hardware (that is, hardware that does not support QP).<div><br></div><div>It should be possible to implement DDP or some form of compensated summation more efficiently.<br><div><br></div><div>Jeff<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 4:18 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 would think that we could probably implement a reproducible dot product in the krylov code since it only happens on the coarse grid which should be small enough.</div><div><br></div><div>HPGMG uses max norms, so we should be ok for that part.</div><span><font color="#888888"><div><br></div><div>Brian</div></font></span><div><div><div><br></div><br><div><blockquote type="cite"><div>On Jul 31, 2015, at 3:27 PM, Hoemmen, Mark <<a href="mailto:mhoemme@sandia.gov" target="_blank">mhoemme@sandia.gov</a>> wrote:</div><br><div><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">On 7/31/15, 3:45 PM, "Jed Brown" <</span><a href="mailto:jed@jedbrown.org" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">jed@jedbrown.org</a><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">> wrote:</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov" target="_blank">bvstraalen@lbl.gov</a>> writes:<br><blockquote type="cite">The concern is not trivial.  I¹ve spent some time re-reading<br>Precimonious paper (<a href="http://eecs.berkeley.edu/~rubio/includes/sc13.pdf" target="_blank">eecs.berkeley.edu/~rubio/includes/sc13.pdf</a><br><<a href="http://eecs.berkeley.edu/~rubio/includes/sc13.pdf" target="_blank">http://eecs.berkeley.edu/~rubio/includes/sc13.pdf</a>>) and I realize<br>that it would not be hard to make a faster version of FMG using mixed<br>precision.  <br></blockquote><br>Just a quick comment now.  I think there's not as much fat to trim as<br>you think.  In general, the precision needs to be as accurate as the<br>discretization.  Most flops occur on fine grids where the discretization<br>is more accurate than single precision.  I challenge you to speed up<br>HPGMG by more than, say, 15%, while maintaining order of accuracy on<br>fine grids.<br><br><blockquote type="cite">There have been papers over the last few years using 4-byte AMG as a<br>preconditioner<span> </span><br></blockquote><br>So much fat already.  Then you have a Krylov method and full-accuracy<br>residuals, but HPGMG solves in the cost of a few residual evaluations.<br>Also, these low-accuracy preconditioners are usually used for problems<br>that are only modestly ill-conditioned.  Try it with an operator with<br>condition number 10^{12} like you see in solid mechanics or geodynamics<br>and it doesn't look so hot any more.<br></blockquote><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">It could be fun to use such a tool to find out the best places to put</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">128-bit floating-point arithmetic.  That could help with some really hard</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">problems, or at least avoid some reproducibility issues.</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">mfh</span></div></blockquote></div><br></div></div><span><div>
<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-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></span></div><br>_______________________________________________<br>
HPGMG-Forum mailing list<br>
<a href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">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><br clear="all"><div><br></div>-- <br><div>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div></div></div>
</div></blockquote></div><br><div>
<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;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></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>HPGMG-Forum mailing list</span><br><span><a href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a></span><br><span><a href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a></span><br></div></blockquote></div></div></blockquote></div><br><div>
<span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-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></div></div></div></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>