Анализ потоков в Vtune зависает на __kmp_acquire_ticket_lock

В настоящее время я тестирую проект, написанный на C++, чтобы определить горячие точки и эффективность многопоточности, используя Intel VTune. При обычном запуске программа работает около 15 минут. Используя анализ горячих точек в VTune, я вижу, что функция __kmp_fork_barrier занимает примерно 40% всего процессорного времени.
Поэтому я также хотел увидеть эффективность многопоточности, но при запуске threading-модуля в VTune, он вообще не запускает проект, а вместо этого зависает на __kmp_acquire_ticket_lock при работе в Hardware event-based sampling-режиме. Вместо этого при запуске в user-mode sampling-режиме проект немедленно завершается с ошибкой сегментации (чего не происходит при запуске без VTune и проверке с помощью valgrind). При использовании вместо этого HPC performance characterization происходит сбой VTune.
Это проблемы с VTune или с моей программой? И как я могу найти проблемы с последним?


c++ multithreading openmp profiling intel-vtune
person arc_lupus    schedule 21.04.2021    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вызовы __kmp_xxx являются функциями среды выполнения Intel/Clang OpenMP. __kmp_fork_barrier вызывается при достижении барьера OpenMP. Если вы тратите 40% своего времени на эту функцию, это означает, что у вас есть проблема балансировки нагрузки с потоками OpenMP в вашей программе. Вам нужно исправить этот рабочий дисбаланс, чтобы повысить производительность. Вы можете использовать (экспериментальную) поддержку среды выполнения OMPT для отслеживания того, что делают потоки и когда они это делают. VTune должен иметь минимальную поддержку профилирования программ OpenMP. Сбой VTune, скорее всего, является ошибкой, и о ней следует сообщить на Intel. форум, чтобы разработчики VTune могли это исправить. Со своей стороны вы можете убедиться, что ваша программа всегда проходит все барьеры OpenMP детерминированным способом. Для получения дополнительной информации см. Учебное пособие по Intel VTune OpenMP.

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

person Jérôme Richard    schedule 21.04.2021
comment
Это хорошо знать. И все же, почему Vtune зависает на __kmp_acquire_ticket_lock, и не продолжает выполнение программы? Без этой проблемы я бы уже провел проверку балансировки нагрузки. - person arc_lupus; 21.04.2021
comment
Блокировки билетов являются реализацией спин-блокировки. Это сильно зависит от реализации среды выполнения Intel, но я думаю, что __kmp_acquire_ticket_lock пытается получить спин-блокировку, но безуспешно, потому что другая блокировка не освобождается другим потоком (я точно не знаю, почему, это может зависеть от кода приложения). ). Тот факт, что отчет VTune кажется мне нормальным, если на самом деле есть проблема с блокировкой. Это может означать, что в вашем коде или в среде выполнения OpenMP существует недетерминированная взаимоблокировка, если вы не сталкиваетесь с этой проблемой без VTune. - person Jérôme Richard; 21.04.2021
comment
Есть ли способ найти этот тупик в моем коде, особенно если я явно не использовал OpenMP в своем коде? - person arc_lupus; 21.04.2021
comment
Если вы используете библиотеку, использующую OpenMP, вы можете попытаться проанализировать стек вызовов, когда __kmp_acquire_ticket_lock вызывает проблему. Вы сможете узнать причину проблемы в библиотеке и сообщить им о проблеме. Обратите внимание, что вам, вероятно, потребуется (частично) отключить оптимизацию, чтобы кадр стека оставался действительным. В этом случае это может изменить поведение вашей программы. В качестве альтернативы вы можете попробовать инструмент Intel Inspector, который должен находить такие проблемы (я никогда им не пользовался). - person Jérôme Richard; 21.04.2021