> if only to understand WHY the "streaming" of data is efficient, while random-access is very inefficient.

I think what they're saying is that 99.9% of programmers don't need to know why, they just need to know that streaming access is 2-3x faster than random even without any memory stalls.

You don’t need to know any of that to know that streaming access is more efficient than random access. You just need to know that caches cache localized blocks. Actually, you don’t even need to know that. You could even just be told that streaming access is faster than random access.

This is how cargo cult programming begins.

It's called working on the relevant level of abstraction.

I am all for knowing things just to know things...but why does a programmer need to know WHY the streaming of data is efficient?

Because fundamentally, the DRAM is a major component of the computer, just as CPU cores are a major component of the computer.

Now, I'd personally explain things in a far more simple manner than what was described in the PDF. Here are the facts that programmers need to know:

1. DRAM stores data in very tiny capacitors. These tiny capacitors have two properties: they run out of electricity in just 64ms. And second, they run out of electricity after a SINGLE read operation.

2. DRAM has a temporary location called "sense amplifiers" where data is stored during a refresh or a read. These sense amplifiers can hold data permanently.

3. This "temporary read" is called Row-open (or RAS). Reading from an already open row is called a Column-read (CAS). Sending the data back to DRAM proper is called Precharge (PRE). Remember, the sense amplifiers must be clear before they can read from a new row. (The old data in DRAM was destroyed when you read it with the RAS operation)

4. I guess there's a periodic refresh you should know about: instead of trying to fix all RAM every 64ms, you're supposed to do it in small chunks at a time. Every dozen microseconds, RAM will self-read / self-write to refresh another row. Don't be surprised if your memory-reads randomly stall out an extra few hundred nanoseconds because of this refresh.

The end. Not so hard, now is it?

--------

DRAM is faster when you stream, because you open a row once, fill out all the data in a row, and then send the row back to DRAM. In effect, you only have to do a bunch of "column" writes to sense amplifiers, as opposed to opening-and-closing a bunch of different rows.

----------

So yeah, programmers should know it because its really not that hard to learn :-) And if you start measuring your program at the nanosecond level, you'll actually see these effects and start to demand explanations.

-------------

EDIT: Hmmm... the more I think of it, the less its something "programmers" need to know and something "SysAdmins / DevOps need to know". An advanced Sys Admin can use these profiler tools to figure out whether they need that 6x Memory Channel computer or the 8x Memory channel computer on the next purchase.

Is your code memory-bound? Or is it CPU bound? Should you buy more cores? Should you buy more LRDIMMs for higher amounts of RAM? Or is your program latency-bound and actually benefits from the lower latency of RDIMMs or even UDIMMs ?

The programmers kinda don't make those decisions.

I'd say this expanation merits the title "What Every Programmer Should Know", more so than the original twelve or so pages.

So, RAM is the new tape, cache is the new RAM?