Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Type: text/plain;
  charset="iso-8859-1"
From: Tim Prince <tprince AT computer DOT org>
Reply-To: tprince AT computer DOT org
To: "Gareth Pearce" <tilps AT hotmail DOT com>, ssakorho AT messi DOT uku DOT fi
Subject: Re: 1.3.10 memcmp() bug
Date: Thu, 25 Apr 2002 06:01:54 -0700
Cc: cygwin AT cygwin DOT com
References: <F177Hv1cO9MH7CSEI5W00007e62 AT hotmail DOT com>
In-Reply-To: <F177Hv1cO9MH7CSEI5W00007e62@hotmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020425130154.424F52CC3A@inet1.ywave.com>

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/