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