This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brian.curtin, jnoller, kevinwatters, lemburg, nascheme, pitrou, rcohen, schmir
Date 2010-01-22.20:26:16
SpamBayes Score 5.2976493e-06
Marked as misclassified No
Message-id <1264192046.3526.53.camel@localhost>
In-reply-to <4B5A0456.6000308@egenix.com>
Content
> Just use some conversion formula, e.g. switching interval in micro
> seconds = constant * byte code check interval. We can then determine
> a constant to match todays CPU performance.

Well, there are two problems:
- opcode execution cost varies so wildly that trying to pick up an
average would be meaningless (it can vary by many order of magnitudes
between e.g. a POP_TOP and a CALL_FUNCTION calling a C extension method)
- the interval doesn't have the same effect in the new GIL as it has in
the old GIL; in the old GIL, it merely gives the OS a chance to switch
threads if it wants to (there are many missed opportunities, by a
proportion which will be system-dependent); in the new GIL, thread
switching is enforced which means it is not necessary to stop so often.

So we'd have a formula like:

new GIL interval = old GIL interval * opcode duration / proportion of
missed switching opportunities in the old GIL

where two of the three factors on the right side are totally
unpredictable :)

> Perhaps I'm missing some feature of the new GIL. Is there some
> documentation for it somewhere ?

Almost nothing besides what is found in ceval_gil.h and in the following
thread:
http://mail.python.org/pipermail/python-dev/2009-October/093321.html
Dave Beazley did a high-level presentation about it:
http://www.dabeaz.com/python/NewGIL.pdf

> > Well, if you don't use any threads you don't have to change the setting
> > in the first place :-). You might want to do it in order to
> > "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
> > is unnecessary with the new GIL, since the interval is ignored when
> > there's only one thread running.
> 
> Hmm, how do you determine that only one thread is running ?

Actually, I don't determine it, it's a side effect of how the GIL is
implemented. If no thread is waiting for the GIL, the main thread isn't
"asked" to drop it.

> What if an extension uses threads that are not under Python
> control, e.g. when embedding the JVM or when using a CORBA
> ORB ?

These don't wait for the GIL, hopefully :-)
History
Date User Action Args
2010-01-22 20:26:19pitrousetrecipients: + pitrou, lemburg, nascheme, schmir, kevinwatters, jnoller, brian.curtin, rcohen
2010-01-22 20:26:17pitroulinkissue7753 messages
2010-01-22 20:26:16pitroucreate