You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nd...@apache.org> on 2008/03/29 17:43:44 UTC
[drlvm] thread local storage in open/hythread.h
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?
-Nathan
Re: [drlvm] thread local storage in open/hythread.h
Posted by Nathan Beyer <nb...@gmail.com>.
2008/3/31 Pavel Rebriy <pa...@gmail.com>:
> 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 <nb...@gmail.com> wrote:
> >
> > On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> > <gs...@apache.org> 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
>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x418 day of Apache Harmony Francis ANDRE wrote:
> zthread is a high level C++ thread abstraction package that provides almost
> the basic multi threading primitives like Semaphore, RWLock, RecursiveRWLock,
> Barrier, Condition, ThreadLocal support, etc... as well as high level
> primitive like Worker,
> ConcurrentQueues and so on...(similar to the concurrent package from Doug Lea)
>
> IMHO, it is an high level, abstract, mostly complete and portable
> threading package in C++...
GPL
> Francis
>
> Nathan Beyer a écrit :
> > On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <fr...@easynet.fr> wrote:
> >> >> 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.
> >>
> >> What would you think about using the zthread package as general rule and using
> >> optimal hand coded part for optimization??
> >> http://zthread.sourceforge.net/
> >>
> >> Francis
> > I'm not familiar with that project, so I can't really comment. What
> > would be the advantages of using it?
> > -Nathan
> >
> >> Pavel Rebriy a écrit :
> >>
> >>
> >>> Nathan,
> >> >
> >> > TLS access is a performance critical function, that why unified (single,
> >> > clean) approach could have 20-30% of performance degradation on some
> >> > benchmarks.
> >> >
> >> > On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
> >> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> >> >> <gs...@apache.org> 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
> >> >>>
> >> >
> >> >
> >> >
> >>
>
>
--
Egor Pasko
Re: [drlvm] thread local storage in open/hythread.h
Posted by Xiao-Feng Li <xi...@gmail.com>.
Hmm, I am not sure if Harmony really needs a separate threading
package. It basically needs only the native threads. And I guess that
to clean up the #defines should be much easier than to introducing a
new thread package.
Thanks,
xiaofeng
On Mon, Mar 31, 2008 at 11:01 PM, Francis ANDRE
<fr...@easynet.fr> wrote:
> zthread is a high level C++ thread abstraction package that provides almost
> the basic multi threading primitives like Semaphore, RWLock, RecursiveRWLock,
> Barrier, Condition, ThreadLocal support, etc... as well as high level primitive
> like Worker,
> ConcurrentQueues and so on...(similar to the concurrent package from Doug Lea)
>
> IMHO, it is an high level, abstract, mostly complete and portable threading
>
> package in C++...
>
> Francis
>
> Nathan Beyer a écrit :
>
>
> > On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <fr...@easynet.fr> wrote:
> >> >> 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.
> >>
> >> What would you think about using the zthread package as general rule and using
> >> optimal hand coded part for optimization??
> >> http://zthread.sourceforge.net/
> >>
> >> Francis
> >
> > I'm not familiar with that project, so I can't really comment. What
> > would be the advantages of using it?
> >
> > -Nathan
> >
> >> Pavel Rebriy a écrit :
> >>
> >>
> >>> Nathan,
> >> >
> >> > TLS access is a performance critical function, that why unified (single,
> >> > clean) approach could have 20-30% of performance degradation on some
> >> > benchmarks.
> >> >
> >> > On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
> >> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> >> >> <gs...@apache.org> 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
> >> >>>
> >> >
> >> >
> >> >
> >>
>
>
--
http://xiao-feng.blogspot.com
Re: [drlvm] thread local storage in open/hythread.h
Posted by Francis ANDRE <fr...@easynet.fr>.
zthread is a high level C++ thread abstraction package that provides almost
the basic multi threading primitives like Semaphore, RWLock, RecursiveRWLock,
Barrier, Condition, ThreadLocal support, etc... as well as high level primitive
like Worker,
ConcurrentQueues and so on...(similar to the concurrent package from Doug Lea)
IMHO, it is an high level, abstract, mostly complete and portable threading
package in C++...
Francis
Nathan Beyer a écrit :
> On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <fr...@easynet.fr> wrote:
>> >> 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.
>>
>> What would you think about using the zthread package as general rule and using
>> optimal hand coded part for optimization??
>> http://zthread.sourceforge.net/
>>
>> Francis
>
> I'm not familiar with that project, so I can't really comment. What
> would be the advantages of using it?
>
> -Nathan
>
>> Pavel Rebriy a écrit :
>>
>>
>>> Nathan,
>> >
>> > TLS access is a performance critical function, that why unified (single,
>> > clean) approach could have 20-30% of performance degradation on some
>> > benchmarks.
>> >
>> > On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
>> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
>> >> <gs...@apache.org> 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
>> >>>
>> >
>> >
>> >
>>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Francis ANDRE <fr...@easynet.fr>.
zthread is a high level C++ thread abstraction package that provides allmost
basic multi threading primitives like Semaphore, RWLock, RecursiveRWLock,
Barrier, Condition, TLS, etc... as well as high level primitive like Worker,
ConcurrentQueues and so on...(mostly like the concurrent package from Doug Lea)
it is a accurate, abstract and mostly complete threading package in C++...
Francis
Nathan Beyer a écrit :
> On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <fr...@easynet.fr> wrote:
>> >> 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.
>>
>> What would you think about using the zthread package as general rule and using
>> optimal hand coded part for optimization??
>> http://zthread.sourceforge.net/
>>
>> Francis
>
> I'm not familiar with that project, so I can't really comment. What
> would be the advantages of using it?
>
> -Nathan
>
>> Pavel Rebriy a écrit :
>>
>>
>>> Nathan,
>> >
>> > TLS access is a performance critical function, that why unified (single,
>> > clean) approach could have 20-30% of performance degradation on some
>> > benchmarks.
>> >
>> > On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
>> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
>> >> <gs...@apache.org> 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
>> >>>
>> >
>> >
>> >
>>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Nathan Beyer <nb...@gmail.com>.
On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <fr...@easynet.fr> wrote:
> >> 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.
>
> What would you think about using the zthread package as general rule and using
> optimal hand coded part for optimization??
> http://zthread.sourceforge.net/
>
> Francis
I'm not familiar with that project, so I can't really comment. What
would be the advantages of using it?
-Nathan
>
> Pavel Rebriy a écrit :
>
>
> > Nathan,
> >
> > TLS access is a performance critical function, that why unified (single,
> > clean) approach could have 20-30% of performance degradation on some
> > benchmarks.
> >
> > On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> >> <gs...@apache.org> 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
> >>>
> >
> >
> >
>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Francis ANDRE <fr...@easynet.fr>.
>> 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.
What would you think about using the zthread package as general rule and using
optimal hand coded part for optimization??
http://zthread.sourceforge.net/
Francis
Pavel Rebriy a écrit :
> Nathan,
>
> TLS access is a performance critical function, that why unified (single,
> clean) approach could have 20-30% of performance degradation on some
> benchmarks.
>
> On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
>> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
>> <gs...@apache.org> 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
>>>
>
>
>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Pavel Rebriy <pa...@gmail.com>.
Nathan,
TLS access is a performance critical function, that why unified (single,
clean) approach could have 20-30% of performance degradation on some
benchmarks.
On 31/03/2008, Nathan Beyer <nb...@gmail.com> wrote:
>
> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> <gs...@apache.org> 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
Re: [drlvm] thread local storage in open/hythread.h
Posted by Nathan Beyer <nb...@gmail.com>.
On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
<gs...@apache.org> 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
>
Re: [drlvm] thread local storage in open/hythread.h
Posted by Gregory Shimansky <gs...@apache.org>.
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.
--
Gregory