Date: Thu, 12 Jul 2007 16:27:49 -0500 (CDT) From: "Sean C. Farley" <scf@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc Message-ID: <20070712161200.I8789@thor.farley.org> In-Reply-To: <86lkdl5osc.fsf@dwp.des.no> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <86lkdl5osc.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1187149148-1184274994=:8789 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20070712161640.I8789@thor.farley.org> On Thu, 12 Jul 2007, Dag-Erling Sm=F8rgrav wrote: > "Sean C. Farley" <scf@FreeBSD.org> writes: >> On Wed, 11 Jul 2007, Matthew Dillon wrote: >>> Long ago I decided that strlen() was simply not in the critical >>> path for virtually any program. >> Since strlen() is used in every program directly or indirectly >> through libc, I thought it was beneficial to make it faster. > > The first rule of optimization is: don't do it. > The second rule of optimization is: don't do it yet. > The third rule of optimization is: don't optimize what you haven't > measured. I am a rule breaker at least for the first two. :) I tried to follow the third rule. > Can you show us an actual application that spends a significant part > of its run time in strlen()? My test program that loops over strlen(). :) I already tested diff which showed that it does not spend enough time calling strlen() to matter, so I dropped the issue of optimization. I had looked into it while tweaking the *env() functions I wrote. It slowed them down a little, so I wanted to see what could be done with it. That is when I noticed that all platforms except for i386 and ARM use a faster (for me) C version already in the base. Currently, I am only suggesting that the C version, which is not optimized, be also used on i386. I did not test ARM. You could say the assembly version is going against the first rule of optimization. The dialog I am now having with Bruce is me trying to learn why I was seeing such a large difference between C and assembly. Sean --=20 scf@FreeBSD.org --0-1187149148-1184274994=:8789--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070712161200.I8789>