Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman zzbbaadd at aol.com
Thu Sep 20 02:17:36 EDT 2007


2

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

>
> 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.

Is the only point in getting rid of the GIL to allow multi-threaded
applications?

Can't multiple threads also provide a performance boost versus
multiple processes on a single-core machine?

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

Ugh, I guess I have to agree with Steven D'Aprano - it depends.

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

OK, I can see that.

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

OK, have to agree. Sounds like it could be a good candidate for a
fork. One question - is it a computer science maxim that an
interpreter that implements multi-threading will always be slower when
running single threaded apps?

>
> And another question: why should such people spend time they do not have to
> make Python worse for themselves?

I can't make an argument for someone doing something for free that
they don't have the time for. Ditto for doing something for free that
they don't want to do. But it does seem that if they give a reason for
why it's the wrong thing to do, it's fair to make a counter-argument.
Although I agree with Steven D'Aprano's theme in that it should be a
cordial rebuttal and not a demand.





More information about the Python-list mailing list