Влияние гиперпоточности на gettimeofday и другие измерения времени

когда я сравнивал ЦП с гиперпоточностью с матричными операциями BLAS в C, я наблюдал почти точное удвоение времени выполнения функций при использовании гиперпоточности. Я ожидал некоторого улучшения скорости из-за выполнения не по порядку или других оптимизаций.

Я использую gettimeofday для оценки времени выполнения. Чтобы оценить наблюдение, я хочу знать, что вы думаете о стабильности gettimeofday в среде гиперпоточности (Debian Linux 32 Bit) или, может быть, о моих ожиданиях (они могут быть неверными)?

Обновление: я забыл упомянуть, что запускаю тестовое приложение дважды, устанавливая привязку к одному ядру гиперпоточности для каждого. Например, gemm запускается дважды параллельно.


c hyperthreading gettimeofday
person bknux    schedule 12.12.2014    source источник
comment
Если ваш код и данные в значительной степени помещаются в кеш (особенно L1, но, возможно, также и в L2), для чего такие вещи, как BLAS, разработаны/оптимизированы, то при выполнении этого кода не будет большинства остановок конвейера и пузырей, в которых гиперпоточность планирует инструкции из другого потока, что в значительной степени побеждает гиперпоточность.   -  person twalberg    schedule 12.12.2014

Ответы (1)


arrow_upward
2
arrow_downward

Я сомневаюсь, что использование вами gettimeofday() объясняет несоответствие, если, возможно, вы не измеряете очень маленькие интервалы времени.

Более того, я не ожидал, что включение гиперпоточности улучшит производительность однопоточных вычислений BLAS. Один поток использует только один процессор (одновременно), поэтому дополнительные логические процессоры, предоставляемые гиперпоточностью, не помогают.

Хорошо настроенный BLAS эффективно использует кэш данных ЦП, чтобы сократить время доступа к памяти. Однако это не очень помогает, если необходимые данные удаляются из кэша, что может произойти, когда другой процесс выполняется другим логическим процессором того же физического ЦП. Даже в малонагруженной системе, вероятно, достаточно работы, чтобы ОС всегда планировала процесс на каждом доступном (логическом) процессоре.

person John Bollinger    schedule 12.12.2014
comment
Извините, я забыл упомянуть, что я запускаю функции blas параллельно. - person bknux; 13.12.2014
comment
Вы упускаете суть. Сам BLAS является однопоточным, поэтому отдельные вычисления не выигрывают от наличия дополнительных ядер (будь то физических или логических). С другой стороны, на использование кеша каждого из них так же отрицательно влияет другое вычисление BLAS, выполняемое на том же физическом ЦП, как и случайное, не связанное с ним вычисление, выполняемое там. - person John Bollinger; 13.12.2014