POV-Ray : Newsgroups : povray.programming : Set small values to 0. : Re: Set small values to 0. Server Time
29 Nov 2023 20:15:05 EST (-0500)
  Re: Set small values to 0.  
From: William F Pokorny
Date: 25 Aug 2020 06:56:12
Message: <5f44ee4c$1@news.povray.org>
On 8/24/20 6:55 PM, DonF wrote:
> POV-Ray 3.7 is part of the SPEC 2017 suite of benchmarks. While running POVRAY
> from SPEC, I see some very significant performance differences that are
> triggered by some very slight numerical differences. Apparently, the very slight
> numerical differences cause different code paths to be taken resulting in the
> very significant performance differences in subsequently executed routines.
> The 3.7 version file involved is quadrics.cpp, and the routine involved is
> Compute_Quadric_BBox().

I agree code is not optimal. As to what to do...

Is the SPEC 2017 suite running the inbuilt benchmark(1) or is this some 
particular scene file? If the latter, could you provide that file or a 
link to it as well as it's associated .ini file or command line flag set?

(1) - IIRC there is no quadric in the benchmark, but...

With the significant performance differences, could you provide some 
detail? Numbers, running environments, ...

My quick take is those initial EPSILONs (1e-10 in POV-Ray) should be 
more like what I'm using in my personal povr branch (gkDBL_epsilon at ~ 
4.4e-16) which would make the initial zeroing less aggressive and so 
re-zeroing(1) of the recalculated values would less likely result in 
performance improvements, but likely in more stable performance results.

This sort of change should be safe where there is some chance, with the 
current EPSILON value, the re-zeroing of D, G, I or J would not be for 
particular shapes/surfaces.


The quadric shape is not all that frequently used these days by POV-Ray 
users. Parabolic shapes are probably the most common. Fixing things 
related to it have gotten lower priority over time.

There are several github issues tangled in the quadric bounding.

Broken quadric bounding in CSG intersection and difference. #315


Investigate and review use of CRITICAL_LENGTH in code. #379

come to mind, but there are others. I suspect part of the issue with 
quadric bounding is the shapes often have an infinite aspect to them.

I wonder if the automatic bounding not the best idea for quadratics due 
numerical issues. If a user knows she specified a parabola, she likely 
knows what bounding of use to for her application outright. If not 
precisely, then she knows the parabolic bounding calculation is the 
correct one to use and could call code for to calculate it.

Given the differences are large I suspect what is happening is the j not 
being zero essentially bypasses the appropriate automatic bounding 
calculation(2) and we get the initial huge bounding box - and so ray - 
surface root finding gets run all the time(2a).

(2) - This touches on another possible change. Namely, being smarter 
about the j tests in each of those bounding conditionals. We would need 
to really think about what small j values matter for each type of 
shape/surface and then use better values.

(2a) - If the bounding off options completely worked in v3.7 and v3.8 as 
they did v3.6, for specmark testing you could just turn off all the 
bounding so long as the scene is not too complicated. Moot point today 
as one cannot 'completely' turn off bounding in v3.7/v3.8; the bbox 
closest to the shape is always sometimes in play and that's the bbox 
being calculated here.

Given the tangle of issues above, it might make the most sense for 
specmark testing to change the scene(s) involved to avoid the quadratic 
shape. Or to implement and always use user bounding; In v3.7 & v3.8 the 
user bounding is forced off by default and automatic bounding is used 


Bill P.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.