I reckon this is more comparable to the Ruby version:
from random import Random
from threading import Thread
rand = Random().random
THREADS, SIZE = 20, 100000
threads = []
class Test(Thread):
def __init__ (self):
Thread.__init__(self)
def run(self):
a = [rand()*SIZE for x in xrange(SIZE)]
a.sort()
def test():
for i in xrange(THREADS):
t = Test()
threads.append(t)
t.start()
for t in threads :
if t.isAlive() :
t.join()
if __name__=='__main__':
from timeit import Timer
t = Timer("test()", "from __main__ import test")
print "%.2f sec/pass" % (t.timeit(number=10)/10)
Which results in 5.48 sec/pass
Looking at cProfile, 50 or so calls to built-in method acquire takes an avg. 4.102 sec.
What would impress me would be a 2x gain in a 2 core machine, specially in threads that neither depend on each other nor share any data.
Anyway, as a Zope/Plone consultant, I would be delighted to see Python making an effort to better support multi-core CPUs. Obviously, I would love if Ruby did that too.
It is a small number of patches to the base MRI to enable better use of shared memory for forked processes, on operating systems that use copy-on-write semantics for fork. In particular, this optimization is exploited in the Phusion Passenger product that the same developers created. Phusion Passenger is kind of like mod_wsgi but using different process management.
It seems the developers are also trying to offer a higher level of support than is available for the base MRI. For example, they backported the recent security patches to an older version than the MRI developers were willing to do.
Kinda. It is really similar to mod_wsgi. It can run Ruby applications that implement the Rack interface (there is a Rails/Rack adapter). The Rack interface is just the Ruby port of WSGI, so it can also run any WSGI application (e.g. Django).
Looking at cProfile, 50 or so calls to built-in method acquire takes an avg. 4.102 sec.