On Fri, 2 Sep 2016 09:53:25 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> On Fri, Sep 2, 2016 at 7:44 AM, Tom Hacohen <t...@osg.samsung.com> wrote: > > On 02/09/16 15:40, Cedric BAIL wrote: > >> On Sep 2, 2016 07:15, "Tom Hacohen" <t...@osg.samsung.com> wrote: > >>> Good job trying to tackle it, but this is wrong. > >>> > >>> This is not thread-safe and the Eo infrastructure should be. So > >>> essentially, this optimisation is not allowed. You could maybe do a > >>> cache per-thread, raster claims that __thread is actually quite alright > >>> nowadays with GCC, I'm not sure, but this, and the following patch > >>> should be reverted. > >>> > >>> If you have anything to say to defend this approach, please do so by > >>> Monday, otherwise I'll revert both patches then. > >> > >> Raster has already added lock around all the use of it. There is maybe one > >> missing on isa will check later today. > > > > Ah missed that. Sorry, catching up with things. > > > > Is it still an improvement, even with the lock? > > A little bit, but clearly not as much. Will land another patch for > efl_isa with spinlock, but we should try with thread local variable. > It would pay off more for two reason, first the cache will be per > thread so preserving it more efficiently and second thread local > storage is faster than spinlock. The only issue is that we need to > invalidate all thread local storage on eoid destruction and I don't > know how to do that yet. when i added the lock around eoid lookup... it went from w to 5% of cpu usage. :( thus my thoughts on "there has to be a better way". :) thus why i checked tls and __thread speeds to get an idea of how much it might win. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
