Ron Parker <par### [at] fwicom> wrote...
> On Tue, 28 Dec 1999 20:00:25 -0800, 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 ?
>
> Well, you're evaluating a part of the process that typically takes a
> lot less time and doesn't tax the same parts of the architecture that
> a render does.  In particular, parsing is more concerned with file I/O
> and memory allocation performance than with floating point
> performance, so you're likely to see huge differences from filesystem
> to filesystem and from OS to OS, even on the same computer.

Yes.  For example, with #while loops and macros, POV uses the 'fseek()'
function to get to the appropriate place in the file and parses it.
Especially if you use many macros that are spread across many files, you'll
find that this will be a test of the quality of the disk caches (both
hardware and software caches).

> Your example is probably more dependent on memory allocation than
> anything else, so it might be a good measure of how fast your computer
> can allocate memory.  Whether that's a good gauge of performance is up
> to you, but I'd say no.

The speed of memory allocation and deallocation can depend on the compiler
used and the operating system.  I once saw a paper that compared the speed
of various implementations of malloc() and free().

Also, as Chris Colefax pointed out, the exact nature of the POV script will
have an affect on the characteristics of the parse, which may make it
dependent on the speed of your floating-point math.

-Nathan

Post a reply to this message