Author: Matthew Hull
Date: 13:59:41 08/27/02
Go up one level in this thread
On August 27, 2002 at 16:01:50, Robert Hyatt wrote: >On August 27, 2002 at 13:03:39, Matthew Hull wrote: > >>On August 27, 2002 at 11:28:43, Robert Hyatt wrote: >> >>>On August 27, 2002 at 09:42:15, Matthew Hull wrote: >>> >>>>On August 26, 2002 at 22:36:13, Robert Hyatt wrote: >>>> >>>>>On August 26, 2002 at 21:33:18, Jeremiah Penery wrote: >>>>> >>>>>>On August 26, 2002 at 15:06:05, Robert Hyatt wrote: >>>>>> >>>>>>>On August 26, 2002 at 13:12:42, Jeremiah Penery wrote: >>>>>> >>>>>>>>On August 26, 2002 at 11:16:47, Robert Hyatt wrote: >>>>>> >>>>>>>>As I said, much of that time must come from the long travel path, slow memory >>>>>>>>controller, etc. >>>>>>> >>>>>>>We just disagree on where the delay is. I believe that at _least_ 80% of >>>>>>>the latency is in the chip. Not in the controller/bus... >>>>>> >>>>>>>>If you see 140ns today (average), you don't believe that almost half of that >>>>>>>>latency is caused by the travel path from CPU/controller/memory and back? If >>>>>>>>the memory controller runs at bus speed (133MHz), it has 7.5ns/clock cycle. >>>>>>>>That alone is significant latency added to the process. >>>>>>> >>>>>>>I don't believe it, no. I believe that most of the latency is in the DRAM >>>>>>>itself, not in the controller. The controller has no "capacitors" to deal >>>>>>>with, it is made up of SRAM buffers and some form of hardware logic (such >>>>>>>as TTL) which means switching times are at the picosecond level. It takes >>>>>>>a _bunch_ of picoseconds to add up to a nanosecond... >>>>>> >>>>>>The clock cycle of the memory controller is some 7.5ns. It can only send one >>>>>>request/clock, AFAIK. That is already adding significant latency. >>>>> >>>>> >>>>>OK... same issue I talk about in parallel programming classes... Amdahl's >>>>>Law, slightly paraphrased to fit here. If the total access time is > 100ns, >>>>>and the controller has a 7.5ns cycle time, what happens when you design a >>>>>controller that takes _zero_ nanoseconds? Answer: you are _still_ near >>>>>100ns in total access time as you only eliminated 7.5... >>>>> >>>>>That is the problem I see. DRAM is simply inherently slow in terms of >>>>>latency. It is hard to take a static charge, shunt it somewhere to measure >>>>>it, and do that quickly. Because of resistance, capacitance and inductance >>>>>as I mentioned earlier.. IE replace a capacitor with a balloon filled with >>>>>water. It is _hard_ to get that water out and over to something that can >>>>>measure it, when you have millions of balloons sharing common water tubes... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>>>Even a few 10s reduces your number of 120ns to the claimed 80ns of Hammer. :) >>>>>>> >>>>>>>I'll believe 80 when I actually get my hands on it. :) Because that will >>>>>>>be faster than any Cray ever made (that used DRAM, older crays used bipolar >>>>>>>but the memory was not nearly as dense). >>>>>> >>>>>>>I was talking about cray from the perspective that they have never had an 80ns >>>>>>>memory access time. It has _always_ been over 100 since they moved away from >>>>>>>bipolar memory to DRAM for density. And their controllers have >_never_ "sucked" >>>>>> >>>>>>It's difficult to find really accurate data on this. I've read more than a few >>>>>>different things. But from what I can tell, the latency (cycle time) of DRAM c. >>>>>>1994 was on the order of 100ns. (In 1980, it was 250ns; 1989 was nearer 170ns). >>>>>>It hasn't been lowered at that pace since then, but it has gotten lower. As >>>>>>I've said, current figures I've seen place it at 70ns today. _Any additional >>>>>>latencies_ seen are/were caused by controller, path length, and whatever else. >>>>> >>>>> >>>>>I don't know of any way to lower latency. How do you make a charge leave a >>>>>capacitor faster? Maybe at super-conducting temps, perhaps. But you have to >>>>>deal with the magnetic field that has to propogate as the current attempts to >>>>>move along a wire... Smaller distances can help _some_. But this is a "square" >>>>>problem. Not a linear problem. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>If you don't think path length can influence latency very much, then you must >>>>>>not talk about RDRAM having bad latency. :) The only reason it has higher >>>>>>latency is because of a much longer path length for the memory request signal. >>>>>>(And sometimes the banks can go into sleep mode, and take a while to wake.) >>>>> >>>>>I understand how they chain things together and how it added to the serial gate >>>>>count. The problem with RDRAM is that they couldn't make the DRAM dump any >>>>>faster, and they added more gates in an effort to improve streaming performance, >>>>>which has nothing to do with random access... >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>Cray machines probably have some additional issues because they're >>>>>>super-multi-ported designs, with a lot of processors trying to concurrently >>>>>>access the same memory banks. (I'm talking about their vector machines, not >>>>>>stuff like the T3E, which is some kind of Alpha cluster.) >>>>> >>>>>They have lots of issues. But even going back to single-cpu machines, latency >>>>>was no better than it is today... and with every new generation of cpu, the >>>>>memory fell that much farther behind... ie cycletime of cpu * number of cycles >>>>>to do a read has effectively been constant since they first went from Bipolar to >>>>>DRAM. >>>> >>>> >>>>How much is latency improved with bipolar? >>>> >>>>Also, what is the future of RAM. Now it seems hopelessly behind, and getting >>>>"behinder". >>> >>> >>>Bipolar has no actual read latency. So all the latency is in moving the >>>data around... IE think "JK flip-flop" and you'll get the idea. There is >>>a zero/one value that is always available without having to dump a capacitor >>>and rewrite it. The only latency issues are latency from the point where the >>>bit is presented to the point where the bit has to be moved... >>> >>>DRAM is definitely a slow item. But it is also, by far, the most dense memory >>>system we can build with reasonable access times. Cray went that way so that >>>they could build compact 32 gig memory systems. >> >> >>Where I work, we still have some old bipolar mainframes. But they still have >>high speed buffers (is that the same thing we call cache on a PC?). If memory >>latency is not an issue, why the high speed buffers? >> >>Also, why can't all memory be as fast as cache memory, or why can't all memory >>just be cache memory? >> >>Thanks. > > >Cache is based on SRAM. That is a group of transistors that lock an input >zero or one and hold their output at that level until told to do otherwise. > >The difference between having a light that is always on, so that the only >delay is to check it, vs having to turn the light on, let it warm up to get >bright enough, etc... > >Such as a sodium-vapor lamp. Takes a long time to get bright. > >I can't imagine a bipolar memory machine requiring buffers. Are you sure they >are not core-memory machines? That has the same sort of problem. To read a >bit, you have to try to change its state and sense if it changed or not. With >SRAM (Bipolar is one way to implement this) you don't have to turn it on or off >to see if it was off or no, you just measure the output that is always set... They might be hybrid bipolar-CMOS (Hitachi). > >As for why not cache rather than DRAM, the answer is in several parts. > >1. DRAM is _far_ denser than SRAM, so that it takes up less physical >space. > >2. DRAM requires less power, so it produces less heat. > >3. DRAM is far cheaper to manufacture. It is easier to make tiny capacitors >than to make tiny transistors. I've always wondered, and now I know. Thanks!
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.