Originally Posted by Diablosbud
I've always been confused between latency and speed. Which is better when running at high CPU speeds, lower latency or higher clock? I know that a bit of both is important, but I'm just wondering which is more beneficial in certain situations.
If you ordered from Amazon.com, the latencies would be the guys filling the orders and sorting the boxes into the trucks and the clockspeed would be how fast trucks could go (and the road distance would be comparable to the latency due to the trace length in the motherboard, but that's another topic) bus width would be the size of the truck. Let's assume you live just a few miles from the distribution center and get enough stuff to warrant them having a truck specifically for your usage.
In this imperfect analogy, which is more important to you? That depends on your needs. When you place an order for a bunch of stuff you'll need in 15 minutes, you won't get it on time if the guys at the distro center can't fill the order quickly enough nor will you if the truck isn't big enough to do it in one trip nor if the truck isn't fast enough.
In short, both are important, but only insomuch as they are fast. The CPU says that it thinks it will need the contents of XX RAM cells. The speed this request is completely transmitted to the RAM is determined by the clockspeed. The time between the edges of the clock cycles is unused (and is technically a form of latency) while the distance that must be traveled across the computer board (ages in computer terms) is another latency. If you think of RAM as a giant spreadsheet with rows and columns, then you have a fairly good idea of how it's designed. When RAM gets a request, it looks up the appropriate cells and sends back the data. RAM latency (the time to do this lookup) is measured in clockcycles, but that isn't really useful outside of lower level design work. A much better type of measurement would be the time the lookup takes in nanoseconds like harddrives use (I realize that the amount of nanoseconds would change as you adjust the latencies and clockspeed, but cycles are meaningless without a frame of reference in time anyway).
Let's talk about latency in terms of time. If you have a RAM chip clocked at 120 cycles per minute (impossibly slow, but adding lots of digits doesn't help the explanation) and it takes 20 cycles for the memory to look up the answer and send it back, then the real time used is 10 seconds. Now, if we adjust to 240 cycles per minute, but keep the same 20 cycle latency, then our lookup time is now 5 seconds. What if it's 240 CPM and 40 cycle latency? then the actual time spent doing the lookup is the same as the 120 CPM and 20 cycle latency example. So... real latency is dependent on the clockspeed.
Anyway, the processor doesn't really care about how fast the RAM is nor does it care about the latency. The processor only cares about "is the information here when I need it?" The reason why CPU's use cache is to solve this exact issue. As the processor is working, it guesses about what data it will need and sends memory requests for that data. The data is then kept in the cache until it is needed or discarded. Since the latencies, speed, and distance of cache are better, there's a greater chance that the info will get to the CPU as it needs it. If the CPU guesses wrong, then the entire thread stalls out until the information arrives (a cache miss). ALL ddr memory is incredibly SLOW compared to what a CPU needs (that is, the CPU needs data EVERY clock cycle).
So back to the question about which is more important... Well, it depends, but with lots of onboard cache being normal in this day in age to compensate for all the time (real time) it takes for data to get from RAM to CPU, I would say that raw speed is more critical, but the tradeoff is that more transistors must be spent for cache and prediction.