|
 |
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.
---
Asides:
-
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
https://github.com/POV-Ray/povray/issues/315
and
Investigate and review use of CRITICAL_LENGTH in code. #379
https://github.com/POV-Ray/povray/issues/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
instead.
Anyway.
Bill P.
Post a reply to this message
|
|
