On 2/17/19 6:41 PM, William F Pokorny wrote:
>>
>> IIRC there was a use case for a `polynomial` primitive that needed an 
>> order of 16, and Jerome decided it would be nonsense to increase it by 
>> 1 just to wait for the next use case to require an order of 17; so he 
>> went ahead and increased the limit to something that was not totally 
>> arbitrary. 35 was a natural choice because above this threshold the 
>> `binomials` array of constants would overflow the data type on some 
>> machines (32-bit `unsigned int`).
>>
>> If we want to use a lower maximum order, 19 would be a logical choice, 
>> as it's the threshold at which we could change the datat type of the 
>> `binomials` array from `unsigned int` to `unsigned short` to save some 
>> memory.
>>
> 
> Thanks for the background. I'll put it on my list to look at what 19 
> would give us performance wise.

Same test set up as before; setting MAX_ORDER to 19.

+wt1
14.25 -> 14.14 ---> -0.77%

+wt2
14.31 -> 14.16 ---> -1.05%

+wt3
19.11 -> 18.79 ---> -1.67%

+wt4
22.90 -> 22.35 ---> -2.40%

For my own day to day use I plan to hard code my working POV-Ray version 
to 10 (sphere_sweep) as that's the largest needed for other than user 
coded polynomials as far as I know.

Bill P.

Post a reply to this message