Re: how to exploit multicore cpu w/ Lua?

[William Ahern <william@...>]

On Sat, Mar 31, 2012 at 07:31:09AM +0900, Miles Bader wrote:
> William Ahern <william@25thandClement.com> writes:
> >> The ideal scenario I had in mind was the ability to have a modified
> >> LuaVM that bundles LuaLanes behind the scenes, making it invisible
> >> to the developers. Legacy code would not need any modification
> >> (calls to coroutines stay unmodified): the VM transparently wraps
> >> those calls and redirect them to the appropriate LuaLanes calls. Is
> >> this reasonable ? Does this "LuaLanesVM" exists already ?
> >
> > I wonder if time would be better spent hacking the Lua GC to allow
> > moving objects between different states.
> 
> Yeah, some sort of "multi-thread-aware GC", which either allows
> objects to be moved between threads (not so simple of course,
> e.g. with deep-vs-shallow, strings, etc), or even better allows one to
> just _share_ objects directly between threads, does seem the holy
> grail.
> 
> Hmm, surely the interaction of GC and multi-threading must have
> received a lot of research attention by now...
> 

No doubt, but the real issue is whether Lua could implement any such
algorithms without a substantial penalty in code complexity and run-time
performance. The former being the most important.

Perhaps if a constraint was added, like a small, fixed number of parallel
states, things could be considerably simplified. The bookkeeping for an
indefinite number of threads surely must be more complex than if, say, you
limited yourself at compile time to, say, 32 or 64 parallel threads. Then
each thread-aware object (promoted to that status when copied across states)
could maintian a simple reference map (similar to a reference count). Such a
thing would be easy to inherit when an object was added to a thread-aware
table object, for example.

That's probably hopelessly naive, though. I should do some real research,
but my ACM library membership lapsed.