Wed May 21 14:56:00 GMT 2008
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.
More information about the Cygwin-developers