libc_r is deprecated

[Peter Wemm]

On Wednesday 26 October 2005 04:08 am, Robert Watson wrote:
> 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 :-). 

Here's an example. fetch http://people.freebsd.org/~peter/pp.c

peter at daintree[1:59pm]/tmp-160> ./pp_c_r -v

PING-PONG CONFIGURATION:

target (-i) = 1000000
ntables (-n) = 1
sleepms (-z) = 0
pthread_scope (-s) = process
pthread_process (-p) = private
concurrency (-c) = 0
stacksize (-S) = 0

2 threads initialised in 0ms
1 games completed in 1472ms

Summary of all thread libraries:
libc_r:     1472ms
libpthread: 1658ms
libthr:     8496ms

Note the execution times.. libc_r is the fastest, followed closely by 
libpthread, and libthr is way behind.  This is on a UP system.  On SMP 
though, the numbers are very different.  libpthread falls flat on its 
face.  libthr holds up more gracefully, but is still slower than 
libc_r.

On a 4-cpu system:
libc_r:      1498ms
libthr:     25462ms
libpthread: 28104ms

This is pure computationally intensive program.  It excercises the 
locking mutexes.  It certainly shows a worst-case for libthr and shows 
how libpthread doesn't handle SMP scheduling well either.  It is 
especially embarresing because libc_r is a single process, while libthr 
and libpthread are using two cpus concurrently.

This is a good example of why libc_r should not be removed.  We need it 
to show baseline values.

By all means, don't build it by default. But don't remove it entirely.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5