13 ms·

UltraRAM: 'Universal Memory' That Brings RAM-Like Speed to Non-Volatile Storage

245 points by pulse7 5y ago

dekhn 5y ago
I'd rather I could just add a battery to RAM and use that as nv storage. I have seen (production, heavy load) systems that do this (RAMSAN is an example).
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.
lichtenberger 5y ago
I wonder if it's faster than Intel Optane DC Memory and if that's the deciding advantage, such that no additional volatile DRAM is needed: https://news.ycombinator.com/item?id=29906049 https://news.ycombinator.com/item?id=29906049
- imachine1980_ 5y ago
  if the cost is low you can opt out of the catche layer whoiut big performace drops, reducing the complexity
avidphantasm 5y ago
With endurance of 100x to 1000x that of flash, this seem like it would be a poor replacement for DRAM (but definitely a good replacement for flash and spinning disks, depending on the cost/GB). I searched, but could not find any obvious/easily accessible endurance summaries for DRAM (which I realized I had never given much thought). Does anyone know of any good sources for this?
- jeffbee 5y ago
  DRAM doesn't have program/erase wear-out. The device is essentially a capacitor. There is no endurance limit for tiny capacitors. DRAM does have a retention limit, only a few milliseconds. That's a drawback.
  - pitaj 5y ago
    There is an endurance limit for any sufficiently small electronic device. Electromigration. With capacitors specifically, dielectric will eventually fail.
    - deleted 5y ago
      [deleted]
    - jeffbee 5y ago
      OK, but they don't wear out from that based on write cycles, they would wear out from that based on power-on hours.
lichtenberger 5y ago
BTW: if someone is interested to contribute or use the project... my open source project, an evolutionary, immutable JSON data store will benefit from fast random, fine granular access to durable storage as it has to read scattered word aligned page fragments from random locations in an append-only file in parallel to reconstruct a full page in-memory. The crux is that SirixDB is storing a huge persistent tree of tries index over revisions plus user defined indexes, a path summary and shared object fields in one log-structured appended only file. It does not simply copy whole database pages, but mainly stores only changed records/nodes. So it mainly stores the whole index in one file (append-only) plus an offset file to map timestamps to revision offsets (besides the 32bit revision numbers / revisions stored in the main file). This means that we can store checksums of the child db pages in parent pages as in ZFS and to store the checksum of the UberPage in the page itself to validate the whole resource and we don't need a seperate transaction log despite an in memory cache for the single read-write trx. https://github.com/sirixdb/sirix https://github.com/sirixdb/sirix and a query processor called Brackit for document stores based on a JSONiq like query language: https://github.com/sirixdb/brackit https://github.com/sirixdb/brackit
hinkley 5y ago
> program-erase cycling endurance is "one hundred to one thousand times better than flash." That is still not enough write operations to let anyone treat this like a bigger version of RAM, is it?
- baybal2 5y ago
  Which means 10^12 to 10^13. SRAM needs 10^20 DRAM 10^17 Any memory exploiting variable dielectric properties is subject to dielectric failure.
  - thoughtsimple 5y ago
    According to the conclusion in the white paper, they tested for endurance only to 10^7 with no degradation. Obviously that is not enough for a real system.
  - wolverine876 5y ago
    Do you know good sources on that? Thanks.
  - pishpash 5y ago
    Right, there are physical limitations to how physical states can be altered (density, speed, energy) with enough persistence against entropic decay. Persistence is an abstraction to push the renewal burden onto backup maintainers. I'd much rather see work directed towards a self-repairing style of persistence.
  - after_care 5y ago
    Without constantly loading cached data into dram the number of writes to it would be significantly lower.
