Live data from Hacker News

Rest in Peace, Optane

specbranch.com

111–120 of 122 posts

Re: Rest in Peace, Optane

#111

Earlier quoted context omitted.

You do, in fact. It’s called a memory write barrier. Ensures consistency of data structures as needed. And it call stall the cpu pipeline, so there’s a nontrivial cost involved.

The point is that on PMem that is simply "sfence", and not a potentially super-expensive "fsync" syscall... Fsync is an fsync, not a memory barrier...

They both involve flushing cache to backing stores, and waiting for confirmation of the write. It’s literally the same thing. It’s just writing a cache line to RAM is orders of magnitude faster than writing a disk sector to storage, even with NVME SSDs. Octane is/was somewhere in the middle.

Re: Rest in Peace, Optane

#112

What was interesting about Optane was that it was kinda an attempt to get rid of disk and ram distinction. You had single device (optane stick) which served as both - ram and disk. After decades of current approach we finally could physically get rid of disks - hdds, ssds or even nvme sticks. https://www.theregister.com/2022/08/01/optane_intel_cancella... >Optane presented a radical, transformative technology but bec…

Yeah - the article was talking about mmap... but what i wanted was to not have to define persistence boundary. I wanted the entire in-memory state of my program to be persisted - perhaps even duplicated and moved elsewhere

Look at developing for MSP430s with FRAM -- these microcontrollers have a decent amount of FRAM with full persistence, full XIP etc, up to 256 kB; but only 8 kB or less of traditional SRAM. Even in this world, where you /could/ have everything persisted, you still end up aware of the persistence boundary and using SRAM both for the absolutely highest-performance code (e.g. interrupt handlers; FRAM has more wait states than SRAM in this implementation), but more interestingly for things that specifically /should not/ be persisted (e.g. the bytes storing whether your POST has completed, hardware initialized, etc). You can come close to persistence-oblivious, especially at a conceptual "application layer", but the overall implementation still ends up persistence-aware.

Re: Rest in Peace, Optane

#113
post #64

Earlier quoted context omitted.

The problem is optane wasn't as fast as DRAM, nor as cheap as disk. So you still needed the conceptual split anyway, and there wasn't a compelling reason to really use it (OK, I can get a lot of RAM but it's 1/10th the speed of my normal RAM, which will kill both memory latency and memory bandwidth limited applications, which is basically any workload which wants lots of RAM. Or I can get super fast persistent storag…

Where Optane could've been used: distributed storage. The whole game there is about how fast can you ack the writes while writing as far away as you can. The company I worked for in this specific area had used pmem when that was available for that specific reason. I'm no expert on costs of these things and especially wouldn't dare to predict how these costs could've behaved in the future, but my guess would be not th…

You're right and it did get used for that. Unfortunately that's nowhere large enough a use case to support the entire product/business/r&d.

Re: Rest in Peace, Optane

#114

Earlier quoted context omitted.

I think it will be basically impossible to move away from von Neumann unless you control the entire stack, including OS and software. I don’t even think Apple could do it with Mac, because they are general purpose machines (for now at least). Maybe Apple could do it with iOS devices. Nintendo might be able to pull it off, though people trying port titles from other platforms may no longer try to do so. Because so man…

I'm not sure if Sony would want to make a system with a very unique architecture again. Devs complained about how hard it was to program PS2 games, and again with PS3. PS4 and 5 are practically PCs by comparison.

I don’t want to say that we’ll never see big architecture changes again but I think a company like Sony would want more confidence that they’d get real advantages. Cell wasn’t just unpopular with developers but also never delivered compelling performance; I suspect if they’d had a PC CPU and a Blu-ray player at the same price it would’ve sold identically.

Anyone trying this needs to figure out a decade-long schedule with points where something would be worth using for some reason so they don’t have to run the whole thing in a vacuum hoping it’ll be worth it at the end.

Re: Rest in Peace, Optane

#115

What was interesting about Optane was that it was kinda an attempt to get rid of disk and ram distinction. You had single device (optane stick) which served as both - ram and disk. After decades of current approach we finally could physically get rid of disks - hdds, ssds or even nvme sticks. https://www.theregister.com/2022/08/01/optane_intel_cancella... >Optane presented a radical, transformative technology but bec…

Like Itanium, it was one of those Intel projects that was simultaneously too ambitious and not ambitious enough. If Intel really wanted to redesign the Von Neumann architecture, they would have had to be prepared to absorb losses for much longer, way north of a decade. The alternative might have been to focus exclusively on providing SSDs using the new technology and maybe try to segue into this new memory architectu…

At the very least wait for CXL to become commonplace before you get ready to cancel, since that's the kind of interface that is a perfect fit for optane.

Re: Rest in Peace, Optane

#116

Earlier quoted context omitted.

The point is that on PMem that is simply "sfence", and not a potentially super-expensive "fsync" syscall... Fsync is an fsync, not a memory barrier...

They both involve flushing cache to backing stores, and waiting for confirmation of the write. It’s literally the same thing. It’s just writing a cache line to RAM is orders of magnitude faster than writing a disk sector to storage, even with NVME SSDs. Octane is/was somewhere in the middle.

> They both involve flushing cache to backing stores, and waiting for confirmation of the write.

No they don't. A fence only imposes ordering. It's instant. It can increase the chance of a stall when it forbids certain optimizations, but it won't cause a stall by itself.

CLWB is a small flush, but as tanelpoder explained the more recent CPUs did not need CLWB.

Re: Rest in Peace, Optane

#117
post #22

Earlier quoted context omitted.

Knowing apple’s marketing moves, they could definitely do that: just use a single number to describe memory. And then pretend it’s a big number.

I can already see it: base 128GB of total system unified memory for your files and data.

Keep all other files in iCloud for big money. Genius

Re: Rest in Peace, Optane

#118
post #68

Earlier quoted context omitted.

The Xbox360 already had unified memory too. That gave it a slight edge compared to the PS3 in the long term because it was more flexible compared to a fixed 50:50 split.

The original xbox before it too.

And the N64 before them. I think it was the first console with unified memory.

Re: Rest in Peace, Optane

#119

My HP laptop came with optane memory, as far as I could tell, it was nothing special. I eventually pulled it to upgrade to a Terabyte ssd

I also had one. 1tb+octane cache.

It actually was a net decrease in performance! The reason is that first writes would saturate the cache SSD. Then the octane driver software must manually flush the cache to the main SSD.

What happened was that the laptop CPU actually heated up faster doing this, and reached throttle temps sooner.

I disabled the optane function and the performance increased to something typical.

Re: Rest in Peace, Optane

#120

Why was everyone so obsessed with the idea of Optane as universal memory? From a consumer perspective, it was a fast small SSD that doesn't wear out. That was enough to justify it's value at the prices it went for(Or at least it seems like it, I never personally used it). It didn't need any radical rethink of computing to be worth it. I'm not even a fan of the nonvolatile RAM idea. Rebooting is often the first thing…

> Rebooting is often the first thing we do to fix stuff. Depends on the environment. That used to be the common approach for windows, less so for *nix systems.

Linux is pretty good now about not having the whole system lock up, but restarting programs still seems to be the #1 troubleshooting action.
Post reply on HN