When I execute the python program in the virtual environment of Anaconda, the console will report the following error.
D:\Anaconda\lib\site-packages\numpy\__init__.py:148: UserWarning: mkl-service package failed to import, therefore Intel(R) MKL initialization ensuring its correct out-of-the box operation under condition when Gnu OpenMP had already been loaded by Python process is not assured. Please install mkl-service package, see http://github.com/IntelPython/mkl-service
from . import _distributor_init
According to the tutorial of GitHub, I executed conda install -c intel mkl-service and I have installed mkl-service, but the problem is still not solved.
I searched the Internet for a long time, but no effective solution has been found. Please help or try to give some ideas on how to achieve this.Thanks in advance.
I'm setting up my Conda environment with a remote GPU to use Pytorch.
The GPU I use is only NVIDIA-SMI 396.54, so I can only use cuda version 9.2
However, I need to use a higher version torch to be able to use some attributes.
I tried
conda install pytorch==1.7.1 torchvision==0.8.2 cudatoolkit=9.2
But this results in
print(torch.version.cuda)>> None
torch.cuda.is_available() >> False
There are two things I would check.
You may have unintentionally installed the pytorch cpu version or had it in your environment first, before running the above command. Even if you install the gpu version of Pytorch, if you already have the cpu version of pytorch then torch.cuda.is_available() will return False. Therefore I suggest checking out this link:
Forum on why Pytorch is CPU version even after installing cudatoolkit version
Although, I am pretty sure the above thing is your problem, I suggest looking at this second thing.
For understanding how to download previous version of Pytorch refer to this link. https://pytorch.org/get-started/previous-versions/
After looking at this, I suggest starting a new conda env and running your conda install command first.
Sarthak Jain
Background
I've just got a new M1 mac mini dev machine, and migrated from my old x86 mac using apple's migration assistant.
Doing that also copied over all my conda environments to the new machine (they were all in my home directory)
I installed the latest version of anaconda and anaconda plus all my python code and environments seem to work fine (this includes a bunch of wheel modules, notably numpy/scipy).
I did a bunch of googling for my questions below, but couldn't find any good answers anywhere - so I thought I'd ask SO as this seems like a quite common situation others will run into
Questions
Does anyone know the status of M1 native versions of python/numpy/scipy etc provided by conda forge?
I presume that all the binaries in my environments for python/numpy etc all still the old x86 versions, as they were all in environments in my home directory, and running via emulation. So, how do you go about changing/updating those to a M1 arm native
version if/when available?
A quick update as of July 2021.
TLDR
The conda-forge group have a M1 native conda installer here.
Installation is simple - run the installer, and you have conda up and running.
This will install an M1 native conda, and that conda's default environment will by default install M1 native python versions and M1 native versions of modules (if available).
There seem to be native osx M1 native wheels for most common modules now available on the conda-forge channel.
Current status
It seems Anaconda still do not have a native M1 version, nor does Miniconda. ...I can't figure out why it's taken so long and neither still seem to have native M1 support, but that's a separate issue.
Alternative
However, as steff above mentioned, conda-forge (as in the group responsible for maintaining the conda-forge channel) do have a installer for their version of conda that is itself both native M1, and also sets up your environment to pull M1 native wheels where available. This they call Miniforge.
Their github is here.
Various installers for their Miniforge (via direct download, curl or homebrew) can be found on their github page (above) - the direct link to the ARM native miniforge installer is here.
A quick search on conda-forge show's almost all common modules do now have native M1 wheels available. (look for supporting platform 'osx-arm64` eg numpy)
Caveats
I've not tested this too extensively yet, and I'm not sure exactly what happens if a non-M1 wheel is available (I believe it will default to downloading a no-arch version).
I'm also not sure/haven't tested whether you can mix and match M1 wheels with x86 mac wheels. (I'm guessing this would work, but haven't tried).
I also have only done minimal testing using the conda's pip, and how well it recognizes/tries to download/resolves M1 vs x86 pip packages.
The answer here is going to evolve over time, so here is the most up-to-date knowledge I have as of 27 Jan 2021.
Installing conda in emulation mode works completely fine. All you need to do is to install it in a Terminal run in emulation mode, or else install it using a Terminal emulator that has not been ported over yet.
Once your conda environments are up and running, everything else looks and feels like it did on x86 Macs.
If you'd like a bit more detail, I blogged about my experience. Hopefully it helps you here.
I got my M1 about 2 weeks ago and managed to install absolutely everything I need natively from conda-forge and pip. The installer you can download here.
As of 5Feb Homebrew is also officially supported on osx-arm64.
2022/03/02 answers
Native M1 installations are pretty simple now. Here are a few options for Miniforge and Miniconda.
(1) Using Apple's instructions for Tensorflow with Miniforge
This uses the same Miniforge solution mentioned above but includes an M1-optimized Tensorflow install, meaning TF has access to the M1 GPU cores.
Look for the "arm64: Apple Silicon" section at:
https://developer.apple.com/metal/tensorflow-plugin/
(2) Running native M1 with Miniforge and Rosetta with Miniconda side-by-side (Jeff Heaton's tutorial from 2021/11)
Jeff basically uses Apple's solution above for the native Miniforge install.
https://www.youtube.com/watch?v=w2qlou7n7MA
(3) Using native M1 Miniconda
There was a native M1 Miniconda installer published in 2021/11: Miniconda3 macOS Apple M1 64-bit bash (Py38 conda 4.10.1 2021-11-08)
https://docs.conda.io/en/latest/miniconda.html
My Experiences
I successfully ran the side-by-side installation from Jeff's tutorial with a few changes. It was very easy and I verified that in the native M1 Miniforge environment that Numpy is using the optimized BLAS/LAPACK linear algebra libraries and that Tensorflow has GPU access. I will update here after I run the Miniconda native M1 installer.
I installed the native version of python3 through miniforge (Apple version) and Spyder (Intel version) through homebrew and everything is working just fine for me with one exception, I've observed one strange behaviour when setting the "graphics backend" option to "automatic" instead of "inline".
Spyder >>> Prefernces >>> IPython Console >>> Graphics >>> Graphics Backend >>> inline, or automatic
When I start Spyder with the "inline" option and switch to "automatic", the opened kernels function just as expected. However, if I open new consoles they don't work at all. The issue also persists after restarting Spyder. The only way I manage to plot graphics in a separate window is to start Spyder with IPython console "graphics backend" set to "inline" and then change it to "automatic".
If I run python3 through terminal, plotting graphics works just fine as well.
My installation commands were:
brew install --cask miniforge
conda init zsh
conda activate
brew install --cask spyder
brew install PyQt#5
pip3 install matplotlib
You can check out this anouncement by Anaconda. You can now use Anaconda on your M1 MAC direclty.
"The 2022.05 release of Anaconda Distribution features native compiling for Apple M1’s ARM64 architecture (boasting 20% faster compute), Anaconda Navigator 2.1.4, conda 4.12.0, as well as several new and updated packages. 2022.05 is also the last release that will support win32."
I have a problem where
import torch
print(torch.cuda_is_available())
will print False, and I can't use the GPU available. I've tried it on conda environment, where I've installed the PyTorch version corresponding to the NVIDIA driver I have. I've also tried it in docker container, where I've done the same. I've tried both of these options on a remote server, but they both failed. I know that I've installed the correct driver versions because I've checked the version with nvcc --version before installing PyTorch, and I've checked the GPU connection with nvidia-smi which displays the GPUs on the machines correctly.
Also, I've checked this post and tried exporting CUDA_VISIBLE_DEVICES, but had no luck.
On the server I have NVIDIA V100 GPUs with CUDA version 10.0 (for conda environment) and version 10.2 on a docker container I've built. Any help or push in the right direction would be greatly appreciated. Thanks!
For anyone else having this problem, it turned out my server manager has not updated the drivers for the server.
I switched to a different server, installed anaconda and things started working like it should, i.e., torch.cuda.is_available() returns True after setting up a fresh environment.
Rasa Core version: 0.13.0a4
Python version: 3.6.1
Operating system: Windows 10
I could successfully train the model for the created stories using python nlu_model.py. But when I try to launch the bot in command prompt, I get an entry point not found error.
This link said that this might be a Tensorflow GPU issue, but I am not using GPU.
I tried to upgrade to the latest Tensorlow version, but still didnt work.