hi,

I have a macro which expands to an array, eg

#macro mkArr(...)
.....
array [2] {...}
#end

which gets assigned, repeatedly, to the same '#declare'd variable.  is this ok
wrt memory management, or is it better to '#undef' the elements, and or the
array, before replacing it wholesale?  is there a difference?  do 'mixed' arrays
behave same as "normal" arrays?


regards, jr.

Post a reply to this message

Le 2020-06-09 à 06:07, jr a écrit :
> hi,
> 
> I have a macro which expands to an array, eg
> 
> #macro mkArr(...)
> .....
> array [2] {...}
> #end
> 
> which gets assigned, repeatedly, to the same '#declare'd variable.  is this ok
> wrt memory management, or is it better to '#undef' the elements, and or the
> array, before replacing it wholesale?  is there a difference?  do 'mixed' arrays
> behave same as "normal" arrays?
> 
> 
> regards, jr.
> 
> 
Whenever you assign a new value to any variable, the new value simply 
replace the old one in the same memory space.
The only issue that may arise for memory management, is when you assign 
a string that don't always have the same length.

So, you don't need to #undef.

I don't know for mixed arrays.

You may need to #undef if you want to assign a new value of a different 
type like float to vector or string.

Post a reply to this message

hi,

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-06-09 à 06:07, jr a écrit :
> > I have a macro which expands to an array, eg
> >
> > #macro mkArr(...)
> > .....
> > array [2] {...}
> > #end
> >
> > which gets assigned, repeatedly, to the same '#declare'd variable.  is this ok
> > wrt memory management, or is it better to '#undef' the elements, and or the
> > array, before replacing it wholesale?  is there a difference?  do 'mixed' arrays
> > behave same as "normal" arrays?
> >
> Whenever you assign a new value to any variable, the new value simply
> replace the old one in the same memory space.
> The only issue that may arise for memory management, is when you assign
> a string that don't always have the same length.
>
> So, you don't need to #undef.

no strings in this project.  still not quite clear what happens when "...simply
replace the old one in the same memory space".  does POV-Ray do "garbage
collection" at this point, or is the previous value orphaned?

(I ask because the example is a simplification.  the array returned is dynamic
and may contain hundreds of results/elements.  my main "problem" is that the
documentation does not give me any clues.)


> I don't know for mixed arrays.
>
> You may need to #undef if you want to assign a new value of a different
> type like float to vector or string.

currently I simply "#declare Arr = array {};", ie overwrite (?) the previous
content, hence want/need to know what happens to the old values.


regards, jr.

Post a reply to this message

On 6/11/20 3:49 AM, jr wrote:
> hi,
> 
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2020-06-09 à 06:07, jr a écrit :
>>> I have a macro which expands to an array, eg
>>>
>>> #macro mkArr(...)
>>> .....
>>> array [2] {...}
>>> #end
>>>
>>> which gets assigned, repeatedly, to the same '#declare'd variable.  is this ok
>>> wrt memory management, or is it better to '#undef' the elements, and or the
>>> array, before replacing it wholesale?  is there a difference?  do 'mixed' arrays
>>> behave same as "normal" arrays?
>>>
>> Whenever you assign a new value to any variable, the new value simply
>> replace the old one in the same memory space.
>> The only issue that may arise for memory management, is when you assign
>> a string that don't always have the same length.
>>
>> So, you don't need to #undef.
> 
> no strings in this project.  still not quite clear what happens when "...simply
> replace the old one in the same memory space".  does POV-Ray do "garbage
> collection" at this point, or is the previous value orphaned?
> 
> (I ask because the example is a simplification.  the array returned is dynamic
> and may contain hundreds of results/elements.  my main "problem" is that the
> documentation does not give me any clues.)
> 
>> I don't know for mixed arrays.
>>
>> You may need to #undef if you want to assign a new value of a different
>> type like float to vector or string.
> 
> currently I simply "#declare Arr = array {};", ie overwrite (?) the previous
> content, hence want/need to know what happens to the old values.
> 

I'm not familiar with the new-ish array / dictionary functionality or 
code, but I think POV-Ray will let you know if an undef is required. You 
cannot redefine functions for example, without first an undef(2).

It should be the previous memory gets freed(1) on the new declare if 
POV-Ray allows it. Perhaps proceed as if all OK, and worry about undefs 
if you see memory growth? In such a case, I'd consider the lack of a 
parser error message (or not freeing memory automatically) a bug.

(1) - IIRC memory use is higher with the newer features. Both because 
mixed array elements are all of a size which accommodates the largest. 
And on growth the increments are in some sort of multiple of the 
existing size. Again, not familiar with the code and I have not myself 
used it. All Christoph's work.

(2) - Undefs are are not going to help with memory fragmentation over 
time in any case supposing you are allocating and freeing a large number 
of varying arrays.

Aside: Anyone else find the #declare, #undef (un-define) pairing 
inconsistent. ;-)

