Какое программное обеспечение хорошо использовать для параллельной отладки?


24

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

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


Я не вижу, как ответы здесь будут существенно отличаться от stackoverflow.com/questions/329259/… . MPI - сложная часть, а не OpenMP. В любом случае, отладка состояния гонки в многопоточных программах прямо сейчас неразрешима.
Джефф

ThreadSanitizer - это хорошее решение для отладки условий гонки в многопоточных программах, хотя я не знаю никого, кто пытался добавить MPI в смесь!
Мабрахам

Ответы:


17

Есть два основных коммерческих варианта: ДДТ от Allinea (что мы используем в TACC ) и Totalview (как упоминалось в другом комментарии). Они обладают сопоставимыми характеристиками, активно развиваются и являются прямыми конкурентами.

Eclipse имеет свою Parallel Tools Platform , которая должна включать поддержку программирования MPI и OpenMP и параллельный отладчик.


Я никогда не слышал, чтобы кто-нибудь использовал параллельный отладчик PTP. Я не уверен, что это значит ...
Джефф

У меня есть несколько коллег, которые пытались, но я никогда не играл с этим сам.
Билл Барт,

16

Я должен дать ответ обманщику. Моя производительность никогда не была улучшена ни одним из предложений выше. Они медленные и дорогие по сравнению с моим предпочтительным вариантом параллельно: один сеанс GDB на процесс. Каждый GDB может подключаться к процессу MPI и находиться в xterm (это происходит автоматически при использовании PETSc -start_in_debugger). Я использовал это в течение 15 лет, к счастью. Возражения:

1) я не могу смотреть на глобальные данные

Поскольку MPI является моделью с общим доступом, глобальных данных нет, только локальные данные

2) Эта стратегия не масштабируется на множество процессов

Никто не делает ошибок. Ошибки возникают в отдельных процессах, возможно, при входе от 1 или 2 соседей. Вы можете легко создавать GDB только для участвующих процессов (например, в PETSc, который вы используете -debugger_nodes 0,5,17). Кроме того, вышеперечисленные системы сильно сдаются при запуске каждого процесса, что делает их медленными. Метод GDB, на самом деле, гораздо более масштабируем.

GDB также очень переносим. Он работает везде, понимает C ++ и Fortran, и позволяет выполнять произвольный код внутри прогона. Я написал специальные функции, чтобы легко отображать данные при работе в нем.


4
Эй, трус, если ты понизишь голос, оставь комментарий.
Мэтт Кнепли

5
Я не был против, но я в некоторой степени не согласен. Я столкнулся с несколькими ошибками в масштабе, которые не отображались при небольших размерах, и использование параллельного отладчика было эффективным способом их поиска. Я делаю большую часть отладки с помощью printf и присоединяюсь к отдельным процессам с помощью gdb, но я видел преимущество параллельного отладчика.
Билл Барт

3
Единственный раз, когда я сталкивался с ошибкой в ​​масштабе, была ошибка производительности из-за неправильного алгоритма коллективного общения. С другой стороны, мое мнение даже более экстремально, чем у Мэтта, поскольку наиболее близким к отладчику, который я когда-либо использую, является valgrind.
Джек Полсон

1
@BillBarth Я знаю, что вы правы, что в 1000 процессах есть ошибки, которые не обнаруживаются при небольших проблемах (у Динеша был известный PETSc, который длился месяцами, который обнаруживался только на 82 процессорах). Моя цель была больше противостоять господствующей мудрости. Я думаю, что параллельные отладчики являются хорошим последним средством, а не первым средством.
Мэтт Кнепли,

3
Я понизил тебя. Ваш ответ не то, что спросили.
aterrel

5

Я использую только два отладчика для последовательных и параллельных программ:

  1. Отладчик Kernighan, то есть продуманные печатные заявления и осторожное мышление.
  2. Несколько экземпляров GDB, как описано o http://www.open-mpi.org/faq/?category=debugging#serial-debuggers .

В случае, когда (2) недостаточно масштабируемо, я ссылаюсь на (1b).


1
Я никогда не слышал имя «отладчик Kernighan», но я одобряю, потому что так я всегда отлаживаю.
Джек Полсон,

4

Существует Intel Parallel Studio, которая включает в себя параллельный отладчик. Я никогда не работал с этим, но я видел его в нескольких демонстрациях. Вот видеоурок, который показывает некоторые функции.

Я также видел несколько оберток вокруг GDB, которые в некоторых случаях работали достаточно хорошо.


3

Totalview . Это коммерческий отладчик. Очень легко просматривать стек на каждом процессоре. Вы можете видеть значения переменных (и изменять их) между процессорами / потоками. Вы можете построить векторы или матриц для визуализации значений переменных. Очевидно, сценарии также возможны (Tk / Tcl) для более сложного анализа точек наблюдения, хотя я сам никогда не работал с этим.


С субъективной стороны, когда центр HPC моего университета установил это, я думал, что это было излишним. Затем я узнал, как легко было выполнить очень сложную отладку. Это действительно отличная программа.
Янн

Я второй тоталвью тоже. Я использовал его во многих случаях, и он очень мощный, хотя и очень дорогой ...
BlaB


1

Интересно, почему никто не упомянул Padb (Parallel Application Debugger), который с открытым исходным кодом и бесплатное программное обеспечение, как предпочитает OP, но не такой мощный, как коммерческие аналоги, например: TotalView for HPC


-1

Вот дайджест некоторых ответов, данных мне ранее:

OpenMP имеет функции синхронизации: omp_get_wtime()и omp_get_wtick()- онлайн-документы

У Google есть профилировщик процессора

Есть Scalasca, которая делает OpenMP и MPI профиль и анализ

Тогда есть Тау и vtune, которые я не использовал.

Удачи!


Я не думаю, что вопрос касается времени, но я могу ошибаться. Хорошие предложения, хотя ...
Янн

Этот ответ больше о профилировании, чем отладке ...
mbq

Я обнаружил, что инструменты профилирования являются хорошей заменой параллельным отладчикам. Я часто нахожу случай, когда параллельные ошибки связаны с проблемами производительности, такими как logjam в MPI. Инструменты производительности часто обнаруживают это. Профилировщик памяти TAU хорош для выяснения причин возникновения случайных ошибок.
Джефф
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.