User-controllable thread pool limits for parallel target to @vectorize and @guvectorize

[seibert]

(As requested on the numba-users mailing list.)

Right now we always assume the number of threads for the parallel target is equal to the number of CPUs. There are plenty of situations where this is not desirable (multiple processes, etc), and so it is important to have some mechanism to limit the number of threads.

At a minimum, it would make sense to check the value of OMP_NUM_THREADS at startup, in order to mimic the behavior of other parallel libraries like MKL. We don't actually use OpenMP's thread pool (though maybe we could someday), but this variable is at least somewhat well known to users who want to control the number of threads.

We may also want an API in Numba to change the number of threads as well.

[stuartarchibald]

Environment variable implemented in #1932.

[seibert]

Fixed by #1932. (We might further expand things to allow control per call as well.)

[jzwinck]

For reference, #2713 is to make the number of threads controllable at runtime.

[jcmgray]

OMP_NUM_THREADS is a very common way of setting the level of thread parallelism in a program. How do people feel about letting numba check this upon import as well? NUMBA_NUM_THREADS would of course take precedent if set.