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>