Christoph Hormann <chr### [at] gmxde> wrote:

>Mael wrote:
>>>Hmm, but this isn't benchmark.pov...
>> 
>> 
>> Does benchmark.pov have lot of intersections csg ? It seems fair to me to
>> test this patch on a scene that uses it (and perhaps even a lot of it to
>> clearly show the effect of the new algorithm)
>
>The benchmark scene uses a reasonable amount of CSG, a comparison with 

I don't think so.
Both of my private builds take about 38min for benchmark.pov (PIV
2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).

Setting use_photons = use_area_light = show_clouds = show_objects to
false				==> about 114sec both.
Additionally remove the Sockets ==> about  79sec both.
So as a rough estimate the intersection objects only take about 2% of
the total time.

>this scene would show how much gain you can expect in a typical scene.
>You can of course construct a scene where POV-Ray spends 90% of the time 
>with CSG calculations but this would not be very realistic.

Yes and no.
Give me a ratio old version <-> new version and i'll give you a scene
that shows a better ratio :-).
This is a problem with benchmarks or measurements generally, you have
to have a close look at the boundary conditions.
IMHO benchmark.pov can be used to benchmark the hardware it is running
on but i wouldn't use it to profile/compare different versions of
POV-Ray on the same hardware.

Andreas

Post a reply to this message

> Yes and no.
> Give me a ratio old version <-> new version and i'll give you a scene
> that shows a better ratio :-).
> This is a problem with benchmarks or measurements generally, you have
> to have a close look at the boundary conditions.
> IMHO benchmark.pov can be used to benchmark the hardware it is running
> on but i wouldn't use it to profile/compare different versions of
> POV-Ray on the same hardware.
>
> Andreas

I agree. Just because a patch does not appreciably speed up benchmark.pov 
does not mean that the patch isn't worthwhile. Why is benchmark.pov 
arbitrarily declared to be the ideal or typical POV-Ray scene, anyway? 
With so many possibilities of doing things in POV-Ray, is there even such 
a thing as "the typical scene" ?


George


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

George Pantazopoulos wrote:

> I agree. Just because a patch does not appreciably speed up benchmark.pov
> does not mean that the patch isn't worthwhile. Why is benchmark.pov
> arbitrarily declared to be the ideal or typical POV-Ray scene, anyway?
> With so many possibilities of doing things in POV-Ray, is there even such
> a thing as "the typical scene" ?

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.

-- 
Ken Tyler

Post a reply to this message

I fully agree with Ken.
  benchmark.pov has been designed to mearure the rendering speed of typical
scenes in average.

  However, I agree with George as well: If a feature does not slow down
benchmark.pov but considerably speeds up some feature which is rather
often used, in my opinion it's worth adding.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

Andreas Kaiser wrote:
>>
>>The benchmark scene uses a reasonable amount of CSG, a comparison with 
> 
> 
> I don't think so.
> Both of my private builds take about 38min for benchmark.pov (PIV
> 2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).
> 
> Setting use_photons = use_area_light = show_clouds = show_objects to
> false				==> about 114sec both.
> Additionally remove the Sockets ==> about  79sec both.
> So as a rough estimate the intersection objects only take about 2% of
> the total time.

Which is exactly the case for an average 'real' scene (real meaning not 
a technical test scene but a true final scene for a real image).  I 
guess if you do a statistical analysis of some of the better POV-Ray 
generated IRTC submissions you will find this confirmed.  This is not 
the case for scenes that make heavy use of isosurfaces and other objects 
with expensive intersection tests.

I agree with Warp though that a weak performance in rendering 
benchmark.pov is not at all a reason not to integrate this improvement. 
  The patch you posted in p.b.p. will make it quite difficult though 
since you did not clearly mark your changes.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Thorsten Froehlich wrote:
> 
> 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.

Heavy use of the noise function is quite common for a typical POV-Ray 
scene, even without media, due to procedural textures and geometry.  In 
a typical isosurface landscape scene it is even more excessive than in 
benchmark.pov.

> 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...

Surely the use for comparing processors is limited by this but for 
comparing the performance of whole computers concerning POV-Ray use this 
is exactly what's needed - a typical POV-Ray render will spend much time 
with memory access (in addition to bounding slabs just think of large 
meshes, photon maps, radiosity, image maps).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <4006b4d1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   However, I agree with George as well: If a feature does not slow down
> benchmark.pov but considerably speeds up some feature which is rather
> often used, in my opinion it's worth adding.

I agree as well. The benefit will be moderate for most scenes, but many 
scenes will render considerably faster. I'd say this is definitely a 
worthwhile optimization.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:

>[...]
>
>I agree with Warp though that a weak performance in rendering 
>benchmark.pov is not at all a reason not to integrate this improvement. 
>  The patch you posted in p.b.p. will make it quite difficult though 
>since you did not clearly mark your changes.

What's the preferred way to submit/mark changes?

For the posted csg.cpp:

function All_CSG_Union_Intersections, 
	lines 148 - 167, 183 - 185

function All_CSG_Intersection_Intersections completely,

function All_CSG_Merge_Intersections,
	lines 436 - 438

BTW evaluation of 'tstPoint' at lines 277 and 278 is loop invariant
and should be moved just before the for-loop.

Andreas

Post a reply to this message

On Fri, 16 Jan 2004 13:58:38 GMT, kai### [at] siemenscom (Andreas Kaiser)
wrote:
> What's the preferred way to submit/mark changes?

http://megapov.inetart.net/manual/internals.html#markup

ABX

Post a reply to this message