This post is to document a tuning attempt for others who might follow.....

I've been doing a little profiling of Pov-Ray 3.5 and it is no surprise the ray
object intersection functions are consistently expensive.

I noticed on many calls to Intersect_Sphere we are doing the "radius squared"
calculation on the call itself.  I modified the code to instead calculate the
radius squared value only when the sphere is created or modified and to store
this value in the sphere data structure.  As expected there is a small storage
penalty which depends on the number of spheres used in a scene or generated to
bound objects. The memory hit was small on the scenes I tried, peaking at 0.34%

Unfortunately, the performance improvement peaked at only 0.35%...  I had hoped
for more. Perhaps with more modern processors the multiplication performance is
nearly as fast as grabbing a  pre-calculated value? Especially true I expect, if
you miss one or more of the caches on the memory access.  Processor, machine
memory architecture, compiler and scene differences certainly muddy the waters
which it comes to tuning this code!!!

My feeling is this change isn't worth much, but enough to be considered when the
Pov-Ray 4.0 work gets going.

Just as processors have gotten faster at multiplication over the years,
computers today have a lot more memory. By the time 4.0 is released I would bet
many computers will be measuring ram in gigabytes instead of megabytes.  I think
it would be good to look for memory/performance trade offs with 4.0.
Bill P.

Post a reply to this message

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

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

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


Does that mean you managed to get a AIX compile of 3.5??? I'm certainly
interested in that.

Thomas

Post a reply to this message

Thomas,   With gcc 2.95 yes.  How can I help?  Bill P.

> William F. Pokorny wrote:
> >Hi Thorsten,
> >AIX, RS6000, gcc, -pg when compiled for profiling, a graphical version of gprof,
> >differences measured with load modules compiled without -pg.
>
> Does that mean you managed to get a AIX compile of 3.5??? I'm certainly
> interested in that.
>
> Thomas

Post a reply to this message

William F. Pokorny wrote:
>Thomas,   With gcc 2.95 yes.  How can I help?  Bill P.


Would it be possible to send me a copy, I haven't managed to get an AIX
compile going unfortunatly. Have you tried to make a 64 bit compile BTW. I
tried that with the 3.1 code and it works except for radiosity.

My email is thomasvdv "at" gmx.net

Thanks!

Thomas

Post a reply to this message

Thomas,
Sorry... I just saw this post.  I have not tried a 64 bit compile with 3.5a.  I
tried
one with 3.1 and gave up as I didn't have an immediate need.  It has been
my experience that you actually pay a small performance penalty and a sizeable
storage penalty when you jump to 64 bit modules.  But of course when you
need it....

A copy is on it's way.
Bill P.


> William F. Pokorny wrote:
> >Thomas,   With gcc 2.95 yes.  How can I help?  Bill P.
>
> Would it be possible to send me a copy, I haven't managed to get an AIX
> compile going unfortunatly. Have you tried to make a 64 bit compile BTW. I
> tried that with the 3.1 code and it works except for radiosity.
>
> My email is thomasvdv "at" gmx.net
>
> Thanks!
>
> Thomas

Post a reply to this message