[HPGMG Forum] Do we want the benchmark to go into intrinsics?

Mark Adams mfadams at lbl.gov
Wed Apr 30 18:34:28 UTC 2014


On Wed, Apr 30, 2014 at 7:05 AM, Jed Brown <jed at jedbrown.org> wrote:

> Sam Williams <swwilliams at lbl.gov> writes:
>
> > For HPL, the website just has the reference implementation but links
> > to optimized BLAS.  The reality is its very unlikely every vendor
> > optimizing for HPGMG will contribute to the repo and give up IP
> > ownership.  As such, optimized becomes a sliding scale.  There is
> > optimized in the repo and there's the optimized from the vendor.
>
> I don't foresee "standard" libraries of HPGMG spice, but perhaps that is
> a viable mechanism.  I would like there to be a way for users to
> reproduce vendor-provided numbers _after_ The List is released.
> (Otherwise people have to blindly trust the committee.  I'd rather
> empower the public to "trust but verify".)  Mark was interested in a way
> to make the source code accessible eventually.  I wonder if there is a
> way to swing that (perhaps with a special license).
>
>
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.

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.


> > I also think that like BLAS, the optimized (architecture-specific)
> > HPGMG code needs to be self-contained and not sprinkled throughout.  I
> > don't want porting to a new architecture becoming a search for every
> > instance of __bgq__, __x86__, __mic__ ... to make sure you've found
> > every routine.
>
> In HPGMG-FE, the restriction and prolongation has been pretty good
> without further trickery, so the two parts that need optimization are
> tensor contraction and the pointwise element kernel.  The main reason
> tensor contraction is "generic" now is so that it can be reused between
> different operators, but once we pin down an operator, there is no
> reason not to group it back into one file.  My intent was that at the
> end of the day, there would be one file containing optimization for each
> architecture.  It is already set up so that new source files are
> automatically registered.
>
> _______________________________________________
> HPGMG-Forum mailing list
> HPGMG-Forum at hpgmg.org
> https://hpgmg.org/lists/listinfo/hpgmg-forum
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140430/761fd0df/attachment.html>


More information about the HPGMG-Forum mailing list