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

s.t.> Компьютеры считают МКЭ на CPU или GPU?

И там и там. Тебе какой-то конкретный пакет для физрасчётов нужен, или просто интересуешься?

Sandro> И там и там. Тебе какой-то конкретный пакет для физрасчётов нужен, или просто интересуешься?
просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты. И когда запускается SOLIDWORKS Simulation не видно, чтобы нарастала нагрузка на видеокарту.

Sandro>> И там и там. Тебе какой-то конкретный пакет для физрасчётов нужен, или просто интересуешься?
s.t.> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты. И когда запускается SOLIDWORKS Simulation не видно, чтобы нарастала нагрузка на видеокарту.

Для Solid нужна Quadro (рекомендовано). Иначе просто CPU (не проверено , точнее не помню ... видео поменял - вроде быстрее стало . Но субъективно) . (Хотя и помню - как в AutoCAD (ещё в 90-е) , OpenGL включаешь в Настройках .... И сразу рендеринг раз в 10 ускорялся) ...
PS 3DMax и Maya -должны GPU на 100% "терзать" по умолчанию .

Sandro>> И там и там. Тебе какой-то конкретный пакет для физрасчётов нужен, или просто интересуешься?
s.t.> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты. И когда запускается SOLIDWORKS Simulation не видно, чтобы нарастала нагрузка на видеокарту.

Это нужно смотреть спецификации на конкретный пакет.
НАпример, Abaqus точно умеет, но с ограничениями на минимальный и максимальный размер задачи и тип анализа.

s.t.> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты.
Видеокарты не умеют щитать плавточку - это большое ограничение.

s.t.>> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты.
pokos> Видеокарты не умеют щитать плавточку - это большое ограничение.

Уже очень давно умеют. Да, на двойной точности скорость сильно проседает, но одинарная — без проблем. Ну и с подачи Нвидии ещё и половинную протащили. Даже в новую редакцию стандарта от IEEE.

s.t.>> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты.
pokos> Видеокарты не умеют щитать плавточку - это большое ограничение.

Да уже сто лет в обед , как все вектора и матрицы в 3D считаются именно во float (причём аппаратно) . Всякие int и bool и тд - это уже "издержки" , костыли .

O.N.> Да уже сто лет в обед , как все вектора и матрицы в 3D считаются именно во float (причём аппаратно) . Всякие int и bool и тд - это уже "издержки" , костыли .

Сто лет в обед уже нужна дабл флот, а местами и квад.
Вторая бяка, что алгоритм не обеспечивает параллелизм до того количества параллельный устройств, что есть в ГПУ.

Sandro> ...Ну и с подачи Нвидии ещё и половинную протащили.
Дык, это ж для т.н. ИИ. Для, хотя бы, 1000 итераций это не годится вообще.

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

Как верно заметили, скорость на большинстве популярных GPU падает при переходе к 64 битам, а 32 бит для численых методов дифуров как правило недостаточно категорически (а 64 бит - просто недостаточно ). Хотя, конечно, сейчас пойдёт про "смотря где, что и когда"... Но в целом ошибки в сложных итерационных расчётах быстро накапливаются, поэтому, КМК, конкретно МКЭ на 32 битах смысла не очень имеет (ну или сетка такая грубая; но тогда можно и без GPU обойтись).

В целом, НЯП, сейчас большинство популярных расчётных и симуляционных пакетов умеют или в CUDA, или в (реже) OpenCL или (редко) и то, и то.

s.t.>>> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты.
pokos>> Видеокарты не умеют щитать плавточку - это большое ограничение.
Стыдно такое писать в 2025. ВИДЕОкарты - нет. Но нынешние "видеокарты" - уже давно не только видео. А может, даже уже и не столько.
Посмотри хотя бы CUDA, там как бы не бОльшая часть про плавующую запятую.

Sandro> Уже очень давно умеют. Да, на двойной точности скорость сильно проседает, но одинарная — без проблем. Ну и с подачи Нвидии ещё и половинную протащили. Даже в новую редакцию стандарта от IEEE.
Для нейросеток иногда достаточно и двух бит не-флоата. Смотря как делать.

