 |
lua-l archive |
|
|
||
|
Javier Guerra kirjoitti 19.6.2008 kello 15:41:
On Thu, Jun 19, 2008 at 3:02 AM, Asko Kauppi <askok@dnainternet.net> wrote:Good luck.thanks!As a minor correction to your list of "deep tables, closures, coroutines etc.", at least Lanes has no issues with deep tables. Maybe you meant largetables (takes more time to copy back-forth) or recursive tables (notimplemented, to favor speed). Anyways, for closures and coroutines theargument 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 synchronized.
Still, as a general rule "separated" approach does suit better to "bigger grain" multithreading, where each Lua state is akin to OS processes.
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 / multipleprocesses 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 applications.
Indeed, it does. I happen to be working for a clustering application nowadays, though not with Lua.
-asko
-- Javier