Ideally on good multi-processor machines, you see a pretty good speedup.
But multi-core machines are a problem: though you have multiple cores,
you only have one memory controller, and usually quite a crummy one. So
if all the cores are fetching tons of stuff from non-cached memory (as
is often the case in EC), it's a bad bottleneck.
We see a similar problem in MASON, by the way: even if you have a bunch
of threads, if they're fetching a lot of non-cached RAM, you're in trouble.
Still, 25% faster doesn't sound quite right. For grins, I just ran
ecsuite on my two-core Macbook Pro:
time java ec.Evolve -file ecsuite.params -p pop.subpop.0.size=30000 -p
evalthreads=1 -p breedthreads=1 -p seed.1=4 -p generations=20
10.904u 0.212s 0:11.28 98.4% 0+0k 0+12io 8pf+0w
10.718u 0.241s 0:08.67 126.2% 0+0k 0+9io 8pf+0w
11.464u 0.280s 0:07.88 148.9% 0+0k 0+1io 8pf+0w
So, 7.88 seconds vs 11.28 seconds. That's 43% faster, on a very
fast-evaluating problem no less. Which is about right for a typical
two-thread problem in most systems. Could it be your computer architecture?
So: how long are your evaluations? How much memory are you using per
evaluation? How much memory have you given the VM? What kind of
representation are you using? Are you also doing multithreaded
Cem Safak SAHIN wrote:
> I have question related to the multithreading. I am using 8-core machine.
> When I spawn 2 threads (evalthreads), the timing results are getting
> better (25% better). However, if I spawn more than 2 threads, the timing
> results are getting worst than no-multithreading case. More threads result
> in degradation at the timing results. When I googled about the multi-
> threading in ECJ, I found some answers in the archive files. Basically,
> they were saying that (Population Number)/(Number of threads) processes at
> the same time. Is there any known reason or similar experiment after a
> certain number of multi threads, there is some degradation in the timing