Где-то-в-инетахТехнологии постоянной памяти (PM) позволяют использовать в новых серверах второго поколения Intel® Xeon® Scalable запоминающие устройства с атрибутами как хранилища, так и памяти (Storage Class Memory, SCM – память как класс хранилища). Модули постоянной памяти на основе технологии 3D XPoint™ с интерфейсом DDR4 по пропускной способности и задержкам приближаются к традиционным DRAM модулям памяти (одновременно поддерживая побайтную адресацию, а также подключение по DDR шине), но являются энергонезависимыми, как SSD или HHD диски

Постоянная память от Intel (Intel® Optane™ DC) может использоваться в трех режимах (модах):
Memory Mode – байт адресуемая память, видимая операционной системой и приложениями как обычное ОЗУ;
App Direct (application direct) – побайтноадресуемое хранилище, видимое как DAX filesystem и требующее от приложений умения с ним работать;
Storage over App Direct mode – блочное хранилище, видимое ОС и приложениями как обычный диск.
В одном сервере Intel® Optane™ DC может использо ваться сразу в нескольких режимах.



Это нужно в подфоруме C просить. Пусть автор и владелец "вектора на триллион" протестирует и нам расскажет )))
У меня дома всего лишь Athlon с 8 Gb, мне не до Optane )))

mayton,
вряд ли

1) кроме ноутбуков существуют еще сервера и хранилища данных
2) последовательный доступ всегда был и будет быстрее случайного. Даже, внезапно, на RAM. Старенькая РУ5 в Zx Spectrum с 64 Kbit памяти и то имела циклы: установка адреса строки, установка адреса колонки/ячейке в строке, запись или чтение данных. Соответственно, последовательный доступ был быстрее, т.к. адрес строки банально не нужно было менять/передавать в микросхему.

Подозреваю, в современной памяти все так же, только еще хуже ))). Интерфейсы взаимодействия между блоками компьютера все более и более из паралелльных становятся последовательными. Throughtinput возрастает, а latency или то же или даже замедляется.

Для RAM, скорее всего (точно не знаю), размер оптимального блока 64 байта - размер строки cache линии процессора
Для SSD - 512/4Kb на чтение и 64/256 Kb (или больше) на запись
Для жестких дисков и RAID массивы - мегабайты

и даже, от самой ячейки это не сильно зависит, т.к. между ячейкой памяти и процессором еще будут располагаться:
IDE / SATA / SCSII - контроллер массива, дисковой полки - FibreChannel / SCSII / Inifiniband / Ethernet - свитч и метры кабеля - плата / контроллер в компьютере - PCI-E - процессор

Все инфраструктуру на DDR4-микросхему не запихать, а даже если и запихать ))), даже для обычной RAM, в многопроцессорных конфигурациях тут же на NUMA наталкиваемся. Когда даже доступ к оперативной памяти может подразделяться на "своя память" и "чужая память"

Т.ч. пока вместо упрощения иерархии доступа к памяти, существует потребность еще более усложнить иерархию памяти. Т.к. например адекватной поддержки NUMA в средствах разработки и языках программирования, вот лично я не знаю. Взять Java, видел ряд работ в Инете, где пытались Heap и Thread под NUMA оптимизировал, не получилось... получилось хуже, чем работать с усредненной памятью. Усредненной, это когда или повезет и попадется быстрая или не повезет и попадется медленная ))) - но в среднем, все более-менее работает.

IMHO

Оно уже с DOS "коробочно", утилита SMARTDRV.EXE )))

Какая разница какое API верхнего уровня. Беда то, что на нижнем уровне все равно нужно преврашать "отдельные байты" в _блоки_ _большего_ размера, иначе производительность будет ниже плинтуса (упремся в latency, а нам нужно максимально выбрать through input шины / устройства).

Для передачи данных через интерфейсы, что DDR, что SATA, что Ethernet / SoE / etc, байт совершенно неподходящий размер блока, поэтому необходимость кэшей на всех уровнях никуда не девается, что RAM - аппаратный кэш процессора, что диски и файловая система и меммори маппед - програмный кэш ОС и аппаратный кэш RAID.

От смены API на другое (обычный ФС на меммори маппед), ничего не меняется и не поменяется !

Может, только, программистам станет чуть удобнее. Но, как показывает мой опыт, попытка сделать что-то удобнее для программиста ==> меньше думаем и больше делаем хрени )))

IMHO