Date: Tue, 22 Apr 2003 06:25:35 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Terry Lambert <tlambert2@mindspring.com> Cc: threads@freebsd.org Subject: Re: libkse -> libpthreads Message-ID: <20030422060235.Y33034-100000@haldjas.folklore.ee> In-Reply-To: <3EA49134.71A5BDC8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Apr 2003, Terry Lambert wrote: > Narvi wrote: > > On Mon, 21 Apr 2003, Geoffrey C. Speicher wrote: > > > What's not clear about it? libkse is a superset of the functionality > > > of libthr. Seems pretty straightforward to me that the long-term > > > winner is libkse. > > > > This assumes that libkse M:N model will provide supperior performance and > > scalability, and this is not clear. Or does merely the fact that itis M:N > > somehow make it more winning contender? > > See other discussion. Performance should be identical, after > the upcall is eliminated in the case where all threads are > created PTHREAD_SCOPE_SYSTEM, and libkse communicates this to > the kernel to avoid generation of upcalls on blocking operations. > > Jeff makes a good point about the potential for bugs because of > the more sophisticated and larger total number of lines of code, > however. > Unless something went inheremtly wrong in case of the solaris threading libraries (or the published information is wrong), there is the potential for the additional code and complexity to add sufficent overhead to be measurable as perfomance degradation. It could be such might happen only with large values of M and N (and thus not surface in the next K years in a serious way in FreeBSD) or it could show up also on relatively small values of M and N or not at all. There are some unknowns in the picture, and say assigning a non-trivial likelyhood to at some point all processorts being 8-way (or even 4-way) EV8 style SMT would change some aspects of it. > Daniel also makes a good point about not finding them unless the > code is put in production. > > To my mind, it comes down to bug avoidance vs. bug detection, if > you weigh these arguments against each other. > I prefer bug avoidance and spending the saved time on perfomance - but this is for the moment a preference of somebody without time to spend on either thread library. > -- Terry >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030422060235.Y33034-100000>