3 ms·

NVMe is just a 4-lane PCIe interface with a different connector. So if that's not fast enough, it could instead go on a 8x or 16x expansion card. The question

NVMe is just a 4-lane PCIe interface with a different connector. So if that's not fast enough, it could instead go on a 8x or 16x expansion card. The question for me would be whether this is truly a drop-in replacement for either disk or RAM, or if it's something that needs to be treated as a separate peripheral while new applications are written to really take advantage of it— for example, a database that DMAs directly from permanent storage to the network with no concept of loading or caching anything in RAM.

naikrovek 5y ago
> The question for me would be whether this is truly a drop-in replacement for either disk or RAM a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. a replacement for one or another could be possible for today's machines, though. or both, if you have two devices with the correct connectors. but not both if they share address space. what does it mean for an operating system, or even an application, to "start up" when all that really means is moving data to RAM so it can be accessed quickly enough? when storage and RAM do finally converge, there will be no "boot" process in the conventional sense. you will power the device up and it will be ready instantly; everything is already "in RAM" the instant power is applied.
- staticassertion 5y ago
  Well, more than that happens when a program starts up. It's mapped in, libraries will be dynamically linked in, an address space has to be allocated, a process structure has to be allocated, memory has to be mapped as executable, etc. I don't think we would want "program on hard drive" and "program in memory" to be isomorphic for a bunch of reasons, one being security.
  - naikrovek 5y ago
    There are mitigations for the security concerns; the new architecture I envision is a new architecture, we can do things correctly and intelligently. don't let your x86 experience cloud your view of what can be done. just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. > Well, more than that happens when a program starts up. of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. > I don't think we would want "program on hard drive" and "program in memory" to be isomorphic that is one of the biggest potential reasons to use the technology in question, and one of the biggest reasons that it is being worked on.
    - staticassertion 5y ago
      > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Sure, that'd be cool, like segmentation registers. > of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. That's fair but it did seem like a central part of your point was that "starting up" was equivalent to existing on disk - though I suspect I was misreading your post.
    - chx 5y ago
      > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Heh. Everything old is new again. I think the VM/370 was the first to do this in 1972.
- rbanffy 5y ago
  > a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. The AS/400 was like that - a single address space for everything. Its descendants still do that to this day as IBM's midrange server family (right below the mainframe line). We've kind of been there with Smalltalk and image-based Lisp machines - from within the image, everything seems persistent. It's not as cool as it seemed to be back then - being able to reset to a known clean state is useful and having no distinction between what is persistent and what shouldn't be creates some interesting problems. Worth noting though that computers that had ferrite core memories worked like that. RAM contents were intact after a power loss and the original internet routers, based on the Honeywell H316, shipped with their software loaded into the core memory.
Melatonic 5y ago
I think I would be more concerned about latency vs throughput. PCIe has great latency compared to almost anything but I suspect RAM access by the CPU must be quite a bit faster edit: I did some quick searches and it does look like RAM is orders of magnitude lower latency
- mikepurvis 5y ago
  How much that matters would depend a lot on use case, though. If the scenario was a database where the data is in PCIe-connected UltraRAM and the indexes are in RAM RAM, then it would probably be fine since you'd mostly be streaming big contiguous blocks from the UltraRAM to the network. But certainly ultimately to most benefit from this kind of thing, you'd need a new architecture for it, with a new, RAM-like interface between the CPU and the unified memory backend. I'd guess we see this kind of thing first either in either niche use cases like microcontrollers, or from somewhere like Apple, since they'd have the vertical integration required to actually pull it off.
  - Melatonic 5y ago
    I guess we could just use normal ram slots assuming it could be powered and whatnot by them. Might be able to build something into the mobo microcontrollers to recognize if ram or ultraram is plugged in and then know what to use each for.
    - mikepurvis 5y ago
      It's interesting to speculate how much actual adaptation would be needed to get from a naive implementation to one that actually takes advantage of the new capabilities. Thinking of in particular of stuff like Fast Startup in Windows, which under the hood is just turning most power-on events into a restore-from-hibernate. Then again, maybe it's even simpler than that— no fancy copy-RAM-to-storage is needed if the RAM itself is persistent. Literally just power everything down, and then when you power on later, pick up from where you left off with nothing more to say about it.

