clipka wrote:
[...]
> I guess the impact of this could be reduced by increasing the number of
> frames per job package.

That's my evil plan.  ;)

>  > I also anticipate decreased performance on images with
> > (single-thread) parse times approaching trace times.
>
> Why should that /decreasse/ performance? At present, parsing is done
> over and over again for each image anyway. (Of course it will not max
> out the node while parsing, but this would be the case on a single-node
> system as well.)

I'm thinking of it this way.  Suppose a frame takes 1 second to parse, and 64
seconds for one thread to trace.  On a single-core machine, it's 65 seconds
total; on eight cores it's about (1+64/8) 9 seconds and about 90% utilization of
all cores.  Now consider the reverse, 64 seconds to parse, and 1 to trace.  The
total time is the same 65 seconds for a single core machine, but at best
(64+1/8) 64.125 seconds on the eight-core, with barely over 12% utilization.

> Hmm... it might be an interesting idea for animations to have POV-Ray
> run parse threads for a number of frames in parallel (depending on
> available cores), then render the batch of frames.

That would be a good way to approach it, I think.  The TACC folks made a pretty
big deal about trying to structure your message-based (MPI) multiprocessing
application to pass fewer, larger messages (on the order of megabytes or
greater) rather than many smaller ones.  Having some number of parsing threads
pass the resulting data structures (1 thread producing one data structure for
each frame) to a balanced number of rendering nodes (perhaps 1 node for each
frame) seems like a good place to start for animations.  And, since most
animation frames in a sequence are much like the ones just before, a fairly
simple adaptive parse/render load balancing scheme should work well.

Post a reply to this message