Comment by ajross
10 hours ago
> That's a really intense restriction.
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.
A hash lookup can be very fast. There's no reason for it to be slow when it doesn't need to invoke the fallback. JITs can't remove the slowest case but they can make the normal case very fast. Saying it can't be fast ever is a huge cop-out.
> Saying it can't be fast ever is a huge cop-out.
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.
LuaJIT has the same dynamism with dictionaries and it's very fast at accessing them in JIT code.
I don't have enough experience with PyPy to say much about it.