Removing GIL is interesting work and probably multiple people are willing to contribute. Threading and synchronization is a deep topic and it might be that if just one person toys around with removing GIL he might not see performance improvement (not meaning to offend anyone who tried this, honestly) but what about forking a branch for this work, with some good benchmarks in place and have community contribute? Let's say first step would be just replacing GIL with some fine grained locks with expected performance degradation but afterwards we can try to incrementally improve on this.<div>
<br><div>Thank you,</div><div>Vlad<br><div><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 8:20 AM, Maciej Fijalkowski <span dir="ltr"><<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Aug 10, 2011 at 1:43 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Wed, Aug 10, 2011 at 7:32 AM, David Beazley <<a href="mailto:dave@dabeaz.com">dave@dabeaz.com</a>> wrote:<br>
>><br>
>> On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:<br>
>><br>
>>> On Wed, Aug 10, 2011 at 9:09 PM, David Beazley <<a href="mailto:dave@dabeaz.com">dave@dabeaz.com</a>> wrote:<br>
>>>> You're forgetting step 5.<br>
>>>><br>
>>>> 5. Put fine-grain locks around all reference counting operations (or rewrite all of Python's memory management and garbage collection from scratch).<br>
>>> ...<br>
>>>> After implementing the aforementioned step 5, you will find that the performance of everything, including the threaded code, will be quite a bit worse. Frankly, this is probably the most significant obstacle to have any kind of GIL-less Python with reasonable performance.<br>
>>><br>
>>> PyPy would actually make a significantly better basis for this kind of<br>
>>> experimentation, since they *don't* use reference counting for their<br>
>>> memory management.<br>
>>><br>
>><br>
>> That's an experiment that would pretty interesting. I think the real question would boil down to what *else* do they have to lock to make everything work. Reference counting is a huge bottleneck for CPython to be sure, but it's definitely not the only issue that has to be addressed in making a free-threaded Python.<br>
><br>
> They have a specific plan, based on Software Transactional Memory:<br>
> <a href="http://morepypy.blogspot.com/2011/06/global-interpreter-lock-or-how-to-kill.html" target="_blank">http://morepypy.blogspot.com/2011/06/global-interpreter-lock-or-how-to-kill.html</a><br>
><br>
> Personally, I'm not holding my breath, because STM in other areas has<br>
> so far captured many imaginations without bringing practical results<br>
> (I keep hearing about it as this promising theory that needs more work<br>
> to implement, sort-of like String Theory in theoretical physics).<br>
<br>
</div>Note that the PyPy's plan does *not* assume the end result will be<br>
comparable in the single-threaded case. The goal is to be able to<br>
compile two *different* pypy's, one fast single-threaded, one<br>
gil-less, but with a significant overhead. The trick is to get this<br>
working in a way that does not increase maintenance burden. It's also<br>
research, so among other things it might not work.<br>
<br>
Cheers,<br>
fijal<br>
<div><div></div><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/riscutiavlad%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/riscutiavlad%40gmail.com</a><br>
</div></div></blockquote></div><br></div></div></div>