Re: How to comprehend that Lua automatically removes whatever is in the stack below the results after the function returned?

[孙世龙 sunshilong <sunshilong369@...>]

Hi, bel

>In any case, you need to deal with Lua dynamically increasing and reducing
>not only the stack, but many other objects as well. Handle these
>allocations by a proper "special purpose" alloc/free implementation,
>instead of using the "general purpose" algorithms in a typical non-realtime
>standard C library.
TLSF is a good choice. What do you think about it? Or any other
available choice?


>One key to reach real-time requirements is not to prevent Lua from
>dynamically allocating the stack (or any other object), but to provide an
>allocator function capable of providing memory in a fixed time.
And
>This way, you will not end up with a "general purpose real time Lua",
>but with a special purpose system ... that cannot handle lengthy strings,
>but work with numbers in real time.

I agree that the allocator function is the key factor. But as you said that
the "special" purpose real-time system that even cannot handle lengthy strings,
so I still think that dynamically growing the stack is a problem that should be
solved or avoided.

And another question, what do you think "real-time" really mean? Does it have
any relation with handling lengthy strings? I am really confused, though I have
been doing some development with real-time OS for half an year.

>Would you mind telling something about the purpose of the real time system
>and the role of Lua therein?
I want the Lua script can meet soft real-time requirement, which
controls a robot
arm to grab food(i.e cookies).

Thank you for your attention to my question.

Best regards
Sunshilong

On Thu, Sep 24, 2020 at 2:56 AM bel <bel2125@gmail.com> wrote:
>
> > Growing an object requires copying, which can't be done in constant time. Most CPUs can copy very quickly but it's still an O(n) operation, however efficient you make the memory management.
>
> Even copying is only O(n) for a "larger" number of bytes n. For small n effects memory access, caching, ... (random effects) do have a much bigger effect on execution time than copying a byte more - making it effectively independent from n. The ~32 bytes mentioned before would be "small" from that point of view.
>
> You are definitely right when it comes to operations with large n, like concatenating lengthy strings ... so ... "don't do that " (or measure up to what length you can handle the resulting delay).
>
> To clarify the recommendation: Write an allocator function where you can log the memory usage profile, recording what memory blocks your Lua program is actually using (for me the vast majority of blocks was < ~60 Bytes, in total some hundred blocks of this size, and after initialization it never needed a block with more than some hundred bytes, ... don't remember the exact numbers). Then preallocate ~1000 blocks * ~60 bytes, lock it in memory, and use this preallocated pool in your allocator function (if you use it for just one state, you can even drop mutexes there).
>
> This way, you will not end up with a "general purpose real time Lua", but with a special purpose system ... that cannot handle lengthy strings, but work with numbers in real time.
> From my experience, real time systems are always "special purpose" anyway - so this approach might work for you or not, depending on what the system is supposed to do.
> Would you mind telling something about the purpose of the real time system and the role of Lua therein?
>
>
> On Wed, Sep 23, 2020 at 5:32 PM Gé Weijers <ge@weijers.org> wrote:
>>
>>
>>
>> On Wed, Sep 23, 2020, 06:15 bel <bel2125@gmail.com> wrote:
>>>
>>> One key to reach real-time requirements is not to prevent Lua from dynamically allocating the stack (or any other object), but to provide an allocator function capable of providing memory in a fixed time. (Others are fine tuning garbage collection, preloading libraries and replacing/not using the io library after initializing, by the way).
>>
>>
>> Growing an object requires copying, which can't be done in constant time. Most CPUs can copy very quickly but it's still an O(n) operation, however efficient you make the memory management.
>>
>> Some operations performed by the garbage collector may also not meet hard realtime requirements. It all depends on how much delay you can handle.
>>
>>
>>>