I searched through a couple of related groups and did not find an answer...


I have been running the POV-Ray standard benchmark to compare results of
different compilers on 64-bit systems (eg. Itanium 2). In my report, I want
to include the detailed results, but I am note sure exactly what Tests and
Succeeded mean under the Ray->Shape Intersection in the context of the
benchmark and the standard benchmark scene.
Example:
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Box                           79496652         9441690     11.88

Post a reply to this message

Jerry Feldman wrote:
> I searched through a couple of related groups and did not find an answer...
> 
> 
> I have been running the POV-Ray standard benchmark to compare results of
> different compilers on 64-bit systems (eg. Itanium 2). In my report, I want
> to include the detailed results, but I am note sure exactly what Tests and
> Succeeded mean under the Ray->Shape Intersection in the context of the
> benchmark and the standard benchmark scene.
> Example:
> Ray->Shape Intersection          Tests       Succeeded  Percentage
> ----------------------------------------------------------------------------
> Box                           79496652         9441690     11.88

Probably does not have much meaning in your case. These numbers should 
remain identical for each run of the benchmark, provided the benchmark 
is run with the proper options.

What this is used for is checking things like object bounding. This 
helps a scene creator determine if there is an efficiency problem in the 
scene. (an example would be if this number were well below about 5% 
there would be a major problem, something is not bounded properly and 
manual bounding may be needed)

AFAIK the only measurement for the benchmark is the time to render the 
scene.


-- 
~Mike

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:

> What this is used for is checking things like object bounding. This
> helps a scene creator determine if there is an efficiency problem in the
> scene. (an example would be if this number were well below about 5%
> there would be a major problem, something is not bounded properly and
> manual bounding may be needed)
>
> AFAIK the only measurement for the benchmark is the time to render the
> scene.
Thanks for the reply.
In my case we ran 2 different compilers each with optimization levels O3, O2
and o). The numbers were different but consistent for each run. Nearly all
of the percentages were above 5%, but there were some well below.
ICC Opt level O3:
Isosurface Cache                127619           41187     32.27
Mesh                          15396094           65150      0.42
Plane                         92422022         1296548      1.40
Sphere                       282061960       167429963     59.36

GCC Opt level O3
Isosurface Cache                131983           41748     31.63
Mesh                          15317900           65226      0.43
Plane                         92179859         1292354      1.40
Sphere                       281530294       166539345     59.16

I'll rerun the benchmarks for one of the above to make sure that these
numbers are identical. I was asked to place the raw results in the paper,
but if I do, I would need to explain them in some general terms.

Post a reply to this message

Jerry Feldman wrote:
> Mike Raiford <mra### [at] hotmailcom> wrote:
> 
> 
>>What this is used for is checking things like object bounding. This
>>helps a scene creator determine if there is an efficiency problem in the
>>scene. (an example would be if this number were well below about 5%
>>there would be a major problem, something is not bounded properly and
>>manual bounding may be needed)
>>
>>AFAIK the only measurement for the benchmark is the time to render the
>>scene.
> 
> Thanks for the reply.
> In my case we ran 2 different compilers each with optimization levels O3, O2
> and o). The numbers were different but consistent for each run. Nearly all
> of the percentages were above 5%, but there were some well below.
> ICC Opt level O3:
> Isosurface Cache                127619           41187     32.27
> Mesh                          15396094           65150      0.42
> Plane                         92422022         1296548      1.40
> Sphere                       282061960       167429963     59.36
> 
> GCC Opt level O3
> Isosurface Cache                131983           41748     31.63
> Mesh                          15317900           65226      0.43
> Plane                         92179859         1292354      1.40
> Sphere                       281530294       166539345     59.16

Interesting... I don't know any explanation for the differences, except 
that each compiler optimizes differently and gives a slight difference 
to when the interesection test passes or fails.

One other note: Something like mesh, the bounding box could potentially 
be much larger than the actual object, resulting in a bounding miss 
(resulting in the low percentages)


-- 
~Mike

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:

> Interesting... I don't know any explanation for the differences, except
> that each compiler optimizes differently and gives a slight difference
> to when the interesection test passes or fails.
>
> One other note: Something like mesh, the bounding box could potentially
> be much larger than the actual object, resulting in a bounding miss
> (resulting in the low percentages)

Thanks again Mike. I reran one of the benchmarks and compared it with the
prior results. Nearly all the numbers were identical except for Height
Field Cell,   Isosurface Cache, and sphere, but there are some other issues
that might account for those possibly in the way I ran them. But,
essentially, you answered my question enough for the paper.

Post a reply to this message