Regression with current pre-0.2.9 git and the elk code

[martin-frbg]

Just a quick heads up - I will try to pinpoint the problem if possible later:
Using the ELK "computational chemistry" code from elk.sourceforge.net I see lots of failures in the test problems distributed with the code when I build it against the current git version of openBLAS optimized for either Haswell or Sandybridge.
Using 0.2.8 built for Sandybridge, all is well on this i7-4770 (though openblas gives no measurable speedup on these small problems).
To reproduce:

1. get elk-2.2.10.tgz from sourceforge
2. unpack it and run the included "setup" script to create make.inc
3. in make.inc, specify the openblas library instead of the included lapack&blas
4. run make, and then "make test"
5. With 0.2.8, all 17 tests pass within a total runtime of around 155 seconds, with
   0.2.9, runtime is more than doubled (due to the test cases failing to converge)
   and most tests report failure.
   One hint: in test-002, valgrind emits lots of "use of uninitialized value" warnings in calls to dgemv_t, dgemm_kernel, zscal_k etc.

[xianyi]

@wernsaar , could you look at this issue?
Thank you

[wernsaar]

On 15.12.2013 23:36, martin-frbg wrote:

Just a quick heads up - I will try to pinpoint the problem if possible later:
Using the ELK "computational chemistry" code from elk.sourceforge.net I see lots of failures in the test problems distributed with the code when I build it against the current git version of openBLAS optimized for either Haswell or Sandybridge.
Using 0.2.8 built for Sandybridge, all is well on this i7-4770 (though openblas gives no measurable speedup on these small problems).
To reproduce:

1. get elk-2.2.10.tgz from sourceforge
2. unpack it and run the included "setup" script to create make.inc
3. in make.inc, specify the openblas library instead of the included lapack&blas
4. run make, and then "make test"
5. With 0.2.8, all 17 tests pass within a total runtime of around 155 seconds, with
   0.2.9, runtime is more than doubled (due to the test cases failing to converge)
   and most tests report failure.
   One hint: in test-002, valgrind emits lots of "use of uninitialized value" warnings in calls to dgemv_t, dgemm_kernel, zscal_k etc.

---

Reply to this email directly or view it on GitHub:
#329
Hi,

if you want to build for haswell, piledriver or bulldozer, you need
recent versions for gcc and binutils, and yuo need valgrind-3.9.0
or newer

Werner

[martin-frbg]

Build system in question is opensuse 12.3, so fairly recent (binutils-2.23, gcc472, using gcc482 does not solve the problem). Will do further analysis with valgrind 3.9 instead of the 3.8.1 used for the above. Please note that a sandybridge build of 0.2.8 works without errors, while 0.2.9 sandybridge is unusable on the same system.

[martin-frbg]

Just for the record, updating binutils to 2.24 did not change anything. (Neither did updating valgrind change anything
fundamental about the slew of warnings - but I do have to concede that it generates a similar (high) number of complaints for 0.2.8 although that one manages to yield the correct results).

[martin-frbg]

Finally got around to taking another look - it turned out the problem with 0.2.9-rc1 is specific to openmp: When Elk is compiled without the "-fopenmp" from its default make.inc settings, all its tests pass on Haswell with 0.2.9-rc1. Conversely, a -fopenmp build linked against 0.2.9-rc1 fails even on nehalem architecture, where 0.2.8 works well (provided that it was built with USE_THREAD=0, USE_OPENMP=1)

[martin-frbg]

The problem apparently was introduced well before the Haswell branch was merged. Bisecting now.

[martin-frbg]

dfd1064 is the first bad commit
commit dfd1064
Author: Zhang Xianyi [email protected]
Date: Sat Nov 2 15:09:33 2013 +0800

refs #287. Don't enable OpenMP for netlib LAPACK sequential Fortran codes.

[martin-frbg]

Have confirmed now that removing the distinction between F(P)FLAGS and LAPACK_F(P)FLAGS introduced by the above change to Makefile.system fixes my problem also in current git head.

[xianyi]

@martin-frbg ， Thank you for the investigation.

I added dfd1064 to fix the SEGFAULT with OpenMP on Windows.

[martin-frbg]

Yes, I saw that but it was not clear to me if that was a real fix, and not just papering over a different problem.
If "SEGFAULT on Windows" trumps "wrong result on (at least) Linux", can the change be made "#ifdef WINDOWS"
please ?

[xianyi]

Please try develop branch.
Thank you again.

[martin-frbg]

Thank you. (Might it make sense to revisit #287 now that 0.2.9 contains a newer LAPACK ?)

[martin-frbg]

Will see if I can get openblas&elk built on a windows/mingw system in the near future for additional insight.