Add (or document) environment variable to disable parallelism

[mdekstrand]

Feature request

Right now, there is not a (documented) way to disable Numba parallelism from environment variables. Setting NUMBA_NUM_THREADS=1 still does something with the threading layer, and with the TBB threading layer this also results in a TBB shutdown error:

terminate called after throwing an instance of 'tbb::missing_wait'
  what():  wait() was not called on the structured_task_group

I see 3 reasonable solutions:

• Add a new NUMBA_DISABLE_PARALLEL environment variable that is the equivalent of ignoring parallel=True
• Add a none option for NUMBA_THREADING_LAYER that disables threading entirely.
• Disable threading / parallelism when the thread count is 1 (I don't personally like this option, as it prevents testing the difference between no-parallel code and parallel code with 1 thread in testing scalability)

[stuartarchibald]

Thanks for the request, it will be discussed at the next core developer meeting (next week).

General question to help drive discussion: What is the practical reason for wanting to do this? Is it to test e.g. the standard nopython=True CPU target vs. parallel + 1 thread vs. parallel + n threads ?

A bit of background...

• Consideration is required over the parallel target being more involved than "on" or "off", there's a whole host of options that can be switched http://numba.pydata.org/numba-doc/latest/developer/architecture.html#stage-6b-perform-automatic-parallelization, though on/off is the most common use.
• The threading backend that executes the scheduled work is independent of the notion of parallel code generation. The parallel target makes it such that there is a function that can be executed in parallel, the internal scheduling of which is left to the threading backend. AFAIR setting the number of threads to one (or indeed any other number) does not impact the creation or representation of the function amenable to parallel execution. Further, parallel target functions depend on the threading backend for execution, calls to the threading layer are generated and compiled into the jitted code.
• There has been some initial discussion over enabling suitable parallel target compiler passes for the non-parallel cpu target, this somewhat aligning code generation between the two targets.

As a quick work around, could you augment your code with something like:

if os.environ.get('NUMBA_DISABLE_PARALLEL', None) is not None:
    nb_parallel = False
    from numba import njit
else:
    nb_parallel = True
    from numba import jit
    njit = jit(parallel=True, nopython=True)

for a similar effect?

As to the issue with NUMBA_NUM_THREADS=1 and TBB, this is a bug, thanks, reported here.

[mdekstrand]

Yes, that is precisely the purpose. There are two main reasons for this:

• When debugging, to isolate faults by making sure they show up in a pure-CPU compilation as well as a parallel compilation.
• Performance testing, to include the overhead of using the threading layer; this is less important, I have just been trying to do it for completeness.

[mdekstrand]

The quick workaround is exactly what I was going to do if I need it more urgently than it can get added to Numba 😃 .

[hugohadfield]

+1 for the NUMBA_DISABLE_PARALLEL environment variable to exist by default. Was running a workshop with ~20 people installing a library dependent on Numba and had problems with the parallel layer for many of them. Had to tell them to use NUMBA_DISABLE_JIT before loading the library which made it ~100x slower, while not an ideal situation NUMBA_DISABLE_PARALLEL would have been very useful...

[stuartarchibald]

I don't think that this is a hugely involved task, I've scheduled it for the 0.44 RC (the next release cycle). @hugohadfield (or indeed anyone) If you'd like to have sooner, PRs are welcome and the core developers can assist/provide guidance as needed.