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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com