Re: LUA with simulation

[David Given <dg@...>]

On 29/11/12 22:25, Philipp Kraus wrote:
[...]
> std::vector<state> l_state;
> create_init_states( l_states, number_of_individuals );
> for(std::size_t t=0; t < simulation_time; ++i {
> 	for (std::size_t i=0; i < l_state.size; ++i)
> 		l_state[i] = run_lua_script( l_state[i], environment, t );
> }

I assume 'state' here is referring to a simulation state, and not to a
Lua state (lua_State*)?

I don't quite follow your description of your architecture.

If you really can't have any persistent data from each work unit to the
next on a single thread, then yes, you are going to have to load the
script each time. It is possible to speed this up, however.

Look for the luac utility, which you get with your Lua distribution.
This will allow you to precompile a Lua script into a bytecode file,
which can then be loaded as if it were an ordinary script. Loading
bytecode typically takes half to a third of the time of loading source.

Note that bytecode files are not portable across architectures --- you
can't use bytecode that was compiled on ARM on MIPS, for example. So you
need to compile it on the same kind of machine as one of your cluster nodes.

Also, while loading bytecode is faster, the Lua compiler is blisteringly
fast anyway --- tens of megabytes of source a second. So using bytecode
may not necessarily make an observable difference to performance. How
long does a single work unit take? i.e., how long one of your nodes
takes to perform one simulation step? If it's more than five hundred
milliseconds or so, then script load time is not going to be a
significant part of the total time taken.

[...]
> I would use MPI & threading, so on a MPI core I can have n threads, on each
> thread I would create a Lua state. 
> My call "run_lua_script" can be different of the l_state[i], so there can be 
> different Lua scripts and on the state a special script is run, so if I don't order my states
> I can have got on each thread p Lua states, for each script one Lua state.

However, this sounds like you have multiple persistent Lua states per
thread? You don't have to destroy the Lua state and recreate it every
time you execute a work unit?

If this is the case, then you can just load all your scripts into the
Lua state and then run_lua_script() just runs the appropriate one for
the work unit. That way, you only have to initialise the Lua states
once, when the thread is spawned.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Of course, on a sufficiently small planet, 40 km/hr is, in fact,
│ sufficient to punt the elastic spherical cow into low orbit." ---
│ Brooks Moses on r.a.sf.c

Attachment: signature.asc
Description: OpenPGP digital signature