gh-150865: Add PyUnstable_Immortalize - #160138

Documentation build overview

📚 cpython-previews | 🛠️ Build #35331167 | 📁 Comparing a41538d against main (aed4ad8)

  🔍 Preview build  

Hi @ZeroIntensity thank you for the PR.

Immortal types are fixing the free-threaded slowdown for both PRs numpy/numpy/pull/32853 and numpy/numpy/pull/32552 about as well as the tp_free trick.

Benchmarks:

numpy/numpy/pull/32853 types (flagsobj, _array_converter), free-threaded, million calls/s**

linspace, unique and delete show no difference beyond noise in any build.

numpy/numpy/pull/32552 types (neighborhood iterator, MapIter), free-threaded, million calls/s**

GIL build, one thread, ns per call (lower is better)

import numpy takes the same time in every build (about 58 ms free-threaded, 52 ms GIL).

@ZeroIntensity wasn't there another approach you were thinking about for this?

Per our discussion during the sprint, I think we reached a consensus that NumPy can use static types for things it would otherwise immortalize, right? As far as I can tell, it should be possible to share third-party static types across interpreters; the only requirement for subinterpreters is to use multi-phase initialization, which doesn't disallow static types. (If you find bugs with that, we should fix those!)

@prathamhole14 @mattip does that work for you two?

As far as I know, static types are incompatible with the limited API. If CPython wishes to allow c-extension authors to support subinterpreters, free-threading, and the limited API in a performant way, I think we need to be able to declare heap types immutable and immortal.

The limited API already has performance problems (all the Py_INCREF calls can't be inlined, for example), which is why you should distribute per-version wheels anyway. Could NumPy use heap types when compiling for the limited API, and then use static types otherwise?