Athlon goes DDR

[David N. Lombard]

"Robert G. Brown" wrote:
> 
> On Mon, 30 Oct 2000, Eugene Leitl wrote:
> 
> > --AMD introduces AMD-760? chipset, enabling the world's first
> > commercially available PC platform supporting next-generation Double
> > Date Rate (DDR) memory technology--
> 
[dnl]
>
> Seriously, this looks very promising.  According to my benchmarks, there
> is a class of code (mostly big-memory vector arithmetic operations) that
> will just about double if they do indeed succeed in doubling memory
> bandwidth.  However, they didn't mention (or if they did I didn't see
> it) the effect on memory latency.  Are we to presume that DDR won't
> affect memory latency relative to SDRAM?  I would guess that if it
> significantly improved it they would have said something...

Having worked with one of those codes for a long time, I can assure you
that latency is not the issue, these are bandwidth dominant codes.  The
app in question is one of the few that does well with RDRAM.  We have
always been more concerned about memory b/w than CPU speed.  Back when
Intel first released the 150 MHz P5, we did a benchmark with rejumpering
the carrier of a 150 MHz CPU w/ 60 MHz FSB to 133 MHz CPU w/ 66 MHz
clock, the latter was 10% faster.

Equally significant in the press release was the 266 MHz FSB.

> Also, as always, folks should be aware (before they rush right out and
> buy 128 spanking new nodes based on the technology) that on a LOT of
> code mixes "cache works".  Like mine.  What this means is that one's
> numerical performance is much more strongly tied to the CPU's rates when
> operating on data in L1 or possibly L2, and my measurements show AMD
> CPU's to very slightly underperform relative clock compared to Intel for
> these code mixes, pretty much independent of memory speed.  The BEST
> thing to do is find such a box and try it with your code (which I plan
> to do as soon as possible).

Amen!  The best benchmarks are for YOUR code running YOUR datasets.

-- 
David N. Lombard