[HN Gopher] Performance of Persistent Memory: 300 nanoseconds
___________________________________________________________________
Performance of Persistent Memory: 300 nanoseconds
Author : pbalcer
Score : 77 points
Date : 2020-05-13 12:23 UTC (1 days ago)
(HTM) web link (pmem.io)
(TXT) w3m dump (pmem.io)
| kragen wrote:
| I don't know about this persistent memory thing, but I sure want
| one of the tape drives this guy uses that can seek to anywhere on
| the tape in [?]100ms. (It says ~100ms, but I feel sure that
| that's a typo -- ~100 is -101, after all, and it's even more
| improbable that his tape drive is a time-travel device.)
| pbalcer wrote:
| OP here, yes - you are right, mea culpa. I'll try to correct
| that particular picture.
|
| Thanks for pointing it out.
| kragen wrote:
| While you're at it, maybe you could fix the Y-axis scale on
| that graphic. It's more like something from Soviet-era Pravda
| than something from a company I'd want to design my CPU.
| Logarithmic scales are all very well, that 10-100 ms is
| absolutely not the same distance from <1 ms* as ~80-100 ns
| is. (And for some reason the latency numbers are labeling
| horizontal separator lines, while the memory types are in
| between those lines, falsely suggesting that, for example,
| "DDR DRAM" occupies the range between 1-10ns and
| "~80-100ns".) Also, "m" is the SI symbol for "micro", not
| "u". And what is "Bock Granularity"?
|
| The whole graphic is just a train-wreck of carelessness and
| unconcern for accuracy. It reframes the entire post as an
| exercise in marketing (to people without critical thinking
| skills) rather than a source of reliable technical
| information.
| craftinator wrote:
| Oh, the pedantry is strong on HN today!
| kragen wrote:
| What is your comment intended to add to this discussion?
|
| It's not pedantry to point out that tape drives do not have
| hundred-millisecond access latency. That's low by two or
| three orders of magnitude; hardly a pedantic distinction --
| it's as large as the difference between SSDs and spinning
| rust. By contrast, it would be pedantic to complain, for
| example, that many spinning-rust disks now have access
| latencies closer to 8ms than to 10ms.
| Arnavion wrote:
| >It says ~100ms, but I feel sure that that's a typo -- ~100 is
| -101
|
| Using tilde to mean "approximately" is way more common than
| using it to mean "bitwise-negation in two's complement", not in
| the least because the latter meaning is specific to programming
| and even more specific to certain programming languages.
| cogman10 wrote:
| Not even programming language but in fact hardware
| architectures. While everything now-a-days does twos
| compliment there were a few early architectures that did ones
| compliment and a few that did just signed bits (Heck, IEEE
| 754 floats use signed bits, not two's complement. But that's
| mostly because there are no advantages AFAIK to a two's
| complement float)
| kragen wrote:
| I would be surprised to learn that there were
| implementations of C on sign-magnitude or one's-complement
| architectures that implemented "~" as anything other than
| bit inversion interpreted in two's-complement, and yet were
| sufficiently compatible that they could run large C
| programs developed on more traditional architectures. Are
| you familiar with any?
|
| C does not permit the application of "~" to floating-point
| numbers. JS does, but it converts them to integers first,
| and interprets it as bit inversion in two's-complement.
| AnimalMuppet wrote:
| If I understand correctly, ~ means raw "invert the bits".
| Two's complement doesn't enter into the picture - it
| relates to how the bits are interpreted, which is a layer
| above what ~ does. One's complement, two's complement,
| unsigned... we don't care, _just invert the bits_.
| sudosysgen wrote:
| This is a good point. Tape drives can have latencies in the
| seconds, if you're doing anything but sequential operations.
| Rafuino wrote:
| Part 2 is here: https://pmem.io/2020/03/26/performance-2.html
| danharaj wrote:
| I think it would be fun to futz around with persistent memory but
| AFAIK it would mean working specifically with Intel tech. Will
| there be a point in time when I will be able to program against
| something that's not Optane as well with the same interface?
| wmf wrote:
| Probably not. 3D XPoint can't be used in non-Intel DIMMs due to
| licensing. Samsung and Micron gave up on PCM. MRAM isn't dense
| enough. IBM has done a lot of research on non-DRAM DIMMs but
| none of it can come to market without suitable media.
| loeg wrote:
| There are NVDIMMs that are just DRAM with a battery/supercap
| and some NAND to store on powerloss that implement the same
| spec.
| pbalcer wrote:
| Disclaimer: I work at Intel on Persistent Memory
|
| If you are asking just about the OS interfaces - you can
| already emulate persistent memory with DRAM [1], which allows
| you to play around with the programming model. There are also
| NVDIMM-N devices available on the market today that expose the
| same interface. IBM also has a product called Virtual
| Persistent Memory [2].
|
| I expect that once CXL [3] becomes adopted, there will be more
| diversity in terms of Persistent Memory hardware vendors.
|
| [1] - https://docs.pmem.io/persistent-memory/getting-started-
| guide...
|
| [2] - https://www.ibm.com/downloads/cas/09ERZEVQ
|
| [3] - https://pirl.nvsl.io/PIRL2019-content/PIRL-2019-Stephen-
| Bate...
| danharaj wrote:
| Thank you! My question was deliberately vague but you hit all
| the points I cared about and gave me keywords to read further
| about.
| trentnelson wrote:
| Can you share anything public about when the consumer-level
| gear is going to hit the market?
___________________________________________________________________
(page generated 2020-05-14 23:01 UTC)