Конечно. Появление RRAM позволит снизить латентность снапшота (не уверен, что до нуля, но сильно). Но общая машинерия никуда не денется пока объём RAM меньше объёма диска. А вот потом… это совсем интересно. :)
Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.
Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.
Интересно, что несколько проблем, которые казались просто неприступными, вдруг неожиданно разрешились. У меня из чужого кода были TCP/IP и USB stack, и в обоих колом стояли затыки, которые даже погружением в дебаггер на пару дней не были решены. А тут вдруг я их оба закрыл каждый за вечер. Взгляд "размылился", что ли...
Задачей, очевидно, является не написание VM, а создание ОС с персистентной ортогональностью и виртуальной машиной в глобальной памяти. (Блекджеком и шахматами и поэтессами повеяло, да?)
С обычной явской VM я этот вес не подниму точно. С таким подходом — поднял до уровня proof of concept. То есть — пока оно себя оправдывает. Мне, кроме всего, важно понять ограничения и возможности подхода, а это хорошо делать с развязанными руками.
Собственно, почему я заинтересовался. ОС Фантом, над которой я работаю — ОС с персистентной памятью. И мотивация у меня ровно вот такая: стейт современного приложения = граф, и заперсистить его в ФС = всегда война, немцы, потеря времени и здравого смысла. Вместо этого ОС просто гарантирует приложению, что ничего в файл писать не надо, "просто оставь это здесь", оно никуда не денется. Ограничения в размере адресного пространства — это следующий вопрос. В 32 бит они есть, а в 64 уже, считай, не будет. Но — технически это всё реализовано как persistent paging, то есть в традиционных ФС аналог такой техники — memory mapped file. Отсюда мне было бы интересно знать, какая производительность получается, в сравнении с сериализациями графа/дерева в традиционную/оптимизированную ФС, если его положить в mem mapped file. Я полагаю, что характеристические оценки скорости для такого подхода будут оценкой сверху для производительности дисковой подсистемы ОС Фантом.
На уровне виртуальной машины это, вроде бы, большого смысла не имеет, там только проверка типов специфична. Вот раскрыть шаблон при генерации JIT — это интересно. Но нет, сейчас такого нет, потому что, для начала, пока нет JIT.
Но подход-то 100% Ваш? Положить явное дерево в бинарный код и скрыть за деревьями реализацию (степень параллелизма) реального хардвера. Ведь бинарник мультиклета, насколько я понимаю, делает именно это — там параметр инструкции — это чтение из регистра, памяти или прямо указание на выход другой инструкции. (За это, кстати, они заплатили полной невозможностью использовать хоть как-то инфраструктуру gcc, да и, думаю, llvm тоже в терминах деревьев исполняемый код генерировать не умеет.)
(Вообще признаю, что мне пришлось задуматься. Но:)
Кусок данных, который читает железка на другой стороне. С ней нельзя договориться о синхронизации. Нужно выставить данные в нужном порядке и гарантировать, что до того, как будет выставлен бит "данные готовы" они будут действительно готовы. То есть — явно запретить реордер записи в память.
(Там ещё и кеш надо явно сбрасывать, или через некешируемое окно работать.)
Но в изрядной степени я Ваше возражение приму. В целом lock — поработали — unlock при том, что lock-unlock являются fence-ами — вполне типичная картина.
Здравствуйте. С огромным интересом прочитал цикл про стековое представление. Задача обобщения представления параллелизма в коде программы, судя по комментариям, понятна очень не всем, :), но это, наверное, нормально. Скажите, а подход Мультиклета Вы анализировали? Фактически, насколько я понимаю, они сделали именно то, что Вы предлагаете — закодировали дерево операций в бинарном представлении, только, дополнительно, научились в определённой степени обходиться вообще без регистров (прямое соединение нескольких АЛУ в рантайме). Я, к сожалению, не нашёл времени разобраться в этой архитектуре совсем детально, но навскидку подход кажется очень правильным.
Про volatile — Вы предполагаете, что логика использования переменной обязательно пересекается с вызовами примитивов синхронизации, что необязательно. Правы Вы в том, что не всегда обязательно и помечать переменные как volatile, но статья-то вводная, лучше перебдеть.
Насчёт процессоров и памяти — да, я выдал Интелу избыточный кредит, Вы правы. Вероятно, меня сбил с толку тот факт, что типичная реализация спинлока для Интела является барьером, поэтому целостность появляется автоматически при использовании любого примитива синхронизации.
Это интересно. Разработчики архитектуры MIPS написали мне сегодня, что в современных MIPS-ах есть возможность при реализации спинлока использовать пару LL+PAUSE, чтобы заснуть до тех пор, пока объект, прочитанный через LL не изменится.
На минуточку, это позволяет реализовать spinless spinlock! :)
Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.
Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.
Блекджеком ишахматами и поэтессами повеяло, да?)С обычной явской VM я этот вес не подниму точно. С таким подходом — поднял до уровня proof of concept. То есть — пока оно себя оправдывает. Мне, кроме всего, важно понять ограничения и возможности подхода, а это хорошо делать с развязанными руками.
Кусок данных, который читает железка на другой стороне. С ней нельзя договориться о синхронизации. Нужно выставить данные в нужном порядке и гарантировать, что до того, как будет выставлен бит "данные готовы" они будут действительно готовы. То есть — явно запретить реордер записи в память.
(Там ещё и кеш надо явно сбрасывать, или через некешируемое окно работать.)
Но в изрядной степени я Ваше возражение приму. В целом lock — поработали — unlock при том, что lock-unlock являются fence-ами — вполне типичная картина.
Насчёт процессоров и памяти — да, я выдал Интелу избыточный кредит, Вы правы. Вероятно, меня сбил с толку тот факт, что типичная реализация спинлока для Интела является барьером, поэтому целостность появляется автоматически при использовании любого примитива синхронизации.
На минуточку, это позволяет реализовать spinless spinlock! :)