[Beowulf] Woodcrest Memory bandwidth
sdm900 at gmail.com
Mon Aug 14 18:00:38 PDT 2006
actually, latency determines bandwidth more than memory speed... see
my rant(?) from a little over a year ago
prefetch etc. help, but the limiting factor is still latency. Hence
the opterons have significantly higher real memory bandwidth (their
latency is about 1/3 that of xeons/p4's etc). If you look at the
ia64's then they have even high latency again, but they can have a
huge number of outstanding loads (from memory its >80), so their
effective bandwidth is high.
On 15/08/2006, at 8:10, Joe Landman wrote:
> Hi Stu:
> Stu Midgley wrote:
>> sorry, forgot to reply all... don't you hate gmail's interface
>> What is the memory latency of the woodcrest machines? Since memory
>> latency really determines your memory bandwidth.
> Hmmm... not for large block sequential accesses. You can prefetch
> these assuming enough intelligence in the code generator (heh), or the
> hardware if the memory access pattern is fairly consistent.
> Latency really defines the random access local node GUPS, well, its
> really more complex than that, but roughly that.
> That said, I would like to measure this. I have an old code which
> this, any pointers on code other people would like me to run? If its
> not too hard (e.g. less than 15 minutes) I might do a few.
>> If Intel hasn't made any improvements in latency then the limited
>> number of out-standing loads in the x86-64 architecture will limit
>> bandwidth regarless of the MB/s you throw at it.
> Hmmm... Ok, you are implying that if your processor can consume the
> load/store slots faster than it can launch them, and there are a
> number of memory operations in flight (2? as I remember, not
> looking at
> my notes now), it is going to be load-store pipeline limited, not
> necessarily "bandwidth". That is, the memory system would be
> significantly faster than the CPU can consume.
> I haven't looked closely at the Woodcrest arch yet. Don't know
> precisely what they are doing here and how it differs from AMD. Would
> be interesting. So far I haven't been impressed with code that I
> thought I should be really impressed with on this machine. Oddly the
> performance was about what we got out of the Core Duo on this
Dr Stuart Midgley
Industry Uptake Program Leader
iVEC, 'The hub of advanced computing in Western Australia'
26 Dick Perry Avenue, Technology Park
Kensington WA 6151
Phone: +61 8 6436 8545
Fax: +61 8 6436 8555
Email: industry at ivec.org
More information about the Beowulf