Bug in zgemm on AMD #380
Comments
|
The problem is also present for |
|
On 03.06.2014 20:20, Andreas Noack Jensen wrote:
I cannot reproduce this error. Is this a 32bit or 64bit build, what is the TARGET, do you use threading? Regards Werner |
|
We have only seen it on the reported architecture. It is a 64 bit build and the bug is there both with and without threading. @tkelman Can you say more about the TARGET? |
|
I think TARGET is empty. The set of Makefile flags, as best as I can reconstruct them, are:
|
|
On 04.06.2014 14:50, Tony Kelman wrote:
could you please compile with the following comand line: FFLAGS=-O2 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=16 NO_AFFINITY=1 TARGET=PILEDRIVER INTERFACE64=1 BINARY=64 Which C- and Fortran compiler do you use? Regards Werner |
|
On 04.06.2014 14:50, Tony Kelman wrote:
I simply cannot reproduce the error. The file Makefile.rule is included. Best regards Werner |
|
I used GCC and Gfortran 4.8.2, MinGW cross-compiled either from Linux (Julia binaries) or Cygwin (my build of up-to-date develop branch) to compile OpenBLAS. The user who's seeing the issue was compiling the test program with |
|
On 04.06.2014 16:25, Tony Kelman wrote:
please try the binary, that I have now published at sourceforge.net. and report the result. Best regards Werner |
|
cc @jasax |
|
@wernsaar Which Fortran compiler and what version do you use? |
|
On 05.06.2014 19:48, Viral B. Shah wrote:
I built openblas for windows on our Ubuntu machine with mingw64. Best regards Werner |
|
Best to reopen the issue. |
|
I just fixed a bug about generating DLL. I think this is a different bug. |
|
Hi, @ViralBShah Type: Please send me the result of the command: Regards Werner |
|
Hi, Which openblas.dll do you want me to use with the gdb test? I have the
Please tell me. Meanwhile I'll try the latest. Best On 6/6/14, Viral B. Shah notifications@github.com wrote:
|
|
On 06.06.2014 18:25, jasax wrote:
please use the dll from this download: I want to know, which zgemm_kernel is used. Regards Werner |
|
Hi, Sorry, I now see I have certainly missed the test programs (thought it So, which is the test program? Do I have to compile openblas source Thx Jose On 6/6/14, wernsaar notifications@github.com wrote:
|
|
On 06.06.2014 19:31, jasax wrote:
please use the short fortran program for the test. Regards, Werner |
|
Hi Werner, I was out for weekend, only now I am working in the amd 8320 8-core PC I really don't understand the instructions, sorry, regarding the So I must be doing something wrong. Please see if you can detect the Regards On 6/7/14, wernsaar notifications@github.com wrote:
|
|
Hi Werner, Perhaps I'm being a bit stupid and this is what you want :-) Please see if this is what is intended. Regards Jose ############################# $ gdb a.exe Breakpoint 1, test () at test.f90:12 ############################# On 6/7/14, wernsaar notifications@github.com wrote:
|
|
On 09.06.2014 16:08, jasax wrote:
level3.c is the single threaded mid-level function for gemm. Best regards Werner |
|
Hi Werner, Sorry, I've been looking how to not use threads in gdb, and could not So, do I have to recompile test.f90 without threads (and what compiler Thx, and sorry for my ignorance of these matters :-) Jose On 6/9/14, wernsaar notifications@github.com wrote:
|
|
On 09.06.2014 17:16, jasax wrote:
in Linux, I simply type export OMP_NUM_THREADS=1 before starting gdb. Regards Werner |
|
Hi, The mingw shell is (or should be...) similar to a bash shell in Linux, Regards Jose On 6/9/14, wernsaar notifications@github.com wrote:
|
|
I thought that Piledriver kernels fallback to Bulldozer - is that right? If so, does that mean that the bug could potentially exist on Bulldozer too? |
|
Hi, I have the compilation log (below) but warnings and errors are still Now the failure happens when exporting (lots of) symbols in gfortran Any help appreciated... Regards Jose .................................................................................. ar -ru ../../libopenblas_piledriverp-r0.2.9.a strtri_UU_single.obj ................................. ########################## ................................................ trtri_L_parallel.c: In function 'ztrtri_LN_parallel': JAugusto@THOR /e/Compiled/OpenBLAS-develop JAugusto@THOR /e/Compiled/OpenBLAS-develop JAugusto@THOR /e/Compiled/OpenBLAS-develop ........................................................................... Cannot export zunmr3_: symbol not defined JAugusto@THOR /e/Compiled/OpenBLAS-develop On 6/11/14, Viral B. Shah notifications@github.com wrote:
|
|
@jasax it seems like your MinGW installation has trouble with Fortran? Weren't you able to compile the Fortran test examples earlier? Regardless, I built a debug version of OpenBLAS v0.2.9 using Julia's make flags and uploaded it here: http://sourceforge.net/projects/juliadeps-win/files/openblas-v0.2.9-x86_64-w64-mingw32-debug.7z/download Do you see the problem with that binary, and if so please try the gdb steps discussed earlier. |
|
Hi, I wrote 2 enhancements for dynamic_arch:
Example: OPENBLAS_VERBOSE=2 ./dlinpack.goto 1000 1000 1
Example: OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=barcelona ./dlinpack.goto 1000 1000 1 OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=opteron ./dlinpack.goto 1000 1000 1 The name of the coretype is not case sensitive. To test this, you can checkout my fork at github: Best regards Werner |
|
Hi, I compiled the fortran small examplewith no problem. But all the sources is other kind of animal ;-) Perhaps the errors Do you know if someone is compiling OpenBLAS regularly from sources But I already saw it was made available a tarball with a recompilation Regards On 6/12/14, Tony Kelman notifications@github.com wrote:
|
|
Yeah we're building openblas very regularly in msys2 with msys-gmake, and cygwin-to-mingw cross-compile with cygwin-gmake. I suspect mingw-make can't handle the openblas Makefiles properly. Also the mingw-w64 distribution you're using (tdm) is one I've used on other projects, but not with openblas and julia. |
|
Hi Werner, Toni, Finally I had a few time to test the libopenblas with debug at my work Here goes the output of info all-register inside zgemm... etc. I tried to set number of threads=1 (as you told) but 2 are launched Please give more instructions :-) Regards Jose JAugusto@THOR ~ JAugusto@THOR /c/Users/JAugusto/Dropbox/Julia/OPenBLAS_Tests JAugusto@THOR /c/Users/JAugusto/Dropbox/Julia/OPenBLAS_Tests Breakpoint 1, zgemm_nn (args=0x22f7a0, range_m=0x0, range_n=0x0, On 6/13/14, Jose Augusto jasaugusto@gmail.com wrote:
|
|
On 16.06.2014 22:19, jasax wrote:
thank you for the debug output, Regards |
|
Hi, Regards |
|
I lowered the stack usage for gemm kernels. Thanks |
|
Thanks Werner. Building from your develop branch now, will post a binary in the Julia issue so the users who were having this problem can test. |
|
Oh, and here are the 2 files you requested, but from a build of your latest commit 23203d5, building on my Sandy Bridge machine (which does not exhibit the bug), with DYNAMIC_ARCH enabled so we will test on a few Haswell machines to see whether the bug occurs |
|
On 19.06.2014 19:58, Tony Kelman wrote:
on SANDYBRIGE machines, a local stack is not used for gemm kernels, but Best regards Werner |
|
Not sure about AMD yet, but one of the Haswell users (i7-4700MQ) is still seeing incorrect results unless he sets |
|
On 19.06.2014 21:02, Tony Kelman wrote:
Is it possible, that I can have remote access to a test machine, to debug Best regards Werner |
|
Yes, Windows 8 x86_64 was the Haswell user running into problems. I just asked him about the possibility of remote debugging in the Julia issue. My lab got a new Windows Haswell machine recently, I haven't had a chance to test out OpenBLAS on it yet, but should be able to borrow it starting sometime next week. |
|
Hi, this evening, I got another idea. Do you also get wrong results by setting Best Regards Werner |
|
Hi Werner, let's leave this issue for discussing the AMD problem, and use #392 for the Haswell one |
|
a lot of bugs if compiling for Windows are fixed. So I close this issue |
|
Can you make a 0.2.10 release candidate release with these fixes, so that we can try it out? |
|
Hi @ViralBShah , |
|
Thank you very much. I have updated julia to use 0.2.10.rc1 and will keep you posted as we verify everything. |
On a AMD FX(tm)-8320 Eight-Core Processor machine running Windows and with OpenBLAS complied with 64 bit integer support the following program
gives the wrong answer
The text was updated successfully, but these errors were encountered: