From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1Dxc3t-0001jw-7W for garchives@archives.gentoo.org; Wed, 27 Jul 2005 02:54:25 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6R2pjSC025710; Wed, 27 Jul 2005 02:51:45 GMT Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6R2phKK023190 for ; Wed, 27 Jul 2005 02:51:44 GMT Received: from [192.168.0.123] (pcp04370732pcs.nrockv01.md.comcast.net[69.140.218.245]) by comcast.net (rwcrmhc12) with ESMTP id <20050727025045014000as9be>; Wed, 27 Jul 2005 02:50:45 +0000 Message-ID: <42E6F684.6040009@erols.com> Date: Tue, 26 Jul 2005 22:50:44 -0400 From: Matt Randolph User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc. References: <42E258A7.5080501@telia.com> <200507252224.52700.luke-jr@utopios.org> <1122331103.13635.51.camel@cocagne.max-t.internal> <200507261540.06591.luke-jr@utopios.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1ea9e5e6-e641-49dd-a102-5e5582bbcb4e X-Archives-Hash: ee4bd5e5272d5a5544b3c055cc2026ca This is interesting. Guess what effect cpu frequency scaling has on memcpy. I wonder if the difference has to do purely with the cpu frequency, or if it's because the memory controller in on the die. At 1800 MHz: $ ./memcpy 1808 1000 1048576 Memory to memory copy rate = 1060.210815 MBytes / sec. Block size = 1048576. At 1000 MHz: $ ./memcpy 1005 1000 1048576 Memory to memory copy rate = 808.985352 MBytes / sec. Block size = 1048576. This is an unpatched glibc, of course. I've got a single 512MB stick of premium Corsair ram in it (the sister stick lives in another computer until prices drop, at which time I will buy another matched pair of the good stuff). The fact that I'm using only one stick and I'm getting speeds similar to those using two, suggests to me that the strangely low numbers some people are getting are not explained away by their using only a single channel. -- "Pluralitas non est ponenda sine necessitate" - W. of O. -- gentoo-amd64@gentoo.org mailing list