Thanks Mike, exactly what I wanted to know. Am 15.07.2012 13:47, schrieb Mike Pall:
Tobias Oberstein wrote:Could someone give me a rough estimate on - time it takes to instantiate a new VM2 microseconds for lua_open() (no libraries) 30 microseconds for lua_open() + luaL_newstate() (with all default libs) (On Linux/x64 at 3 GHz) You can cut down on the overhead if you don't need all libraries.- the minimal memory footprint of a newly created VM instance8 KB without any libraries 23 KB with all libraries That's the minimum footprint with a shared allocator across all instances (i.e. the system allocator, not the builtin one).
Those numbers are really great and very competitive, even when compared to a run-time/language that was written to optimize those metrics (Erlang).
Say I have a process creating 10k VMs. How long will it take, how much memory consume?That's not a useful scale for VM instances. Use one VM for each thread and divide them up with coroutines. Each coroutines needs only around 400 bytes, including a minimal stack.
Sure, there is coroutines and deferred patterns. I was just curious whether the Erlang approach (concurrent sequential state machines communicating via message passing) would work with LuJIT in principle.
Have a thread pool size cpu cores, and schedule VM to execute on that.Compared to coroutines/deferred this has the advantage that state is really isolated and (in the absence of I/O lib) VMs can be preempted
when running untrusted code.Anyway, one more related thing: the GC (also the planned new one) does GC per VM instance .. nothing global .. so I can run concurrent GC : concrruent in the sense multiple VMs collected in parallel (not concurrent in the sense within 1 VM), right?
Thanks again, Tobias