D1031R1 draft 1 of proposed C++ object model and lifetime changes for persistent memory support

[Niall Douglas]

pmem list members may find draft 1 of the proposed C++ object model and lifetime changes for persistent memory support of interest. So far nobody has blown holes in it, which suggests that the proposed changes are being taken seriously.

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/bk8esqk-Qoo

Explicit persistent memory support is minimal, but you do finally get legal use of mapped memory, which is currently undefined behaviour. Baby steps forward.

Niall

[st...@steveheller.org]

Wow, that looks great!

I'm only on page 7 of your proposal and you have already answered a question that has been bothering me ever since I heard about the Optane PM module and started trying to figure out how to use it optimally. That question is whether I will be able to extend a memory map for a memory-mapped file quickly and easily, as I could with a "regular" file in a file system.

The reason this is important to me is that I have a user mode virtual memory library that is begging for this device. It provides access to essentially unlimited amounts of data as though they were memory-resident, including vectors and maps of variable-length binary strings. Obviously optimal use of the PM module will improve my already good performance by orders of magnitude for small data elements.

Would it be possible for you to look at what I have? I have attached a brief description of the library.

[st...@steveheller.org]

I think I have found a typo in that paper. On page 18. it says "Usually, but not always, mapped storage is a memory cache of equivalent storage a high latency storage device."

Is there a missing word in that sentence?

[Niall Douglas]

On Monday, August 6, 2018 at 11:29:03 PM UTC+1, st...@steveheller.org wrote:

I'm only on page 7 of your proposal and you have already answered a question that has been bothering me ever since I heard about the Optane PM module and started trying to figure out how to use it optimally. That question is whether I will be able to extend a memory map for a memory-mapped file quickly and easily, as I could with a "regular" file in a file system.

You can extend a map into reserved address space without issue on the major platforms. Though, on Microsoft Windows, one must resort to an undocumented NT kernel API.

I've raised with Microsoft getting that API documented, they don't object in principle. They use it themselves extensively, and it's been stable since the NT 3.x days.

 

The reason this is important to me is that I have a user mode virtual memory library that is begging for this device. It provides access to essentially unlimited amounts of data as though they were memory-resident, including vectors and maps of variable-length binary strings. Obviously optimal use of the PM module will improve my already good performance by orders of magnitude for small data elements.

Would it be possible for you to look at what I have? I have attached a brief description of the library.

I can tell you that the standards committee won't be interested in anything which doesn't work well on spinning rust, as well as persistent memory. In fact, a quick straw poll of the committee found that almost nobody felt persistent memory worth doing anything about, even fewer than a similar poll on Reddit /r/cpp.

I have often said that until Apple ship a MacBook Pro with all persistent memory, nobody will consider it anything but a very niche technology. When Apple do do this, then it'll snowball.

In terms of your algorithms, it's easy enough to make a write-once read-many implementation. It gets much harder when you allow modification where sudden power loss can occur. You can take a "heavy" approach like the PMDK does, where one uses elements of database theory to implement a suite of algorithms. Or one can take a "light" approach, which exchanges algorithmic intrusiveness for performance. There is a real lack of empirical experience outside Intel for the latter, and I suspect there may be a future when such experience is as rare and valuable as Ethereum smart contract experience, most of whom are earning more than a million a year.

So in response to your library, I think that you need to start with a well defined set of design goals, and a well defined set of things that you won't be doing e.g. power loss recoverability. I'd also be thinking not in terms of strings, but in terms of fixed or arbitrary length sequences of bytes, taking care that these align to cache line boundaries if that is important. Finally, please do leverage C++ 20, for missing library functionality there are standalone C++ 11 or 14 implementations without having to drag in something like Boost.

Regarding the missing word in paper, it's fixed. Thanks for reporting it!

Niall