What every programmer should know about memory, Part 1 (2007)
lwn.net
lwn.net
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/
We have DDR5 now; see JEDEC for the details.
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.
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.
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...)
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...).
Link to full pdf by the way: http://futuretech.blinkenlights.nl/misc/cpumemory.pdf