Hacker News Reader

Comment by rob74 | Hacker News Reader

The article does however mention the basic issue which led to Optane's failure (at least if I understand it correctly): that all current OSes have a concept of primary and secondary storage, whereas for getting optimal performance out of Optane, you need to have several levels of memory storage (which apparently have to be managed by the OS, as opposed to CPU caches): a program's code can stay in the Optane memory, while the stack and heap have to be in "real" RAM to reduce wear on the Optane memory when the program is executed? So Intel would have had to develop an OS for it, or worked on extending e.g. the Linux kernel in that direction.

View on HN

FWIW this article, like The Register articles of olde, did bring this point up.

Multics had this concept back 60 years ago; like many useful Multics ideas (cough security) it was jettisoned in Unix. Most interestingly, Organick’s book describes a hierarchy of fast to slow, with the slowest being tape backup :-).

More recently HP’s “The Machine” was designed this way — the article touches on this but if you don’t know what they are talking about that HP paragraph looks like it was accidentally jammed in.

With the increased use of databases and key stores plus the dominance of mobile platforms, this single store model will probably be back.

> like The Register articles of olde

Coo, thanks!

That is what I'm going for, yes. :-) Or at least, when I have the time, it is, anyway...

(If it's not obvious, I wrote the linked article.)

El reg has had two truly great writers in its history; perhaps you'll be the third!

Oh my word. I am honoured.

JOOI: who are you thinking of? I rate Orlowski, even though I disagree with Andrew about a lot of stuff IRL.

> or worked on extending e.g. the Linux kernel in that direction.

Iirc Intel was the biggest code contributor for 2021 to the kernel. So they already have the expertise.

Running code from Optane would likely be a mistake, though. Jumps would be very expensive due to the extra latency (unless they hit the cache). Perhaps it can work with page swaps but still.

There's already plenty of code to handle NUMA, it shouldn't have been too hard to add proper support for that.

It adds another layer - while NUMA is about latencies, Optane memory is about latency AND how frequently the information is changed (to minimize wear on the device). There are some obvious signals (disk caches would be one), but richer semantics would help a lot to make it perform.

I am a bit ignorant in OS stuff but isnt that managed by the filesystem? I think some people were using them as LOG drives in ZFS fs.

Be wary mixing Optane drives (what you seem to be referring to) and Optane memory (parent commenter).

That's described in the article, that they could be used in Linux, but only as a volume. Apparently (if I read the article correctly) that wasn't optimal for exploiting the higher performance.

As I understand it Linux's VFS and Block layer aren't really designed to exploit the type of throughput and latency that Optane provided.

What I'm curious about is what happened to all the PMem (Persistent Memory) and NVRAM (Non-volatile RAM) work that went into recent Linux kernels and libraries.

I thought that with DAX, it was possible to have a real file system, but access to the actual bits goes straight to the backing storage, not the page cache (as it would with traditional block devices). So the block layer and VFS inefficiencies would not necessarily matter, at least if you can use DAX.

> Apparently (if I read the article correctly) that wasn't optimal for exploiting the higher performance.

That can be compensated by tuning the price point. If the performance isn't there, make it cheaper until it's better than the alternatives.

This is Itanium all over again

Itanium was a bet on compilers being able to extract parallelism from the source code. Maybe JIT optimizations, where code is rewritten on the fly, more or less the same way as a reordering buffer works, would have done the trick, but, in the end, Itanium fell short of its performance promises. I'm not sure compilers alone can do it.

The trouble with Itanium was that memory latency is a limiting factor. A CPU knows what is in the cache but the compiler doesn’t. In fact, a major use of parallelism in CPUs is to hide latency and that involves a flexibility of scheduling greater than bundling groups of instructions together. (Think of 3 instructions hanging because 1 needs to load something as opposed to a system which might be able to barrel on and run a few non-dependent instructions.)

> A CPU knows what is in the cache but the compiler doesn’t.

You could kind of try to sidestep that by inserting preload instructions ahead of the instructions that would use the values but I agree that doing that at runtime would probably be better. Maybe a JIT runtime could help, but, still, that's beyond the control of the compiler.

https://www.researchgate.net/publication/3044999_Beating_in-...

This one was never realized AFAIK, but addresses a lot of the latency issues of the IPF designs due to their relatively static nature. Still does not take the massive cost of reservation stations. I think being open will be a major requirement going forward. It is hard to build trust in a black box and RISC-V is about to become a real alternative. Being modular, open and growing up from smaller systems seems like a winning strategy to me.

I can't wait to have a completely Windows-proof desktop again (even though my last SPARC still has an x86 coprocessor board) and my IBM PPC machine had Windows NT for it.

I did some research on

https://en.wikipedia.org/wiki/Transport_triggered_architectu...

which is an approach to CPU design that puts specialized CPU design in the reach of quite a few people (say on an FPGA) but the main weakness of it is that it is not smart at all about fetching. Although it is not hard at all to make that kind of CPU N-wide you are certainly going to have all N lines wait for a fetch.

Seems to me though that that kind of system could be built with a custom fetcher that would let you work around some of the challenges.

Also a major issue was the big iron shared memory systems that Itanium targeted. They collectively fell out of favor with the trend towards Virtualised x64 commodity clusters and later the cloud. I’d love to see an EPIC strategy for a CPU targeted at smaller systems. Perhaps implementing webassembly based actors in hardware and support for messaging and pmem. Wasmcloud in hardware.

The way I see, disaggregation will be a thing and we may be back to large shared memory racks in cloud datacenters. While an individual cloud machine can range from small to very large (effectively one fully dedicated host) a rack-sized server enables much larger (and profitable) offerings. Scaling up has limits, but it's very comfortable to have the option when needed.

Hardly an Intel specific problem (frowns at Alpha)

Reply on news.ycombinator.com