This is the mail archive of the
mailing list for the glibc project.
Re: [i386] memcmp very slow
- From: Roger Sayle <roger at eyesopen dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: <gcc at gcc dot gnu dot org>, <libc-alpha at sources dot redhat dot com>
- Date: Mon, 28 Oct 2002 21:33:08 -0700 (MST)
- Subject: Re: [i386] memcmp very slow
Could you describe which processor (and perhaps the version of
GCC) you're timing? I seem to be unable to reproduce your results,
as my numbers show your routine slightly slower on a 1.2GHz AMD
athlon using GCC 3.3 (experimental) on i686-pc-cygwin (1.472s vs. 1.402s
for a x100 version of your test.c benchmark). However both are much
better than the system memcmp (1.57s).
I'd love to see a faster i386 "memcmp" in glibc, newlib and,
if possible, GCC.
My only concern with disabling x86 memcmp in the compiler is that
GCC is also used to generate x86 code for non-glibc targets, where
not inlining memcmp may adversely affect performance.
The algorithm itself looks very clever. An implementation in
GCC's i386 backend could even make use of the known alignment
information, and then even transform "memcmp(a,b,c)" into
"-memcmp(b,a,c)" to take advantage of your algorithm's asymmetry
if a and b were known to have different alignments.
If I may make two suggestions. You should add another loop
to test.c's main, as the resolution of time(1) means that its
safer to compare times in seconds rather than hundredths of a
second. Secondly, you should compare the "user" (or CPU) times
reported by time(1) rather than the "real" (or elapsed) times.
Roger Sayle, E-mail: firstname.lastname@example.org
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833