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

[Jeffrey Yasskin]

On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 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.

Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
I don't think changing the definition of Py_INCREF and Py_DECREF
justifies going to Python 4.0, so I don't think their definitions
should be part of the ABI. If that's not what the ABI means, that's ok
too.