Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman zzbbaadd at aol.com
Thu Sep 20 00:42:43 EDT 2007


On Sep 19, 5:08 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> "Terry Reedy" <tjre... at udel.edu> wrote in message

This is a little confusing because google groups does not show your
original post (not uncommon for them to lose a post in a thread - but
somehow still reflect the fact that it exists in the total-posts
number that they display) that you are replying to.


>
> This assumes that comparing versions of 1.5 is still relevant.  As far as I
> know, his patch has not been maintained to apply against current Python.
> This tells me that no one to date really wants to dump the GIL at the cost
> of half Python's speed.  Of course not.  The point of dumping the GIL is to
> use multiprocessors to get more speed!  So with two cores and extra
> overhead, Stein-patched 1.5 would not even break even.
>
> Quad (and more) cores are a different matter.  Hence, I think, the
> resurgence of interest.

I am confused about the benefits/disadvantages of the "GIL removal".
Is it correct that the GIL is preventing CPython from having threads?

Is it correct that the only issue with the GIL is the prevention of
being able to do multi-threading?

If you only planned on writing single-threaded applications would GIL-
removal have no benefit?

Can threading have a performance benefit on a single-core machine
versus  running multiple processes?

> So now this question for you:  "CPython 2.5 runs too slow in 2007: true or
> false?"

I guess I gotta go with Steven D'Aprano - both true and false
depending on your situation.

> If you answer false, then there is no need for GIL removal.

OK, I see that.

> If you answer true, then cutting its speed for 90+% of people is bad.

OK, seems reasonable, assuming that multi-threading cannot be
implemented without a performance hit on single-threaded applications.
Is that a computer science maxim - giving an interpreted language
multi-threading will always negatively impact the performance of
single-threaded applications?

>
> | Most people are not currently bothered by the GIL and would not want its
> | speed halved.
>
> And another question: why should such people spend time they do not have to
> make Python worse for themselves?
>
Saying they don't have time to make a change, any change, is always
valid in my book. I cannot argue against that. Ditto for them saying
they don't want to make a change with no explanation. But it seems if
they make statements about why a change is not good, then it is fair
to make a counter-argument. I do agree with the theme of Steven
D'Aprano's comments in that it should be a cordial counter-argument
and not a demand.





More information about the Python-list mailing list