Что означает время, затрачиваемое на параллелизм потока в выводе профилировщика? - PullRequest
8 голосов
/ 09 февраля 2011

Я был бы очень признателен, если бы кто-нибудь с хорошим опытом работы с Intel VTune Amplifier рассказал мне об этом.

Недавно я получил отчет об анализе производительности от других ребят, которые использовали Intel VTune Amplifierпротив моей программы.Это говорит о том, что в области параллелизма потока большое время служебной информации .

Что означает время служебной информации ?Они не знают (спросил меня), у меня нет доступа к Intel VTune Amplifier.

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

while (true)
{
   mutex.lock();
   if (event changed)
   {
      mutex.unlock();
      // do something
      break;
   }
   else
   {
      mutex.unlock();
      usleep(3 * 1000);
   }
}

Это может бытьпомечено как Служебное время ?

Любой совет?


Я нашел справочную документацию о Служебное время с сайта Intel.http://software.intel.com/sites/products/documentation/hpc/amplifierxe/en-us/win/ug_docs/olh/common/overhead_time.html#overhead_time

Выдержка:

Служебное время - это продолжительность, которая начинается с освобождения общего ресурса и заканчивается получением этого ресурса.В идеале продолжительность служебной нагрузки очень мала, поскольку она сокращает время, которое поток должен ждать для получения ресурса.Однако не все процессорное время в параллельном приложении может быть потрачено на выполнение реальной работы с полезной нагрузкой.В случаях, когда параллельное выполнение (Intel® Threading Building Blocks, OpenMP *) используется неэффективно, значительная часть времени может быть проведена внутри параллельной среды, тратя процессорное время на высоких уровнях параллелизма.Например, это может быть связано с низкой степенью детализации разделения работы в рекурсивных параллельных алгоритмах: когда размер рабочей нагрузки становится слишком низким, накладные расходы на разделение работы и выполнение служебной работы становятся значительными.

Все еще сбивает с толку .. Можетэто значит "вы сделали ненужную / слишком частую блокировку"?

Ответы [ 3 ]

2 голосов
/ 24 февраля 2011

Я тоже не очень разбираюсь в этом, хотя я сам немного пытался использовать pthread.

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

for(i=0;i<NUM;i++) {
    sum += array[i];
}

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

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

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

Конечно, он также учитывает время, необходимое для переключения семафоров и мьютексов. В вашем случае это, вероятно, означает, что значительное количество времени тратится на внутренние компоненты mutex.lock и mutex.unlock.

Некоторое время назад я распараллелил часть программного обеспечения (используя pthread_barrier), и у меня были проблемы, когда для запуска барьеров требовалось больше времени, чем для использования одного потока. Оказалось, что цикл, в котором должно быть 4 барьера, был выполнен достаточно быстро, чтобы лишние затраты не стоили.

0 голосов
/ 09 февраля 2011

Я не знаком с vTune, но в ОС происходит переключение между потоками. Каждый раз, когда поток останавливается и загружается на процессор, необходимо сохранить текущий контекст потока, чтобы его можно было восстановить при следующем запуске потока, а затем восстановить контекст нового потока, чтобы он мог продолжить обработку.

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

0 голосов
/ 09 февраля 2011

Извините, я не эксперт по pthread или Intel VTune Amplifier, но да, блокировка мьютекса и разблокировка его, вероятно, будут учитываться как накладные расходы.

Блокировка и разблокировка мьютексов может быть реализована каксистемные вызовы, которые профилировщик, скорее всего, просто собрал бы с потоками.

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