3 ms·
This is a great question. One way I imagine it: Short term, the disk controller becomes a peripheral on the memory bus. On a 64-bit x86-64 system, the top 16 b
by nneonneo 10y ago
This is a great question. One way I imagine it:
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.
- imtringued 10y ago>Suddenly "serialization" to disk is no longer required That's not true. You'd still want excel to just save your sheets as xls file and show it to a coworker as opposed to sharing the entire excel program state. Upgrading from one version to another also requires a stable persistent data format for things such as configurations. Not to mention that you still need serialization to communicate over a network.
- nneonneo 10y agoYes, you're definitely right - "serialization" as a concept is going to still be needed for data interchange. I just didn't want to mention it because that's just status quo, not part of the new computing model. In my original comment, I simply meant that you would no longer have to serialize your data to your own disk.
- yourapostasy 10y agoThat's almost a weird amalgam of really old school computer architectures and new. It seemed to me from the layperson descriptions of how the old tube-based systems were operated, some of the old architectures had no notion of files at all, it was all RAM all the time. I also read stories of when rotating media first started being used, programmers wrote data not sequentially on the media but in an optimized pattern so by the time the cpu pulled a value into RAM the read head was positioned multiple units over, and so data was written out according to the demands of the hardware, and now we're talking about taking the cpu out of most of the loop. We aren't coming full circle with the new memory architectures we're exploring, but kind of a spiral in a "history doesn't repeat but rhymes" manner by dusting off some old techniques and putting new spins on them, pun not intended. If always-persistent state becomes popular, then I wonder if that will revive the popularity of image-based environments, a la Smalltalk and Lisp Machines, along with the collaboration challenges those introduced.