Antoine Pitrou <pit...@free.fr> added the comment: Just a quick test under Linux (on a dual quad core machine): - with iotest.py and echo_client.py both running Python 2.7: 25.562 seconds (410212.450 bytes/sec) - with iotest.py and echo_client.py both running Python 3.2: 28.160 seconds (372362.459 bytes/sec)
As already said, the "spinning endlessly" loop is a best case for thread switching latency in 2.x, because the opcodes are very short. If each opcode in the loop has an average duration of 20 ns, and with the default check interval of 100, the GIL gets speculatively released every 2 us (yes, microseconds). That's why I suggested trying more "realistic" workloads, as in ccbench. Also, as I told you, there might also be interactions with the various timing heuristics the TCP stack of the kernel applies. It would be nice to test with UDP. That said, the observations are interesting. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7946> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
