This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 2 Jun 2013 17:53:58 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <20130529055518 dot GA23030 at domone dot kolej dot mff dot cuni dot cz> <ormwraq3rx dot fsf at livre dot home> <20130601031151 dot GK20323 at brightrain dot aerifal dot cx> <ora9n9i3jc dot fsf at livre dot home> <20130602154150 dot GN20323 at brightrain dot aerifal dot cx> <ortxlgh2an dot fsf at livre dot home>
On Sun, Jun 02, 2013 at 02:04:32PM -0300, Alexandre Oliva wrote:
> On Jun 2, 2013, Rich Felker <dalias@aerifal.cx> wrote:
>
> > Do you have any performance figures to justify this?
>
> Sure, in the paper.
I read the text version which just had some hand-waving. I'll check
the PDF.
> It also explains the optimization you seem to have
> missed, that enables the dynamic loader to turn dynamic TLS into
> something very close to initial exec when the TLS segment of a dlopened
> library fits in the static TLS segment. I say you seem to have missed
> that because you can't possibly be saying that all the work done by
> __tls_get_addr() is as costly as simply returning the value passed in in
Actually that is what I'm saying. The hot path of __tls_get_addr
should be just a couple dereferences and branches which are always
predicted correctly. If it's slower than that in glibc, that's a bug
in glibc.
Rich