[Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

[Antoine Pitrou]

Jeffrey Yasskin <jyasskin <at> gmail.com> writes:
> 
> Over an 8-year lifetime for Python 3, Moore's law predicts that
> desktop systems will have up to 64 cores, at which point even the
> simplest GIL-removal strategy of making refcounts atomic will be a
> win, despite the 2x performance loss for a single thread.

That's only if you think all workloads parallelize easily (and with little work
from the average programmer), which sounds a bit presumptuous. When you have a
GUI application and the perceived performance is driven by UI responsivity,
spawning dozens of threads can little to improve the picture ("GUI application"
here can mean a feature-rich Web application, too).

As for desktop systems having 64 cores, that's unless the available die space
gets used for something else instead, e.g. an integrated GPU. Or unless the
desktop dies in favor of something else (e.g. laptops with small tightly
integrated chips). The former is already in AMD's and Intel's plans. The latter
could be happening right now.

And we're not even talking about embedded platforms, or virtual machines where a
64-core server is partitioned into 64 "single-core" systems.

(and then there's the whole threading vs processing debate ;-))

Endly, removing the GIL means you have to make all base types (especially
containers) thread-safe without sacrificing their performance. I don't think
it's just about reference-counting.


That said, the Py_Incref() and Py_Decref() functions already exist. Perhaps they
should be advertised a bit more in the documentation. The day a hypothetical
Python implementation gets rid of reference-counting while remaining binary
compatible with the rest of the API (which rules out PyPy), and gets much faster
in the process, I think people will happily suffer a small recompile.

Regards

Antoine.