On April 14, the SNIA Compute Memory and Storage Initiative (CMSI) held a webcast asking the question – Do You Wanna Program Persistent Memory? We had some answers in the affirmative – answering the call of the NVDIMM Programming Challenge.
The Challenge utilizes a set of systems SNIA provides for the development of applications that take advantage of persistent memory. These systems support persistent memory types that can utilize the SNIA Persistent Memory Programming Model, and that are also supported by the Persistent Memory Development Kit (PMDK) Libraries.
The NVDIMM Programming Challenge seeks innovative applications and tools that showcase the features persistent memory will enable. Submissions are judged by a panel of SNIA leaders and individual contest sponsors. Judging is scheduled at the convenience of the submitter and judges, and done via conference call. The program or results should be able to be visually demonstrated using remote access to a PM-enabled server.
NVDIMM Programming Challenge participant Steve Heller from Chrysalis Software joined the webcast to discuss the Three Misses Hash Table, which uses persistent memory to store large amounts of data that greatly increases the speed of data access for programs that use it. During the webcast a small number of questions came up that this blog answers, and we’ve also provided answers to subjects stimulated by our conversation.
Q: What are the rules/conditions to access SNIA PM hardware test system to get hands on experience? What kind of PM hardware is there? Windows/Linux?
A: Persistent memory, such as NVDIMM or Intel Optane memory, enables many new capabilities in server systems. The speed of storage in the memory tier is one example, as is the ability to hold and recover data over system or application resets. The programming challenge is seeking innovative applications and tools that showcase the features persistent memory will enable.
The specific systems for the different challenges will vary depending on the focus. The current system is built using NVDIMM-N. Users are given their own Linux container with simple examples in a web-based interface. The users can also work directly in the Linux shell if they are comfortable with it.
Q: During the presentation there was a discussion on why it was important to look for “corner cases” when developing programs using Persistent Memory instead of regular storage. Would you elaborate on this?
A: As you can see in the chart at the top of the blog post, persistent memory significantly reduces the amount of time to access a piece of data in stored memory. As such, the amount of time that the program normally takes to process the data becomes much more important. Programs that are used to data retrieval taking a significant amount of time can then occasionally absorb a “processing” performance hit that an extended data sort might imply. Simply porting a file system access to persistent memory could result in strange performance bottlenecks, and potentially introduce race conditions or strange bugs in the software. The rewards of fixing these issues will be significant performance, as demonstrated in the webcast.
Q: Can you please comment on the scalability of your HashMap implementation, both on a single socket and across multiple sockets?
The implementation is single threaded. Multiple threading poses lots of overhead and opportunity for mistakes. It is easy to saturate performance that only persistent memory can provide. There is likely no benefit to the hash table in going multi-threaded. It is not impossible – one could do an example of a hash table per volume. I have run across multiple sockets that were slower with an 8% to 10% variation in performance in an earlier version. There are potential cache pollution issues with going multi-threaded as well.
The existing implementation will scale one to 15 billion records, and we would see the same thing if we have enough storage. The implementation does not use much RAM if it does not cache the index. It only uses 100mb of RAM for test data and does not use memory.
Q: How would you compare your approach to having smarter compilers that are address aware of “preferred” addresses to exploit faster memories?
The Three Misses implementation invented three new storage management algorithms. I don’t believe that compilers can invent new storage algorithms. Compilers are much improved since their beginnings 50+ years ago when you could not mix integers and floating-point numbers, but they cannot figure out how to minimize accesses. Smart compilers will probably not help solve this specific problem.
The SNIA CMSI is continuing its efforts on persistent memory programming. If you’re interested in learning more about persistent memory programming, you can contact us at pmhackathon@snia.org to get updates on existing contests or programming workshops. Additionally, SNIA would be willing to work with you to host physical or virtual programming workshops.
Please view the webcast and contact us with any questions.
