Гасенин Леонид. Технология OMP. Поиск кратчайших путей из одной вершины (алгоритм Дейкстры). Вариант 21.

[Leontin16]

• Задача: Поиск кратчайших путей из одной вершины (алгоритм Дейкстры).

• Вариант: 21.

• Технология: OMP.

• Описание:
  В OMP версии реализован классический алгоритм Дейкстры с линейным поиском вершины, имеющей минимальное текущее расстояние (сложность O(n²)). Граф строится неявно как полный: вес ребра между вершинами i и j равен |i - j|. Начальная вершина — 0. Входной параметр InType задаёт количество вершин n. Выходное значение — сумма кратчайших расстояний от вершины 0 до всех вершин (включая саму вершину 0). Благодаря специальному виду графа ожидаемый результат известен аналитически:

  $$\text{sum} = \frac{n(n-1)}{2}$$

  Это позволяет легко проверить корректность работы алгоритма.

  Параллельная реализация:

  • Количество потоков определяется один раз в начале выполнения с помощью omp_get_num_threads() внутри параллельной области.
  • Поиск вершины с минимальным расстоянием (FindGlobalVertexOMP) распараллелен следующим образом:
    • Каждый поток ищет локальный минимум среди непосещённых вершин в своей порции итераций (цикл с #pragma omp for nowait).
    • Локальные минимумы и соответствующие вершины сохраняются в общие массивы.
    • С помощью #pragma omp barrier обеспечивается завершение локального поиска всеми потоками.
    • В #pragma omp single один поток выбирает глобальный минимум из локальных и помечает выбранную вершину как посещённую.
  • Релаксация рёбер (RelaxEdgesOMP) выполняется параллельно для всех вершин, кроме текущей глобальной, с использованием #pragma omp parallel for. Для каждого соседа вычисляется новый путь и при необходимости обновляется расстояние.
  • Итоговая сумма расстояний (CalculateTotalSumOMP) считается с редукцией (#pragma omp parallel for reduction(+:total_sum)), что позволяет избежать гонок данных.
  • Все критические секции (обновление глобальной вершины, массива visited) защищены либо атомарными операциями, либо выполняются внутри single, что гарантирует корректность при параллельном выполнении.

• Тестирование:

  • Функциональные тесты для n = 3, 5, 7 проверяют совпадение полученной суммы с ожидаемой (n(n-1)/2).
  • Перформанс-тесты используют n = 200 для измерения времени выполнения и сравнения с последовательной версией.
  • Для организации тестов применяются готовые утилиты ppc::util::BaseRunFuncTests и ppc::util::BaseRunPerfTests.

---

Чек-лист

• Статус CI: Все CI-задачи (сборка, тесты, генерация отчёта) успешно проходят на моей ветке в моем форке
• Директория и именование задачи: Я создал директорию с именем <фамилия>_<первая_буква_имени>_<короткое_название_задачи>
• Полное описание задачи: Я предоставил полное описание задачи в теле pull request
• clang-format: Мои изменения успешно проходят clang-format локально в моем форке (нет ошибок форматирования)
• clang-tidy: Мои изменения успешно проходят clang-tidy локально в моем форке (нет предупреждений/ошибок)
• Функциональные тесты: Все функциональные тесты успешно проходят локально на моей машине
• Тесты производительности: Все тесты производительности успешно проходят локально на моей машине
• Ветка: Я работаю в ветке, названной точно так же, как директория моей задачи
  (например, nesterov_a_vector_sum), а не в master
• Правдивое содержание: Я подтверждаю, что все сведения, указанные в этом pull request, являются точными и
  достоверными

[Leontin16]

Шаблон оформления патчей:
номер.вариант.фиксы clang-tidy.оптимизация.покрытие.omp.остальное

[Leontin16]

Тесты падают по причине внутренних ошибок серваков гита (HTTP 500), попробую запушить еще один пустой коммит, если не пройдет, попробую завтра ¯ \ (ツ) / ¯

[Leontin16]

Все понятно