cinder VS faster-cpython

They’ve kind of done that with Cinder https://github.com/facebookincubator/cinder. Threads and Instagram lie on top of this and it’s essentially a fork of Python 3.10.

I think the problem there is even a company like Meta wants to rest on the shoulders of the giant Python community. It makes sense for Meta to try to get parts of Cinder into Python.

I used to work on the Cinder JIT and can help document any passes you find interesting or confusing.

Have a look at Cinder - https://github.com/facebookincubator/cinder - it's Meta's performance oriented fork of CPython that they use to run Instagram (which is a big Django app).

You might enjoy Cinder then. It's based on CPython so it is nearly 100% compatible.

https://github.com/facebookincubator/cinder/

Disclaimer: I used to work on it.

I think Cinder's Static Python, which also performs runtime type checking, is more ambitious. Though it's not production ready yet.

Here's a fork that implements that https://github.com/facebookincubator/cinder - it might be nice to one day get that up streamed but obviously it'll be controversial and it certainly needs more time to bake. Hopefully at some point we can make it a pip installable extension though.

The other thing that was interesting to me, was the potential of type annotations to help make for a faster, safer experience on the compiler end of things. One example is seen in Meta’s Cinder project, on the docs it explains how typing can be used to reduce the number of steps for the compiler ([cinder/static_python.rst at cinder/3.8 · facebookincubator/cinder · GitHub](https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/static_python.rst)), making it more effective.

Instagram is a huge Django app and unlike all the ML libraries, Django isn't highly optimized low-level code wrapped in Python, at least not by default. That's why Facebook are putting so much work into running a more performant fork of CPython - https://github.com/facebookincubator/cinder

It is unclear to me whether Python 3.12 will receive significant improvements. Based on the information from https://github.com/faster-cpython/benchmarking-public, it appears that there may be a 2% performance enhancement. Is this the anticipated result, or are there additional developments awaiting merger?

Initially, the "Shannon Plan" (https://github.com/markshannon/faster-cpython/blob/master/pl...) aimed for a 50% improvement with each release. Has this goal been deemed unattainable, or are there adjustments being made to the plan?

see: https://github.com/markshannon/faster-cpython/blob/master/plan.md

Yes, the Shannon plan, which is actively being worked on by a team headed by Guido, includes JIT work in stages 3 and 4

The goal with faster cpython is for small compounding improvements with each point release[0]. So in the end it should be much more than a tiny improvement.

[0] https://github.com/markshannon/faster-cpython/blob/master/pl...

The Shannon Plan. Announced by Guido at the 2021 Python Language summit, funded by Microsoft.

Well, good news then, it's in the planning!

The faster-cpython plan includes adding a simple JIT in Python 3.12.

But a JIT is already planned for a future release it’s just there’s a ton of other improvements they can do to speed it up first. See: https://github.com/markshannon/faster-cpython/blob/master/pl... where the plan is detailed.

Between this link and the OP, we're seeing the first improvements to drop from Mark Shannon's Microsoft-funded full-time work on CPython optimization, alongside Eric Snow and Guido van Rossum:

https://www.theregister.com/2021/05/19/faster_python_mark_sh...

https://github.com/markshannon/faster-cpython/blob/master/pl... - indicates that this is step 2 of 4, where the forthcoming steps actually plan to introduce JIT compilation!

From the OP Changelog:

- bpo-44590: All necessary data for executing a Python function (local variables, stack, etc) is now kept in a per-thread stack. Frame objects are lazily allocated on demand. This increases performance by about 7% on the standard benchmark suite. Introspection and debugging are unaffected as frame objects are always available when needed. Patch by Mark Shannon.

And from the What's New:

- “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.)

- Method calls with keywords are now faster due to bytecode changes which avoid creating bound method instances. Previously, this optimization was applied only to method calls with purely positional arguments. (Contributed by Ken Jin and Mark Shannon in bpo-26110, based on ideas implemented in PyPy.)

Really, really exciting beginnings. I can't wait to see what's next!

It seems like the optimizations mentioned in the Faster CPython project aren't mentioned in that changelog. Are they going to be hitting the 50% speedup that they were pushing for?

https://github.com/markshannon/faster-cpython/blob/master/pl...