In article <4006229C.572F22AE@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> Benchmark.pov was not "arbitrarily declared" a typical scene. It was carefully
> designed to test a wide variety of feature sets present in the program and to
> pose as a reasonable challenge to modern computing architectures. There is no
> way a single scene is going to create a high level performance test for every
> feature the program offers and even if you could it would take forever to
> render. Instead we decided to craft a scene with a balanced set of features
> that could reasonably be expected to test both the performance of the program
> and the computers it is operated on while at the same time maintaining an
> acceptable rending time. To date the developers have used it extensively for
> fine tuning the performance of the program both internally and at compile
> time and if it does nothing else it has performed beyond expectations for
> accomplishing that.

While all you say is correct and remains valid, it has to be admitted that
benchmark.pov has one little bias as it does give a rather heavy weight to
the noise function due to the clouds.  Another thing is that while it is a
realistic benchmark for comparing POV-Ray performance of roughly similar
systems (same architecture) when using them to do "real" work with POV-Ray,
it is not suitable to compare the performance of any particular
processor/system with a specific other one to determine which one is
"faster".

The reason is that such a comparison is not optimal with the default
benchmark.pov is that automatic bounding is turned on, which makes the major
task while rendering searching the bounding volumes.  This to a major part
depends on memory access.  It is really a lot of searching, but not so much
computing at all...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message