11–20 of 63 posts
It cannot use NumPy and other libraries (since it is Rust), but at the same time, I see its potential in creating high-performance code to be used in Python numerical environment.
It’s a phenomenal library for developing novel computationally intensive algorithms on numpy arrays. It’s also more versatile than Jax.
In presentations, I’ve heard Leland McInnes credits numba often when he speaks of his development of UMAP. We built a very computationally intensive portion of our application with it and it has been running in production, stable, for several years now.
It’s not suitable for all use cases. But I recommend testing it if you need to do somewhat complex calculations iterating over numpy arrays for which standard numpy or scipy functions don’t exist. Even then, often we were surprised that we could speed up some of those calculations by placing them inside numba.
Edit: ex of a very small function I wrote with numba that speeds up an existing numpy function (note - written years ago and numba has undergone quite some amount of changes since!): https://github.com/grej/pure_numba_alias_sampling
Disclosure - I now work for Anaconda, the company that sponsors the numba project.
Software from our group (cij[1], qha[2]) were developed when numba seems to be the best option for JIT. It generates more pain in the hindsight. It generates a lot of depreciated warning due to unstable API, locked numpy to a certain version (i remember 1.21) due to compatibility issues, and when M1 Mac comes out, there were for a long time lack of llvmlite porting to the new platform, so cannot run on these new Macs…
What if I'm (in Python) doing non-numerical stuff like parsing text and generating code? What JIT / AOT tooling (if any) is suitable?
[1] https://github.com/pybind/pybind11 [2] https://github.com/fwilliams/numpyeigen
Software from our group (cij[1], qha[2]) were developed when numba seems to be the best option for JIT. It generates more pain in the hindsight. It generates a lot of depreciated warning due to unstable API, locked numpy to a certain version (i remember 1.21) due to compatibility issues, and when M1 Mac comes out, there were for a long time lack of llvmlite porting to the new platform, so cannot run on these new Macs…
What if I'm (in Python) doing non-numerical stuff like parsing text and generating code? What JIT / AOT tooling (if any) is suitable?
Example I can think of include:
1. pyyaml’s parser in C vs the Python version get a huge speed up on large files
2. some parsing table (~GB size) using pandas vs self-implemented Python code with a lot of for loop gain 20x speed up at least.
* PyPy JITs everything, so it can do _normal_ Python numerical code that is quite fast and regular Python code that is fast. However, its interactions with libraries like NumPy add overhead, and it seems like it can't JIT code that interacts with NumPy in a useful way (AFAIK, would be happy to be proven wrong). So not useful for optimizing numeric functions that interact with libraries like NumPy.
* Plain old NumPy and friends. This is great... if the operation you want is already available as a "vectorized" API. "Vectorized" in this context does NOT mean SIMD, it's a Python-specific usage, see below.
* Numba: JIT compilation specifically focusing on interop with NumPy and similar libraries. Lets you write subset of Python but unlike NumPy you can use for loops and go fast.
* AOT compilation: Cython, Rust, C++, etc.. You have a longer feedback loop, but you have a full programming language, especially if you avoid Cython. OTOH Cython has nicer Python interop so for simple just-a-little-addon it can be easier to use if you don't already know Rust. You really shouldn't be writing new C++ in this day and age (but wrapping an existing library is useful). Like C++, Cython doesn't help with memory safety. Cython also suffers from two compilers, so debugging can be harder, especially if you use the C++ interop; if you are wrapping existing C++ library, I'd probably start with PyBind11 based on long-ago experience with Boost::Python.
Longer form:
* "Vectorization" in the context of Python: https://pythonspeed.com/articles/vectorization-python/
* PyPy and Numba as alternatives to vectorization: https://pythonspeed.com/articles/vectorization-python-altern...
* Choosing a compiled language: https://pythonspeed.com/articles/rust-cython-python-extensio...
* The performance overhead of AOT compiled libraries (less relevant if you're doing anything numeric): https://pythonspeed.com/articles/python-extension-performanc...
* Numba intro: https://pythonspeed.com/articles/numba-faster-python/
The main problem with Numba is that simple functions are easy enough, and this lulls you into a false sense of security- that things will work.
Unfortunately, every time it turns into an a hair tearing exercise of trying to structure the code such that Numba's vast array of unpredictable edge cases isn't hit.
The error messages are often infuriatingly bad.
At this point I've banned Numba from our codebase. If there's a case for Numba, we just do it in C++ instead.
Edit: we've been looking at Taichi https://www.taichi-lang.org/
I will save you the pain: switch to Julia.
(Modules like PyJulia facilitate a more incremental approach.)
How would this compare to Pypy? I didn't think Pypy uses LLVM so I wonder who produced better code. That said, they're targeted at different audiences. I feel Numba is targeted at data science and machine learning and even AI. I feel a large portion of using or programming a computer is structural and not the actual work of adding numbers together. Very little of the code generated does the useful part a computer doe…
Isn't that constraint propagation?
I'm discovering JS at the moment. I don't fully understand the async model, but the promise seems like a generic constraint of "the result is now available"
Maybe you could have the "flow managements" as other constraints?