Davide,
Thanks for posting your numbers. I think they are interesting and the 11x
speedup for 16 threads is not bad, however the overhead of STM is still too
high compared to PyPy.
well, yes and no: richards.py runs 30x faster on PyPy than on CPython. The
more typical speedup of PyPy is 5x, so If I can get an 11x speedup instead,
I'm already pretty happy.
In particular, my main interest is as always legacy C++. Remi's thesis shows
how one can build higher level structs to control commits. Iow., I can offer
the Python user thread-safe access to non-thread-safe C++ without forcing a
use pattern on him. Now, if the bulk of the time spent is not in Python in
the first place, the overhead may very well not be "too high."
Needs to be proven, and of course the lower the overhead the better, but I'm
rather optimistic. :)
I think for this purpose you need the best timing, not the average,
especially if you are using a desktop/laptop.
Yes, I know: with Intel's version of OpenMP for example, affinity is set to
threads on start, not on creation. Short benchmarks tend to be consistently
off in individual runs when the assignment ends up unbalanced.
The point was more that the last couple of digits in the timing, although
printed, are largely noise. And thus that PyPy-2.1 didn't start slowing down
for 2000 iterations as the numbers otherwise suggest.
Best regards,
Wim
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
