This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Updated x86-64 memcpy and New x86-64 memset
- From: Ulrich Drepper <drepper at redhat dot com>
- To: "Menezes, Evandro" <evandro dot menezes at amd dot com>
- Cc: List GLIBC <libc-alpha at sourceware dot org>
- Date: Mon, 20 Aug 2007 16:01:16 -0700
- Subject: Re: Updated x86-64 memcpy and New x86-64 memset
- References: <1E52B51E700FAF42ADA0B9432F7CCCD25A84E6@SAUSEXMB1.amd.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Menezes, Evandro wrote:
> This patch updates the x86-64 memcpy for AMD's upcoming Barcelona
> processor, which bears an L3 cache shared among its cores.
>
> A new x86-64 memset is also proposed which improves the performance for
> both tiny (a few bytes) and huge (a few Mbytes) blocks.
Have you even looked at the code I checked in the libc cvs? You
introduced all the same problems again. WTF do you define
_x86_64_data_cache_size? I've pointed this out already back when.
Also, the variable names are inconsistent. We always use __ prefixes
for such objects. You even renamed one variable by removing a leading
_. Don't ever do this!
You compare (in memcpy) what is larger:
__x86_64_core_cache_size_half
_x86_64_data_cache_size_half
The result is never going to change. Therefore this should be done in
the cacheinfo initialization. If one of the vars is never used
otherwise remove it (I haven't checked it).
In addition you mess around with whitespacing. Don't.
Where are the performance numbers for memset? For Intel and AMD.
And the piÃce the rÃsistance: the patch is a complete mix of Unix and
DOS line terminations. What are you thinking?
- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGyh082ijCOnn/RHQRAmC5AJ4/OG9qKGdKiQVjn1ef+KUfaSW4CACfd5tb
p4Su3ap+wQ96HdIQK/3iBTc=
=L4ly
-----END PGP SIGNATURE-----