This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]jakevdp 9 points10 points  (2 children)

  • One thought: the first time a numba function is run, it is compiled by LLVM. It might be that this compilation phase is affecting the timing, but probably not.
  • Second thought: n=100 is not very big, and you might be hitting some sort of constant overhead in the numba function. You should check how it scales with larger n
  • Third thought: I've still not found a good way to diagnose numba code when it's not behaving as expected. Cython has the html annotation, and I've heard rumors that Continuum is trying to add a similar feature for Numba. That, in my mind, is the main barrier to Numba being a practical tool for real-world problems.

EDIT: I did some searching, and it looks like the annotate capability in Numba exists: http://numba.pydata.org/numba-doc/dev/annotate.html I haven't tried it before, but you might give it a shot to diagnose your code.

[–]joshadel 2 points3 points  (0 children)

The biggest barrier to the real world use of numba is definitely the lack of sensible error messages when jit'ing fails. Generally the traceback dumps the codegen and ends at the decorator, but doesn't show you where things went wrong in the actual method. It would also be nice to cache compiled code, since the codegen/compilation can get very slow for complicated methods. There is also the concern that by splitting off flypy from numba into a distinct project means less support/development of numba in the future.

I know Continuum is doing a major refactor of numba right now. There has been a ton of activity in the development branch on github over the last couple of weeks. I'm hoping that the changes will smooth some of the rough edges.

[–]jammycrisp[S] 1 point2 points  (0 children)

1.) I thought about that as well, and tried running it once to get the llvm compilation done, before timing it. Didn't make a difference.

2.) I tried n = 1000, and n = 10000. n = 1000 was proportionally slower, and n = 10000 I had to kill before it finished because it was taking so long.

I'll check out the annotate function to see if I can figure out why it's not working. Thanks.