From owner-svn-src-head@FreeBSD.ORG Fri Oct 1 15:28:03 2010 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 9FBCD106566C; Fri, 1 Oct 2010 15:28:03 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2368FC1C; Fri, 1 Oct 2010 15:28:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:75a8:594d:1806:1e34] (unknown [IPv6:2001:7b8:3a7:0:75a8:594d:1806:1e34]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 675775C43; Fri, 1 Oct 2010 17:28:02 +0200 (CEST) Message-ID: <4CA5FE07.5010104@FreeBSD.org> Date: Fri, 01 Oct 2010 17:28:07 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100929 Lanikai/3.1.5pre MIME-Version: 1.0 To: Roman Divacky References: <201010011310.o91DABUU007534@svn.freebsd.org> <20101001132233.GA83116@freebsd.org> In-Reply-To: <20101001132233.GA83116@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jilles Tjoelker , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r213326 - head/lib/libc/i386/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: Fri, 01 Oct 2010 15:28:03 -0000 On 2010-10-01 15:22, Roman Divacky wrote: > there's "rep cmps" in bcmp.S and memcmp.S in both amd64/i386 > > they both have C counterparts, no idea how fast those are (they > are going char by char). > > does this wisdom apply to those too? Well, these versions compare by words first, using "repe cmpsl" (for i386) and "rep cmpsq" (for amd64). Only if there any bytes remaining after that, they are checked with "repe cmpsb". It is probably possible to optimize these versions for the case the source pointers are not aligned. That will not occur too much, probably, and complicate the implementation. On the other hand, the C implementations of bcmp and memcmp are basically simple "while (*src++ == *dst++);" implementations, so it is entirely up to the compiler to do any optimization magic there. In any case, without some statistically sane speed measurements, this is all just talk... ;)