<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 30, 2014 at 7:05 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Sam Williams <<a href="mailto:swwilliams@lbl.gov" target="_blank">swwilliams@lbl.gov</a>> writes:<br>
<br>
> For HPL, the website just has the reference implementation but links<br>
> to optimized BLAS.  The reality is its very unlikely every vendor<br>
> optimizing for HPGMG will contribute to the repo and give up IP<br>
> ownership.  As such, optimized becomes a sliding scale.  There is<br>
> optimized in the repo and there's the optimized from the vendor.<br>
<br>
</div>I don't foresee "standard" libraries of HPGMG spice, but perhaps that is<br>
a viable mechanism.  I would like there to be a way for users to<br>
reproduce vendor-provided numbers _after_ The List is released.<br>
(Otherwise people have to blindly trust the committee.  I'd rather<br>
empower the public to "trust but verify".)  Mark was interested in a way<br>
to make the source code accessible eventually.  I wonder if there is a<br>
way to swing that (perhaps with a special license).<br>
<div><br></div></blockquote><div><br></div><div>I think we should insist that they make their code public after it is published in a Top500 list.  We are doing them a favor by listing them.  We don't them anything as far as I know.  I want their competitors and the public to verify their code.  We don't have the time.  This not going to be as simple as DGEMM.</div>

<div><br></div><div>This is above my pay grade but John seemed to agree with this model.  I think should definitely try this model and see if we have the juice to do it.  What leverage do they have?  We are doing them a favor and we have a monopoly.  If they can make a case that they have a legitimate business reason to hold the IP on the then sure we can listen.  But every manager is going to want to CTA and say "keep it secret" as a safe easy thing to do. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> I also think that like BLAS, the optimized (architecture-specific)<br>
> HPGMG code needs to be self-contained and not sprinkled throughout.  I<br>
> don't want porting to a new architecture becoming a search for every<br>
> instance of __bgq__, __x86__, __mic__ ... to make sure you've found<br>
> every routine.<br>
<br>
</div>In HPGMG-FE, the restriction and prolongation has been pretty good<br>
without further trickery, so the two parts that need optimization are<br>
tensor contraction and the pointwise element kernel.  The main reason<br>
tensor contraction is "generic" now is so that it can be reused between<br>
different operators, but once we pin down an operator, there is no<br>
reason not to group it back into one file.  My intent was that at the<br>
end of the day, there would be one file containing optimization for each<br>
architecture.  It is already set up so that new source files are<br>
automatically registered.<br>
<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" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
<br></blockquote></div><br></div></div>