On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel <onef...@gmail.com> said:
> 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. the worker system, message passing etc. would be useful for bob. we dont need the lsl -> lua bit. :) but we may definitely generate lua src text FROM multiple sections/snippets of lua that make up an object... :) > 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-) yes. what is missing there i guess is the implement() method that has to collect results and run in the mainloop. for very simple calculations/work running it in a threads and messaging will be much more overhead than just running it there and then.. so that's going to possibly need some heuaristic to guess where it should be run etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
