POV-Ray : Newsgroups : povray.programming : Set small values to 0. Server Time
28 Mar 2024 16:38:03 EDT (-0400)
  Set small values to 0. (Message 1 to 8 of 8)  
From: DonF
Subject: Set small values to 0.
Date: 24 Aug 2020 19:00:01
Message: <web.5f4445554167f6d8af6fbbee0@news.povray.org>
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().

In Compute_Quadric_BBox(), some values are setup that control how much work is
ultimately done elsewhere in the program. In this routine, some setup work is
performed based on all sort of floating point compares to 0.0: > 0.0, < 0.0, ==
0.0, and != 0.0. With these critical comparisons to 0.0, slight numerical
differences can result in a different setup, so it is very important that if a
value is intended to be 0.0, that it is actually 0.0.

And obtaining actual 0.0 values is partially obtained by setting values that are
close to zero to actually be 0.0, such as, the below POVRAY code.

  /* Set small values to 0. */

  if (fabs(A) < EPSILON) A = 0.0;
  if (fabs(B) < EPSILON) B = 0.0;
  if (fabs(C) < EPSILON) C = 0.0;
  if (fabs(D) < EPSILON) D = 0.0;
  if (fabs(E) < EPSILON) E = 0.0;
  if (fabs(F) < EPSILON) F = 0.0;
  if (fabs(G) < EPSILON) G = 0.0;
  if (fabs(H) < EPSILON) H = 0.0;
  if (fabs(I) < EPSILON) I = 0.0;
  if (fabs(J) < EPSILON) J = 0.0;

However, after the above adjustments of some small values to 0.0 are completed,
a few of the values are recalculated, which once again results in some small
values that are not equal to zeo, such as J for the SPEC test case. Certain
compilers versions or compiler options may result in an exact value of
0.000000e+00, but with most compiler versions and options, due to the limited
precision of floating point operations, the J values end up being something
close to zero, like 8.881784e-16, but not actually zero, resulting in the
different setup to be performance and much poorer performance.

    /* Recalculate coefficients. */

    D += A * T1[X];
    G += E * T1[Y];
    I += H * T1[Z];
    J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z] +
2.0*I);

If the J value is simply re-adjusted back to 0., as was done earlier, then much
better performance is obtained without changing the correctness of the generated
..tga files.

As mentioned above, SPEC is based off of POV-Ray 3.7 and although file names
have changed and updates have occurred in 3.8, the same basic issue is still
appears to be present in 3.8.

So my question is:

Should the "set small values to 0." adjustments be re-made, primarily for "J",
 so that consistent comparisons can be make to 0.0, or was it intentional
not to make any readjustments to "set small values to 0." after the "recalculate
coefficients" was performed?


Post a reply to this message

From: Bald Eagle
Subject: Re: Set small values to 0.
Date: 24 Aug 2020 19:45:00
Message: <web.5f4450b5e03bfc801f9dae300@news.povray.org>
"DonF" <nomail@nomail> wrote:

> However, after the above adjustments of some small values to 0.0 are completed,
> a few of the values are recalculated, which once again results in some small
> values that are not equal to zeo, such as J for the SPEC test case.

Yuk.

Nice catch!  I'm sure it must have taken quite a bit of digging to uncover the
root cause of this.   It sounds a lot like the triangle normal bug that surfaced
a while back.
http://news.povray.org/povray.binaries.scene-files/message/%3C57b5e71b%241%40news.povray.org%3E/#%3C57b5e71b%241%40news
.povray.org%3E

The bigger it gets, the more complicated it gets to debug...  ;)


Post a reply to this message

From: William F Pokorny
Subject: Re: Set small values to 0.
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.

---
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

From: DonF
Subject: Re: Set small values to 0.
Date: 25 Aug 2020 23:20:01
Message: <web.5f45d45de03bfc80af6fbbee0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:


DETAILS:


