UltraRAM: 'Universal Memory' That Brings RAM-Like Speed to Non-Volatile Storage | Hacker News Reader

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

tomshardware.com

245 pointspulse7129 comments

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.

>They use the word “quantum” a lot, but you can substitute that word with “very thin”.

Holy crow, I hate this.

The use of quantum seems appropriate as it's referring to quantum tunneling, which is something that comes up a lot with CPU architectures as they get extra tiny.

I believe this is what you're referring to https://en.wikipedia.org/wiki/QFET

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?

Why only the other day https://news.ycombinator.com/item?id=29897713 we was pondering what would need all that data bandwidth for the new PCIe-6 specs.

Having too much bandwidth or capacity is a problem in IT that often solves itself more often than not.

The real problem though is latency - RAM is extremely low latency and that is one of its primary benefits. I can't say for sure what this new tech has but reading about Intel Optane (which is already much lower latency than normal SSD) it seems to have a latency of approximately 1-10us. DDR4 is something like 50ns. Pretty large disparity (my numbers could be off - this was just after some quick searches)

Check out "Intel Optane DC". You might like what you find, but to my knowledge it's only targeted at data centers.

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.

> 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.

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.

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.

> 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.

> 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.

> 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.

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

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.

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.

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.

Hibernate is actually the first thing I always disable on any windows machine - it takes up a lot of extra ram. And with SSD startup from cold is usually so fast I find fast startup not all that great either.

We're getting there https://www.anandtech.com/show/17203/pcie-60-specification-f...

M.2 actually reserved a key for the "Future Memory Interface". That of course must be serdes based due to the pin-count and general physics.

The key here is that it is RAM-like WRITE speed. We've had RAM-like read speed for over 20 years.

Seems suspect. What hard drive has had RAM-like read speed for over 20 years?

Let's go back to 2002, toshiba announces 1GB compact flash memory card with a read speed of 6.5MB/second (maximum).

Compare that to 2002 Hynix Net DDR II with a read speed of about 100MB/s and clearly you can see how wrong I am.

My bad, I was confusing Flash that had a DRAM-like interface, and Flash that could read as fast as DRAM. But I cannot edit my response now.

What is "RAM-like speed?" It certainly was a different value 20 years ago than it is today. I'm restoring a machine from 1989 that on a good day can push 15MB/s through RAM, while I think contemporary RAM will do more than 12GB/s. GP's statement is ambiguous.

RAM has always been perceived as fast, but storage was always perceived as slow, for decades, and didn't begin to get fast until 20 years ago. I think if there were 15MB/s HDDs matching RAM bandwidth in 1989 it would seem a lot more impressive than a really really fast, near-RAM bandwidth-fast SSD today, even though 12GB/s is so crazy fast it is beyond comprehension.

I'm guessing the page cache for hot data?

Is that non-volatile? (retains its memory without power)

> This is almost the same structure as traditional flash

Thus that mean it also is almost as easy to manufacture?

Actually I don’t think this will be very difficult in terms of adding the molecular beam epitaxy steps to the traveler. However, there is massive fab-wide risk from introducing III-V elements into the process, which can contaminate everything, so they may have to build an entirely new fab for this process. It’s been a while for me, so my understanding may be dated.

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.

Several of the folks I've talked to who were most excited about Optane (and disappointed about its delayed introduction & market rejection) were interested primarily in the greater per-chip density, with persistence as at best a "nice-to-have".

Take your typical in-memory database: The primary scalability constraint is how much "fast enough" memory you can park close to your CPU cores. Persistence lets you make some faster / broader failure & recovery guarantees, but if those are major application concerns, you probably wouldn't be using an in-memory database in the first place.

>and disappointed about its delayed introduction & market rejection

Even at peak NAND and DRAM price ( at ~3x of normal ), where Optane had a slight chance of competing, Intel was still selling it at cost, with a volume that could not even fulfil their minimum purchase agreement with Micron. With a technical roadmap that doesn't fulfil their initial promise, and questionable cost reduction plan even at optimal volume.

Compared that to DRAM ( DDR5 / DDR6 and HMB ) and NAND ( SLC / Z-NAND ), as much as I love the XPoint technology the cost benefits just didn't make any sense once DRAM and NAND falls back to normal pricing. Micron already know this all the way back in 2018, but the agreement with Intel kept them from writing it out clearly.

I'm curious: The promise of Optane has pushed Intel's stock upwards. Did it's rejection by the market pushed the stock downward in a similar amount ?

I honestly dont think that was ever the case, unless it was some mainstream media reporting. In reality Intel has been making record profits YOY for 4 or 5 years in a row. Mostly due to Datacenter revenue. Optane, or NAND / Storage business is a tiny segment on Intel's profits. Although the narrative that Optane will create a lock in on Server Sector certainly helped a tiny bit. But now the threat is coming from elsewhere.

