Re: performance....

On Mon, Apr 15, 2002 at 09:52:03AM -0400, Bill Abt wrote:

[snip]

> I'm a little concerned
> about pthread_self since we use almost the same technique as LinuxThreads
> and I'll have a look. 

It doesn't really appear that way to me, but I confess I haven't
studied it carefully, so maybe I don't understand whats happening.

My impression is that Linuxthreads uses at least 3 different methods
for doing thread_self.  
   a) stores a pointer to the current thread in an unused segment
      register, if supported by the arch and the cpu.  If thats not
      available, then,
   b) uses evenly spaced and aligned stacks, which allows simple
      manipulation of the current stack to obtain the thread
      pointer, which is at the end of the stack.  Or, if the user
      as specified using his own stack allocations (which are
      not spaced and aligned), then,
   c) they do a linear scan of all the threads to locate the current
      thread, based on the current stack.

a) and b) are quite efficient.  c) is not efficient at all if there
are very many threads.  a) or b) are the normal defaults, and the
user has to specifically put himself in to the state of using c).

It appears to me that NGPT uses a variant of c), but only has to
scan the "native threads", which is presumably more efficient
that scanning *all* the threads, but still is not as simple and
efficient as a) or b).  Also, the NGPT pthread_self function involves
several layers of function calls, which adds a bit of overhead
too.

I would guess that this accounts for the differences in pthread_self
performance that people are seeing, but I haven't specifically tested
this myself.

On the subject of pthread_mutex_lock performance, it appears to me
that each attempt to lock a mutex in NGPT involves a linear search
of a list of up to 100 statically allocated mutexes.  Even if the
list of static mutexes is short, it would seem that this is quite
inefficient compared to Linuxthreads, or say, FreeBSD threads.  If
the lock is contested and the thread blocks, you might not notice the
added overhead.  But, in the case of an uncontested mutex lock, I'd
guess the difference would be quite noticeable.  Since pthread_cont_wait
involves a call to pthread_mutex_lock, the cond_wait performance 
would also be adversly affected.

Again, I haven't done any testing.  I'm just scanning the code 
(and possibly incorrectly at that).

-- 
Richard Seaman, Jr.        email:    [email protected]
5182 N. Maple Lane         phone:    262-367-5450
Nashotah WI 53058            fax:    262-367-5852