Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

danluu.com

Post reply on HN
Print view View original

31–40 of 45 posts

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

#31

Post by acdha »

pbsd wrote: post #14
eloff wrote: post #8

Earlier quoted context omitted.

How do you square that with the performance of the AES-NI instructions? That is theoretically 16 bytes per cycle from the manual. Per core. That is way in excess of memory bandwidth, even with DDR4.

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.

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

#32

Post by acqq »

6cxs2hd6 wrote: post #30
abhaybhuva wrote: post #29

Full coverage is here: http://www.improgrammer.net/intel-adding-instructions-speed-...

I'm downvoting your comment because - that seems to be copy and pasted (i.e. plagiarized) from the original blog post http://danluu.com/clwb-pcommit/ - your submission history suggests you are associated with improgrammer.net

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

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

#33

Post by 0x0 »

signa11 wrote: post #24
0x0 wrote: post #23

Isn't there a higher risk of data loss, if your "hard drive" is 100% memory mapped - all it would take is one buggy kernel driver writing to an invalid pointer or memset'ing the whole thing to 0?

well, the same is true now as well right ? for example, a buggy driver can override a buffer-cache pointer with something else, and then you are hosed. if you are playing in the kernel-land and not careful enough, you are courting disaster...

True, but if it overruns a buffer, it still needs to maintain a valid SCSI/ATAPI/whatever command packet format and submit the packet to the controller with repeatedly increasing block numbers - that's a lot of instructions, while something that clears the entire address space could probably be done in 1-2 assembly instructions (mov rcx, -1; rep stosq)

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

#34

Post by 8957a7e86 »

acqq wrote: post #32
6cxs2hd6 wrote: post #30

Earlier quoted context omitted.

I'm downvoting your comment because - that seems to be copy and pasted (i.e. plagiarized) from the original blog post http://danluu.com/clwb-pcommit/ - your submission history suggests you are associated with improgrammer.net

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.

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

#35

Post by eloff »

pbsd wrote: post #14
eloff wrote: post #8

Earlier quoted context omitted.

How do you square that with the performance of the AES-NI instructions? That is theoretically 16 bytes per cycle from the manual. Per core. That is way in excess of memory bandwidth, even with DDR4.

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…

Ah, I was forgetting about rounds, you're correct that you won't be able to match the memory bandwidth then.

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

#36

Post by bahahah »

runeks wrote: post #28
bahahah wrote: 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.

Components are available on the market now based on PCM, MRAM, and FRAM. I know that Intel has large productization, not research, teams working on a variant of SCM. Near means 2-3 years though. Research exit to market ready is always a 3-5 year cycle when process engineering is involved.

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

#37

Post by rbanffy »

harshreality wrote: post #18
Animats wrote: post #5

Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems. There are alternatives.…

Can't use current flash chips in that way, because write endurance.

Also, current Flash memories do not allow single address writes. At least the write endurance problem could be addressed by adding write leveling to an address translation layer. The single address thing could be addressed by a caching/grouping layer that could interact with the leveling mechanisms. Add to that an all-core state dump to a block write and you can recover to an internally consistent state after a power failure.

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

#38

Post by rbanffy »

Animats wrote: post #5

Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems. There are alternatives.…

Don't forget core memory existed before rotating disks. The first internet routers were shipped with their program already loaded.

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

#39

Post by dang »

6cxs2hd6 wrote: post #30
abhaybhuva wrote: post #29

Full coverage is here: http://www.improgrammer.net/intel-adding-instructions-speed-...

I'm downvoting your comment because - that seems to be copy and pasted (i.e. plagiarized) from the original blog post http://danluu.com/clwb-pcommit/ - your submission history suggests you are associated with improgrammer.net

Ouch, that's bad. Also, plagiarizing luu doesn't sit well around these parts. That's the home team!

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

#40

Post by rbanffy »

JoeAltmaier wrote: post #27
shaurz wrote: post #22

How to solve the context switch overhead issue: https://www.destroyallsoftware.com/talks/the-birth-and-death...

How about: a cpu that has scores of hyperthreads? They don't block in the kernel; they stall on a semaphore register bitmask. That mask can include timer register matches another register; interrupt complete; event signaled. Now I can do almost all of my I/o, timer and inter-process synchronization without ever entering a kernel or swapping out thread context. I've been waiting for this chip since the Z80.

While not exactly a chip (it never reached board stage) I designed a processor in college where the register file was keyed to a task-id register. This way, context switches could take no longer than an unconditional jump.

I dropped this feature when I switched to a single-task stack-based machine (inspired by my adventures with GraFORTH - thank you, Paul Lutus). This ended up being my graduation project.

Post reply on HN