New submission from 0x666 vasiliauskas.agn...@gmail.com:
I think something wrong with implementation of multiprocessing module.
I`ve run this very simple test on my machine (core 2, vista):
import multiprocessing as mul
from time import time
def f(x):
return x*x
if __name__ == '__main__':
Changes by Jesse Noller jnol...@gmail.com:
--
assignee: - jnoller
nosy: +jnoller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5000
___
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
The multiprocessing module indeed has some overhead:
- the processes are spawned when needed. Before you perform performance
timings, you should warm up the Pool with a line like
pool.map(f, range(mul.cpu_count()))
(starting a
Jesse Noller jnol...@gmail.com added the comment:
My results don't match yours. (8 cores, Mac OS/X):
testing multiprocessing on 8 cores --
10 elements map() time 0.0444118976593 s
10 elements pool.map() time 0.0366489887238 s
10 elements pool.apply_async() time
Jesse Noller jnol...@gmail.com added the comment:
Closing as not an issue.
--
resolution: - invalid
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5000
___
Changes by Benjamin Peterson benja...@python.org:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5000
___
___
0x666 vasiliauskas.agn...@gmail.com added the comment:
Thanks for quick response and for informative answers, especially
thanks to Antoine Pitrou/Amaury Forgeot.
p.s.
By seting bigger range - range(15) and elements = 1000, I was able to
get speed-up factor up to 1.8. Wow, I`m amazed :-)
Good