Description of the SPEC test case:

   POV-Ray is a free and open source ray-tracing application. The CPU2017
   version is based on POV-Ray version 3.7.

   The benchmark renders a 2560 x 2048 pixel image of a chess board, with the
   pieces placed on the board in the starting position. The rendered scene
   image is saved as a Targa (.tga) file.

   This output image is compared with the reference output image using the
   SPEC utility [1]imagevalidate, which calculates a the structural
   similarity (SSIM) index between corresponding 8x8 groups of pixels in each
   image. The SSIM index has a range of -1 (maximal difference) to 1
   (identical). The benchmark requires that all computed SSIM indices be
   greater than 0.996 in order for the run to be considered successful.

   A log of the execution is also generated, but its contents are not used to
   validate correction operation of the benchmark.

   POV-Ray (which became 511.povray_r) was contributed to CPU2017 by one of
   the developers, Thorsten Froehlich, under the GNU Affero License v3.


Performance of SPEC2017 REF sized test case:

  Sample performance difference using Intel compiler on a Skylake system
  with the spec2017 REF size test case, but most compilers on most platforms,
  including x86 or ARM platforms, can see similar large performance differences
  with just this one slight numerical difference in J.

    If J turns out to be zero, or if reset.          218 seconds.
    Without resetting J to zero when close to zero.  349 seconds. 60% slower.

  Both output images validated successfully using the SPEC imagevalidate method,
  but the one output image took much longer to generate.


Input .ini file used for the SPEC2017 REF sized test case:

Width=2560
Height=2048
All_Console=On
All_File=SPEC-benchmark.log
Antialias_Depth=3
Antialias=On
Antialias_Threshold=0.3
Bits_Per_Color=8
Bounding_Threshold=1
Bounding=On
Buffer_Output=Off
Buffer_Size=0
Clock=0
Continue_Trace=Off
Create_Histogram=Off
Cyclic_Animation=Off
Debug_Console=Off
Display=Off
Display_Gamma=1.0
Draw_Vistas=Off
Fatal_Console=On
Fatal_Error_Command=
Fatal_Error_Return=I
Field_Render=Off
Final_Clock=1
Final_Frame=1
Histogram_Name=
Histogram_Grid_Size=0.0
Initial_Clock=0
Initial_Frame=1
Include_Header=
Input_File_Name=SPEC-benchmark-ref.pov
Jitter_Amount=0.30
Jitter=Off
Light_Buffer=On
Odd_Field=Off
Output_Alpha=Off
Output_File_Name=SPEC-benchmark.tga
Output_File_Type=t
Palette=3
Pause_When_Done=Off
Post_Frame_Command=
Post_Frame_Return=I
Post_Scene_Command=
Post_Scene_Return=I
Preview_End_Size=1
Preview_Start_Size=1
Pre_Frame_Command=
Pre_Frame_Return=I
Pre_Scene_command=
Pre_Scene_Return=I
Quality=9
Remove_Bounds=Off
Render_Console=On
Sampling_Method=1
Split_Unions=Off
Statistic_Console=On
Subset_End_Frame=1
Subset_Start_Frame=1
Test_Abort_Count=0
Test_Abort=Off
User_Abort_Command=
User_Abort_Return=I
Verbose=Off
Version=3.5
Video_Mode=0
Vista_Buffer=On
Warning_Console=Off


Description of input .pov:

    // Persistence Of Vision raytracer sample file.
    // POV-Ray scene description for chess board.
    // By Ville Saari
    // Copyright (c) 1991 Ferry Island Pixelboys
    //
    // This scene has 430 primitives in objects and 41 in bounding shapes and
    // it takes over 40 hours to render by standard amiga.
    //
    // If you do some nice modifications or additions to this file, please send
    // me a copy. My Internet address is:  vsa### [at] niksulahutfi
    //
    // -w320 -h240
    // -w800 -h600 +a0.3

    // Note : CHESS2.POV was created from Ville Saari's chess.pov
    // -- Dan Farmer 1996
    //  - Cchanged textures
    //  - Added camera blur and changed focal length
    //  - Use sky sphere
    //  - Modularized the code
    //  - Added felt pads to bottom of pieces

    // remaining manual bounding commented out by Bob Hughes, August 31, 2001


