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

Опубликован стандарт параллельного программирования OpenMP 4.5, opennews (??), 29-Ноя-15, (0) [смотреть все] Мне показалось, или дизайн подправили , Илья (??), 11:45 , 29-Ноя-15, (1) С кем не общался, все упоминают OpenMP как костыль И на практике вообще не встр, Аноним (-), 12:13 , 29-Ноя-15, (2)   // Я пишу научное ПО с применением openmp В научных вычислениях это станадрт наряд, KLIM (?), 12:40 , 29-Ноя-15, (3) +2   OpenMP - адский костыль Представьте, каково это, отлаживать код в котором сущес, Аноним (-), 13:07 , 29-Ноя-15, (5) –1   // Кому не нравятся прагмы, есть подвижки к переходу на generalized attributes htt, ferux (ok), 17:22 , 29-Ноя-15, (18)   Костыль, но попадаются приложения его использующие тот же imagemagick , АнониМ (ok), 13:22 , 29-Ноя-15, (6) +1   Всё верно и добавить нечего , Аноним (-), 14:21 , 29-Ноя-15, (7) +1   Насколько я помню, изначальная идея была - быстро распараллелить старый код Поэ, Аноним (-), 14:38 , 29-Ноя-15, (8) +2   Мы используем в John the Ripper вот уже 5 лет OpenMP может работать костылем и, solardiz (ok), 15:38 , 29-Ноя-15, (9) +10   По моему ты ваще них я не понимаешь в параллельных вычислениях А сравнивать с , pavlinux (ok), 15:46 , 29-Ноя-15, (10) –8   // OpenMP прагмовая высокоуровневая обертка над тредами, Аноним (-), 15:48 , 29-Ноя-15, (11) +1   // Да-да, настоящие пОцаны сразу пишут на ассемблере, а не этих ваших высокоуров, Трорвальдс (?), 16:36 , 29-Ноя-15, (15) +1   Настоящие пацаны давно пишут наи т п , Аноним (-), 16:57 , 29-Ноя-15, (16) +1   Не вижу нигде осуждений, Аноним (-), 15:50 , 29-Ноя-15, (12)   Раскроешь нам эту изюминку OpenMP Ведь вопрос был как раз про это, и походу ты , Аноним (-), 15:52 , 29-Ноя-15, (13) +1   // Хранение последовательной и параллельной программы в едином файле исходного кода, Dark Amateur (?), 18:56 , 29-Ноя-15, (21) +2   Это такая сверх необходимая вещь и всем очень нужная, да еще и не реализуемая на, Аноним (-), 19:07 , 29-Ноя-15, (22) –2   Если программа больше 10 строк - то вещь очень нужная, как минимум для отладки Е, Dark Amateur (?), 19:15 , 29-Ноя-15, (23) +2   А в чем разница между отладкой однопоточного и многопоточного приложения Или ва, Аноним (-), 19:48 , 29-Ноя-15, (27) –2   Слив засчитан С , 10й Брейтовский переулок (?), 00:01 , 30-Ноя-15, (33) +1   Вопрос некорректен, Вы сравниваете теплое с мягким pthreads - библиотекаOpenMP -, mkarev (?), 19:25 , 29-Ноя-15, (24)   Не-не-не, как раз тёплое с мягким и сравниваем, а посему вопрос уместен Скажем , Dark Amateur (?), 19:39 , 29-Ноя-15, (25)   В худшем случае - Ваша программа упадет на машине без AVX PS раз уж сравнивать , mkarev (?), 19:46 , 29-Ноя-15, (26) –2   Начиная с Haswell это, вроде как, не так, Аноним (-), 19:54 , 29-Ноя-15, (28) –1   Да, потому что в хасвеле появился AVX2, mkarev (?), 19:57 , 29-Ноя-15, (29)   Нормальная программа не должна падать ни при каких обстоятельствах Особенно, ес, Dark Amateur (?), 20:05 , 29-Ноя-15, (30) +1   Согласен, для этого в нормальных программах обмазываются реализациями под кажд, mkarev (ok), 21:06 , 29-Ноя-15, (31) –3   CPUBoss с Вами не согласен http cpuboss com cpu AMD-FX-8320Кто сказал, что p, Dark Amateur (?), 21:45 , 29-Ноя-15, (32) +2   Простите, а что это тогда Да, конечно, вы намекаете компилятору, что тут можно , mkarev (ok), 09:03 , 30-Ноя-15, (37)   Я сталкивался с кодом, который использует OpenMP в подобных задачах https opu, redwolf (ok), 21:14 , 01-Дек-15, (43) +3   Вот еслибы это было кроссплатформенностью уровня выполнения, а не компиляции, це, bOOster (ok), 13:46 , 30-Ноя-15, (39) –2   По такой логике и Qt -- костыль И вообще решения на C -- костыль А Вы, слу, redwolf (ok), 21:20 , 01-Дек-15, (44) +1   Отличная практика путать жопу с пальцем Главное демагогией позаниматься , bOOster (ok), 04:48 , 02-Дек-15, (45) –2   Я активно использую openMP в программах на Ansi C11 и очень доволен, согласен чт, AAAAAAaaAAAAAA (?), 02:04 , 30-Ноя-15, (34) +1   из НЕ-проприетарного - он пока безальтернативен для HPC, к сожалению не на ICC-ж, Аноним (-), 18:20 , 05-Дек-15, (47)   OpenMP распространен в научном и инженерном софте, примерно так же как MPI, alexxy (ok), 12:42 , 29-Ноя-15, (4) +3 // Только местные школьники-дурачки про это не в курсе Эти кловуны выдают бред у, Трорвальдс (?), 16:27 , 29-Ноя-15, (14) –1 // OpenMP работает на pthreads, не , Аноним (-), 16:59 , 29-Ноя-15, (17) –5 // https software intel com en-us articles threading-models-for-high-performance-, KLIM (?), 17:25 , 29-Ноя-15, (19) +2 Нативно ни одна из этих ОС не поддерживает OpenMP Таким образом, на Unix-like О, dmitrmax (?), 09:58 , 30-Ноя-15, (38) OpenMP может работать с SIMD OpenMPI еще и сетевым слоем для распределения по GR, Аноним (-), 02:22 , 30-Ноя-15, (35) В догонку еще один http www mpich org , Аноним (-), 02:23 , 30-Ноя-15, (36) и прочая туфта распространена в научном и инженерном софте , Аноним (20), 18:32 , 29-Ноя-15, (20) А как вручную рассадить потоки по ядрам В pthread-ax разве есть такая возможност, Аноним (-), 14:17 , 30-Ноя-15, (40) // есть, написать свой планировщик, Аноним (20), 15:56 , 30-Ноя-15, (41) Ну да, попросить у планировщика ядра Линя два ядра проца и раздать своим поток, Аноним (-), 18:00 , 30-Ноя-15, (42) –1 автору - SIMD это SIMD а блоки векторизации - это блоки векторизации - не путае, Аноним (-), 18:18 , 05-Дек-15, (46) 1,2,4,40,42,46

