Почему у вас есть миллионы актеров в приложении, но всего 10 000 потоков слишком много?

Question

Почему у вас есть миллионы актеров в приложении, но всего 10 000 потоков слишком много? Как получается, что создание миллионов актеров практично, но больше, чем пару нитей нет? Что могут сделать те ники, которые не могут сделать эти актеры (иначе мы будем использовать актеров все время!)?

Answer 1

Предполагая, что Scala и JVM:

Каждая нить оставляет за собой некоторое количество памяти для своего стека:

java -v 
-Xss<size>  set java thread stack size 

Так создают много потоков съест вашу память.

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

Answer 2

У вас обычно может имеет 10 000 потоков в приложении. Я не знаю никаких ограничений, которые могут остановить вас.

С другой стороны, поскольку у немногих современных настольных компьютеров есть 10 000 процессоров, вряд ли это будет хорошей идеей.

Когда вы говорите «актеры», вы говорите о the actor model? Если это так, это сравнение яблок с апельсинами; поток - фактически запущенный путь исполнения, и актер ближе к закрытию. В потоке выделены связанные с ним ресурсы (по крайней мере, для зеленых потоков, расположение указателя инструкций и многое другое для потоков ядра). Актер может быть очень минимальным.

Answer 3

Модель актера не подразумевает масштабность для миллионов действующих лиц. Это деталь реализации. Например, из Scala Actors : A Short Tutorial:

«Когда актеры называют поточно-блокировками таких операций, как получение (или даже ожидания), рабочий поток, который выполнение текущего актера (Self) является заблокировано Это. означает, в основном, что актера представлен в виде заблокированного нити. в зависимости от количества актеров вы хотите использовать, вы можете , чтобы избежать этого, так как большинство JVMs не может обрабатывать более чем несколько тысяч нитей на стандартных аппаратных средств «.

Таким образом, можно реализовать Актеры с теми же ограничениями, что и Threads (или даже худшие ограничения в патологической реализации).

Аналогичным образом, нитки представляют собой абстрактную концепцию без конкретных требований к ресурсам. Ограничение на 10000 лимитов предназначено для конкретной реализации (вероятно, потоки Windows на уровне ядра или pthreads) по сравнению с Threads в целом. Фактически, проводятся исследования для создания потоков пользовательского уровня, которые масштабируются для миллионов потоков. См:

• The Qthread library
• Qthreads: An API for Programming with Millions of Lightweight Threads

Message Passing и Актеры являются отличным способом для управления параллелизмом, но они не единственным способом. Прежде чем переключиться на Actors-only, прочитайте Rich Hickey's explanation о том, почему он не включил Актеров в Clojure.

Software transactional memory - еще одна альтернатива управлению изменчивым общим состоянием.

Answer 4

Актеры и нитки не являются объектом одного и того же типа.
* Нить - это фактический объект на вашей машине - он питается предсказуемым количеством ресурсов и имеет точные служебные данные, связанные с ним. Следовательно, если вы опишете 1 000 000 заданий, предоставив каждому из них поток, вы явно просите свой компьютер на 1000 000 раз больше ресурсов одного потока.
* Актер - это скорее способ объяснить вашему языку блок задач, поэтому он не имеет точного изображения во время выполнения. У вашего компилятора гораздо больше свободы в использовании ресурсов по своему усмотрению для выполнения задачи, которую вы описываете.

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

Но актеры позволяют вам объяснить, что вы хотите сделать, чтобы это было легче понять на вашем языке программирования. Таким образом, он может управлять ressources гораздо более эффективным способом, так что, если вы опишете 1 000 000 задач с актерами, у среды гораздо больше шансов найти способ скомпилировать и запустить ее, чтобы она по-прежнему управляема. Что касается потоков, большая часть различий связана с тем фактом, что, когда субъекты описывают очень четкую обработку, они могут быть запущены на потоке, что позволяет использовать схемы с использованием пула потоков произвольного размера для обработки запросов по мере их поступления. Вы не блокируете компилятор в схеме, которая убьет его производительность: он знает, что он не может порождать 1000 000 потоков, поэтому он попытается выполнить это по-другому и часто будет успешным. Свобода в определении количества потоков обеспечивает большую оптимизацию, первая из которых использует столько потоков, что на машине есть ядра/процессоры, что дает оптимальную вычислительную скорость. Такой дизайн также намного более устойчив к проблемам взаимоблокировки, поскольку вы не имеете прямого отношения к синхронизации и блокировке.

Что касается того, что может делать нить, а не актеров, то не так уж много, но потоки, являющиеся более близким представлением о том, что происходит в вашей машине, вы более точно контролируете то, что на самом деле происходит. Таким образом, с потоками, теоретически можно добиться большей производительности, хотя на самом деле с использованием потоков, чтобы победить хороший компилятор, вооруженный границами Актеров на невозможном, потому что модель настолько сложна в использовании, и потому, что компилятор знает так много вещи, которые вам невозможно знать.
Другое дело, хотя и не теоретическое ограничение, что Threads делают возможным, и что актеры не очень хорошо разбираются в библиотеках, которые используют Threads. Действительно, потоки являются базовой моделью многих сред, и у вас много библиотек, требующих от вас использовать их определенным образом. Актеры, возможно, не очень в этом способны.
Я все еще могу думать о другом, что могут сделать нитки, а не актеры: в реальном времени (я имею в виду жесткое реальное время, как в крайнем сроке окончания микросекунды, джиттер и код доказательств на nano-second-order и твердые гарантии). Я думаю, что в реальном времени можно использовать актерскую модель, но, насколько мне известно, такой реализации нет, поэтому до этого вам строго нужно делать жесткие в реальном времени потоки.

Так почему же мы не использовали актеров с самого начала? Это как много хороших вещей в программировании: потребовалось время и опыт, чтобы понять лучшие модели и реализовать их. У нас есть намного лучшие инструменты и языки в среднем, чем мы использовали 30 лет назад, и это то же самое с Актерами. Он появился совсем недавно как лучший способ сделать параллелизм.