On 2/17/19 9:39 PM, clipka wrote:
> Am 18.02.2019 um 00:41 schrieb William F Pokorny:
> 
...
>>
>> OK. Surprised the heap allocation is slower than one on the stack. I 
>> figured the allocation and free mechanisms were more or less the same 
>> - just being a difference of where in memory it happened. Guess not?
> 
> Definitely not.
> 

Dick, Christoph, Thanks both for the helpful tutorials on stack operation.

...
> 
> As a matter of fact, as I just discovered, C99 _does_ support such a 
> thing; but it's not "flexible array member" but "variable length 
> arrays"; and they can't be nested in structs, and C++ did not adopt them.
> 
> One reason why C++ did not adopt them is some entirely unrelated 
> fundamental stumbling block rooted in the C++ type concept. But I guess 
> they might also mess up - or at least complicate - exception handling; 
> "stack unwinding" would be the buzzword there.

This last I'd come across as I was thrashing around. I must have blended 
the two features together as one in my mind...

Bill P.

Post a reply to this message

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