Почему в приложении могут быть миллионы актеров, а просто 10 000 потоков - это слишком много? - PullRequest
5 голосов
/ 30 июля 2010

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

Ответы [ 4 ]

4 голосов
/ 06 сентября 2010

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

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

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

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

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

4 голосов
/ 30 июля 2010

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

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

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

Таким образом, создание множества потоков израсходует вашу память.

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

3 голосов
/ 30 июля 2010

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

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

1 голос
/ 31 июля 2010

Модель актера не подразумевает масштабирование до миллионов актеров.Это деталь реализации.Например, из Scala Actors: краткое руководство :

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

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

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

Передача сообщений и актеры являются отличным способом управления параллелизмом, но не единственным.Прежде чем переключиться на «Только для актеров», прочитайте объяснение Рича Хики о том, почему он не включил Actors в Clojure.

Программная транзакционная память - еще одна альтернатива для управления изменяемымобщее состояние.

...