Call for thread testers
Mike Makonnen
mtm at identd.net
Fri Aug 29 03:34:14 PDT 2003
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 at identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon !
More information about the freebsd-threads
mailing list