Стоимость / выгода распараллеливания на основе размера кода?

Question

Как вы выясните, стоит ли распараллеливать конкретный блок кода на основе его размера? Правильно ли выполнен следующий расчет?

Предположим:

• Пул потоков, состоящий из одного потока на процессор.
• Блок кода, связанный с процессором, со временем выполнения X миллисекунд.
• Y = min(number of CPUs, number of concurrent requests)

Таким образом:

• Стоимость: сложность кода, потенциальные ошибки
• Преимущество: (X * Y) миллисекунды

Мой вывод заключается в том, что не стоит распараллеливать для небольших значений X или Y , где "small" зависит от того, насколько ответными должны быть ваши запросы.

Answer 1

Одна вещь, которая поможет вам понять это: Закон Амдала

Ускорение программы, использующей несколько процессоров в параллельных вычислениях, ограничено временем, необходимым для последовательной части программы. Например, если программе требуется 20 часов с использованием одного ядра процессора, а конкретную часть в 1 час нельзя распараллелить, а оставшуюся многообещающую часть в 19 часов (95%) можно распараллелить, то независимо от того, сколько процессоров мы выделяем для параллельного выполнения этой программы минимальное время выполнения не может быть меньше критического 1 часа. Следовательно, ускорение ограничено до 20х.

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

Answer 2

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

Answer 3

Ну, выгода действительно больше:

(X * (Y-1)) * Tc * Pf

Где Tc - стоимость используемой вами структуры потоков. Никакая многопоточная структура не масштабируется идеально, поэтому использование 2x потоков, скорее всего, будет в 1,9 раза быстрее.

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

Кроме того, это Y-1, так как однопоточный в основном предполагает Y == 1.

Что касается принятия решения, то это также вопрос разочарования / ожидания пользователя (если пользователь раздражен ожиданием чего-либо, это принесет большую пользу, чем задача, которую пользователь на самом деле не возражает - что не всегда только из-за времени ожидания и т. д. - это отчасти ожидания).