 |
lua-l archive |
|
|
||
|
> If I understand correctly, all the objects should have
a pre-known max
> size to meet the soft real-time requirements.
Not exactly. The concept is to allow the Lua interpreter to allocate and free all objects, as it always does, but to not pass this memory dynamics to the operating system or glibc. You can effectively make most reallocations “zero cost” operations (at the cost of a small memory overhead). Probably some pseudo-code for the allocator function explains this more clearly:
if (nsize==0) {
…
} else if (!ptr) {
nsize =
get_better_quess_of_size_from_object_type(nsize, osize); /* osize is LUA_T*,
see https://www.lua.org/manual/5.3/manual.html#lua_Alloc
*/
if (nsize <= 64) return new_element_from_64_bytes_pool();
if (nsize <= 256) return
new_element_from_256_bytes_pool();
if (nsize <= 4096) return
new_element_from_4096_bytes_pool();
if (we_are_in_initialization) return
malloc(); /* can do this when loading program */
else fatal_error(); /* but cannot during cyclic real-time … somebody
should have tested before */
} else {
if (is_in_64_bytes_pool(ptr)) {
if (nsize <= 64) return ptr;
/* resizing in the range [1..64] does “nothing” */
else … /* move to a bigger block …
happens rarely */
} else if (is_in_256_bytes_pool(ptr))
{
if (nsize <= 256) return ptr;
/* … same as before */
…
Where the pools are basically arrays, like
static char my_64_bytes_pool[500][64], my_256_bytes_pool[100][256], my_4066_bytes_pool[20][4096];
except they are allocated page aligned and locked. The sizes 64, 256 and 4096 (and
that there are 3 pools), the number of 500, 100 and 20 elements are just
example numbers here. Actual numbers come from a lot of testing/profiling of
real life programs made for exactly this context (if the numbers are not well chosen,
the code will still work but it will waste some memory). This code assumes
objects will tend to keep their sizes within a certain range – there is no
theory predicting this (as to my knowledge), it is an experimental finding.
Maybe this code expresses more clearly what I meant, than my attempts to
explain it in English. Essentially Lua forwards all resizing operations to the
allocator, but the allocator does not call malloc/realloc/free during real time
processing. You need to know the maximum amount of memory used and pre-allocate
it (with some reserve). But for real time you anyway need to keep memory
consumption below some maximum, because when the system starts to swap data to
disk due to low memory, even soft real time is definitely lost.
> I use Lua scripts to control the robot arm to grab
cookies, plates, fruits
> and etc. And move them from one point to another.
I’m curious about the role of Lua in your application. Are you using Lua for the robot program (defining pick/place positions and sequences), object identification/tracking (camera, sensor, conveyor belt?), robot coordinate transformation and/or also for real time path trajectory generation (for servo drives)?
> No damage or bad things may happen if the soft
real-time requirement is
> breaked occasionally.
I think there is no commonly agreed on clear definition of “soft” real time and no precise discrimination from “hard” real time – for an estimation of the real time capability of a system, you need a lot more information (cycle time, jitter of the underlying operating system and hardware, timing constraints of I/O devices and/or field busses, …). Missing a sensor signal or detecting the position of a moving object at the wrong time will yield to missed picks, discontinuities in motion profiles will cause undesirable dynamic stress for the robot mechanics or drop a grabbed cookie, …
Archiving real time capability of an interpreter is also just a small step on a long path towards a full robot control software ecosystem. In case you are interested in a professional, commercial hard real-time software system for robot control (including sensor/camera integration, path blending, events some milliseconds before a pick position is reached, …), I might be able to give you some recommendations, depending on your exact needs. Just write me an email (you have my email address?). Feel free to do so as well, for highly robotic specific topics (that might be too specific for the Lua mailing list). Probably you are trying to build something already existing.
>However, the data processed in every cycle has a more or less constant,
>and limited size. There is no handling of "lengthy" (thousands of bytes)
>strings.
If I understand correctly, all the objects should have a pre-known max
size to meet the soft real-time requirements.
>If you have something completely different in mind, all my suggestions
>above may not be helpful at all - so probably you should explain a little
>more on your use case (I don't want to bother you with irrelevant stuff).
I use Lua scripts to control the robot arm to grab cookies, plates, fruits
and etc. And move them from one point to another.
No damage or bad things may happen if the soft real-time requirement is
breaked occasionally.
Best regards.
Sunshilong
On Fri, Sep 25, 2020 at 5:57 AM bel <bel2125@gmail.com> wrote:
>
> Yes, all objects (strings, tables/arrays, ...) need to have a known maximum size. But that's by no means specific to Lua.
> There are a lot of implicit assumptions on the type of real time system in my two short comments above - that's why I finally asked for some information on the kind of real time system you have in mind, because maybe all my attempts to explain could be a waste of time for both of us, if you have completely different requirements than I had and you are looking for something completely different.
>
> By "real time" I mean some loop running in some fixed cycle (somewhere between 100 microseconds and 10 milliseconds) or event/interrupt driven. Every cycle starts with reading some input values (booleans and numbers) corresponding to sensor signals. Inputs could also be "messages" (data from serial communication, network packages, ...) - these are of type string but with a well known maximum length (the serial interface has a maximum baud rate, you know the cycle time --> you can calculate it). Within every cycle you need to process all (relevant) inputs, e.g. by filtering it and storing results in a log (data logger), by calculating outputs (closed loop control), probably updating some internal state machines, ... In any case, you must never miss any cycle, because the input data will be gone, the data logs incomplete, the outputs and state machines incorrect. However, the data processed in every cycle has a more or less constant, and limited size. There is no handling of "lengthy" (thousands of bytes) strings.
> If you have something completely different in mind, all my suggestions above may not be helpful at all - so probably you should explain a little more on your use case (I don't want to bother you with irrelevant stuff).
>
> On Thu, Sep 24, 2020 at 3:34 PM Gé Weijers <ge@weijers.org> wrote:
>>
>>
>>
>> On Wed, Sep 23, 2020, 11:56 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.
>>
>>
>> Growing a table is the operation that would cause significant delays when the table is large enough. You would have to keep sizes small or fixed to guarantee constant time operations.
>>
>> Growing an array by doubling it's size when you run out of space has O(1) complexity, but that is amortized complexity which is not good enough for hard realtime work unless you limit the maximum array size.
>>
>>>