A tail calling interpreter for Python (already landed in CPython)

Will Python ever get fast? Or even _reasonably_ fast?

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.

So then what's the point? Is Python really just a glue language like all the rest?

Python is fast enough for a whole set of problems AND it is a pretty, easy to read and write language. I do think it can probably hit pause on adding more syntax but at least everything it adds is backwards compatible. You won’t be writing a 3D FPS game engine in Python but you definitely can do a whole lot of real time data processing, batch processing, scientific computing, web and native applications, etc. before you need to start considering a faster interpreter.

If your only metric for a language is speed then nothing really beats hand crafted assembly. All this memory safety at runtime is just overhead. If you also consider language ergonomics, Python suddenly is not a bad choice at all.

I guess I'm wondering what is the point of tail-call optimizations, or even async/await when it's all super slow and bounded by the runtime itself? There are basically no improvements whatsoever to the core cpython runtime. So really what is all this for? Some theoretical future version of Python that can actually use these features in an optimal way?

VWWHFSfQ, you may already know this, but: I recommend this talk by Armin Ronacher (Flask creator) on how Python's implementation internals contribute to the difficulties of making Python faster.

https://www.youtube.com/watchv=qCGofLIzX6g

One case study Ronacher gets into is the torturous path taken through the Python interpreter (runtime?) when you evaluate `__add__`. Fascinating stuff.

The JIT will improve - you can also use PyPy to get speedups on programs that don't use a ton of C extensions.

Also, free-threading is coming so we'll have threads soon.

I don't know if Python can every really be fast as by design, objects are scattered all over memoryand even things like iterating a list, you're chasing pointers to PyObject all over the place - it's just not cache friendly.

I think if you want python but fast then Mojo is your only hope.

EDIT: yes and there’s pypy as well as pointed out below. Basically you gotta use an alternative python implementation of some kind.

There’s always PyPy - it’s much faster than CPython and, unlike Mojo, is ready to use today.

> You won’t be writing a 3D FPS game engine in Python

While Eve Online isn’t an FPS, it is an MMORPG written in stackless Python, and seems to be doing OK.

> If your only metric for a language is speed then nothing really beats hand crafted assembly

Only if you know the micro-architecture of the processor you are running on at great depth and can schedule the instructions accordingly. Modern compilers and vms can do crazy stuff at this level.

> Python is fast enough for a whole set of problems AND it is a pretty, easy to read and write language.

It is definitely easy to read. But speed is debatable. It is slow enough for my workload to start wondering about moving to pypy.

This TCO is in how the CPython interpreter works, not in making Python itself tail recursive. Some of the C code in the interpreter has been reorganized to put some calls into tail position where the C compiler turns them into jumps. That avoids some call/return overhead and makes the interpreter run a little faster. It's still interpreting the same language with the same semantics.

It was, once.

Nowadays (for about 12 years already I think) there is nothing much stackless about it.

The concept was nice. Stackless and greenlets.. yess. But the way they rewrote C stack just killed caches. Even a naive reimplementation just using separate mmapped stacks and wrapping the whole coro concept under then-Python's threading module instantly gained like 100x speedup on context switch loads like serving small stuff over HTTP.

Edit: Though at this point it didn't much differ from ye olde FreeBSD N:M pthread implementation. Which ended badly if anyone can remember.

everything it adds is by default backwards compatible, because old programs didn't use it, because it wasn't there yet, and so won't break.

Python's problem is that the non-new stuff is not always backwards compatible. It happens way too often that A new python version comes out and half the python programs on my system just stop working.

Your link is broken, here's a working one: https://www.youtube.com/watch?v=qCGofLIzX6g

They do continuously struggle with CPU load and by all accounts have a mountain range of technical debt from that decision, though.

PyPy has a list implementation that specializes under the hood. So if you stuff it with integers, it will contain the integers directly instead of pointers to them. That's at least how I understood it.

Will your program ever be fast if you don’t learn the microarchitecture of your CPU first? :)

PyPy is a valid option and one I would explore if it fits what you are doing.