Execution Trace:

  With my own little debug trace through the Compute_Quadric_BBox() routine of
  file quadrics.cpp using the SPEC test case, I see 19 calls to the
  Compute_Quadric_BBox() routine.

  All calls to Compute_Quadric_BBox() execute one of the many
  "Check for xxxxxxx (?-axis)" code blocks, EXCEPT the one case where
  "J is recalculated, ends up being close to zero, but not quite zero,
  and is not reset". In this one case, none of the "Check ..." code blocks are
  executed, the "Add translation" and the "Beware of bounding boxes to large"
  are executed, and large values for BBox.Lengths the BBox.Lower_Left values
  are used.


  Executed code when J is "recalculated" and ends up being exactly equal to
  0.0 (or is reset to zero if close) for the 1 of 19 cases that differed:

    J was recalculated to J=4.440892e-16,
    and then reset to 0.0 with modified code I added.

      Check for cone (y-axis).
      Add translation.
      Quadric->BBox.Lengths 0 to 2:     4.333333 3.500000  4.333333
      Quadric->BBox.Lower_Left 0 to 2: -2.166667 8.000000 -2.166667


  Executed code when J is "recalculated" and ends up NOT quite being exactly
  equal to 0.0:

      Add translation.
      Beware of bounding boxes to large.
      Quadric->BBox.Lengths 0 to 2:     20000000000.000000  20000000000.000000
20000000000.000000
      Quadric->BBox.Lower_Left 0 to 2: -10000000000.000000 -10000000000.000000
-10000000000.000000

  For the faster executing run, note that the "Beware of bounding boxes to
  large" code block is still executed for 8 of the 19 calls to
  Compute_Quadric_BBox(), and even when "Beware of bounding boxes to large"
  is NOT called, the large BBox values may be still be set or inherited.
  For this faster test case, 12 of the 19 calls to
  Compute_Quadric_BBox() ended up with large BBox values, so having the
  large BBox values is not unusual, but for the one call where J was not
  reset when perhaps it could/should have been reset, the large BBox values
  were one of the differences encountered between the slower and faster
  runs.


Portion of log file results (not used for SPEC verification) for the
fast and slow execution.

  Fast execution with recalculated J reset to zero when it is close to zero:
  218 seconds.

    Image Resolution 2560 x 2048
    ----------------------------------------------------------------------------
    Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
    Rays:          114705211   Saved:           1162288   Max Level: 5/5
    ----------------------------------------------------------------------------
    Ray->Shape Intersection          Tests       Succeeded  Percentage
    ----------------------------------------------------------------------------
    Box                           16019108        16019107    100.00
    Cone/Cylinder                 12818313         3292990     25.69
    CSG Intersection            1100588845       111370367     10.12
    CSG Union                     88374684        76631294     86.71
    Plane                       4514922317      2468835793     54.68
    Quadric                      330552192       175746735     53.17
    Sphere                       289188952        70116199     24.25
    Bounding Box                2485773879       745702120     30.00
    Light Buffer                1823322702      1064180254     58.36
    ----------------------------------------------------------------------------


  Slow execution with recalculated J NOT reset to zero when it was close
  to zero: 349 seconds.

       Note the large increase in "Tests" for many of the
       "Ray->Shape Intersestion" values, such as CSG Intersection, Plane,
       Quadric, and Sphere, (flagged with **) which presumably
       results in the large increase in execution time.

    Image Resolution 2560 x 2048
    ----------------------------------------------------------------------------
    Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
    Rays:          114705211   Saved:           1162288   Max Level: 5/5
    ----------------------------------------------------------------------------
    Ray->Shape Intersection          Tests       Succeeded  Percentage
    ----------------------------------------------------------------------------
    Box                           16019108        16019107    100.00
    Cone/Cylinder                 12818313         3292990     25.69
    CSG Intersection            2573044515**     113104449      4.40
    CSG Union                     88374684        76631294     86.71
    Plane                       5987377987**    3804982796     63.55
    Quadric                     1066780027**     285487345     26.76
    Sphere                      9123922972**      73475346      0.81
    Bounding Box                2368729644       732816314     30.94
    Light Buffer                2057730695      1350487574     65.63
    ----------------------------------------------------------------------------



