Распараллеливание программного обеспечения с OpenMP по сравнению с планированием Affinity?

Сценарий: у меня есть программа, которую можно легко распараллелить с помощью OpenMP, скажем, основной цикл программы — это цикл for и независимые данные внутри него, поэтому его распараллеливание было бы тривиальным. Однако в настоящее время я не распараллеливаю его, а вместо этого использую родственное планирование.

Эта программа выполняет работу с некоторыми входными файлами, указанными папкой в ​​аргументах командной строки. Чтобы запустить эту программу параллельно, кто-то может создать такой bat-файл:

start \affinity 1 "1" bat1
start \affinity 2 "2" bat2
start \affinity 3 "3" bat3
start \affinity 4 "4" bat4

где bat1-4 — это bat-файл, который вызывает main.exe с другой входной папкой для каждого bat-файла. Таким образом, в этом случае будет 4 экземпляра main.exe, работающих на input_folder1, input_folder2, input_folder3, input_folder4 соответственно.

Какие преимущества дает использование такой библиотеки, как OpenMP, вместо планирования сродства? я думаю

  • Меньше использования памяти, один стек и куча для одного экземпляра программы, в отличие от n экземпляров программы для n ядер.
  • Лучшее масштабирование

Но могу ли я ожидать повышения производительности? Почему, если так?


c c++ openmp parallel-processing affinity
person Syntactic Fructose    schedule 20.04.2016    source источник
comment
Как насчет преимущества, заключающегося в том, что пользователю не нужно создавать огромный bat-файл каждый раз, когда его нужно запускать параллельно?   -  person NoseKnowsAll    schedule 21.04.2016

Ответы (1)


arrow_upward
1
arrow_downward

Если ваша проблема просто параллельна, без взаимодействия между данными в отдельных входных файлах, то вы, вероятно, не увидите ускорения с OpenMP, а можете даже увидеть замедление, так как выделение памяти и различные другие вещи тогда должны быть потокобезопасным. Однопоточные процессы могут значительно повысить эффективность, и на самом деле это происходит в GNU libc, где поддержка компоновки в потоках POSIX означает, что вы также получаете более медленную реализацию malloc

person Phil Miller    schedule 20.04.2016
comment
Последнее утверждение о malloc интересно. Не могли бы вы дать несколько ссылок на исходный код glibc или документацию, подтверждающую его? Я не вижу malloc в разных версиях в glibc 2.12 или новее, хотя ptmalloc2 может быть скомпилирован без потокобезопасности. Кроме того, в библиотеке есть возможность создать одну область памяти на ядро ​​для (почти) безблокировочной реализации malloc, и по крайней мере в дистрибутивах на основе RedHat эта опция включена. - person Hristo Iliev; 21.04.2016
comment
Это по памяти, но я помню, что связывание с -lpthread привело к другой версии или, возможно, вставленной конфигурации сборки malloc. - person Phil Miller; 21.04.2016