Mail Archives: cygwin/2002/04/25/09:14:28
On Thursday 25 April 2002 00:22, Gareth Pearce wrote:
> >On Tuesday 23 April 2002 23:41, Sami Korhonen wrote:
> > > On Tue, 23 Apr 2002, Tim Prince wrote:
>
> >AFAICT there's no reason this should behave differently on linux or
> > cygwin. You're comparing the speed of memcmp() against the speed of
> > comparing ints in
> >a loop. When you don't ask the compiler to in-line memcmp(), you get a
> >library function which is written with enough smarts to compare 4 bytes at
> >a
> >time. Various versions of gcc are interpreting the instruction to use
> >"optimized" in-line code as a rep cmpsb, which is slower than the newlib
> >memcmp() function, even on my P-III.
> >P4's, particularly early versions, are notorious for various performance
> >glitches when using rep cmpsb on long strings. gcc isn't smart enough to
> >look at the lengths of your strings and second guess your instruction to
> > do that, nor does it have a crystal ball to second guess your instruction
> > to generate 486 code, even if you were running a version with P4
> >optimizations.
> >In time critical applications, it can be quite important to learn the
> >particular tricks of your compiler and when to choose a separately
> > compiled string function, or when to ask for in-line, as well as to
> > acquire a library
> >of such functions built for the processor of your choice. On the P4, you
> >would have available 64-bit integer comparisons if you chose to use them
> > to speed this up.
> >--
>
> gcc 3.1+ are supposed to be 'more' intelligent about such things -
> althought they arent brilliant.
>
> Regards,
> Gareth
At least with -march=pentium3, gcc-3.1 has the same problem of not knowing
not to do what is asked.
--
Tim Prince
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -