GPU и метод конечных элементов

Татарин>> Сейчас куча процов с AVX, там, где нужна точность...
pokos> Вот, я и говорю, что у "видеокарт" с этим делом всё плохо.
Количество само по себе даёт новое качество.

GPU сейчас - десятки-первые сотни триллионов 32-битных операций в секунду.
CPU - в лучшем случае миллиарды FLOPS.
Да, размен сильно отличается от 1-в-1, но не в сотню тысяч раз же!

Сколько волка не корми, всё равно у слона толще.
Даже если у тебя CUDA-код симуляции плавающей точки г**но, всё равно ты можешь получить выигрыш одновременно и по точности, и по скорости. Ну или ты должен писать прям вот полное, истинное, совершенное г**но, чтобы видеокарточка на массивных расчётах была хуже.

Татарин> Сколько волка не корми, всё равно у слона толще.

У меня есть стойкое подозрение, что банально программисты не могут в большинстве своём писать под GPU. Даже в игровой индустрии мало кто может это делать правильно. См. историю с рендером в Doom 2016. Там совершенно отмороженная архитектура рендера с заточкой на максимум скорости. Тьяго вот сделал замечатетельную презентацию на GDC с объяснениями, зачем, почему и как всё там сделано. Слайды у него офигенские, кстати, из них всё понятно.
И что? Почти 10 лет прошло, кто-то смог повторить этот вычислительно сложный и одновременно быстрый движок?

Татарин> Количество само по себе даёт новое качество.
В сеточных методах не даёт. Чтобы хоть что-то дало, приходится мельчить сетку. А для 3Д - это примерно кубическая зависимость для потребного колва вычислений от колва точек.
Сэкономил 4 бита - будь ласка сделать в 4096 раз больше операций.

Татарин> CPU - в лучшем случае миллиарды FLOPS.
Интель пишет, что несколько побольше:
Intel® Core™ i9-12900KF Processor (30M Cache, up to 5.20 GHz) i9-12900KF - 819.2 GFLOPs.

Татарин> ...ты можешь получить выигрыш одновременно и по точности, и по скорости.
Не можешь.

Татарин>> Количество само по себе даёт новое качество.
pokos> В сеточных методах не даёт. Чтобы хоть что-то дало, приходится мельчить сетку.
Да нет, я имел в виду эмуляцию "большой" плавающей точки "мелкими" или целочисленными величинами.
fmul, конечно, "тяжёлый", но на 10000-10000 целочисленных операций, всё же, не тянет.

pokos> Интель пишет, что несколько побольше:
pokos> Intel® Core™ i9-12900KF Processor (30M Cache, up to 5.20 GHz) i9-12900KF - 819.2 GFLOPs.
Хм. 10 FLOP/такт?
Не знаю, как это считано, но это явно не f-команды, а что-то типа vpmull* для 16 или 32 бит точности. Причём, ессно, регистровых.

Ну сам смотри: память - 4800МТ/с (DDR5), то есть, 64-битных чисел можно в принципе прокачать только 4.8Г (это в пределе, на больших последовательных только-чтениях). Уже даже только память не справится.

Та же НВидиа А30 - 933Гб/с.

Татарин>> ...ты можешь получить выигрыш одновременно и по точности, и по скорости.
pokos> Не можешь.
Хм. Почему?

Татарин>> Сколько волка не корми, всё равно у слона толще.
Sandro> У меня есть стойкое подозрение, что банально программисты не могут в большинстве своём писать под GPU. Даже в игровой индустрии мало кто может это делать правильно.
Знаешь, это относится к сложному коду вообще. Ну да, не могут. И да, под GPU писать чуть сложнее (плюс писанина имеет свою специфику, в которую мало кто по-настоящему вникает, из-за нежелания или сроков).
Это решается как обычно - библиотеками. Кто-то умный придумал и написал быстрый решатель системы линейных уравнений для OpenCL - все пользуются. Да, не так эффективно, как могло бы. Но всё же.

Посмотри на то, как сложно и долго внедряются (даже не сказать "внедрялись") банальные векторные расширения. И я уверен, что и сейчас - просто дофигища мест, куда можно ещё впендюрить SSE*/AVX*-команды с большой выгодой.

Но 20% усилий (изменения некоторых библиотек) дают 80% результата (прибавки к скорости). Так и живём, так и далее будем.

Sandro> См. историю с рендером в Doom 2016. Там совершенно отмороженная архитектура рендера с заточкой на максимум скорости.
Там всю жизнь собиралась команда отмороженых, с самого Дума начиная (он, вообще-то на 486 33МГц без плавающей точки шёл уже нормально). Они, собссно, практически создали 3д-индустрию.
Ставить их в пример можно и нужно, но ожидать, что все могут что-то подобное выдавать на конвеере - нечестно. Если бы это было возможно, мы бы вообще жили в другом мире.

Это должно решаться и решается иначе.

s.t.> Компьютеры считают МКЭ на CPU или GPU?
s.t.> Вроде как умение GPU оперировать большими матрицами говорит в пользу того, что выгодно именно на графическом считать.

Ansys Mechanical решатель может
не уверен насчет сеточного генератора