That’s a good point. If I remember correctly, optane has a operating mode where the memory is only meant to be used as RAM. It’s stored on the non-volatile RAM in an encrypted form and the key is intentionally discarded/lost when rebooted.

Another obvious operating mode is to make the NVRAM be the first line of swap and have things spill from DRAM into NVRAM when there is memory pressure. I think Intel also offered a mode like this, where it made everything look like DRAM and it would spill onto NVRAM as it needed to. Of course, this would be better rolled into the OS or application level so smarter decisions can be made, but given very high NVRAM densities it’s a great application for the technology.

I think technology like this should force us to rethink how we do stuff at a fundamental level. Does the concept of treating "storage hardware" and "compute hardware" even make sense in this world?

We should probably start rethinking everything we do from the OS layer to the way we write applications and exchange data. Truly performant non-volatile RAM would be (will be?) a revolution that rivals some of the earliest groundbreaking work in computer science.

Definitely. You also have stuff like putting compute into the hardware. I read somewhere about SSDs with on-board compute doing serialization/deserialization of some data structures on the device itself, for instance. You can, in principle, take compute on board a NIC and if you could address the memory controller directly, you could serve NVRAM backed key-value store directly, without the CPU at all. Things are getting mushy and our way of addressing hardware resources and the OS abstractions behind them aren’t up to the task anymore.

In the research world, due to various things about the kind of work that is feasible to do and get published in a reasonable timeframe, they just aren’t looking at these bigger questions as deeply as I think they ought to. People do more minor iterations on the existing approaches, which is a pity.

That's not putting compute into hardware (i.e. for the first time), that's just building custom application-specific hardware, which happens all the time. You used to have the floating point unit outside the CPU.

Some fundamentals don't change. One one side there are processors (CPU, GPU, whatever) and on the other side we want to persistent some data for decades in some format that lets us exchange it with other people or multiple applications inside the same box. I don't expect ext4 and NTFS to go away soon. In between could totally change.

Why would it be any different than now? What fundamentally changes if RAM itself became persistent vs. being persistable to other hardware, except you'd save the one-time data loading cost? Case in point, RTX 3090 GPU's have 24GB of RAM on board, and they're left always on.

I agree that nothing would change. Even the "flushed to journal" approach of databases and filesystems would remain, because that doesn't just happen because of the looming danger of power loss, it also happens because software malfunctions exist and you want to separate work in progress from the done and approved.

And if it's not cheaper as RAM it's not interesting anyways. Chances are if you could afford 1:1 paging plenty of applications would happily do and not mind the separation between a fast copy and a persistent copy at all.

If RAM and storage become one and the same the way you store your data in memory is how you store your data permanently. The state of your application becomes your data storage. Or at least in theory it could.

> The state of your application becomes your data storage.

That's honestly a worst-case scenario. Imagine an application that is permanently in RAM -- and no matter how often you kill it, it will never "reload" from a clean state.

There will likely be other ways of resetting the state of memory.

Why you are asked to "clear cache" so often on Android.

Erlang and kin rely explicitly on the ability to crash and start over with a clean slate.

Yeah but the point is you can do that today. The OS does it with hibernation.

Imo, what kills Optane, is that it has limited write cycles, like an SSD, and because of that you can't treat it like RAM.

If I'm reading this right, I think UltraRAM doesn't solve this problem. From the article:

> its fast switching speed and program-erase cycling endurance is "one hundred to one thousand times better than flash."

I know flash can get some impressive endurance now, but if you start treating it like RAM, is 1000x that endurance even enough?

> I know flash can get some impressive endurance now, but if you start treating it like RAM, is 1000x that endurance even enough?

Anything with limited endurance will need some kind of controller in front of it that makes sure that it wears out evenly. You'll end up with "copy-on-write" RAM that will be inherently slow/space inefficient, either due to block size being way too large for typical RAM access pattern or the data structure managing it becoming too large.

And of course you incur extra latency from having to do look-ups in the first place.

This is a problem. When I worked on it I didn’t treat it as RAM, but as something RAM would spill to. Essentially treating it as where memory mapped files are stored and then being clever about how those files are read/written. This reduces writes to once per modified byte address within a transaction (e.g., between msyncs).

Another comment already mentions this, but I guess a functional data structure would be easiest to maintain, even though there's stuff like this for PMEM such that any data structure would work essentially: https://pmem.io/

This[1] Open Source data store I'm maintaining is storing a huge tree of tries eventually on durable storage, but it's essentially a huge persistent index stored in an append-only file. The last layer of "indirect index pages" stores list of pointers to page fragments, which store the actual records (the list however is bound to a predefinded size). A single read-write trx per resource syncs the new page fragments, which mainly only include the updated or new records plus the paths to the root page to a durable device during a postorder traversal of the in-memory log. The last thing is an atomic update, which sets a new offset to point to the new UberPage, the root of the storage. All pages are only word aligned except for RevisionRootPages, which are aligned to a multiple of 256 bytes. All pages are compressed and might in the future optionally be encrypted.

