Что выбрать для параллельных вычислений на GPU с большой точностью?

Question

[Имя]

Мне нужно производить вычисления с комплексными числами с точностью выше чем double, т.е. с использованием сторонних библиотек.
Я так-же не хотел бы глубоко вникать в сами параллельные вычисления, а лишь сделать то, что мне требуется, поэтому хочу выбрать что-то попроще.
Выбор стоит между CUDA и OpenCL, мне известно что CUDA только для Nvidia, но это особо не пугает.
Мне нужна возможность отображать вычисленные данные на экран, для этого я вероятно использую OpenGL, но могу и Vulkan если это потребуется.
Так что мне лучше выбрать для таких требований?

Вроде как CUDA попроще и документации/примеров больше, так ли это?
И возможно ли CUDA и OpenGL связать с OpenGL для что-бы не копировать данные через CPU.

Answer 1

[mayton2019]

В терминологии С++ выше double (64bit) находится __float128.
Я-бы проверил поддерживает ли CUDA/OpenCL эти типы
на уровне API. Если вдруг не поддерживает - то придется
их реализовывать самому.

До того как их реализовывать я-бы спросил у автора - действительно
ли ему нужны числа с такой мантиссой и экспонентой как он хочет
и для каких алгоритмов. В большинстве случаев в алгоритмах
всегда есть маневр. Есть возможность где-то срезать углы и не делать
избыточных расчетов. Тем более что для нужд физики обычного double
хватает. Что такого надо считать чтобы double не хватало - я не знаю.
Поперечник обозримой вселенной в пропорции к планковской длине?

Comments

[Имя]

Фракталы считаю, там очень быстро упирается приближение в точность double.

[pfg21]

задумался посмотрел, не хватит 2^128 для сохранения размера вселенной в планковских длинах :)
понадобится чтото около 2^203. в 256 бит влезет :)

[mayton2019]

pfg21, рисуешь Множество Мандельброта?

[Имя]

mayton2019, да

[mayton2019]

Имя, мне вот тоже было всегда интересно. Взял язык высокого уровня. Типа С++ или Rust
с шаблонами. И объявил свой тип

class FloatingPoint[256, 20] { ... }

И сразу получил арифметику 256 битных вещественных с экспонентой в 20 бит к примеру.
Ну и правила Nan/Infinity - пускай останутся как и были.

Что будет - в implementations? Всякие с++ intrisics c SSE/AVX операциями. Мне уж это
будет безразлично. Главное чтоб я не тратил время на реализацию.

[Имя]

mayton2019, да так-то есть библиотеки для этого, но в GPU это всё не работает

Answer 2

[rPman]

К сожалению оценка будет сильно привязана к железу, а помятую о ситуации на рынке, переставшим быть глобальным, еще и сильно будет зависеть от стоимости используемого железа.

Если гуглить, обнаруживается достаточно старая статья dwave по которой в пределах одного nvidia устройства разница в производительности (там считали кубиты, а там как раз математика непростая, комплексные числа и т.п.) достигала от 13% до 60% в пользу cuda, что логично. Но статья 14-летней давности, с тех пор и llvm подросло, и amd на рынок взошла как следует.

Допускаю что и в современных реалиях cuda будет работать быстрее за счет каких-нибудь оптимизаций или если найдешь уже вручную оптимизированную библиотеку под твою задачу, но opencl не привяжет твое решение гвоздями к значительно подорожавшим nvidia железкам (если сравнивать железо от разных производителей с одной ценой, скорость у amd может оказаться выше)

но не на много.

Comments

[Имя]

А что насчёт простоты использования?