From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHz5A-0006Bj-8L for qemu-devel@nongnu.org; Tue, 19 Mar 2013 12:08:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHz58-0001YQ-Oa for qemu-devel@nongnu.org; Tue, 19 Mar 2013 12:08:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHz58-0001YH-GK for qemu-devel@nongnu.org; Tue, 19 Mar 2013 12:08:10 -0400 Message-ID: <51488D63.3010504@redhat.com> Date: Tue, 19 Mar 2013 10:08:03 -0600 From: Eric Blake MIME-Version: 1.0 References: <1363362619-3190-1-git-send-email-pl@kamp.de> <1363362619-3190-4-git-send-email-pl@kamp.de> In-Reply-To: <1363362619-3190-4-git-send-email-pl@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2HTVRBAEENDINJMJRQEFG" Subject: Re: [Qemu-devel] [PATCHv2 3/9] buffer_is_zero: use vector optimizations if possible List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HTVRBAEENDINJMJRQEFG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/15/2013 09:50 AM, Peter Lieven wrote: > performance gain on SSE2 is approx. 20-25%. altivec > is not tested. performance for unsigned long arithmetic > is unchanged. >=20 > Signed-off-by: Peter Lieven > --- > util/cutils.c | 7 +++++++ > 1 file changed, 7 insertions(+) >=20 > diff --git a/util/cutils.c b/util/cutils.c > index 857dd7d..00d98fb 100644 > --- a/util/cutils.c > +++ b/util/cutils.c > @@ -190,6 +190,13 @@ size_t buffer_find_nonzero_offset(const void *buf,= size_t len) > */ > bool buffer_is_zero(const void *buf, size_t len) > { > + /* use vector optimized zero check if possible */ > + if (((uintptr_t) buf) % sizeof(VECTYPE) =3D=3D 0=20 > + && len % (BUFFER_FIND_NONZERO_OFFSET_UNROLL_FACTOR > + * sizeof(VECTYPE)) =3D=3D 0) { Is it worth factoring this check into something more reusable, by adding something like 'bool buffer_can_use_vectors(buf, len)' in patch 2/9? > + return buffer_find_nonzero_offset(buf, len)=3D=3Dlen; Spaces around binary operators. Is it worth rewriting this function into a simpler: check up to (BUFFER_FIND_NONZERO_OFFSET_UNROLL_FACTOR - 1) longs until we are aligned check buffer_find_nonzero_offset on the aligned middle check up to (BUFFER_FIND_NONZERO_OFFSET_UNROLL_FACTOR - 1) longs at tail instead of having two instances of code that can loop over the entire buffer? Otherwise, searching for zeros on an unaligned buffer will remain slower, even though the bulk of the search could still benefit from the vector operations. > + } > + > /* > * Use long as the biggest available internal data type that fits = into the > * CPU register and unroll the loop to smooth out the effect of me= mory Your patch results in C99 declarations after statements; while we require C99, I'm not sure if qemu prefers to stick to the C89 style of declarations before statements. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2HTVRBAEENDINJMJRQEFG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRSI1jAAoJEKeha0olJ0Nqc98H/1uwF61ia9Tn6vxWGAxqnYfh pjpLnsbzBSRVyUH0UwCNRUZd+FcbtF1s/EMl0PtOs97/6gEMTAZBv4x5uJJYe9/T MlH3mOERhvS57JIG0JDQfquduvykEZjntovE6NUqf1gyYfMaNW69gF2IKRn+AHJq luk4brn9ykfXzIxBc0GWSlHio0HsNAvQ9t6eq1kKZNxOzNbRlub5u8DJMGyPOhjY 1NAeqTcOhC+tGPbZ1c9yg6LXOYqNIKwhTVPI7zCELBVMWw1QkKqzqZ/p5wECP6eL 7lm3VfxCfxqAxkjBh8DtIdP6lgH1YrHQlad4ANiOymVE54NJ+brIopwsSsVZD84= =7icd -----END PGP SIGNATURE----- ------enig2HTVRBAEENDINJMJRQEFG--