Re: rawmemchr

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Wed, May 21, 2008 at 03:01:55PM +0100, Dave Korn wrote:
>Eric Blake wrote on 21 May 2008 04:56:
>>According to Christopher Faylor on 5/20/2008 9:22 PM:
>>>Unless there's something I'm missing, cygwin should be using the
>>>assembly language routines in string.h.
>>
>>True enough.  But look at machine/i386/strchr.S - it skips straight to
>>L9 if the string is unaligned, rather than parsing the first few bytes
>>and benefiting from the aligned algorithm on the bulk of the search.
>>And in the special case of the target byte of 0, it still wastes time
>>creating a second mask, and performing two tests instead of one inside
>>the L10 loop.  ~ The same principles should apply of providing
>>rawmemchr in x86 assembly to make strchr(p,0) behave almost twice as
>>fast as it currently does.
>
>Maybe you could show a few timing measurements from realistic testcases
>at this point in the discussion?  I haven't felt comfortable trying to
>directly infer from instruction counts to real-time clock cycles any
>time in the past two decades myself, there are so many confounding
>factors these days that I'm not even confident of being able to validly
>reason about it any more.

I took a look at freebsd's implementation of strchr last night and they seem
to use an implementation that is similar to what cygwin uses internally -
just a simple asm implementation.

I'm not really comfortable going with a new strchr implementation given how
important that function is.  If we can find a free, tested implementation that
is better than what we have now, then I'm all for changing to it.

And, btw, an oft-repeated meta issue: please don't cc between closed and
open mailing lists.  It makes it difficult for the people in the open
mailing list (newlib) to respond.

cgf