SII писал(а):
dzavalishin писал(а):
Стоимость записи в обменный формат с сериализацией и работой файловой системы навскидку на 3-5 порядков выше, чем прямая запись страницы памяти на диск.
Бред. 3-5 порядков -- это 1000 - 100 000 раз. Учитывая, что скорость ввода-вывода для традиционных дисков в тысячи раз медленнее, чем скорость обработки данными процессором (а SSD чрезвычайно дороги и имеют малую ёмкость, поэтому подходят лишь для определённого круга задач), преобразование данных перед записью или после считывания скажется на времени от момента начала операции и до приведения данных в необходимый формат в очень малой степени. Ну а если использовать асинхронный ввод-вывод (не дожидаться, пока диск соизволит записать или прочитать очередную порцию данных, а, запустив ввод-вывод с одной порцией, продолжать работу над следующими), то время загрузки или сохранения документа вообще практически сведётся к времени ввода-вывода. Наконец, если "обменный формат" подразумевает упаковку данных, в то время как рабочий ("прекомпилированный") имеет распакованный вид, то время сохранения или загрузки такого рабочего представления может оказаться в разы больше, чем упакованного "обменного" формата.
Число раз оценено верно.
pageout требует исполнения нескольких сот строк кода, причём - линейного. пейджфолт, постановка страницы в очередь, запуск io в драйвере, прерывание, снятие семафора. всё. при этом сами ДАННЫЕ совершают ОДНО ПЕРЕМЕЩЕНИЕ. Прямо из памяти в диск - и процессор в этом участия не принимает. и записать можно только модификации.
запись doc-файла - это пятиэтажная война с сериализацией в xml, упаковкой (которая никому не нужна, вообще-то), кучей сисколлов к файловой системе, выделению дисковых страниц под требуху файловой системы - а ещё, глядишь, разбалансируется дерево где-нибудь в инодах-каталогах :)... при этом данные таскает с места на место процессор, причём несколько раз. и записать можно только всю пачку. даже если поменял один байт.
вот она и разница в 3-5 порядков. кстати, сделать это в фоне нельзя - сериализовать стейт приложения нужно обязательно синхронно, с остановом работы приложения. в фоне можно только записать сериализованные данные. запись же стейта приложения в фантоме происходит реально асинхронно.
снижение времени ввода-вывода ввиду упаковки - единственный аргумент, который я частично принимаю. частично - потому что - см выше - он убивается необходимостью писать на диск весь стейт, тогда как реально он весь никогда не меняется. для того же ворда норма - пара абзацев за редактирование. вот для фотошопа - да, модель ввода-вывода Фантома может оказаться неидеальна - да и то, посмотреть надо.
И вообще - смотреть надо, как оно будет - предположения достаточно эфемерны. Мне подсказали интересное исследование - реально собрана статистика по пейджингу юниксов и проведён анализ: что будет, если взять юникс и положить его в среду а-ля Фантом, то есть выделять всем приложениям уникальные адреса и никогда не использовать адреса повторно. При этом адреса сегментов кода используются повторно, а сегменты данных всегда уникальны. Оказывается, что годовая потребность адресного пространства имеет вполне вразумительный порядок - типа терабайта - БЕЗ сборки мусора.
Задача, которую пытался решить этот исследователь, и которую ставит перед собой Фантом - обеспечить прямую персистентную линейную адресацию всего, что есть в системе. Это - очень важное свойство. Оно обеспечивает interoperability более высокого, чем где либо, уровня. Остальное - вторично.