Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Опубликован стандарт параллельного программирования OpenMP 6.0"	+/–
Сообщение от opennews (??), 15-Ноя-24, 10:44
После трёх лет разработки опубликован набор спецификаций OpenMP 6.0 (Open Multi-Processing), определяющих API и способы применения методов параллельного программирования для языков Си, Си++ и Фортран на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD).  Предполагается, что начальная поддержка отдельных возможностей OpenMP 6.0 будет включена в состав выпусков LLVM/Clang 20 и GCC 15... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62236
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 15-Ноя-24, 10:44	+3 +/–
Существуют ли какие-то применения openmp на практике?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #9, #12, #13, #26, #57, #59, #61

4. Сообщение от Аноним (4), 15-Ноя-24, 11:12	+/–
В Gentoo добавил, кроме всего прочего, в CFLAGS="... -fopenacc -fopenmp ..." Все собирается и работает без проблем. Увеличение производительности не тестировал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #18, #20

5. Сообщение от Аноним (5), 15-Ноя-24, 11:15	+3 +/–
Извините, ничего производительнее, чем просто std::thread, мои эксперименты не нашли. Ни TBB, ни OpenMP.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #10, #11, #14, #56, #64

6. Сообщение от Аноним (1), 15-Ноя-24, 11:19	+1 +/–
> Увеличение производительности не тестировал. Было ли это увеличение, скорее там уменьшение. У меня  для фортрана так с надеждой на лучшее (а гфортран очень тормозной код генерирует в целом) FCFLAGS="${COMMON_FLAGS} -fopenmp -fprefetch-loop-arrays -fexternal-blas -fblas-matmul-limit=15" Наверно какие-то применения на суперкомпах можно найти, но вот есть ли преимущества обычного софта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #8

7. Сообщение от Анониматор (?), 15-Ноя-24, 11:26	+5 +/–
Вряд ли оно имеет целью увеличение производительности. Скорее просто стандарт, чтоб программисту было легче пересаживаться с одного языка на другой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (8), 15-Ноя-24, 11:43	+11 +/–
Если в софте возможности OpenMP никак не использованы, то и пользы от добавления этих флагов никакой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #37

9. Сообщение от Аноним (9), 15-Ноя-24, 11:47	+5 +/–
Для консьюмерских приложений, вроде нет ничего современного... Проблема в архитектуре современных серверов. Сейчас нельзя просто так купить привычные для OpenMP SMP-систему, везде ccNUMA и всякие гетерогенные SoC. В этой ситуации сама концепция shared memory и модель fork-join летит псу под хвост. Да, безусловно OpenMP поддерживает NUMA в какой-то степени в какой-то из свежих спецификаций, что даёт понять приложению о топологии памяти (она же неравномерная). Вот только дальше начинается проблема с фиктивными ядрами на всяких современных amd64-процессорах. Ну знаете, когда в процессоре 48 "физических" ядер, а с DRAM-контроллером могут взаимодействовать только 12. При этом из них только 4 могут иметь один мультиплаер по частотам, а все остальные другой. То есть по идее можно все переписать на новые версии OpenMP, но кто бы это делал... Ну то есть масштабирование многопоточного приложения на системах с неравномерным доступом к памяти обычно требует реализации внутренненго планировщика, выполненного как супер-сервер. Таких реализаций на OpenMP я не знаю, возможно они есть, скиньте. Альтернатива - платформозависимые API для работы с потоками и процессами, которые умеют лучше и больше, но уже под конкретную ОС/планировщик. По-факту, никто не парится. Все эти высокопросизводительные многопоточные вычисления просто пихают в виртуалки, чтобы вышестоящая инфра разобралась со всем этим и выдала равномерную память UMA, где shared memory не деградирует за счёт того что часть тредов/физических устройств сидят за интерконнект-шинами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #29, #67

10. Сообщение от Аноним (8), 15-Ноя-24, 11:47	+1 +/–
std::thread, само по себе, никак не задействует DSP, если он емеется, и/или GPU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #17

11. Сообщение от Аноним (11), 15-Ноя-24, 12:07	+/–
У него под капотом обычный pthread
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15

12. Сообщение от Анонимов (?), 15-Ноя-24, 12:09	+4 +/–
Не особо. Раньше можно было выйграть пару циклов в расчетном по для суперкластеров в связке OpenMP+MPI (HybridPP), но в последние лет 10 особо голову сношать себе не хочет и используют чистый MPI.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

