This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gomp slowness
- From: Ian Lance Taylor <iant at google dot com>
- To: skaller <skaller at users dot sourceforge dot net>
- Cc: Gary Funck <gary at intrepid dot com>, Joe Buck <Joe dot Buck at synopsys dot COM>, gcc at gcc dot gnu dot org
- Date: 02 Nov 2007 07:39:33 -0700
- Subject: Re: gomp slowness
- References: <1192640402.10798.11.camel@rosella.wigram> <20071017170948.GA25883@synopsys.com> <1192671772.25512.36.camel@rosella.wigram> <20071102040200.GA25827@intrepid.com> <1193993311.5893.33.camel@rosella.wigram>
skaller <skaller@users.sourceforge.net> writes:
> A really cool (non-Posix) implementation would put TLS globals
> on the stack base .. but this does require at least one extra
> machine register in languages like C which don't provide
> a static display (pointer to parent function). For languages
> that do, such as Modula and most FPLs, the display pointer
> has to be provided anyhow, so the TLS globals come at
> no extra cost.
In a C executable, TLS requires one extra machine register. TLS
variables are accessed via offsets from that register. So what's the
significant difference between that and your proposal?
> There are bound to be performance issues if you have to query
> any kind of global data base shared between threads to obtain
> data local to the thread. The only exception to this is the data
> held in the 'task state', which is typically just the machine
> registers and in particular the stack.
TLS does not require querying a global data base to get thread local
data.
The only way I can interpret your comments is that you are assuming
that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared
library). But stack based thread local storage won't work for
dlopen'ed shared libraries at all.
I think you need to look at the TLS access code before deciding that
it has bad performance. Make sure to look at the code in the
executable after the linker has optimized it.
Ian