Многопоточность с очень большим количеством потоков

Во-первых, действительно ли вы используете обычные потоки Python по умолчанию, доступные в интерпретаторе Python 2.7 по умолчанию (CPython), и весь ваш код написан на Python? Если это так, вы, вероятно, на самом деле не используете несколько ядер ЦП из-за глобальной блокировки интерпретатора, которую имеет CPython (см. https://wiki.python.org/moin/GlobalInterpreterLock). Возможно, вы могли бы попробовать запустить свой код под Jython, просто чтобы проверить, будет ли производительность лучше.

Вероятно, вам следует переосмыслить архитектуру своего приложения и переключиться на ручное планирование событий вместо использования потоков или, возможно, попробовать использовать что-то вроде гринлетов (https://stackoverflow.com/a/15596277/1488821), но это, вероятно, будет означать менее точное время из-за отсутствия параллелизма.

Для меня 1600 потоков звучит много, но не чрезмерно, учитывая, что это симуляция. Если бы это было производственное приложение, оно, вероятно, не было бы пригодным для производства.

Стандартная машина не должна иметь проблем с обработкой 1600 потоков. Что касается ОС, эта статья может предоставить вам с некоторыми представлениями.

Когда дело доходит до вашего кода, скрипт Python — это не собственное приложение, а интерпретируемый скрипт, и поэтому для его выполнения потребуется больше ресурсов ЦП.

Я предлагаю вам вместо этого попробовать реализовать симуляцию на C или C++, что создаст собственное приложение, которое должно выполняться более эффективно.

Не используйте для этого потоки. Если вы придерживаетесь Python, позвольте узлам выполнять свои действия один за другим. Если производительность, которую вы получаете при этом, в порядке, вам не придется использовать C/C++. Если действия, которые выполняет каждый узел, просты, это может сработать. В любом случае, нет никакой причины использовать потоки в Python вообще. Потоки Python можно использовать в основном для блокировки ввода-вывода, чтобы не блокировать вашу программу, а не для использования нескольких ядер ЦП.

Если вы действительно хотите использовать параллельную обработку и писать свои узлы так, как будто они действительно разделены и обмениваются только сообщениями, вы можете использовать Erlang (http://www.erlang.org/). Это функциональный язык, очень хорошо подходящий для выполнения параллельных процессов и обмена сообщениями между ними. Процессы Erlang не сопоставляются с потоками ОС, и вы можете создать их тысячи. Однако Erlang — чисто функциональный язык и может показаться крайне странным, если вы никогда не использовали такие языки. И это также не очень быстро, поэтому, как и Python, он вряд ли будет обрабатывать 1600 действий каждые 5 мс, если только действия не будут довольно простыми.

Наконец, если вы не получаете желаемой производительности при использовании Python или Erlang, вы можете перейти на C или C++. Тем не менее, все еще не используйте 1600 потоков. На самом деле использование потоков для повышения производительности разумно только в том случае, если количество потоков не превышает значительно количество ядер ЦП. В этом случае вам может понадобиться шаблон реактора (с несколькими потоками реактора) (http://en.wikipedia.org/wiki/Reactor_pattern). В библиотеке boost.asio есть отличная реализация паттерна реактора. Это объясняется здесь: http://www.gamedev.net/blog/950/entry-2249317-a-guide-to-getting-started-with-boostasio/

Некоторые случайные мысли здесь:

Я неплохо справился с несколькими сотнями таких потоков в Java; это можно сделать с помощью правильного языка. (Но я не пробовал это в Python.)

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

Одна большая проблема, с которой я столкнулся, заключалась в том, что потоки блокировали друг друга. Разрешение 100 потокам вызывать один и тот же метод для одного и того же объекта в одно и то же время, не дожидаясь друг друга, требует некоторого размышления и даже исследования. Я обнаружил, что моя многопоточная программа поначалу часто использовала только 25% 4-ядерного процессора, даже при полной загрузке. Это может быть одной из причин, по которой вы бежите медленно.

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

Стоит иметь больше потоков, чем ядер. Когда у вас есть два потока, они могут блокировать друг друга (и будут, если они будут делиться какими-либо данными). Если у вас есть код для запуска, который не будет блокироваться, вы хотите запустить его в своем собственном потоке, чтобы он не ждал, пока код, который блокируется, разблокируется и завершится. Я обнаружил, что как только у меня появилось несколько потоков, они начали множиться как сумасшедшие — отсюда и моя программа с сотнями потоков. Даже когда 100 потоков блокируются в одном месте, несмотря на всю мою гениальность, есть множество других потоков, чтобы занять ядра!