On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel <onef...@gmail.com> > said: > > > On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL <cedric.b...@free.fr> > > wrote: > > > > > Right now only a thought exercice, but you can get info there : > > > https://phab.enlightenment.org/w/bob/ . > > > > Definitely something my LuaJIT experiments will be good for. > > > > "A daemon could be in charge of generating the JIT and thus sharing > > information across processes (Does LuaJIT allow for this?)." > > this is way too premature in terms of optimizing imho. sure - having > N apps all go run their own jit on the same bit of lua is > inefficient. having it jitted once and shared is much better. but how > do we share jitted code sensibly so it can be executed in N places > safely? we would need to share jitted code inside mmaped shared > memory segs mmaped to the same absolute addresses, unless we modified > the jit engine to use base address relative code generation... ugh!. > or we run it all in the server and ipc results/input to and fro? ... > hmm ewww... > > > If that means that some EFL based C code is generating and compiling > > Lua code, in response to commands from a socket, then yes. If that > > also includes running the results in a threaded way with message > > passing, then also yes (same daemon). I have these working > > already. Designed to deal with thousands of Lua scripts running at > > once, and using LuaJIT. I've mentioned this before. > > right now thoughts are along the lines of every object type (widget? > or part in edje) is really a bunch of lua to implement it - or to > calculate it and hand off to a "go implement this state for me" > code... > > what i'd like to see is for it to be easily parallelisable into > threads. so we can calculate lots of params/parts in parallel when > possible (independent calc paths - eg of 2 child branches before > parent has to look at results of children) etc. thus why calc vs > implement should be stages.. maybe lua tables with functions > (methods) to implement calc , implement, etc. etc. - don't know. > thought exercise atm. My point is that this sort of thing is not just a thought exercise for me, I've done a lot of the work already for another project. I was always keeping Edje Lua in mind when I did it though, thinking some of the work could apply there. Naturally I used EFL for this project. B-) It's a virtual world scripting engine. Second Life / OpenSim virtual worlds are made of 256 x 256 meter sims, with hundreds or thousands of these sims in any given world. Each sim might have several thousand LSL scripts running, and in a lot of cases most of those scripts are just multiple copies of the same dozen scripts. So I've been writing a daemon that generates Lua scripts (translated from pre existing LSL scripts), then compiles and runs them with LuaJIT, using a threaded worker queue with message passing system. Getting it to run fast and use minimal resources is important for this project. I don't want thousands of these same dozen scripts soaking up memory, I want one of each. This daemon will also run in the virtual world viewer, driving Edje UIs via Edje Lua. I got a lot of the bob bits already sorted out, before I knew there was a bob. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