Татарин> Посмотри хотя бы CUDA, там как бы не бОльшая часть про плавующую запятую.
Татарин> ...а 32 бит для численых методов дифуров как правило недостаточно категорически (а 64 бит - просто недостаточно ).
Дык, ты определись, для начала, достаточно или нет.

Я утверждаю, что "видеокарты" не умеют 80 бит, которых для многих расчётов таки достаточно.

.

Татарин>> Посмотри хотя бы CUDA, там как бы не бОльшая часть про плавующую запятую.
Татарин>> ...а 32 бит для численых методов дифуров как правило недостаточно категорически (а 64 бит - просто недостаточно ).
pokos> Дык, ты определись, для начала, достаточно или нет.
Я отвечал на это:
pokos> Видеокарты не умеют щитать плавточку - это большое ограничение.
Плавточка - она очень разной размерности бывает.

pokos> Я утверждаю, что "видеокарты" не умеют 80 бит, которых для многих расчётов таки достаточно.
Я уже давно не видел 80-битной точности в реальных программах. Лет так 15 уже точно.

См. сами определения float и double в большинстве компиляторов С/С++ (ну и Ява/c# до кучи).
С 2000-мохнатого года в компиляторах IEEE_754
float - 32, double - 64 бита.

Татарин> Я уже давно не видел 80-битной точности в реальных программах. Лет так 15 уже точно.
Щитайте меня ретроградом.

Татарин>> Я уже давно не видел 80-битной точности в реальных программах. Лет так 15 уже точно.
pokos> Щитайте меня ретроградом.
Простой вопрос: каким компилятором ты пользуешься и что пишешь?

Если вижуальник, то см. /fp (Specify floating-point behavior) | Microsoft Learn
Или просто глянь в ieee754.h, если gcc.

Чтобы хотя бы ты сам себя считал себя ретроградом с основаниями на то, ты должен бы компилять под х86 (не х64) всегда с определёнными опциями (не с дефолтом для большинства компиляторов).
Обычно этим никто не заморачивается. Готов поверить на слово, что ты исключение, но, если только ты не заморачивался на этом специально, то у тебя были всё те же модные-молодёжные опции компиляции, как у всех (по дефолту для х86 vc, НЯП, компилирует код так, что расчёт идёт в 80-битах, и результат кастится в 64 по итогу выражения; по меньшей мере, лет 15 назад было так).

Это, конечно, если выключены SSEx оптимизации. Если включены, то там работают ектеншены с (до)256-бит размером, и хоть точность промежуточных там может быть высокая, но в итоге всё равно дабл = 64 бита. 80 бит вариант там тоже не предусмотрен. Long double в некоторых компиляторах раньше был 80 бит, сейчас - 128.
А чтобы прикрутить квадрупл (типа, поддерживаемый аппаратно), НЯП, до сих пор нужны те ещё танцы с бубном.

Татарин> Простой вопрос: каким компилятором ты пользуешься и что пишешь?
Только ГНУ Ц, только хардкор!

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

pokos> Более-менее результат, обычно, можно получить, проделав пару миллионов итераций.
pokos> Обрати внимание на потребную точность, установленную по умолчанию. Отмечу, что, периодически, и её не хватает и в решении появляются артефакты, легко видимые невооружённым глазом, либо, вовсе, программа встаёт с сообщением "сингуляр матрикс".
Ну так понятное дело.
Сам от этого далёк уже долгое время, но когда пересекался с людьми, считавшими численными методами итеративно большие системы, те использовали алгоритмы, которые были далеки от излагаемых в учебниках.
Там тебе что 64 бита, что 80 - почти один фиг; ещё десяток итераций, и нету той разницы.

Точность мантиссы умирает практически в первом же умножении/делении. А чтобы не умирала, ты должен честно удвоить точность мантиссы результата по сравнению с аргументами. Ну и какая при таких делах разница - 64 или 80 бит? Почти никакой.

Татарин> ...Ну и какая при таких делах разница - 64 или 80 бит? Почти никакой.
Разница достаточная для большинства таких применений. 4 десятичные цифры на дороге не валяются.

К щастию, в указанном примере решения устойчивы, поэтому артефакты появляются и исчезают.
Однако, бывают и уравнения с поведением гораздо хуже, например, про динамику сплошных сред.

Татарин>> ...Ну и какая при таких делах разница - 64 или 80 бит? Почти никакой.
pokos> Разница достаточная для большинства таких применений. 4 десятичные цифры на дороге не валяются.
pokos> К щастию, в указанном примере решения устойчивы, поэтому артефакты появляются и исчезают.
Ну, тогда тебе, скорее, повезло: ты попал прям в узкую нишу, где сразу и точность важна, и разница в 16 бит играет, и нелинейность слабая, и бОльшей точности не нужно.

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

Sandro>> И там и там. Тебе какой-то конкретный пакет для физрасчётов нужен, или просто интересуешься?
s.t.> просто интерес возник. Ведь машины с CAD часто имеют мощные видеокарты. И когда запускается SOLIDWORKS Simulation не видно, чтобы нарастала нагрузка на видеокарту.

Но они не всё ускоряют на GPU.

Татарин> Я уже давно не видел 80-битной точности в реальных программах. Лет так 15 уже точно.
Татарин> См. сами определения float и double в большинстве компиляторов С/С++ (ну и Ява/c# до кучи).
Татарин> С 2000-мохнатого года в компиляторах IEEE_754
Татарин> float - 32, double - 64 бита.

В Паскале есть тип extended 80 бит. В АДА long_long_double. В MS VC++ long_double.

С другой стороны С/C++ и не предназначен для ведения серьезных расчетов.

Вот в фортране нет 80 бит. Там сразу 128.

Татарин> Ну, тогда тебе, скорее, повезло: ты попал прям в узкую нишу, где сразу и точность важна, и разница в 16 бит играет, и нелинейность слабая, и бОльшей точности не нужно.
И не говори! Иногда даже удаётся увеличить Гмин, Чтол и Абстол на два порядка, чтобы считало быстрее.
Татарин> Сейчас куча процов с AVX, там, где нужна точность...
Вот, я и говорю, что у "видеокарт" с этим делом всё плохо.

Татарин>> float - 32, double - 64 бита.
Jerard> В Паскале есть тип extended 80 бит. В АДА long_long_double. В MS VC++ long_double.

Microsoft-specific: The representation of long double and double is identical. However, long double and double are treated as distinct types by the compiler. The Microsoft C++ compiler uses the 4- and 8-byte IEEE-754 floating-point representations. For more information, see IEEE floating-point representation.

 

Да, ты можешь заставить вижуальник работать с 80-бит long double, но это требует внимания: нужно смотреть на конкретный компилятор и его опции. Для очень старых х86-компиляторов long double реально был 80-битным, но надо именно что внимательно смотреть на версию и опции компиляции (ссылку см. выше).
А, ещё 80 бит сохраняет (в смысле в памяти) оптимизирующий компилятор от Интел.

Во всех остальных случаях ты будешь иметь либо со внутренних 80-бит вычислений даункаст до 64 (gcc или VC++ с дефолтами для double), либо апкаст до 128 бит (те же, там же, для long double). Причём, выигрыш по точности для long double будет меньше, чем ты мог бы ожидать.

То же самое касается современных компиляторов Паскаля.

Jerard> С другой стороны С/C++ и не предназначен для ведения серьезных расчетов.
Пожимаю плечами.

Jerard> Вот в фортране нет 80 бит. Там сразу 128.
Проблема в том, что большинство фортранов, НЯЗ, на х86/х64 используют те же f-инструкции сопроцессора с 80-битной точностью. Может быть, сейчас у каких-то появилась поддержка SSE/AVX, но относительно недавно (10 лет назад) это было проблемой.

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