In comp.sys.ibm.pc.hardware.chips already5chosen@[EMAIL PROTECTED]
wrote in part:
> SRAM could shave off 15 ns in the case of DRAM page miss. Or
> 50-55ns in the case of page conflict, but those are very
> rare. In the supposedly most common case of DRAM page hit
> SRAM doesn't help at all. Actually, you will have hard
> time finding commodity SRAMs that is as fast as now common
> DDR2-800 CL5 at page hit.
You are talking device response times, and I appreciate your
information. However, I am interested in system response (software
performance), and my measurements are far less encouraging:
Latency CPU@[EMAIL PROTECTED]
mem.ctl RAM
ns
88 k8@[EMAIL PROTECTED]
NForce3 DDR400
144 P3@[EMAIL PROTECTED]
laptop SO-PC133?
148 2*P3@[EMAIL PROTECTED]
Serverworks ??
178 P4@[EMAIL PROTECTED]
i850 RDRAM
184 K7@[EMAIL PROTECTED]
SiS735 PC133
185 P3@[EMAIL PROTECTED]
440BX PC100
217 2*Cel@[EMAIL PROTECTED]
440BX PC90
234 P2@[EMAIL PROTECTED]
440BX PC100?
288 P2@[EMAIL PROTECTED]
440BX PC66
I do need to find & test some more modern systems, but I'm
underwhelmed by the slowness of latency improvement. CPU has
increased min 4x, latency response at best 2.5x . Run this
pgm from L2 (small set) and it comes back around 10 ns.
compile: $ gcc -O2 lat10m.c
run: $ time ./a.out [multiply user time by 100 to give ns]
/* lat10m.c - Measure latency of 10 million fresh memory reads
(C) Copyright 2005 Robert Redelmeier - GPL v2.0 licence granted */
int p[ 1<<21 ] ;
main (void) {
int i, j ;
for ( i=0 ; i < 1<<21 ; i++ ) p[i] = 0x1FFFFF & (i-5000) ;
for ( j=i=0 ; i < 9600000 ; i++ ) j = p[j] ;
return j ; }
-- Robert
|
