Microsoft’s support for Faster CPython is cancelled It's been a tough couple of days. Microsoft's support for the Faster… | Mike Droettboom | 45 comments .
I think it was a nice thing while it lasted. Just a recap: Python 3.14 is roughly 20-40% faster than 3.10 (when this project first started). I want to thank everyone who contributed to the project in some form or another — not just those at MS. The impact on the world of computing cannot be overstated.
We have a few options now (non-exhaustive):
- Finding another sponsor (unlikely it seems, unless we get an altruistic billionaire).
- Shutting down the ongoing experimental strands of work.
- Continuing with community stewardship.
As the title suggests, I’m in favour of option 3. If somehow option 1 happens in the next few months, then we can just ignore this post then.
Community Ownership of Faster CPython
While waiting for some other sponsorship to happen, or if that never happens. I propose we transfer Faster CPython to a community-owned model.
The steps are the following:
- Form a performance-wg, to replace the weekly Faster CPython syncs with MS and Meta. Meta could also host these if they wish to. Weekly/bi-weely meetings across people working on performance have proven to be extremely useful to resolve conflicts and gather consensus on performance design decisions. This WG has no decision-making power.
- Set up PSF-owned benchmarking infra. ARM has already graciously loaned/donated a benchmarking machine (thanks to Diego). We can use that to continue the existing benchmarking work. Thanks also to Mike, Thomas, and Matt the
bench_runner
infra is open source and has good documentation to set it up. - Explore the next design choices for the JIT.
The design choices have to be radically shifted to assuming no corporate sponsorship. This means we prioritise maintainability of the JIT, over peak performance.This takes a backseat. Community is more important right now.
For the performance-wg. I propose we have a community council, responsible for conflict resolution mediation and also the technical direction of the community Faster CPython project. I am modelling this after the typing council (PEP 729). We should have 5 members from varying backgrounds to decentralize power. These backgrounds should ideally represent free threading, the JIT, and various other stakeholders. Note that this WG has no decision-making power, it will simply be a conflict mediation and discussion gathering point. I nominate myself to the initial community wg in the transition period, as I am the longest non-corporate community volunteer in the Faster CPython project (~3 years volunteer, ~6 months or so working on free-threading by Quansight), and I have contributed to the specializing interpreter, the JIT’s optimizer, the tail-calling interpreter, and deferred reference counting (free-threading). I withdraw my self-nomination to the informal WG, and instead nominate Mark Shannon.
I believe it’s possible for this project to be community-led. We have excellent community JIT contributors in the form of Tomas Roun, Savannah, Pieter, and many more. I often look to PyPy for a project that has performance wins, but is led by a smaller (though still very dedicated) community team.
If this proposal receives strong opposition, I will discard the idea. If this proposal garners enough support, I will ask for nominations one three week from now, and we can draft a perf-wg PEP set up informal wg meetings.
TLDR
I propose for the formation of an informal WG that has no decision making power, that is merely just to facilitate ongoing collaboration and discussion among various parties concerned with CPython performance. This WG will succeed the role of Mike Droetboom, who has been an awesome mediator these past few years in Faster CPython.