Intel's roadmap for Optane SSDs with 1,000x performance

Short term, the disk controller becomes a peripheral on the memory bus. On a 64-bit x86-64 system, the top 16 bits of the address are either 0000 or ffff for RAM. Make it so that the prefix 1000 (for example) maps to the disk, so accessing (physical) address 1000000013371000 accesses byte 13371000 on the disk.

Now processes can just ask the OS to perform a physical memory mapping to obtain a range of virtual addresses directly backed by disk pages, with page protections set based on their filesystem permissions. Such physical address mapping interfaces already exists in most OSes to support memory mapped I/O (for example, mapping /dev/mem in Linux).

This addressing scheme has another advantage: other devices on the system can use e.g. DMA to directly talk to the disk without any CPU intervention. For example, the GPU could load textures straight off of disk, just like John Carmack wants.

Medium term, we start rethinking the filesystem. If we make the address range for a given disk completely persistent, we can just put pointers to disk bytes on the disk itself. Processes will use the same virtual addresses as the physical addresses when talking to the disk. Suddenly "serialization" to disk is no longer required: data structures can be stored in native form directly on the disk. Imagine having a "dmalloc" function call hand you a chunk of persistent storage which you treat the same as any memory, but which can outlive the process. Similar concepts exist in some languages (like MUMPS), and now we bring the idea to all programming environments.

Long term, RAM ceases to be an independent entity, and merely becomes OS-managed cache for the big persistent storage (assuming it still has any latency/bandwidth advantages by this point). Now you can get rid of the notion of "shutting down" or "starting up" the system: everything is persistent. Without having to constantly refresh DRAM to keep the system alive, devices can "sleep/hibernate" more frequently and readily, saving significant power. Programming models become nearly unrecognizable as old models of memory management and process lifetimes give way to new models of persistent storage management and eternal services.

We're not far off from seeing a potential revolution in computing here.

I believe that they are using fairly best-case latency numbers, under the assumption that the memory accesses are close to sequential. For random memory accesses, as you note, the latencies are higher. Unfortunately the article doesn't go into detail on what Optane's worst-case latencies are, nor what the latencies will be like in a real functional system (mostly because Intel has only early prototypes to show).

The second thing is that Intel has been claiming multiple GB/second of throughput as well. They really do believe this will be a replacement for DRAM on some platforms. As in you read into your L3 case from this stuff and you flush to it when you write out a dirty cache lines. And while that will make the overall system slower, it gives it literally instant stop/start capability if the key parts of your architecture are static (can retain data at 0 clock). What that means is a laptop that can turn it self off between waiting for sectors to read in from the disk or packets to come off the network, or keys to be pressed by the user. Non-illuminated run times in days off of a battery source rather than hours.

Imagine a 1.2TB of this stuff on the motherboard substituting for DRAM. So you've got every application and all the data for your applications already "in memory" as far as the chip is concerned. App switching? Instant, app data availability? instant. Quite a different experience than what we have today.

A similar approach has been taken with HP's interesting memristor-based "Machine"

There's a lot of interesting stuff in Organick's book on Multics, not all of which was implemented, unfortunately. And a lot of really good stuff was tossed overboard when fitting Unix into a PDP-7 (a lot of overwrought bad stuff was jettisoned too -- don't get the wrong idea!).