Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Posts Tagged ‘optane

Development 2.0

4 комментария

Ох вау, новый блогпост, а вы-то думали что Нестерук suka мертв. Ну, еще нет, хоть я на пенсии и пишу это на острове пенсионеров (Мадейра). Какой-то адский бабулькоград.

Так ну ладно, я тут пришел поговорить про Optane. Точнее это отмазка. Вся суть в том, что я снова хочу толкать все те же свои программитские идеи которые и раньше толкал, только Optane делает это чуть проще.

Итак, о чем мы? Да о том, что скорость SSD-образных технологий постепенно приближается к скорости RAM — настолько, что те модели Optane которые есть на рынке сейчас — это М.2 драйвы для кэшей для тех у кого еще нет SSD и те кто хочет малой кровью получить прирост к перформансу.

Конечно Intel — это, извините, лживая и не особо заботящаяся о своих клиентах компания. Это я как пользователь всего их стэка говорю, им глубоко пофиг что их компилятор накрывается на тривиальных примерах с “Ошибка 3”, а про то что прирост скорости процов в последнии несколько лет чуть ли не нулевой (ну, процентов 15) вообще говорить не стоит, как и о продолбанном Broadwell.

Так вот, Optane — это такой “звоночек” что идет, пусть и не очень быстро, самая настоящая конвергенция, когда нет разницы в скорости и персистентности между RAM и “долгосрочными” носителями информации. А это в свою очередь открывает интересные возможности, и не только для геймдева где “Loading screen” это нечто ругательное.

Что за идею я вам хочу толкнуть? Да все ту же идею что программы должны быть всегда запущенны, и что разделение программы на этап компиляции и этап запуска — это бред. Еще со времен Java 2, простихосподи, у нас была возможность скомпилировать программу прямо из программы и динамически ее подгрузить. Вот насчет отгрузки все сложнее (легко в C++, очень сложно в .NET) можно долго писать, но возможность такая существует. Итак, что бы хотелось иметь?

  • Программист запускает программу как “чистый лист”, то есть по сути запускает лишь работающий, пустой IoC контейнер без регистраций (и SMS).

  • Программист редактирует программу “по живому”, в процессе запуска. Контейнер дает ему возможность добавить новый класс/интерфейс или поменять существующий. Это кстати — не совсем тривиальные задачи, но в базовом сценарии, когда все зависимости заинжекшены — вполне реально.

  • Кусок кода, который кодер только что сваял компилируется и загружается в программу. Ну или сохраняется как либа и подгружается.

  • Если был изменен существующий тип, он заменяется, перерегистрируется в контейнере и потом каждый тип, который его использует, пересоздается снова. Это может стать очень большой, рекурсивной операцией т.к. нужен обход зависимостей всех зарегистрированных в контейнере типов.

  • Если был создан новый тип, он просто регистрируется в контейнере и в дальнейшем может быть использован как напрямую так и через контейнер.

Вот это, мои дорогие, то как я вижу Development 2.0 — новая парадигма, в которой ничего не нужно пересобирать и перезапускать. Нужен просто такой IoC контейнер, который настроен на вечную персистентность системы и умеет худо бедно отгружать типы (или делать грамотный перезапуск). Технология динамического прототипирования, про которую я неоднократно говорил — это proof of concept того, про что я тут пишу.

А что, собственно, происходит дальше? Неужто мы редактируем прямо продакшн? Ну это уже от вас зависит — если вы захотите запилить “параллельную реальность” для проверки идей и тестирования, то это реально! И будет работать намного быстрее т.к. все уже загружено в процесс и никакой рекомпиляции “всего и вся” делать не нужно! А уже наработанные технологии code coverage дадут возможность трекать изменения и ранить тесты только на то, что реально поменялось.

Чтобы не быть голословным, я пошалуй напишу proof of concept на это дело. Какие-то наработки у меня уже есть с давнего dotNext, сейчас самое время сделать апдейт…

Реклама

Written by Dmitri

5 июня 2018 at 19:42

Опубликовано в Programming

Tagged with