> 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)

Based on my observations, 4.4e-16 might be a little too restrictive to catch
many of the obvious "close to zero values". An EPSILON of 1e-10 may,
or may not, be too lax, but I think 4.4e-16 would be too restrictive.
The recalculated values of J that were not close to zero for this case,
and hence didn't need to be reset were either -1.0, or already 0.0.


Post a reply to this message

From: Thorsten
Subject: Re: Set small values to 0.
Date: 26 Aug 2020 02:07:08
Message: <5f45fc0c$1@news.povray.org>
I will see if I can spare some time to take a look at this over the weekend.

Thorsten Froehlich

On 26.08.2020 05:17, DonF wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> DETAILS:
> 
> Description of the SPEC test case:
> 
>     POV-Ray is a free and open source ray-tracing application. The CPU2017
>     version is based on POV-Ray version 3.7.
> 
>     The benchmark renders a 2560 x 2048 pixel image of a chess board, with the
>     pieces placed on the board in the starting position. The rendered scene
>     image is saved as a Targa (.tga) file.
> 
>     This output image is compared with the reference output image using the
>     SPEC utility [1]imagevalidate, which calculates a the structural
>     similarity (SSIM) index between corresponding 8x8 groups of pixels in each
>     image. The SSIM index has a range of -1 (maximal difference) to 1
>     (identical). The benchmark requires that all computed SSIM indices be
>     greater than 0.996 in order for the run to be considered successful.
> 
>     A log of the execution is also generated, but its contents are not used to
>     validate correction operation of the benchmark.
> 
>     POV-Ray (which became 511.povray_r) was contributed to CPU2017 by one of
>     the developers, Thorsten Froehlich, under the GNU Affero License v3.
> 
> 
> Performance of SPEC2017 REF sized test case:
> 
>    Sample performance difference using Intel compiler on a Skylake system
>    with the spec2017 REF size test case, but most compilers on most platforms,
>    including x86 or ARM platforms, can see similar large performance differences
>    with just this one slight numerical difference in J.
> 
>      If J turns out to be zero, or if reset.          218 seconds.
>      Without resetting J to zero when close to zero.  349 seconds. 60% slower.
> 
>    Both output images validated successfully using the SPEC imagevalidate method,
>    but the one output image took much longer to generate.
> 
> 
> Input .ini file used for the SPEC2017 REF sized test case:
> 
> Width=2560
> Height=2048
> All_Console=On
> All_File=SPEC-benchmark.log
> Antialias_Depth=3
> Antialias=On
> Antialias_Threshold=0.3
> Bits_Per_Color=8
> Bounding_Threshold=1
> Bounding=On
> Buffer_Output=Off
> Buffer_Size=0
> Clock=0
> Continue_Trace=Off
> Create_Histogram=Off
> Cyclic_Animation=Off
> Debug_Console=Off
> Display=Off
> Display_Gamma=1.0
> Draw_Vistas=Off
> Fatal_Console=On
> Fatal_Error_Command=
> Fatal_Error_Return=I
> Field_Render=Off
> Final_Clock=1
> Final_Frame=1
> Histogram_Name=
> Histogram_Grid_Size=0.0
> Initial_Clock=0
> Initial_Frame=1
> Include_Header=
> Input_File_Name=SPEC-benchmark-ref.pov
> Jitter_Amount=0.30
> Jitter=Off
> Light_Buffer=On
> Odd_Field=Off
> Output_Alpha=Off
> Output_File_Name=SPEC-benchmark.tga
> Output_File_Type=t
> Palette=3
> Pause_When_Done=Off
> Post_Frame_Command=
> Post_Frame_Return=I
> Post_Scene_Command=
> Post_Scene_Return=I
> Preview_End_Size=1
> Preview_Start_Size=1
> Pre_Frame_Command=
> Pre_Frame_Return=I
> Pre_Scene_command=
> Pre_Scene_Return=I
> Quality=9
> Remove_Bounds=Off
> Render_Console=On
> Sampling_Method=1
> Split_Unions=Off
> Statistic_Console=On
> Subset_End_Frame=1
> Subset_Start_Frame=1
> Test_Abort_Count=0
> Test_Abort=Off
> User_Abort_Command=
> User_Abort_Return=I
> Verbose=Off
> Version=3.5
> Video_Mode=0
> Vista_Buffer=On
> Warning_Console=Off
> 
> 
> Description of input .pov:
> 
>      // Persistence Of Vision raytracer sample file.
>      // POV-Ray scene description for chess board.
>      // By Ville Saari
>      // Copyright (c) 1991 Ferry Island Pixelboys
>      //
>      // This scene has 430 primitives in objects and 41 in bounding shapes and
>      // it takes over 40 hours to render by standard amiga.
>      //
>      // If you do some nice modifications or additions to this file, please send
>      // me a copy. My Internet address is:  vsa### [at] niksulahutfi
>      //
>      // -w320 -h240
>      // -w800 -h600 +a0.3
> 
>      // Note : CHESS2.POV was created from Ville Saari's chess.pov
>      // -- Dan Farmer 1996
>      //  - Cchanged textures
>      //  - Added camera blur and changed focal length
>      //  - Use sky sphere
>      //  - Modularized the code
>      //  - Added felt pads to bottom of pieces
> 
>      // remaining manual bounding commented out by Bob Hughes, August 31, 2001
> 
> 
> Execution Trace:
> 
>    With my own little debug trace through the Compute_Quadric_BBox() routine of
>    file quadrics.cpp using the SPEC test case, I see 19 calls to the
>    Compute_Quadric_BBox() routine.
> 
>    All calls to Compute_Quadric_BBox() execute one of the many
>    "Check for xxxxxxx (?-axis)" code blocks, EXCEPT the one case where
>    "J is recalculated, ends up being close to zero, but not quite zero,
>    and is not reset". In this one case, none of the "Check ..." code blocks are
>    executed, the "Add translation" and the "Beware of bounding boxes to large"
>    are executed, and large values for BBox.Lengths the BBox.Lower_Left values
>    are used.
> 
> 
>    Executed code when J is "recalculated" and ends up being exactly equal to
>    0.0 (or is reset to zero if close) for the 1 of 19 cases that differed:
> 
>      J was recalculated to J=4.440892e-16,
>      and then reset to 0.0 with modified code I added.
> 
>        Check for cone (y-axis).
>        Add translation.
>        Quadric->BBox.Lengths 0 to 2:     4.333333 3.500000  4.333333
>        Quadric->BBox.Lower_Left 0 to 2: -2.166667 8.000000 -2.166667
> 
> 
>    Executed code when J is "recalculated" and ends up NOT quite being exactly
>    equal to 0.0:
> 
>        Add translation.
>        Beware of bounding boxes to large.
>        Quadric->BBox.Lengths 0 to 2:     20000000000.000000  20000000000.000000
> 20000000000.000000
>        Quadric->BBox.Lower_Left 0 to 2: -10000000000.000000 -10000000000.000000
> -10000000000.000000
> 
>    For the faster executing run, note that the "Beware of bounding boxes to
>    large" code block is still executed for 8 of the 19 calls to
>    Compute_Quadric_BBox(), and even when "Beware of bounding boxes to large"
>    is NOT called, the large BBox values may be still be set or inherited.
>    For this faster test case, 12 of the 19 calls to
>    Compute_Quadric_BBox() ended up with large BBox values, so having the
>    large BBox values is not unusual, but for the one call where J was not
>    reset when perhaps it could/should have been reset, the large BBox values
>    were one of the differences encountered between the slower and faster
>    runs.
> 
> 
> Portion of log file results (not used for SPEC verification) for the
> fast and slow execution.
> 
>    Fast execution with recalculated J reset to zero when it is close to zero:
>    218 seconds.
> 
>      Image Resolution 2560 x 2048
>      ----------------------------------------------------------------------------
>      Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
>      Rays:          114705211   Saved:           1162288   Max Level: 5/5
>      ----------------------------------------------------------------------------
>      Ray->Shape Intersection          Tests       Succeeded  Percentage
>      ----------------------------------------------------------------------------
>      Box                           16019108        16019107    100.00
>      Cone/Cylinder                 12818313         3292990     25.69
>      CSG Intersection            1100588845       111370367     10.12
>      CSG Union                     88374684        76631294     86.71
>      Plane                       4514922317      2468835793     54.68
>      Quadric                      330552192       175746735     53.17
>      Sphere                       289188952        70116199     24.25
>      Bounding Box                2485773879       745702120     30.00
>      Light Buffer                1823322702      1064180254     58.36
>      ----------------------------------------------------------------------------
> 
> 
>    Slow execution with recalculated J NOT reset to zero when it was close
>    to zero: 349 seconds.
> 
>         Note the large increase in "Tests" for many of the
>         "Ray->Shape Intersestion" values, such as CSG Intersection, Plane,
>         Quadric, and Sphere, (flagged with **) which presumably
>         results in the large increase in execution time.
> 
>      Image Resolution 2560 x 2048
>      ----------------------------------------------------------------------------
>      Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
>      Rays:          114705211   Saved:           1162288   Max Level: 5/5
>      ----------------------------------------------------------------------------
>      Ray->Shape Intersection          Tests       Succeeded  Percentage
>      ----------------------------------------------------------------------------
>      Box                           16019108        16019107    100.00
>      Cone/Cylinder                 12818313         3292990     25.69
>      CSG Intersection            2573044515**     113104449      4.40
>      CSG Union                     88374684        76631294     86.71
>      Plane                       5987377987**    3804982796     63.55
>      Quadric                     1066780027**     285487345     26.76
>      Sphere                      9123922972**      73475346      0.81
>      Bounding Box                2368729644       732816314     30.94
>      Light Buffer                2057730695      1350487574     65.63
>      ----------------------------------------------------------------------------
> 
> 
> 
>> 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)
> 
> Based on my observations, 4.4e-16 might be a little too restrictive to catch
> many of the obvious "close to zero values". An EPSILON of 1e-10 may,
> or may not, be too lax, but I think 4.4e-16 would be too restrictive.
> The recalculated values of J that were not close to zero for this case,
> and hence didn't need to be reset were either -1.0, or already 0.0.
> 
> 
>


