[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ATLAS/flame

R Clint Whaley wrote:

> Robert,
> >why don't you simply take our stuff, run it on your favorite machine,
> >and put the resulting timings on a webpage yourself?  Since we have
> >our .a files out there, this is a simple thing to do.  Since we only have
> >one .a file, there is no opportunity for confusion.
> I will do some timings myself once the new release is out; I doubt I will
> post them to the webpage because I doubt they are of great interest to
> most ATLAS users.  We are talking about a tiny difference on one of 20 or
> so supported architectures here . . .
> >I merely picked up the ONLY version for PII and PIII that was on your
> >atlas webpage a while back.
> This doesn't fly.  It was labeled for a 512K cache, and the source would
> have fixed it.  The point is if you are going to compare your numbers to
> someone elses', you should make them accurate.  If I *did* post comparison
> numbers, I would ensure to install the other library correctly before
> publishing results.  I have built you an archive, so if you want to compare
> with ATLAS, please use it.
> >I urge you to do the ATLAS community a favor, and put
> >numbers for a broad spectrum of problem sizes on the web page,
> >rather than just one peak number.
> ATLAS comes with very accurate timers, which can easily time arbitrarily sized
> problems, so the user can easily see the performance himself.  They are
> designed to be able to compare ATLAS with an arbitrary blas, so he can even
> do whatever timing comparisons he wants.  We give some rough timings so
> new users can see that these blas are well optimized; We don't put peak
> values for our numbers: it's a 500x500 case, which is not peak on almost
> any machine.  Doing timings like you are talking about is impractical when
> support an arbitrarily large architecture set, as opposed to 1.
> Clint

Very well then, can someone in the ATLAS community kindly do a
nonpartisan comparison?  Furthermore, since Clint points at the
value of having this on many different architectures, perhaps someone
from another vendor can help us out by optimizing a tiny kernel for
another architecture.  I can specify the requirements for that kernel
easily and clearly.