jeffbee 5y ago
This is a semiconductor physics paper, not a computer architecture paper, and it doesn't make any kind of claims that would support the statement of "DRAM-like speed". They can erase their enormous single-bit device in 5ms, which is forever. The features are 1000s of times larger than current silicon DRAM. It also has endurance of only 10^7 erase cycles, which a computer could exhaust in a split second, if the device were fast enough. The interesting thing here is the non-volatility for this type of structure on Si instead of GaAs.
nynx 5y ago
As people are saying, the read/write endurance doesn't seem like enough to replace DRAM, but this would be a _fantastic_ replacement for flash (and the long-term data endurance seeems awesome).
- lichtenberger 5y ago
  For servers there's already Intel Optane DC Memory and it's not fast enough to replace volatile memory in most cases, but way faster than flash drives. Thus, UltraRAM might have no real benefit? Maybe we'll have to wait, also regarding the cost factor.
conductor 5y ago
I think it's at least a decade since Texas Instruments introduced the FRAM series of their MSP430 microcontrollers [0]. Good to know there are efforts to bring such technologies to "bigger" computers - having TBs of RAM in your laptop must be fun. [0] https://en.wikipedia.org/wiki/TI_MSP430#FRAM_series https://en.wikipedia.org/wiki/TI_MSP430#FRAM_series
arghnoname 5y ago
We've had a variant of this in the form of intel's persistent memory (named Octane DC memory or something stupid like this). It's addressable like RAM, but persistent. Performance is not quite that of DRAM (within an order of magnitude), but reads and writes go through the normal memory cache so latency and throughput effects are often hidden by the cache. It's been a research topic to decide how to best use persistent byte addressable memory. Performance disparities are one problem, but the larger issue is actually one of correctness. Data structures are written to protect against race conditions in critical sections, but generally they are not written to maintain correctness in the event of a power failure and subsequent bring-up with some indeterminate persistent state (anything that went through cache is persistent, nothing else is. what was happening when the machine went down)? It's an interesting problem, lots of solutions. Most use a transactional interface--now doing this efficiently is the harder problem separate from but informed by the actual performance of the hardware.
- stcredzero 5y ago
  I know of "persistent" data structures from dabbling in Clojure. Just thinking off the top of my head just from that little bit of knowledge. If the very last thing that happens in an update, is a pointer update that "commits" the new data, it's correct if we assume RAM is dependable and the pointer update is atomic. What if there was a command which updated the value in the persistent store, then coerced a cache miss upwards through all of the cache levels? If the bottom level update at the persistent store is atomic, then it doesn't matter if the propagating cache misses are interrupted by a power failure. EDIT: But oh, the huge latency!
  - aidenn0 5y ago
    Ordering is what kills you there; lets say you have update X and Y both in cache and for correctness they must happen in that order. If you just do a global cache flush, you lose if Y happens before X. So you need to flush after X and after Y. This means that every update to a persistent store involves hitting memory twice. This also means that every implementation of a data structure needs to do all of this work correctly. Filesystems have many fewer data structures than general purpose code, and they still occasionally have correctness bugs here. You might be able to salvage some performance by having a large write queue and running all cache as write-through, but that will make writes, on average, far more expensive than reads. Perhaps a more reasonable option would be to use only static memory for the caches and have a battery-backed coprocessor flush the caches on power-loss.
