This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12019] memchr overshoots on Alpha
- From: "mcree at orcon dot net dot nz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 23 Sep 2010 10:48:35 -0000
- Subject: [Bug libc/12019] memchr overshoots on Alpha
- References: <20100914154213.12019.eblake@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mcree at orcon dot net dot nz 2010-09-23 10:48 -------
RTH's patch certainly fixes the segfault that was in the test case reported by
Debian. Speed tests also show it runs faster when searching large memory
buffers. I allocated 100Mbytes memory, filled it with 0xff except for a 0x00
half way in, then timed the memchr() search for the 0x00. With current memchr()
(alphaev6 optimised version from Debian's libc6.1-alphaev67 package) get (after
averaging over 10 memchr() searches):
cycles: 129525563 (scaled from 50.0%)
instructions: 50746044 (scaled from 50.0%)
cache-misses: 837238 (scaled from 50.0%)
mbox-replays: 4416463 (scaled from 25.0%)
With RTH's new version get (compiled with -O2 -mcpu=ev67):
cycles: 52405038 (scaled from 50.0%)
instructions: 62017822 (scaled from 50.0%)
cache-misses: 1034687 (scaled from 50.0%)
mbox-replays: 6866 (scaled from 25.0%)
so while it executes more CPU instructions it does it much faster! It's over
twice as fast as the old version. Nice. The almost complete removal of Mbox
replay traps is presumably a significant part of the speedup.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=12019
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.