Комментарии 57
Содержимое оперативной памяти будет сохраняться от выключения до следующего включения компьютера
То есть самый действенный сейчас метод починки поломок в ОС/программах перестанет работать (выкл/вкл)
Ну то есть по сути мы будем просто иметь эдакий супер-спящий режим - когда состояние оперативной памяти не надо сбрасывать на накопитель. Но тогда при старте именно процедуры БИОС должны будут запрашивать либо определять, запустить ОС "с нуля" или с текущего состояния - сама ОС этого сделать не сможет.
Плюс неминуемые сопутствующие проблемы с изменением аппаратной конфигурации либо состоянием/режимом аппаратных компонентов между выключением и последующим включением (отключение флешки, развал сетевого подключения, спящий режим монитора и пр.). Думаю, большинство программ будут не очень рады такому, с их точки зрения мгновенному, изменению... боюсь, что они просто будут вопить о неисправности аппаратуры и сыпаться.
Вообще-то периферия, о которой вы говорите, прямо таки нормально работает и прямо щас. Т.е. с точки зрения современной операционной система вытаскивание флешки или шнурка монитора прям щас, на ходу - не является чем-то запредельно сложным в обработке. А теперь следим за руками :) - остановка работающей машины и продолжение ее программы с того же места с точки зрения программы - не остановка. Следовательно - выключили (засуспендили) программу, вытащили флешку, включили - с точки зрения программы это всего лишь выдергивание флешки 'в процессе". Ничего страшного.
Совсем ничего страшного, если программа в этот момент вообще не общается с устройством. Насчёт флешки согласен - максимум получим армагеддон на самой флешке и сбой файловой операции в программе. А с подключенным устройством, которое требует для общения предварительных настроек/согласований или синхронизации операций ввода и вывода, всё будет не так шоколадно. Опять же сетевые протоколы, следящие, например, за последовательностью пакетов или штампами времени - развалятся. В общем, ПО обязано будет учитывать такие временнЫе лакуны в работе.
Ну вот для сетевого коннекшена отработка разрыва - чуть ли не штатная процедура которая по уму должна поддерживаться на уровне приложения (пре-подключения ретраи и все такое).
Если все это правильно реализовать на уровне драйверов, то приложению вообще будет пофиг на все это - оно будет запрашивать получать и обрабатывать не обращая внимания на то, когда оно было остановлено и запущено. Вот другое дело что отправленный пакет данных после сна может с большой вероятностью оказаться уже сильно outdated - но это опять же не проблема, при правильно написанном сетевом стеке.
Почему только сейчас об этом говорите а не 15 лет назад когда флешки начали свое господство после сд дисков?
Ага, выключил компьютер, вытащил флешку, ушёл на работу, подключил флешку к другому..., вернулся, воткнул обратно флешку, включил. ...Компьютер продолжил запись файла который был уже удалён на другом компьютере и на месте которого был создан новый... ой
Не совсем, так как всё состояние «компьютера», т.е. ОС путешествует вместе с «флешкой» в данной концепции.
Состояние это да, но флешки тоже никуда не денутся какое-то время. Тут вопрос во внешнем мире и переферии, которая может поменяться. Состояние компьютера становится некой монадой как в хаскеле которая взаимодействует с внешним миром, который может неожиданно поменяться пока компьютер спит. Мышка была, а теперь на её месте клавиатура и тп. Система должна получать на уровне железа какой-то сигнал когда включается и заново сканировать и инициализировать всю переферию, отменяя все активные операции.
А ведь это можно и сделать и сейчас, спроектировав энергонезависимое питание контроллера памяти DRAM.
Потребуются ОС и программное обеспечение с совершенно иной компьютерной архитектурой
Это ещё зачем? Чем существующие не устраивают?
del. не туда
Базовая поддержка в ядре - это конечно, хорошо, но дальше нужно либо полностью писать поддержку на пользовательском уровне (ядро даст по сути только девайс с поддержкой DAX), либо добавлять в ОС удобные механизмы для написания PM-specific кода. Скажем, делать что то типа IBM i (она же AS 400) с общим пространством объектов без разделения память/диск (реально на традиционном железе используется checkpointing). Упомянутый в статье Фантом задумывался похожим образом (по крайней мере во времена, когда dz писал в ЖЖ в основном на технические темы), и вроде он даже до сих пор развивается, но не знаю, насколько готов для реального использования.
Современные ОС созданы под фон-неймановскую архитектуру. Кажется, что наличие персистентной RAM принципиально ничего не должно менять. Могут появляться какие-то подсистемы более эффективных инкрементных состояний, но, по-сути, все сейчас уже готово. Вообще, особого профита с этого разработчики пока не увидели, как я понимаю: идея, конечно, красивая, храним все в памяти всегда, а про ФС просто забыли.
Однако, не совсем очевидны революционные преимущества, оптимизационные вполне понятны - прогрева меньше надо, но ведь и сбросить некорректное состояние уже не так тривиально.
Кажется, что прорывом будет - когда RAM станет сильно "ближе" к CPU или вообще совмещена с вычислителем (но это уже, возможно, не фон-неймановская архитектура).
Увы рэвольюции не будет.
Первое - вычислители у памяти это нейросети. Такое уже есть но стоит как крыло самолёта.
Второе - у памяти с CPU есть огромные, чисто физические проблемы. Первая это время задержки, она чисто физическая - чем больше память тем дольше время доступа к ней. Потому кэш L1 досихпор в +-30КБ делают, ибо так сохраняются нормальные задержки. Вторая проблема это невыровненых доступ к памяти. Из-за довольно фундаментальных проблем память может быть эффективно реализована только постранично-построчно, что напрочь убивает скорость рандомного доступа. На современных DRAM она что-то порядка 400МТ, в то время как выровненная может доходить до +5000МТ. У L-кэшей она в несколько раз выше, но невыровненый доступ также делает несколько циклов доступа к шине, что дропает скорость не в 10 раз но раза в 2 точно.
Из всех этих нюансов и возникает что единственный эффективный метод сделать универсальную ЭВМ это фигачить её память как бутерброд. В этом плане дна ещё не нащупали. Ибо пока инженеры осваивают L3 кэш в сотню мегабайт, умные дяди потирают ручки в ожидании L4 кэша со сверх широкой шиной в пару гигабайт. Так что всё ещё впереди.
Физически непонятно как делать память которая бы не была организованна постранично-построчно и имела нормальную пропускную способность/скорость доступа/время рандомного чтения. У любой существующей технологии есть только одна сильная сторона, но никогда несколько.
думаю, для нашего классического программного обеспечения это не даст какого-то существенного выигрыша, потому что нет прикладной проблемы, которую эта технология решает:
- десктопный софт всё равно будет иметь функции загрузки/сохранения для обмена данными или для "отката из бекапа"
- облачные пакеты вроде гугловых таблиц уже и так давно хранят состояние без нажатия "сохранить"
- серверное ПО работает за счёт бесперебойного энергоснабжения, а при возникновении проблем всё равно весь софт должен (и умеет) переинициализироваться
если нет реальной решаемой проблемы, то технология будет буксовать на внедрении, даже если технически всё уже будет возможно, на практике - будет никому не нужно
думаю, ближайшее будущее, где такая память может найти применение - это ИИ агенты, которые должны будут удерживать в памяти объёмы данных, не позволяющие перегружать их достаточно быстро из места постоянного хранения в нейроморфный чип для обработки
для таких систем может быть ценна возможность "уснуть" без потери состояния, удерживая какой-нибудь петабайтный/эксабайтный слепок состояния сознания прямо в нейроморфном чипе
если нет реальной решаемой проблемы, то технология будет буксовать на внедрении, даже если технически всё уже будет возможно, на практике - будет никому не нужно
сейчас вы файл открываете и читаете с диска используя буфер в цикле, а будете сразу указатель на данные получать. Это ли не zero-copy к которому все стремятся?
пример хороший, согласен
для баз данных такой подход действительно сулит много хорошего, по сути там давно есть запрос на возможность постоянного хранения больших объёмов данных со скоростью доступа как у оперативной памяти
однако, у меня есть несколько сомнений касательно экстраполяции того, по какому именно пути пойдёт прогресс
самое простое, при чтении данных конечная цель, как правило, состоит не в получении указателя на буфер данных в памяти, а инициализация/парсинг этих данных. zero-copy там будет в одном месте, но потом в процессе работы программы данные как правило неоднократно копируются, особенно с учётом современной всеобщей любви к иммутабельности и чистым функциям, в которых принято копировать все данные ради того чтобы поменять их часть. конечно, когда это будет реализовано как copy-on-write паттерн на уровне ядра - некоторый прогресс, скорее всего, будет достигнут, но обращу ваше внимание, что тот же copy-on-write был изобретён десятки лет назад, однако не привёл к автоматическому и повсеместному zero-copy, как об этом мечтали идеалисты fork подхода к порождению процессов
"zero-copy к которому все стремятся" - громкое заявление в прикладном контексте. утрирую, вот например, из моих коллег наверное примерно никто ни к какому zero-copy не стремится, а решают совсем другие задачи и проблемы. zero-copy это, безусловно, хорошее направление развития, как и, например, выше упомянутые чистые функции и иммутабельность. отрасль помаленьку становится умнее. но не стоит переоценивать прогресс, на 98% реальный бизнес заинтересован далеко не в красоте и эффективности концепций, а в эффективном производстве и продажах. Слишком быстрый рост прогресса и повсеместное применение космических технологий там где надо, и там где не надо (возьмём хоть микросервисный холивар) - часто, наоборот, вредят бизнесу. итого, я бы сказал, что 98% людей от ИТ не то что не стремятся к zero-copy, а даже и не в курсе про этот паттерн, они вместо этого заняты реальным миром и реально полезными вещами
следом за скоростью чтения данных автоматически встаёт вопрос о скорости их обработки. серверные CPU безусловно будут развивать многоядерность и дальше, но реальная следующая революция - уверен, в SIMD обработке данных на GPGPU или им подобных платформах. GPGPU эффективно работает только с памятью, расположенной очень рядом с чипом (а лучше - воообще на нём). Поэтому данные из CPU RAM копируются в GPU RAM для обработки и обратно, и по сравнению со скоростью, с которой GPU может их перелопатить - время переброса данных по шине примерно так же (в тысячи раз) медленнее, как время чтения данных с диска по сравнению с чтением их из CPU RAM. итого, к моменту когда где-то реально понадобятся петабайты энергонезависимой памяти со скоростью работы CPU RAM, будет стоять уже совсем другая проблема - как достичь от этой памяти скорости работы GPU RAM и разместить так близко к чипу, чтобы пропускная способность была достаточна для загрузки всех ядер. и снова получим ту же ситуацию - данные из "медленной" энергонезависимой CPU RAM будут грузится для обработки в быструю энергозависимую GPU RAM
когда дойдём до нейроморфных чипов, оптических компьютеров и, если повезёт, квантовых - цикл снова повторится. итого, разделение на медленную энергонезависимую доступную в большом объёме память и быструю энергозависимую доступную в небольшом объёме память - скорее всего будет сохраняться. приведённая выше технология решает проблему, которая уже почти успела устареть
Погуглите про mmap.
Под капотом mmap на обычном диске блочные операции. Персистентная память даёт возможность записывать отдельные кеш линейки. А так да, тот же интеловский 3DXPoint в персистентном режиме поддерживается в линуксе через mmap и DAX.
Не чувствую принципиальной разницы между "блоками читаем с диска в оперативку" и "кэшлиниями читаем из оперативы в кэш процессора". По сути получили просто двухуровневое кэширование (а если вспомнить что в современных процессорах несколько кэшей, то скорей четырёхуровневое).
Вопреки окружающей действительности в МФТИ имеются передовые разработки по этой теме на мировом уровне. Хотя конечно о коммерчески успешном внедрении, как это повелось ещё с СССР, говорить не приходится. И скорее всего получится "как всегда".
Это идеальный путь для развития компьютерных систем, так как он устраняет одно из фундаментальных противоречий современной компьютерной архитектуры.
Хоть бы написали, что за противоречие...
Естественно, софт должен писаться явно с использованием persistent memory. Есть, скажем, набор библиотек PMDK ( https://pmem.io/pmdk/ ) для упрощения реализации поддержки. Но основные сложности скорее в редизайне - для примера можно посмотреть описание поддержки PM в SAP HANA ( https://www.vldb.org/pvldb/vol10/p1754-andrei.pdf ) - не знаю, дошло ли оно до production.
А что конкретно сейчас на рынке есть из persistent memory? Интеловский 3DXPoint уже всё; у Микрона раздел на сайте есть, но конкретных моделей с ценами сходу не вижу.
HP вроде до сих пор продаёт планки стандарта NVDIMM.
Они на страничке Intel Optane упоминают, подозреваю что распродают остатки (ну или Интел для них по контракту обязался какое то время продолжать выпуск - в любом случае это ненадолго).
У HP была интересная идея архитектуры, по сути основанной на PM (The Machine), но там всё вроде осталось на стадии прототипа.
Интел все еще продает оптан. Но поскольку современные NVME по сути его догнали практически, это бесполезно.
Реклама оптана и новые разработки - свернуты.
Даже кеш из оптана - не взлетел, драм-буфер + батарейка все так же эффективнее.
В США интеловский оптан все так же доступен в планах хостинга IBM.
Помнится, в 10х годах обещали революцию с мемристорами. Где оно все сейчас?
Прошлая такая инициатива под названием Intel Optane провалилася, ибо 1) дорого 2) дорого 3) выигрышь минимальный.4) требуется переписывать софт(никто не хочет).
Предложенный подход потребует и новой архитектуры всей вычислительной системы, новой ОС, с другой идеологией (виртуальная память не очень хорошо ложится на этот подход, хотя и нельзя сказать, что это нерабочий подход).
Логично, что и программы будут работать несколько по другому (на низком уровне, тк не будет острой необходимости выполнять ввод-вывод с постоянной памяти, а можно работать, как с обычной, да и работа с регистрами и обычной памятью, может быть немного переделана ....) Очень интересно и ждём первых прототипов, хотя бы на уровне виртуальных машин.
Спасибо за статью, заставила задуматься :-)
Почитайте Солтиса про архитектуру AS/400, она как раз должна подойти, хотя сама система работает на обычном железе.
Сейчас если что-то есть в постоянной памяти, его не обязательно загружать в оперативную, можно просто отобразить, тогда получаем почти прямое чтение из постоянной памяти при обращении к оперативной, но немножко буферизированное, для снижения iops нагрузки. Так что тут какой-то проблемы давно нет, и все упирается только в скорость диска. С этой точки зрения быстрый классический ssd или быстрая постоянная память - практической разницы нет, чтение идет точно также только при доступе к конкретным страничкам данных.
А вот что касается регистров, уйти от них нельзя. Чтобы процессор был быстрым, все данные у него должны физически находится на расстоянии не больше нескольких миллиметров от ядра. Любые попытки увеличить расстояние закономерно увеличивают и длину линий, и задержки, что снижает частотный потенциал и производительность. А это значит что не смотря на постоянную память, софт продолжит иметь часть состояния за пределами этой постоянной память, и продолжит терять свою память при любых сбоях. Конечно частично это можно обойти костылями, например сбрасывать регистры на диск при сбое по питанию, пока емкости подсистемы питания еще держат заряд и есть несколько сотен миллисекунд все сохранить. Но ровно тоже самое можно делать и сейчас, только это никому не нужно, надежнее просто обеспечить постоянное питание.
А от программных и аппаратных ошибок не застрахован никто, так что даже при наличии постоянной памяти любую программу нужно будет время от времени перезапускать.
Вот и выходит что как бы постоянная память это шаг вперед, как минимум потому что ssd должны будут приблизиться к параметрам оперативной память, но в тоже время по факту она ничего не меняет, как это пытаются расписать в статьях: те же регистры, тот же образ программы в памяти (пусть физически теперь этот образ и не в оперативке а в каком-нибудь служебном файле на диске), и все те же проблемы со сбоями и ошибками, с перезапуском программ и ОС.
Этой "революции" лет двадцать уже. РазбудИте когда наконец состоится...
Я листал страницу, читая заголовки, и остановился на мейнфреймах, там прямо был порыв мысли. Прочитав пару абзацев, стал спотыкаться на опечатках и ошибках. Я выписал те фразы, что нашёл, на случай если вам не будет жаль времени на редактирование статьи. К запятым решил не докапываться, статья и без них вполне грамотная и научная :)
"обладая свойствами сверхпроводимости и сегнетоэлектричества" --> "и получает свойства сверхпроводимости и сегнетоэлектричества";
"Причём храниться можно будет не только «снимок» оперативной памяти" --> видна рука редактора, точнее, незаконченная правка: нужно убрать либо постфикс у глагола ("хранить можно будет"), либо слово "можно" ("храниться будет");
"перед выключением, которое уже и не станет «шатдауном»" --> или "которое уже не будет «шатдауном»", или "которое станет уже не «шатдауном»";
"носить в кармане, как сейчас карту SSD" --> тут у меня уже поползла улыбка: либо это опечатка смешала вместе планки SSD и карты памяти SD, либо это часть описываемой фантазии;
"необязательно должны будут всегда находиться во включённом состоянии" --> снова два варианта: либо убрать "обязательно" и оставить только частицу "не", либо убрать "всегда".
Спасибо за публикации!
Перестанет существовать одна из самых больших проблем - необходимость загрузки данных в память для работы с ними. Можно будет данные обрабатывать прямо там, где они хранятся.
Такие системы будут идеальны для баз данных
Звучит красиво, но по факту сказка, потому что память программы размазана по внутренним структурам ОС и железа. Наличие постоянной памяти никак не избавляет программу от зависимости от состояния ОС/железа. И нет даже теоретического способа надежно снять такую зависимость.
Может, это какой-то хабро-глюк? Все ссылки на статьи 2020 года.
Мы точно на пороге "революции"?
Обычные задачи эта технология не решает, т.к. всё реально важное и так на батарейках. В специальных задачах – возможно, но на то они и специальные, чтобы про них не знать...
Звучит как - давайте переобзовем все другими словами и файловая система с файлами будет не нужна, будут нужны объекты и индексы.
Зато революция.
По сути вся революция будет в переходе SSD на более долговечные компоненты и без dram кэша. А более быстрая ОЗУ так или иначе останется, плюс в процессорах пока не приходится говорить о резком скачке скорости вычислений.
Внедрение персистентной памяти: добро пожаловать в революцию?