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. -- ------------- 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
