Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Oct 2005 14:10:22 -0700
From:      Peter Wemm <peter@wemm.org>
To:        freebsd-arch@freebsd.org
Cc:        Marc Olzheim <marcolz@stack.nl>, Daniel Eischen <deischen@freebsd.org>, Robert Watson <rwatson@freebsd.org>, David Xu <davidxu@freebsd.org>, arch@freebsd.org
Subject:   Re: libc_r is deprecated
Message-ID:  <200510261410.23688.peter@wemm.org>
In-Reply-To: <20051026120219.V32255@fledge.watson.org>
References:  <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <435EBD49.7090207@freebsd.org> <20051026120219.V32255@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510261410.23688.peter>