Comment by dusted | Hacker News Reader

Comment by dusted | Hacker News Reader

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

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

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com