Re: Lua Coroutines (Thread) Performance

[HyperHacker <hyperhacker@...>]

2011/7/13 Timothée VERROUIL <dreamothee@hotmail.com>:
> Hi,
>
> I'm building a Script Engine that binding C++ to Lua.
> This part is ok and work correctly but know, I've to implement the game
> logic part and I'm not really aware about the best practices.
> So, here is what I want to do, and the twice solutions I've found.
>
> I've a C++ GameObject and I want to script it with Lua.
> So, I've to send a reference of that object to Lua (no problem here) and
> I've to Update the script each frame of the game loop.
> But, I'see 2 ways to do that, each has its advantages and inconvenients.
>
> Notice that to inject a reference, I do something like that :
>    - I affect a new name to the right metatable :
>      Metatable["tmpVar123"] = Metatable
>    - I set it to global
>    - I affect a local variable to this global
>
> 1) Whith Lua Thread
>  When the game start, for each gameObject which has a script, I create a new
> Lua Thread from C++ and initialize all of its local variables
> (as self which represents the reference of the gameObject).
> So, when I Update the script, the local variables are well initialized and
> there are no collisions with the other scripts because of the Lua Thread.
>
> 2) Without Lua Thread
> I do the same as with Lua Thread but I don't create one thread for each
> script.
> So, in order to avoid collisions between scripts, I initialize each local
> variables before Updating the script.
>
> So, I think that to choose between this 2 methods, all depends of the
> performance of the lua thread (imagine if I have something like 1000 game
> objects,
> so 1000 threads too!)
>
> Thanks,
>
> Tim
>
>
>

Well in the single Lua state approach, you can just do something like:
-Push the game object "frame" function
-Push the object itself any any arguments to the function
-Call using lua_call or lua_pcall
once for each object that needs to be updated. So there isn't really
any *need* for more than one Lua state. As long as you use a decent
naming convention, global collisions shouldn't be an issue (and
provide a way to share information between objects).

However, using more than one state has the advantage that each state
can run in its own OS thread. As computers add more CPU cores and
become more oriented to parallel processing, being able to take
advantage of all those cores is important. If you do this you can have
multiple objects updating simultaneously, which should offer a
significant speed boost if done well.

Of course, you don't need one Lua state per object either. You might
create one per CPU core, and then divide your objects into groups and
use the single-state approach on each group.


--
Sent from my toaster.