From owner-svn-src-head@FreeBSD.ORG Tue Nov 22 06:45:37 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47C69106566C; Tue, 22 Nov 2011 06:45:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id EB0758FC0C; Tue, 22 Nov 2011 06:45:36 +0000 (UTC) Received: by pzk33 with SMTP id 33so32055131pzk.3 for ; Mon, 21 Nov 2011 22:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RZc40lI4rakDFtxVD7ul69sAeEzRAn5izbdeHw+pi1c=; b=PMlplKSp3zyXmJBaFUFSo2k+VCanWX3G2o6A26XoH2880t31ON4bv6WT4J7irLjSIc tBUQjNDJzyLiKXihd5+KFB3WP07hW3/djjU2AR+N67H1ASWHTB9oC2v/xGS8WCQt1FLO PICPijWtaUK8RDJ32ACpezJsVbofuArkdaFIQ= MIME-Version: 1.0 Received: by 10.68.30.193 with SMTP id u1mr13914282pbh.93.1321944336299; Mon, 21 Nov 2011 22:45:36 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Mon, 21 Nov 2011 22:45:36 -0800 (PST) In-Reply-To: <201111220250.pAM2oPWC070856@svn.freebsd.org> References: <201111220250.pAM2oPWC070856@svn.freebsd.org> Date: Mon, 21 Nov 2011 22:45:36 -0800 X-Google-Sender-Auth: An2Os5eUWFzunOQVDjOdV_cRZgg Message-ID: From: mdf@FreeBSD.org To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r227812 - head/lib/libc/string X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:45:37 -0000 On Mon, Nov 21, 2011 at 6:50 PM, Eitan Adler wrote: > Author: eadler (ports committer) > Date: Tue Nov 22 02:50:24 2011 > New Revision: 227812 > URL: http://svn.freebsd.org/changeset/base/227812 > > Log: > =A0- fix some style(9) nits with my last commit > =A0- add a comment explaining why I used '|' instead of '||' > > =A0Submitted by: danfe@ > =A0Approved by: =A0emaste@ > > Modified: > =A0head/lib/libc/string/strcasecmp.c > =A0head/lib/libc/string/strncmp.c > > Modified: head/lib/libc/string/strcasecmp.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/lib/libc/string/strcasecmp.c =A0 Tue Nov 22 02:27:59 2011 =A0 = =A0 =A0 =A0(r227811) > +++ head/lib/libc/string/strcasecmp.c =A0 Tue Nov 22 02:50:24 2011 =A0 = =A0 =A0 =A0(r227812) > @@ -49,7 +49,7 @@ strcasecmp_l(const char *s1, const char > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*us1 =3D (const u_char *)s= 1, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*us2 =3D (const u_char *)s= 2; > =A0 =A0 =A0 =A0if (s1 =3D=3D s2) > - =A0 =A0 =A0 =A0 =A0 return (0); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > > =A0 =A0 =A0 =A0FIX_LOCALE(locale); > > @@ -73,8 +73,9 @@ strncasecmp_l(const char *s1, const char > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*us1 =3D (const u_char *)s= 1, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*us2 =3D (const u_char *)s= 2; > > - =A0 =A0 =A0 if (( s1 =3D=3D s2) | (n =3D=3D 0)) > - =A0 =A0 =A0 =A0 =A0 return (0); > + =A0 =A0 =A0 /* use a bitwise or to avoid an additional branch instructi= on */ > + =A0 =A0 =A0 if ((s1 =3D=3D s2) | (n =3D=3D 0)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); I guess I'm a little confused. Do we really have profiling information at this level that suggests the overhead of the branch is significant? I thought most hardware had pretty good branch-prediction, particularly with speculative execution. Wouldn't something like __predict_false() have more value for performance, or is all this just guess-work? I would much rather have the code say what it means unless there's real, measurable performance differences from doing otherwise. Thanks, matthew