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.
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.
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)
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.
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.
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 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.
> 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.
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.
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.
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 :-)
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."
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.
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'.
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.
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.
> 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.
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.
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.
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.
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 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.
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().
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.
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.
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?
There is an endurance limit for any sufficiently small electronic device. Electromigration. With capacitors specifically, dielectric will eventually fail.
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."
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.
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.
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.
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.
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 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.
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).
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.