-
Notifications
You must be signed in to change notification settings - Fork 129
Change default blas_info dictionary in cmodule #444
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
Conversation
e619f0b
to
d35f4c4
Compare
I've decided to completely change the
|
8702bac
to
97d0bd2
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #444 +/- ##
==========================================
+ Coverage 80.66% 80.74% +0.08%
==========================================
Files 160 160
Lines 46025 46007 -18
Branches 11266 11245 -21
==========================================
+ Hits 37124 37148 +24
+ Misses 6668 6635 -33
+ Partials 2233 2224 -9
|
Seems like the function just moved to |
The |
This is with OSX & accelerate:
|
It’s not surprising that the flags fail to link to accelerate. I could add some platform and processor checks to this to actually only try mkl on Intel and to add the -framework flag on macOS |
I added a check for conda: # Check if in a Conda/Mamba environment
conda_prefix = os.environ.get('CONDA_PREFIX')
if conda_prefix:
# Check for the existence of typical BLAS libraries in the Conda environment
blas_libs_path = os.path.join(conda_prefix, 'lib')
if os.path.exists(os.path.join(blas_libs_path, 'libblas.so')):
return "-lblas"
elif os.path.exists(os.path.join(blas_libs_path, 'libopenblas.so')):
return "-lopenblas"
elif sys.platform == 'darwin' and os.path.exists(os.path.join(blas_libs_path, 'libblas.dylib')):
return "-lblas"
# Add checks for other BLAS libraries as necessary that correctly selects accelerate on my osx. |
To discuss: If we don't support 3.12, maybe we should enforce this here in `pyproject.toml`? Source: <#441 (comment)> I'm not convinced that this is the right move since it might slightly hinder testing. But if we are explicit, then this seems to me like the correct place for it.
@twiecki, can you try again now? The only difference was that I hadn't included the |
@lucianopaz That didn't help/fix the issue. |
It seems we're running into this issue: klee/klee#591 Changing (replacing = with a comma). |
I didn't know that the |
@lucianopaz It now detects blas on OSX with clang. However, it prefers
|
Alternatively, I'm not sure what |
It will on OSX:
|
Have we tested on windows? |
Sorry, I meant to say that I don't think that openblas will ever end up being used as a default. |
Yes, that's what we want and what I was saying here:
|
I’ll test it |
Do you need me to test nothing is changed for linux amd64 users (like me)? |
Sure, the more testing the better. This one could cause quite some disruption if we get it wrong. |
This is what I got before:
And what I get after:
|
Lgtm.
…On Fri, Oct 27, 2023, 12:54 Ricardo Vieira ***@***.***> wrote:
This is what I got before:
-L/home/ricardo/miniconda3/envs/pytensor/lib -lcblas -lblas -lcblas -lblas -Wl,-rpath,/home/ricardo/miniconda3/envs/pytensor/lib
And what I get after:
-L/usr/lib/x86_64-linux-gnu -L/home/ricardo/miniconda3/envs/pytensor/lib -L/usr/lib/gcc/x86_64-linux-gnu/9 -llapack -lblas -lcblas -lm -Wl,-rpath,/home/ricardo/miniconda3/envs/pytensor/lib
—
Reply to this email directly, view it on GitHub
<#444 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFETGDLGB7GXP2SDQHEDLLYBOHHVAVCNFSM6AAAAAA45K26F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBSG4YTAMRSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Actually, I don't think |
That directory came from the compiler default link directories. That means that it is consistent with the env settings and the compiler configuration. Maybe the safest thing is to not include |
I guess conda doesn't provide all libraries and some linking still happens against OS libs? |
@lucianopaz Any thoughts on this? Should we just merge? CC @ricardoV94 |
I'll remove the compiler libs from the -L flags and then I think we can merge |
@ricardoV94, do you want to try this out on your AMD setup and see if the link flags work for you there? |
This is what I get now
vs main:
|
@ricardoV94 that looks perfect to me |
@ricardoV94, LGTM |
Congrats on slaying this dragon @lucianopaz! Time for a new release. |
Closes #441
Motivation for these changes
numpy.__config__.get_info
has been deprecated and removed, so we have to set default link libraries some other way.Implementation details
This is a very rough first implementation. The idea is to use something like python's
sys.path
to look for libraries files (this would match a conda env lib folder and also the system level python lib folders, I still need to figure out what to do with venvs). Then look for some default libraries to link against, like mkl or openblas. I added LAPACK, but maybe the c code that is generated bypytensor
doesn't have the proper includes to be able to link against that.I haven't changed any other code yet, but the long term goal would be to remove most of the blas ldflag logic from the startup. In particular, I flagged a couple of platforms for deprecation (EPD and Canopy, which I think are no longer developed anyway)
Checklist
Major / Breaking Changes
default_blas_ldflags
has changed and might give different default link flags. It no longer looks atnumpy
for blas information, but rather searches some common system paths to try to find BLAS libraries to link against. The order of priorities is 1) MKL, 2) OPENBLAS, 3) LAPACK, 4) BLASNew features
Bugfixes
Documentation
Maintenance