I guess these byte addressable persistent memory devices are an ideal fit for small sized parallel random reads of potentially tiny page fragments to reconstruct a full page in-memory.

However, I hope they'll eventually achieve a better price in comparison to DRAM and SSDs than Intel Optane DC PMEM current price range.

[1] https://github.com/sirixdb/sirix

All of that stuff is really interesting from a technical perspective, but if the persistent memory isn't cheaper than RAM then 95% of machines won't need it, or won't need more than a small buffer of it. It'll be amazing for database servers and almost nobody else.

And Optane failed that test.

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!

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.

Well said. I will just add that there are cache write-through instructions and fence instructions. You can use these for just the pointer swap components the parent was talking about, but absolutely you’re correct, you can just take a naive data structure and have this work out of the box.

There is work to make this transparent to existing data structures, but it (of course) imposes its own overhead.

Why not using DAX FS mode for Optane DC memory for instance and serialize the data structure by hand? I'm not sure how much performance you lose. That said the data store I'm working on serializes the huge persistent in-memory index to durable storage in a postorder traversal (mainly changed records in a data page Plus path copies) and atomically sets an offset to the main root, the UberPage to the new revision in a file. So, I'd say it's precisely what you describe :-)

At least on PPC you can map write-through, that solves 99% of this on an embedded system with battery backed SRAM I use.

Does it have unlimited write cycles?

No, it would last a decent bit if used ‘appropriately,’ but sadly in a heavy use environment it would be a consumable.

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

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.

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."

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

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.

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!

Which is why distributed local compute is the future! The real tradeoff is between compute vs. communication.

Plus, MPI is way cooler than OpenMP.

Corollary: Constant time random access data structures don't exist.

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'.

You'll still need snapshotted backups. Some storage may be devoted to that.

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.

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

So let's wait and see.

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.

So like a smalltalk or lisp based image system.

I’m down for that.

> 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.

We can have this architecture today. Writing an OS is hard, though.

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.)

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.

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.

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.

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...

I'm pretty sure Intel loaned him the P5800X drives, starting before they were widely available for purchase. But those are a different product from the Optane DC persistent memory product that uses DIMM slots instead of PCIe and NVMe.

I mention io_uring in my original comment. The issue isn’t that the tech doesn’t exist, it’s that it’s not being used.

And even before that there was Linux AIO etc.

A nice counter-example are project loom green threads which will make use of it. But yeah it is very much underused

It can come up in use-cases with very large in-memory databases, caches or indexes that would otherwise have to be rebuilt/reloaded on reboot, taking hours. Imagine having, say 4TB of index in memory and needing to patch that server. With persistent memory you could be back up and running much more quickly. Especially helpful when you have many of these types of servers that have to all get patched in some sequence.

This is not a home-use-case, but it certainly exists today in larger Enterprises.

So it's not (necessarily) about having a very fast filesystem, it's about having persistent memory.

What kind of patching?

Is the goal to say "okay, here is a persistent chunk of memory with a file or program in it, keep it preserved while the OS reboots, then if it's a program reconnect the files and sockets it was using"?

Because you can just remove the word 'persistent' and do that today. Most hardware shouldn't wipe memory on a reboot, and if it does talk to your vendor for a BIOS option. And all the support code you need in your OS should be roughly the same.

> This is not a home-use-case, but it certainly exists today in larger Enterprises.

Part of me hopes someone in here proves you wrong :-) Us techies do mad things sometimes...

> This means that there is no market for these crazy fast devices.

If this becomes a real product, I expect that market will be created. My guess is that it would show up in Apple hardware very early on, if not first. It probably would increase battery life (if I understand this tech correctly, you won’t have to power the RAM while the system is sleeping), and they’ve shown they’re willing to completely redesign their hardware.

Also in the desktop world, Microsoft’s DirectStorage API was made exactly to alleviate those concerns, although marketed primarily for games.

What does eBPF have to do with storage?

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.

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().

> 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?

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.

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.

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.

Without constantly loading cached data into dram the number of writes to it would be significantly lower.

Do you know good sources on that? Thanks.

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.

This name, UltraRAM, is already in use by Xilinx for quite a while, 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.

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?

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.

There is an endurance limit for any sufficiently small electronic device. Electromigration. With capacitors specifically, dielectric will eventually fail.

OK, but they don't wear out from that based on write cycles, they would wear out from that based on power-on hours.

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

What the heck happened to memristors anyway? Is HP still even working on them?

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.

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 and a query processor called Brackit for document stores based on a JSONiq like query language: https://github.com/sirixdb/brackit

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

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

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

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).

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.

Did someone say ‘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.

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.

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.

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.

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.

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.

There are products that do this. Gigabyte's I-RAM GC-RAMDISK is one.

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)

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.

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.

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).

Looks down at the FRAM chip on his project

Oh. Okay.

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

What ever happened with Nantero?

Reply on news.ycombinator.com