Hacker News
points by Dylan16807 2 days ago | 0 comments
> No dicts or objects or lists or strings, etc.

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?

[–] ajross 2 days 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.

[–] Dylan16807 2 days ago
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.
[–] zahlman 1 day ago
Yes, Python's hash lookups are actually pretty good. The comments in the implementation are an interesting read.

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.

[–] ajross 2 days ago
> 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.

[–] Dylan16807 2 days ago
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.

[–] strenholme 1 day ago
I have moved my more complex scripting from Perl/PHP/Python to Lua for a lot of reasons. One being that Lua (even PUC Lua) is a good deal faster than Python (or /bin/sh); another is that, if I want even more speed, I can use LuaJIT (which keeps me stuck at Lua 5.1, but Lua 5.1 is perfect for my needs).

I wish Lua 5.1 could become part of POSIX; there are a lot of implementations of it out there.

[–] ajross 1 day ago
Yeah, this is sort of the disconnect. Lua is a fast dynamic interpreter, sitting well above Python but rather below e.g. V8 in its ability to run scalar code over "interpreter types" like doubles and strings and vectors and hash tables.

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.

[–] strenholme 1 day ago
LuaJIT handles double, strings, and dictionaries at near C level performance. Also, arrays, but Lua’s data model has dictionaries and arrays be the same data structure. Lua 5.1 (i.e. LuaJIT) only supports double numeric types,[1] and its strings are immutable.

Lua 5.1’s edge over Javascript and Python is that it’s a lot smaller and simpler.

[1] It’s possible to recompile Lua 5.1 to have the numeric data type be an int, but the standard compiles of Lua5.1 only have double precision floats for numbers. Bitwise operators are technically not part of Lua 5.1, but a library to add support is easy and is usually done: Most Lua5.1 forks including LuaJIT and MediaWiki’s version of Lua5.1 have such a library available. Later versions of Lua have both int and float support.

[–] Dylan16807 1 day ago
If you're saying V8 is quite fast why did you say the world is "waiting for a counterexample" to JITs on very dynamic objects being slow?

When OP wrote "inline Cython" they didn't seem focused on numerics, they talked about "proper C speed", and they mentioned modifying the language. I don't think it's getting off-topic to suggest a deeper integration that lets the JIT be very intimate with the interpreter and truly inline things in a way that bypasses language-crossing and type-dispatching overhead. As long as you're in the hot path, let it look up object fields in a couple instructions.

[–] zahlman 1 day ago
Probably "bound by the data model" is a better way to put it. The interpreter might not be required to touch the data structure, but you have to do a lot of touching of the data structure to get the work done (plus, its mere existence ruins any dream of cache coherency).
[–] Dylan16807 1 day ago
For most objects, you access it directly and nothing weird happens, right?

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.