от поддержки:
GPU Acceleration in Mechanical generally requires good FP64 performance to support all solvers. If using iterative based solvers, FP32 performance may be adequate
1.4. Requirements for the GPU Accelerator in Mechanical APDL
Not all models support GPU acceleration, please see:
3.2. Supported GPU Hardware, Analysis Types, and Features
To activate a GPU not on the recommended list, add the environment variable ANSGPU_OVERRIDE=1
Be aware this is not recommended (as it's not on the recommended list)
Briefly showed some instance types available in our Ansys Gateway Powered by AWS platform
G3 instance aligns with the M60 used by you
Other instance types have newer/better GPUs available

Татарин> Да нет, я имел в виду эмуляцию "большой" плавающей точки "мелкими" или целочисленными величинами.
А! Ну, можно, конечно, если осторожно.
Я ещё лет 30 назад двигал тезис, что 1024 бита фиксы хватит на все расчёты в этой Вселенной, но тогда это было слишком ново для людей. Тогда и однотактный умножитель 32х32 был чудом технологий.

Татарин> Хм. 10 FLOP/такт?
Думаю, это пиковое с учётом колва ядер и потоков.
А скорость памяти тут слабо влияет - до неё ещё кэшей три уровня.

Татарин> Хм. Почему?
Потому что, в таких расчётах самое интересное происходит именно на краях или в областях неустойчивости решений, там, где рвутся производные. Соответственно, просто так пожертвовать точностью ты не можешь - получится туфта в результате. По факту, требуемая точность задана густотой твоей сетки и степенью сглаживания краёв (краёв - во всех смыслах).
Грубо говоря, никого не интересует, что там происходит в метре от кумулятивной струи, а интересны её границы.

Случай, который я приводил, простой - он, фактически, двумерный и полностью устойчивый. Но, и в нём, как видим, требования к точности немалые. Заместить их массовкой менее точных вычислителей получается с трудом - надо лепить кадавра.

parex12> Ansys Mechanical решатель может
parex12> не уверен насчет сеточного генератора
Дык, это оно и есть. Как-то работают ребята.

Правда, я нашёл у них всего два приложения, где могут быть неустойчивости:
- Динамика судов и морских сооружений;
- Нестационарные динамические расчёты прочности конструкции во временной области.

И то, непонятно, насколько подробно они их обрабатывают.

Татарин> С/С++ точно не самый удобный язык для расчётов, но вот поддержать любой новых тип данных или эффективные вычисления на нём реально просто, поддержка (на уровне общедоступных библиотек) появляется почти мгновенно.

Чета до сих пор нету. Окромя MS и Intel.

Татарин>> С/С++ точно не самый удобный язык для расчётов, но вот поддержать любой новых тип данных или эффективные вычисления на нём реально просто, поддержка (на уровне общедоступных библиотек) появляется почти мгновенно.
Jerard> Чета до сих пор нету. Окромя MS и Intel.
Нету чего?

Татарин> Нету чего?

Типов данных. Ты, же сам писал.

Татарин>> Нету чего?
Jerard> Типов данных. Ты, же сам писал.
С++ нативная поддержка компилятора для новых типов непринципиальна.
В С++ можно написать класс с перегрузкой операторов, и он в коде ничем не будет отличаться от нативных типов. При этом язык довольно близок к железу и не мешает использовать любые фишки железа (у чего, ессно, есть обратная сторона).

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

pokos> - Нестационарные динамические расчёты прочности конструкции во временной области.
pokos> И то, непонятно, насколько подробно они их обрабатывают.

В моей задаче с большими деформациями адаптивный алгоритм не справлялся, возникали неустойчивости, как я понял. Приходилось самому разбивать на несколько подзадач и перетаскивать напряжения с предыдущего шага в следующий как нач.условия. Моделировал wire bonding для получения нужной мне формы проволочки.

parex12> В моей задаче с большими деформациями адаптивный алгоритм не справлялся, возникали неустойчивости, как я понял.
Ну, при пластических деформациях без разрушения с большими сдвигами они могут появляться, то тут ничего такого сильного не вижу. Скорее, именно потеря точности на краях, о чём нам говорит успешный метод преодоления.
parex12> Приходилось самому разбивать на несколько подзадач и перетаскивать напряжения с предыдущего шага в следующий как нач.условия. Моделировал wire bonding для получения нужной мне формы проволочки.
По сути, это такой своеобразный метод сглаживания краёв (во всех смыслах), т.е. ограничение вторых производных методом их обнуления.

Проверяется размельчением сетки раз в пять-семь. Если помогает - надо увеличивать точность.

pokos> то тут ничего такого сильного не вижу.
pokos> Проверяется размельчением сетки раз в пять-семь.

Измельчением сетки в Ansys это, к сожалению, не лечится.
Куда уж больше деформировать

parex12> Куда уж больше деформировать
А пятак УЗ-сварки на конце этой проволочки? Вот, где веселуха-то.

parex12>> Куда уж больше деформировать
pokos> А пятак УЗ-сварки на конце этой проволочки? Вот, где веселуха-то.


"Process Simulation of Gold Wire Ball Thermosonic Bonding for Hybrid Integrated Circuits"
China Aerospace Science and Technology Corporation, The No. 771 Institute Xi’an, China

да это высший пилотаж, но мне, хвала аллаху, это не нужно было. Нужны были координаты клюва бондера

del

медиттация наше все

parex12> да это высший пилотаж...
Ну...Таки да!
Там весь процесс, собственно, сварки основан на неустойчивостях.