On 4/21/20 3:52 AM, jr wrote:
> hi,
> 
...
>>
>> The scale and range of a scene with respect to accuracy as an issue is
>> always there relative to the accuracy you have available.
> 
> naively, I'd assumed some kind of upgrade/development "policy" that sees all
> floats replaced with doubles, in time.
> Maybe. I'm not aware of any such policy, but I'm not a core developer.

The code base is internally mostly at double floats. There are a few 
places like bounding and color management where single floats get used. 
Done to save storage in the former I think or where the additional 
accuracy is of no practical value (to color results at least) in the 
later. On 'my' list to look at moving these to doubles.

For povr in the continuous pattern wave modification code I recently 
moved a few pattern stored values from singles to doubles. Partly to 
avoid the type conversions, but mostly because my grand plan is to flush 
out the function/pattern code so the interplay between functions and 
patterns is as seamless as it can be. I didn't want functions modified 
by a wave modifier to be getting single float parameters - in a way not 
visible to the user - when the reasonable assumption is everything is at 
double floats.

>> ...
>> Relatedly, I believe in going after better performance continually in
>> software tools - otherwise you're on the slippery slope to poky. :-)
> 
> hmm, I probably "sit on the fence" on that.  eg agree with you when it's a
> compiler or other s/ware which has to take h/ware developments into account, but
> kind of disagree for, say, programs not tied to h/ware, like 'sed'.
> 

I'm with you I think. I failed to be clear (I 'was' too flippant :-)). I 
am pushing for continual performance testing and especially an 
unwillingness to take much slowdown due changes over time without 
compensating improvements somewhere.

What has happened intentionally - or not - with POV-Ray moving v37 to 
v38 and the generic architecture compile shipped with linux 
distributions is a 30-40% slow down with certain common types of scenes.

https://github.com/POV-Ray/povray/issues/363

This after running down a lot of stuff like dynamic casts in the ray 
tracing code to recover performance seen in the benchmark scene.

In part the benchmark scene doesn't cover but a small slice of 
functionality in POV-Ray and mostly this was all that was getting run 
for performance testing.

I believe too, too many times we said this change is only a 1 or 2% slow 
down... Do enough of those in a year and you are well on to pokey at 
year end. The 1 or 2% slowdown at year end is relative to current 
performance. Many later changes, if looked at January 1st, might have 
been rejected out of hand as being too much of a slow down.

Aside: The GNU build methodology supports a code marking method for 
hardware optimized versions of functions that get picked/set at 'load 
time' depending upon your particular hardware or certain hardware 
capabilities. Both compiler and hand optimized code can be implemented 
in this way. Yes, this a reason my personal povr version is headed to a 
GNU only build(1) process. I want to play with this capability in povr 
proper.

Bill P.

(1) - Our current vector template class looks to be somewhat in the way 
of best 'compiler' hardware optimization...

Post a reply to this message