On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui <[email protected]> wrote: > I agree with vincent, and I think that there shouldn't be a "define it > before including eina.h" implicit rule.. while it's not so bad, and it would > work, it's not the right way to do it. > these functions shouldn't be inlined I think, they should be a define, and
Using define instead of inline has a lot issue. First it doesn't let the compiler when it's better or not to inline, it will always inline. Second it doesn't do any type checking so you can break stuff much more easily. And generally inline is much more easy to read than define. > for the posix functions, they are way too big to be inline, they would > dramatically increase the generated code, especially if you lock/unlock > everywhere. I actually don't understand what point your are trying to make here. > As for performance, give us hard numbers! I don't think it would > affect performance for such function calls. So in my opinion, make them > defines, and have the posix versions as actual functions that the defines > call (so for non posix with smaller functions, you don't need an actual > call). What does matter is call to small function, because the overhead of setting up the stack, saving register, jumping to the actual function to call and then coming by restoring register and the stack does introduce a cost. Something you will not see on your high end laptop, but on embedded device. And the inline function are function that are typically in the hot path of our stack, so function call really do matter. And moving to #define would not solve the issue Vincent is pointing as far as I understand it. > On Wed, Oct 26, 2011 at 8:29 AM, Cedric BAIL <[email protected]> wrote: > >> On Wed, Oct 26, 2011 at 1:48 PM, Vincent Torri <[email protected]> >> wrote: >> > On Wed, 26 Oct 2011, Cedric BAIL wrote: >> >> On Wed, Oct 26, 2011 at 11:13 AM, Vincent Torri <[email protected]> >> wrote: >> >>> On Wed, 26 Oct 2011, Cedric BAIL wrote: >> >>>> On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri <[email protected]> >> wrote: >> >>>>> Eina includes eina_inline_lock_posix.h on something else than >> Windows, >> >>>>> hence pthread.h. _GNU_SOURCE is not defined. >> >>>>> >> >>>>> Suppose now that a user of Eina does this: >> >>>>> >> >>>>> #include <Eina.h> >> >>>>> #include <pthread.h> >> >>>>> >> >>>>> The user will not have the possibility to features available with >> >>>>> _GNU_SOURCE (like CPU_SET for example. I have that problem with >> Enesim), >> >>>>> except by defining it just before including Eina.h. Which is not the >> best >> >>>>> solution, I think. >> >>>>> >> >>>>> The problem, here, is that lock stuff is only inlined functions. The >> >>>>> problem will be solved if they are in a source file. Maybe at the >> >>>>> beginning, having these functions inlined was interesting because >> they >> >>>>> were short. I'm not sure that keeping them inlined is really useful, >> now. >> >>>> >> >>>> As from a performance point of view, it really matter to have them >> >>>> inlined or not. Function call does cost. >> >>> >> >>> I know that, but i would like to have numbers, here, to verify it's >> worth >> >>> having them inlined. Note that I'm talking about the posix part, not >> the >> >>> 'void' or windows part. >> >>> >> >>> If your argument is : "no numbers are needed, it's faster", then why >> not >> >>> defining all the functions inlined ? >> >> >> >> I don't have access at the moment on machine where that does matter. >> >> But to put stuff into perspective, Eina_Magic check could cost around >> >> 10% of your time and it's just a function call with an if inside, much >> >> simpler that taking a lock. So I don't have number, but it's just way >> >> better to avoid the 10s instructions that are needed to do a function >> >> call. >> >> And why not inlining everything, >> > >> > that was a sarcasm... >> > >> >> that why we use static inline >> >> instead of a macro, gcc can choose to inline the function or not >> >> depending on all the cost implied by the function call. And we don't >> >> put all function inlined, because that would just increase the binary >> >> size and invalidate cache to much. So it is only a solution for very >> >> small function called very often. >> > >> > Look at the function eina_lock_take() in the posix file : 67 lines (with >> > the defines). Do you call that a small function ? And I perfectly >> remember >> > you telling to use **static** inline to force gcc to inline the function. >> > Now you're saying that gcc will sometimes inline it, sometimes not ? >> > You're contradicting yourself. >> >> No I am not, the static is here to prevent a clash between symbol. >> That's all it is saying and it will never force a function to be >> inlined. It just make it possible to the compiler to do so if it makes >> sense. I told to put static, because inline doesn't tell anything >> about the symbol visibility and that would be an issue. >> -- >> Cedric BAIL >> >> >> ------------------------------------------------------------------------------ >> The demand for IT networking professionals continues to grow, and the >> demand for specialized networking skills is growing even more rapidly. >> Take a complimentary Learning@Cisco Self-Assessment and learn >> about Cisco certifications, training, and career opportunities. >> http://p.sf.net/sfu/cisco-dev2dev >> _______________________________________________ >> enlightenment-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Cedric BAIL ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
