[HN Gopher] UltraRAM: 'Universal Memory' That Brings RAM-Like Sp...
___________________________________________________________________
UltraRAM: 'Universal Memory' That Brings RAM-Like Speed to Non-
Volatile Storage
Author : pulse7
Score : 180 points
Date : 2022-01-11 10:30 UTC (1 days ago)
(HTM) web link (www.tomshardware.com)
(TXT) w3m dump (www.tomshardware.com)
| grue_some wrote:
| 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.
| jl2718 wrote:
| 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.
| 37 wrote:
| >They use the word "quantum" a lot, but you can substitute that
| word with "very thin".
|
| Holy crow, I hate this.
| staticassertion wrote:
| 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.
| judge2020 wrote:
| I believe this is what you're referring to
| https://en.wikipedia.org/wiki/QFET
| Melatonic wrote:
| 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?
| mikepurvis wrote:
| NVMe is just a 4-lane PCIe interface with a different
| connector. So if that's not fast enough, it could instead go
| on a 8x or 16x expansion card.
|
| The question for me would be whether this is truly a drop-in
| replacement for either disk _or_ RAM, or if it 's something
| that needs to be treated as a separate peripheral while new
| applications are written to really take advantage of it-- for
| example, a database that DMAs directly from permanent storage
| to the network with no concept of loading or caching anything
| in RAM.
| naikrovek wrote:
| > 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.
| Melatonic wrote:
| 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
| beebeepka wrote:
| We're getting there https://www.anandtech.com/show/17203/pcie
| -60-specification-f...
| formerly_proven wrote:
| 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.
| Zenst wrote:
| 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.
| Melatonic wrote:
| 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)
| Someone wrote:
| > This is almost the same structure as traditional flash
|
| Thus that mean it also is almost as easy to manufacture?
| SavantIdiot wrote:
| The key here is that it is RAM-like _WRITE_ speed. We 've had
| RAM-like read speed for over 20 years.
| hypertele-Xii wrote:
| Seems suspect. What hard drive has had RAM-like read speed
| for over 20 years?
| dusted wrote:
| 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
| egypturnash wrote:
| 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 wrote:
| You'll still need snapshotted backups. Some storage may be
| devoted to that.
| nine_k wrote:
| 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 wrote:
| We can have this architecture _today_. Writing an OS is hard,
| though.
| nine_k wrote:
| 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 wrote:
| So like a smalltalk or lisp based image system.
|
| I'm down for that.
| inetknght wrote:
| > _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.
| zamadatix wrote:
| 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 wrote:
| 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."
| bee_rider wrote:
| 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 wrote:
| Which is why distributed local compute is the future! The
| real tradeoff is between compute vs. communication.
| bee_rider wrote:
| Plus, MPI is way cooler than OpenMP.
| continuational wrote:
| Corollary: Constant time random access data structures
| don't exist.
| causality0 wrote:
| 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 wrote:
| This article didn't mention density/cost. That's a key reason
| why we still use storage.
|
| So let's wait and see.
| austincheney wrote:
| 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.
| StringyBob wrote:
| 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.
| ummonk wrote:
| 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.
| nynx wrote:
| 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 wrote:
| 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.
| ksec wrote:
| 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.
| lichtenberger wrote:
| 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
| imachine1980_ wrote:
| if the cost is low you can opt out of the catche layer whoiut
| big performace drops, reducing the complexity
| jeffbee wrote:
| 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.
| selimnairb wrote:
| 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 wrote:
| 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 wrote:
| There is an endurance limit for any sufficiently small
| electronic device. Electromigration. With capacitors
| specifically, dielectric will eventually fail.
| [deleted]
| jeffbee wrote:
| OK, but they don't wear out from that based on write
| cycles, they would wear out from that based on power-on
| hours.
| HippoBaro wrote:
| 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.
| mdavis6890 wrote:
| 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.
| The_rationalist wrote:
| 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...
| wtallis wrote:
| 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.
| Someone wrote:
| > 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.
| mhh__ wrote:
| What does eBPF have to do with storage?
| tenebrisalietum wrote:
| 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().
| conductor wrote:
| 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
| fader wrote:
| 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
| narrator wrote:
| What the heck happened to memristors anyway? Is HP still even
| working on them?
| zwieback wrote:
| 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.
| lichtenberger wrote:
| 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
| hinkley wrote:
| > 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 wrote:
| 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.
| wolverine876 wrote:
| Do you know good sources on that? Thanks.
| thoughtsimple wrote:
| 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.
| unnouinceput wrote:
| 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)
| dekhn wrote:
| 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).
| rytill wrote:
| 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.
| supperburg wrote:
| 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.
| bee_rider wrote:
| 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.
| Jwarder wrote:
| 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.
| banana_giraffe wrote:
| There are products that do this. Gigabyte's I-RAM GC-RAMDISK is
| one.
| gjs278 wrote:
| arghnoname wrote:
| 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.
| tinus_hn wrote:
| Does it have unlimited write cycles?
| arghnoname wrote:
| No, it would last a decent bit if used 'appropriately,' but
| sadly in a heavy use environment it would be a consumable.
| abraxas wrote:
| 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.
| arghnoname wrote:
| 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.
| pishpash wrote:
| 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.
| pmontra wrote:
| 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.
| pishpash wrote:
| 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.
| abraxas wrote:
| 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.
| pishpash wrote:
| Yeah but the point is you can do that today. The OS does
| it with hibernation.
| inetknght wrote:
| > _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.
| macintux wrote:
| Erlang and kin rely explicitly on the ability to crash
| and start over with a clean slate.
| abraxas wrote:
| There will likely be other ways of resetting the state of
| memory.
| twoodfin wrote:
| 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.
| arghnoname wrote:
| 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.
| ksec wrote:
| >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.
| petra wrote:
| 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 ?
| torginus wrote:
| 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.
| jw14 wrote:
| 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?
| arghnoname wrote:
| 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).
| mzs wrote:
| At least on PPC you can map write-through, that solves 99% of
| this on an embedded system with battery backed SRAM I use.
| lichtenberger wrote:
| 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
| stcredzero wrote:
| 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 wrote:
| 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.
| arghnoname wrote:
| 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.
| lichtenberger wrote:
| 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 :-)
| joezydeco wrote:
| _Looks down at the FRAM chip on his project_
|
| Oh. Okay.
___________________________________________________________________
(page generated 2022-01-12 23:00 UTC)