Re: embedded lua: invocation overhead?

["Gabor Szokoli" <szocske@...>]

On 10/13/06, Asko Kauppi <askok@dnainternet.net> wrote:
> I won't be the best responder, but you will get others.. :)

You are already of great help, party by making me think it over more thoroghly.

> What I'd consider if I was you, is the syntactic simplicity
> (readability, maintainability) of the language you will choose.
> Partly, it is about execution speed, but if you choose something that
> later on just drools you down because of lack of expression, that's
> sacrificing developer resources. I'd _not_ roll my own language.

The application domain is quite limited: "call context" manipulation
in a telecommunication software. Think "Call Processing Language" in
Sip Express Router.

> That said,
> - try it. You didn't refer to the platform you're running on, which
> would be vital information to know whether "thousands" is applicable
> or not. It's definately not out of the reach (of a modern computer)
> anyways. On 20-200MHz embedded, it might be.

You are right, I was quite uninformative.
We are using high performance servers, but on the other hand, the
script which removes the first letter from a string (the international
access digit from the beginning of a called number, say) should not
consume a measurable portion of the resources.
I am sure the manipulation itself is quite efficient, I am woried
about vm startup.
A single call can have about 5 independent script invocations at
different stages of call processing, and we handle hundreds of calls
each second.

> - memory. How much do you have it; can you have a pool of pre-
> initialized Lua states available, that you'd just grab and call per
> each invokation. alas:

I was hoping I would not need that. Just too much constant turnover, not peaks.

> - threading. Are the invocations coming sequentially (you'd need just
> one lua_State) or N numbers whenever?

Possibly as many as parell calls: indefinite.

> - tradeoffs: nothing much. I don't see a single thing where modding
> Lua would make it essentially faster for you. Number types, if you're
> running without an FPU (surely, you aren't?).

There surely is an (unused) FPU. Again, I'm not trying to speed up
execution, I am worried about vm initialisation, the scripts
themselves are negligably small. However, excuse my suspicion, but
would prefer not to have a long-lived "strategy factory" running in a
scripting language.

> - precompiling. You say configuration files, and talk of LuaJIT. If
> you can completely pre-do the compilation phase, you'd definately
> gain some speed. Question is, if you use the same script multiple
> times, precompile. If not..

Yes, the scripts would come from config files, practically never reloaded.
They in fact constitute configuration of call handling.
They just get run terribly often :-)

> > - Can I make sure no script can hurt the host process?
>
> How could they?  Meaning yes, you can (should) disable things like
> 'os.*' table; simply set them to nil or better still never initialize
> in your host C module.
>
> Then Lua will only be able to touch what your object bridging allows
> it.  What exactly you mean by 'hurt'?

Well, that. Segfault my process, corrupt memory, etc.
I'm glad I can't.

> Eternal loops could be seen as a way to hurt; but there are ways to
> prevent that (timers, mainly).

Yes, I was planning to prime a trigger so no call gets held up in
scripted for longer than a few milliseconds.

> > - Can I destructively interrupt the "parse" (or whatever the
> > equivalent of dofile is for an in-memory bytecode-compiled script
> > which I am sure I can cache and reuse) function when a safety timer
> > expires?
>
> This escapes me; can you rephrase that (or maybe someone else gets it
> rights and teaches us).

The above trigger, a separate c++ thread would need to be able to
destroy a vm instance and regain its resources.

> Please tell the list where you ended up, and why. Would be
> interesting to hear!  :)

I'll report back when we make a decision if you guys are interested.

On the other hand, EEL looks quite promissing :-)


Thanks:

Gabor Szokoli