[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
R Clint Whaley wrote:
> >I see no significant change in the difference between ATLAS and ITXGEMM when
> >linking with this new version. Notice that we consider "peak" to be much less
> >important than how the routines perform for all matrix sizes.
> Hmm, 72 to 78 percent should be significant, particularly for the very large
> LU numbers you do (unless you feel the gap between 72 and 80 that you
> presently have between ITX and ATLAS is insignificant :).
> >I will do an exhaustive run tonight. Do you prefer m,n,k=40:40:520 or
> >or what increments favor this version of ATLAS?
> I think you need to rerun all the ATLAS timings in order to replace the
> incorrect timings on your webpage. You installed a binary plainly labeled
> as for 512K caches on a machine you indicate has 256K. This error would not
> have occured if you installed from source, as I asked when you first contacted
> ATLAS for help. I have given you a prebuilt binary since you were unwilling
> to compile from source to fix your error. I think leaving knowingly
> inaccurate timings would be dishonest on your part.
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 merely picked up the ONLY version for PII and PIII that was on your
atlas webpage a while back.
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.