OpenBLAS build a DYNAMIC_ARCH, instead of a tuned for the build host …

[truatpasteurdotfr]

avoid having a per cpu generation openblas version:
ref:
https://github.com/xianyi/OpenBLAS/wiki/faq#choose_target_dynamic

example of generated builds:

[centos-easybuild c6/64bits OpenBLAS-0.2.14]$ ll /tmp/OpenBLAS-0.2.14-*/lib/libopenblas*4.a
-rw-r--r--. 1 centos centos 56296988 Oct 14 14:18 /tmp/OpenBLAS-0.2.14-DYNAMIC/lib/libopenblasp-r0.2.14.a
-rw-r--r--. 1 centos centos 25561066 Oct 14 13:58 /tmp/OpenBLAS-0.2.14-NEHALEM/lib/libopenblas_nehalemp-r0.2.14.a
-rw-r--r--. 1 centos centos 25749722 Oct 14 14:05 /tmp/OpenBLAS-0.2.14-SANDYBRIDGE/lib/libopenblas_sandybridgep-r0.2.14.a

these were built with:

make BINARY=64 USE_THREAD=1 CC=gcc FC=gfortran NO_AFFINITY=1 USE_THREAD=1 PREFIX=/tmp/OpenBLAS-0.2.14-NEHALEM TARGET=NEHALEM
make BINARY=64 USE_THREAD=1 CC=gcc FC=gfortran NO_AFFINITY=1 USE_THREAD=1 PREFIX=/tmp/OpenBLAS-0.2.14-SANDYBRIDGE TARGET=SANDYBRIDGE
make BINARY=64 USE_THREAD=1 CC=gcc FC=gfortran NO_AFFINITY=1 USE_THREAD=1 PREFIX=/tmp/OpenBLAS-0.2.14-DYNAMIC DYNAMIC_ARCH=1

[hpcugentbot]

Automatic reply from Jenkins: Can I test this?

[boegel]

Jenkins: ok to test

[boegel]

Does this imply that $OPENBLAS_CORETYPE must be specified at runtime? What if it's not?

From https://github.com/xianyi/OpenBLAS/wiki/faq:

How to choose TARGET manually at runtime when compiled with DYNAMIC_ARCH

The environment variable which control the kernel selection is OPENBLAS_CORETYPE (see driver/others/dynamic.c) e.g. export OPENBLAS_CORETYPE=Haswell. And the function char* openblas_get_corename() returns the used target.

Also, changing an existing easyconfig is probably not a good idea for something like this.

Maybe we should have a separate easyconfig with an added versionsuffix?

[hpcugentbot]

Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/4770/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

[truatpasteurdotfr]

@boegel: +1 for a specific version suffix (maybe one per cpu feature? HASWELL/NEHALEM/... and one DYNAMIC) leaving the people choosing and/swapping the prefered version according to their compute node.

I am not familiar enough with OpenBLAS and so far I have only used ATLAS and build-hosted tuned version.
Nevertheless, imho, openblas does the right thing according to:
https://groups.google.com/forum/#!searchin/openblas-users/dynamic_arch/openblas-users/dqlSef_hmnI/dHZmWiwYJTsJ
and
https://groups.google.com/forum/#!searchin/openblas-users/dynamic_arch/openblas-users/H6CYJ1Di8B8/hWyGkzOHKc0J

[truatpasteurdotfr]

works for me :) I had to mass rebuild eb forcing the default optarch=march=native to optarch=mtune=intel to allow the haswell host build to run on our nehalem/sandy-bridge/haswell compute node

[boegel]

ping?

[truatpasteurdotfr]

It would be nice to have a "generic" version which is able to use any target, at the expense of some storage space -> rpm (fpm packed) version will benefit of being able to run whatever the build host cpu is.

[cfenoy]

Should this be in an EasyBlock? We could have an EasyBlock that sets the DYNAMIC_ARCH=1 if --optarch=GENERIC, or does nothing otherwise.

[boegel]

@cfenoy That makes sense to me.

[migueldiascosta]

@truatpasteurdotfr, this PR is being closed for the following reason(s): no activity for > 1 year.
Please don't hesitate to reopen this PR or add a comment if you feel this contribution is still relevant.
For more information on our policy w.r.t. closing PRs, see https://easybuild.readthedocs.io/en/latest/Contributing.html#why-a-pull-request-may-be-closed-by-a-maintainer

[truatpasteurdotfr]

I just think it would be a nice feature to have, but I am not active enough in the project to push it further. Just do as you wish! Cheers.

[migueldiascosta]

@truatpasteurdotfr this PR was closed as part of a semi-automatic clean up operation, of which one of the goals is precisely to surface the old/stale PRs for which there is still interest, so thank you very much for speaking up

personally, I think there's nothing wrong with using DYNAMIC_ARCH in OpenBLAS (it's similar to what Intel MKL does, and we have no problem with that...), and I have used it myself, but it is only one of the possible site approaches to heterogeneous clusters (see also easybuilders/easybuild#448), typically used where there is only a few and minor architecture variants, since for many and major variants, sites will end up building for each arch for the sake of all the other software that doesn't use dynamic arch...

@cfenoy's suggestion is feasible, as long as sites interested in this approach build OpenBLAS separately with optarch=GENERIC, since that would likely be too harsh, performance wise, for everything else, if set globally. The only alternative I see is to add a new EB option (boolean "dynarch"?) for using dynamic arch when available, and make the OpenBLAS easyblock (and eventually others with similar features?) check that new option...

In either case, there should be no need to change the easyconfigs, we should follow up on this elsewhere...

[boegel]

@migueldiascosta Maybe open a dedicated issue on it?