In my infinite stupidity I've replied to this mailing group without
properly subscribing. Sorry for the duplicates.

Full disclosure: I work at Intel on the set of libraries mentioned above.

Our project is fully hardware agnostic - any set of NVDIMMs is going to
work. This is a new tier of memory between transient RAM and storage SSD's.
It combines the features of both, NVDIMMs provide memory that is both
byte addressable and persistent across power failures. The speed and other
characterstics are obviously vendor dependent. The term I've seen some
people use to describe this new memory is "storage class memory" and I
think it really captures the intended use case.

There are currently few NVDIMM providers - you might recall recent HP
announcement about their new non-volatile memory enabled servers.
Also a company called Plexistor is providing software-defined persistent
memory solutions.

As for Intel offering in this space: the 3D XPoint announcement happend
few months back and it was widely covered by the media. Here are two nice
presentations:
http://www.snia.org/sites/default/files/NVM/2016/presentations/RickCoulson_All_the_Ways_3D_XPoint_Impacts.pdf
http://www.snia.org/sites/default/files/SDC15_presentations/persistant_mem/JimHandy_Understanding_the-Intel.pdf

If anyone finds this topic interesting I recommend checking out our website
pmem.io and the going through the presentations presented at various
SNIA organized NVM Summits:
http://www.snia.org/events/non-volatile-memory-nvm-summit
Also, the SNIA programming model is something else to look at after some
initial reading:
http://www.snia.org/tech_activities/standards/curr_standards/npm
It's what the NVML is based on.

Hope that this clarifies some things.

Piotr

W dniu czwartek, 19 maja 2016 09:28:07 UTC+2 użytkownik Greg Ewing napisał:

Terry Reedy wrote:
> Because each is an O(n) operation.  I was thinking of non-volatile
> writes as been relatively slow and in some sense more costly, but maybe
> that is not necessarily the case for new designs.

Large flash memories are usually organised into blocks, like
a disk. Writing a block is relatively slow, so you'd want to
buffer up your changes and write as much as you can in one go.

For Python objects, that would probably mean keeping a
shadow copy in RAM and flushing it to NV storage periodically.
Techniques similar to those used in relational databases
might be needed to ensure that the contents of the storage
remains consistent in the event of failures.

--
Greg
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/