OpenMP отладка вопросов новичка - PullRequest
7 голосов
/ 15 декабря 2010

Я начинаю изучать OpenMP, запускаю примеры (с gcc 4.3) из https://computing.llnl.gov/tutorials/openMP/exercise.html в кластере. Все примеры работают нормально, но у меня есть несколько вопросов:

  1. Как узнать, в каких узлах (или ядрах каждого узла) были запущены разные потоки?
  2. Случай узлов, каково среднее время передачи в микросекундах или наносекундах для отправки и получения информации?
  3. Каковы лучшие инструменты для отладки программ OpenMP?
  4. Лучшие советы по ускорению реальных программ?

Ответы [ 2 ]

7 голосов
/ 15 декабря 2010
  1. Обычно ваша OpenMP-программа не знает и не заботится о том, на каких ядрах она работает.Если у вас есть система управления заданиями, которая может предоставить нужную вам информацию в своих файлах журнала.В противном случае вы могли бы, вероятно, вставить вызовы в среду внутри ваших потоков и проверить значение некоторой переменной среды.Как это называется и как вы это делаете, зависит от платформы, я оставлю это на ваше усмотрение.

  2. Как, черт возьми, я (или любой другой SOer) должен знать?Для обоснованного предположения вы должны будете рассказать нам намного больше о вашем оборудовании, операционных системах, системе времени выполнения и т. Д. И т. Д. И т. Д. И т. Д. Лучший ответ на этот вопрос - тот, который вы определяете по своим собственным измерениям.Я боюсь, что вы также можете ошибаться, думая, что информация передается по компьютеру - переменные программирования с общей памятью обычно остаются в одном месте (или, по крайней мере, вы должны думать о том, что они находятся в одном месте, в реальности ситуация может быть намного более запутанной).но также невозможно различить) и не отправляется или не получает.

  3. Параллельные отладчики, такие как TotalView или DDT , вероятно, являются лучшими инструментами.Я еще не использовал параллельные возможности Intel отладчика, но они выглядят многообещающими.Я оставлю это менее хорошо финансируемым программистам, чем я, чтобы рекомендовать варианты FOSS, но они есть.

  4. i) Выберите самый быстрый параллельный алгоритм для вашей задачи.Это не обязательно самый быстрый последовательный алгоритм, выполняемый параллельно.

    ii) Проверка и измерение.Вы не можете оптимизировать без данных, поэтому вы должны профилировать программу и понимать, где узкие места производительности.Не верьте никаким советам о том, что «X быстрее, чем Y».Такие заявления обычно основаны на очень узких и часто устаревших случаях и стали, по мнению их покровителей, «истинами».Почти всегда можно найти контрпримеры.Это ВАШ код, который ВЫ хотите сделать быстрее, ничто не заменит ВАШИХ расследований.

    iii) Знайте свой компилятор наизнанку.Доходность (измеренная в улучшениях скорости кода) за время, потраченное на настройку параметров компиляции, намного выше, чем доходность от изменения кода «вручную».

    iv) Одна из «истин»Я цепляюсь за то, что компиляторы не очень хорошо умеют оптимизировать использование иерархии памяти на современных процессорных архитектурах.Это одна из областей, где изменение кода вполне может быть целесообразным, но вы не узнаете об этом, пока не представите свой код.

1 голос
/ 15 декабря 2010
  1. Вы не можете знать, что разделение потоков на разные ядра полностью обрабатывается ОС. Вы говорите об узлах, но OpenMP - это многопоточное (а не многопроцессорное) распараллеливание, которое позволяет распараллеливать для одной машины, содержащей несколько ядер. Если вам нужно распараллеливание на разных машинах, вам нужно использовать многопроцессорную систему, такую ​​как OpenMPI.

  2. Порядок величины времени связи:

    • огромен в случае обмена данными между ядрами внутри одного и того же процессора, его можно считать мгновенным
    • ~ 10 ГБ / с для связи между двумя ЦП через материнскую плату
    • ~ 100-1000 МБ / с для сетевых соединений между узлами, в зависимости от аппаратного обеспечения

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

  3. Для OpenMP, gdb хорошо справляются с работой, даже со многими потоками.

  4. Я работаю в симуляции экстремальной физики на суперкомпьютере, вот наши ежедневные цели:
    • использовать как можно меньше связи между потоками / процессами, 99% времени это связь, которая убивает производительность в параллельных заданиях
    • оптимально разделить задачи, нагрузка машины должна быть как можно ближе к 100% все время
    • проверка, настройка, повторная проверка, повторная настройка .... Распараллеливание вовсе не является общим «чудодейственным решением», оно обычно требует некоторой практической работы, чтобы быть эффективным.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...