On 4/21/20 3:52 AM, jr wrote:
>> 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
>> 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.
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
(1) - Our current vector template class looks to be somewhat in the way
of best 'compiler' hardware optimization...
Post a reply to this message