Странное поведение примера библиотеки Parallel Boost Graph Library - PullRequest
Новая
       88

Странное поведение примера библиотеки Parallel Boost Graph Library

0 голосов
/ 15 октября 2019

Я настроил простые тесты с помощью библиотеки Parallel Boost Graph Library (PBGL), которые я никогда раньше не использовал, и наблюдал совершенно неожиданное поведение, которое я хотел бы объяснить.

Мои шаги были следующими:

  • Дамп тестовых данных в формате METIS (вид социального графа с 50 млн вершин и 100 млн ребер);

  • Создание модифицированного примера PBGL из graph_parallel\ example \ dijkstra_shortest_paths.cpp

    • Пример был немного расширен, чтобы перейти к алгоритмам Eager, Crauser и delta-step.

      Примечание: построение примера потребовало некоторого неясного обходного пути для определения MUTABLE_QUEUE в crauser_et_al_shortest_paths.hpp (пример кода фактически несовместим с новым mutable_queue) 

    int lookahead = 1;  
    delta_stepping_shortest_paths(g, start, dummy_property_map(), get(vertex_distance, g), get(edge_weight, g), lookahead);  
    dijkstra_shortest_paths(g, start, distance_map(get(vertex_distance, g)).lookahead(lookahead));  
    dijkstra_shortest_paths(g, start, distance_map(get(vertex_distance, g)));

  • Выполнить

    mpiexec -n 1 mytest.exe mydata.me
    mpiexec -n 2 mytest.exe mydata.me
    mpiexec -n 4mytest.exe mydata.me
    mpiexec -n 8 mytest.exe mydata.me

Наблюдаемое поведение:

  • -n 1 :
    Использование памяти: 35 ГБ в 1 рабочем процессе, который использует ровно 1 поток устройства (загрузка процессора 12,5%)
    Время дельта-шага: около 1 мин 20 с
    Время ожидания:около 2 мин
    время краузера: около 3 мин 20 с.

  • -n 2 : сбой на этапе загрузки данных.

  • -n 4 :
    mem использование: 40+ Гб в примерно равных частях в 4 запущенных процессах, каждый из которых использует ровно 1 поток устройства.
    время вычислений не изменяется в пределах ошибки наблюдения.

  • -n 8 : использование
    mem: 44+ Гб в примерно равных частях в 8 запущенных процессах, каждый из которых использует ровно 1 поток устройства
    время вычислений остается неизменным в пределах ошибки наблюдения.

Таким образом, кроме ненадлежащего использования памяти и очень низкой общей производительности, наблюдаются только те изменения, которые наблюдаются, когда запущено больше процессов MPI. общее потребление памяти и линейный рост загрузки процессора. Тот факт, что исходный граф каким-то образом разделен между процессами (вероятно, по диапазонам номеров вершин), тем не менее очевиден.

Что не так с этим тестом (и, возможно, с моей идеей использования MPI в целом)?

Моя среда:
- один компьютер Win 10 с 64 Гб и 8 ядрами;
- MS MPI 10.0.12498.5;
- MSVC 2017, набор инструментов 141;
- повышение 1.71

NB. См. Оригинальный пример кода здесь .

...