#124 zgemm accesses C for beta=0

Both
closed-fixed
5
2009-08-06
2009-04-09
No

Hi,

we are using ATLAS for our density-functional theory code SPHInX (electronic structure theory), and its just great! Its big advantage over other BLAS implementations is for "thin" matrices (M >> N), which occur quite commonly in our code.

Unfortunately, I have now encountered a problem for certain cases in zgemm when beta=0 (alpha=1, transA='N', transB='N', lda=M, ldb=K). We do not initialize C in this case, which usually works fine. For certain cases, e.g. m=32, n=120, k=240 (or k=21646, which is the original case), however, we sometimes get nans. We reproducibly get nans if C is initialized with nans.

I wonder
a) if the BLAS standard says anything on whether I may use uninitialized C's for beta=0, and
b) if this nan-propagation is a known(=wanted?) behaviour of the ATLAS

The tech details:

ATLAS 3.8.3 (an older 3.7.26 seems to be fine)

uname -a
Linux cmpc34 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC x86_64 x86_64 x86_64 GNU/Linux

Dual Core AMD Opteron(tm) Processor 270 2GHz

compiled with -fPIC with a gcc 4.2.3

Discussion

  • Hi,

    The BLAS standard is very clear: for BETA=0, a conformant BLAS is not allowed use the input values of C. A C filled with NaN should not produce NaN (unless A or B does) when BETA=0. Therefore, if ATLAS is doing what you say, it is an error in ATLAS. This is an error that crops up with some frequency, as I add some code and forget the special case, or a particular configuration reveals a pre-existing oversight, so I would imagine that you have found a bug in ATLAS.

    I don't have time to look at it today, but I hope to do so over the weekend, and will update this once I have confirmed or been unable to confirm your observation (I have an Opteron, so I'm hopeful).

    Thanks,
    Clint

     
    • assigned_to: nobody --> rwhaley
     
    • labels: 497307 -->
    • milestone: 148062 -->
    • status: open --> open-accepted
     
  • I have confirmed this is a bug in ATLAS 3.8.3. At least this problem size does *not* trigger an error on 3.9.11. I am moving it to the confirmed bug tracker.

     
    • labels: --> Incorrect answer
    • milestone: --> Both
    • status: open-accepted --> open-fixed
     
  • OK, the fix for this bug is posted at:
    http://math-atlas.sourceforge.net/errata.html#JITB0

    Thank you very much for reporting this bug.

    It has been fixed in both 3.8 and 3.9 basefiles, and so I can close this bug report after the release of 3.9.12.

    Just for my own curiosity, did you find that ATLAS runs faster than some other BLAS (eg., MKL/goto) for the nonsquare cases you are interested in?

    Thanks,
    Clint

     
    • status: open-fixed --> closed-fixed
     
  • 3.9.12 has been released.