Folks, numba is great. To first approximation: write your python function to "look like C"[1] and work over the numpy arrays you probably already have and understand, put a "@jit" decorator on it, and you're done. It JITs and runs your code natively at native performance.
With some extra effort, there are features for SIMD vectorization and thread parallelism, and even GPU backends (that, full disclosure, I've been pretty frustrated by -- but they do work).
[1] Which is to say, don't touch Python interpreter data structures. No dicts or objects or lists or strings, etc... If you're bound by the interpreter[2] you're bound by the interpreter and nothing is going to help you.
[2] A corrolary here is that the kind of C code numba is NOT good for is "following pointers between structs", which is something that can't be expressed in either python or numpy.
[–] Dylan16807 2 days ago
[–] ajross 2 days ago
Is it? An object field access in python is a dynamic hash lookup followed by a method call as a fallback (itself involving hashed lookups up the class hierarchy). That's not an "interpreter vs. native" kind of thing, that's just the semantics of the language that have to be preserved. And that's just not going to be "fast" in the way that the user of a JIT would want. Code dominated by Python datastructures is going to be "slow" in ways that JITs can't fix, ever.
Which is why Python appears to have given up on the effort in this space. PyPy too[1] really never delivered on the desired performance gains (like 5x or so on typical code) without forcing the user into careful optimization.
Numba, to its credit, doesn't even try. It falls back to python if it must for python stuff, but is quite clear that it's providing no benefit if that's what you're doing. And the stuff it does do is obvious and clean and extremely useful.
[1] PyPy is also looking pretty moribund recently.
[–] Dylan16807 2 days ago
[–] ajross 2 days ago
Maybe, but the world is still waiting for the counterexample. Python is simply not a runtime well-suited to optimization.
In the meantime, those of us who actually enjoy real HPC problems are using numba and rolling our eyes about all the confuffery around JITs. Maybe one will arrive that proves us wrong, but numba is fast today.
[–] Dylan16807 2 days ago
I don't have enough experience with PyPy to say much about it.
[–] strenholme 1 day ago
I wish Lua 5.1 could become part of POSIX; there are a lot of implementations of it out there.
[–] ajross 1 day ago
The upthread comment was about an idea for "inline Cython", which was then hijacked because that's largely what numba is. These are technologies aimed at optimized native code running over native types to do stuff like numerics and ML and other HPC tasks. Lua isn't any more responsive to this domain than Javascript has been, it's not really the subject under discussion.
[–] zahlman 1 day ago
[–] Dylan16807 1 day ago
Can you not mostly cache whether anything weird needs to happen and do the direct access with minimal overhead?
You said elsewhere "But that doesn't help much if/when you're doing two hash lookups per iteration just to find two small integers to add together." but looking up two fields isn't inherently a very big overhead. And you can cache the actual hash, and if you want to you can make sure the fields on similar objects have a consistent offset and cache that offset to make it even faster. This code using lots of objects is presumably not the core number crunching on arrays; we're doing more logic per access and we can handle a few instructions to get a value.
[–] sgarland 2 days ago
I don’t know how people who’ve worked with Python and been frustrated with its performance don’t know about Numba.
[–] bheztio 2 days ago
[–] ajross 2 days ago
The one aesthetic gripe I have is that the LLVM included is a fork. It won't even try to work with the system LLVM and insists on installing a huge wheel with custom binaries. But on a modern system an extra LLVM is noise, so I guess I don't care that much.
[–] pitrou 1 day ago
It's not technically a fork, it's a standalone build of vanilla LLVM (ok, there are a couple patches: https://github.com/numba/llvmlite/tree/main/conda-recipes).
> It won't even try to work with the system LLVM and insists on installing a huge wheel with custom binaries.
Not only does LLVM not have a stable ABI, it doesn't even have a stable API. It's difficult to write code that works reliably against a non-trivial number of LLVM major versions.
For the record, here is the LLVM compatibility table for llvmlite versions (llvmlite is the Python-C++ shim that Numba uses to talk to LLVM): https://llvmlite.readthedocs.io/en/latest/#llvm-compatibilit...
If you want a Numba linked against your system LLVM, the solution would be for your distribution to provide a system package for Numba (and llvmlite).
That's a really intense restriction. Sounds like the name fits; it's not general purpose, it's jit for number crunching and little else.
I'm not sure exactly what you mean by "bound by the interpreter" but there's nothing about touching those data structures that requires the interpreter to be involved in most cases. The problem of slow APIs can be solved by the JIT having intimate knowledge of python's internals, can't it?