6 ms·

Finally. This has been expected for a long time, we've grown so used to the traditional idea of storage tiers.. When I can have 4 TiB of non-volatile system mem

by dusted 5y ago

Finally. This has been expected for a long time, we've grown so used to the traditional idea of storage tiers.. When I can have 4 TiB of non-volatile system memory, the implications are significant. No longer will we need to "load" things, there'd be no reason to copy an executable or resource from the filesystem into memory to use it, it can be executed, used and modified directly where it is. This is wonderful for a great many things. A system native to this type of memory may be divided into "permanent" and "scratch" storage. So if you create a new file, you do something of a named allocation, and operate directly in that buffer, and allocate another unnamed (scratch) buffer for the undo/redo stuff. Now there's no longer a save button, since there is only the one instance of your file. Sure, reallocation and stuff will need to be convenient, probably you could have a convenient, but that's a small issue to fix. Then there's boot times, powering off? save PC and registers to some predetermined place, powering on: load them, and you're ready to continue, literally no boot time.. No reason to put the system to "sleep" you can power it on and off within a few clock cycles. Add a framebuffer on the display, or something like eink, together with "power up on input" and you get enourmous power-savings and battery life

zamadatix 5y ago
You will always have storage tiers. The main technical divider between tiers is latency, even if the same way of storing bits becomes the best way for all storage you'll still have tiny low latency cache, small latency small local storage, and enormous latency but enormously sized remote storage. Inside those latency tiers you'll still have cheap lower speed options and expensive higher speed options. This is true even if they use the same technology to store the actual bits as there is more to storage than that. Even non-volatility just falls into cost tiering, 4 TBs of battery backed RAM storage with somewhere to dump quick when the power goes out is a cost consideration vs 4 TBs of non-volatile RAM like storage.
- corysama 5y ago
  There was a paper a few years back that came down to "Given a large enough active address space and a random enough access pattern, randomly accessing N addresses becomes an O(N log N) operation in practice because of TLB cache hierarchy. This penalty does not appear to be avoidable in the long run."
  - continuational 5y ago
    Corollary: Constant time random access data structures don't exist.
  - bee_rider 5y ago
    And in the long-long run we'll always have a latency of at least 2r/c to randomly access memory elements within a radius r of our compute elements!
    - pishpash 5y ago
      Which is why distributed local compute is the future! The real tradeoff is between compute vs. communication.
      - bee_rider 5y ago
        Plus, MPI is way cooler than OpenMP.
  - magicalhippo 5y ago
    This reminds me of the ZFS talk where they note that if you have enough clients doing sequential IO, it looks like random IO to the server. https://youtu.be/yHgSU6iqrlE?t=2577 https://youtu.be/yHgSU6iqrlE?t=2577
  - labawi 5y ago
    While just about any "constant-time" operation gets a log N factor, given large enough N, the TLB issue is mostly surmountable. Assuming you do want to keep using virtual memory, you can not-simply¹ use huge pages and avoid the log N TLB factor. Which is a big thing, because TLB misses are very costly, so it can be worth it, even though you are giving up a lot of the paged-memory benefits. ¹ Lots of limitations and caveats. Your MMU needs big enough pages with a reasonable amount of TLB entries. Managing memory becomes more difficult. Your CPU likely has few large TLB entries, so only certain size ranges fit, etc.
nine_k 5y ago
What takes most time when suspending a laptop now, AFAICT, is powering down various I/O devices, and giving software some time to react to that. A system where RAM is non-volatile can have great many computations running concurrently. No need to "start" a program, its running state just stays since the last time. You may need to sometimes restart a program from a known good state, if things go wrong. Also, all the undo info (subject to space limits) is persisted and available whenever needed. All the auxiliary structures for a document / picture / code you work on just live next to them, are them. To send a document, you export it to an accepted format, detaching from the in-program representation.
- wizzwizz4 5y ago
  We can have this architecture today. Writing an OS is hard, though.
  - nine_k 5y ago
    Halfway, I'd say, because even if NVMe is fast, it's not that fast. For instance, an IDE, instead of keeping the parse trees in RAM, has to use a database on a disk for persistence, while caching a hot subset in RAM for speed. When all of your disk becomes RAM disk, only persistent, things already change in interesting ways. But hardware based on a persistent-RAM-only design would definitely need a very different OS. (With a Linux compatibility layer, inevitably, though.)
