Compile numba code with nogil=True

[mrocklin]

This helps when parallelizing around sparse

[mrocklin]

Generic example:

In [1]: import numba

In [2]: import numpy as np

In [3]: x = np.random.random(100000000)

In [4]: @numba.jit(nopython=True)
   ...: def f(x):
   ...:     total = 0
   ...:     for i in range(len(x)):
   ...:         total += x[i]
   ...:     return total
   ...: 

In [5]: f(x)  # run once to compile
Out[5]: 50001234.14227918

In [6]: %load_ext ptime

In [7]: %ptime -n 4 f(x)
Total serial time:   0.52 s
Total parallel time: 0.50 s
For a 1.05X speedup across 4 threads

In [8]: @numba.jit(nopython=True, nogil=True)
   ...: def f(x):
   ...:     total = 0
   ...:     for i in range(len(x)):
   ...:         total += x[i]
   ...:     return total
   ...: 

In [9]: f(x)  # run once to compile
Out[9]: 50001234.14227918

In [10]: %ptime -n 4 f(x)
Total serial time:   0.52 s
Total parallel time: 0.14 s
For a 3.63X speedup across 4 threads

[codecov]

Codecov Report

Merging #159 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #159   +/-   ##
=======================================
  Coverage   96.92%   96.92%           
=======================================
  Files          11       11           
  Lines        1205     1205           
=======================================
  Hits         1168     1168           
  Misses         37       37

Impacted Files	Coverage Δ
sparse/coo/indexing.py	100% <100%> (ø)	⬆️
sparse/coo/umath.py	96.85% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4104eab...d3c73cd. Read the comment docs.

[hameerabbasi]

Is there any risk of incorrect results when doing this, assuming no race conditions?

[mrocklin]

That's probably more a question for you than it is for me. Do any of these functions rely on global state or mutate their inputs? If they were called concurrently in multiple threads would that be a problem?

[mrocklin]

Usually the answer is "no", but we may be doing inplace modifications for performance sake,.

[mrocklin]

Previously these functions were run with a giant lock around them so that no other Python function would run at the same time. Now we are removing that lock.

[hameerabbasi]

Do any of these functions rely on global state or mutate their inputs?

No, they don't do that. :-) Thanks for this, I wondered why the dask.array version was as slow as it was.

[hameerabbasi]

This gets a +1. Thanks for this.

[mrocklin]

I wondered why the dask.array version was as slow as it was.

There are very likely other reasons than just this. This is something that will likely improve over time as it gets some use.

[mrocklin]

Thanks for the review @hameerabbasi . Merging!