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