cvs commit: src/lib/libc/string strcspn.c strspn.c src/sys/libkern strspn.c

[David Schultz]

On Sun, Apr 03, 2005, Bruce Evans wrote:
> On Sat, 2 Apr 2005, David Schultz wrote:
> 
> >BTW, anyone know a good reason why we have optimized string
> >functions (e.g. strcmp(), strcpy()) in libc, but not in libkern?
> 
> It is because str* functions are almost never used in the kernel.
> E.g., to a first approximation, strcmp() is only used for initialization.
> Even the non-string function for copying pathnames from user space
> (copyinstr()) rarely shows up in profiles.  Standard C string functions
> are a few orders of magnitude less important than this.

Fair enough.  I haven't done any profiling for a while, so I'll
take your word for it that they're not important.  As you mention,
most of the uses seem to be for initialization.  Or in the I/O
path where nobody cares.

> >In testing strcmp(s, s), I found that the libc version on i386 is
> >11% faster when s has length 1 and 4% faster when s has length 400.
> 
> That's surprisingly little for an "optimized" asm version versus an
> unoptimized C version.

Yes, particularly given that 400 bytes still fits in my L1 cache.
AFAICT, the only trick that libc/i386/strcmp.S plays that gcc -O2
doesn't is loop unrolling.  Both versions do byte-by-byte
comparisons.  With gcc -O2 -funroll-loops -march=pentium4, the
C version isn't measurably slower at all for 400 byte strings.