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