Re: LuaJIT problems

[Mike Pall <mikelu-0801@...>]

Mark Meijer wrote:
> [...] But it does run faster. Around
> 50% faster with threads that do nothing other than yield in a loop,
> and anywhere from 2 to 4 times as fast with threads that actually do a
> little work.

That doesn't sound so bad. If you need the speed, use it. If you
don't, then maybe it's easier to proceed without it.

This may sound strange, coming from me, but LuaJIT is just a tool
with specific strengths and specific weaknesses (as you've
discovered). Only use a tool, if it fits the problem at hand.

> Could that be because the stack size is now too low? I've set it to
> 128k for the moment. I couldn't say, since I have no clue how LuaJIT
> and Coco handle coroutines, nor exactly what has an impact on how much
> stack space it needs. Of course, I imagine that anything happening in
> a C library like wxLua, requires stack space as usual.

GUI libraries are known for their (sometimes) excessive stack
usage. I have no first-hand experience with wxLua, though. You
could try doing all GUI work from coroutines created with a
larger C stack (see the LuaJIT docs for coroutine.create() and
lua_newcthread()).

> I don't know, but I'm guessing that the Linux implementation, with
> regards to coroutines, is not something that could only work on Linux?
> Either way, on Windows, I'm not sure what the advantage is supposed to
> be of using win32 fibers for it.

Fibers are the only (reasonable) way to do this under Windows.
There's some undocumented stuff going on behind the Windows Fiber
API (like switching SEH handlers). It varies depending on the
Windows version, too. I've tried to create C stacks "by hand" for
Windows, but this experiment failed miserably.

--Mike