-
-
Notifications
You must be signed in to change notification settings - Fork 5k
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
RFC: Switch to cython_<lapack,blas>
based wrappers and deprecate custom scipy.linalg.<lapack,blas>
#20682
Comments
cross-ref #4516 |
Just occured to me that we can at least do this for our own internal use and leave the deprecation for later. |
cython_<lapack,blas>
based wrappers and deprecate custom scipy.linalg.<lapack,blas>
cython_<lapack,blas>
based wrappers and deprecate custom scipy.linalg.<lapack,blas>
This proposal isn't very clear to me I'm afraid. We should consider public API we expose separately from what we do internally. For public API:
For SciPy's internal usage:
I don't think so, because of what I wrote above. |
I can do that at some point after Fortran rewrites. It is not the problem. But probably the actual problem is having two copies of OpenBLAS or picking up what we have at compile time. How does Cython set pickup ILP64 if the linked OpenBLAS is 32bit? |
It doesn't, that was my point. Internally we can use ILP64 everywhere when the user builds for that, but the requirements for the Cython API are different.
Yeah, we probably don't want to put that back. That was a really weird construction. We should have a unified build that provides both LP64 and ILP64 symbols. Currently MKL and Accelerate provide that. OpenBLAS could in the future, but not today. |
Ah OK, intel-lingo for 32 bit is LP64, I didn't pay attention. We need to do something about this at some point anyways. I'll try some about it at when I can spare time. |
If you deprecate the F2PY wrappers, would it be possible to expose the Cython ones as Python functions? Something along these lines.. The ability to call BLAS from Python is really nice, especially |
I don't think we will. At least I haven't seen a reason for that yet. Either way, we will only deprecate the current wrappers if a new and improved API for low-level access to BLAS/LAPACK functions is available to switch to. @ilayn I'm all for improving our BLAS/LAPACK wrapping, however it requires some prototyping and a very crisp and concise proposal, after laying out all the constraints that the new situation should meet. This RFC as written should probably be closed, because it is fairly incomplete and as written it cannot be executed, due to the points I raised above. Maybe let's use this one as a discussion thread, and at some point open a new one which is complete? |
If we are going to deprecate wrappers we are not going to remove them without alternatives. The problem with the existing ones are just historical inconsistencies and by quite a lot. There is hardly any consistency of the wrappers and everyone of them feels unique. Some exports m, n array size some hide it and so on many weird stuff as I mentioned above. So we will deprecate when we have a proper alternative which what this issue is about.
That's very unlikely to beat numpy if same optimizations are given at build time to both. |
Not sure what you mean by this. This is an RfC not a PR. And as I am trying to make a case, there are ways to do this including 64 bit Cython wrappers. And there are many open similar discussion as linked above. So what is missing about the RfC, maybe you didn't like it? We just did not choose which way. But I don't agree that backwards compatibility is an issue here because it will be needed at some point because of |
An RFC is usually a detailed proposal about what to do. This is more a "hey let's get rid of the Let's turn this around: what do you actually want as input from other maintainers here? Or what are the next steps? |
Thanks everybody for your clarifications!! I'm glad to hear that BLAS wrappers are going to be kept in the public API, at least in some form. That said, I'd like to push back against the following statement a little:
The multithreading does make a difference! These days, single-core memory bandwidth is often a fraction of the total. This gets worse if there is NUMA. Here is a benchmark on a machine with 2x Intel Xeon 6252N @2.6 GHz. NumPy was compiled with -march=native -mtune=native and BLAS is OpenBLAS from conda-forge:
With Intel Distribution for Python, even np.add is multithreaded. It's a pretty significant boost:
|
Historically, we have gone through many stages of BLAS/LAPACK wrappers. And consequently we have a lot of home-baked wrappers to the formal BLAS/LAPACK routines.
This actually allowed the users to conveniently call native routines through
f2py
glue. While this is very valuable, our way of carrying the historical inconsistencies have been quite high. Just to name a fewuplo='L'
or converted into0
,1
alalower=1
(since bool is not really available).C
injection, sometimes kept in Fortran order.lwork
queries sometimes included as separate public function<routine>_lwork
but sometimes left to user by calling the same routine twice with exposedlwork
keyword set to-1
.I think we can switch to cython based linkage to have more automated wrapper generation and less strain on our testing framework. And also it would make things more straightforward to compile.
On the downside, we let f2py to handle the normalization of arguments and this has to be robust in the cythonized wrappers. Moreover, we will have to make sure that the F-contiguous and
<s,d,c,z>
flavorizing happens properly.We touched upon this many times over the years but let's consolidate the discussions here (last time we mentioned this was I think #13663 (comment))
One particular difficulty is that if we want to solve the historical issues, unfortunately, we have to get rid of all wrappers and offer new ones where the naming would be different. I'm not necessarily a big fan of this but doing this without breaking anybody's current code this seems like the only option. And probably needs more than 2 versions for deprecation cycles.
Hence it would be the case that
scipy.linalg.lapack
andscipy.linalg.blas
gets deprecated goes away and new ones, whatever the name might be will be the new auto-generated submodule names.The text was updated successfully, but these errors were encountered: