Skip to content(if available)orjump to list(if available)

Python 3.14 Getting New Interpreter

Python 3.14 Getting New Interpreter

21 comments

·February 10, 2025

haberman

I blogged about this: https://blog.reverberate.org/2025/02/10/tail-call-updates.ht...

It uses a technique I published several years ago for writing fast interpreters with tail calls: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

There is also this tweet from the author: https://x.com/kenjin4096/status/1887935698906529903

hkwerf

While it's not implemented, Rust even has a keyword reserved [1] for musttail, "become": https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000...

[1] https://doc.rust-lang.org/reference/keywords.html

oefrha

For us non-compiler nerds, can you comment on which compilers support musttail? I suppose latest clang has it. gcc: since you mentioned support was only added in July 2024, I suppose it's not in gcc 14 yet? How about Apple clang from Xcode 16? And MSVC?

saidinesh5

Thanks for the article.

Funnily enough, the first half of the article made a lot more sense after the second half where i was wondering "wouldn't goto do the same?" And then i remembered it was mentioned in the first half...

madspindel

> Preliminary numbers on our machines suggest anywhere from -3% to 30% faster Python code, and a geometric mean of 9-15% faster on pyperformance depending on platform and architecture.

Nice!

morkalork

Is this against 3.12 and 3.13? I only ask because there was a noticeable drop in performance when I updated to those versions.

ano-ther

> The baseline is Python 3.14 built with Clang 19 without this new interpreter.

ninetyninenine

They didn’t add tail calls for the longest time because it blows the stack and makes it harder to debug when stepping through code. Maybe they should make a keyword in Python to explicitly enable tail call recursion when it’s needed.

jy14898

> This is not to be confused with tail call optimization of Python functions, which is currently not implemented in CPython.

> This new interpreter type is an internal implementation detail of the CPython interpreter. It doesn’t change the visible behavior of Python programs at all. It can improve their performance, but doesn’t change anything else.

codr7

I get the feeling that Python is finally reaching the critical mass needed to significantly improve performance, good times.

rakatata

Kinda sad how the industry settled on Python. The performance is not the best and the integration with native languages is far my ideal.

Yesterday I tried to create a Zig library for Bun using bunffi and it was mindblowing how easy it was. You can get pretty much the best of both worlds without obscure bindings. But yeah, both projects are still fairly young.

dist-epoch

Have you looked at pybind11? It's quite easy to use to integrate C/C++.

emidln

I'd recommend nanobind over pybind11 at this point. Similar api, from the same author, but under active development and support.

OutOfHere

At this point it feels like there is nothing stopping Python's performance from approaching that of Julia over the next decade.

kristofferc

Except for the language semantics.

theandrewbailey

Pi-thon.

aitchnyu

All patch versions must add digits so each one asymptotically approaches pi. Yes, this is not unprecedented.

yapyap

haha you beat me to the punch.

was thinking the exact same!

null

[deleted]

null

[deleted]

null

[deleted]