My previous posts regarding the Numba package for Python used version 0.11. Recently, Numba has gone through some major changes in version 0.12.1, 0.12.2 and 0.13. My last post explained how I had used the nopython keyword argument to speed up my code. Importantly, it showed that removing array allocation steps (i.e. np.zeros(…)) allowed Numba 0.11 to automatically generate code that did not use the Python C API. I decided to see what the current state of affairs is with version 0.13. The release notes for Numba are available here.
Firstly, the autojit decorator and function has been deprecated, although it still works for the moment. It has been replaced by using jit without a function signature. Now for some speeds using the same code as my last post.
- exp_test_1: 1.47 seconds per loop.
- jit_exp_test_1: 20.1 milliseconds per loop.
- Numpy exp: 11.8 milliseconds per loop.
- exp_test_2: 457 milliseconds per loop.
- jit_exp_test_2: 19.9 milliseconds per loop.
- exp_test_3: 1.47 seconds per loop.
- jit_exp_test_3: 19.6 milliseconds per loop.
- jit_exp_test_3_withpython: 19.4 milliseconds per loop.
Since my previous post, I have also upgraded to Numpy 1.8.0 compiled with Intel MKL and available from www.lfd.uci.edu/~gohlke/pythonlibs/. This seems to have sped up the unjitted functions relying on Numpy.
Numba has improved significantly as it is now just 2x slower than Numpy without using nopython, compared to 11x slower in my previous post! +1 for usability. Using nopython=True does not produce much of an improvement. This fits with the release notes stating that Numba now compiles loops in nopython mode (if they can be) even if there are array allocations at the start of the jitted function. Unfortunately, the Numba nopython mode speed has dropped somewhat from version 0.11 to version 0.13. Considering the improvements though in simplicity, I won’t moan.
Using nopython=True is still worthwhile because it produces an error when your code cannot be accelerated using nopython mode, rather than producing slow code. I still prefer having an error over having slow code without a clue as to why it is slower than expected.