ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> python-dev
python-dev
Re: [Python-Dev] Reworking the GIL
by Antoine Pitrou other posts by this author
Nov 7 2009 7:09AM messages near this date
Re: [Python-Dev] Reworking the GIL | Re: [Python-Dev] Reworking the GIL
Hello,

>  Solaris X86, 16 cores: some python extension are likely missing (see 
config.log)
>  Windows XP SP3, 4 cores: all python extensions but TCL (I didn't bother
checking why it failed as it is not used in the benchmark). It is a release 
build.
>  
>  The results look promising but I let you share your conclusion (some latency
results seem a bit strange from my understanding).

Thank you! The latency results don't look that strange to me.

If you're surprised that py3k shows better latency than newgil on the "pi
calculation" workload, it's easy to understand why: py3k speculatively releases
the GIL so often on that workload (every 100 opcodes) that the latencies are
indeed very good, but if you look at the corresponding throughput numbers they
are dismal (your Solaris box shows it falling to less than 20% with two threads
running compared to the baseline number for single-thread execution, and on your
Windows box the number is hardly better with 45%).

So, to sum it up, the way the current GIL manages to have good latencies is by
issueing an unreasonable number of system calls on a contended lock, and
potentially killing throughput performance (this depends on the OS too, because
numbers under Linux are not so catastrophic).

The new GIL, on the other hand, is much more balanced in that it achieves rather
predictable latencies (especially when you don't overcommit the OS by issueing
more computational threads than you have CPU cores) while preserving throughput
performance.

>  Side-note: PCBuild requires nasmw.exe but it no longer exists in the latest
>  version. I had to rename nasm.exe to nasmw.exe. Would be nice to add this to
>  the readme to avoid confusion...

You should file a bug on http://bugs.python.org

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40maillist.acti
vestate.com
Thread:
Antoine Pitrou
Stefan Ring
Stefan Ring
Nick Coghlan
Antoine Pitrou
Antoine Pitrou
Antoine Pitrou
Baptiste Lepilleur
Antoine Pitrou
Baptiste Lepilleur
Guido van Rossum
Antoine Pitrou
Guido van Rossum
Baptiste Lepilleur
Antoine Pitrou
Antoine Pitrou
Sturla Molden
John Arbash Meinel
Antoine Pitrou
Antoine Pitrou
Jeffrey Yasskin
martin
Antoine Pitrou
martin
Gregory P. Smith
Antoine Pitrou
Christian Heimes
Christian Heimes
Brett Cannon

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved