4 ms·

What every programmer should know about memory, Part 1 (2007)

90 points by kercker 9y ago

FrankyHollywood 9y ago
This one is also very usefull: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/ http://igoro.com/archive/volatile-keyword-in-c-memory-model-...
ACow_Adonis 9y ago
Out of curiosity, can any hacker news types quickly tell me if there's been any significant developments since this paper was authored that a programmer should fundamentally consider these days?
- deleted 9y ago
  [deleted]
- pjc50 9y ago
  It's generally sound and the latency problems have if anything got more acute. The block diagrams about architecture are a little out of date now we're past Nehelem. See http://www.ni.com/white-paper/11266/en/ http://www.ni.com/white-paper/11266/en/ We have DDR5 now; see JEDEC for the details.
- cdoxsey 9y ago
  Yes. Persistent memory: http://pmem.io http://pmem.io. This a storage medium accessible like memory and much faster than traditional disks. It blurs the line between memory and disk and will fundamentally alter the way we build systems. For example you may no longer need a leveldb or sqlite disk store, you could just use plain data structures in persistent memory. An early version is currently available with i3 instances on Amazon. Expect to hear more about this in the next few years.
  - jawilson2 9y ago
    I'm more interested in what is actually being used right now, e.g. if I am deploying to a bunch of Skylake processors, what has changed?
  - gwbas1c 9y ago
    Oh gosh no! We already have something similar with memory mapped files. The original .doc format was just Word's data structures shoved in a memory-mapped file. That's why it was so hard to make 3rd party applications compatible. Serialization, like xml or SQLite, is needed to ensure that a file format is interoperable among different programs and different versions of your program. How can you add a field to a data structure in version 2 when your data structures are so tightly coupled to your persistent data? Furthermore, things like SQLite offer indexing that lets you find data without needing to traverse all your RAM in a foreach loop. It abstracts away your application's data's format from the algorithm needed to access it quickly. And finally, what happens when your program crashes? What if your data structures are in a bad state, or corrupt? What about transactional integrity? How do you abstract your pointers, because the addresses of your structures will change the next time around. I suspect that SQLite (and similar) will have updates that take advantage of persistent memory. (Edit) I also suspect that persistent memory will help lower power consumption. A device could go into a kind of a sleep mode much more easily if it didn't need to page in and out its memory.
- abainbridge 9y ago
  > All CPUs (two in the previous example, but there can be more) are connected via a common bus (the Front Side Bus, FSB) to the Northbridge. This is very out of date. The Northbridge was pushed onto the CPU die about the time that the article was written (2007). I'm not sure exactly what consequence that has but I suspect it invalidates a large chunk of the discussion. Modern memory controllers (which are on the CPU die and evolved out of what used to be the Northbridge) have various fancy features that weren't available in 2007. For examples: 1. DDIO. Without this, when a PCIe device DMAs data into system RAM, you are very likely to get a cache miss when the CPU reads the data because the data was written into DRAM and not the CPU cache. DDIO writes it into the CPU cache. This is quite important for modern networking, where the packet interval can be less than the time taken for a cache miss. (https://www.intel.co.uk/content/www/uk/en/io/data-direct-i-o-technology.html https://www.intel.co.uk/content/www/uk/en/io/data-direct-i-o...) 2. These days a single CPU has many cores, hyperthreading and deep-speculative execution abilities. As a result, the CPU can post many reads into the memory subsystem in parallel. The memory controller keeps a table of who's reading what, so that it can optimize DRAM access - eg two independent reads can be scheduled together if they happen to target the same DRAM row. Checkout my boring question on Stackoverflow (https://stackoverflow.com/questions/45382914/parallel-memory-access-on-modern-processors https://stackoverflow.com/questions/45382914/parallel-memory...).
  - zdw 9y ago
    The Northbridge/FSB section is there for historical context - immediately after he covers CPU-attached memory and NUMA.
    - abainbridge 9y ago
      Yes. Sorry. Didn't read enough. I think my two examples of stuff-that's-new-since-then remain valid.
rimher 9y ago
Good idea to splice it up, makes it easier to tackle. Link to full pdf by the way: http://futuretech.blinkenlights.nl/misc/cpumemory.pdf http://futuretech.blinkenlights.nl/misc/cpumemory.pdf
kuharich 9y ago
Prior discussion: http://news.ycombinator.com/item?id=1394346 http://news.ycombinator.com/item?id=1394346
dang 9y ago
https://hn.algolia.com/?query=What%20every%20programmer%20should%20know%20about%20memory%20points%3E20&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0 https://hn.algolia.com/?query=What%20every%20programmer%20sh...

90 points by kercker 9y ago

This one is also very usefull: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/ http://igoro.com/archive/volatile-keyword-in-c-memory-model-...

ACow_Adonis 9y ago

Out of curiosity, can any hacker news types quickly tell me if there's been any significant developments since this paper was authored that a programmer should fundamentally consider these days?

deleted 9y ago
[deleted]
pjc50 9y ago
It's generally sound and the latency problems have if anything got more acute. The block diagrams about architecture are a little out of date now we're past Nehelem. See http://www.ni.com/white-paper/11266/en/ http://www.ni.com/white-paper/11266/en/ We have DDR5 now; see JEDEC for the details.
cdoxsey 9y ago
Yes. Persistent memory: http://pmem.io http://pmem.io. This a storage medium accessible like memory and much faster than traditional disks. It blurs the line between memory and disk and will fundamentally alter the way we build systems. For example you may no longer need a leveldb or sqlite disk store, you could just use plain data structures in persistent memory. An early version is currently available with i3 instances on Amazon. Expect to hear more about this in the next few years.
- jawilson2 9y ago
  I'm more interested in what is actually being used right now, e.g. if I am deploying to a bunch of Skylake processors, what has changed?
- gwbas1c 9y ago
  Oh gosh no! We already have something similar with memory mapped files. The original .doc format was just Word's data structures shoved in a memory-mapped file. That's why it was so hard to make 3rd party applications compatible. Serialization, like xml or SQLite, is needed to ensure that a file format is interoperable among different programs and different versions of your program. How can you add a field to a data structure in version 2 when your data structures are so tightly coupled to your persistent data? Furthermore, things like SQLite offer indexing that lets you find data without needing to traverse all your RAM in a foreach loop. It abstracts away your application's data's format from the algorithm needed to access it quickly. And finally, what happens when your program crashes? What if your data structures are in a bad state, or corrupt? What about transactional integrity? How do you abstract your pointers, because the addresses of your structures will change the next time around. I suspect that SQLite (and similar) will have updates that take advantage of persistent memory. (Edit) I also suspect that persistent memory will help lower power consumption. A device could go into a kind of a sleep mode much more easily if it didn't need to page in and out its memory.
abainbridge 9y ago
> All CPUs (two in the previous example, but there can be more) are connected via a common bus (the Front Side Bus, FSB) to the Northbridge. This is very out of date. The Northbridge was pushed onto the CPU die about the time that the article was written (2007). I'm not sure exactly what consequence that has but I suspect it invalidates a large chunk of the discussion. Modern memory controllers (which are on the CPU die and evolved out of what used to be the Northbridge) have various fancy features that weren't available in 2007. For examples: 1. DDIO. Without this, when a PCIe device DMAs data into system RAM, you are very likely to get a cache miss when the CPU reads the data because the data was written into DRAM and not the CPU cache. DDIO writes it into the CPU cache. This is quite important for modern networking, where the packet interval can be less than the time taken for a cache miss. (https://www.intel.co.uk/content/www/uk/en/io/data-direct-i-o-technology.html https://www.intel.co.uk/content/www/uk/en/io/data-direct-i-o...) 2. These days a single CPU has many cores, hyperthreading and deep-speculative execution abilities. As a result, the CPU can post many reads into the memory subsystem in parallel. The memory controller keeps a table of who's reading what, so that it can optimize DRAM access - eg two independent reads can be scheduled together if they happen to target the same DRAM row. Checkout my boring question on Stackoverflow (https://stackoverflow.com/questions/45382914/parallel-memory-access-on-modern-processors https://stackoverflow.com/questions/45382914/parallel-memory...).
- zdw 9y ago
  The Northbridge/FSB section is there for historical context - immediately after he covers CPU-attached memory and NUMA.
  - abainbridge 9y ago
    Yes. Sorry. Didn't read enough. I think my two examples of stuff-that's-new-since-then remain valid.

rimher 9y ago

Good idea to splice it up, makes it easier to tackle. Link to full pdf by the way: http://futuretech.blinkenlights.nl/misc/cpumemory.pdf http://futuretech.blinkenlights.nl/misc/cpumemory.pdf

kuharich 9y ago

Prior discussion: http://news.ycombinator.com/item?id=1394346 http://news.ycombinator.com/item?id=1394346

dang 9y ago

https://hn.algolia.com/?query=What%20every%20programmer%20should%20know%20about%20memory%20points%3E20&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0 https://hn.algolia.com/?query=What%20every%20programmer%20sh...