Re:LuaJIT Remake: An ongoing attempt to re-engineer LuaJIT f...
by throwaway81523 on Sunday November 27, 2022 @03:17AM
(#33761355)
I think I remember the whitepaper, but don't know where to find it these days.
Elisp bytecode now has a compiler using libgccjit, in Emacs 28.
LuaJIT simply did a lot of heavy lifting, implementing a full blown compiler with register allocation and all of that. Lua wasn't special that way. Rather, the Python devs didn't care that much about speed, and Python has the baked in notion that Python programs are a tree of nested dictionaries. Thus, there is only so much performance that could be wrung out of PyPy. But it still helps a lot.
Python 3 was of course a tragedy. If they were going to break stuff at all, they could have made some of that dynamicity optional (few programs use it). Then PyPy could have been the reference implementation and it would be crazy fast, eliminate the GIL, and so on. Just like Lisp implementations have done for 50+ years.
Elisp bytecode now has a compiler using libgccjit, in Emacs 28.
LuaJIT simply did a lot of heavy lifting, implementing a full blown compiler with register allocation and all of that. Lua wasn't special that way. Rather, the Python devs didn't care that much about speed, and Python has the baked in notion that Python programs are a tree of nested dictionaries. Thus, there is only so much performance that could be wrung out of PyPy. But it still helps a lot.
Python 3 was of course a tragedy. If they were going to break stuff at all, they could have made some of that dynamicity optional (few programs use it). Then PyPy could have been the reference implementation and it would be crazy fast, eliminate the GIL, and so on. Just like Lisp implementations have done for 50+ years.