13. Сообщение от Neon (??), 15-Ноя-24, 14:08	+1 +/–
Для некоторых задач, типа решения систем диф.уравнений, работа с матрицами и т.д. дает значительное ускорение. Обычно такие задачи специализированные и самописные. Обычному софту openmp мало помогает, плохо автоматически он параллелиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

14. Сообщение от Neon (??), 15-Ноя-24, 14:10	–1 +/–
Ну так openmp делает тоже самое, только автоматически для некоторых задач. Выше физических ограничений платформы не прыгнешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #16

15. Сообщение от Аноним (17), 15-Ноя-24, 14:51	+/–
Во-первых, необязательно. Во-вторых, именно поэтому я pthread не упомянул. Это платформозависмое API, которое бесполезно почти. Обёртки вокруг него и winapi - zero cost, нет особых причин юзать платформозависимое API.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

16. Сообщение от Аноним (17), 15-Ноя-24, 14:52	–2 +/–
>только автоматически С OpenAI o1 не путайте. Кодить всё равно приходится. Причём то же самое, просто в другом виде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Аноним (17), 15-Ноя-24, 14:52	+/–
Для оных - OpenCL/Sycl.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

18. Сообщение от Аноним (18), 15-Ноя-24, 15:56	+/–
Если софт использует OpenMP, то он без этих флагов не скомпилируется, как я понимаю. Нужные пакеты сами добавляли, а для остальных бесполезно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #77

19. Сообщение от Аноним (19), 15-Ноя-24, 16:07	+8 +/–
Все эти потоки и многопроцессорность не что иное как путь в никуда. Инженерам нужно увеличивать производительность в однопотоке, а не костылить. А то вон уже есть процы со 192 потоками, а скроллинг в хроме всё равно со статтерами и микрофризами.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #27, #35, #41, #42, #65, #66

20. Сообщение от Аноним (20), 15-Ноя-24, 16:09	+1 +/–
"... -fopenacc... гусары молчать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #33, #62

21. Сообщение от anonymous (??), 15-Ноя-24, 16:33	–2 +/–
Скроллинг со статтерами (кандидат на новый мем? вместо "как конпелять кде под фрибзд")? Из за натыканых везде особенно в ядре "сохранялок энергии". Как нубуки стали пиарить, с тех пор всё в этой коричневой "энергосохраняющей" субстанции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23

23. Сообщение от Аноним (19), 15-Ноя-24, 16:52	+1 +/–
Да ты повідключай все энергосберегайки, так комп будет жрать как 4 пни во времена прескотов. И не факт что избавишься от статтеров, потому что они завязаны на 1 поток, на который разрабы куй ложили в угоду многопоточности. Даже в эппл не смогли побороть эту бяку, хотя вообще в отдельный поток вынесли отрисовку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #70

25. Сообщение от Аноним (25), 15-Ноя-24, 17:30	+/–
Параллельное программирование это когда два программиста работают над одной задачей. Multy Processing - множественная обработка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #36

26. Сообщение от Бывалый Смузихлёб (ok), 15-Ноя-24, 17:33	+2 +/–
как задача на лабораторной
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

27. Сообщение от Аноним (27), 15-Ноя-24, 17:43	–1 +/–
> Все эти потоки и многопроцессорность не что иное как путь в никуда. Инженерам нужно увеличивать производительность в однопотоке, а не костылить. Удивительно, как такие комментарии набирают кучу плюсиков. 🤦 Это многое говорит об уровне компетенции большей части здешних комментаторов. Да, уважаемый эксперт, нужно в один поток. А заодно вырубить оптимизации на уровне компилятора, а на уровне CPU - предсказание ветвей, спекулятивное выполнение и остальной прогресс за последние 40 лет. Ну, чтобы инженеры булки не расслабляли, а оптимизациями занимались. Вот тогда в хроме скроллинг будет ого-го!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

29. Сообщение от 123 (??), 15-Ноя-24, 17:48	+/–
> По-факту, никто не парится. Все эти высокопросизводительные многопоточные вычисления просто пихают в виртуалки, чтобы вышестоящая инфра разобралась со всем этим и выдала равномерную память UMA ха ха, она взяла и разобралась (нет), запихивание в виртуалки лишь иллюзия того, что в вышестоящем слое нет тех же самых проблем, и если тебя лично это беспокоит, то всех кто отвечают за верхний слой - не особо, бизнес крутится лавешка мутится, не мамонты не вымрут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #91