Post a reply to this message

From: William F Pokorny
Subject: Re: Set small values to 0.
Date: 27 Aug 2020 06:45:22
Message: <5f478ec2$1@news.povray.org>
On 8/25/20 11:17 PM, DonF wrote:
> Description of the SPEC test case:
> 
>     POV-Ray is a free and open source ray-tracing application. The CPU2017
>     version is based on POV-Ray version 3.7.

Yesterday, I quickly read your answer - thank you. On seeing Thorsten's 
post decided not to post myself.

Awaking this morning though, had a question in my head whether the above 
statement really true? I doubt you are really running v3.7 - or at least 
any official version of v3.7 because your output has the line:

Light Buffer                2057730695      1350487574     65.63

and this support was dropped in v3.7 onward.

When thinking about your issue, I was looking at the v3.8 code base and 
those github issues are against v3.7 / v3.8 versions.

FWIW I guess. Thorsten will better know whats going on.

Bill P.


Post a reply to this message

From: DonF
Subject: Re: Set small values to 0.
Date: 30 Aug 2020 01:00:01
Message: <web.5f4b317fe03bfc80af6fbbee0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> Awaking this morning though, had a question in my head whether the above
> statement really true? I doubt you are really running v3.7 - or at least
> any official version of v3.7 because your output has the line:


