To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part.
> On 8 Oct 2021, at 10:13, Steven D'Aprano <firstname.lastname@example.org> wrote:
> Hi Sam,
> On Thu, Oct 07, 2021 at 03:52:56PM -0400, Sam Gross wrote:
>> I've been working on changes to CPython to allow it to run without the
>> global interpreter lock. I'd like to share a working proof-of-concept that
>> can run without the GIL.
> Getting Python to run without the GIL has never been a major problem for
> CPython (and of course some other Python interpreters don't have a GIL
> at all).
On the first page of Sam's design overview he references Gilectomy by name.
> Single threaded code is still, and always will be, an important part of
> Python's ecosystem. A lot of people would be annoyed if the cost of
> speeding up heavily threaded Python by a small percentage would be to
> slow down single-threaded Python by a large percentage.
Quoting that same design document, Sam writes: "The new interpreter
(together with the GIL changes) is about 10% faster than CPython 3.9
on the single-threaded pyperformance benchmarks."
Python-Dev mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/JO7OQCHZKIFNKSXTTXT2JBCF5H47M7OO/
Code of Conduct: http://python.org/psf/codeofconduct/