When it comes to persistent memory, many application developers initially think of change as hard work that likely yields incremental result. It’s perhaps a better idea to look at the capability that’s new, but that’s already easily accessible using the methods that are in place today. It’s not that enabling persistent memory is effortless, it’s more that normal code improvement can take advantage of the new features in the standard course of development.
The concept of multiple memory tiers is ingrained in nearly every programming model. While the matrix of possibility can get fairly complex, it’s worth looking at three variables of the memory model. The first is the access type, either via load/store or block operation. The second is the latency or distance from the processing units; in this case the focus would be on the DIMM. The last would be memory persistence.
Adding persistence to the DIMM tier of memory provides opportunity to programmers in a variety of ways. Typically, this latency is used for most of the program flow, while data eventually is moved to a farther tier such as disk or network for persistence. Allocating the majority of data to a low-latency tier like a DIMM has significant potential.
An example of this in the marketplace would be SAP’s HANA in-memory database. However, it’s less well-known that more traditional database products in the same category have built-in methodologies for moving data that is repeatedly accessed into the DIMM tier, later committing changes to storage via background processes. It’s likely that adding persistence to DIMMs in volume would be both valuable and also architecturally possible in a short period of development time.
One way that this process is simplified for developers is the fact that the SNIA NVM Programming Model for DIMM-based persistence incorporates both load/store and block access modes. Developers already familiar with using SSD over rotating media — that would be a fourth memory vector, deal with the ambiguity — would be able to see some incremental performance and potentially some system design simplification. Those already using memory for data storage could utilize better recovery options as well as explore changes that high-performance storage could bring.
Join other developers on Wednesday, January 23rd at the
SNIA Persistent Memory Programming Hackathon to explore options for how your software can take advantage of this new opportunity. Complimentary registration is available at this link.