Когда вам понадобятся «сотни тысяч» потоков?

Erlang, Go и Rust все заявляют так или иначе, что поддерживают параллельное программирование с дешевыми «нитями» /сопрограммами. В Перейти в FAQ говорится:

  

Практически создается сотни тысяч горутов в одном и том же адресном пространстве.

Rust Tutorial говорит:

  

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

Документация Erlang говорит:

  

Первоначальный размер кучи по умолчанию из 233 слов довольно консервативен, чтобы поддерживать системы Erlang сотнями тысяч или даже миллионов процессов.

Мой вопрос: какое приложение требует столько одновременных потоков выполнения? Только самые загружаемые веб-серверы получают даже тысячи одновременных посетителей. Приложения типа Boss-worker /job-dispatching, которые я написал, уменьшают количество возвратов, когда количество потоков /процессов намного больше числа физических ядер. Я полагаю, что это может иметь смысл для числовых приложений, но на самом деле большинство людей делегирует параллелизм сторонним библиотекам, написанным на языке Fortran /C /C ++, а не на этих языках нового поколения.

31 голос | спросил user39019 10 FebruaryEurope/MoscowbSun, 10 Feb 2013 07:33:45 +0400000000amSun, 10 Feb 2013 07:33:45 +040013 2013, 07:33:45

8 ответов


19

один вариант использования - websockets:
поскольку websockets долговечны по сравнению с простыми запросами, на занятом сервере много веб-сокетов будет накапливаться с течением времени. microthreads дают вам хорошее концептуальное моделирование, а также относительно легкую реализацию.

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

ответил kr1 10 FebruaryEurope/MoscowbSun, 10 Feb 2013 09:53:29 +0400000000amSun, 10 Feb 2013 09:53:29 +040013 2013, 09:53:29
15

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

Привлекая это в веб-мир - рассмотрите систему типа Twitter . Система, вероятно, не будет использовать микропотоки при создании веб-страниц, но может использовать их в своей коллекции /кэшировании /распространении твитов.

Эта статья может быть полезной.

ответил Dave Clausen 10 FebruaryEurope/MoscowbSun, 10 Feb 2013 08:35:45 +0400000000amSun, 10 Feb 2013 08:35:45 +040013 2013, 08:35:45
11

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

Рассмотрим эту функцию Erlang, которая поддерживает счетчик:

counter(Value) ->
    receive                               % Sit idle until a message is received
        increment -> counter(Value + 1);  % Restart with incremented value
        decrement -> counter(Value - 1);  % Restart with decremented value
        speak     ->
            io:fwrite("~B~n", [Value]),
            counter(Value);               % Restart with unaltered value
        _         -> counter(Value)       % Anything else?  Do nothing.
    end.

На обычном языке OO, таком как C ++ или Java, вы должны сделать это, имея класс с частным членом класса, общедоступные методы для получения или изменения его состояния и объекта-экземпляра для каждого счетчика. Эрланг заменяет понятие экземпляра объекта процессом, понятием методов с сообщениями и поддержанием состояния с помощью хвостовых вызовов , которые перезапускают функцию с любыми значениями, составляющими новое состояние. Скрытая выгода в этой модели - и большая часть Erlang's raison d'être - заключается в том, что язык автоматически сериализует доступ к значению счетчика посредством использования очереди сообщений, что делает параллельный код очень простым с высокой степенью безопасности.

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

ответил Blrfl 25 FebruaryEurope/MoscowbMon, 25 Feb 2013 18:22:54 +0400000000pmMon, 25 Feb 2013 18:22:54 +040013 2013, 18:22:54
4
  

Мой вопрос: какое приложение требует столько одновременных потоков выполнения?

1) Тот факт, что язык «масштабируется» означает, что у вас меньше шансов, что вам придется вырывать этот язык, когда все становится более сложным в будущем. (Это называется концепцией «Whole Product».) Многие люди пишут Apache для Nginx именно по этой причине. Если вы находитесь где-то рядом с «жестким пределом», наложенным потоком накладных расходов, вы будете бояться и начать думать о том, как пройти мимо него. Веб-сайты никогда не могут предсказать, сколько трафика они получат, поэтому потратить немного времени на то, чтобы сделать вещи масштабируемыми, разумно.

