Date: Wed, 11 Jul 2007 23:19:30 -0500 (CDT) From: "Sean C. Farley" <scf@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc Message-ID: <20070711231412.K4613@thor.farley.org> In-Reply-To: <200707112351.l6BNpMUN063847@apollo.backplane.com> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <200707112351.l6BNpMUN063847@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2007, Matthew Dillon wrote: > :Since strlen() is used in every program directly or indirectly through > :libc, I thought it was beneficial to make it faster. In the case of > :i386, the C version used by all the other architectures, except for ARM, > :is much faster that the assembly version. This is without any > :optimization on its part. > : > :I need to test out grep (FreeGrep) to see how it behaves when calling > :regexec() (may use strlen() in certain cases) many times (i.e., grep -R > :on the source tree) using both versions. > > Yes, but there's a difference between using strlen() a couple of > times in the program and using it in a core processing loop or > other high-performance element of the program. And even if it is > used in such places it isn't going to be used so often that the > program would actually benefit from the few nanoseconds of > improvement you might get from it. The chances of that are nearly > zero. I tested it with diff and saw no difference :) between the assembly version and mine. I would still recommend to use the C version (src/lib/libc/string/strlen.c) over the assembly version since the assembly version adds no value while the C version is used already for most of the other architectures. Obviously, there is no rush. Sean -- scf@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711231412.K4613>