Re: status and perceptions of luaproc

[Javier Guerra Giraldez <javier@...>]

On Fri, Aug 7, 2015 at 8:51 AM, Rena <hyperhacker@gmail.com> wrote:
> Even Python, the "batteries, charger and solar cells included" language,
> seems to have missed this boat - it provides "threading", but only one
> thread can actually run at a time (global interpreter state is locked while
> executing) and it doesn't sound like it'd be easy to fix without breaking
> other things.

that's why there's also the "multiprocessing" module, that uses
multiple processes,each with their own interpreter stack and GIL
(sound familiar?).  It's been there for several years now, and it's
usually regarding ad "the replacement" for threads.


> I recall Lua provides some macros lua_lock and lua_unlock that an
> implementation can override (by default they do nothing) to allow
> thread-safe access. Maybe future versions could include e.g.
> LUA_USE_PTHREAD, LUA_USE_WINAPI_THREAD, etc, enabled by default on
> appropriate platforms, which would implement a basic mutex? Or would that
> add too much overhead to code that isn't using threads? Anyway it sounds
> like those macros would do much the same as Python's global lock, i.e. no
> actual parallel execution. So maybe not even worth doing?

exactly.  on top of that, even if those locks protect the LuaVM
integrity, by incorporing multithreading into the execution model, you
inherit all the fun things, like having to care about other threads
meddling with your values while you're modifying them.  say hello to
locks...

and it's terribly inefficient: in multicore hardware, most simple
locks are by nature system-wide, having to propagate to _every_ core
in the system.  By experience, even in a high-memory-bandwidth system
like modern Xeon familes, there's a low maximum number of inter-core
messages per second.  Think like a core can do several thousand
operations in the same time as propagating just one lock.



> The thread libraries I've used run a separate Lua state in each thread and
> provide some type of communication channel between them. This is a nice
> simple model, but maybe not the most efficient.

Au contraire, passing messages is far more efficient than sharing
variables; because you only incur in one inter-process fault, instead
of trashing caches on almost each access of shared variables.


> Even just a module that uses separate Lua states for each thread but can
> work around some of those limitations (which I suspect would require a
> modified Lua), e.g. copying tables/functions/userdata directly between
> states without the need for slow dumping/reloading or recursive copying,
> would be great.

I'm succesfuly faking a similar thing using FFI objects on LuaJIT; by
manually using mmap() to allocate memory it's easy to get them shared
between processes.  The consistency is "just" a matter of discipline.

but even then, i have to be _very_ careful to make each message count,
or performance is trashed.

on a related note, i'm using processes (spawned with fork()) and not
threads because if I create many LuaJIT VMs on the same address space,
they all limit to the same "low 2G" addresses, making it unusable for
anything beyond a hundred threads.  with enough RAM, a thousand
processes is quite doable.


> The holy grail of course would be true parallel execution, using multiple
> CPU cores, within one Lua state. It's just unfortunate that threading is one
> of those annoying things that's extremely difficult to do correctly, but
> extremely easy to do in a way that seems to work but contains a subtle,
> critical flaw that only manifests in production at 16:53 on a Friday, just
> once, and then can't be reproduced until everyone has dismissed it as cosmic
> ray induced error and given up looking for the bug.

with care, it's not so hard to get multithreading consistency; but
making it perform well? that's a real challenge.


-- 
Javier