CI: build with OpenBLAS #4
Conversation
Use the OpenBLAS DLL generated from gfortran. See numpy/numpy#9645 for more information.
appveyor.yml
Outdated
| @@ -20,7 +20,6 @@ environment: | |||
| TEST_MODE: fast | |||
| APPVEYOR_SAVE_CACHE_ON_ERROR: true | |||
| APPVEYOR_SKIP_FINALIZE_ON_EXIT: true | |||
| BUILD_COMMIT: v1.13.0rc2 | |||
There was a problem hiding this comment.
Why are you removing that?
There was a problem hiding this comment.
It's not removed; it's down below (from merge conflicts). I can reset it if you want.
|
@charris Ping. |
|
Restarted the stalled test. There is one warning issued during the tests, I'm not sure it is relevant |
|
The use of mingw and cygwin could use some explanation. You could add an explanatory section at the beginning explaining in outline how things are done. Are both mingw and cygwin guaranteed to be available? @matthew-brett @pv Thoughts? |
|
It's essentially the same procedure we use for Scipy. Note that Cygwin is not used (the commands only clear up pip cache). |
|
OK, let's give this a shot. @matthew-brett Do you know if the problem with OpenBLAS Cholesky on 32 bit windows is fixed? |
|
Thanks @xoviat . |
|
The openblas binaries used here are compiled with vanilla mingw-w64, not mingwpy, and do not have the issue with cholesky. |
Good to know, thanks for the info. |
|
Does that mean that they mess with the fp status word? Do they rely on
that? We've seen weird issues before either because loading a mingw-w64 dll
causes extended precision to be enabled for other routines that weren't
expecting it, or else that the mingw-w64 routines misbehave when called
from a thread, because the thread doesn't have extended precision enabled.
(Sorry if this is way off base.)
…On Nov 5, 2017 08:28, "Pauli Virtanen" ***@***.***> wrote:
The openblas binaries used here are compiled with vanilla mingw-w64, not
mingwpy, and do not have the issue with cholesky.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlOaDLNSdf03ondeylm3Bu5czj-dbcAks5szeItgaJpZM4QDT0m>
.
|
|
I have not seen mingw change the fpu mode. I have seen MSVC change the fpu mode on 32 bits. |
|
Also, to clarify, when I say "mingw," I am never talking about mingw.org. |
|
mingw definitely changes the fpu mode to enable "extended" precision by
default; the windows standard is to use only double precision.
…On Nov 5, 2017 09:42, "xoviat" ***@***.***> wrote:
I have not seen mingw change the fpu mode. I *have* seen MSVC change the
fpu mode on 32 bits.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlOaAnm30geWKuyfFkwERnAHVeTZDy1ks5szfOdgaJpZM4QDT0m>
.
|
|
All I know is that numpy is built with this exact configuration and there are no FPU mode changes found by numpy/numpy#9574. That suggests to me that MinGW does not change the FPU mode, at least in this case. |
|
That test doesn't do anything until after numpy is imported, at which point
it has already changed the fpu mode.
…On Nov 5, 2017 09:52, "xoviat" ***@***.***> wrote:
All I know is that numpy is built with this exact configuration and there
are no FPU mode changes found by numpy/numpy#9574
<numpy/numpy#9574>. That suggests to me that
MinGW does not change the FPU mode, at least in this case.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlOaDZmBA-eNVKelkw9BX6QzTiWnzU5ks5szfXsgaJpZM4QDT0m>
.
|
|
Assuming that the FPU mode is changed, the question is what to do about it. For Python >= 3.5, I think I'll have an OpenBLAS ready that doesn't use MinGW, but is fully compatible with the CRT that can go into the next numpy release. For older Pythons, the options (that I can think of) are:
One option that I would not recommend is switching back to mingwpy, as the project has been abandoned. |
|
I don't think this results to fpu mode changes on import, at least based on a quick check. |
Closes #3.