The SPEC 2017 benchmark documentation indicates v3.7, but the SPEC code
itself is still documented as being version 3.6, as indicated from the
below comments from the quadrics.cpp. But it looks like a common issue
between 3.6 and 3.7, unless the issue is resolved elsewhere in the newer
version.


/****************************************************************************
 *               quadrics.cpp
 *
 * This module implements the code for the quadric shape primitive.
 *
 * from Persistence of Vision(tm) Ray Tracer version 3.6.
 * Copyright 1991-2003 Persistence of Vision Team
 * Copyright 2003-2009 Persistence of Vision Raytracer Pty. Ltd.
 *---------------------------------------------------------------------------
 * NOTICE: This source code file is provided so that users may experiment
 * with enhancements to POV-Ray and to port the software to platforms other
 * than those supported by the POV-Ray developers. There are strict rules
 * regarding how you are permitted to use this file. These rules are contained
 * in the distribution and derivative versions licenses which should have been
 * provided with this file.
 *
 * These licences may be found online, linked from the end-user license
 * agreement that is located at http://www.povray.org/povlegal.html
 *---------------------------------------------------------------------------
 * This program is based on the popular DKB raytracer version 2.12.
 * DKBTrace was originally written by David K. Buck.
 * DKBTrace Ver 2.0-2.12 were written by David K. Buck & Aaron A. Collins.
 *---------------------------------------------------------------------------
 * $File: //depot/povray/spec-3.6/source/quadrics.cpp $
 * $Revision: #1 $
 * $Change: 5014 $
 * $DateTime: 2010/06/13 03:51:51 $
 * $Author: thorsten $
 * $Log$
 *****************************************************************************/


