libc_r is deprecated

[Robert Watson]

On Wed, 26 Oct 2005, David Xu wrote:

> What is raw performance? are you comparing it with RELENG-4, if you only 
> need a single thread, why should we start SMP project ? I am interesting 
> to see libthr is worse than libc_r in real world application, give us 
> example. I have an example, run Dave's crew example from his book, 
> libc_r just falls on its face. 
> http://people.freebsd.org/~davidxu/ptest.tgz also, Robert can get better 
> result if he does not use libc_r but use a state machine but not thread 
> to serve http request like an example in ACE.

We both know that many things can be made faster by not using threading, 
but apparently that isn't deterrence to prevent people from using threads 
when in fact it hurts performance :-).  Our goals are presumably to:

- Provide improved programming tools and models so that people can write
   better/faster code.  For example, adding KQueue, etc.

- Make the commonly used programming tools and models as fast as we can.
   Just because people use threads where it doesn't always make sense
   doesn't mean we shouldn't try to make their applications faster.
   Threads are widely used not just because they offer parallelism, but
   also because they offer a programming model that is appealing.

I'll try to set up and run Apache2 with various configurations as a 
substitute for the performance measurement httpd I have in 
src/tools/tools/netrate, and see how its mpms interact with our threading 
implementations.

My increasing suspicion is that the performance issue for threads is heavy 
access to the file descriptor related locks, resulting in significant 
contention.  I need to look at traces and profiling some more to decide 
which are the biggest problems, and whether there are useful ways to 
improve them that help.  In the libthr vs. libpthread measurements, it 
could well be that libpthread reduces kernel lock contention by allowing a 
thread to compete less with itself for locks: i.e., it introduces 
additional kernel threads only when blocked on a real sleep, not a mutex 
wait, whereas with libthr, threads will yield to each other on a CPU as 
they sleep on mutexes, resulting in more mutex contention.  This is just a 
conjecture, however.

Robert N M Watson