11–19 of 19 posts
This comes up over and over. It's great. But, the 75% of useful content comes after 25% of diving way too deep into the details of the electrical engineering. "Every programmer" should know the orders of magnitude of cache hierarchy latencies, how RAM loads a whole cache line to service that single byte you requested, roughly how the automatic prefetcher thinks, that MESI and NUMA access are a growing issue, that the…
Any resources on where i can read up on these ?
This comes up over and over. It's great. But, the 75% of useful content comes after 25% of diving way too deep into the details of the electrical engineering. "Every programmer" should know the orders of magnitude of cache hierarchy latencies, how RAM loads a whole cache line to service that single byte you requested, roughly how the automatic prefetcher thinks, that MESI and NUMA access are a growing issue, that the…
on modern systems the memory controller interfaces between the memory network and the DRAM. I wouldn't say the CPU/NIC or CPU/storage boundary touches the memory controller (except if its writing to memory)
It is possible for the PCI host bridge DMAs to load and store into caches, but in practice it can be difficult if not impossible to line everything up so the data is in cache when it is required, because of the data throughput and pipelining (many parallel pipelines) latency variations even on local NAND devices, etc.
Maybe you get your command/complete rings from cache (which would be nice since they have to come in order and the CPU has to operate on), but it's very hard to get all your data served by the caches.
The old favorite netflix serving talks show this
This comes up over and over. It's great. But, the 75% of useful content comes after 25% of diving way too deep into the details of the electrical engineering. "Every programmer" should know the orders of magnitude of cache hierarchy latencies, how RAM loads a whole cache line to service that single byte you requested, roughly how the automatic prefetcher thinks, that MESI and NUMA access are a growing issue, that the…
on modern systems the memory controller interfaces between the memory network and the DRAM. I wouldn't say the CPU/NIC or CPU/storage boundary touches the memory controller (except if its writing to memory)
1) Reading and writing to memory addresses in such a way as to be interpreted by the memory controller to forward those actions to/from the PCI bus and other systems. That forwarding being controlled by reading and writing to addresses in a way that the MC interprets as commands to configure itself.
2) Ports -- which still exist for legacy reasons, but are long out of fashion.
What's #3?
Earlier quoted context omitted.
on modern systems the memory controller interfaces between the memory network and the DRAM. I wouldn't say the CPU/NIC or CPU/storage boundary touches the memory controller (except if its writing to memory)
My limited understanding is that the CPUs have two most-common interfaces to the rest of the system: 1) Reading and writing to memory addresses in such a way as to be interpreted by the memory controller to forward those actions to/from the PCI bus and other systems. That forwarding being controlled by reading and writing to addresses in a way that the MC interprets as commands to configure itself. 2) Ports -- which…
x86 has "ports". I don't know about modern implementations but I would guess they are done with MMIO out the back end of the core (e.g., the CPU turns inb/outb instructions into accesses to special memory ranges).
Either way MMIO is the way to configure devices.
DMA is how to move data between device and CPU or devices. But nowadays with high performance devices, you don't set up a request and then send a MMIO command to process that request, and then get an interrupt and do a MMIO to get completion status of the command. The commands and completions themselves are DMA'ed. So you have ring buffers (multiple for a multi queue or virtualized device) for commands and completions which get DMAed. You do the MMIOs and interrupts only to manage starting and stopping (fill, empty, etc) conditions of the queues.
DMAs can go direct to caches in some architectures, but as I said L3 caches are only so large, and data volumes so large that it can be hard to arrange. You would hope your queues are mostly cached at least, but in reality I don't know if that actually happens well.
This comes up over and over. It's great. But, the 75% of useful content comes after 25% of diving way too deep into the details of the electrical engineering. "Every programmer" should know the orders of magnitude of cache hierarchy latencies, how RAM loads a whole cache line to service that single byte you requested, roughly how the automatic prefetcher thinks, that MESI and NUMA access are a growing issue, that the…
You don't need to know the DRAM timing stuff, technically, but it doesn't hurt to learn something new.
The actual problem with this doc is that it was written a very long time ago so although most things are very very true still a few things (like everything on the quality of prefetching techniques should be taken with a large grain of salt)
Hennessey and Patterson is still good but there's only like 1 alternative, and the most up to date "complete" book on memory I'm aware of is from 2007 (Jacobs et al).
Also: I've read about memory quite bit, I get it. What I don't get, and am thus asking for recommendations for is: "What every programmer should know about storage".
This is from 2007! Still somewhat relevant though.
If you have a 114-page paper, you probably don't have a document of what every programmer should know about memory, especially since many programmers work in domains where some of the recommendations here aren't even possible to follow! Here's a brief summary of what every programmer really needs to know about memory: * There is a hierarchy of memory from fast-but-small to slow-but-large. The smallest and fastest is…
You have to know something about consistency. You don't need to know the details but you need to know enough to know you don't know enough to write your own synchronization primitives or lock free algorithms, at least.