31. Сообщение от 123 (??), 15-Ноя-24, 17:53	+/–
Parallel Processing, Parallel Execution то же может применяться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #53

33. Сообщение от Аноним (33), 15-Ноя-24, 18:24	+/–
У меня две дискретки AMD стоят, раньше и opencl включал, вдруг поможет производительности для пары пакетов. Или есть какие нюансы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #63

34. Сообщение от Аноним (-), 15-Ноя-24, 19:09	+/–
А - зачем это "массовому среднему" программисту и пользователю ПК? Сколько решают Невье-Стокса и пишут грамотно софт, который хорошо параллелится? Ну - просто - фиг с ним с этим OpenMP! - какой процент программеров нормально и ОСОЗНАННО с потоками в POSIX-thread может работать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #52

35. Сообщение от Аноним (-), 15-Ноя-24, 19:16    Скрыто ботом-модератором	–1 +/–
Многопоточность - это путь к созданию адекватных моделей предметных областей. Просто надо "УМЕТЬ в потоки" и - "в параллельность". Ну, то есть, - грамотно проектировать, а не только "код гнать". А то мода появилась спорить в чатах и конфах "что лучше", какая реализация многопоточности - нативные потоки, горутины, корутины, "хрензнащо"рутины... Тут ведь - как у "Ленинграда" в "ЗОЖ"- "если в башне пое-ень, то - хоть е-ень, хоть - не е-ень!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

36. Сообщение от Аноним (36), 15-Ноя-24, 19:21	+2 +/–
Вы не поняли, это когда параллельно на программирование, но кипишь идёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

37. Сообщение от anonymous (??), 15-Ноя-24, 20:56	+/–
Если в софте OpenMP не задействован, то к нему и use flag не применится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #43

41. Сообщение от Аноним (41), 15-Ноя-24, 22:34	+/–
— Обязательно 10 ГГц! И 20 ГГц! Весь мир в труху!.. Но потом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

42. Сообщение от Аноним (42), 16-Ноя-24, 00:41	+3 +/–
Простейший пример: Открытие/Закрытие файла, работа с медленным устройством, многозадачность. В один поток как-то "ухабисто".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #44, #46

43. Сообщение от Вымя (?), 16-Ноя-24, 00:42	+/–
Я так понял что анон глобально добавил флаг при сборке всех пакетов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #68, #69

44. Сообщение от Аноним (44), 16-Ноя-24, 01:55	–7 +/–
> Простейший пример: > Открытие/Закрытие файла, работа с медленным устройством, многозадачность. > В один поток как-то "ухабисто". Да забей, персонаж не понимает, что несет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #45

45. Сообщение от Аноним (45), 16-Ноя-24, 02:17	+/–
Он вообще-то правильно обозначил проблему, пусть и слегка в шутливой форме. Многопоточность это действительно гигакостыль, который порождает усложнение, а следовательно невероятное количество ошибок и уязвимостей ещё на уровне проектирования SoC, не говоря про программирование.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #48

46. Сообщение от Аноним (45), 16-Ноя-24, 02:28	+1 +/–
> Открытие/Закрытие файла, работа с медленным устройством, многозадачность. Для работы с I/O не надо over 9000 ядер и потоков. Выше проблему подняли правильно, потому что все гонятся за циферками в multiple threads, забывая о том, что по производительности на ядро системы практически топчутся на месте последние лет 15.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #54

47. Сообщение от Аноним (45), 16-Ноя-24, 02:33	+/–
Большинство десктоп-ориентированных задач выполняются в а-ля event loop'е. Но где-то на задворках, в глубоком ынтерпрайзе, может и нужно для каки-то специфических вычислений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #55

48. Сообщение от Аноним (44), 16-Ноя-24, 03:20	–5 +/–
> Многопоточность это действительно гигакостыль, который порождает усложнение, а следовательно невероятное количество ошибок и уязвимостей ещё на уровне проектирования SoC, не говоря про программирование. Похоже, что люди делают усложнения ради усложнений, так ведь? Другого объяснения сего парадокса опеннетный эксперт не видит? Ну вот не додумались, дурачки, до такого простого решения всех проблем - не использовать многопоточность. А если серьезно я представляю, как тот персонаж взвыл, если бы его хром с лагающим скроллбаром стал вдруг работать в один поток и один процесс. Откуда ж вы, эксперты такие, лезете...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

