Date: Wed, 26 Oct 2005 22:17:56 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Wemm <peter@wemm.org> Cc: Marc Olzheim <marcolz@stack.nl>, Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org, David Xu <davidxu@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: libc_r is deprecated Message-ID: <20051026221511.R31152@fledge.watson.org> In-Reply-To: <200510261410.23688.peter@wemm.org> References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <435EBD49.7090207@freebsd.org> <20051026120219.V32255@fledge.watson.org> <200510261410.23688.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Oct 2005, Peter Wemm wrote: > 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. Similar properties can be explored using "juggle" and "thr_pipeline", which look at the performance of IPC between threads, and the performance of pthread'd data processing pipelines in microbenchmark form: http://www.watson.org/~robert/freebsd/benchmarks/ juggle tries a number of IPC methods, and illustrates how some of them do better for bigger data operations, some for smaller, some on UP, some on SMP, etc. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051026221511.R31152>