multithreading - Java multithreaded rendering, how to optimize -

multithreading - Java multithreaded rendering, how to optimize -

i working on fractal rendering software. basic setup have big 2-dimensional array (picture), values incremented.

the simple rendering process

while( iteration < maxiteration ) { update pixel in array; }

this stupidly simple parallellize; have several threads simultaneously, since each thread (very likely) work different pixels @ same time, , if there update collision in array, fine. the array shared among threads!

however, maintain track of total number of iteratins done, need iteration volatile, suspect slows downwards code little.

what baffels me virtually same speed 4 threads , 16 threads, , run on 64-core machine, verified runtime.getruntime().availableprocessors().

one issue have no command on in array threads work, hence, issue might big case cache misses? array of size of fullhd-image: 1920x1080x4 longs.

thus, seek possible issues, , solutions them, since think might mutual type of problem.

edit: code trying optimize available here (sourceforge). class threadcomputator represents 1 thread, , these iterations. number of iterations done stored in shared variable currentiteration, (in current code) incremented in synchronized block.

all threads write histogram object, big array of doubles. writing not need atomic, overwrites rare, , error tolerated.

i think you've answered own question.

because implement chaos game algorithm. means next pixel need work on depends non-deterministically on current pixel.

and have memory scheme on computer functionally random access; but, fastest performance possible if have localized (within cache pages) reads , writes.

i'd re-implement algorithm so:

get of desired writes "time instant", wrap them in class / info construction such can ordered , grouped memory page / cache line. generate list of memory pages requiring access. randomly assign to-be-accessed memory page thread. run updates page before thread works on memory page.

yes, won't 100% random anymore; can mitigate counting "write time" , assuming writes in same write time occurred simultaneously. still thrash memory pretty badly, @ to the lowest degree thrash less.

java multithreading performance