[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: another try at multithreading
- From: Asko Kauppi <askok@...>
- Date: Thu, 19 Jun 2008 16:20:59 +0300
Javier Guerra kirjoitti 19.6.2008 kello 15:41:
On Thu, Jun 19, 2008 at 3:02 AM, Asko Kauppi <email@example.com>
As a minor correction to your list of "deep tables, closures,
etc.", at least Lanes has no issues with deep tables. Maybe you
tables (takes more time to copy back-forth) or recursive tables (not
implemented, to favor speed). Anyways, for closures and coroutines
argument is valid.
yep, i know some of the serialising solutions there are pretty
complete; but it's a heavy price to pay for parallelism.
Just to give some more light on the issue, which really should be
benchmarked before any _real_ discussion takes place. But here goes..
Serialization does have a hefty price tag (low performance) but in
many cases, it is not needed.
When you give parameters to a new state, or read a ready state's
return values, this is done without serialization, as a direct state-
to-state copy (in Lanes, at least). Therefore the operation might not
be as heavy-weight as you may think. Whether it's speedy enough
depends of course on each situation.
When data is passed between two running states (in Lanes),
serialization is used, since it does not require the states to be
Still, as a general rule "separated" approach does suit better to
"bigger grain" multithreading, where each Lua state is akin to OS
It is good for us all, and for Lua, to have a broad approach to this
area. Also it gives a more practical basis for comparisons, once
implementations do exist.
There are these two ways of seeing parallelism. And networking /
processes can be seen as third.
yep, in fact, the serialising step imposed by LuaLanes might make it
easy to evolve into a clustering solution without redesigning
Indeed, it does. I happen to be working for a clustering application
nowadays, though not with Lua.