In article <41476f28$1@news.povray.org> , Ryan Lamansky <Spa### [at] kardaxcom>
wrote:

> In spite of the mysterious absence of any performance difference, I
> still think it's "good" code because it's much simpler, and it's much
> more accurate since the EPSILON test is delayed until the very end.  A
> possible drawback is that IEEE floating point behavior is required--I
> don't have enough experience with the various POV-Ray-supported
> platforms to know if this is a problem.

The algorithm you show is hardly any different for the miss case.  It
exchanges two divisions for one division and two multiplications in the best
case, but exchanges one divisions against two divisions and one
multiplication in the worst case for the first if/else block alone.

And all your code assumes division is so much slower that it can offset the
difference in the average case.  I seriously doubt it can by a serious
margin except for specially constructed cases because the average case is a
miss of a bounding box in a reasonably complex scene.

Your point about EPSILON is, well, pointless because you trade the division
by zero for the EPSILON comparison, which produces little if any gain in
precision.

However, I do agree that the complexity of the Z if/else with its case could
be better implemented.  This is something the algorithm you show has
optimized very well.  However, this is also the code most infrequently
executed.

I think the main reason you see no real difference is because there simply
is none to be measured.  The code parts that are better are not important
enough to show a difference in complex scenes, and simple scenes render fast
already :-)

If you are interested in optimizing POV-Ray, I would recommend to profile
first to find where most time is wasted.

    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