2) Один горутин на запрос только для начала. Есть много причин, чтобы использовать goroutines внутри.

  • Рассмотрим веб-приложение с одновременными запросами на 100 одновременных запросов, но каждый запрос генерирует 100-ти внутренних запросов. Очевидным примером является агрегатор поисковой системы. Но практически любое приложение может создавать goroutines для каждой «области» на экране, а затем генерировать их независимо, а не последовательно. Например, каждая страница на Amazon.com составлена ​​из 150 + back-end запросов, собранных только для вас. Вы не замечаете, потому что они параллельны, а не последовательно, и каждая «область» - это собственный веб-сервис.
  • Рассмотрите любое приложение, в котором надежность и латентность имеют первостепенное значение. Вероятно, вы хотите, чтобы каждый входящий запрос сбрасывал несколько обратных запросов, а возвращался в зависимости от того, какие данные поступают назад .
  • Рассмотрите любое «соединение с клиентом», выполненное в вашем приложении. Вместо того, чтобы говорить «для каждого элемента, получить данные», вы можете открутить кучу goroutines. Если у вас есть куча подчиненных БД для запроса, вы будете волшебным шагом N быстрее. Если вы этого не сделаете, это не будет медленнее.
  

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

Производительность - не единственная причина для разрыва программы на CSP . Это может сделать программу более понятной, и некоторые проблемы могут быть решены с гораздо меньшим количеством кода.

Как и в слайдах, связанных выше, параллелизм в вашем коде является способом организации проблемы. Не имея goroutines, как будто у вас нет структуры данных Map /Dictonary /Hash на вашем языке. Вы можете обойтись без него. Но как только вы его получите, вы начнете использовать его повсюду, и это действительно упростит вашу программу.

В прошлом это означало «сворачивать свое» многопоточное программирование. Но это было сложно и опасно - все еще не так много инструментов, чтобы убедиться, что вы не создаете расы. И как вы мешаете будущему сопровождающему совершить ошибку? Если вы посмотрите на большие /сложные программы, вы увидите, что они тратят LOT ресурсов в этом направлении .

Так как параллелизм не является первоклассной частью большинства языков, у сегодняшних программистов есть слепое место, почему они были бы полезны для них. Это станет более очевидным, поскольку каждый телефон и наручные часы будут направлены в сторону 1000 ядер. Идите на корабли со встроенным детектором гонок.

ответил Blrfl 25 FebruaryEurope/MoscowbMon, 25 Feb 2013 18:22:54 +0400000000pmMon, 25 Feb 2013 18:22:54 +040013 2013, 18:22:54
2

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

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

ответил Zachary K 10 FebruaryEurope/MoscowbSun, 10 Feb 2013 11:53:00 +0400000000amSun, 10 Feb 2013 11:53:00 +040013 2013, 11:53:00
1

Удобство. Назад, когда я начал делать многопоточное программирование, я делал много моделирования и разработки игр на стороне для удовольствия. Мне показалось, что было бы очень удобно просто открутить поток для каждого отдельного объекта и позволить ему делать это самостоятельно, а не обрабатывать каждый из них через цикл. Если ваш код не нарушен недетерминированным поведением, и у вас нет коллизий, он может упростить кодирование. Благодаря возможности, доступной нам сейчас, если я вернусь к этому, я с легкостью представляю, что выкрутите пару тысяч потоков из-за наличия достаточной вычислительной мощности и памяти для обработки множества дискретных объектов!

ответил Brian Knoblauch 25 FebruaryEurope/MoscowbMon, 25 Feb 2013 19:37:09 +0400000000pmMon, 25 Feb 2013 19:37:09 +040013 2013, 19:37:09
1

Простой пример для Erlang, который был разработан для связи: передача сетевых пакетов. Когда вы выполняете один HTTP-запрос, у вас могут быть тысячи TCP /IP-пакетов. Добавьте к этому, что каждый подключается одновременно, и у вас есть ваш прецедент.

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

ответил Florian Margaine 28 SatEurope/Moscow2013-12-28T00:07:41+04:00Europe/Moscow12bEurope/MoscowSat, 28 Dec 2013 00:07:41 +0400 2013, 00:07:41
-2

Здесь возникают некоторые задачи рендеринга. Если вы выполняете длинную цепочку ops на каждом пикселе изображения, и если эти ops параллельны, то даже относительно небольшое изображение 1024x768 находится прямо в скобке «сотни тысяч».

ответил Maximus Minimus 10 FebruaryEurope/MoscowbSun, 10 Feb 2013 18:26:06 +0400000000pmSun, 10 Feb 2013 18:26:06 +040013 2013, 18:26:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132