- spitfire 5y ago
  So like a smalltalk or lisp based image system. I’m down for that.
- inetknght 5y ago
  > What takes most time when suspending a laptop now, AFAICT, is powering down various I/O devices, and giving software some time to react to that. tbqh that's a problem with software design. It's better to just power down devices and not let software react. That would force software to handle unexpected failures much more gracefully and we'd all be better for it.
causality0 5y ago
We had that back in the day with Palm and Pocket PC. It was terrible. Not only will good developers have no idea how much memory to expect to have, the bad ones will assume infinite memory and make no effort at efficiency at all. I have zero interest in a software ecosystem where one program expects me to have eight gigabytes of free memory and another expects 512.
petra 5y ago
This article didn't mention density/cost. That's a key reason why we still use storage. So let's wait and see.
austincheney 5y ago
I am writing a shared file system application such that an OS like GUI displays the file system of various machines. Reading a large file system volume takes longer than transferring a data structure of that system across a fast network. A file system executing at RAM speed would fundamentally alter perceptions of distribution and thus decentralization.
egypturnash 5y ago
A system built like this sounds like a massive failure waiting to happen. For example: Once upon a time, back around the turn of the century, I worked in animation. Primarily with Flash. After upgrading to Flash 5 we discovered some killer bugs in it related to huge files; when working with the files created by putting everyone's scenes together into one file to do final polish and prep for outputting a .swf, after a few days of that, it would reliably crash within a few minutes of work. And it would crash so hard that it left something behind that made it impossible to just swear, launch Flash again, and get back to work; these crashes could only be remedied by a full reboot. I was the Flash director of the episode we discovered this and I had a very unpleasant week trying to beat that damn thing into a shippable shape. We'd already worked around some other bugs where Flash slowly trashed its working copies of files; it was standard procedure to regularly save as a new file, close, and re-open, as this seemed to make a lot of cleanup happen that wouldn't happen with a normal save. This had the bonus of giving us a lot of versioned backups to dig through in the event of file corruption or accidental deletion of some important part of it. Which is a thing that can easily happen when you have about a dozen people trying to crank out several minutes of animation on a weekly schedule. I no longer work with Flash but I have certainly experienced my share of data loss due to my big, complex tools with massive codebases that are older than half the people now working on them getting into weird states. The habits I built back then of saving regularly mean that I rarely lose more than a few minutes of work, instead of potentially losing every hour I spent on a complex file because there is no more distinction between a file 'in memory' and 'on disc'.
- pishpash 5y ago
  You'll still need snapshotted backups. Some storage may be devoted to that.
ivegotnoaccount 5y ago
I don't think I would like such a system that maps everything directly to memory. At least, with the current separation, if some program's or even the kernel's memory gets corrupted, I can just restart my computer and it will usually fix it, whereas using an NVRAM in such a way could make it easier to break things in a durable fashion.

by dusted 5y ago

zamadatix 5y ago

You will always have storage tiers. The main technical divider between tiers is latency, even if the same way of storing bits becomes the best way for all storage you'll still have tiny low latency cache, small latency small local storage, and enormous latency but enormously sized remote storage. Inside those latency tiers you'll still have cheap lower speed options and expensive higher speed options. This is true even if they use the same technology to store the actual bits as there is more to storage than that. Even non-volatility just falls into cost tiering, 4 TBs of battery backed RAM storage with somewhere to dump quick when the power goes out is a cost consideration vs 4 TBs of non-volatile RAM like storage.

corysama 5y ago
There was a paper a few years back that came down to "Given a large enough active address space and a random enough access pattern, randomly accessing N addresses becomes an O(N log N) operation in practice because of TLB cache hierarchy. This penalty does not appear to be avoidable in the long run."
- continuational 5y ago
  Corollary: Constant time random access data structures don't exist.
- bee_rider 5y ago
  And in the long-long run we'll always have a latency of at least 2r/c to randomly access memory elements within a radius r of our compute elements!
  - pishpash 5y ago
    Which is why distributed local compute is the future! The real tradeoff is between compute vs. communication.
    - bee_rider 5y ago
      Plus, MPI is way cooler than OpenMP.
- magicalhippo 5y ago
  This reminds me of the ZFS talk where they note that if you have enough clients doing sequential IO, it looks like random IO to the server. https://youtu.be/yHgSU6iqrlE?t=2577 https://youtu.be/yHgSU6iqrlE?t=2577