grue_some 5y ago
This name, UltraRAM, is already in use by Xilinx for quite a while, https://www.xilinx.com/support/documentation/white_papers/wp477-ultraram.pdf https://www.xilinx.com/support/documentation/white_papers/wp... . They are the larger, but less flexible, embedded memories inside there Ultrascale and newer FPGAs. So, I was confused by the title of the article.
jl2718 5y ago
Short explainer: This is almost the same structure as traditional flash. That is, it has a “floating gate” which sits between the control gate and the channel between source and drain. When a large “write” voltage is applied to the control gate, charge tunnels into the floating gate, and stays there. Then a smaller “read” voltage on the control gate causes conduction in the channel. The main difference here is that the floating gate is made of many thin layers of heterogeneous (III-V) highly-valent semiconductor so that a smaller voltage is needed to tunnel charge into it. Other than the floating gate, this is a very traditional SLC flash structure, and it’s done in a very large area. They use the word “quantum” a lot, but you can substitute that word with “very thin”. I believe the utility of that structure versus bulk III-V is that it creates multiple barriers that allow precise linear control of the tunneling depth over a larger voltage range, and many places for charge to get ‘stuck’, versus one potential well that would just tunnel straight to the drain.
- Melatonic 5y ago
  So basically this is the opposite of a RAM disk - very interesting. I wonder if the NVME interface is fast enough to support something like this?
  - beebeepka 5y ago
    We're getting there https://www.anandtech.com/show/17203/pcie-60-specification-finalized-x16-slots-to-reach-128gbps https://www.anandtech.com/show/17203/pcie-60-specification-f...
  - mikepurvis 5y ago
    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.
StringyBob 5y ago
Did someone say ‘3D XPoint‘? https://www.theregister.com/2015/07/28/intel_micron_3d_xpoint/ https://www.theregister.com/2015/07/28/intel_micron_3d_xpoin... Always thought 3DXpoint (later released as optane) seemed cool, but had an almost impossible hill to climb by being completely oversold before it was released such that it was doomed to disappoint.
- ummonk 5y ago
  I still can't believe they decided to rebrand it as generic "Optane". The name doesn't really convey how much of a step change in technology it is.
supperburg 5y ago
I’ve always wondered by we didn’t just have tons of ram paired with a really good in-line battery rather than optane etc.
- Jwarder 5y ago
  I remember these being a bit of a nerd cred item in the early 2000s. Googling around I don't see anything too new in this space. I wonder if there was a problem with that approach or if SSDs just filled that niche.
- gjs278 5y ago
- bee_rider 5y ago
  I believe we do have something similar -- data centers almost always integrate some form of energy storage (from the venerable battery to fun stuff like flywheels). That kind of stuff is better handled at the building or rack level though I think -- the goal is to maybe backup some workloads and get everything into a safe state.
- banana_giraffe 5y ago
  There are products that do this. Gigabyte's I-RAM GC-RAMDISK is one.
HippoBaro 5y ago
The problem with fast byte-addressable non-volatile memory isn't hardware IMO. They've been around for a while, with Optane DC being the better option at the moment. The real issue is that software and APIs aren't keeping up with the hardware. If you do IO with memory mappings or anything POSIX, you will not be able to saturate a modern NVME SSD. And I'm not even talking about Optane here. This means that there is no market for these crazy fast devices. Look at the storage-optimized instances of every major cloud provider, and you won't find them. They would be too expensive, and the software people would run on them wouldn't be any faster than the older, cheaper SSDs. It'll take time for the software to evolve and catch up. Initiatives like DAX, eBPF, and io_uring in the kernel are a big step forward in the right direction.
- mhh__ 5y ago
  What does eBPF have to do with storage?
  - tenebrisalietum 5y ago
    eBPF is being or already is extended to hook into kernel facilities other than networking. I could see it being used to implement some abstraction onto storage other than POSIX block device or mmap().
  - HippoBaro 5y ago
    You can implement stuff using eBPF and do IO and compute in without leaving the kernel. It’s crazy. For instance you can perform an on-disk b-tree lookup in the kernel. These devices are so fast that crossing the kernel boundary becomes the limiting factor.
- The_rationalist 5y ago
  That is no longer true, io_uring maintainer bought an Optane in 2021 and fine tuned io_uring to saturate said Optane https://www.phoronix.com/scan.php?page=news_item&px=Linux-IO_uring-10M-IOPS https://www.phoronix.com/scan.php?page=news_item&px=Linux-IO...
