Как определить оптимальное количество рабочих потоков - PullRequest
1 голос
/ 18 сентября 2009

Я написал программу на C, которая читает набор данных из файла, а затем применяет алгоритм интеллектуального анализа данных, чтобы найти кластеры и классы в данных. В данный момент я пытаюсь переписать эту последовательную многопоточную программу с PThreads, и я новичок в параллельном программировании, и у меня возник вопрос о количестве рабочих потоков, которые мешали мне:

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

Ответы [ 2 ]

2 голосов
/ 18 сентября 2009

Здесь есть несколько проблем.

  1. Как говорит Алекс, количество потоков, которые вы можете использовать, зависит от приложения. Но есть и ограничения, связанные с проблемой типа , которую вы пытаетесь решить. Должны ли ваши потоки общаться друг с другом или все они могут работать изолированно в отдельных частях проблемы? Если им необходимо обмениваться данными, тогда будет максимальное количество потоков, за пределами которых будет доминировать межпотоковое взаимодействие, и вы не увидите дальнейшего ускорения (на самом деле код будет работать медленнее!). Если им не нужно обмениваться данными, то потоки, равные количеству процессоров, вероятно, будут близки к оптимальным.

  2. Динамическая настройка пула потоков в соответствии с базовой архитектурой для обеспечения скорости во время выполнения - непростая задача! Вам понадобится много дополнительного кода для профилирования ваших функций во время выполнения. Посмотрите, например, как FFTW работает параллельно. Это, конечно, возможно, но довольно продвинуто и будет сложно, если вы новичок в параллельном программировании. Если вместо этого достаточно оценки количества ядер, то попытка определить это число из ОС во время выполнения и соответственно порождать ваши потоки будет намного проще.

Чтобы ответить на ваш вопрос о технике: большинство больших параллельных кодов работают на суперкомпьютерах с известной архитектурой и требуют много времени для запуска. Лучшее количество процессоров - это не только функция числа, но и топология связи (как связаны процессоры). Поэтому они получают выгоду от этапа тестирования, на котором наилучшее количество процессоров определяется путем измерения времени, затрачиваемого на небольшие проблемы. Обычно это делается вручную. Если это возможно, профилирование всегда следует отдавать предпочтению угадыванию на основе теоретических соображений.

2 голосов
/ 18 сентября 2009

В основном вы хотите иметь столько готовых к запуску потоков, сколько у вас доступно ядер, или не более 1 или 2, чтобы гарантировать, что ни одно из доступных вам ядер никогда не останется без работы. Хитрость заключается в оценке количества потоков, которые обычно блокируются в ожидании чего-то другого (в основном ввода / вывода), поскольку это полностью зависит от вашего приложения и даже от внешних объектов, находящихся вне вашего контроля (базы данных, другие распределенные службы и т. Д. И т. Д.) .

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...