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

Re: ATLAS/flame



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