Date: Wed, 26 Oct 2005 12:08:26 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: Marc Olzheim <marcolz@stack.nl>, Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org Subject: Re: libc_r is deprecated Message-ID: <20051026120219.V32255@fledge.watson.org> In-Reply-To: <435EBD49.7090207@freebsd.org> References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> <20051025134834.GB62148@stack.nl> <435EBD49.7090207@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-). Our goals are presumably to: - Provide improved programming tools and models so that people can write better/faster code. For example, adding KQueue, etc. - Make the commonly used programming tools and models as fast as we can. Just because people use threads where it doesn't always make sense doesn't mean we shouldn't try to make their applications faster. Threads are widely used not just because they offer parallelism, but also because they offer a programming model that is appealing. I'll try to set up and run Apache2 with various configurations as a substitute for the performance measurement httpd I have in src/tools/tools/netrate, and see how its mpms interact with our threading implementations. My increasing suspicion is that the performance issue for threads is heavy access to the file descriptor related locks, resulting in significant contention. I need to look at traces and profiling some more to decide which are the biggest problems, and whether there are useful ways to improve them that help. In the libthr vs. libpthread measurements, it could well be that libpthread reduces kernel lock contention by allowing a thread to compete less with itself for locks: i.e., it introduces additional kernel threads only when blocked on a real sleep, not a mutex wait, whereas with libthr, threads will yield to each other on a CPU as they sleep on mutexes, resulting in more mutex contention. This is just a conjecture, however. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051026120219.V32255>