On Wed, Oct 26, 2011 at 1:48 PM, Vincent Torri <vto...@univ-evry.fr> wrote: > On Wed, 26 Oct 2011, Cedric BAIL wrote: >> On Wed, Oct 26, 2011 at 11:13 AM, Vincent Torri <vto...@univ-evry.fr> wrote: >>> On Wed, 26 Oct 2011, Cedric BAIL wrote: >>>> On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri <vto...@univ-evry.fr> >>>> 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
