How does this differ from direct threading interpreters?<p>It seems like it solves the same problem (saving the function call overhead) and has the same downsides (requires non-standard compiler extensions)<p>EDIT: it seems the answer is that compilers do not play well with direct-threaded interpreters and they are able to perform more/better optimizations when looking at normal-sized functions rather than massive blocks<p><a href="http://lua-users.org/lists/lua-l/2011-02/msg00742.html" rel="nofollow">http://lua-users.org/lists/lua-l/2011-02/msg00742.html</a>
Recent discussion: <a href="https://news.ycombinator.com/item?id=42999672">https://news.ycombinator.com/item?id=42999672</a><p>Do check out the articles in the top most comment.. about how tail call optimization gets you faster interpreters.<p>It completely eliminates the overhead of function calls in the generated machine code while you still your code modularly using functions.
`return goto f()` syntax in C seems interesting<p>I had a similiar idea that Python could have `return from f()` to support tail calls without the issues raised about implicit tail calls
To read about the basics of tail calls optimization:<p><a href="https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html" rel="nofollow">https://blog.reverberate.org/2021/04/21/musttail-efficient-i...</a>
See also this little bit of discussion about a week back: <a href="https://news.ycombinator.com/item?id=42999672">https://news.ycombinator.com/item?id=42999672</a>
Will Python ever get fast? Or even _reasonably_ fast?<p>The answer is no, it will not. Instead they'll just keep adding more and more syntax. And more and more ways to do the same old things. And they'll say that if you want "fast" then write a native module that we can import and use.<p>So then what's the point? Is Python really just a glue language like all the rest?