52. Сообщение от Аноним (52), 16-Ноя-24, 03:59	+/–
При чём тут урматы? Треды - это абсолютно естественная модель, которая элементарно воспринимается нормальным человеком: два процессора выполняют команды параллельно. Все остальные модели требуют какого-то недюжинного напряжения воображения, и всё равно в итоге почти всегда сводятся к тредам. Единственная более естественная модель - это чистый fork() и запуск нескольких программ одновременно, но большинство естественных задач так не решить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #73

53. Сообщение от Аноним (53), 16-Ноя-24, 04:05	+/–
компьютинг забыли)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

54. Сообщение от Аноним (41), 16-Ноя-24, 05:36	+/–
> обозначил проблему, пусть и слегка в шутливой форме > забывая о том, что по производительности на ядро системы практически топчутся на месте последние лет 15. А как ты себе представляешь серьёзный разговор на эту тему? Я только так: "мальчик, 20 лет назад перестал работать закон масштабирования Деннарда - частоты упёрлись в потолок и сразу появились многоядерные процессоры, тут не о чем забывать".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

55. Сообщение от Аноним (55), 16-Ноя-24, 10:34	+1 +/–
Пишу из задворков глубокого интырпрайза. Сколько раз пытались применить OpenMP, столько раз оказалось не нужным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

56. Сообщение от Аноним (56), 16-Ноя-24, 12:14	+/–
пук в лужу, ей-богу. стд трид. Почитал бы статью, глядишь и программировать бы начал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

57. Сообщение от ijuij (?), 16-Ноя-24, 12:28	+/–
В суперкомпьютерах юзают часто!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #58

58. Сообщение от Аноним (1), 16-Ноя-24, 12:58	+/–
Вроде не так и часто. Но тут суть в том, что на суперкомпах запускают ровно те же mkl и fftw и применений могло бы быть и побольше. Вроде даже даже у opencv tbb в итоге, видимо, совсем неудобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

59. Сообщение от Аноним (59), 16-Ноя-24, 13:03	+/–
> Существуют ли какие-то применения openmp на практике? Используется в некоторых местах в ImageMagick. Не знаю, насколько он помогает. Еще есть в libsoxr, но там его использование больше вредит производительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #60

60. Сообщение от Аноним (1), 16-Ноя-24, 13:21	+/–
Примерно как opencl в x264?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

61. Сообщение от Аноним (-), 16-Ноя-24, 15:54	+1 +/–
Ну когда я был студентом и изучал OpenGL, то делал тестовое задание для компании Samsung. Да, оно реально работает. Меня правда не взяли из-за проблем с документами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

62. Сообщение от Аноним (-), 16-Ноя-24, 15:56	+/–
Ну так это видеокарта, а не процессор. Вообще тоже отличная штуковина.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

63. Сообщение от Аноним (-), 16-Ноя-24, 16:00	+/–
По производительности OpenAcc почти такой же как CUDA, чуть меньше правда, но код выглядит более красиво и понятно. По моему мнению его проще и понять и использовать. Связка OpenMP + MPI + OpenACC вообще дает отличный результат, если вы конечно понимаете нюансы что лучше делать на видеокарте, что на процессоре и как это все выполнять параллельно и как это все вместе синхронизировать (если необходимо).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #72

64. Сообщение от Аноним (-), 16-Ноя-24, 16:05	+/–
Ну так дело же не в самой производительности, а в удобстве использования. То что оно выполняет свои задачи распараллеливания кода - факт. А с чего вы взяли что оно должно быть самым производительным? Разве они такое заявляли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

65. Сообщение от Аноним (-), 16-Ноя-24, 16:12	–1 +/–
Я вам напомню историю - все эти многопроцессорности и многопоточности были придуманы в России, только наработки сбежали вместе с Пионтковским. Он стал большой шишкой в Интел и вышли новые процессоры. Об этом есть полно информации в инете. И ещё, а как это связано с вашей проблемой скролинга и фризов браузера?  У меня вот таких проблем нет. Причем даже на старом оборудовании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #71, #74, #92

66. Сообщение от Аноним (66), 16-Ноя-24, 16:13	+/–
Скролингом вообще видиха заниматься должна, а не сpu
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

67. Сообщение от Аноним (-), 16-Ноя-24, 16:20	+/–
> То есть по идее можно все переписать на новые версии OpenMP, но кто бы это делал... Ну если код не секретный, то ИИ, разве нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

