From owner-freebsd-arch@FreeBSD.ORG Wed Oct 26 21:10:24 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB8B116A420; Wed, 26 Oct 2005 21:10:24 +0000 (GMT) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C41F43D48; Wed, 26 Oct 2005 21:10:24 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 425B019773; Wed, 26 Oct 2005 14:10:24 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Wed, 26 Oct 2005 14:10:22 -0700 User-Agent: KMail/1.8.2 References: <435EBD49.7090207@freebsd.org> <20051026120219.V32255@fledge.watson.org> In-Reply-To: <20051026120219.V32255@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261410.23688.peter@wemm.org> Cc: Marc Olzheim , Daniel Eischen , Robert Watson , David Xu , arch@freebsd.org Subject: Re: libc_r is deprecated X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 21:10:24 -0000 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