<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 12:33 PM, Sam Williams <span dir="ltr"><<a href="mailto:swwilliams@lbl.gov" target="_blank">swwilliams@lbl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think there is a difference in saying<br>
- we need a high-quality implementation to tease out the kiviat characteristics in order to showcase the compute requirements of FEM<br>
- we need a high-quality reference implementation that's been manually optimized for Mira.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I'm not sure what the issue is here.  This is portable in that it is not defined for non BGQ.  We may not need to deploy the BGQ optimization in the distribution but why not distribute it if we have it?</div>
<div><br></div><div>Jed seemed to be saying that we need an factor of 2x on _all_ platforms provided by us in reference implementations.  This may not be what Jed meant, but we are most likely not going to have the resources to do this.  You two are delivered more than we need, probably, but there is nothing wrong with too much power.  This is really up to you and Jed as you two are doing all the real work.  I think we need to have this '[well] within 2x' in the reference implementation for _a_ machine, and preferably many/most/all of the major platforms.  Jed has the bad luck that the kiviat data is on an uncooperative machine, but it is an important platform anyway.</div>
<div><br></div><div>I don't think you should feel that you need to do everything well.  As I said I think that you two are both doing more than a solid job on reference implementations and there will have to be a model of allowing user/center/vendor contributions.  So I would not worry about it too much.  That said, I do and will salivate at the prospect of a good Phi and Cuda implementations, but don't feel pressure to deliver it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
On Apr 29, 2014, at 9:22 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
<br>
> Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov">bvstraalen@lbl.gov</a>> writes:<br>
><br>
>> Jed Brown    7b171e1          fe: loop optimizations to TensorContract_QPX<br>
>> 28 Apr 2014<br>
>> Jed Brown    339691b          fe: initial QPX version of tensor contraction<br>
>> 28 Apr 2014<br>
>> Jed Brown    b1189a3          make: remove redundant link flags<br>
>> 28 Apr 2014<br>
>><br>
>> This seems like a pretty unportable benchmark idea.  Does HPL do this<br>
>> for the download version?  Or are these commits to the research<br>
>> branch?<br>
><br>
> We need a "high-quality" implementation.  The XL compiler is amazingly<br>
> terrible at producing decent code for the small tensor contractions<br>
> (versus gcc on x86, which does quite well).  Consequently, any<br>
> performance counter data on BG/Q is entirely measuring the compiler (by<br>
> about an order of magnitude).  The fact that code is easier to optimize<br>
> on Intel than BG/Q is well-known, but we can't have a credible benchmark<br>
> without decent code-gen there.  I don't want private vendor<br>
> implementations to be an order of magnitude faster than what people can<br>
> run for themselves.  (A modest difference is unavoidable.)<br>
><br>
> Note that this stuff is not compiled when running on other<br>
> architectures, so does not impact portability.  I also have Intel<br>
> AVX/FMA intrinsics which are easier to work with and produce nearly 2x<br>
> speedup over vanilla C (and GCC produces better code than ICC).<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
<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" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</div></div></blockquote></div><br></div></div>