68. Сообщение от Аноним (-), 16-Ноя-24, 16:34	+/–
У меня Gentoo. Глобально стоит: USE="... opencl openmp ..." включает поддержку в скрипте .configure который может добавлять опции компиляции в Makefile. CFLAGS="... -fopenacc -fopenmp ..." включает поддержку кода компилятором В portage примерно 31 пакет поддерживает сборку с opencl и около 90 собираются с openmp и 0 пакетов используют openacc. Из них у меня в системе используется в общем чуть больше 20 пакетов. А что есть проблемы с установкой этих опций глобально? Именно openmp в Gentoo относится к глобальным опциям. Лет 5-7 уже использую эти опции и проблем не заметил. Могу CFLAGS сделать только для определенных пакетов, но это нежелательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

69. Сообщение от Аноним (-), 16-Ноя-24, 16:56	+/–
Добавить флаг это одно, а увеличение производительности это другое. Работу Opencl в radeontop я так и не увидел. Работу OpenMP никогда не тестировал. По поводу openacc не известно есть ли у меня в системе пакеты его использующие. smp ntpl pthread точно работают, архиваторы, видеокодировщики запускают свои фотки на ядрах CPU, загружают их на 100% (в htop видно) и в разы ускоряют работу программы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

70. Сообщение от anonymous (??), 16-Ноя-24, 17:28	+/–
Десятки лет уже невозможно это отключить, оно напихано везде, в надежде спровоцировать отключение блоков процессоров да и остального железа вплоть до PCI и памяти чтобы пальцетыкальщикам аккумуляторщикам было комфортнее. И невозможно спрогнозировать когда оно сработает. Надо в каменный век возвращаться срочно - своё железо делать. Иначе программирование превратится в сельское хозяйство - "инде взопрели озимые, вышел старик понюхал портянку и аж заколдобился". То ли будет урожай то ли нет и надо другое сажать. То ли будет статтер если фазза луны и проприетарная фирмварь решит надо отключить то ли нет. А от тебя ничего не зависит как и от колхозника.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

71. Сообщение от anonymous (??), 16-Ноя-24, 17:38	+/–
Фантазии какие то. Просто технологически стало возможно несколько процессоров на 1 кристалл впихнуть и даже кэши. А так как процессор плоский а задержка сигнала зависит от квадрата расстояния (из-за особенностей физических свойств проводников в кристалле, там сильно погонная ёмкость и сопротивление влиять начинает на тех частотах) то чем физически ближе расположишь блоки тем быстрее будет работать при всех равных. Вот и стали проектировать исходя из того что всё что часто обменивается данными должно быть рядом в кластерах. И получилось - реальная скорость резко взросла. Всё бросили на многоядерность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

72. Сообщение от Аноним (72), 16-Ноя-24, 18:05	+/–
MPI надо отдельно на узлах кластера настраивать. OpenACC не нашёл прог которые его используют. OpenCL на mesa и свободных драйверах видеокарт AMD не у меня работает. Если кто знает как настроить помогите. Я вижу проблему в отсутствии поддержки Clover OpenCL в mesa:  https://mesamatrix.net/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #86

73. Сообщение от Аноним (-), 16-Ноя-24, 18:13	+/–
>Треды - это абсолютно естественная модель, которая элементарно воспринимается нормальным человеком: два процессора выполняют команды параллельно. Как чистосишник скажу. Возьмём к примеру 4-х ядерный процессор и запустим на нём программу, которая выполняется в 4 потока. Мы точно не будем знать, выполняются ли эти 4 потока на 4-х физических процессорах одновременно. Может статься так, что процессор выполнит первый и второй поток на одном физическом ядре, третий и четвёртый потоки на третьем и чётвёртом физическом ядре соответственно. Более того, никто не сможет гарантировать того, что процессор вздумает выполнить 4 потока на одном физическом ядре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #78

74. Сообщение от Аноним (-), 16-Ноя-24, 18:40	–1 +/–
> все эти многопроцессорности и многопоточности были придуманы в России, только наработки сбежали вместе с Пионтковским Боян, котрому 200 лет. Россия сама тырила европейские технологии. Украв, копировала у себя некачествеено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #88

77. Сообщение от svpcom (ok), 16-Ноя-24, 23:09	+1 +/–
весь openmp работает через #pragma. То есть если компилятор это не поддерживает, то просто будет код выполняться последовательно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

78. Сообщение от Аноним (78), 16-Ноя-24, 23:34	+/–
Ну и что? Док на критикал секшн и всё, не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #79

