Good demo for showing benefits of parallelism

[Philipp Spöth]

Kevin is right with his optimization ideas of course. But there is something else going on there. The native approach already should gain way more speed than Jascha describes. And even worse on my Core Duo on windows the tracer drastically looses time with more threads. With one thread on a 640x480 image it takes 11 seconds. With two threads it takes 86 seconds!

When looking at the process manager with 2 threads it shows that cpu usage is constantly only somehwere between 15% and 35%. Increasing priority of the threads in D doen't seem to do anything. Raising Priority in the process manager lifts cpu usage to near 100%. However it doesn't make the progam finish any faster.

There must be some implizit synchronising involved though I have no idea where and why.

 Jascha Wetzel <[firstname]@mainia.de> Wrote:


> Kevin Bealer wrote:
> > [...]
> > The goal is for all the threads to finish at about the same time.  If
> > they don't you end up with some threads waiting idly at the end.
> >
> > This would require reintroducing a little synchronization.
> > [...]
> 
> that's all very reasonable, thx.
> i changed the job distribution by dividing the image into a grid,
> assigning (equally sized) cells to threads in an extending spiral
> starting in the middle of the image. this is due to the assumption that
> the hardest cells are around the middle (which is the case for the test
> scene).
> the distribution of those cells is of course synchronized.
> new sources: http://mainia.de/prt_grid.zip
> 
> now everything is faster, even with one thread. but the speedup with
> more threads decreased (time stays about the same for 1-16 threads).
> still, i haven't quite "felt" the multicore performance.
> 
> meanwhile, a friend tells me, that his speedups with image processing
> algorithms and naive block assignment are close to 200%...
> 
> atm i suspect there's a more technical reason to that, something with
> the threading lib or the like...