Технически, почему процессы в Erlang более эффективны, чем потоки ОС?

Question

Характеристики Эрланга

С Программирование на Erlang (2009):

Эрлангский параллелизм быстрый и масштабируемый. Его процессы легки в том, что виртуальная машина Erlang не создает поток ОС для каждого созданного процесса. Они создаются, планируются и обрабатываются в виртуальной машине независимо от базовой операционной системы. В результате время создания процесса составляет порядка микросекунд и не зависит от числа одновременно существующих процессов. Сравните это с Java и C #, где для каждого процесса создается базовый поток ОС: вы получите несколько очень конкурентоспособных сравнений, причем Erlang значительно превосходит оба языка.

С Параллельное программирование на Erlang (pdf) (слайды) (2003):

Мы наблюдаем, что время, затрачиваемое на создание процесса Эрланга, постоянно от 1 мкс до 2500 процессов; после этого он увеличивается примерно до 3 мкс для 30 000 процессов. Производительность Java и C # показана в верхней части рисунка. Для небольшого числа процессов создание процесса занимает около 300 мкс. Создание более двух тысяч процессов невозможно.

Мы видим, что для 30 000 процессов время отправки сообщения между двумя процессами Эрланга составляет около 0,8 мкс. Для C # требуется около 50 мкс на сообщение, до максимального количества процессов (которое составляло около 1800 процессов). Java была еще хуже: до 100 процессов требовалось около 50 мкс на сообщение, после чего она быстро увеличивалась до 10 мс на сообщение, когда было около 1000 процессов Java.

Мои мысли

Я не до конца понимаю, почему процессы Эрланга намного эффективнее порождают новые процессы и имеют гораздо меньший объем памяти на процесс. И ОС, и Erlang VM должны выполнять планирование, переключение контекста и отслеживать значения в регистрах и т. Д. ...

Просто почему потоки ОС не реализованы так же, как процессы в Erlang? Должны ли они поддерживать что-то большее? И зачем им больше памяти? И почему у них медленнее нерест и общение?

Технически, почему процессы в Erlang более эффективны, чем потоки ОС, когда речь идет о порождении и коммуникации? И почему потоки в ОС не могут быть реализованы и управляться так же эффективно? И почему потоки ОС занимают больше памяти, а также медленнее порождают и общение?

Подробнее

• Внутри Erlang VM с акцентом на SMP (2008)
• Параллелизм в Java и в Erlang (pdf) (2004)
• Измерения производительности потоков в Java и процессов в Erlang (1998)

Answer 1

Существует несколько факторов:

1. Процессы Эрланга не являются процессами ОС.Они реализуются виртуальной машиной Erlang с использованием облегченной модели совместной потоковой обработки (преимущественной на уровне Erlang, но под управлением совместно запланированной среды выполнения).Это означает, что переключение контекста намного дешевле, поскольку они переключаются только в известных контролируемых точках и, следовательно, не должны сохранять все состояние ЦП (нормальное состояние, регистры SSE и FPU, отображение адресного пространства и т. Д.).
2. В процессах Erlang используются динамически распределенные стеки, которые начинаются очень маленькими и растут по мере необходимости.Это позволяет порождать многие тысячи - даже миллионы - процессов Erlang, не занимая при этом всю доступную оперативную память.
3. Раньше Erlang был однопоточным, что означало, что не требовалось обеспечивать безопасность потоков между процессами.Теперь он поддерживает SMP, но взаимодействие между процессами Erlang в одном и том же планировщике / ядре все еще очень легкое (есть отдельные очереди выполнения на ядро).

Answer 2

После еще одного исследования я нашел презентацию Джо Армстронга.

От Erlang - программное обеспечение для параллельного мира (презентация) (в 13 мин):

[Erlang] - это параллельный язык - я имею в виду, что потоки являются частью языка программирования, они не принадлежат операционной системе. Это действительно то, что не так с языками программирования, такими как Java и C ++. Его потоки не на языке программирования, потоки - это что-то в операционной системе - и они наследуют все проблемы, которые возникают в операционной системе. Одной из проблем является гранулярность системы управления памятью. Управление памятью в операционной системе защищает целые страницы памяти, поэтому наименьший размер потока может быть наименьшим размером страницы. Это на самом деле слишком велико.