79. Сообщение от Аноним (78), 16-Ноя-24, 23:34	+/–
Лок имелось ввиду
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

83. Сообщение от Аноним (-), 17-Ноя-24, 00:40	+/–
Это были совместные разработки. Даже в 90-х ещё что-то было.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

86. Сообщение от gentoo (?), 17-Ноя-24, 13:16	+/–
Вопрос применения очень запутанный. Примененение видеокарт gpu для разгрузки процессора cpu имеет очень много ньюансов. Для видеокарт AMDradeon (желательно не ниже архитектуры названия кода polaris10 см. доки на gcc и LLVM) надо установить набор программ ROCM версия opencl-2.1 недавно подняли до версии 3.0 но есть один нюанс требования к версии pciexpress не ниже 3.0 так как в версия 2.0 не поддеррживает атомарные операции на шине (введеные в ROCM софт amd не понятно зачем хотя понятно чтоб железо новое покупали) Есть обходной путь установить opencl-2.1 из драйвера amdgpupro последней версии (имеется ввиду до выхода ROCM) в gentoo так. Далее в CFLAGS= -march=native -fopenmp -fopenacc -pipe gcc автоматом подхватит видеокарту (если одна) если не одна указываем флаги выбора gpu -foffload=target (читаем путанные доки экспериментируем так как все меняется) В Clang примерно тоже но флаги чуть разные. В любом случае нужно установить SPIRV-LLVM-translator opencl-clang-translator Проверим opencl > clinfo видим что (PAL/HSAIL) языки для гетерогенных вычислений. Да и чем новее версии компилятора тем лучше. Код на С С++ имеющий pragma (на спец код матрицы диф уравненияи т.п) и иже с ним будет отравлять c помощю компилятора это дело на SPIRV opencl (читаем доки) далее на видеокарту затем система сборки откомпилированную часть кода вернет обратно в сборку и бинарь программы собран. Да mesa c rusticl не предназначен для компиляции C C++ (надеюсь пока обратите внимание на clinfo какие расширения поддерживает opencl-rusticl сравните с проприетарным или ROCM). emerge -av и далее собираем. С nvidia не в курсе там cuda может все проще но AMD это ад. Смотрим в radeontop Cчас компилирую на AMD-RX570-8G Clang (с помощю GCC-14)часть кода пошла на видеокарту и оба баг не знаю на 1942 выводе стэка проц пошел в один поток и еле еле навидеокарте.Сборка тормозит (на некоторых программах) но считает на видеокарте что то с потоками не знаю для меня это все пока в новинку. В других дистрах может все проще не проверял и не хочу gentoo устраивает во всем. Кто чего добавит по этому делу или поправит спасибо. Да и не совсем понятно как компиляторы подхватывают opencl доки очень мутные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #89, #90

87. Сообщение от Аноним (-), 17-Ноя-24, 14:32	+/–
Так и это бы удалил. Люди то не поймут к чему и кому персонально мессендж был адресован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

88. Сообщение от Аноним (-), 17-Ноя-24, 14:35	+1 +/–
Ага а в Болгарии просто так проходят встречи о том как возродить отечественную электронику. У них она наверно с помощью магии нарисовалась. А факт в том что после распада цепочки поставок нарушились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

89. Сообщение от Аноним (-), 18-Ноя-24, 10:11    Скрыто ботом-модератором	+/–
Огромное спасибо разработчикам ChatGPT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

90. Сообщение от Аноним (-), 18-Ноя-24, 11:56	+/–
Чтобы OpenMP в Gentoo заработал надо кроме USE="... openmp ..." и CFLAGS="... -fopenmp ..." собрать sys-libs/libomp c USE="offload ompt".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

91. Сообщение от Аноним (91), 20-Ноя-24, 17:50	+/–
А как у них с безопасностью? В OpenCL здесь давно писали о дырах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

92. Сообщение от bOOster (ok), 21-Ноя-24, 10:09	+/–
Ну во первых не в России а в СССР и так называемом Соц.Лагере - две большие разницы. А во вторых еще дофига технологий так-же появились в СССР + СЛ например onchip DMA и т.п.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

93. Сообщение от anonymous (??), 21-Ноя-24, 12:20	+/–
>Обеспечена поддержка сохранения графа задач (taskgraph), определяющего зависимости между задачами и порядок выполнения задач, для повышения эффективности последующего повторного воспроизведения. Т.е. make теперь можно средствами OpenMP реализовать, окромя парсера?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема