Ken <tyl### [at] pacbellnet> wrote:
> Benchmark testing generaly relies on the amount of time it takes
> to render a given scene. If one were to design a scene that was
> parsing intensive rather than render intensive how well would it
> evaluate a systems performance ?
>
> For example I designed this scene to take exactly 30 sec. to parse
> on my system. There is a camera added simply to ensure that it was
> not pointed at any object and there are no lights added so that I
> rendered a black screen only. Render time at 640x480 with aa = 0.3
> was only 8 sec. which is inconsequential. A pigment was added to
> the object to ensure that no CPU cycles were spent on sending no
> pigment warnings messages to the message window for each object
> created by the scene code.
[snip]

I guess what you're mostly measuring with a test such as the one you posted
is the speed of memory allocation and filling (there aren't any complicated
transformations or other CPU-intensive parsing tasks).  This speed would be
affected by the physical speed of your RAM, the amount you have (and the
amount available under multi-tasking OS's), the drivers used to access it,
and probably the compiler used to make the POV-Ray executable.

All in all, benchmark tests of any kind can really only measure the speed of
tasks similar to what the test itself does, and even using POV-Ray there are
wildly different parsing tasks, eg. smoothing large heightfields or creating
subdivided bicubic patches, calling macros (particularly when they are
included from separate files), calculating bounding boxes and vista and
light buffers, etc.

Perhaps the best test of parsing and rendering is a scene which includes
many varied elements, giving something as close to a 'real-world' test as
possible?

Post a reply to this message