Re: libc_r is deprecated
From: Peter Wemm (peter_at_wemm.org)
Date: 10/26/05
- Previous message: Peter Wemm: "Re: libc_r is deprecated"
- In reply to: Robert Watson: "Re: libc_r is deprecated"
- Next in thread: David Xu: "Re: libc_r is deprecated"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: freebsd-arch@freebsd.org Date: Wed, 26 Oct 2005 14:10:22 -0700
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 _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Peter Wemm: "Re: libc_r is deprecated"
- In reply to: Robert Watson: "Re: libc_r is deprecated"
- Next in thread: David Xu: "Re: libc_r is deprecated"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
