Date: Mon, 13 Nov 2006 04:20:09 +0000 From: Chris <chrcoluk@gmail.com> To: "David Xu" <davidxu@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libpthread vs libthr. Message-ID: <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com> In-Reply-To: <200611130707.10220.davidxu@freebsd.org> References: <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> <200611130707.10220.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/11/06, David Xu <davidxu@freebsd.org> wrote: > On Sunday 12 November 2006 07:03, Chris wrote: > > On 10/11/06, Nikolay Pavlov <quetzal@zone3000.net> wrote: > > > Hi. In this post i am not trying to raise a discussion about teoretical > > > advantages of some special threading model, but still i would like to > > > figure out why libthr in it current state is not our default posix > > > thread library and could it be so in time of 7-STABLE? > > > > > > As a user and administrator of FreeBSD i want to mention some benefits > > > of libthr: > > > > > > 1. It's simpler. > > > 2. It's stable and has been used by many of us for a long time. > > > 3. It proved to be very productive on real world applications. > > > 4. It has active talented developers. > > > 5. If it was a default library it would couse a incrase of users > > > feedback which would lead to futher improvement of it's code by the time > > > 7 becomes a stable branch. > > > > > > And some flaws of libpthread: > > > > > > 1. It's more difficult. > > > 2. It's slow in compare of libthr. > > > 3. The last, but the worst. IMHO the position under which libpthread is > > > the library by default is the source of a bad myth that threading model > > > in FreeBSD sucks and threading applications is slow. If 7.0 had libthr > > > as a default posix threads library we could brake that belief. > > > > > > This point of view may seem one-sided that is why someone with good > > > knowledge of the current state of code could tell other pros and cons > > > of both libraries. > > > > > > Another interesting question is which of the libraries will better work > > > with multikernel and multiprocessor systems which will be very popular > > > by the time 7.0 branch launches its stable releases. > > > > > > -- > > > ====================================================================== > > > - Best regards, Nikolay Pavlov. <<<----------------------------------- > > > ====================================================================== > > > > HI I posted in another thread about how my own experiences seem to > > differ from all these benchmarks, they are based on 3 heavily loaded > > web/mysql servers. > > > > One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd > > 6.1 and 3rd is another dual xeon freebsd 6.1. > > > > All 3 of these machines perform better as well as more stable under > > higher loads using libpthread process scope. > > > > System scope appears to make mysql hog the system and everything slows > > down except of course mysql. > > > > Libthr appears to make mysql very sporadic with some requests fast > > others with a unexplained 5-10 sec delay including timeouts. > > > > Process scope on libpthread gives me the best results not making mysql > > starve the server of resources and it has a consistent response time > > of under 2 seconds under hevay loads. > libthr on FreeBSD 6.1 respects process scope, if your mysql is compiled > with process scope, it will use it, this is only removed in -CURRENT, > I don't know why you said that it starved server resource if KSEGRP > really works as expected. > > > > > I cant explain other then it maybe that test mysql data isnt a proper > > way to test these threading libraries only real work loads can. > > > > Chris > > _______________________________________________ Interesting libthr can use system or process scope? as far as I am aware it was using whatever the default is for libthr. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3aaaa3a0611122020n461719nfad2adf378498f5a>