4

Я знаю, что подобные вопросы задавались, но я думаю, что мой случай немного отличается.

Допустим, у меня есть компьютер с 8 ядрами и бесконечной памятью с ОС Linux.

У меня есть программное обеспечение для вычислений под названием Gaussian, которое может использовать преимущества многопоточности. Поэтому я установил счетчик потоков на 8 для одного расчета максимальной скорости. Однако я действительно не могу решить, что делать, когда мне нужно выполнить, например, 8 вычислений одновременно. В этом случае я должен установить количество потоков равным 1(всего 8 потоков, порожденных в 8 процессах) или оставить его равным 8(всего 64 потока, порожденных в 8 процессах) для каждого задания? Это действительно имеет большое значение? Смежный вопрос заключается в том, выполняет ли ОС автоматическую загрузку ядер для разных ядер для каждого потока?

РЕДАКТИРОВАТЬ: я знаю, что сравнительный анализ является лучшим способом узнать. Дело в том, что компьютеры принадлежат моему университету, поэтому они все время заняты. Другими словами, его рабочая нагрузка изменяется неконтролируемым образом для меня, потому что другие люди тоже используют эти компьютеры для своих расчетов, что делает невозможным эксперимент. Кроме того, программное обеспечение очень дорогое (1500 $ или около того) и лицензируется для каждого компьютера, поэтому я не могу просто запустить тест на моем персональном компьютере ...

4 ответа4

5

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

Многие процессоры Intel поставляются с гиперпоточностью, поэтому каждое ядро может поддерживать два потока. Например, 8-ядерная система, которая поддерживает гиперпоточность, должна иметь 16 потоков, чтобы полностью использовать систему.

3

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

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

Во время ожидания поток ничего не делает, поэтому ожидания будут отрицательно влиять на пропускную способность. В этом случае большее число процессов и меньшее количество потоков на процесс улучшат пропускную способность, поэтому производительность 8x8 будет выше, чем 1x64.

С другой стороны, если каждый поток полностью изолирован и нет общих общих ресурсов, тогда операционная система будет планировать потоки без какого-либо различия между двумя случаями 8x8 или 1x64. В этом случае только общее количество потоков важно для общей пропускной способности, поэтому оба случая имеют одинаковую производительность.

3

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

Книга "Параллелизм программирования на JVM" содержит несколько хороших сведений об этом:

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

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

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

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

Таким образом, мы можем вычислить общее количество потоков, которое нам понадобится, следующим образом:

Количество потоков = количество доступных ядер / (1 - коэффициент блокировки)

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

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

Лучшее решение - сравнить его экспериментально.

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

1

Вы сами должны ответить на вопрос. «Компьютеры принадлежат моему университету, поэтому они все время заняты»

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

Многопоточность всегда менее эффективна при расчете на основе "вычислительной мощности" из-за издержек переключения контекста. Это только ускоряет проблемы использования всех "свободных" незанятых ресурсов. Идея: использовать 8 компьютеров, чтобы запустить проблему, вероятно, в 7,9 раз быстрее, что никогда не может быть больше 8.

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

кстати, по-эгоистично, есть инструменты красной шапки, которые называют grid, которые могут разделить вашу работу на весь linux над кампусом. (> 200). Он будет бегать так быстро, просто не попадитесь, потому что он замедлит всех. или используйте старые инструменты, математическая параллель.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .