lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Mark Meijer wrote:
> However if I wanted to spawn, say, 5000 of 'em it should be no
> problem. But with LuaJIT it is. If I launch 1000, it works. I launch
> another 1000, it still works. If then I launch another 1000, it
> crashes with the out of memory error. I also noticed that 1000 of my
> fibers (i.e. what I call fibers in my little Lua module) costs about
> 9MB of memory with JIT, while only a little over 2MB in plain Lua.
> What's more, it's 9MB regardless of whether or not I include the stack
> compiler flag for LuaJIT to decrease its size. So... Am I overlooking
> something else? :P

Apparently the *reserved* stack size has not been reduced (and
this is what counts here). The "cost" you are seeing is only the
*committed* stack size (2 stack pages at 4K plus the thread
struct and the Lua stack, so 9K per thread sounds about right).

Try setting the STACKSIZE statement in the .DEF file for the EXE
as MSDN recommends.

> Anyway, about coroutines in LuaJIT... My whole point of using
> coroutines was because I don't know of any other threading mechanism
> that could handle such large amounts of threads so efficiently. Should
> I forget about LuaJIT for this particular demo app? I don't know a
> great deal about actual fibers in windows.

Maybe yes, maybe not. It depends on what you're doing. LuaJIT 1.x
relies on Windows fibers to provide individual stacks for
coroutines. So there is some memory overhead and some overhead
for coroutine creation and coroutine switching due to the calls
to the WIN32 fiber functions (it's much faster on Linux with
inlined coroutine switching).

You really have to benchmark a typical usage scenario to find out
whether the use of LuaJIT pays off in this case.