Remove strict requirement of MKL so that M1 chips are supported natively

[elbamos]

If you have questions about a specific use case, or you are not sure whether this is a bug or not, please post it to our discourse channel: https://discourse.pymc.io

Description of your problem

% mamba install pymc3=3.11
Encountered problems while solving:
  - nothing provides mkl-service needed by pymc3-3.11.0-pyhd8ed1ab_0

Note that earlier versions of pymc3 fail to install because they depend on theano or theano-pymc, which aren't available in M1 builds, rather than aesara.

It appears from here: 2edbe6c that mkl-service was added to quash a theano warning. Is mkl-service still really necessary with aesara?

[OriolAbril]

pymc3 3.11 still uses theano-pymc, not sure if it helps, but Aesara will be used from 4.0 onwards only.

[twiecki]

@OriolAbril I don't think that will help, aesara still is much faster with mkl.

@elbamos Isn't there a compatibility mode? @fonnesbeck talks about it working well.

[fonnesbeck]

Currently, you won't be able to run this natively. It will have to be under Rosetta2.

[elbamos]

@twiecki It can run under Rosetta2, although if you're also running native python, its a real chore. Pymc is the last tool in my toolbox that still needs to run under compatibility mode. I had hoped this was a conda dependencies issue that could be resolved to permit native operation, but I suppose the answer is that it is not.

[elbamos]

Actually, I take that back.

I was able to get the current version of pymc3 (installed from git, reporting v3.11.1) running natively on M1, simply by changing two references to aesana.tensor.nnet.sigmoid to point to aesana.tensor.sigmoid.

I'm guessing the naming issue is really that what's currently up on the git references a different version of aesana than what's found on conda-forge.

Am I missing something? It really seems that mkl-service doesn't need to be a requirement, and if its dropped, then this can run natively as is.

If someone proposes a benchmark to show the performance implication, I'm happy to run it.

[elbamos]

If anyone wants to try it (@fonnesbeck ?), I've pushed to branch m1 in a fork, and am debating whether to make a PR: https://github.com/elbamos/pymc3/tree/m1

This works with the version of aesana available on conda-forge.

[twiecki]

Revisiting this issue. It seems like indeed we should remove the strict MKL requirement now that M1 exists. Ideally we'd find a way to tell conda to use MKL if it's available but fall back to OpenBLAS if it doesn't.

[twiecki]

@elbamos Want to do a PR?

[twiecki]

https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/#how-to-add-a-osx-arm64-build-to-a-feedstock

[twiecki]

Digging a bit deeper:
I think we should drop the mkl-services dependency. PyMC3 itself does not depend on libblas (like MKL), only aesara does, so it should be on aesara to specify that dependency.

Moreover, we prohibit the use of other libblas implementations which is causing this problem here.

The reason we did is that by default conda install pymc3 pulls in openblas which is much slower than mkl. Instead, however, we should change our installation instructions to say conda install pymc3 libblas=*=*mkl to get the right backend if you need it, but do not prohibit installation on M1.

[elbamos]

@twiecki I think you’re exactly right. My recollection of when I tried to do this to support a pr (which is now way out of date behind master) is that the only required change was dropping mkl-service from the requirements and an install script.

[elbamos]

@twiecki Hey it looks like you've had pr's open for a couple of weeks. Is there anything I can do to help you get this merged?

[twiecki]

@elbamos Yeah this is a bit stuck because of needing to coordinate this with aesara. That's fine but we don't yet have a PyMC3 release that depends on aesara. Once we have that we can move ahead here. Or maybe there's another way that I'm not seeing.

[twiecki]

This is the PR updating aesara: conda-forge/aesara-feedstock#29

[elbamos]

@twiecki It looks like there are two different things going on. One is to remove mkl-service as a pymc3 dependency. When I tried this, that alone was sufficient to enable pymc3-head and aesara to install and work together properly.

I just checked, and mkl-service is not an aesara dependency. I can install aesara through conda on my m1 laptop and the proper arm64 toolchain is pulled-in.

The other thing going on has to do with removing various toolchain dependencies from aesara. This does not, to me, appear necessary for the goal of m1 compatibility.

So my suggestion is to de-link the two projects.

[twiecki]

@elbamos Yes, mkl-service was removed as a dependency and I think the compile-chain is set up properly there too now. So all that's left is PyMC3 but as there is no release that depends on aesara, we still need to keep our own compiler dependencies in here, no? Also, removing mkl-services caused some problems here: #4932

[elbamos]

@twiecki Let me try to separate some issues... It looks to me that:

• mkl-service and mkl are still dependencies of pymc3-main, you have a pending PR to remove them but it hasn't been accepted
• pymc3-main head depends on aesara
• aesara-release installs properly, with the correct toolchain, on unix and OS X systems
• There may be an issue with the aesara toolchain on Windows systems
• neither aesara nor pymc3 should be requiring mkl as a dependency, because its not actually required for either to run, and users may have their own reasons for using a different BLAS
• the compile toolchain installation should be, and it looks to me that it is, managed as an aesara dependency rather than a pymc3 dependency
• there are other issues (bugs) in pymc3-main head concerning compatibility with the current version of aesara, in particular that some functions have been relocated in one place but not the other.

Please let me know if there's some way I can be helpful with some of this.

[twiecki]

@elbamos All of those are correct, except the last one, where is that info from?

[elbamos]

@twiecki That refers to issues reported in #4932 by sreedat. I observed similar issues when I looked at this a few months ago. Maybe I'm wrong about it.

Either way, if the rest of my description is right, then it would seem that the thing to do to close this issue, would be to get your pr removing mkl from pymc3 accepted.

[seamus0215]

I'm still getting this error when trying to import pymc3

WARNING (theano.configdefaults): install mkl with conda install mkl-service: No module named 'mkl'

And I can't find any issues that have been resolved.

[twiecki]

@seamus0215 pymc3 is still using theano where this fix isn't applied. You can upgrade to 4.0.0beta5 and it should be fixed, or wait a week until 4.0 final is released.