[Python-Dev] Variant of removing GIL.

Luis P Caamano lcaamano at gmail.com
Sat Sep 17 18:32:11 CEST 2005

On 9/17/05, python-dev-request at python.org <python-dev-request at python.org> wrote:
> Message: 9
> Date: Fri, 16 Sep 2005 21:07:23 -0500
> From: skip at pobox.com
> Subject: Re: [Python-Dev] Variant of removing GIL.
> Message-ID: <17195.31323.202978.650080 at montanaro.dyndns.org>
>     Martin> However, this is really hard to do correctly - if it were
>     Martin> simple, it would have been done long ago.
> I don't believe difficulty is the only (or primary) barrier.  I think
> *someone* would have tackled it since Greg Stein did back in 1.4(?) or his
> free-threading changes would have been incorporated into the core had they
> yielded speedups on multiprocessors and not hurt performance on
> uniprocessors.
> Skip

It did yield speedups on multiprocessors.  The uniprocessor part
could've been solved just like most kernels do, one binary for
UP and another for MP.  That's what IBM, RedHat, Solaris, and
almost all other modern kernels that support SMP machines

In theory, if we had those changes in the CPython interpreter, we
could've been running at 1.6 times the speed on dual processor
machines today (according to Greg's benchmark data) and at the
same speed on UP machines running the UP compiled CPython
interpreter, which would not have had all the locking calls not
needed on a UP machine that would hurt its performance.

By now, we probably could've improved on the scalability of
MP performance when running on machines with more
than three processors.

Mind you though, I'm not trying to oversimplify the issue.
I was not using python yet at that time (I started around
1.5/1.6) and I didn't see all the info involved in the decision
making process, so I'm sure there were other issues that
contributed to the decision of not keeping Greg's free
threading changes.

My point is that not yielding speedups on multiprocessors
and hurting performance on uniprocessors is not a good
or valid reason to drop free-threading.

Luis P Caamano
Atlanta, GA USA

More information about the Python-Dev mailing list