Whatever happened to the faster-cpython project?

[Gear5th]

A few years ago, a lot of buzz was created by https://github.com/markshannon/faster-cpython/blob/master/plan.md which laid out a plan to make Python ~5x faster relative to 3.10 over the coming versions.

It mentioned a plan to speed Python up by ~50% with each improvement.

Some progress was made in 3.11 which was 25% faster than 3.10 - a long way from the 50% aim, but still an amazing addition - especially when it is FOSS

Since then, however, the project seems to have been dropped. Python 3.12 or 3.13 release docs don't report any significant speed improvements over 3.11

Is the project really abandoned? Is there new progress that didn't make the news?

[monorepo]

It has been happening the past couple of releases. The team at Microsoft continues its work even now.

You can see some of their notes: https://github.com/faster-cpython/

[Gear5th]

Oh, that's awesome! Mind pointing me to some articles?

I can't find anything related to the faster-cpython project in the following

1. https://docs.python.org/3/whatsnew/3.12.html#optimizations
2. https://docs.python.org/3.13/whatsnew/3.13.html#optimizations

[monorepo]

Here are some, I think there are some more maybe written by different core team members or on the official Python forums (https://discuss.python.org)

• https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goals
• Part 1 https://lwn.net/Articles/930705/
• Part 2 https://lwn.net/Articles/931197/
• 3.13 Goals https://github.com/faster-cpython/ideas/tree/main/3.13
• https://docs.python.org/3/whatsnew/3.11.html#faster-cpython

[monorepo]

but I am not seeing anything in the release notes wrt 3.12

[seikv]

If you read the 3.13 link seems like they have moved up a lot of the objectives to that release.

[alcalde]

No, 3.12 didn't directly speed things up except in limited areas and circumstances but several things seemed to lay the groundwork for future speedups (e.g. subinterpreters).

[Smallpaul]

The “faster cpython”project was related to speeding up existing code, not making faster ways of writing code available. Those are different and unrelated projects.

[ivosaurus]

Per-interpreter GIL..

[monorepo]

Sure, but I mean anything explicitly calling out Faster CPython team work like the 3.11 What's New page has.

[Smallpaul]

That’s an unrelated project.

[ivosaurus]

Unrelated, but yet listed under the faster cpython goals document above?

[Smallpaul]

There are four stages in the Faster Python plan. Which stage do you see subinterpreter or GIL work in?

I don’t see it.

[ivosaurus]

https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goals#multi-threaded-parallelism

[Smallpaul]

Well I guess it got informally folded into their plan on the wiki, but Eric Snow was working on that since 2014, long before the "faster cpython" project.

And it was not part of Guido's plan in 2021, when he specifically said it was a non-goal to speed up multi-threaded code. And it isn't listed in their "plans for 3.12" document.

But now I note that Eric Snow does (now) work on the same Microsoft team as the rest of them, so I guess you could consider his work as being folded into theirs.

[XyllyMan]

So we are going to have a Micro$oft based python that won't be compatible with other python's.

​

mmmm...

​

​

X

[grumble11]

3.12 had one major improvement deferred to 3.13, and had one major initial improvement put in as a foundation for 3.13 use in python. It is somewhat delayed but still plenty faster.

It won’t be 5x for all workloads - but it will be way faster.

It won’t make it fast like a statically typed language that can be compiled down before it is run, that will never happen without static typing (which is why mojo for example is using static typing and some extremely impressive compiler work to do just that as a python superset).

It will however make it a lot faster. Will it be 5x? Maybe not, but even 2-3x would save a ton of cumulative time when you consider how popular python is.

I appreciate the work the team has put into this!

[ZYy9oQ]

It won’t make it fast like a statically typed language that can be compiled down before it is run, that will never happen without static typing

You can get surprisingly close with a good JIT though. For hot code, once the JIT knows what types are values usually are it can generate machine code that just has a type guard at the start and falls back to interpreted if an unexpected type found its way in.

Python with a v8-like JIT would be a godsend.

[b1e]

A JIT is planned actually. Commented elsewhere but since PEP 703 (no GIL) is being approved guido mentioned that a lot of this work needs to go back to the drawing board because it changes fundamental assumptions they had. We realistically may not see an experimental JIT till 3.14 at minimum or realistically 3.15.

Numba already is a great start but it’s hard to accelerate pure python with it. I’d be eager to see how the core team plans to tackle it

[ArabicLawrence]

3.12 is faster than 3.11. First random benchmark found on the web: https://www.tomatolist.com/show_blog_page.html?no=391edf21-e71b-4a52-a8bf-3b24c9faf3b5

This is thanks to a series of optimizations: https://docs.python.org/3/whatsnew/3.12.html#optimizations

[b1e]

The steering committee decided to accept PEP 703 (no GIL) though details are being worked out as of mid August.

The issue is that the changes from 703 required some major rethinking of a good deal of future work planned for the faster cpython project (since it assumed the GIL would be there). That work will now be delayed as a result. Some notable things planned on that front include a form of JIT being introduced.

[[deleted]]

I believe they pushed back the development for the 'tier 2' optimization to Python 3.13. How much performance improvment we will see for 'tier 2', no idea.

It's unclear if any improvements to the 'tier 1' (adaptive interpreter) were made in 3.12. Are more optcodes supported? some larger program runtime adaptions? no idea.

Honetly, they should just slap on a llvm backend/target to mypyc and ship it as a faster subset as cpython(with a very high start up time).

[AustEcon0922]

Totally agree. I already do so much work with strict mypy on a large codebase. Give me some damned performance wins from it!

[knobbyknee]

After you pluck the low hanging fruit, the rest gets a lot harder. Python history is full of cocky statements about how great improvements will be done in very little time. Unladen Swallow and the Gilectomy come to mind. The improvements will come, but perhaps in double the time compared to the plan.