Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenBLAS/0.3.7-GCC-8.3.0 with optarch=GENERIC builds with avx512. #9754

Open
terjekv opened this issue Jan 21, 2020 · 5 comments
Open

OpenBLAS/0.3.7-GCC-8.3.0 with optarch=GENERIC builds with avx512. #9754

terjekv opened this issue Jan 21, 2020 · 5 comments
Milestone

Comments

@terjekv
Copy link
Collaborator

terjekv commented Jan 21, 2020

OpenBLAS/0.3.7-GCC-8.3.0 built with optarch=GENERIC returns an illegal instruction when used via R on an i5 without avx512. OpenBLAS/0.3.5-GCC-8.2.0-2.31.1 does not suffer from this issue.

Interesting feature here, these are all built on the same host with the same optarch=GENERIC:

$ pwd; ls -1 */lib/
/opt/uio/modules/rhel8/easybuild/software/OpenBLAS
0.3.1-GCC-7.3.0-2.30/lib/:
cmake
libopenblas.a
libopenblas_haswellp-r0.3.1.a
libopenblas_haswellp-r0.3.1.so
libopenblas.so
libopenblas.so.0
pkgconfig

0.3.5-GCC-8.2.0-2.31.1/lib/:
cmake
libopenblas.a
libopenblas_haswellp-r0.3.5.a
libopenblas_haswellp-r0.3.5.so
libopenblas.so
libopenblas.so.0
pkgconfig

0.3.7-GCC-8.3.0/lib/:
cmake
libopenblas.a
libopenblas_skylakexp-r0.3.7.a
libopenblas_skylakexp-r0.3.7.so
libopenblas.so
libopenblas.so.0
pkgconfig
@terjekv
Copy link
Collaborator Author

terjekv commented Jan 21, 2020

When built on the i5 itself, 0.3.7-GCC-8.3.0 produces libopenblas_haswellp-r0.3.7.so as expected.

@boegel boegel added this to the 4.x milestone Feb 5, 2020
@terjekv
Copy link
Collaborator Author

terjekv commented Feb 5, 2020

Well, I found out why. OpenBLAS with EasyBuild never supported optarch. And it's documented as a special case: https://easybuild.readthedocs.io/en/latest/Controlling_compiler_optimization_flags.html#caveats

For example, the OpenBLAS build system will autodetect the processor architecture in the build host, and will optimize for that processor architecture by default.

If you want a generic OpenBLAS build you will need to tweak the OpenBLAS easyconfig file to define the desired TARGET to use. For this you will need to modify the buildopts easyconfig parameter, for example:

buildopts = 'TARGET=PRESCOTT BINARY=64 ' + threading + ' CC="$CC" FC="$F77"'

I might have to see if there is a way to resolve this somehow in the OpenBLAS EasyBlock, so at least the optarch is adhered to.

@boegel
Copy link
Member

boegel commented Feb 5, 2020

This can probably be fixed in the easyblock, indeed. I think the documentation dates from before we had a custom easyblock for OpenBLAS (when we were still using ConfigureMake).

@BerndDoser
Copy link

Same behavior with OpenBLAS-0.3.9-GCC-9.3.0.eb. Using --optarch=march=skylake compiles with both flags -march=skylake -march=skylake-avx512. Is there a workaround?

@terjekv
Copy link
Collaborator Author

terjekv commented Jul 28, 2020

@BerndDoser There is no workaround directly in EasyBuild right now. I have not had time to look at this in a long while, sorry. There is an old WIP here easybuilders/easybuild-easyblocks#1946 that requires a bit of work right now. As such, the options are basically:

  1. Build OpenBLAS on a node with the desired architecture, or
  2. manually edit https://github.com/easybuilders/easybuild-easyblocks/blob/develop/easybuild/easyblocks/o/openblas.py to ensure that TARGET is set to an appropriate arch based on TargetList.txt in the OpenBLAS source.

I really should sit down and work on that PR. Sorry. :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants