Is numba worth the trouble if numpy can do most of the work?

[danielballan]

This S.O. question, in particular the original poster's comment on the answer, sums up my feelings as I try work fit numba into my code. Seems like a lot of common numpy idioms are not supported.

Explicit loops, which seem to be what numba wants, make code less readable and obviously slower for users who might not have numba available. Disappointing.

On the other hand, the line profiler %lprun shows me that the refine function in feautre.py takes 95% of the runtime during feature location, so making that faster is worth the trouble, even if it does take a lot of trouble.

Thoughts?

[danielballan]

OK, I have numba working on feature.py, similar to how Nathan used it on identification.py: it speeds up the refine loop. For extra credit, I managed to keep general dimensions, not just 2D.

I have more work to do before I merge this into master, but for this is the speedup so far:

numba-dan branch:
noise-filled dummy image: 1 loops, best of 3: 1.15 s per loop
image of particles: 1 loops, best of 3: 1.61 s per loop

on master:
noise-filled dummy image: 1 loops, best of 3: 1.32 s per loop
image of particles: 1 loops, best of 3: 1.9 s per loop

[danielballan]

Figures above had memorization code removed. The times are better with memoization reinstated, so masks are only generated once.

numba-dan with memoization turned on
1 loops, best of 3: 966 ms per loop
1 loops, best of 3: 1.38 s per loop

[nkeim]

Yes, numba (or cython, etc.) is worth the trouble! :) At least when you're tracking a flowing material made of close-packed particles, which really taxes the subnet code. Switching the subnet code to numba gave me roughly an order of magnitude in speed for my data.

I have battled numba before, so if you are running into problems, I may be able to help. Also, now that you have the numba code running and passing tests, there may be ways to speed it up. As in Cython, it's possible for the code to silently drop back into the Python object model, which means a huge penalty.

I have re-forked the master branch of this repo and will probably add the numba subnet code soon. I don't mean to be impatient --- I just have to add a feature to the linker for my research, and I thought I'd try to quit my old numba branch, which means that I need comparable performance from the new one soon.

I'm so glad that refine can work with numba! Thanks!

[danielballan]

Great! Once I have something that I'm sure is working, I'll ask for your help. Maybe later today if things go well.

Don't worry about seeming impatient -- I was worried about seeming that way myself. I'd like to have something stable to work on soon. I think what remains is:

1. Develop PIMS to the point where the API is stable so that the tutorials for trackpy will be stable too. As you can see, Tom has been hard at work nearly rewriting the whole thing, making it much better.
2. Merge in my numba refine branch.
3. Merge in your numba subnet branch, and set up the existing unit tests to run on it.
4. Test things on real data for a few days.
5. Update README/docs/tutorials at least to the point that there is no wrong information.

Anything else on our collective wish list before declare victory on v0.2 and start using it full time?

[danielballan]

We have our numba subnet. #44 paves the way for a drop-in replacement or 2D special case for refine, whether it numba, cython, or C. Since Nathan has indicated that his needs are met in runtrackpy, I will close this issue.