Date: Fri, 29 Aug 2003 06:34:11 -0400 From: Mike Makonnen <mtm@identd.net> To: Daniel Eischen <eischen@vigrid.com> Cc: David Xu <davidxu@freebsd.org> Subject: Re: Call for thread testers Message-ID: <20030829103411.GA18513@kokeb.ambesa.net> In-Reply-To: <Pine.GSO.4.10.10308271953550.9892-100000@pcnet5.pcnet.com> References: <200308280723.35697.davidxu@FreeBSD.org> <Pine.GSO.4.10.10308271953550.9892-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 27, 2003 at 07:57:18PM -0400, Daniel Eischen wrote: > > Yes, perhaps my kernel was a bit out of date. I also had > forgotten I had libc_r mapped to libkse with libmap.conf, > so the libc_r tests were actually using libkse! I re-ran > the tests on a different box, single PIII 800MHz, 512MB RAM. > They look better, although libthr still doesn't give consistent > results. > > Run 1 Run 2 Run 3 > ----------------------------------------------------------- > libc_r real 0m13.739s 0m13.739s 0m13.882s > user 0m3.330s 0m3.302s 0m3.394s > sys 0m9.858s 0m9.893s 0m9.820s > ----------------------------------------------------------- > libkse(M:N) real 0m11.977s 0m12.199s 0m12.097s > user 0m3.248s 0m3.081s 0m2.857s > sys 0m8.190s 0m8.517s 0m8.575s > ----------------------------------------------------------- > libkse(1:1) real 0m11.972s 0m12.044s 0m12.035s > user 0m3.198s 0m2.980s 0m3.183s > sys 0m8.244s 0m8.480s 0m8.282s > ----------------------------------------------------------- > libthr real 0m34.180s 0m16.193s 0m34.119s > user 0m5.075s 0m3.874s 0m5.255s > sys 0m28.286s 0m11.626s 0m28.038s > ----------------------------------------------------------- > > libkse(1:1) and libkse(M:N) are about equal, and slightly > better than libc_r. I can't explain libthr results. Libthr is built with debugging options by default. Still, though it shouldn't be taking such a big performance hit. I suspect the real cause has something to do with the general "unfinished" state of the library in the sense that I haven't bothered with optimizations so far. Also, the fact that syncronization on locks in the kernel use sched_lock may be pessimizing performance. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030829103411.GA18513>