Сообщения

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

2. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
Сообщение от Аноним (-), 29-Ноя-15, 12:13
С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread, qthread, qtconcurrent, но не openmp. Кто что думает вообще по этому стандарту? Кто работал с ним?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Опубликован стандарт параллельного программирования OpenMP 4..."	+2 +/–
	Сообщение от KLIM (?), 29-Ноя-15, 12:40
	Я пишу научное ПО с применением openmp. В научных вычислениях это станадрт наряду с MPI.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Опубликован стандарт параллельного программирования OpenMP 4..."	–1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 13:07
	OpenMP - адский костыль. Представьте, каково это, отлаживать код в котором существенная часть логики сидит в прагмах.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	18. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от ferux (ok), 29-Ноя-15, 17:22
	Кому не нравятся прагмы, есть подвижки к переходу на generalized attributes (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n276...). Да и существует много задач, для распараллеливание решения которых, достаточно прагрмы, вроде #pragma omp parallel for - никаких проблем с точки зрения читаемости кода и легкости его отладки.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от АнониМ (ok), 29-Ноя-15, 13:22
	Костыль, но попадаются приложения его использующие тот же imagemagick.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	7. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 14:21
	>С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread, qthread, qtconcurrent, но не openmp. Всё верно и добавить нечего.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	8. "Опубликован стандарт параллельного программирования OpenMP 4..."	+2 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 14:38
	Насколько я помню, изначальная идея была - быстро распараллелить старый код. Поэтому стандарт был построен на прагмах, т.е. по сути командах компилятору, которые сильно замусоривают код, но не требуют его правки. На, как это обычно бывает, реализация поперла дальше идеи. Лучше бы это всё реализовывывли в синтаксисе языка, не было бы таких проблем с отладкой. Да и поддержку видеокарт и других устройств уже давно пора вводить непосредственно в c++. Но получается тоже всё будет на прагмах.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	9. "Опубликован стандарт параллельного программирования OpenMP 4..."	+10 +/–
	Сообщение от solardiz (ok), 29-Ноя-15, 15:38
	> Кто работал с ним? Мы используем в John the Ripper вот уже 5 лет. OpenMP может работать костылем (и наше применение как раз этому соответствует, т.к. прагмы добавлялись в том числе в старый код), но может и не (не более чем альтернативы) когда пишется новый код и OpenMP хорошо подходит для задачи (обычно это сколько-нибудь длительные вычисления, а не интерактив). Проблем с отладкой особо нет (не более чем для альтернатив - ну и что, что прагмы, как будто step-into в их реализации в библиотеке на уровне исходника бы чем-то помог). default(none) помогает избежать части багов в своем коде. Проблемы с производительностью есть при частой синхронизации потоков (тысячи раз в секунду) и/или на системах с посторонней загрузкой. Это цена за упрощение кода основной программы. Можно эту цену и не платить, а держать раскидывание частей задачи по потокам более под своим контролем, при этом всё равно используя OpenMP, но тогда смысла использовать именно OpenMP меньше. Зато, если отдать всё решать runtime-библиотеке, раскидыванием по потокам можно рулить (static vs. dynamic, affinity, ...) с помощью переменных окружения (и не только) не тратя на это свой код. При этом основная логика вычислений может быть более наглядно видна в исходнике, чем при явной многопоточности. К тому же, есть OpenMP offload, аналога которого в перечисленных альтернативах нет. Мы пока что его попробовали лишь чуть-чуть, с Xeon Phi. Производительность, как и ожидали, получается хорошая лишь для offload-а сколько-нибудь длительных вычислений (хотя бы сколько-то миллисекунд) и небольшого объема передаваемых данных. Тем не менее, в ряде случаев этого может быть достаточно, а исходник получается проще, чем если всё это делать вручную.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	10. "Опубликован стандарт параллельного программирования OpenMP 4..."	–8 +/–
	Сообщение от pavlinux (ok), 29-Ноя-15, 15:46
	> С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его > применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread, > qthread, qtconcurrent, но не openmp. По моему ты ваще них..я не понимаешь в параллельных вычислениях. А сравнивать с тредами все равно, что теплое с мягким. > Кто работал с ним? Ааааа, ну понятно - не читал, но осуждаю.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	11. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 15:48
	OpenMP прагмовая высокоуровневая обертка над тредами
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Трорвальдс (?), 29-Ноя-15, 16:36
	> OpenMP прагмовая высокоуровневая обертка над тредами Да-да, "настоящие пОцаны" сразу пишут на ассемблере, а не этих ваших "высокоуровневых обёртках". Cool story bro
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 16:57
	Настоящие пацаны давно пишут на > std::thread, pthread, qthread, qtconcurrent и т.п.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от Аноним (-), 29-Ноя-15, 15:50
	> ... не читал, но осуждаю. Не вижу нигде осуждений
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	13. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 15:52
	> А сравнивать с тредами все равно, что теплое с мягким. Раскроешь нам эту изюминку OpenMP? Ведь вопрос был как раз про это, и походу ты один здесь знаешь истину.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	21. "Опубликован стандарт параллельного программирования OpenMP 4..."	+2 +/–
	Сообщение от Dark Amateur (?), 29-Ноя-15, 18:56
	Хранение последовательной и параллельной программы в едином файле исходного кода. Получение соответствующих бинарников зависит от одного ключа. Как долго придётся корячиться с макросами, чтобы в случае чего, скомпилировать последовательную программу на pthreads? Кстати, OpenMP поддерживается MS Visual C++ Compiler, где, внезапно, нет pthreads. Привет, кроссплатформенность. Какие аналоги #pragma omp simd есть в pthreads?
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Опубликован стандарт параллельного программирования OpenMP 4..."	–2 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 19:07
	> Хранение последовательной и параллельной программы в едином файле исходного кода Это такая сверх необходимая вещь и всем очень нужная, да еще и не реализуемая на std::thread? Никогда бы не подумал. У всех моих программ простым ключиком можно свести количество потоков к нужному количеству. И это вообще не требует никаких усилий.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Опубликован стандарт параллельного программирования OpenMP 4..."	+2 +/–
	Сообщение от Dark Amateur (?), 29-Ноя-15, 19:15
	> Это такая сверх необходимая вещь и всем очень нужная Если программа больше 10 строк - то вещь очень нужная, как минимум для отладки. > не реализуемая на std::thread Естественно реализуемая. Вопрос в том, какими усилиями? > У всех моих программ простым ключиком можно свести количество потоков к нужному количеству OpenMP это умеет ещё и переменными окружения.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Опубликован стандарт параллельного программирования OpenMP 4..."	–2 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 19:48
	А в чем разница между отладкой однопоточного и многопоточного приложения? Или вам это нужно только чтобы отследить разницу в выводе соответствующих версий приложения? Честно говоря, на мой взгляд, этот аргумент в пользу OpenMP очень надуманный. И статистика использования openmp говорит не в его пользу.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от 10й Брейтовский переулок (?), 30-Ноя-15, 00:01
	>>> А в чем разница между отладкой однопоточного и многопоточного приложения "Слив засчитан" (С)
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от mkarev (?), 29-Ноя-15, 19:25
	> Какие аналоги #pragma omp simd есть в pthreads? Вопрос некорректен, Вы сравниваете теплое с мягким. pthreads - библиотека OpenMP - языковое расширение, поддержка, которого _необходима_ в компиляторе Но автовекторизация есть в любом современном компиляторе. Вообще ручной код на интринсиках под заданную архитектуру уделает #pragma omp simd (и любой другой автовекторизатор, включая icc) как стоячего. На банальных циклах типа a = a + b автовекторизатор, конечно, справляется, но как только делаем шаг в сторону - просим его, например, векторизовать КИХ фильтр, так внезапно на выходе получаем скалярный код. На сегодняшний день нет серебрянной пули для автоматической генерации качественного SIMD кода.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	25. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от Dark Amateur (?), 29-Ноя-15, 19:39
	> Вопрос некорректен, Вы сравниваете теплое с мягким. Не-не-не, как раз тёплое с мягким и сравниваем, а посему вопрос уместен. Скажем спасибо Анониму. > OpenMP - языковое расширение, поддержка, которого _необходима_ в компиляторе Я-то об этом в курсе. > Вообще ручной код на интринсиках под заданную архитектуру уделает #pragma omp simd. Не факт. Например, в коде у вас SSE2-интринсики, а у пользователя компилятору строго прописано юзать AVX. Итого: в лучшем случае получите просадку в производительности (ЕМНИП из-за переупаковки данных между группами инструкций), в худшем - ошибку компиляции. С OpenMP такой проблемы не будет. Как и при переносе той же программы на ARM, например.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Опубликован стандарт параллельного программирования OpenMP 4..."	–2 +/–
	Сообщение от mkarev (?), 29-Ноя-15, 19:46
	В худшем случае - Ваша программа упадет на машине без AVX. PS: раз уж сравнивать начали с SSE2, то ее старший брат AVX2, т.к. AVX - float point only. > С OpenMP такой проблемы не будет. Как и при переносе той же программы на ARM, например Ага, проблем не будет. Равно как и скорости )) Ну и на всех Ваших армовских компиляторах конечно же есть поддержка самой последне спеки  OpenMP ? Я Вас умаляю.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Опубликован стандарт параллельного программирования OpenMP 4..."	–1 +/–
	Сообщение от Аноним (-), 29-Ноя-15, 19:54
	> float point only Начиная с Haswell это, вроде как, не так
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от mkarev (?), 29-Ноя-15, 19:57
	Да, потому что в хасвеле появился AVX2
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от Dark Amateur (?), 29-Ноя-15, 20:05
	> В худшем случае - Ваша программа упадет на машине без AVX. Нормальная программа не должна падать ни при каких обстоятельствах. Особенно, если теряется контроль на исполняемой средой. Интринсики - попытка быть умнее всех, прикручивая программу к конкретной железке. В некоторых случаях это оправдано (как и ассемблерные вставки, например), но не в случае с софтом широкого назначения: придётся либо ставить ограничения, либо обмазываться ими под каждые наборы инструкций и набор опций компилятора. Последнее вполне может быть причиной воплей: "азазаз, на интеле работает в 10 раз быстрее, чем на амуде, амдуде - сосед" и далее в том же духе, хотя виноват на пользователь, не AMD, а программист, который обязательно полениться / не успеет / не получит денег за очередную 100500-ю реализацию функции под новые интринсики. > Равно как и скорости )) Чаще всего софт тормозит не из-за отсутствия интринсиков. Попробуйте оптимизацию на алгоритмическом уровне. В любой случае, между местами быстрой и полностью рабочей программой, я выбираю рабочую. > Ну и на всех Ваших армовских компиляторах конечно же есть поддержка самой последне спеки  OpenMP ? Я Вас умаляю. Ну, GCC на ARM ещё не забанили.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	31. "Опубликован стандарт параллельного программирования OpenMP 4..."	–3 +/–
	Сообщение от mkarev (ok), 29-Ноя-15, 21:06
	>Нормальная программа не должна падать Согласен, для этого в нормальных программах "обмазываются" реализациями под каждый набор инструкций, а в рантайме по cpuid определяют самый быстрый из доступных и исбользуют его в работе. AMD действительно сосет. И сосет она не по вине программиста, а потому, что в AMD нет ничего старше SSE3 по части SIMD (убогий SSE4A не предлагать) Вот мы и получаем, что 12-крылый AMD на фоне четырех головых Core I7 в глубокои анусе при, скажем, софтовом кодировании HEVC. >Попробуйте оптимизацию на алгоритмическом уровне Ну это совершенно капитанский совет У меня к Вам встречное предложение - попробуйте скомпилировать на супер дупер авто simd компиляторе, алгоритмически оптимизированный, скажем dct 8x8 (у которого сложность NlogN, против N^2 канонiчной имплементации в лоб). А потом возьмите версию на интринсиках, хотябы на самом дремучем SSE2. Результаты Вас сильно удивят. Я с этими делами сталкиваюсь каждый день (кодек девелопмент) и сказками про автовекторизацию сыт по горло. Не спорю, для проектов, у которых нет потребности/ресурсов на прокачку DSP части, автовекторизация в любом виде будет приятным бонусом. Взять хотябы то, во что разворачивается на самом деле банальный memcpy
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Опубликован стандарт параллельного программирования OpenMP 4..."	+2 +/–
	Сообщение от Dark Amateur (?), 29-Ноя-15, 21:45
	> AMD нет ничего старше SSE3 по части SIMD CPUBoss с Вами не согласен: http://cpuboss.com/cpu/AMD-FX-8320 > скомпилировать на супер дупер авто simd компиляторе Кто сказал, что #pragma omp simd в OpenMP - это автовекторизация? Не, конечно, сами инструкции подбираются автоматически, учитывая при этом и опции компилятора, но рассовываются и тюнингуются они всё-таки программистом. > для этого в нормальных программах "обмазываются" реализациями под каждый набор инструкций > Я с этими делами сталкиваюсь каждый день (кодек девелопмент) Ну, таков Ваш путь. В общем случае, возня с конкретным процессором - это перспектива дальнейшей возни с другим процессором, что не всегда рентабельно. Векторизация через OpenMP - дешево и сердито. И если результат не удовлетворителен и есть околобесконечные ресурсы, имеет смысл лесть в интринсики, но не раньше.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от mkarev (ok), 30-Ноя-15, 09:03
	> Кто сказал, что #pragma omp simd в OpenMP - это автовекторизация? Простите, а что это тогда? Да, конечно, вы намекаете компилятору, что "тут можно распараллелить цикл в N раз" Но на этом по сути все и заканчивается > Ну, таков Ваш путь. Таков путь тех, у кого большой объем DSP вычислений, которые надо делать в реальном времени. > В общем случае, возня с конкретным процессором - это перспектива дальнейшей возни с другим процессором Угу, у нас ведь каждый день новая архитектура и набор инструкций рождаются
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Опубликован стандарт параллельного программирования OpenMP 4..."	+3 +/–
	Сообщение от redwolf (ok), 01-Дек-15, 21:14
	Я сталкивался с кодом, который использует OpenMP в подобных задачах: https://opus4.kobv.de/opus4-zib/files/4218/wende_steinke.pdf Об автовекторизации задачи здесь речи не идёт. Если кратко, то с использованием OpenMP пишутся аналоги CUDA-ядер, которые запускаются на многоядерных узлах кластера. Коммуникация между узлами осуществляется с использованием MPI.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Опубликован стандарт параллельного программирования OpenMP 4..."	–2 +/–
	Сообщение от bOOster (ok), 30-Ноя-15, 13:46
	Вот еслибы это было кроссплатформенностью уровня выполнения, а не компиляции, цены бы этому не было. А так костыль.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	44. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от redwolf (ok), 01-Дек-15, 21:20
	> Вот еслибы это было кроссплатформенностью уровня выполнения, а не компиляции, цены бы > этому не было. А так костыль. По такой логике и Qt --  костыль. И вообще решения на C++ --  костыль. А Вы, случаем, не фанат Java?)
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Опубликован стандарт параллельного программирования OpenMP 4..."	–2 +/–
	Сообщение от bOOster (ok), 02-Дек-15, 04:48
	Отличная практика путать жопу с пальцем. Главное демагогией позаниматься...
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Опубликован стандарт параллельного программирования OpenMP 4..."	+1 +/–
	Сообщение от AAAAAAaaAAAAAA (?), 30-Ноя-15, 02:04
	Я активно использую openMP в программах на Ansi C11 и очень доволен, согласен что для C++ подходит плохо. OpenMP не умеет исключения, STL контейнеров и смартпоинтеров не понимает, проблемы с контрукторами. OpenMP это для С и Fortran, в С++ лучше не стоит.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	47. "Опубликован стандарт параллельного программирования OpenMP 4..."	+/–
	Сообщение от Аноним (-), 05-Дек-15, 18:20
	из НЕ-проприетарного - он пока безальтернативен для HPC, к сожалению. не на ICC-же ваять который с MP не дружит. распределенное решение реально работающее - иначе не написать.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

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