На Переднем Крае Разработки Виртуальных Машин

Пока готовится первая статья из образовательной серии о языке Эrlang, я решил перевести одну интересную запись в блоге.

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

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

Из-за этого многие языки программирования используют его в качестве своей исполняемой среды вместо написания собственной виртуальной машины (хотя кто-то до сих пор считает это интересным занятием).

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

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

Поэтому я не верю, что путь, выбранный JVM, является ссылкой для виртуальной машины.

Java не создана для такого будущего:



На переднем крае разработки виртуальных машин

Изображение взято из блога Тоби Арчиани, который украл его у Ульфа Вигера, который взял его у Джо Армстронга, который позаимствовал его у Рика Шагерстерна.

На графике показана часть процессора, до которой можно добраться за один такт.

На первый взгляд сложно оценить преимущества использования виртуальной машины Эrlang. Сборщик мусора работает в мягком режиме реального времени, а сборщик мусора JVM — в жестком реальном времени.

Компиляция «на лету» довольно медленная для методов вычислительной математики и не может «встроить» (назовите правильное слово?) между модулями, как это делает HotSpot. Для неопытных администраторов Эrlang вообще ужасен.

Ни с того ни с сего оно начинает съедать процессорное время и память, и единственный способ узнать, что происходит, — залезть в оболочку и набрать команды на каком-нибудь эзотерическом языке! Но все эти проблемы очень незначительны, если посмотреть на планы и цели виртуальной машиныЭrlang. В начале книги «Программирование на языке Lang» один из создателей языка Джо Армстронг рассказывает о мечте о конкурентной модели программирования: ваша программа работает в N раз быстрее на N процессорах.

Эrlang достиг этой цели в некоторой степени, используя модель распределенного программирования.

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

Хотя Erlang/OTP предоставляет мощную платформу для разработки распределенных сервисов, многие факторы распределения несущественны, когда речь идет об одном сервере с большим количеством процессорных ядер.

Виртуальная машина Rlang поддерживает планировщик SMP, работающий в обычном потоке для каждого ядра процессора.

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

Простое правило Эrlang: создайте столько процессов, сколько захотите — планировщик будет равномерно загружать ими процессор.

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

Та же ситуация и в JVM, но, учитывая, что такое поведение является результатом фундаментальных принципов и конструкции этой виртуальной машины, модель параллелизма rlang предоставляет создателям значительно больше возможностей оптимизации.

Недавняя презентация суперизвестного Erlanger Ульфа Вигера рассказывает нам о ближайшем будущем виртуальной машины Erlanger. В презентации освещаются несколько слабых мест масштабируемости и то, как авторы планируют от них избавиться.

Вы можете прочитать презентацию самостоятельно, или, если вам лень, читать дальше, я постараюсь все сделать за вас.

Итак, вот в чем дело: (извините, что вырезал картинки из презентации Ульфа! Они потрясающие!)



На переднем крае разработки виртуальных машин

На этой фотографии был большой логотип Rrickson. Если кто-то будет жаловаться, я сделаю свою версию.

Вот как выглядит планировщик виртуальных машин Эrlang. Существует множество планировщиков, каждый из которых работает в отдельном потоке и выполняет код из общего потока команд. Вы видите слабое место? Посмотрите на эту кучу стрелок, указывающих в одно место! Как решить такую проблему? Разделяй и властвуй:


На переднем крае разработки виртуальных машин

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

Это начинает выглядеть как ядро операционной системы, верно? Что ж, посмотрим, как это повлияет на масштабируемость системы:



На переднем крае разработки виртуальных машин

Красная линия — современный планировщик SMP с одной очередью выполнения.

Синяя линия — планировщик SMP следующего поколения, который уже будет в следующих версиях rlang. Как мы видим, разделение одной очереди действительно помогло, но после достижения определенного количества ядер производительность снова начинает падать.

В чем дело?



На переднем крае разработки виртуальных машин

Опять куча стрелок, указывающих в одно место! :( Распределение памяти в Эrlang — еще одно препятствие и, соответственно, слабое звено масштабируемости системы.

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

Судя по базовому дистрибутиву Эrlang, потенциал огромен.

А по мере увеличения количества ядер процессора (эти тесты проводились на 64-ядерном процессоре) все эти шаги по оптимизации будут все более востребованы для использования всей мощности вычислительной системы.

Такие системы, как JVM, определенно не исчезнут с приходом многоядерного будущего.

Такой подход, как программная транзакционная память, может успешно использоваться в JVM, особенно с таким языком, как Clojure, для достижения результатов при решении определенных задач распараллеливания, которые лучше, чем модель «ничего общего между процессами» в Эrlang. Но в целом я считаю, что подход rlang concurrency более понятен и облегчает жизнь программистам, скрывая всю распределенную сложность на самом низком уровне виртуальной машины.

Этот подход может быть более логичным, чем PTP, особенно если он приобретёт «человеческое лицо», чего я и пытаюсь добиться своим проектом языка программирования на основе виртуальной машины — Reia. Но главное — существует огромный потенциал для улучшения производительности виртуальных машин для многоядерных систем, и я надеюсь, что однажды мы увидим мечту Джо Армстронга в действии — выполнять программы в N раз быстрее на N процессорах.

P.S. Русский не является моим родным языком, поэтому любые исправления и предложения по улучшению читабельности приветствуются.

Спасибо, что дочитали до конца ;) Теги: #erlang #VM #Erlang/OTP

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.