Re: gomp slowness

[Joel Dice <dicej at mailsnare dot net>]

On Sat, 3 Nov 2007, skaller wrote:
> On Fri, 2007-11-02 at 10:46 -0400, Daniel Jacobowitz wrote:
> > On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
> > > 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.
> >
> > Actually, from context I assume he's talking about pthread_setspecific
> > and does not know about __thread.
>
> Yes, I was talking about pthread_*, i.e. posix threads.
>
> I do know about __thread though.
>
> My argument is basically: there is no need for any such
> feature in a well written program. Each thread already has
> its own local stack. Global variables should not be used
> in the first place (except for signals etc where
> there is no choice).
>
> So any (application) program needing TLS (other than the stack)
> is automatically badly designed.  I've been writing code for
> three decades without using any global variables, ever since
> I learned about re-entrancy.

While I agree that global and thread-local variables are to be avoided in 
general, I wonder how you would treat the following case:

Function A needs to supply some data to function Z, but only via a call 
stack containing functions B through Y.  Must B through Y all take that 
data as a parameter and pass it as an argument?  Would it not be more 
efficient to store it in a register on a register-rich machine instead of 
copying in on every call?

Even putting runtime efficiency aside, the code in the intermediate 
functions is made arguably less readable by each bit of context it has to 
forward along but never use itself.  OTOH, using thread-locals introduces 
"action at a distance", which never helps readability.