On 10/07/13 11:00, Cedric BAIL wrote: > On Wed, Jul 10, 2013 at 6:02 PM, Jérémy Zurcher <jer...@asynk.ch> wrote: >> On Wednesday 10 July 2013 16:41, Cedric BAIL wrote : >>> On Tue, Jul 9, 2013 at 11:08 PM, Jérémy Zurcher <jer...@asynk.ch> wrote: >>>> 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) >>> >>> I think that in your design eo2_func_get need to return the klass >>> somehow or it won't work. >> >> that's why i replaced it with eo2_call_resolve > > Yeah, saw that later on. > >>>> and a stupid benchmark >>> >>> Ok, I pushed my own benchmark and fixed Eo.h compilation with C++. The >> can't compile anymore, gcc and clang yels >> ./src/lib/eo/Eo.h:619:47: error: expected expression before ‘=’ token >> __##Name##_func func = (__##Name##_func) = call.func; \ >> can you fix please > > Oh ! Stupid merge issue. Fixed now. > >>> benchmark is half done has the event can't be tested as those function >>> are eo_do for the moment. Never the less, eo_do2 does create an around >>> 25% slow down in that benchmark. I have yet to understand why and what >>> is going on. I tried to play with pure and const __attribute__, but to >>> no change. Please check what is going on (Also with latest change, I >>> don't think the compiler can optimize the request to >>> _eo_data_scope_get anymore). > >> I think so, maybe we should go back to eo2_func_get && eo2_data_scope_get, >> (and return klass somehow) instead of eo2_call_resolve > > I am thinking that having a function that return the klass would be > better and then get the func and data from it. All this function could > be marked with __attribute__((const)) I guess and lead to further > automatic elimination of duplicated call. > >>> Signal/Benchmark: eo call: OK >>> Benchmark: callback loop: 18.260155ns per round: OK >>> Signal/Benchmark: eo2 call: OK >>> Benchmark: callback loop: 23.235780ns per round: OK >> bad !! > > Apparently the main issue come from the call to eo_unref. Using > _eo_unref directly would give an almost 10% speed increase. Same goes > for eo2_do_start that has a potential for 7% increase if we can call > _eo_ref directly. But the biggest benefit would be to reduce the cost > of calling eo2_call_resolve_internal. Having a const function there > would definitively help the compiler to call those function a limited > amount of time. > > Funny enough, the time spend in __inc is 2% of the all benchmark with > eo2 and 2.30% with eo, so it doesn't require a big leap to do.
By direct you mean the same without the id/magic check? If so, that can easily be done and is planned. Won't be inlined though, which is an annoyance. -- 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