ksec 5y ago
Intel Optane / 3D XPoint is a similar technology that is simple enough to produce and yet the market just isn't there. The problem is NAND has gotten so fast and so cheap, it is one of those good is the enemy of the best. While NAND's roadmap may be somewhat stagnated with cost reduction. Power usage, latency, cycles and bandwidth continues to improve.
rytill 5y ago
I have heard that ASML has a monopoly on EUV, which is required to make the highest-end semiconductors. Are the semiconductors used in high-end memory also bottle-necked by ASML's EUV machines? Pardon my ignorance.
- wtallis 5y ago
  Non-volatile memory usually can't shrink to structures small enough to require EUV without either becoming volatile memory or reducing endurance down to a handful of write cycles. Most R&D on non-volatile memories is focused on novel materials and structures that can be made cheaply without needing EUV or quad-patterned DUV. You especially don't want to be building a 3d memory array with dozens of layers of cells if each layer requires a few EUV steps. That's never going to lead to economical high-volume manufacturing.
fader 5y ago
I was briefly hopeful that this was a commercially viable memristor which I've been waiting for since I first heard of them decades ago. "Memristors can potentially be fashioned into non-volatile solid-state memory, which could allow greater data density than hard drives with access times similar to DRAM, replacing both components." https://en.wikipedia.org/wiki/Memristor https://en.wikipedia.org/wiki/Memristor
- narrator 5y ago
  What the heck happened to memristors anyway? Is HP still even working on them?
  - zwieback 5y ago
    I don't think so, when we split hp the Memristor side went to HPE (hp Enterprise) and I think they canned the whole thing. Maybe some IP is retained, not sure, but any real work would have to be done outside of hpe.
joezydeco 5y ago
Looks down at the FRAM chip on his project Oh. Okay.
unnouinceput 5y ago
Quote: "In a PC system, that would mean you would get a chunk of UltraRAM, say 2TB, and that would cover both your RAM and storage needs" No need to worry boys, Windows will grow in size accordingly. Remember, if Windows is not eating 20% of your storage, you don't have the latest according to Microsoft evangelists. (/s)
aheilbut 5y ago
What ever happened with Nantero?
robochat 5y ago
There is an offhand remark in the article that MRAM failed but why didn't it work out?

245 points by pulse7 5y ago

I'd rather I could just add a battery to RAM and use that as nv storage. I have seen (production, heavy load) systems that do this (RAMSAN is an example).

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.

lichtenberger 5y ago

I wonder if it's faster than Intel Optane DC Memory and if that's the deciding advantage, such that no additional volatile DRAM is needed: https://news.ycombinator.com/item?id=29906049 https://news.ycombinator.com/item?id=29906049

imachine1980_ 5y ago
if the cost is low you can opt out of the catche layer whoiut big performace drops, reducing the complexity

avidphantasm 5y ago

With endurance of 100x to 1000x that of flash, this seem like it would be a poor replacement for DRAM (but definitely a good replacement for flash and spinning disks, depending on the cost/GB). I searched, but could not find any obvious/easily accessible endurance summaries for DRAM (which I realized I had never given much thought). Does anyone know of any good sources for this?

jeffbee 5y ago
DRAM doesn't have program/erase wear-out. The device is essentially a capacitor. There is no endurance limit for tiny capacitors. DRAM does have a retention limit, only a few milliseconds. That's a drawback.
- pitaj 5y ago
  There is an endurance limit for any sufficiently small electronic device. Electromigration. With capacitors specifically, dielectric will eventually fail.
  - deleted 5y ago
    [deleted]
  - jeffbee 5y ago
    OK, but they don't wear out from that based on write cycles, they would wear out from that based on power-on hours.

lichtenberger 5y ago

