How to make a fast dynamic language interpreter

> I think you’re describing deficiencies in the Python impl not anything about the language

To some extent, sure. And, looking at your implementation of your language, something like the optimizations on passing small numbers of parameters could probably help Python out. It spends an inordinate amount of time packing and unpacking parameter tuples.

But, for example, you can easily create a subclass of an integer and alter a small portion of its behavior, without having to code every single operation, which I don't think you can do in lua.

So, the dynamicity I'm describing is what the language has to do (more work at runtime) to support its own semantics.

Don't get me wrong. There are certainly opportunities to make Python go faster, and the core team is working on some of them (for example, one optimization is similar to your creation of additional subtree nodes for attribute lookup for known cases, but in bytecode instead), but I also think that the semantics of Python make large classes of optimization more difficult than for other languages.

For a major example of this kind of dynamicity, lua doesn't chain metatables when looking up metamethods, but Python will look stuff up in as many tables as you have subclasses, and has the complexity of dealing with MRO. That's not something that couldn't be JITed, but the edge cases of what you need to update if someone decides to add or modify a method in a superclass get pretty hairy pretty quickly.

Whereas, in lua, if you want to modify a metamethod and have it affect a particular object, yes, absolutely, you can do that, but it is up to you to modify the direct metatable of the object, rather than some ancestor, because lua is not going to dynamically follow the chain of references on every lookup.

And, back to to the parameter optimization case, I haven't thought that much about it, but there are a lot of Python edge cases in parameter passing, that might make that difficult.

And, of course, the use of ref counting instead of mark/sweep has a cost, but people don't like, e.g., PyPy, because their __del__ methods aren't guaranteed to be called immediately when the object goes out of scope. Lua is more like PyPy in this respect.

So Python has a lot of legacy decisions that make optimization harder.

Then things that try to be called Python often take shortcuts that make things faster, but don't get any traction, because they aren't 100% compatible.

So cPython is a Schelling point with semantics that are more complicated than some other language Schelling points, with enough momentum that it becomes difficult for other Python implementations to keep up with the standard, while simultaneously having enough inertia to keep people engaged in using it even though the optimizations are coming slowly.

I think the sPy language (discussed here a few weeks ago) has the right idea. "Hey, we're not Python, but if you like Python you might like us." Things that claim to be Python but faster either wither on the vine because of incompatibilities with cPython, or quickly decide they aren't really Python after they've lost their, ahem, Mojo, or both.

(The primary exception to this is microPython, which has a strong following because it literally can go where no other Python can go.)

> A more nuanced take is that Lua has many happy fast paths, whereas Python has some unfortunate semantic baggage that complicates those.

This is a good way to describe it. Most of the semantic baggage doesn't make some speed improvements, up to and including JITing, impossible, but it certainly complicates them.

And of course, any semantic baggage will be useful to someone.

https://xkcd.com/1172/

That's yet an other topic, as monkey patching can definitely be explicit in ruby. The dynamically generated things at runtime are generally through the catch all method missing facility that can be overwritten. This can also be done in, say, PHP. It just that the community is less fond of it. Not sure about what most popular ahead of time oriented languages expose as facility in this area, obviously one can always even decide to generate automodifying executable. There is nothing special about ruby when it comes to go into forbidden realms, except maybe it doesn't come to much in your way when you try to express something, even if that is not the most maintenance friendly path.

Good writeup. The Arguments arc (#7→#13) hits close — did basically the same dance for an async step evaluator in Rust a while back. Went all in on Cow assuming borrow-in-the-common-case would earn its keep. Microbenches looked great. Real workload: the Cow discriminant plus lifetime gunk bled into every combinator past the first await, inlining fell off a cliff, the whole point of Cow evaporated. Ripped it out for NoInput / OneInput / MultiInput(Vec) at the evaluator boundary — same split as your ZeroArguments / OneArgument / TwoArguments, just arrived at the ugly way. One thing I keep wondering: have you stacked arity specialization with type specialization on the native path? Binary style, drops the isInt probe altogether. Guessing the code size math didn't work out, or ICs are already soaking up whatever's hot on the object side so the native fast paths don't matter much. Which one?

That is an incorrect analysis. CPython is difficult to JIT because of the lack of thought to the native bindings / extensions, not because of the language itself (as others point out PyPy was way faster long ago)