Assembly string functions in i386 libc

[Sean C. Farley]

On Thu, 12 Jul 2007, Dag-Erling Smørgrav wrote:

> "Sean C. Farley" <scf at 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
-- 
scf at FreeBSD.org