BTW: if someone is interested to contribute or use the project... my open source project, an evolutionary, immutable JSON data store will benefit from fast random, fine granular access to durable storage as it has to read scattered word aligned page fragments from random locations in an append-only file in parallel to reconstruct a full page in-memory. The crux is that SirixDB is storing a huge persistent tree of tries index over revisions plus user defined indexes, a path summary and shared object fields in one log-structured appended only file. It does not simply copy whole database pages, but mainly stores only changed records/nodes. So it mainly stores the whole index in one file (append-only) plus an offset file to map timestamps to revision offsets (besides the 32bit revision numbers / revisions stored in the main file). This means that we can store checksums of the child db pages in parent pages as in ZFS and to store the checksum of the UberPage in the page itself to validate the whole resource and we don't need a seperate transaction log despite an in memory cache for the single read-write trx. https://github.com/sirixdb/sirix https://github.com/sirixdb/sirix and a query processor called Brackit for document stores based on a JSONiq like query language: https://github.com/sirixdb/brackit https://github.com/sirixdb/brackit

hinkley 5y ago

> program-erase cycling endurance is "one hundred to one thousand times better than flash." That is still not enough write operations to let anyone treat this like a bigger version of RAM, is it?

baybal2 5y ago
Which means 10^12 to 10^13. SRAM needs 10^20 DRAM 10^17 Any memory exploiting variable dielectric properties is subject to dielectric failure.
- thoughtsimple 5y ago
  According to the conclusion in the white paper, they tested for endurance only to 10^7 with no degradation. Obviously that is not enough for a real system.
- wolverine876 5y ago
  Do you know good sources on that? Thanks.
- pishpash 5y ago
  Right, there are physical limitations to how physical states can be altered (density, speed, energy) with enough persistence against entropic decay. Persistence is an abstraction to push the renewal burden onto backup maintainers. I'd much rather see work directed towards a self-repairing style of persistence.
- after_care 5y ago
  Without constantly loading cached data into dram the number of writes to it would be significantly lower.

jeffbee 5y ago

This is a semiconductor physics paper, not a computer architecture paper, and it doesn't make any kind of claims that would support the statement of "DRAM-like speed". They can erase their enormous single-bit device in 5ms, which is forever. The features are 1000s of times larger than current silicon DRAM. It also has endurance of only 10^7 erase cycles, which a computer could exhaust in a split second, if the device were fast enough. The interesting thing here is the non-volatility for this type of structure on Si instead of GaAs.

nynx 5y ago

As people are saying, the read/write endurance doesn't seem like enough to replace DRAM, but this would be a _fantastic_ replacement for flash (and the long-term data endurance seeems awesome).

lichtenberger 5y ago
For servers there's already Intel Optane DC Memory and it's not fast enough to replace volatile memory in most cases, but way faster than flash drives. Thus, UltraRAM might have no real benefit? Maybe we'll have to wait, also regarding the cost factor.

conductor 5y ago

I think it's at least a decade since Texas Instruments introduced the FRAM series of their MSP430 microcontrollers [0]. Good to know there are efforts to bring such technologies to "bigger" computers - having TBs of RAM in your laptop must be fun. [0] https://en.wikipedia.org/wiki/TI_MSP430#FRAM_series https://en.wikipedia.org/wiki/TI_MSP430#FRAM_series

arghnoname 5y ago

We've had a variant of this in the form of intel's persistent memory (named Octane DC memory or something stupid like this). It's addressable like RAM, but persistent. Performance is not quite that of DRAM (within an order of magnitude), but reads and writes go through the normal memory cache so latency and throughput effects are often hidden by the cache. It's been a research topic to decide how to best use persistent byte addressable memory. Performance disparities are one problem, but the larger issue is actually one of correctness. Data structures are written to protect against race conditions in critical sections, but generally they are not written to maintain correctness in the event of a power failure and subsequent bring-up with some indeterminate persistent state (anything that went through cache is persistent, nothing else is. what was happening when the machine went down)? It's an interesting problem, lots of solutions. Most use a transactional interface--now doing this efficiently is the harder problem separate from but informed by the actual performance of the hardware.