naikrovek 5y ago

> The question for me would be whether this is truly a drop-in replacement for either disk or RAM a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. a replacement for one or another could be possible for today's machines, though. or both, if you have two devices with the correct connectors. but not both if they share address space. what does it mean for an operating system, or even an application, to "start up" when all that really means is moving data to RAM so it can be accessed quickly enough? when storage and RAM do finally converge, there will be no "boot" process in the conventional sense. you will power the device up and it will be ready instantly; everything is already "in RAM" the instant power is applied.

staticassertion 5y ago
Well, more than that happens when a program starts up. It's mapped in, libraries will be dynamically linked in, an address space has to be allocated, a process structure has to be allocated, memory has to be mapped as executable, etc. I don't think we would want "program on hard drive" and "program in memory" to be isomorphic for a bunch of reasons, one being security.
- naikrovek 5y ago
  There are mitigations for the security concerns; the new architecture I envision is a new architecture, we can do things correctly and intelligently. don't let your x86 experience cloud your view of what can be done. just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. > Well, more than that happens when a program starts up. of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. > I don't think we would want "program on hard drive" and "program in memory" to be isomorphic that is one of the biggest potential reasons to use the technology in question, and one of the biggest reasons that it is being worked on.
  - staticassertion 5y ago
    > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Sure, that'd be cool, like segmentation registers. > of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. That's fair but it did seem like a central part of your point was that "starting up" was equivalent to existing on disk - though I suspect I was misreading your post.
  - chx 5y ago
    > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Heh. Everything old is new again. I think the VM/370 was the first to do this in 1972.
rbanffy 5y ago
> a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. The AS/400 was like that - a single address space for everything. Its descendants still do that to this day as IBM's midrange server family (right below the mainframe line). We've kind of been there with Smalltalk and image-based Lisp machines - from within the image, everything seems persistent. It's not as cool as it seemed to be back then - being able to reset to a known clean state is useful and having no distinction between what is persistent and what shouldn't be creates some interesting problems. Worth noting though that computers that had ferrite core memories worked like that. RAM contents were intact after a power loss and the original internet routers, based on the Honeywell H316, shipped with their software loaded into the core memory.

Melatonic 5y ago

I think I would be more concerned about latency vs throughput. PCIe has great latency compared to almost anything but I suspect RAM access by the CPU must be quite a bit faster edit: I did some quick searches and it does look like RAM is orders of magnitude lower latency

mikepurvis 5y ago
How much that matters would depend a lot on use case, though. If the scenario was a database where the data is in PCIe-connected UltraRAM and the indexes are in RAM RAM, then it would probably be fine since you'd mostly be streaming big contiguous blocks from the UltraRAM to the network. But certainly ultimately to most benefit from this kind of thing, you'd need a new architecture for it, with a new, RAM-like interface between the CPU and the unified memory backend. I'd guess we see this kind of thing first either in either niche use cases like microcontrollers, or from somewhere like Apple, since they'd have the vertical integration required to actually pull it off.
- Melatonic 5y ago
  I guess we could just use normal ram slots assuming it could be powered and whatnot by them. Might be able to build something into the mobo microcontrollers to recognize if ram or ultraram is plugged in and then know what to use each for.
  - mikepurvis 5y ago
    It's interesting to speculate how much actual adaptation would be needed to get from a naive implementation to one that actually takes advantage of the new capabilities. Thinking of in particular of stuff like Fast Startup in Windows, which under the hood is just turning most power-on events into a restore-from-hibernate. Then again, maybe it's even simpler than that— no fancy copy-RAM-to-storage is needed if the RAM itself is persistent. Literally just power everything down, and then when you power on later, pick up from where you left off with nothing more to say about it.