Обсуждение

В архиве: 4 комментария.

Читать и комментировать в ЖЖ ↗

dn2010 · 14 мая 2017

Комментарий

>программировать на CUDA сложно, очень сложно. Если вы хотите "разогнать алгоритм на GPU", то за полдня работы вы это сделать не сможете. Для этого у них есть OpenACC и компиляторы от PGI, там обычный код на C, плюсах или фортране размечается прагмами и становится параллельным. Там конечно не полдня работы, но разметить за неделю полной занятости типичное практическое приложение вполне можно. Нас (http://gwyddion.net) , например, единственное что останавливает, что у нас оно опенсорсное и поддерживается на куче legacy-систем вплоть до Ubuntu 10.04 ЕМНИП. Такой разметкой мало кто из целевой аудитории пока может воспользоваться и сделать так, чтобы можно было скомпилировать PGI быстрое приложение и при этом не ломать legacy gcc это несколько сложнее, чем просто сделать и отладить под один быстрый компилятор. Ну и у меня типичная рабочая машина сейчас это ультракомпактный настольный HP в форм-факторе небольшой книжки, в который зелёную видеокарту просто некуда ставить.

dn2010 · 14 мая 2017

Комментарий

Ну и производители красненьких видеокарт ответили тем, что заопенсорсили весь свой стек гетерогенных вычислений, только OpenCL мало кем поддерживался по сравнению с CUDA и для него промежуточных библиотек типа cuDNN нет. Плюс в современных опенсорсных компиляторах есть почти всё для поддержки того же OpenACC, есть генераторы кода из промежуточного представления в код вычислительных блоков в LLVM, есть зачаточная поддержка параллельных прагм, её нужно просто доделать.

Ответ на комментарий

toshick · 14 мая 2017

Комментарий

1) это именно FLOP а не FLOPs, оценка общей вычислительной емкости задачи. 2) RISK и многоядерные процессоры проигрывают графическим только числом, с вычислительной точки зрения они ничем не хуже. Для bigdata плавающая арифметика не нужна вообще, а для ИИ используется арифметика пониженной точности, обычно float32. В современных RISK она есть, там просто мало ядер. Nvidia берет дешевизной и кудой. 3) Сложные процессорные архитектуры для научных вычислений уже совсем не нужны: сейчас можно позволить себе считать хоть все с произвольной точностью, т.е. обрабатывать длинные числа не как числа, а как символьную строку. 4) Программировать на CUDA сложно, если нужно сделать параллельным уникальный алгоритм. Матричные же операции давно реализованы, разумеется, основные пакеты переключаются между CPU и GPU прозрачно для пользователя.

Анатолий Левенчук · 14 мая 2017

Комментарий

Дык это был хороший ход! И я за открытые стандарты! Но вот "доделать" должен кто-то, на это должны быть ресурсы. NVIDIA выделением этих ресурсов озабочена, для CUDA. А для OpenCL этим никто не озабочен. Колхозное, оно и есть колхозное. Вот мы и имеем, что имеем )))

Ответ на комментарий