[Bug 1177260] New: Switching python-numpy to plain BLAS causes significant performance regression
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260
Bug ID: 1177260 Summary: Switching python-numpy to plain BLAS causes significant performance regression Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: stefan.bruens@rwth-aachen.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: ---
https://build.opensuse.org/request/show/835366 switched numpy to plain BLAS/LAPACK, which causes a significant performance regression:
--- import numpy as np import time
n = 4000
start_time = time.time() A = np.random.randn(n,n).astype('float64') B = np.random.randn(n,n).astype('float64') print(" init took {} seconds ".format(time.time() - start_time))
start_time = time.time() m = A@B print(" mmult took {} seconds ".format(time.time() - start_time))
print(np.__config__.show()) --- python3-numpy-1.19.1 with openblas: mmult took 2.4579274654388428 seconds python3-numpy-1.19.2 with blas/lapack: mmult took 877.8246397972107 seconds python3-numpy-1.19.2 with openblas: mmult took 2.6917877197265625 seconds
MMult 4000x4000 is 64e9 multiplications and additions, thats ~150kOps/s for BLAS/LAPACK.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260
Stefan Brüns stefan.bruens@rwth-aachen.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eich@suse.com, | |stefan.bruens@rwth-aachen.d | |e
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c1
--- Comment #1 from Stefan Brüns stefan.bruens@rwth-aachen.de --- https://build.opensuse.org/request/show/839356
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c2
Egbert Eich eich@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |eich@suse.com
--- Comment #2 from Egbert Eich eich@suse.com --- The plan behind this change was to get rid of the openblas dependency for Leap/SLE for the non-HPC variant so that that numpy did not pull in openblas for architectures which we do not want to support it on. The HPC variant of numpy still uses openblas. The expectation was that the non-HPC variant of numpy would only be used by other packages which happen require numpy. For TW this could easily be changed, however, SLE and Leap can only be changed together.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c3
--- Comment #3 from Stefan Brüns stefan.bruens@rwth-aachen.de --- I have no problem with using plain BLAS on architectures where openBLAS does not exist (e.g. RISC-V, its vectorization support does not fit openBLAS) or which are so rarely used the extra (theoretical) support burden does not pay off.
The current change, regardless of the performance, causes fragmentation and extra work:
- The HPC builds do not run the test suite, regressions can go in unnoticed - when openBLAS is good enough for HPC, it should be good enough for regular use - Having different code for e.g. Leap/SLE and Tumbleweed doubles the work required when there are bugs specific to either BLAS or openBLAS.
numpy is used as the canonical array format for python bindings of many scientific packages, many of these are not available as HPC modules (and as far as I can see, HPC modules do not exist for Leap). IMHO with this change Leap becomes an unusable toy not meant for scientific work.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c4
--- Comment #4 from Stefan Brüns stefan.bruens@rwth-aachen.de --- Another option would be to finally fix update-alternatives for BLAS/openBLAS. Currently the openBLAS build mangles the soname so update-alternatives does not really work.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c5
--- Comment #5 from Egbert Eich eich@suse.com --- (In reply to Stefan Brüns from comment #3)
I have no problem with using plain BLAS on architectures where openBLAS does not exist (e.g. RISC-V, its vectorization support does not fit openBLAS) or which are so rarely used the extra (theoretical) support burden does not pay off.
The current change, regardless of the performance, causes fragmentation and extra work:
- The HPC builds do not run the test suite, regressions can go in unnoticed
This should be fixed regardless of this issue.
- when openBLAS is good enough for HPC, it should be good enough for regular
use
This had nothing to do with 'good enough'. On SLE it is to keep the support matrix small - especially on platforms I'm less familiar with, like ppc and s390. BLAS has been available on SLE for a long time and is consumed by other packages, so it is there already and will not go away easily. It might be an option to drop it in favor of OpenBLAS, however.
- Having different code for e.g. Leap/SLE and Tumbleweed doubles the work
required when there are bugs specific to either BLAS or openBLAS.
Yes, of course.
numpy is used as the canonical array format for python bindings of many scientific packages, many of these are not available as HPC modules (and as far as I can see, HPC modules do not exist for Leap). IMHO with this change Leap becomes an unusable toy not meant for scientific work.
Yes, this is what I don't want either. Technically, you could use these packages with the HPC version of numpy - by setting the environment accordingly - but this would be awkward.
(In reply to Stefan Brüns from comment #4)
Another option would be to finally fix update-alternatives for BLAS/openBLAS. Currently the openBLAS build mangles the soname so update-alternatives does not really work.
I haven't looked at this, yet, but wouldn't this require for BLAS/OpenBLAS to be ABI compatible? Not sure if this is the case ...
I will revert the change - but this will most likely not happen this week, yet, as I'd like to discuss a couple of things with maintainers beforehand.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c6
--- Comment #6 from Stefan Brüns stefan.bruens@rwth-aachen.de --- (In reply to Egbert Eich from comment #5)
(In reply to Stefan Brüns from comment #3)
I have no problem with using plain BLAS on architectures where openBLAS does not exist (e.g. RISC-V, its vectorization support does not fit openBLAS) or which are so rarely used the extra (theoretical) support burden does not pay off.
The current change, regardless of the performance, causes fragmentation and extra work:
- The HPC builds do not run the test suite, regressions can go in unnoticed
This should be fixed regardless of this issue.
- when openBLAS is good enough for HPC, it should be good enough for regular
use
This had nothing to do with 'good enough'. On SLE it is to keep the support matrix small - especially on platforms I'm less familiar with, like ppc and s390. BLAS has been available on SLE for a long time and is consumed by other packages, so it is there already and will not go away easily. It might be an option to drop it in favor of OpenBLAS, however.
- Having different code for e.g. Leap/SLE and Tumbleweed doubles the work
required when there are bugs specific to either BLAS or openBLAS.
Yes, of course.
numpy is used as the canonical array format for python bindings of many scientific packages, many of these are not available as HPC modules (and as far as I can see, HPC modules do not exist for Leap). IMHO with this change Leap becomes an unusable toy not meant for scientific work.
Yes, this is what I don't want either. Technically, you could use these packages with the HPC version of numpy - by setting the environment accordingly - but this would be awkward.
(In reply to Stefan Brüns from comment #4)
Another option would be to finally fix update-alternatives for BLAS/openBLAS. Currently the openBLAS build mangles the soname so update-alternatives does not really work.
I haven't looked at this, yet, but wouldn't this require for BLAS/OpenBLAS to be ABI compatible? Not sure if this is the case ...
Of course the ABIs are compatible, thats what these libraries are for, dito for ATLAS, Intel MKL and AMD ACML.
I will revert the change - but this will most likely not happen this week, yet, as I'd like to discuss a couple of things with maintainers beforehand.
I have looked into the problem again, the real problem is the missing CBLAS build dependency which causes numpy to use a naive internal implemenation, 'DOUBLE_matmul_inner_noblas' instead of dgemm. This is a compile time decision, i.e. blas libraries are completely(?) disabled.
After adding cblas-devel, it uses the runtime-configured (update-alternatives) library again. With netlib BLAS, the time is down again to ~60 seconds, and when switching top openblas_pthreads0, the previous performance is restored.
Unfortunately, openblas has a lower priority than netlib, so this requires manual configuration:
sudo update-alternatives --config libblas.so.3 There are 2 choices for the alternative libblas.so.3 (providing /usr/lib64/libblas.so.3).
Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib64/blas/libblas.so.3 50 auto mode 1 /usr/lib64/blas/libblas.so.3 50 manual mode 2 /usr/lib64/libopenblas_pthreads.so.0 20 manual mode
Dito for liblapack.so.3
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c7
--- Comment #7 from Egbert Eich eich@suse.com --- (In reply to Stefan Brüns from comment #6)
(In reply to Egbert Eich from comment #5)
(In reply to Stefan Brüns from comment #3)
I have no problem with using plain BLAS on architectures where openBLAS does not exist (e.g. RISC-V, its vectorization support does not fit openBLAS) or which are so rarely used the extra (theoretical) support burden does not pay off.
The current change, regardless of the performance, causes fragmentation and extra work:
- The HPC builds do not run the test suite, regressions can go in unnoticed
This should be fixed regardless of this issue.
- when openBLAS is good enough for HPC, it should be good enough for regular
use
This had nothing to do with 'good enough'. On SLE it is to keep the support matrix small - especially on platforms I'm less familiar with, like ppc and s390. BLAS has been available on SLE for a long time and is consumed by other packages, so it is there already and will not go away easily. It might be an option to drop it in favor of OpenBLAS, however.
- Having different code for e.g. Leap/SLE and Tumbleweed doubles the work
required when there are bugs specific to either BLAS or openBLAS.
Yes, of course.
numpy is used as the canonical array format for python bindings of many scientific packages, many of these are not available as HPC modules (and as far as I can see, HPC modules do not exist for Leap). IMHO with this change Leap becomes an unusable toy not meant for scientific work.
Yes, this is what I don't want either. Technically, you could use these packages with the HPC version of numpy - by setting the environment accordingly - but this would be awkward.
(In reply to Stefan Brüns from comment #4)
Another option would be to finally fix update-alternatives for BLAS/openBLAS. Currently the openBLAS build mangles the soname so update-alternatives does not really work.
I haven't looked at this, yet, but wouldn't this require for BLAS/OpenBLAS to be ABI compatible? Not sure if this is the case ...
Of course the ABIs are compatible, thats what these libraries are for, dito for ATLAS, Intel MKL and AMD ACML.
Right, cublas, ARM's blas libarry etc. I've seen header differences between implementations introducing subtle incompatibilities. This was not with openblas - or anything HPC-releated.
I will revert the change - but this will most likely not happen this week, yet, as I'd like to discuss a couple of things with maintainers beforehand.
I have looked into the problem again, the real problem is the missing CBLAS build dependency which causes numpy to use a naive internal implemenation, 'DOUBLE_matmul_inner_noblas' instead of dgemm. This is a compile time decision, i.e. blas libraries are completely(?) disabled.
Yes, it seems like unless HAVE_CBLAS is set (see numpy/distutils/system_info.py). On SLE, there currently is no CBLAS, so requiring it would mean it would be pulled in instead. Therefore I'd rather see netlib's BLAS replaced by OpenBLAS and dropped - I need to take this up with the person responsible for netlib's BLAS and LAPACK in SLE, though. It looks like numpy still uses BLAS functions in umath_linalg.c - even if CBLAS isn't available.
After adding cblas-devel, it uses the runtime-configured (update-alternatives) library again. With netlib BLAS, the time is down again to ~60 seconds, and when switching top openblas_pthreads0, the previous performance is restored.
Unfortunately, openblas has a lower priority than netlib, so this requires manual configuration:
sudo update-alternatives --config libblas.so.3 There are 2 choices for the alternative libblas.so.3 (providing /usr/lib64/libblas.so.3).
Selection Path Priority Status
- 0 /usr/lib64/blas/libblas.so.3 50 auto mode 1 /usr/lib64/blas/libblas.so.3 50 manual mode 2 /usr/lib64/libopenblas_pthreads.so.0 20 manual mode
Dito for liblapack.so.3
Right. libopenblas is not a provider of libblas.so.3..., libcblas.so.3..., liblapack.so.3... either.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c8
--- Comment #8 from Stefan Brüns stefan.bruens@rwth-aachen.de --- (In reply to Egbert Eich from comment #7)
(In reply to Stefan Brüns from comment #6)
(In reply to Egbert Eich from comment #5)
(In reply to Stefan Brüns from comment #3)
I have no problem with using plain BLAS on architectures where openBLAS does not exist (e.g. RISC-V, its vectorization support does not fit openBLAS) or which are so rarely used the extra (theoretical) support burden does not pay off.
The current change, regardless of the performance, causes fragmentation and extra work:
- The HPC builds do not run the test suite, regressions can go in unnoticed
This should be fixed regardless of this issue.
- when openBLAS is good enough for HPC, it should be good enough for regular
use
This had nothing to do with 'good enough'. On SLE it is to keep the support matrix small - especially on platforms I'm less familiar with, like ppc and s390. BLAS has been available on SLE for a long time and is consumed by other packages, so it is there already and will not go away easily. It might be an option to drop it in favor of OpenBLAS, however.
- Having different code for e.g. Leap/SLE and Tumbleweed doubles the work
required when there are bugs specific to either BLAS or openBLAS.
Yes, of course.
numpy is used as the canonical array format for python bindings of many scientific packages, many of these are not available as HPC modules (and as far as I can see, HPC modules do not exist for Leap). IMHO with this change Leap becomes an unusable toy not meant for scientific work.
Yes, this is what I don't want either. Technically, you could use these packages with the HPC version of numpy - by setting the environment accordingly - but this would be awkward.
(In reply to Stefan Brüns from comment #4)
Another option would be to finally fix update-alternatives for BLAS/openBLAS. Currently the openBLAS build mangles the soname so update-alternatives does not really work.
I haven't looked at this, yet, but wouldn't this require for BLAS/OpenBLAS to be ABI compatible? Not sure if this is the case ...
Of course the ABIs are compatible, thats what these libraries are for, dito for ATLAS, Intel MKL and AMD ACML.
Right, cublas, ARM's blas libarry etc. I've seen header differences between implementations introducing subtle incompatibilities. This was not with openblas
- or anything HPC-releated.
I will revert the change - but this will most likely not happen this week, yet, as I'd like to discuss a couple of things with maintainers beforehand.
I have looked into the problem again, the real problem is the missing CBLAS build dependency which causes numpy to use a naive internal implemenation, 'DOUBLE_matmul_inner_noblas' instead of dgemm. This is a compile time decision, i.e. blas libraries are completely(?) disabled.
Yes, it seems like unless HAVE_CBLAS is set (see numpy/distutils/system_info.py). On SLE, there currently is no CBLAS, so requiring it would mean it would be pulled in instead. Therefore I'd rather see netlib's BLAS replaced by OpenBLAS and dropped - I need to take this up with the person responsible for netlib's BLAS and LAPACK in SLE, though.
1. openBLAS is not available for RISC-V, and likely never will 2. directly linking to openblas_* forfeits the possibility to use a different BLAS/LAPACK implementation. 3. Netlib (c)blas + lapack is ~0.7 + 7 MByte, openblas is ~28 MByte.
It looks like numpy still uses BLAS functions in umath_linalg.c - even if CBLAS isn't available.
After adding cblas-devel, it uses the runtime-configured (update-alternatives) library again. With netlib BLAS, the time is down again to ~60 seconds, and when switching top openblas_pthreads0, the previous performance is restored.
Unfortunately, openblas has a lower priority than netlib, so this requires manual configuration:
sudo update-alternatives --config libblas.so.3 There are 2 choices for the alternative libblas.so.3 (providing /usr/lib64/libblas.so.3).
Selection Path Priority Status
- 0 /usr/lib64/blas/libblas.so.3 50 auto mode 1 /usr/lib64/blas/libblas.so.3 50 manual mode 2 /usr/lib64/libopenblas_pthreads.so.0 20 manual mode
Dito for liblapack.so.3
Right. libopenblas is not a provider of libblas.so.3..., libcblas.so.3..., liblapack.so.3... either.
It does not provide the SONAME, so it is not picked up on the RPM level. The same is true for any other BLAS implementation I am aware of. But thats orthogonal to the question whether it is picked up as a runtime provider using update-alternatives.
As long as some file/symlink named libblas.so.3 is in the runtime linker path (either ld.conf* or LD_LIBRARY_PATH), it will be picked up, even if it is a library with a completely different SONAME and file name.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260
Benjamin Greiner code@bnavigator.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |code@bnavigator.de See Also| |https://bugzilla.opensuse.o | |rg/show_bug.cgi?id=1112768
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c9
--- Comment #9 from Stefan Brüns stefan.bruens@rwth-aachen.de --- (In reply to Stefan Brüns from comment #8)
(In reply to Egbert Eich from comment #7)
(In reply to Stefan Brüns from comment #6)
Yes, it seems like unless HAVE_CBLAS is set (see numpy/distutils/system_info.py). On SLE, there currently is no CBLAS, so requiring it would mean it would be pulled in instead. Therefore I'd rather see netlib's BLAS replaced by OpenBLAS and dropped - I need to take this up with the person responsible for netlib's BLAS and LAPACK in SLE, though.
I have enabled CBLAS building in the lapack package, so missing CBLAS in SLE should no longer be a concern:
https://build.opensuse.org/request/show/840488
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c10
--- Comment #10 from Egbert Eich eich@suse.com --- (In reply to Stefan Brüns from comment #8)
- openBLAS is not available for RISC-V, and likely never will
- directly linking to openblas_* forfeits the possibility to use a
different BLAS/LAPACK implementation. 3. Netlib (c)blas + lapack is ~0.7 + 7 MByte, openblas is ~28 MByte.
Right.
Right. libopenblas is not a provider of libblas.so.3..., libcblas.so.3..., liblapack.so.3... either.
It does not provide the SONAME, so it is not picked up on the RPM level. The same is true for any other BLAS implementation I am aware of. But thats orthogonal to the question whether it is picked up as a runtime provider using update-alternatives.
As long as some file/symlink named libblas.so.3 is in the runtime linker path (either ld.conf* or LD_LIBRARY_PATH), it will be picked up, even if it is a library with a completely different SONAME and file name.
Sure.
Your changes to lapack looked fine. I've sent them on to Factory. I cannot accept your drop request for science/CBLAS, yet, as it is still the devel project for Factory. I've filed a separate drop request for that. The priorities of liblapack, libblas and libcblas from the netlib lapack are higher than for the ones from openblas. Thus, even if openblas is installed, it will not be picked up automatically. Do you prefer it this way?
While looking at this, I've noticed there are no update-alternatives for the lapack C interface. openblas does provide this as well, though. It should probably be added.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c11
--- Comment #11 from Stefan Brüns stefan.bruens@rwth-aachen.de --- (In reply to Egbert Eich from comment #10)
(In reply to Stefan Brüns from comment #8)
Your changes to lapack looked fine. I've sent them on to Factory. I cannot accept your drop request for science/CBLAS, yet, as it is still the devel project for Factory. I've filed a separate drop request for that. The priorities of liblapack, libblas and libcblas from the netlib lapack are higher than for the ones from openblas. Thus, even if openblas is installed, it will not be picked up automatically. Do you prefer it this way?
While looking at this, I've noticed there are no update-alternatives for the lapack C interface. openblas does provide this as well, though. It should probably be added.
LapackE should be covered as well, yes.
Though, the current update-alternatives setup is somewhat problematic IMHO - switching only some parts of the blas implementation does not make sense, and may even lead to strange bugs.
I propose to replace the individual library symlinks with a directory symlink. For each variant, have one '/usr/lib(64)/blas-{netlib,openblas_X,...}/' directory which contains all the blas-related libraries. Then add a /usr/lib(64)/blas-default symlink (managed by ua) pointing to e.g. /usr/lib(64)/blas-openblas_serial/.
/usr/lib(64)/blas-netlib would contain e.g. libblas.so.3,liblapack.so.3,etc as individual libraries (or appropriate symlinks), while /usr/lib(64)/blas-openblas_serial/ would contain libblas.so.3,liblapack.so.3,etc as symlinks all pointing to the libopenblas_serial.so file.
The default would become visible by adding /usr/lib(64)/blas-default/ to /etc/ld.so.conf.
This also makes it easy to override the blas implementation for an individual application, just add e.g. /usr/lib(64)/blas-openblas_pthreads/ to LD_LIBRARY_PATH.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c19
--- Comment #19 from Benjamin Greiner code@bnavigator.de --- Methinks this is related: https://build.opensuse.org/package/show/devel:languages:python:numeric/pytho...
But I am not sure, if jay has a consistently updated system.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c20
--- Comment #20 from Benjamin Greiner code@bnavigator.de --- Eh, I see the changes are still pending. So it's unlikely. Sorry for the noise.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c21
Ismail D�nmez idonmez@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |idonmez@suse.com
--- Comment #21 from Ismail D�nmez idonmez@suse.com --- Stefan, could you have a look at this? Thanks!
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c23
Stefan Br�ns stefan.bruens@rwth-aachen.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(stefan.bruens@rwt | |h-aachen.de) |
--- Comment #23 from Stefan Br�ns stefan.bruens@rwth-aachen.de --- @Is(In reply to Ismail D�nmez from comment #21)
Stefan, could you have a look at this? Thanks!
You declined the SR, so there is nothing to look at.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c24
--- Comment #24 from Egbert Eich eich@suse.com --- @Stefan Br�ns: I've got an update ready for OpenBLAS to 3.20 with a number of fixes on top to hopefully address the conflicts between it and netlib lapack. It's been a tedious task as there were two issues in OpenBLAS upstream that required addressing. I'm still in conversations with the OpenBLAS project. I'll submit it these days. This will hopefully make switching between OpenBLAS's implementation and netlib more easy. The issue that led to the rejection of Numpy is home-made. For my HPC packages I try everything to avoid this.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c25
--- Comment #25 from OBSbugzilla Bot bwiedemann+obsbugzillabot@suse.com --- This is an autogenerated message for OBS integration: This bug (1177260) was mentioned in https://build.opensuse.org/request/show/966357 Factory / openblas
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c28
--- Comment #28 from OBSbugzilla Bot bwiedemann+obsbugzillabot@suse.com --- This is an autogenerated message for OBS integration: This bug (1177260) was mentioned in https://build.opensuse.org/request/show/1062552 Factory / python-numpy
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c30
--- Comment #30 from OBSbugzilla Bot bwiedemann+obsbugzillabot@suse.com --- This is an autogenerated message for OBS integration: This bug (1177260) was mentioned in https://build.opensuse.org/request/show/1063744 Factory / openblas
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c31
--- Comment #31 from Stefan Br�ns stefan.bruens@rwth-aachen.de --- (In reply to Egbert Eich from comment #29)
@Stefan Br�ns: I've finally fixed what you've suggested in comment #4 - all flavors of OpenBLAS use the same SONAME so they can be used as plug-in replacements. You can find this in my home on OBS: home:eeich:branches:science/openblas - this also contains some cleanups. If I don't hear any objections I will submit it and later on push it to Factory.
What hasn't been done, yet, is to combine the lapack[e] & [c]blas libraries to a block as you've suggested in comment #11. This would again require to touch lapack and openblas.
Looks good so far. Unfortunately, the OBS SR notification mail only went to the package maintainer (which has not been involved in openBLAS for quite some time ...).
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c32
--- Comment #32 from Egbert Eich eich@suse.com --- (In reply to Stefan Br�ns from comment #31)
Looks good so far. Unfortunately, the OBS SR notification mail only went to the package maintainer (which has not been involved in openBLAS for quite some time ...).
Thanks for checking! I don't see a package maintainer for openblas, the only listed maintainers are the project maintainers for science - you are one of them. So you should have received a notification if it went out at all. I've been missing several of these as well - or they come in days later.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c33
--- Comment #33 from Stefan Br�ns stefan.bruens@rwth-aachen.de --- (In reply to Egbert Eich from comment #32)
(In reply to Stefan Br�ns from comment #31)
Looks good so far. Unfortunately, the OBS SR notification mail only went to the package maintainer (which has not been involved in openBLAS for quite some time ...).
Thanks for checking! I don't see a package maintainer for openblas, the only listed maintainers are the project maintainers for science - you are one of them. So you should have received a notification if it went out at all. I've been missing several of these as well - or they come in days later.
Dimitry_R was package maintainer, but as he is also maintainer in the science project I saw no reason not to remove him for the package. So, next time there will be a notification hopefully.
http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c34
--- Comment #34 from Egbert Eich eich@suse.com --- (In reply to Stefan Br�ns from comment #33)
Dimitry_R was package maintainer, but as he is also maintainer in the science project I saw no reason not to remove him for the package. So, next time there will be a notification hopefully.
Ah, ok, you had removed him already when I looked. That's fine. I guess I don't put myself in as package maintainer either although I've probably done much more than Dimitry lately - there is no reason as I can do everything I need to.
You had suggested to switch liblapack/lapacke/blas/cblas en-block - this has not been done, yet, but I would suggest to wait until Richi has converged with his work on the netlib-lapack package.
-
bugzilla_noreply＠suse.com