libc_r is deprecated
Robert Watson
rwatson at FreeBSD.org
Wed Oct 26 14:17:58 PDT 2005
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
More information about the freebsd-arch
mailing list