Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: x86_64 optimization patches for glibc.
Date: Tue, 26 Jul 2005 09:50:00 -0700
Luke-Jr posted <200507261540.06591.luke-jr@...>, excerpted below, 
on Tue, 26 Jul 2005 15:40:05 +0000:

> On Monday 25 July 2005 22:38, Olivier Crete wrote:
>> On Mon, 2005-25-07 at 22:24 +0000, Luke-Jr wrote:
>> > On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
>> > > > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
>> > > > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
>> > > > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
>> > >
>> > > Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
>> > > Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =
>> >
>> > Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size
>> > = After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block
>> > size =
>> >
>> > Anyone have a clue why I'm getting half what everyone else gets? o.O
>>
>> What kind of cpu/ram/motherboard do you have ?
> 
> RAM: 2875MB/1002MB (286%) used (I didn't see swapping during the test, tho)
> Motherboard: Asus K8V-SE
> CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.876 MHz)

Perhaps it has something to do with the layout of your memory (and BIOS
configuration), single-channel vs. dual-channel memory access?

I'm getting the same lower (550-ish pre- haven't tried the patch yet)
readings here.  However, I know I only have a single 512 meg stick slotted
for each of my two CPUs (dual Opteron), and I'm running NUMA mode, so the
memory is only being accessed at single-channel speeds.  I expect I'd
double those numbers if I had paired sticks operating in per-node
interleaved dual-channel mode.  If I turned off NUMA and set inter-node
interleaving as well, with 4 matched memory sticks, to get full
quad-channel 128-bit interleaving, I expect the numbers would rise
accordingly. (Of course, the latter would be at the expense of allowing
parallel threads running on each CPU independent but parallel access to
their own memory.  I can get dual channel without foregoing that, since
each node is dual-channel capable, but couldn't get quad-channel without
foregoing that independent parallel access, since quad-channel is
inter-node interleaved.)

Of course, that's just supposition, here.  If those with the 1100/2200
rates would confirm whether they are running in dual-channel memory mode,
as I suspect, and you confirm that you are running single-channel mode, as
I am, it'll pretty much confirm that supposition, however.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list


Replies:
Re: Re: x86_64 optimization patches for glibc.
-- Matt Randolph
Re: Re: x86_64 optimization patches for glibc.
-- Sami Samhuri
Re: Re: x86_64 optimization patches for glibc.
-- Raffaele BELARDI
References:
x86_64 optimization patches for glibc.
-- Simon Strandman
Re: x86_64 optimization patches for glibc.
-- Luke-Jr
Re: x86_64 optimization patches for glibc.
-- Olivier Crete
Re: x86_64 optimization patches for glibc.
-- Luke-Jr
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: x86_64 optimization patches for glibc.
Next by thread:
Re: Re: x86_64 optimization patches for glibc.
Previous by date:
Re: x86_64 optimization patches for glibc.
Next by date:
Re: Re: x86_64 optimization patches for glibc.


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.