Re: Consensus: Tuning runtime behaviour with environment variables.

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  1, 2013, Rich Felker <dalias@aerifal.cx> wrote:

> On Fri, May 31, 2013 at 05:43:14PM -0300, Alexandre Oliva wrote:
>> On May 29, 2013, OndÅej BÃlka <neleai@seznam.cz> wrote:
>> 
>> > When performance is concerned I am for auto tuning without env variables
>> > unless performance depends on external factors.
>> 
>> Here's one case where I've long entertained adding an env var to
>> configure libc's internal behavior: the thread local storage
>> optimizations I implemented years ago attempt to assign even the thread
>> local area of dlopened libraries to the static tls segment, so that they
>> can be accessed more efficiently.

> This does not make access more efficient.

It does when using the optimized TLS relocations I introduced.  If
there's room in the static TLS segment, the dynamic loader resolves TLS
references to code equivalent to initial exec; if there isn't, it has to
fallback to the much slower dynamic access modes, even though there are
optimized fast paths there as well, compared with the TLS ABI used by
default on x86 and x86_64.

Note that these optimizations (still) aren't the default TLS mode on
these architectures, even though it was adopted by a few other
architectures as the TLS ABI.  On x86 and x86_64 (and ARM IIRC) you have
to compile with -mtls-dialect=gnu2 (and -fPIC) to get these optimizable
relocations.

Please read http://people.redhat.com/aoliva/writeups/TLS/RFC-TLSDESC-x86.txt
and/or http://people.redhat.com/aoliva/writeups/TLS/paper-gcc2006.pdf
for details.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer