Incorrect results in ZGEMM3M

[antoine-levitt]

I'm getting erroneous results with ZGEMM3M with OpenBLAS. ZGEMM is unaffected. The bug is present with OpenBLAS 0.2.9 and OpenBLAS 0.2.10rc1. It is not present with MKL, ACML or GotoBLAS2 1.13.

I was unfortunately not able to reproduce this with a simpler test case and the way to reproduce it is a bit involved, but I can test patches.

This is with Linux 2.6.18, in single-thread mode, and the CPU is Intel(R) Xeon(R) CPU W3680 @ 3.33GHz.I'm getting erroneous results with ZGEMM3M with OpenBLAS. ZGEMM is unaffected. The bug is present with OpenBLAS 0.2.9 and OpenBLAS 0.2.10rc1. It is not present with MKL, ACML or GotoBLAS2 1.13.

I was unfortunately not able to reproduce this with a simpler test case and the way to reproduce it is a bit involved, but I can test patches.

This is with Linux 2.6.18, in single-thread mode, and the CPU is Intel(R) Xeon(R) CPU W3680 @ 3.33GHz.

[jmbeuken]

little more infos :
OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)
OS … Linux
Architecture … x86_64
BINARY … 64bit
C compiler ... GCC (command line : gcc) -> gcc (GCC) 4.5.4
Fortran compiler ... GFORTRAN (command line : gfortran)
Library Name ... libopenblas_nehalemp-r0.2.10.rc1.a (Multi threaded; Max num-threads is 6)

[wernsaar]

On 01.07.2014 13:44, Jean-Michel Beuken wrote:

more infos :
OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)
OS … Linux
Architecture … x86_64
BINARY … 64bit
C compiler ... GCC (command line : gcc) -> gcc (GCC) 4.5.4
Fortran compiler ... GFORTRAN (command line : gfortran)
Library Name ... libopenblas_nehalemp-r0.2.10.rc1.a (Multi threaded; Max num-threads is 6)

---

Reply to this email directly or view it on GitHub:
#400 (comment)
Hi,

I would like remove the *3M from OpenBLAS.

1. Modern processors can do a lot of multiply/add instructions
   in parallel, so I think that the *3M functions are obsolete.
2. In refblas, there are no *3M functions, so I cannot simply
   check for correct results.

Best regards

Werner

[antoine-levitt]

I don't really know much about these things, but MKL does give a performance improvement with 3M functions, at least with large matrices. Can't you check correctness with ZGEMM? The error I'm seing is not an error of 1e-16 that might be imputable to machine precision, it's completely wrong results.

Anyway, no ZGEMM3M is better than a broken one (right now we ship our software with a configure script that checks for the presence of ZGEMM3M and uses it if available, so it fails with openblas).

[wernsaar]

On 01.07.2014 14:52, Antoine Levitt wrote:

I don't really know much about these things, but MKL does give a performance improvement with 3M functions, at least with large matrices. Can't you check correctness with ZGEMM? The error I'm seing is not an error of 1e-16 that might be imputable to machine precision, it's completely wrong results.

Anyway, no ZGEMM3M is better than a broken one (right now we ship our software with a configure script that checks for the presence of ZGEMM3M and uses it if available, so it fails with openblas).

---

Reply to this email directly or view it on GitHub:
#400 (comment)
Hi,

OK. I will fix this issue. But this will take some days.

Best regards

Werner

[wernsaar]

@antoine-levitt : I disabled the *3M functions for x86_64. Please use my development fork
https://github.com/wernsaar/OpenBLAS.git for testing.

Regards
Werner

[xianyi]

@wernsaar , I reopened this issue, which looks like a bug.

[wernsaar]

@xianyi , I will test and try to enable the *3M at a later time, but this is a task with low priority. First I will work for a very stable and bugfree next release.

Best regards
Werner

[antoine-levitt]

Hi,

If I understand correctly, ZGEMM3M is still present in the current version. Please either disable it, or fix it, so we can change our configure script not to use ZGEMM3M with OpenBLAS below a certain version number. I understand ZGEMM3M functionality is low-priority, but shipping a library that gives incorrect results should not be an option, given how annoying it is for users.

[wernsaar]

On 15.07.2014 09:29, Antoine Levitt wrote:

Hi,

If I understand correctly, ZGEMM3M is still present in the current version. Please either disable it, or fix it, so we can change our configure script not to use ZGEMM3M with OpenBLAS below a certain version number. I understand ZGEMM3M functionality is low-priority, but shipping a library that gives incorrect results should not be an option, given how annoying it is for users.

---

Reply to this email directly or view it on GitHub:
#400 (comment)
Hi,

the fortran and cblas-interfaces are disabled, so you cannot use the
functions
zgemm3m_ or clas_zgemm3m.

Regards
Werner

[antoine-levitt]

Hi,

Oh, I didn't see that, sorry. Thanks! Please update this tracker if/when you fix the bug, so we can try the new version.

Best,
Antoine