Re: RFC: building numpy against OpenBLAS.
Mark H Weaver m...@netris.org skribis: So, I come again to the same conclusion: that we should switch to OpenBLAS on _all_ platforms, and strip away the ATLAS-handling code in our python-numpy package. We can work on fixing OpenBLAS to MIPS later. Agreed, we can’t afford not to have substitutes for things like LibreOffice. Mark or Ricardo, can you push the patch? Thanks! Ludo’.
Re: RFC: building numpy against OpenBLAS.
Ricardo Wurmus ricardo.wur...@mdc-berlin.de writes: Ricardo Wurmus writes: python-numpy currently depends on Atlas, which means that it cannot be substituted with a binary built elsewhere. OpenBLAS is an alternative to Atlas and the binary can be used on all supported CPUs at runtime. This makes it possible for us to make numpy substitutable. We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. Yes, please do! Thanks, Mark
Re: RFC: building numpy against OpenBLAS.
Ricardo Wurmus ricardo.wur...@mdc-berlin.de writes: Ricardo Wurmus writes: python-numpy currently depends on Atlas, which means that it cannot be substituted with a binary built elsewhere. OpenBLAS is an alternative to Atlas and the binary can be used on all supported CPUs at runtime. This makes it possible for us to make numpy substitutable. We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. I think we should go ahead and switch to OpenBLAS on _all_ platforms, not just on MIPS. Were there any objections to that? If not, I'd advocate just doing it. Thanks! Mark
Re: RFC: building numpy against OpenBLAS.
Ricardo Wurmus ricardo.wur...@mdc-berlin.de writes: We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. I think we should go ahead and switch to OpenBLAS on _all_ platforms, not just on MIPS. Were there any objections to that? If not, I'd advocate just doing it. There may have been a misunderstanding: We can switch to OpenBLAS for all platforms _except_ MIPS because OpenBLAS currently does not build on MIPS. I was indeed confused. However, it seems that ATLAS doesn't build on MIPS either, based on its 'supported-systems' field. So, I come again to the same conclusion: that we should switch to OpenBLAS on _all_ platforms, and strip away the ATLAS-handling code in our python-numpy package. We can work on fixing OpenBLAS to MIPS later. What do you think? Thanks! Mark
Re: RFC: building numpy against OpenBLAS.
Mark H Weaver m...@netris.org writes: Ricardo Wurmus ricardo.wur...@mdc-berlin.de writes: Ricardo Wurmus writes: python-numpy currently depends on Atlas, which means that it cannot be substituted with a binary built elsewhere. OpenBLAS is an alternative to Atlas and the binary can be used on all supported CPUs at runtime. This makes it possible for us to make numpy substitutable. We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. I think we should go ahead and switch to OpenBLAS on _all_ platforms, not just on MIPS. Were there any objections to that? If not, I'd advocate just doing it. Libreoffice depends on python2-numpy, so if we don't switch to OpenBLAS on all platforms, then we cannot offer binary substitutes for Libreoffice. Also, the persistent build failures of python-numpy on Hydra are probably due to its use of ATLAS, when ALTAS is built on a different build slave than python2-numpy. So, at this point we have several strong incentives to phase out the use of ATLAS. Mark
Re: RFC: building numpy against OpenBLAS.
We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. I think we should go ahead and switch to OpenBLAS on _all_ platforms, not just on MIPS. Were there any objections to that? If not, I'd advocate just doing it. There may have been a misunderstanding: We can switch to OpenBLAS for all platforms _except_ MIPS because OpenBLAS currently does not build on MIPS. ~~ Ricardo
Re: RFC: building numpy against OpenBLAS.
Ricardo Wurmus writes: python-numpy currently depends on Atlas, which means that it cannot be substituted with a binary built elsewhere. OpenBLAS is an alternative to Atlas and the binary can be used on all supported CPUs at runtime. This makes it possible for us to make numpy substitutable. We currently do not have a working OpenBLAS on MIPS, so the attached patch selects OpenBLAS as an input only when not on MIPS. Some additional configuration happens only unless atlas is among the inputs. If there are no objections I'd like to go ahead and push this patch to build numpy with OpenBLAS. From the comments I gather that it's not as controversial a change as I suspected. ~~ Ricardo
Re: RFC: building numpy against OpenBLAS.
On Wed, May 27, 2015 at 5:50 PM, Ricardo Wurmus ricardo.wur...@mdc-berlin.de wrote: Federico Beffa writes: Out of curiosity, could you outline how OpenBLAS is optimized for a specific CPU architecture while being compiled on a different CPU (and hence allowing to be substituted)? The Quick Install instructions[1] say that when OpenBLAS is compiled with DYNAMIC_ARCH=1 All kernel will be included in the library and dynamically switched the best architecutre at run time. It seems that unlike ATLAS, OpenBLAS does not perform any self-tuning but relies on hand-optimised code (e.g. by using CPU-specific instructions). Sounds good. Thanks! Fede
Re: RFC: building numpy against OpenBLAS.
- Ricardo Wurmus ricardo.wur...@mdc-berlin.de wrote: python-numpy currently depends on Atlas, which means that it cannot be substituted with a binary built elsewhere. OpenBLAS is an alternative to Atlas and the binary can be used on all supported CPUs at runtime. This makes it possible for us to make numpy substitutable. [...] Anyway, I just wanted to post this here to ask for opinions. Maybe this is a bad idea. (In my case it makes sense not to use Atlas, because the compile-time tuning is useless when a shared store is used and clients use Atlas on machines other than the build host.) I would very much like to see OpenBLAS substituted for atlas whereever possible. The runtime performance of OpenBLAS is quite a bit better than ATLAS. I've seen e.g. OpenBLAS to be roughly 20% faster than ATLAS for GEMM calls on Sandybridge platforms. `~Eric