stcredzero 5y ago
I know of "persistent" data structures from dabbling in Clojure. Just thinking off the top of my head just from that little bit of knowledge. If the very last thing that happens in an update, is a pointer update that "commits" the new data, it's correct if we assume RAM is dependable and the pointer update is atomic. What if there was a command which updated the value in the persistent store, then coerced a cache miss upwards through all of the cache levels? If the bottom level update at the persistent store is atomic, then it doesn't matter if the propagating cache misses are interrupted by a power failure. EDIT: But oh, the huge latency!
- aidenn0 5y ago
  Ordering is what kills you there; lets say you have update X and Y both in cache and for correctness they must happen in that order. If you just do a global cache flush, you lose if Y happens before X. So you need to flush after X and after Y. This means that every update to a persistent store involves hitting memory twice. This also means that every implementation of a data structure needs to do all of this work correctly. Filesystems have many fewer data structures than general purpose code, and they still occasionally have correctness bugs here. You might be able to salvage some performance by having a large write queue and running all cache as write-through, but that will make writes, on average, far more expensive than reads. Perhaps a more reasonable option would be to use only static memory for the caches and have a battery-backed coprocessor flush the caches on power-loss.

grue_some 5y ago

This name, UltraRAM, is already in use by Xilinx for quite a while, https://www.xilinx.com/support/documentation/white_papers/wp477-ultraram.pdf https://www.xilinx.com/support/documentation/white_papers/wp... . They are the larger, but less flexible, embedded memories inside there Ultrascale and newer FPGAs. So, I was confused by the title of the article.

jl2718 5y ago

Short explainer: This is almost the same structure as traditional flash. That is, it has a “floating gate” which sits between the control gate and the channel between source and drain. When a large “write” voltage is applied to the control gate, charge tunnels into the floating gate, and stays there. Then a smaller “read” voltage on the control gate causes conduction in the channel. The main difference here is that the floating gate is made of many thin layers of heterogeneous (III-V) highly-valent semiconductor so that a smaller voltage is needed to tunnel charge into it. Other than the floating gate, this is a very traditional SLC flash structure, and it’s done in a very large area. They use the word “quantum” a lot, but you can substitute that word with “very thin”. I believe the utility of that structure versus bulk III-V is that it creates multiple barriers that allow precise linear control of the tunneling depth over a larger voltage range, and many places for charge to get ‘stuck’, versus one potential well that would just tunnel straight to the drain.

Melatonic 5y ago
So basically this is the opposite of a RAM disk - very interesting. I wonder if the NVME interface is fast enough to support something like this?
- beebeepka 5y ago
  We're getting there https://www.anandtech.com/show/17203/pcie-60-specification-finalized-x16-slots-to-reach-128gbps https://www.anandtech.com/show/17203/pcie-60-specification-f...
- mikepurvis 5y ago
  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.

StringyBob 5y ago

Did someone say ‘3D XPoint‘? https://www.theregister.com/2015/07/28/intel_micron_3d_xpoint/ https://www.theregister.com/2015/07/28/intel_micron_3d_xpoin... Always thought 3DXpoint (later released as optane) seemed cool, but had an almost impossible hill to climb by being completely oversold before it was released such that it was doomed to disappoint.

ummonk 5y ago
I still can't believe they decided to rebrand it as generic "Optane". The name doesn't really convey how much of a step change in technology it is.

supperburg 5y ago

I’ve always wondered by we didn’t just have tons of ram paired with a really good in-line battery rather than optane etc.

Jwarder 5y ago
I remember these being a bit of a nerd cred item in the early 2000s. Googling around I don't see anything too new in this space. I wonder if there was a problem with that approach or if SSDs just filled that niche.
gjs278 5y ago
bee_rider 5y ago
I believe we do have something similar -- data centers almost always integrate some form of energy storage (from the venerable battery to fun stuff like flywheels). That kind of stuff is better handled at the building or rack level though I think -- the goal is to maybe backup some workloads and get everything into a safe state.
banana_giraffe 5y ago
There are products that do this. Gigabyte's I-RAM GC-RAMDISK is one.