- labawi 5y ago
  While just about any "constant-time" operation gets a log N factor, given large enough N, the TLB issue is mostly surmountable. Assuming you do want to keep using virtual memory, you can not-simply¹ use huge pages and avoid the log N TLB factor. Which is a big thing, because TLB misses are very costly, so it can be worth it, even though you are giving up a lot of the paged-memory benefits. ¹ Lots of limitations and caveats. Your MMU needs big enough pages with a reasonable amount of TLB entries. Managing memory becomes more difficult. Your CPU likely has few large TLB entries, so only certain size ranges fit, etc.

nine_k 5y ago

What takes most time when suspending a laptop now, AFAICT, is powering down various I/O devices, and giving software some time to react to that. A system where RAM is non-volatile can have great many computations running concurrently. No need to "start" a program, its running state just stays since the last time. You may need to sometimes restart a program from a known good state, if things go wrong. Also, all the undo info (subject to space limits) is persisted and available whenever needed. All the auxiliary structures for a document / picture / code you work on just live next to them, are them. To send a document, you export it to an accepted format, detaching from the in-program representation.

wizzwizz4 5y ago
We can have this architecture today. Writing an OS is hard, though.
- nine_k 5y ago
  Halfway, I'd say, because even if NVMe is fast, it's not that fast. For instance, an IDE, instead of keeping the parse trees in RAM, has to use a database on a disk for persistence, while caching a hot subset in RAM for speed. When all of your disk becomes RAM disk, only persistent, things already change in interesting ways. But hardware based on a persistent-RAM-only design would definitely need a very different OS. (With a Linux compatibility layer, inevitably, though.)
spitfire 5y ago
So like a smalltalk or lisp based image system. I’m down for that.
inetknght 5y ago
> What takes most time when suspending a laptop now, AFAICT, is powering down various I/O devices, and giving software some time to react to that. tbqh that's a problem with software design. It's better to just power down devices and not let software react. That would force software to handle unexpected failures much more gracefully and we'd all be better for it.

causality0 5y ago

We had that back in the day with Palm and Pocket PC. It was terrible. Not only will good developers have no idea how much memory to expect to have, the bad ones will assume infinite memory and make no effort at efficiency at all. I have zero interest in a software ecosystem where one program expects me to have eight gigabytes of free memory and another expects 512.

petra 5y ago

This article didn't mention density/cost. That's a key reason why we still use storage. So let's wait and see.

austincheney 5y ago

I am writing a shared file system application such that an OS like GUI displays the file system of various machines. Reading a large file system volume takes longer than transferring a data structure of that system across a fast network. A file system executing at RAM speed would fundamentally alter perceptions of distribution and thus decentralization.

egypturnash 5y ago

A system built like this sounds like a massive failure waiting to happen. For example: Once upon a time, back around the turn of the century, I worked in animation. Primarily with Flash. After upgrading to Flash 5 we discovered some killer bugs in it related to huge files; when working with the files created by putting everyone's scenes together into one file to do final polish and prep for outputting a .swf, after a few days of that, it would reliably crash within a few minutes of work. And it would crash so hard that it left something behind that made it impossible to just swear, launch Flash again, and get back to work; these crashes could only be remedied by a full reboot. I was the Flash director of the episode we discovered this and I had a very unpleasant week trying to beat that damn thing into a shippable shape. We'd already worked around some other bugs where Flash slowly trashed its working copies of files; it was standard procedure to regularly save as a new file, close, and re-open, as this seemed to make a lot of cleanup happen that wouldn't happen with a normal save. This had the bonus of giving us a lot of versioned backups to dig through in the event of file corruption or accidental deletion of some important part of it. Which is a thing that can easily happen when you have about a dozen people trying to crank out several minutes of animation on a weekly schedule. I no longer work with Flash but I have certainly experienced my share of data loss due to my big, complex tools with massive codebases that are older than half the people now working on them getting into weird states. The habits I built back then of saving regularly mean that I rarely lose more than a few minutes of work, instead of potentially losing every hour I spent on a complex file because there is no more distinction between a file 'in memory' and 'on disc'.

pishpash 5y ago
You'll still need snapshotted backups. Some storage may be devoted to that.

ivegotnoaccount 5y ago

I don't think I would like such a system that maps everything directly to memory. At least, with the current separation, if some program's or even the kernel's memory gets corrupted, I can just restart my computer and it will usually fix it, whereas using an NVRAM in such a way could make it easier to break things in a durable fashion.