/CFD+3d/ полное моделирование испытательного полета

tvv> Подписывайтесь короче, там и обсудим моделирование.
полгода назад вы обещали чего-то сделать, - что-то не вижу результата

101> А GPGPU в CFD не жилец.

Но почему??? У вас же по логике вещей основная нагрузка — это численное интегрирование, а GPU в этих задачах как раз очень хорош.

AXT> Но почему??? У вас же по логике вещей основная нагрузка — это численное интегрирование, а GPU в этих задачах как раз очень хорош.

Основные причины неудачи GPU в вычислительной гидродинамике (CFD):
1. Много ядер, мало памяти на каждое из них. А CFD задачи славятся большими объемами.
2. GPU сидит на тормозном канале PCIe и на пересылках из ОЗУ в GPU и обратно теряется все возможное ускорение в вычислителе.
3. В GPU организация вычислений гетерогенная, т.е. за один такт все ядра выполняют одну и ту же операцию. Т.е. часть делает то, что нам нужно, а остальное простаивает. Как сейчас не в курсе.
4. Язык CUDA - нужно переписывать имеющийся х86 код под GPU. Под AMD, соответственно, свои задрочки. В качестве альтернативы писать на OpenCL юнисекс код, но там не реализованы тонкие вещи, что есть в той же CUDA. Т.е. или ложиться под одного производителя или под нескольких - гемор с поддержанием всего этого табора крайне большой, что затягивает строки разработки, тестирования и отладки.
5. Самое говеное - стабильность работы вашего приложения зависит от текущего состояния драйверов и версии драйверов. Кто когда-либо писал что-либо под минидрайвер OpenGL в курсе. Мы в свое время нашли баг, которого не было в предыдущих версиях. В итоге разработчики драйверов сказали, что для данной видеокарты им уже что-то править в лом, исправления будут внесены в драйвера для более новой видеокарты. Плюс еще огромный зоопарк видеокарт есть.
В сухом остатке - метод конечных элементов ускорение на GPU в два раза. То же самое можно получить купив проц с большим количеством ядер или купив двухпроцессорную рабочую станцию.
Эффект тот же, гемора разработчикам в два раза меньше.

В итоге сидим и изучаем Xeon Phi и ждем его развития - x86 код, переписывать ничего не нужно, памяти обещают в достатке на каждое ядрышко. Пока не все гладко даже на уровне компиляторов, но это трудности роста.

Bredonosec> полгода назад вы обещали чего-то сделать, - что-то не вижу результата

Очередной гений от сохи.

tvv> PS в NASA вон уже последнюю аэродинамическую трубу разобрали давно.

Да у них только в Кливленде шесть действующтх труб. Включая три сверхзвуковых и одну для изучения обледенения.

101> Основные причины неудачи GPU в вычислительной гидродинамике (CFD):
101> 1. Много ядер, мало памяти на каждое из них. А CFD задачи славятся большими объемами.

Ну и что? GPU заточены под потоковую обработку, правильный стиль программирования под них — держим в локальной памяти только обрабатываемый срез потока данных, а ещё лучше — вообще только в регистрах, а локальную используем только для синхронизации, если нужно.

101> 2. GPU сидит на тормозном канале PCIe

Четыре гигабайта в секунду — это мало?

101> и на пересылках из ОЗУ в GPU и обратно теряется все возможное ускорение в вычислителе.

А нафига пересылать? Загрузили начальные значения, и считаем. На выходе — суммарные силы, это немного в объёме.

101> 3. В GPU организация вычислений гетерогенная, т.е. за один такт все ядра выполняют одну и ту же операцию. Т.е. часть делает то, что нам нужно, а остальное простаивает. Как сейчас не в курсе.

Не все, а только те, что в одном блоке. Но да, branch divergence — это проблема.

101> 4. Язык CUDA - нужно переписывать имеющийся х86 код под GPU.

А что, под AVX его не придётся переписывать? Типа, компилятор сам справится?
Нифига он не справится, всё равно придётся ручками писать, если хочется максимальной производительности.

101> Под AMD, соответственно, свои задрочки. В качестве альтернативы писать на OpenCL юнисекс код, но там не реализованы тонкие вещи, что есть в той же CUDA.

Хм, под CUDA я не писал особо, так как не люблю проприетарные решения и vendor lock-in вообще, но вроде как OpenCL как раз имеет более тонкий контроль над GPU. Или в CUDA уже запилили полностью асинхронную обработку задач? Давно не смотрел, что там.

101> 5. Самое говеное - стабильность работы вашего приложения зависит от текущего состояния драйверов и версии драйверов. Кто когда-либо писал что-либо под минидрайвер OpenGL в курсе. Мы в свое время нашли баг, которого не было в предыдущих версиях.

О, это да. Я один раз разбирался с совершенно замечательным багом с частичной записью в MRT, который оказался фичей. Суть в том, что в стандарте это запрещено, но с какого-то момента железо у AMD стало уметь это делать. А раньше драйвера и у красных и зелёных исправляли втихую кривой код, добивая нулями, а потом AMD выпустила драйвера без этой затычки ...
С учётом того, что код достался мне от предшественника, а записи в MRT были разбросаны по всему коду, было "весело".

101> В сухом остатке - метод конечных элементов ускорение на GPU в два раза.

Мало. Очень мало. Вы что-то делаете не так.

101> В итоге сидим и изучаем Xeon Phi и ждем его развития - x86 код, переписывать ничего не нужно,

"Переписывать не нужно"? Вы на голом C пишете? Хмм...

AXT> Ну и что? GPU заточены под потоковую обработку, правильный стиль программирования под них — держим в локальной памяти только обрабатываемый срез потока данных, а ещё лучше — вообще только в регистрах, а локальную используем только для синхронизации, если нужно.

У меня нет пока что основания сомневаться в правильности стиля программирования большинства софтверных компаний нашего толка.

AXT> Четыре гигабайта в секунду — это мало?

Зависит от размерности задачи. Чем больше задача в размерах, тем больше обменов в трафике.
Вот помедитируйте над циферками интерконнекта

AXT> А нафига пересылать? Загрузили начальные значения, и считаем. На выходе — суммарные силы, это немного в объёме.

Задача не влезает целиком в память GPU.


AXT> А что, под AVX его не придётся переписывать? Типа, компилятор сам справится?
AXT> Нифига он не справится, всё равно придётся ручками писать, если хочется максимальной производительности.

Придется, но это работа делается один раз. Как и переход на 64-битную адресацию. Один раз сделал и спишь спокойно. И при этом оно годится и под ЦП и под вычислитель. И это будет работать и под Intel и под AMD.
И не надо параллельно еще солидный кусок кода держать и трястись над ним при выходе очередной версии Куды или графической карты.

AXT> Хм, под CUDA я не писал особо, так как не люблю проприетарные решения и vendor lock-in вообще, но вроде как OpenCL как раз имеет более тонкий контроль над GPU. Или в CUDA уже запилили полностью асинхронную обработку задач? Давно не смотрел, что там.

Бенчмарки просто глянь CUDA vs OpenCL. Второй тормознее.


AXT> Мало. Очень мало. Вы что-то делаете не так.

Т.к. результат получается такой же не только у нас, но и других, то на текущем уровне развития вселенной, очень даже может быть, что и не так.


AXT> "Переписывать не нужно"? Вы на голом C пишете? Хмм...

Ну, нужно конечно же - переводить на векторные операции всю алгоритмистику по возможности.

Но это нужно делать и без Фи, а просто за ради AVX.
Пишем на С++.