[Python-Dev] Making the GIL faster & lighter on Windows

[Glenn Linderman]

On approximately 5/26/2009 12:48 PM, came the following characters from 
the keyboard of Phillip Sitbon:
> Hi everyone,
> 
> I'm new to the list but I've been embedding Python and working very
> closely with the core sources for many years now. I discovered Python
> a long time ago when I needed to embed a scripting language and found
> the PHP sources... unreadable ;)

...

> I've given this a shot already while doing some concurrency testing
> with my ISAPI extension (PyISAPIe). First of all, nothing looks broken
> yet. I'm using my modified python26.dll to run all of my Python code
> and trying to find anywhere it could possibly break. For multiple
> concurrent requests against a single multithreaded ISAPI handler
> process, I see a statistically significant speed increase depending on
> how much Python code is executed. With more Python code executed (e.g.
> a Django page), the speedup was about 2x. I haven't tested with varied
> values for _Py_CheckInterval aside from finding a sweet spot for my
> specific purposes, but using 100 (the default) would likely make the
> performance difference more noticeable. A spin mutex also does well,
> but the results vary a lot more.
> 
> Just as a disclaimer, my tests were nowhere near scientific, but if
> anyone needs convincing I can come up with some actual measurements. I
> think at this point most of you are wondering more about what it would
> break.
> 
> Hopefully I haven't wasted anyone's time - I just wanted to share what
> I see as a possibly substantial improvement to Python's core. let me
> know if you're interested in a patch to use for your own testing.


I wonder if the patch could be structured as a conditional compilation? 
  You know how many different spots are touched, and how many lines per 
spot.

If it could be, then theoretically it could be released and people could 
  do lots of comparative stress testing with different workloads.


-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking