Re: libc_r is deprecated
From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 10/25/05
- Previous message: Marc Olzheim: "Re: libc_r is deprecated"
- In reply to: David Xu: "Re: libc_r is deprecated"
- Next in thread: Peter Wemm: "Re: libc_r is deprecated"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 25 Oct 2005 15:39:33 +0100 (BST) To: David Xu <davidxu@freebsd.org>
On Tue, 25 Oct 2005, David Xu wrote:
>>> Deprecate in 6.x and remove in 7.0?
>>>
>>> Someone might be able to make a port out of it also.
>>
>> I'd like to keep it around in some form -- I recently ran a series of
>> HTTP-related benchmarks and libc_r benchmarked signicantly faster than
>> other libraries on both UP and SMP. I'm working to refine the
>> benchmark for improved realism, and will see if that persists.
>> However, when it comes to understanding scheduling and threading
>> behavior, I think libc_r remains useful...
>
> libc_r runs on single kernel thread, so if you are continue using
> libc_r, you are not testing TCP/IP with multithreads program, this may
> give you false data. Only kernel threads based server can test to see if
> the TCP/IP stack locking works well.
The goal of this set of tests was to look at performance, not stability,
and was a comparative look at the relative performance of the libraries
with identical workloads. Since I was interested in the impact of direct
dispatch in the network stack, which affects scheduling and how workload
is assigned to threads, I felt looking simultaneously at the threading
model was important. I run most of my thread related tests (performance
and stability) using all available threading libraries, although I don't
currently consider case where system scope threads are forced in
libpthread, and the results depend a lot on the nature of the workload.
To be honest, I was quite surprised by how much better performance was
with libc_r for the HTTP-related tests, but due to being pretty busy the
last few weeks, haven't had a chance to figure out why as yet. I hope
hopes of investigating more thoroughly in the next couple of weeks.
The load below is generated by pairing a multi-threaded http client on one
machine, and a multi-threaded http server on another machine. I need to
clean up the server a bit, and also add a forked execution mode. My
anticipation is that, due to reduced contention on file descriptor array
locks for processes, it may actually be faster forked than threaded, and
lead to SMP showing improved performance. So while the tests need
refinement, the results are still quite interesting. Another interesting
observation from these tests is that libthr seemed to outperform
libpthread on UP, but vice versa on SMP.
Robert N M Watson
7.x UP Queued Dispatch:
x httpd_libc_r_queue
+ httpd_libpthread_queue
* httpd_libthr_queue
+--------------------------------------------------------------------------+
|++ * * * xxx|
|+++ * ** ** * * * * xxx|
||A |_____MA_____| |A||
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 11369 11427 11395 11395.25 20.307298
+ 12 9636 9687 9647 9648.5 14.343196
Difference at 95.0% confidence
-1746.75 +/- 14.8851
-15.3288% +/- 0.130626%
(Student's t, pooled s = 17.58)
* 12 9842 10372 10025 10046.917 158.16186
Difference at 95.0% confidence
-1348.33 +/- 95.4708
-11.8324% +/- 0.837812%
(Student's t, pooled s = 112.755)
7.x UP Direct Dispatch:
x httpd_libc_r_direct
+ httpd_libpthread_direct
* httpd_libthr_direct
+--------------------------------------------------------------------------+
|++ * x |
|++ * * * xxx|
|++ * * * * ** * * xxx|
||A |_____A__M_| |A||
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 11463 11506 11487 11484.083 12.42767
+ 12 9866 9899 9884 9881.6667 10.464949
Difference at 95.0% confidence
-1602.42 +/- 9.72722
-13.9534% +/- 0.0847018%
(Student's t, pooled s = 11.4883)
* 12 10463 10869 10759 10686.667 133.98055
Difference at 95.0% confidence
-797.417 +/- 80.5601
-6.94367% +/- 0.701494%
(Student's t, pooled s = 95.1452)
7.x SMP Queued Dispatch:
x httpd_libc_r_queue
+ httpd_libpthread_queue
* httpd_libthr_queue
+--------------------------------------------------------------------------+
| * ++ x|
| * ++ x|
| * ++ xx|
|*** ++ xx|
|*** ++ xx|
|*** ++ xx|
||A| |A |A|
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 10573 10665 10642 10631.833 27.259138
+ 12 7591 7620 7605 7604.5833 9.6996564
Difference at 95.0% confidence
-3027.25 +/- 17.3228
-28.4735% +/- 0.162933%
(Student's t, pooled s = 20.459)
* 12 5400 5548 5460 5467.25 48.028637
Difference at 95.0% confidence
-5164.58 +/- 33.0639
-48.5766% +/- 0.31099%
(Student's t, pooled s = 39.05)
7.x SMP Direct Dispatch:
x httpd_libc_r_direct
+ httpd_libpthread_direct
* httpd_libthr_direct
+--------------------------------------------------------------------------+
| * + xx|
| * + xx|
| *** ++ xx|
|******* ++ xx|
| |_A| |A A||
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 10603 10649 10621 10620.333 13.865151
+ 12 8664 8695 8676 8678.0833 10.569754
Difference at 95.0% confidence
-1942.25 +/- 10.4383
-18.288% +/- 0.0982856%
(Student's t, pooled s = 12.3281)
* 12 7165 7449 7307 7297.25 77.255332
Difference at 95.0% confidence
-3323.08 +/- 46.9927
-31.2898% +/- 0.442479%
(Student's t, pooled s = 55.5006)
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Marc Olzheim: "Re: libc_r is deprecated"
- In reply to: David Xu: "Re: libc_r is deprecated"
- Next in thread: Peter Wemm: "Re: libc_r is deprecated"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
