4 ms·

OP said "numba", not "numpy" - numba is a JIT that's compatible with CPython! https://numba.pydata.org/ https://numba.pydata.org/

• yjftsjthsd-h 6y ago
  Ah, I'd assumed a typo; thanks! However, I can't tell if/how much my concerns hold: > You don't need to replace the Python interpreter, run a separate compilation step, or even have a C/C++ compiler installed. Just apply one of the Numba decorators to your Python function, and Numba does the rest. (Emphasis mine) Also, I can't tell whether https://numba.readthedocs.io/en/stable/user/5minguide.html#will-numba-work-for-my-code https://numba.readthedocs.io/en/stable/user/5minguide.html#w... implies that some code won't work, or won't get faster?
  • devxpy 6y ago
    Yes, some code won't work -- numba has a nice compiler that will show you errors if it cannot infer the type of even a single variable at compile time (which usually happens the first time you call your function at run-time). The argument of "some code won't get faster" is null, since you typically only want to use `@njit`, which ensures that you're in `nopython` mode. I guess that's a double edged sword, in that when it says `nopython`, it really does mean no python. This means you can only use features from the python interpreter that the numba team has re-implemented in LLVM IR. --- IIRC `@njit` does involve an overhead in `lowering` the types from python -> LLVM when the first njit function in the call graph is invoked, but not after that. All this means that if you use `for-loops` in nopython mode, they are guaranteed to run faster, at least in my experience.