Hello Folks:

Thanks for your comments and links.  I checked the POVBench, compared with
the parallel section since using dual processors.  Seems that my numbers
appear entirely respectable-- and that on a motherboard in use for only two
days, one whose BIOS has not yet even been tuned.

SkyVase on ABit w/ dual 400 Celeron at 500, 83 MHz bus, 128MB RAM, no BIOS
tuning.
_______________________________
_______________________________
640x480 a0.3

Instances    Time Each
_______________________________
4                  65.5              Single CPU Win98
2                  62.25
1                  63.5
_______________________________
8                  30                  Dual CPU  NT40
6                  28.7
4                  28.31
2                  32.6
1                  65

It's clear that the dual CPU machine is at peak efficiency around FOUR
instances.

I have not yet experimented with DIVIDING the image into four sections, then
combining.

On it's face, I am unconcerned with:
--- the amount of time it will take to load programs into parallel nodes
(POV programs are ridiculously short);
--- networking the image portions to a hub for combining (100 Mb net is
nearly FREE these days, and would take all of 50 milliseconds) and for BIOS
programmers, there may totally FREE motherboard communications busses (5
times faster!) just waiting to be exploited (do the numbers 33 and 66 MHz
suggest anything?);
--- image portion combining overhead. [As implied, conveyance of the image
portions would not be significant providing the portion size is not too
fine-grained.   10ms would be huge if the renderer was only given a 20ms
job, but only a half-percent of a two-second job.]  As for the Combiner Hub,
it would use RAMDisk, and should not take any longer to combine than the
nodes took to produce the imageportions.
   Given this guess, if we are measuring ONE rendering, the combiner will
double the time.  If however, we are averaging ONE HUNDRED renderings, it
will only add ONE PERCENT (it's doing the last job's output while the
imaging nodes are onto new mischief).

It is apparent here that *load balancing* is a pretty crucial issue.   I'm a
bit more concerned about initialization times of the POV interpreter.

Another concern in real world image processing with cluster computers is
PREDICTING how long a given program will take to render, so we know how to
carve up the images so as to initiate the optimal number of instances on a
multi-CPU node  (in my case 4- see above).

SCENARIO ONE:
   This would be more of an issue on, say, a 10-dual-CPU-node "10 GHz"
cluster.  Perhaps for continuous image production this will actually be a
nonissue.   (Report the instances to the 'boss' when they get below, say,
four... and get another job.  ---Non-union, I would say.--- :)

SCENARIO TWO:
    Number of instances on a node would indeed *not* be a concern on, say, a
300
single-CPU cluster-- but giving each CPU a task large enough so that
communication remains a small percentage would still require predictive
analysis.

Think it's possible to gut the POV interpreter so it just combines
best-guesses as what this command and that loop will require in rendering
time?   (Aw, c'mon, don't  tell me there's a switch for that!  :)   Other
strategies?

Think of another place to post these concerns?

I have begun work on the first scenario- the dual-CPU cluster.    I may do
the second... have 300 ISA backplane slots, racks, and about 50 CPU cards
for starters.   But I'm looking for some old ISA card which has more
processing power and is dirt cheap- like a video card which used overkill
RISC maybe?

Ain't it FUN?

Matt

Post a reply to this message