5 ms·
CPUs keep on getting more memory channels per socket. That trend was already visible 15 years ago, when AMD moved the northbridge onto the CPU. Scaling it depen
by greglindahl 7y ago
CPUs keep on getting more memory channels per socket. That trend was already visible 15 years ago, when AMD moved the northbridge onto the CPU. Scaling it depends on scaling pin counts, which are now amazing.
- wtallis 7y agoTo put some numbers to this: In 2005, Opterons used a 940-pin socket and had dual-channel DDR, for 6.4GB/s total bandwidth to feed two cores. In 2009, Xeons the LGA1366 socket to provide triple-channel DDR3, 32GB/s for four (later six) cores. Now, we're up to 4094 pin sockets providing 8 channels of DDR4 for a total of 204.8GB/s of memory bandwidth for 64 cores, which is exactly the same per-core bandwidth we had in 2005. (And for comparison, a $200 graphics card will also have around 200GB/s of memory bandwidth.)
- vbezhenar 7y agoUnrelated question, what about RAM latency? Did it significantly improve since 2005?
- dwrodri 7y agoSo at the consumer level, DDR2[popular standard c. 2005] could be clocked up to 266 MHz whereas DDR4[popular now] clocks in at 1600MHz. So a little more than a 6x speedup in transaction times. Unlike processors, whose features make it quite difficult to compare against each other, DRAM has stayed relatively straightforward: its still just a bunch of densely packed flip-flops connected to a memory controller that offers bank-strided column/row access. As you can imagine, processor performance has grown a lot more than 6x over the years. The amount of cores in a package alone has increased more than 6x! So how do we get around this? 1) Larger caches: the most efficient optimization to any slow task is to simply not perform said task. Having a larger L3 cache means sending requesting fewer pages from DRAM. 2) “Hiding” latency with bandwidth: if I have to incur a (relatively) large time penalty tp go to DRAM, I better make sure to make it worth my time. Instead of always getting data in 4KiB pages, often times modern processors support “superpages” all the way up to the gigabytes. If you’re going to go drive out to the store, it makes sense to buy groceries for the week instead of just the candy bar you’re craving right now, right? That way when you actually have to cook the work has already been done. I am probably missing some nuance here, especially when it comes to memory controllers and putting caches on DRAM, but this is the gist.
- vbezhenar 7y agoBut frequency of RAM and latency is not the same. DDR2-800 can have something like 4-4-4-12 timings, while DDR4-2666 can have something like 15-17-17-35 timings. So their result latency will be around the same! And those numbers I just googled, I did not made them up.
- Retric 7y agoDDR2 vs DDR4 has effectively zero impact on latency. Due to the physical distances between RAM modules and the CPU, that’s been stuck within a narrow range for decades. https://en.wikipedia.org/wiki/CAS_latency https://en.wikipedia.org/wiki/CAS_latency The specific implication details make a difference, but nothing is going to provide a 4x improvement in latency so other considerations take precedence. The real change is ever growing cache sizes allowing CPU’s to minimize random RAM reads.
- mantap 7y agoIs there a reason why they don't package a couple GB of DRAM in there?
- Retric 7y agoActually yes, the cache hit ratio is not linear with cache size so you get diminishing returns. http://www.dataram.com/blog/?p=112 http://www.dataram.com/blog/?p=112. On top of this, once a CPU core is operating at say 80% of the time the maximum possible speed up from more cache is 20%. Further, every layer of cache adds latency and cost as you need to check it before going to main memory. In the 486 and early pentium days External Cache was common, but it’s no longer useful.
- mantap 7y agoI had something more like a swap than a cache in mind. Expose it as additional physical address space and let the OS decide which pages live there vs main memory.
- 7y ago
- yvdriess 7y agoNope, you're at the mercy of caches to keep the beast fed.
- blattimwind 7y agoMemory latency was in the 10 ns ballpark 20 years ago and still is. This is unlikely to change unless memory is migrated to an entirely different physical storage mechanism.
- pletnes 7y agoIt takes light 1 ns to travel 30 cm (i.e. 1 standard body part / foot). So getting much faster must mean getting closer. I reckon it is only feasible if the RAM crawls into the CPU.
- jessermeyer 7y ago>I reckon it is only feasible if the RAM crawls into the CPU. reply And God said, "Let there be Cache." And there was Cache.
- earenndil 7y agoI think the proposal is to solder an entire stick of ram onto the CPU.
- magicalhippo 7y agoOr CPU onto the RAM stick... https://www.nextplatform.com/2017/02/23/promises-challenges-ahead-near-memory-memory-processing/ https://www.nextplatform.com/2017/02/23/promises-challenges-...
- yellowapple 7y agoFrom A Certain Point Of View™, this is what the RPi and SO-PINE compute modules are, except unfortunately they're no longer usable as memory modules per se.
- fgonzag 7y agoSo a level 4 cache?
- Const-me 7y ago> which is exactly the same per-core bandwidth we had in 2005. Modern CPU cores are way faster than ones in 15 years old CPUs. That 2015 processor has AMD K8 cores. I wasn’t able to find exact info, but slightly newer AMD K10 can do 8 single-precision FLOPs/cycle, at 2.8 GHz. Modern Zen2 cores can do 32 FLOPs/cycle at approximately same frequency, i.e. per-core performance improved by a factor of 4. Both numbers are theoretical limits only achieved with very specific workloads and heavy use of manual vectorization. Still, real-life general-purpose code scales quite similarly between them. CPU benchmark says their single-threaded performance improved by a factor of 3.5.
- phire 7y agoThe larger and more complex cache hierarchies will go quite far in compensating for the increased per-core performance.