Set number of threads after numpy import

This is not a bug report but just an enhancement proposal.

I think it would be useful and important to be able to easily set the number of threads used by Numpy after Numpy import.

From the perspective of library developers, it is often useful to be able to control the number of threads used by Numpy, see for example https://github.com/biopython/biopython/pull/1401.

It is not difficult to do in a simple script when we are sure that Numpy or Scipy have not been imported previously with something like:

import os
os.environ["OMP_NUM_THREADS"] = "1"
import numpy as np

However, in a library there is a good chance that the user has already imported Numpy in its main script, with something like

import numpy as np

import fluidimage

In this case, I don’t see how to set the number of threads used by Numpy from the fluidimage code.

Thus, it would be very convenient to have a function np.set_num_threads.

[mattip]

Closing, since the threadpoolctl package handles this.

[tomMoral]

@Amir-Arsalan The environment variable are the most reliable and cross platform way to control the number of threads for given implementations and if you want to set it for a given interpreter. You can use:

OMP_NUM_THREADS: openmp,
OPENBLAS_NUM_THREADS: openblas,
MKL_NUM_THREADS: mkl,
VECLIB_MAXIMUM_THREADS: accelerate,
NUMEXPR_NUM_THREADS: numexpr

It is possible to set all these variables to control the number of threads, without knowing which library is loaded in advance.

The issue is when you want dynamic control over the number of threads used. Indeed, once the thread pool is started, changing the environment variable will have no effect. Then, you need to access C-library functionality exposed to set the number of threads used, if they are provided by the underlying implementation. @seberg codes works on linux system, where find_library is able to locate and load the correct library file (.so) to call the dynamic thread-pool rescaling functions. The code in a PR for loky try to do it in a cross platform way, by looping through all DLL and setting the number of threads when it is possible. But both implementations have shortcomings, notably they will fail for some platforms (debian?) and implementations (Accelerate has no way to set the number of threads dynamically).

I am currently working on improving the loky code to make it the most reliable possible but it probably needs feedback. I am open to any suggestions for improvements or better support and comments if you see big drawbacks in the proposed way of changing the number of threads used.