Live data from Hacker News

Why Intel is adding instructions to speed up non-volatile memory

danluu.com

41–45 of 45 posts

Re: Why Intel is adding instructions to speed up non-volatile memory

#41
post #32

Earlier quoted context omitted.

Yes, it is 100% plagiarized. The last sentence in the original text: "It doesn’t directly address the OS overhead issue, but that can, to a large extent, be worked around without extra hardware." Their modification: "It doesn’t directly address the OS overhead issue, but that can, to an astronomically immense extent, be worked around without extra hardware."

It looks like the original text was automatically processed by replacing various words by their synonyms from a thesaurus, leading to hilariously non-idiomatic prose.

Artificial Awkwardness. It was bound to happen.

Re: Why Intel is adding instructions to speed up non-volatile memory

#42
post #28
post #12

There are several storage class memories that are nearing commercialization. Intel is betting big on at least one of them. Most technologies in this class are orders of magnitude faster and have orders of magnitude better endurance than flash memory, while being only slightly slower the DRAM, yet non-volatile. It is plausible that with another layer of in-package cache they could eliminate DRAM altogether, replacing…

> There are several storage class memories that are nearing commercialization. I'm very interested in this. Could you point out which technologies that are near ready for commercialization? My understanding is that the current cost is orders of magnitude higher per unit of storage for these new technologies compared to NAND flash or even DDR3 RAM. But of course, a dedicated fab could change that very quickly.

Well nvDIMMs are available right now (from companies like Netlist, Agigatech, Viking, Smart, Micron). This is DRAM with an analog switch, a controller and flash memory. When you lose power, the DRAM is disconnected from the processor and the contents are copied to the flash. The newer technology might be cheaper, but I thought so far the write performance is not as good as DRAM.

The issue is the cache: the data is not non-volatile until it has been written back to DRAM. Even then, you need some advanced warning of a power outage for it all to work.

Unibus (bus for PDP-11 core memory systems) had an early warning signal, to give the memory controller a chance to write back the previous (destructive) read.

Re: Why Intel is adding instructions to speed up non-volatile memory

#43
Support for non-voltile memory needs to be added to Linux. For example, one should be able to map the non-volatile memory into user space and directly access it. There needs to be some BIOS-OS interaction so that the OS doesn't treat the non-volatile memory as general memory (for the likely case where only some of the memory is non-volatile). Alternatively, the non-volatile memory should be usable as a block device.

The non-volatile memory needs a layer of RAID-like volume management. For example, when you transfer the memory from one system to another, there should be a way to determine that the memory is inserted in the correct slots (remember there is RAID like interleaving/striping across memory modules).

Re: Why Intel is adding instructions to speed up non-volatile memory

#44
post #4
post #3

Earlier quoted context omitted.

if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).

Long story short, memory bandwidth is much faster than the best x86 crypto implementations can handle. Encrypting disks or network is no problem today, but we'll need architectural changes to support full memory encryption without a performance hit.

The VIA C7 AES implementation could keep up with memory (ca. 20Gb/s). With suitable cipher modes you can use multiple pipelined units in parallel with negligible overhead.

Re: Why Intel is adding instructions to speed up non-volatile memory

#45
post #31
post #14

Earlier quoted context omitted.

The theoretical maximum for current chips is less than 16 bytes per cycle. On Haswell you can process (in parallel) 7 blocks in roughly the time it would take to process 1. The latency of each round is 7 cycles, a full AES-128 10 rounds is ~70 cycles, so effectively you can process at most 1.6 bytes per cycle, or 1.14 if you use 256-bit keys (ignoring the cost of key scheduling and overhead here). Even if you dedicat…

Do you believe it's reasonable to assume that AES performance will remain constant over the same 5-7 year timeframe? That's at least a couple of hardware generations for an improvement they could make in the current generation if there was a market for it.

There is certainly room for improvement, but I don't see an 16x speedup happening on a 5-year horizon using the current AES-NI instruction set.
Post reply on HN