Dabeaz

Tell me when there's a video up.

I never got the point of reading slides without the presentation to be honest.
 

I'd rather have slides than a video any day. Thanks, and very exciting developments!
 

Just FYI, these slides do not show up correctly for me (they are just black squares) on Ubuntu 9.10 using Document Viewer 2.28.1.
 

@Adam: That's a bit odd. Debian Squeeze and 2.28.1 here too, and it works. Are the squares filled in or not? If it's just a black 'border', there's probably an issue with displaying the text.
 

Heh, http://www.dabeaz.com/python/GIL.pdf has the problem Adam described for me tho, the squares are filled in instead of just borders. You can read it anyway by selecting the text.
 

ubuntu 9.10 here and the PDF displays fine, nothing awry...
 

It's still GIL but it seems a lot better than the old one.
 

hey, thanks! finally a good summary of the how and why of the new GIL.
 

Still disappointing. When can we get a real, robust threading model?
 

kev009,
I'm guessing you won't get that until Python picks up something like Perl 5's style of threading where you're cloning the interpreter for each thread and specially designating data to share.

With shared interpreter internals, only one interpreter really gets to run at a time.

OTOH, if there's an even better way, I'd love to learn it. I use Perl and Ruby but not Python. I've been mildly following the Python GIL since it's actually pretty close to Ruby's (both Ruby 1.8 and 1.9). In Ruby 1.8 there was only green threads which isn't really anything at all. In Ruby 1.9 there are real threads but they're contending for a GIL.

Perl's threads are real threads and don't contend for a GIL but remain safe because they each have a clone of the interpreter. They become significantly more annoying in practice because actually sharing data between threads becomes non-trivial since the default must be to not share data.
 

Great slides. Looking forward to seeing this in person at PyCon. On slide 2-25, you say "First thread to timeout after Thread 2 starts makes the drop request." Looking at the diagram, I'm guessing what you meant to say was "First thread to timeout which started after Thread2 makes the drop request."
 

Great presentation! Very thoughtful, clear, and concise.
 

check: http://paste.pagenoare.net/default/show/179
and source: http://paste.pagenoare.net/default/show/177

i have on my debian box somewhat different results than presented in .pdf
 

Why would you expect to get the same result in the slides when you're using Python 3.1 and the slides say the new GIL is only available in Python 3.2 (available only through subversion checkout)?
 

that was not about 3.2 and new gil, but about not so 1.8x difference on 3.1/2.6.

but in unladen (todays trunk) - results are much worse...
 

The performance numbers in the talk are the same as the previous GIL talk which was carried out on a Mac OS-X 10.5 system. The numbers will obviously vary if you go to different platforms due to differences in the operating system implementation.
 

As i can see - worst implementation can be spotted on macs. So in your case, you hit the exaggerated results ;)

It's probably connected with poor macosx performance in pthreads.

Btw. If you want little more accurate benchmarks - try http://codespeak.net/svn/pypy/trunk/pypy/translator/goal/gcbench.py

pypy also needs new gil, but even without it - pypy-jit on 32bit linux is 10x faster than 2.6 cpython in sequential mode, so also 10x faster than 3.2newGil in both modes...

This look that pypy is ours only hope for modern interpreter in future. 3.x and binladen looks like have chosen the wrong direction...
 

Well, please don't make it sound like there was some kind of conspiracy to make the results look worse by running tests on a Mac. A Mac is what I use so that's what I ran the tests on. I've had students in classes run the same tests on various machines (Linux, Windows, etc.) and they all get varying degrees of performance degradation--sometimes worse than the numbers I reported, sometimes better.
 

Sorry, that was not my intention ;)

From my experience - worst case would be windows pre nt (95/98/millenium).