bamboon и and doron верны, что многие переменные находятся в игре, но если у вас есть настраиваемый размер ввода n
, вы можете определить сильное масштабирование и слабое масштабирование вашего кода.
Сильное масштабирование относится к исправлению размера проблемы (например, n = 1M
) и изменению количества потоков, доступных для вычисления. Слабое масштабирование означает исправление размера проблемы на поток (n = 10k/thread
) и изменение количества потоков, доступных для вычисления.
Это правда, что в любой программе работает много переменных - однако, если у вас есть какой-то базовый размер ввода n
, можно получить некоторое подобие масштабирования. На симуляторе n-body, который я разработал несколько лет назад, я варьировал потоки для фиксированного размера и входного размера для каждого потока и мог разумно рассчитать приблизительную меру того, насколько хорошо масштабируется многопоточный код.
Поскольку у вас есть только 4 ядра, вы можете рассчитать масштабирование только до 4 потоков. Это сильно ограничивает вашу способность видеть, насколько хорошо он масштабируется до многопоточных нагрузок. Но это может не быть проблемой, если ваше приложение используется только на компьютерах с небольшим количеством ядер.
Вам действительно нужно задать себе вопрос: будет ли это использоваться в 10, 20, 40+ потоках? Если это так, то единственный способ точно определить масштабирование до этих режимов - это фактически сравнить его с платформой, на которой у вас есть это оборудование.
Примечание: в зависимости от приложения может не иметь значения, что у вас есть только 4 ядра. Некоторые рабочие нагрузки масштабируются с увеличением потоков независимо от реального числа доступных ядер, если многие из этих потоков тратят время на «ожидание» чего-либо (например, веб-серверы). Если вы делаете чистые вычисления, это не будет иметь место