Where did you learn that? I’ve been wanting to understand LuaJIT for years, but never got around to it.

Is there a “Heart of LuaJIT” style implementation somewhere? Something that’s like a thousand lines but conveys the core ideas.

I think Mike Pall wrote up a whitepaper with the gory details years ago, but I can’t find it atm.

Damn. If you find anything related to it, I’ll happily Venmo you $20. (High roller, I know.)

The magic of making Lua so fast is seriously underrated. I’m fascinated why Lua in particular seems to be so amenable to speedups vs, say, Python bytecode or even Elisp bytecode.

Here are some places to start with, some of his "famous" mailing list posts: https://news.ycombinator.com/item?id=17329902 and 12 year old reddit bullet list of his too: https://old.reddit.com/r/programming/comments/badl2/luajit_2...

Baseless speculation - was it because the VM was so small and well documented?

Never did program much in Lua but really enjoyed the parts where they describe the virtual machine and instruction set.

EDIT:

Link to the paper I mean https://www.lua.org/doc/jucs05.pdf

For a layman like myself this is very approachable. Again I cannot think of another VM language that has anything this small and well documented.

There was a great thread on lambda-the-ultimate where Mike and a some other famous JIT people talk about the benefits of different approaches. I highly recommend searching for those threads.

Can you help me learn how to search for threads on LtU? I tried using the search box for lua but found nothing. Also failed to find anything in the archives.

I use https://hn.algolia.com/ - so let me try - https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Sorry I read this like 10 years ago.

The other person he talks with is Andreas Gal and they talk about trace trees and method vs tracing jits.

Isn't it the thread that's linked in previous messages in this comment section. Maybe the comment that I linked to in a different message.

I’ll trawl my archives and maybe have a Christmas present for you.

You’re sweet. Thanks for the sentiment, whether or not you find anything. I hope you had a happy Thanksgiving, and that you have a fun and relaxing Christmas break. Cheers.

Lua naturally avoids hashing strings as much as possible. Short strings always have their hash precomputed and local variables are internalized. The default method for implementing variable scopes in dynamic languages just uses a lot of hash tables, but Lua cleverly avoids this:

https://github.com/lua/lua/blob/master/lobject.h#L549

https://github.com/lua/lua/blob/master/lstring.c#L185

Not a language designer, but I have been told the big thing holding back Python is that it exposed too much of its internal guts to external APIs. With so much of the internals exposed, it becomes difficult to make some required backend changes.

Definitely that is true, I wrote a comment about that here: https://news.ycombinator.com/item?id=18041047

Another issue with Python is that the language semantics are much more subtle. This is an excellent talk that shows how even operations that appear simple in Python can be much more complex than they appear: https://youtu.be/qCGofLIzX6g

Not the whitepaper, but here's some resources that I saved for myself to read that might be helpful.

https://www.freelists.org/post/luajit/How-does-LuaJITs-trace...

http://lua-users.org/lists/lua-l/2011-02/msg00742.html

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.