Hi Thorsten,
AIX, RS6000, gcc, -pg when compiled for profiling, a graphical version of gprof,
differences measured with load modules compiled without -pg.

Yes, I agree completely with your performance characterization. What I see is
that for simpler scenes the ray intersection time dominates. As more complex
textures and complex objects are added those start to take more of the total
time comparatively. In fact, in some cases things other than intersections
almost completely account for the CPU time!

My conclusion was that for the typical scene this change was not worth the
trouble. I expected a much larger and more noticeable improvement. But things
have changed since I did this sort of detailed stuff in C - now almost 10 years
ago. The expected benefit was not there.  I stuck this post out here so others,
who might think the same as me on seeing the calling code, can search for
"Intersect_Sphere", as I did, before they start hacking. Perhaps on seeing this
thread they won't waste time.

However, I  do want to put this change on the table for 4.0. People do sometimes
create scenes with simple textures and LOTS of spheres - I remember a few images
where bottles and such had been created completely from spheres.  My test cases
were not this extreme.  All first pass runs were <5 minutes and here I made
multiple passes. The most repeatable improvement, and you are certainly correct
about the noise,  was with chess2.pov. The 2 final chess2.pov runs, where I
measured the 0.35%, were were only about 1400 seconds.

Would it be of help to you and others, who will take up 4.0 development, if I
created an "extreme sphere" scene which I would then run with and without this
change over some days?

We could also build up custom program which implements the two methods and then
calls Intersect_Sphere in a loop however long we want to make it. But, I don't
myself favor this latter idea as the caching in this case is ideal. We are
interested in what happens when Pov-Ray actually runs and the cache is getting
turned over.

If it will help the Pov-Ray development team, I'd be happy to generate more
data. If not, I am moving on.
Bill P.

> In article <3D68F02D.7E13050A@attglobal.net> , "William F. Pokorny"
> <pok### [at] attglobalnet> wrote:
>
> > I've been doing a little profiling of Pov-Ray 3.5 and it is no surprise the
>
> With which tools?  On which platform?
>
> > ray object intersection functions are consistently expensive.
>
> Not sure what you have been measuring there, but the intersections with
> simple objects, expecially spheres are so fast they can completely be
> neglected compared to textures or the more complex objects.
>
> Maybe your scene had just a few spheres without any textures?
>
> And how often did you measure the runs?  And how long where they?
>
> I hope at least a few days because for an hour long test 0.35% are in the
> range of the measuring error.  The difference is just 12 seconds of an hour
> long render!
>
>     Thorsten

Post a reply to this message