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 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. 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).
On Wed, Oct 26, 2011 at 8:29 AM, Cedric BAIL <cedric.b...@free.fr> wrote: > 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 > ------------------------------------------------------------------------------ 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
