from multiprocessing import Pool
p = Pool(4) # 4 worker threads
p.map(somefunc, someiter)
Not sure if this is apples-to-apples. Regardless, I'm always skeptical of the behavior of threaded code, even if it's embarrassingly parallel stuff that is divided among workers.
Unfortunately the multiprocessing module is a lot less efficient in many cases. Scala doesn't have to copy the entire collection across process boundaries or launch the runtime multiple times. (In this particular rather trivial example it doesn't matter much because an Int range is used). I'm afraid Python is losing out in the parallel world due to the GIL as more CPU cores become the norm.
for what it's worth, there's nothing magical (or random) about computer languages - they tend to become more stable over time because they (1) reach some level of internal consistency and (2) become more popular (pressure for backwards consistency).
so yes, it probably is possible to answer this question to some degree if you've been watching scala grow. i haven't, which is why i asked.
16 comments
[ 2.9 ms ] story [ 46.8 ms ] threadWhat?
That help? ;-)
using the standard Control.Parallel.Strategies library (use rwhnf instead of rseq unless you are using v3).
so yes, it probably is possible to answer this question to some degree if you've been watching scala grow. i haven't, which is why i asked.
THAT part of it I hate; we, as programmers, often rely far too heavily and broadly on mapping what we see to what it means. Call stuff what it is.