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/
