[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SUN TLS vs. GNU TLS (was Re: ELF TLS ABI vs L4 ABI)

From: Marcus Brinkmann
Subject: Re: SUN TLS vs. GNU TLS (was Re: ELF TLS ABI vs L4 ABI)
Date: Thu, 18 Nov 2004 19:19:04 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 18 Nov 2004 18:47:52 +0100,
Espen Skoglund <address@hidden> wrote:
> Has anyone ever done any empirical analysis of the performance
> "advantages" of SUN ELF TLS over GNU ELF TLS?  Surely something like
> this must exist in order to motive GNU TLS in the first place.

I guess Ulrich Drepper did.  The only word I have is that it was
measured and has an effect, but I don't have numbers.
>   o For GNU TLS, since the TLS is accessed through %gs one *must*
>     program all TLS accesses in assembly.  That is, one can not just
>     tell the compiler that the TLS is located on location so and so,
>     and let the compiler itself handle all the memory accesses.  This
>     means that 1) TLS related code becomes harder to manage, and 2)
>     the compiler is unable to optimize the accesses to the TLS (e.g.,
>     by cache prefetching, memory access reordering, etc.).

I am not sure about this one.  The GNU TLS has the thread pointer not
only as the base of the segment descriptor, but also at %gs:0 itself.
This means that you can load the TLS base address and use it just as
you would in SUN ELF TLS.

As ELF TLS is intended to be used via the __thread keyword, access to
it is done via the language features of the compiler, and can be
optimized at the compilers leisure.  In particular, GCC can either
load the thread pointer and use it with normal memory accesses, or do
all writes through the %gs segment register, or a mixture of both.

I have not verified that this is what actually happens, but I know
that %gs:0 is still available as the TCB address in GNU ELF TLS, and
that there is even an internal API to get the thread pointer.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]