Date: Sun, 3 Apr 2005 06:20:39 -0400 From: David Schultz <das@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/string strcspn.c strspn.c src/sys/libkern strspn.c Message-ID: <20050403102039.GA24319@VARK.MIT.EDU> In-Reply-To: <20050403162709.Q30325@delplex.bde.org> References: <200504021852.j32IqjhR031587@repoman.freebsd.org> <20050402185706.GA19208@VARK.MIT.EDU> <20050403162709.Q30325@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050403102039.GA24319>