On Tuesday 09 July 2013 13:40, Tom Hacohen wrote : > On 09/07/13 03:55, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen <tom.haco...@samsung.com> > > said: > > > >> Hey guys, > >> > >> The hero Jeremy Zurcher has been playing around and looking for ways to > >> improve Eo and address all the issues that have been raised by everyone. > >> We revisited some old ideas, tried some new ideas and changed our > >> compromises and preferences to better suit our needs (followed by the > >> extensive trial period). We think we made things better and we'd like to > >> hear your thoughts and suggestions. > >> > >> The code resides in devs/tasn/eo2. The differences are not major > >> usage-wise (i.e eo_do), but are major internally and class-creation-wise. > >> There's an example of the usage of the new API in the eo2test directory. > >> The existing code-base hasn't been changed to use the new API, so > >> there's not a lot to review. > >> Eo2 is not complete, we'd like to hear your thoughts before finishing > >> things. > >> > >> Major changes: > >> 1. No more va_args, good ol' normal functions instead. > > > > good and bad. good as varags is a bit unwieldy. bad as in more symbols and > > either more function calls inlined in app code OR more code in general > > inlined > > (with macros or inline funcs). end result? unknown until we try. also > > another > > bad... work to port the existing eo code over. without full details, amount > > of > > work unknown. (missing git tree). > > I think it's better to inline those in the app, yeah. I don't think a > function call + an if are much to worry about. > Amount of work is known: everything needs to be done. This is a draft, > not even a complete solution. This example doesn't handle eo_do_super > and the eo_data_scope_get.
I pushed some stuff in devs/tasn/eo2, nothing inlined (real method call performed), basic eo_data_scope_get support (+ real eo fct call) and a stupid benchmark Intel(R) Core(TM)2 Duo CPU E7500@2.93GHz 64 bits CFLAGS="-O2" ./make.sh gcc: EO : time 71 [ms] EO2: time 67 [ms] clang: EO : time 98 [ms] EO2: time 54 [ms] > > > > >> 2. Functions are resolved in eo and then called directly, creating a > >> "flatter" backtrace. > >> 3. We can have return values (to some extent). > >> 4. Less boiler-plate. > >> 5. Looks like we'll be able to get rid of some code thanks to this change. > >> 6. Possibly (probably) faster on platforms that pass parameters in > >> registers. > > > > hmm unlikely as now its: > > 1 func to begin > > 2 func to end > > 2 func call s per method > > Yeah, but OTOH parameters will be passed in registers instead of the > stack. I guess you are right though. > > > > as opposed to 1 func for begin+end, 1 func per method. i done see eo2 in > > git, > > so i can only comment on the point here, not the code. (if the lookup is a > > macro to get the func ptr, then call it directly, then sure, 2 fn call per > > method). another downside to it all being macros.. code size goes up, this > > instruction cache coherency goes down... :/ > > It's not all macros, code is there. :) > > >> 7. Easier to do breakpoint on a specific eo_do call, instead of an > >> implementation. > >> > >> What we'd still like to achieve: > >> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be > >> best to find a way to use the function pointers (for example) as the > >> IDs, but the problem is, that because function pointers are more > >> "unknown" we can do less optimisations on them which we'd like to avoid. > >> 2. Reduce more boiler-plate. > >> > >> Haven't been implemented yet: eo_do_super (among many other things). > >> > >> Additional comments: > >> EO_FUNC - this one creates a function that resolves and returns the > >> appropriate function. The functions created using this macro should be > >> used instead of the current eo macros. This one can potentially be > >> improved. > >> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and > >> possibly other stuff in the future). > >> > >> Looking forward to hearing what you have to say. > > > > no tree. no git. :) > > As mentioned by others in this thread, it's a branch, not a different > repo. Why would I put it in a different repo?! :) > > -- > Tom. > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- Hell'O from Yverdoom Jérémy (jeyzu) ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
