|
2.4, Аноним (4), 11:12, 15/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
В Gentoo добавил, кроме всего прочего, в CFLAGS="... -fopenacc -fopenmp ..." Все собирается и работает без проблем.
Увеличение производительности не тестировал.
| |
|
3.6, Аноним (1), 11:19, 15/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Увеличение производительности не тестировал.
Было ли это увеличение, скорее там уменьшение.
У меня для фортрана так с надеждой на лучшее (а гфортран очень тормозной код генерирует в целом) FCFLAGS="${COMMON_FLAGS} -fopenmp -fprefetch-loop-arrays -fexternal-blas -fblas-matmul-limit=15"
Наверно какие-то применения на суперкомпах можно найти, но вот есть ли преимущества обычного софта?
| |
|
4.8, Аноним (8), 11:43, 15/11/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если в софте возможности OpenMP никак не использованы, то и пользы от добавления этих флагов никакой.
| |
|
|
2.9, Аноним (9), 11:47, 15/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
Для консьюмерских приложений, вроде нет ничего современного...
Проблема в архитектуре современных серверов. Сейчас нельзя просто так купить привычные для OpenMP SMP-систему, везде ccNUMA и всякие гетерогенные SoC.
В этой ситуации сама концепция shared memory и модель fork-join летит псу под хвост.
Да, безусловно OpenMP поддерживает NUMA в какой-то степени в какой-то из свежих спецификаций, что даёт понять приложению о топологии памяти (она же неравномерная).
Вот только дальше начинается проблема с фиктивными ядрами на всяких современных amd64-процессорах. Ну знаете, когда в процессоре 48 "физических" ядер, а с DRAM-контроллером могут взаимодействовать только 12. При этом из них только 4 могут иметь один мультиплаер по частотам, а все остальные другой.
То есть по идее можно все переписать на новые версии OpenMP, но кто бы это делал...
Ну то есть масштабирование многопоточного приложения на системах с неравномерным доступом к памяти обычно требует реализации внутренненго планировщика, выполненного как супер-сервер. Таких реализаций на OpenMP я не знаю, возможно они есть, скиньте. Альтернатива - платформозависимые API для работы с потоками и процессами, которые умеют лучше и больше, но уже под конкретную ОС/планировщик.
По-факту, никто не парится. Все эти высокопросизводительные многопоточные вычисления просто пихают в виртуалки, чтобы вышестоящая инфра разобралась со всем этим и выдала равномерную память UMA, где shared memory не деградирует за счёт того что часть тредов/физических устройств сидят за интерконнект-шинами.
| |
2.12, Анонимов (?), 12:09, 15/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не особо.
Раньше можно было выйграть пару циклов в расчетном по для суперкластеров в связке OpenMP+MPI (HybridPP), но в последние лет 10 особо голову сношать себе не хочет и используют чистый MPI.
| |
|
1.5, Аноним (5), 11:15, 15/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Извините, ничего производительнее, чем просто std::thread, мои эксперименты не нашли. Ни TBB, ни OpenMP.
| |
|
2.7, Анониматор (?), 11:26, 15/11/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вряд ли оно имеет целью увеличение производительности. Скорее просто стандарт, чтоб программисту было легче пересаживаться с одного языка на другой
| |
2.10, Аноним (8), 11:47, 15/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
std::thread, само по себе, никак не задействует DSP, если он емеется, и/или GPU.
| |
|
|