Если вы добавите больше памяти на свой компьютер - у вас будет такое же количество битов, которое защищает память, так что степень детализации таблиц страниц возрастет - , в результате вы получите, скажем, 64 КБ для процесс, который вы знаете, выполняется в несколько сотен байтов.

Я думаю, что он отвечает, если не на все, хотя бы на несколько моих вопросов

Answer 3

Я реализовал сопрограммы в ассемблере и измерил производительность.

Переключение между сопрограммами, например, процессами Эрланга, занимает около 16 инструкций и 20 наносекунд на современном процессоре. Кроме того, вы часто знаете процесс, на который переключаетесь (пример: процесс, получающий сообщение в своей очереди, может быть реализован как прямая передача вызова от вызывающего процесса к процессу получения), поэтому планировщик не входит в игру, это операция O (1).

Для переключения потоков ОС требуется около 500-1000 наносекунд, потому что вы обращаетесь к ядру. Планировщик потоков ОС может выполняться за время O (log (n)) или O (log (log (n))), что станет заметным, если у вас десятки тысяч или даже миллионы потоков.

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

Answer 4

Эрланговские процессы соответствуют (приблизительно) зеленым нитям на других языках; Там нет принудительного разделения ОС между процессами. (Возможно, существует разделение по языку, но это меньшая защита, несмотря на то, что Эрланг выполняет лучшую работу, чем большинство.) Поскольку они намного легче, их можно использовать гораздо шире.

С другой стороны, потоки ОС могут быть просто запланированы на разные ядра ЦП и (в основном) способны поддерживать независимую обработку, связанную с ЦП. Процессы ОС похожи на потоки ОС, но с гораздо более сильным разделением на основе ОС. Цена этих возможностей заключается в том, что потоки ОС и (тем более) процессы стоят дороже.

---

Другой способ понять разницу заключается в следующем. Предположим, что вы собираетесь написать реализацию Erlang поверх JVM (не очень сумасшедшее предложение), тогда вы сделаете каждый процесс Erlang объектом с некоторым состоянием. После этого у вас будет пул экземпляров Thread (обычно измеряемый в соответствии с количеством ядер в вашей хост-системе; это настраиваемый параметр в реальных средах исполнения Erlang, кстати), которые запускают процессы Erlang. В свою очередь, это распределит работу, которая должна быть сделана, по реальным доступным системным ресурсам. Это довольно аккуратный способ ведения дел, но он опирается полностью на тот факт, что каждый отдельный процесс Эрланга не очень эффективен. Это нормально, конечно; Erlang структурирован так, чтобы не требовать, чтобы эти отдельные процессы были тяжеловесными, поскольку весь их ансамбль выполняет программу.

Во многих отношениях настоящая проблема связана с терминологией. То, что Эрланг называет процессами (и которые строго соответствуют одному и тому же понятию в CSP, CCS и особенно π-исчислении), просто не совпадает с тем, что языки с наследием C (включая C ++, Java, C # и многие другие) называют процесс или поток. Есть некоторые сходства (все включают некоторое понятие параллельного выполнения), но определенно нет эквивалентности. Так что будьте осторожны, когда кто-то говорит вам «процесс»; они могут понять, что это означает нечто совершенно иное ...

Answer 5

Я думаю, что Джонасу нужны были цифры для сравнения потоков ОС с процессами Эрланга. Джо Армстронг, автор Programming Erlang, некоторое время назад проверил масштабируемость процессов Erlang в потоках ОС. Он написал простой веб-сервер на Erlang и протестировал его на многопоточном Apache (поскольку Apache использует потоки ОС). Есть старый сайт с данными за 1998 год. Мне удалось найти его только один раз. Поэтому я не могу предоставить ссылку. Но информация там. Суть исследования показала, что Apache максимально справился с процессами под 8K, тогда как его рукописный сервер Erlang обрабатывал процессы с 10K +.

Answer 6

Поскольку интерпретатору Erlang приходится беспокоиться только о себе, в ОС есть много других проблем.

Answer 7

одна из причин заключается в том, что процесс erlang создается не в ОС, а в evm (виртуальная машина erlang), поэтому стоимость меньше.