2008/3/31 Pavel Rebriy <[EMAIL PROTECTED]>:
> Nathan,
>
> TLS access is a performance critical function, that why unified (single,
> clean) approach could have 20-30% of performance degradation on some
> benchmarks.
>
Do you have an evidence to back up that assertion? 20-30% is quite a difference.
-Nathan
>
>
> On 31/03/2008, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > On 29 марта 2008 Nathan Beyer wrote:
> > > > In open/hythread.h there is the following bit of code.
> > > >
> > > > #ifdef PLATFORM_POSIX
> > > > extern __thread hythread_t tm_self_tls;
> > > > #else
> > > > extern __declspec(thread) hythread_t tm_self_tls;
> > > > #endif //PLATFORM_POSIX
> > > >
> > > >
> > > > hy_inline hythread_t VMCALL hythread_self() {
> > > > return tm_self_tls;
> > > > }
> > > >
> > > > From what I know at the moment, the use of '__thread' isn't a POSIX
> > > > standard, but rather a gcc extension and '__declspec(thread)' is a
> > > > MSVC thing, so the check isn't quite correct. Neither of these works
> > > > on MacOS X and from what I've been able to gather, it shouldn't work
> > > > on FreeBSD, but I can't confirm that. In any case, I was looking at
> > > > implementing this for MacOSX and FreeBSD using pthread_key_t. It
> > seems
> > > > like that could be used for other (all?) platforms as well. Any
> > > > thoughts on that?
> > >
> > > AFAIK there are plenty of different implementation for getting TLS in
> > DRLVM's
> > > implementation of hythread. There are fast ways like those you've
> > mentioned,
> > > slow ways using APR and pthread and very fast ways using inline
> > assembly.
> > >
> > > All of them are quite messed up right now and need some cleaning. The
> > mess is
> > > with different defines that rule the whole stuff - it is not always
> > clear
> > > which define set is used for a particular implementation on a given
> > platform.
> >
> >
> > I would agree that the defines are a bit of a mess or at least seem
> > like it at times.
> >
> > Do you have any suggestions or preferences about a particular TLS
> > approach? I'm all for fast, but I tend to lean towards a consistent
> > (single) clean approach, even it it's not the fastest approach.
> >
> > >
> > > --
> > > Gregory
> > >
> >
>
>
>
> --
> Best regards,
> Pavel Rebriy
>