And once again, my simple fix, at least for the SPEC 2017 test case, was to
simply, rerun the "set small values to 0" check after the "recalculation".


 808   /* Get quadrics coefficients. */
 809
 810   A = Quadric->Square_Terms[X];
 811   E = Quadric->Square_Terms[Y];
 812   H = Quadric->Square_Terms[Z];
 813   B = Quadric->Mixed_Terms[X] / 2.0;
 814   C = Quadric->Mixed_Terms[Y] / 2.0;
 815   F = Quadric->Mixed_Terms[Z] / 2.0;
 816   D = Quadric->Terms[X] / 2.0;
 817   G = Quadric->Terms[Y] / 2.0;
 818   I = Quadric->Terms[Z] / 2.0;
 819   J = Quadric->Constant;
 820
 821   /* Set small values to 0. */
 822
 823   if (fabs(A) < EPSILON) A = 0.0;
 824   if (fabs(B) < EPSILON) B = 0.0;
 825   if (fabs(C) < EPSILON) C = 0.0;
 826   if (fabs(D) < EPSILON) D = 0.0;
 827   if (fabs(E) < EPSILON) E = 0.0;
 828   if (fabs(F) < EPSILON) F = 0.0;
 829   if (fabs(G) < EPSILON) G = 0.0;
 830   if (fabs(H) < EPSILON) H = 0.0;
 831   if (fabs(I) < EPSILON) I = 0.0;
 832   if (fabs(J) < EPSILON) J = 0.0;

 <skip some lines>

 893     /* Recalculate coefficients. */
 894
 895     D += A * T1[X];
 896     G += E * T1[Y];
 897     I += H * T1[Z];
 898     J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z]
