Hello,
On Thu, Jul 11, 2013 at 7:41 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
> On Thursday 11 July 2013 19:11, Cedric BAIL wrote :
>> On Thu, Jul 11, 2013 at 5:36 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
>> > On Thursday 11 July 2013 03:28, Cedric BAIL wrote :
>> >> On Wed, Jul 10, 2013 at 4:06 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
>> >> > still not fully functional,
>> >> >
>> >> > here is the concept:
>> >> >
>> >> > - enhance const Eo_Op_Description *descs; in Eo_Class_Description
>> >> > into:
>> >> >
>> >> > typedef struct _Eo_Op_Description
>> >> > {
>> >> > void *func; /**< The static function to call for the
>> >> > op. */
>> >> > void *api_func; /**< The EAPI function offering this op.
>> >> > */
>> >> > Eo_Op op; /**< The op. */
>> >> > Eo_Op_Type op_type; /**< The type of the Op. */
>> >> > const char *doc; /**< Explanation about the Op. */
>> >> > } Eo_Op_Description;
>> >>
>> >> Yeah, good idea to remove that second array.
>> >>
>> >> > - remove the following from class declaration and definition
>> >> > _Eo_Op_Func_Description []
>> >> > BASE_ID = 0;
>> >> > enum { OP_ID, ID_LAST };
>> >> > etc…
>> >> >
>> >> > - but add
>> >> > static Eo_Class_Id class_id;
>> >> >
>> >> > - on class elaboration:
>> >> > init class_id as BASE_ID was
>> >> > sort Eo_Op_Description by api_func, and set op (using base_op_id)
>> >> >
>> >> > - now EO_FUNC_BODY can do:
>> >> > static volatile Eo_Op op = NOOP;
>> >> > if ( op == NOOP ) op = eo2_get_op_id(class_id, Name);
>> >> > -> search (Name==api_func) in class_id(_Eo_Op_Description)
>> >> >
>> >> > then resolve the op given the calling object as usual
>> >> >
>> >> > - overriding does not use EO_FUNC_BODY()
>> >> > but overrides *func in _Eo_Op_Description -> usual _dich stuff
>> >> >
>> >> > so that's a little overhead on first call to resolve the OP
>> >> >
>> >> > Am I on the right thack ??
>> >>
>> >> Sounds like a good direction to follow. I would still like to expose
>> >> the klass where the op is found in the object instead of directly
>> >> doing eo2_call_resolve. This way we could add a hook before and after
>> >> the function call to do tracing. It will also make it possible for all
>> >> those functions to be pure const functions, this will help the
>> >> compiler greatly I believe. Note a pure const function doesn't modify
>> >> any of its parameter and the result is the same if the same data is
>> >> given to them. Think strlen.
>>
>> > function pointer and associated class are both int the Dich_Chain (what
>> > does Dich Chain mean ??), for sure we don't want to do the lookup twice,
>> > (but if the pure fct is optimized, why not?)
>>
>> The problem is with eo2_call_resolve as it does modify the content of
>> call and that make it not a pure function anymore in my understanding.
> that's exactly what the theory says.
>> That's why I want to split it, so that the compiler can merge and
>> remove calls to eo2_call_resolve at the end. Well, in fact, I do hope
>> that if the compiler is smart enough it will be able to move that
>> evaluation outside of the loop and remove it from the hot path
>> completely. That should be the case in the end for all call to eo2_do
>> and give it an unfair advantage over eo_do.
>>
>> > maybe we should expose op_type_funcs, but _Eo_Class is not public,
>> > sometimes anoying that strict separation, I'll figure something out now.
>> >
>> > I'm _aware_ of pure fcts, what do you think about
>> > static Eo_Op op = EO_NOOP;
>> > if ( op == EO_NOOP ) op = eo2_get_op_id(OpDescs, (void*)Name);
>> > vs
>> > op = eo2_get_op_id(OpDescs, (void*)Name);
>> >
>> > I wonder, I'll give a try all pure now!
>>
>> Let's see that :-)
> sadly it doesn't look to be smart enough or I missed something, see (out vs
> out-pure).
I spend this morning some time looking at the assembly result of that
idea to understand why the compiler can't move things around. I think
I now understand why, pretty easy to understand in fact. Even with all
those const/pure function, there is still 3 functions that are not :
eo2_do_start, eo2_do_end and __inc. All of them act like a barrier to
any optimization to reduce the number of call to any of the const/pure
function. I have been scratching my head on how to solve that, but I
seriously don't think it is possible now.
Sorry I wasted your time with this idea.
> time to eat now!!
That, is always a good idea !
--
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