HippoBaro 5y ago

The problem with fast byte-addressable non-volatile memory isn't hardware IMO. They've been around for a while, with Optane DC being the better option at the moment. The real issue is that software and APIs aren't keeping up with the hardware. If you do IO with memory mappings or anything POSIX, you will not be able to saturate a modern NVME SSD. And I'm not even talking about Optane here. This means that there is no market for these crazy fast devices. Look at the storage-optimized instances of every major cloud provider, and you won't find them. They would be too expensive, and the software people would run on them wouldn't be any faster than the older, cheaper SSDs. It'll take time for the software to evolve and catch up. Initiatives like DAX, eBPF, and io_uring in the kernel are a big step forward in the right direction.

mhh__ 5y ago
What does eBPF have to do with storage?
- tenebrisalietum 5y ago
  eBPF is being or already is extended to hook into kernel facilities other than networking. I could see it being used to implement some abstraction onto storage other than POSIX block device or mmap().
- HippoBaro 5y ago
  You can implement stuff using eBPF and do IO and compute in without leaving the kernel. It’s crazy. For instance you can perform an on-disk b-tree lookup in the kernel. These devices are so fast that crossing the kernel boundary becomes the limiting factor.
The_rationalist 5y ago
That is no longer true, io_uring maintainer bought an Optane in 2021 and fine tuned io_uring to saturate said Optane https://www.phoronix.com/scan.php?page=news_item&px=Linux-IO_uring-10M-IOPS https://www.phoronix.com/scan.php?page=news_item&px=Linux-IO...

ksec 5y ago

Intel Optane / 3D XPoint is a similar technology that is simple enough to produce and yet the market just isn't there. The problem is NAND has gotten so fast and so cheap, it is one of those good is the enemy of the best. While NAND's roadmap may be somewhat stagnated with cost reduction. Power usage, latency, cycles and bandwidth continues to improve.

rytill 5y ago

I have heard that ASML has a monopoly on EUV, which is required to make the highest-end semiconductors. Are the semiconductors used in high-end memory also bottle-necked by ASML's EUV machines? Pardon my ignorance.

wtallis 5y ago
Non-volatile memory usually can't shrink to structures small enough to require EUV without either becoming volatile memory or reducing endurance down to a handful of write cycles. Most R&D on non-volatile memories is focused on novel materials and structures that can be made cheaply without needing EUV or quad-patterned DUV. You especially don't want to be building a 3d memory array with dozens of layers of cells if each layer requires a few EUV steps. That's never going to lead to economical high-volume manufacturing.

fader 5y ago

I was briefly hopeful that this was a commercially viable memristor which I've been waiting for since I first heard of them decades ago. "Memristors can potentially be fashioned into non-volatile solid-state memory, which could allow greater data density than hard drives with access times similar to DRAM, replacing both components." https://en.wikipedia.org/wiki/Memristor https://en.wikipedia.org/wiki/Memristor

narrator 5y ago
What the heck happened to memristors anyway? Is HP still even working on them?
- zwieback 5y ago
  I don't think so, when we split hp the Memristor side went to HPE (hp Enterprise) and I think they canned the whole thing. Maybe some IP is retained, not sure, but any real work would have to be done outside of hpe.

joezydeco 5y ago

Looks down at the FRAM chip on his project Oh. Okay.

unnouinceput 5y ago

Quote: "In a PC system, that would mean you would get a chunk of UltraRAM, say 2TB, and that would cover both your RAM and storage needs" No need to worry boys, Windows will grow in size accordingly. Remember, if Windows is not eating 20% of your storage, you don't have the latest according to Microsoft evangelists. (/s)

aheilbut 5y ago

What ever happened with Nantero?

robochat 5y ago

There is an offhand remark in the article that MRAM failed but why didn't it work out?