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