Bill P.

Post a reply to this message

hi,William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/11/20 3:49 AM, jr wrote:
> > Alain Martel <kua### [at] videotronca> wrote:
> >> Le 2020-06-09 à 06:07, jr a écrit :
> >>> I have a macro which expands to an array, eg
> >>> ...
> ...
> I'm not familiar with the new-ish array / dictionary functionality or
> code, but I think POV-Ray will let you know if an undef is required. You
> cannot redefine functions for example, without first an undef(2).
>
> It should be the previous memory gets freed(1) on the new declare if
> POV-Ray allows it.

agree.

> Perhaps proceed as if all OK, and worry about undefs
> if you see memory growth?

is what I'm doing now, fingers crossed, "flying by the seat of the pants".  :-(

> In such a case, I'd consider the lack of a
> parser error message (or not freeing memory automatically) a bug.
>
> (1) - IIRC memory use is higher with the newer features. Both because
> mixed array elements are all of a size which accommodates the largest.
> And on growth the increments are in some sort of multiple of the
> existing size. Again, not familiar with the code and I have not myself
> used it. All Christoph's work.

both mixed arrays and dynamic arrays are used, together.

(will 'clipka' be able to chip in, at some point?  (I must have missed what
happened))

> (2) - Undefs are are not going to help with memory fragmentation over
> time in any case supposing you are allocating and freeing a large number
> of varying arrays.

had not considered fragmentation.  how does it work, POV-Ray allocates all in
advance and doles out, or allocates on demand?  with relatively large arrays
being created/overwriting an existing, is there a rule of thumb for estimating
memory consumption[*]?

[*] another thing missing completely in the documentation.

(will 'povr' provide at least some introspection tools?)

> Aside: Anyone else find the #declare, #undef (un-define) pairing
> inconsistent. ;-)

I don't think it too bad since it covers '#declare'd and '#local's, but I really
think it should allow multiple identifiers, ie
  #undef A1, A2, ...

(with or without commas)


regards, jr.

Post a reply to this message

On 6/12/20 4:12 PM, jr wrote:
...
>> (1) - IIRC memory use is higher with the newer features. Both because
>> mixed array elements are all of a size which accommodates the largest.
>> And on growth the increments are in some sort of multiple of the
>> existing size. Again, not familiar with the code and I have not myself
>> used it. All Christoph's work.
> 
> both mixed arrays and dynamic arrays are used, together.
> 
> (will 'clipka' be able to chip in, at some point?  (I must have missed what
> happened))

Don't know. Time will tell. Communication stopped over a year ago as you 
know.

> 
>> (2) - Undefs are are not going to help with memory fragmentation over
>> time in any case supposing you are allocating and freeing a large number
>> of varying arrays.
> 
> had not considered fragmentation.  how does it work, POV-Ray allocates all in
> advance and doles out, or allocates on demand?  with relatively large arrays
> being created/overwriting an existing, is there a rule of thumb for estimating
> memory consumption[*]?
> 
> [*] another thing missing completely in the documentation.

I thought fragmentation was probably your first concern when you 
mentioned garbage collection :-). Garbage collection in terms of 'stop 
and do it sometimes' isn't really a POV-Ray SDL / c++ thing.

The code allocates and frees as needed. Memory management is left to 
libc's malloc et al. Perhaps possible to do better here - jemalloc? Way, 
way down on my to-play-with list though.

Some rules of thumb for memory consumption have been described in the 
newsgroups over time - Christoph's efforts mostly - but nothing in the 
documentation. Such documentation is not easy to keep current. Updates 
in povr have already changed things in quite a few places.

Aside: On some level I wonder why undef exists... A long time ago when 
memory was precious I can see reason's to make it available to users so 
things in include files, for example, could be freed early - while 
parsing rather than at post parsing. Today, I'm playing with the idea of 
dumping the keyword. It would push us a smidgen more in the functional 
language direction - which for a scene description language I think a 
good thing. With respect to dynamically executing functions via pointers 
within inbuilt functions, not having the keyword would make things 
simpler.

> 
> (will 'povr' provide at least some introspection tools?)
> 

Nothing planned short term. A wild idea on which I spent a little time 
late last year and early this, is replacing much of the internal povr 
backbone code with Redis. It would enable considerable introspection - 
while enabling better shape/functional code flow for performance. But 
yeah, someday, maybe.

Remembering now, shortly into my first real job, being pulled aside by 
an older co-worker after a meeting. A meeting in which I'd been asked 
how long it would take me to do a task. I'd blurted out two hours. He 
said, "You don't believe it now, but whenever answering how long will it 
take questions with respect to technical issues, always bump your first 
thought up to the next work-time increment and multiply by two. Two 
hours -> day * 2 -> two days. Not sure how he came up with this formula, 
but pushing 40 years later it's been remarkably accurate. This rule of 
thumb in mind - it doesn't bode well for the Redis idea... :-)

Bill P.

Post a reply to this message