+ 2.0*I);

         /* Simple fix to redo the "set small values to 0." after
            the recalculation. */

         /* The SPEC 2017 case only needs this reset for J, but I
            assume it wouldn't hurt to redo for D, G, and I also.
            Also note that the J recalculation is different with the
            newer version of POVRAY, but that didn't change the
            "close to zero, but not actually equal to zero" issue.

         if (fabs(J) < EPSILON) J = 0.0;

 899   }


Post a reply to this message

From: Thorsten
Subject: Re: Set small values to 0.
Date: 30 Aug 2020 10:43:38
Message: <5f4bbb1a@news.povray.org>
The SPEC 2017 code is a beta of 3.7 where the source file comments had 
not been updated yet.

On 30.08.2020 06:58, DonF wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Awaking this morning though, had a question in my head whether the above
>> statement really true? I doubt you are really running v3.7 - or at least
>> any official version of v3.7 because your output has the line:
> 
> 
> The SPEC 2017 benchmark documentation indicates v3.7, but the SPEC code
> itself is still documented as being version 3.6, as indicated from the
> below comments from the quadrics.cpp. But it looks like a common issue
> between 3.6 and 3.7, unless the issue is resolved elsewhere in the newer
> version.
> 
> 
> /****************************************************************************
>   *               quadrics.cpp
>   *
>   * This module implements the code for the quadric shape primitive.
>   *
>   * from Persistence of Vision(tm) Ray Tracer version 3.6.
>   * Copyright 1991-2003 Persistence of Vision Team
>   * Copyright 2003-2009 Persistence of Vision Raytracer Pty. Ltd.
>   *---------------------------------------------------------------------------
>   * NOTICE: This source code file is provided so that users may experiment
>   * with enhancements to POV-Ray and to port the software to platforms other
>   * than those supported by the POV-Ray developers. There are strict rules
>   * regarding how you are permitted to use this file. These rules are contained
>   * in the distribution and derivative versions licenses which should have been
>   * provided with this file.
>   *
>   * These licences may be found online, linked from the end-user license
>   * agreement that is located at http://www.povray.org/povlegal.html
>   *---------------------------------------------------------------------------
>   * This program is based on the popular DKB raytracer version 2.12.
>   * DKBTrace was originally written by David K. Buck.
>   * DKBTrace Ver 2.0-2.12 were written by David K. Buck & Aaron A. Collins.
>   *---------------------------------------------------------------------------
>   * $File: //depot/povray/spec-3.6/source/quadrics.cpp $
>   * $Revision: #1 $
>   * $Change: 5014 $
>   * $DateTime: 2010/06/13 03:51:51 $
>   * $Author: thorsten $
>   * $Log$
>   *****************************************************************************/
> 
> 
> And once again, my simple fix, at least for the SPEC 2017 test case, was to
> simply, rerun the "set small values to 0" check after the "recalculation".
> 
> 
>   808   /* Get quadrics coefficients. */
>   809
>   810   A = Quadric->Square_Terms[X];
>   811   E = Quadric->Square_Terms[Y];
>   812   H = Quadric->Square_Terms[Z];
>   813   B = Quadric->Mixed_Terms[X] / 2.0;
>   814   C = Quadric->Mixed_Terms[Y] / 2.0;
>   815   F = Quadric->Mixed_Terms[Z] / 2.0;
>   816   D = Quadric->Terms[X] / 2.0;
>   817   G = Quadric->Terms[Y] / 2.0;
>   818   I = Quadric->Terms[Z] / 2.0;
>   819   J = Quadric->Constant;
>   820
>   821   /* Set small values to 0. */
>   822
>   823   if (fabs(A) < EPSILON) A = 0.0;
>   824   if (fabs(B) < EPSILON) B = 0.0;
>   825   if (fabs(C) < EPSILON) C = 0.0;
>   826   if (fabs(D) < EPSILON) D = 0.0;
>   827   if (fabs(E) < EPSILON) E = 0.0;
>   828   if (fabs(F) < EPSILON) F = 0.0;
>   829   if (fabs(G) < EPSILON) G = 0.0;
>   830   if (fabs(H) < EPSILON) H = 0.0;
>   831   if (fabs(I) < EPSILON) I = 0.0;
>   832   if (fabs(J) < EPSILON) J = 0.0;
> 
>   <skip some lines>
> 
>   893     /* Recalculate coefficients. */
>   894
>   895     D += A * T1[X];
>   896     G += E * T1[Y];
>   897     I += H * T1[Z];
>   898     J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z]
> + 2.0*I);
> 
>           /* Simple fix to redo the "set small values to 0." after
>              the recalculation. */
> 
>           /* The SPEC 2017 case only needs this reset for J, but I
>              assume it wouldn't hurt to redo for D, G, and I also.
>              Also note that the J recalculation is different with the
>              newer version of POVRAY, but that didn't change the
>              "close to zero, but not actually equal to zero" issue.
> 
>           if (fabs(J) < EPSILON) J = 0.0;
> 
>   899   }
> 
> 
> 
> 
>


Post a reply to this message

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