Home Original page

Jython, GILs and object locking.

Harri Pesonen fuerte at sci.fi
Wed Oct 15 14:54:53 EDT 2003 
Michael Chermside wrote:
> I (Michael Chermside) wrote:
> 
>>I don't think that people ARE saying that. I think that if
>>you polled, most of the python developers would say that
>>the GIL is an unfortunate limitation, but one which is
>>particularly difficult to remove, since so MUCH of the
>>Python interpreter is written with the assumption that
>>the GIL is used.
> 
> Harri replies:
> 
>>I will remove GIL from Python. I have a Python script that 
>>[...] but eventually we have a GIL free Python (I call it 
>>Viper). I don't think that removing GIL is hard, on the 
>>contrary. The job is trivial but tedious.
> 
> Wonderful!! Don't let my words of negativism disuade you...
> this is an excellent project. Once you finish getting Viper,
> to work properly, there will probably be some additional time
> required to address any performance problems that might arise.
> If you can get rid of the performance problems, then I'd
> guess you have an excellent chance of just getting your changes
> adopted into the main branch of Python! Of course, that assumes
> that you've first demonstrated that it works, and that it
> doesn't make performance substantially worse for those with
> just one processor. So there IS work to be done, but if you
> can handle it, than all power to you, and THANKS!

It will be faster because there is no need to Py_INCREF(Py_None) or 
Py_DECREF(Py_None) or other static variables, and because there is no 
GIL or thread state swapping, but it will be slower because there will 
be an extra state argument in function calls. I guess the speed will be 
about the same for single-threaded programs. The real advantage comes of 
course from free-threading.

Harri
More information about the Python-list mailing list