Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Спасибо, избавился от некоторых ложных представлений об OpenCL и CUDA.
>открытый Havoc
Если не ошибаюсь, sorce-лицензия от 50к$ и бесплатным для инди разработчиков не так давно стал, намного позже PhysX. И причем тут AMD его Intel купил.
Если не ошибаюсь, sorce-лицензия от 50к$ и бесплатным для инди разработчиков не так давно стал, намного позже PhysX. И причем тут AMD его Intel купил.
Если уточнить, у AMD с Havok всё как-то затихло, и сейчас они начинают продвигать Bullet Physics, третий по популярности физический движок
Моя софтина под OpenCL всего процентов на 5 медленнее оной же под CUDA.
Так что все не так плохо :-)
Так что все не так плохо :-)
Хорошая статья. Буду давать знакомым — а то часто бывают совершенно ошибочные представления об OpenCL (например — это только для игр).
Поправьте опечатки, плз.
> Пре_д_посылки появления OpenCL
> в силу своей архитектуры имеет набор жестких....?
> Пре_д_посылки появления OpenCL
> в силу своей архитектуры имеет набор жестких....?
Отличная обзорная статья!
Спасибо, отличная статья, все просто и понятно. Надеюсь на продолжение.
У меня к этому времени сложилось мнение что CUDA и OpenCL конкурирующие технологии нвидиа и ати соответственно, а оказывается OpenCL логичное продолжение идеи CUDA и схожесть синтаксиса тоже радует. Спасибо за информацию.
То что CUDA позволит писать переносимый код — хорошо, а может кто-то на пальцах объяснить, как происходит инициализация её? Т.е. надо ли мне знать, какие девайсы воткнуты в локальный комп и инициализировать их (например, выставлять количество SPU, выбор между AMD GPU или NVidia GPU)? Или всем этим занимается библиотека?
В скором времени я напишу подробную статью о том как строится OpenCL приложение.
В кратце так: из кода программы Вы можете получить число устройств с поддержкой OpenCL и их характеристики, потом выбрать и проинициализировать нужное устройство (или несколько устройств) и далее работать с ним.
В кратце так: из кода программы Вы можете получить число устройств с поддержкой OpenCL и их характеристики, потом выбрать и проинициализировать нужное устройство (или несколько устройств) и далее работать с ним.
Т.е. можно запустить одну и ту же задачу одновременно на нескольких девайсах? В смысле, нужное количество раз проинициализировать их и запустить на них задачи, склеивая потом результаты?
По крайней мере в CUDA — можно. Нужно только под каждый девайс завести свой CPU-поток.
Дело в том, что у меня нет в наличии нет двух устройств с поддержкой OpenCL чтобы протестировать это в текущей реализации NVidia
Но в общем да, использование нескольких ускорителей предполагается.
Но в общем да, использование нескольких ускорителей предполагается.
> Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU. Да, именно так, это ничему не противоречит – OpenCL стандарт для гетерогенных систем и ничего не мешает Вам запустить kernel на CPU, более того – это очень удобно в случае если в системе нет другого OpenCL устройства.
Это реальная возможность нормально использовать многоядерные процессоры.
Это реальная возможность нормально использовать многоядерные процессоры.
Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU.
Вчера ATI выпустила версию 2.0-beta4 поддерживающую ускорение вычислений на GPU.
First beta release of ATI Stream SDK with OpenCL™ GPU support.
В летней школе мфти 2009 по высокопроизводительным вычислениям была секция по cuda.
Преподаватель упомянул про opencl, что она есть и все. Когда же у него спросили про opencl он ответит примерно следующее- для пользовательских приложений это хороший выход, который сможет сэкономить время разработки программ. но для Серьезных вычислений научных, всегда будет нужна сверхвысокая производительность. по этому так как opencl должна поднять на более высокий уровень абстракции чем специфичные технологии заточенные под архитектуру, то opencl не станет равномощной узко заточенным системам таким как cuda.
Хотя для не супер компьютеров это вполне подойдет
Преподаватель упомянул про opencl, что она есть и все. Когда же у него спросили про opencl он ответит примерно следующее- для пользовательских приложений это хороший выход, который сможет сэкономить время разработки программ. но для Серьезных вычислений научных, всегда будет нужна сверхвысокая производительность. по этому так как opencl должна поднять на более высокий уровень абстракции чем специфичные технологии заточенные под архитектуру, то opencl не станет равномощной узко заточенным системам таким как cuda.
Хотя для не супер компьютеров это вполне подойдет
Ну уровень абстракции в OpenCL в общем-то не отличается от CUDA практически.
Ведь OpenCL, как было упомянуто в статье, работает поверх CUDA Driver API (в случае NVidia) как и CUDA. А он, в свою очередь, работает с ускорителем, поэтому производительность OpenCL приложений может сравняться с CUDA.
Ведь OpenCL, как было упомянуто в статье, работает поверх CUDA Driver API (в случае NVidia) как и CUDA. А он, в свою очередь, работает с ускорителем, поэтому производительность OpenCL приложений может сравняться с CUDA.
имеется в виду что OpenCL всегда будет «наименьшим общим знаменателем» по функционалу с целью обеспечить легкость реализации на разных платформах. есть также механизм vendor-specific extensions, так что если понадобится поддерживать отдельно бранч под NVIDIA, то возвращаемся к тому, от чего бежали. Уунификация и максимальная производительность никогда не будут жить под одной крышей
C этим согласен, специфичные вещи легче внедрять в CUDA и тем самым обеспечивать интерес к платформе.
Хотя вот есть же в Microsoft Visual C++ не описанные стандартом вещи, ну, скажем, __TRY / __CATCH / __FINALLY (кажется не напутал с количество подчеркиваний).
В принципе тут ситуация могла бы развиваться по такому же пути… Не возьмусь судить, что лучше и, тем более, как оно будет в действительности, но возможность ведь есть?
Хотя вот есть же в Microsoft Visual C++ не описанные стандартом вещи, ну, скажем, __TRY / __CATCH / __FINALLY (кажется не напутал с количество подчеркиваний).
В принципе тут ситуация могла бы развиваться по такому же пути… Не возьмусь судить, что лучше и, тем более, как оно будет в действительности, но возможность ведь есть?
cuda- частный пример. можно ли написать что бы на всех архитектурах работал opencl так же быстро как и на заточенной под архитектуру технология!?
если честно мне кажется, что путь будет такой же как у языков высокого уровня в сравнении с ассемблером. скорость написания выше, но использовать на всю мощь архитектурные особенности тяжело.
если честно мне кажется, что путь будет такой же как у языков высокого уровня в сравнении с ассемблером. скорость написания выше, но использовать на всю мощь архитектурные особенности тяжело.
Дело в том, что как язык — CUDA — это расширени С. Так же как OpenCL, в этом они схожи очень сильно, ведь Вы не пишите CUDA-приложения на ассемблерном коде GPU, за Вас это делает nvcc — специальный компилятор, а Вы решаете сколько хотите использовать ресурсов, как доступаться к памяти, в какой памяти размещать данные. Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня.
Как выглядит cuda я знаю. Чуть чуть даже писал. Но то что язык СИ подобный еще ничего не говорит! Есть особенность архитектуры. К примеру есть разница в уровнях памяти систем на которых считаем. Есть разница в скорости доступа к этой памяти. На школе мфти летом нам показывали как сильно может меняться скорость работы программы от размещения данных в памяти.работали мы как раз с cuda.Когда у нас все было в общей памяти видеокарты(dram) это было одно время выполнения, когда было размещено в shared памяти это на порядок быстрее было. Есть еще много примеров архитектурных особенностей.
И тот факт, что это все СИ подобно на архитектуру ну не как не влияет. А сможет ли opencl оптимизировать программу лучше программиста причем для всех возможных платформ...? Я конечно верю в, то что закодить можно все, но не до такой же степени.
И тот факт, что это все СИ подобно на архитектуру ну не как не влияет. А сможет ли opencl оптимизировать программу лучше программиста причем для всех возможных платформ...? Я конечно верю в, то что закодить можно все, но не до такой же степени.
Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня
Вот тут я написал, что в этом плане CUDA и OpenCL одинаковы.
В вашем понимании засело то, что те действия, которые CUDA выполнялись руками в OpenCL за Вас будет делать кто-то (а именно, компилятор) — это не так. Точно так же будете решать что в какой памяти располагать итд., полностью сами будете решать.
OpenCL не предоставляет какой-то более высокий уровень абстракции, на котором все (или многое) будет делаться за программиста, нет, не будет. OpenCL ничего не оптимизирует (точнее компилятор оптимизирует кое-что, но не более чем nvcc в CUDA)
Я сейчас пишу статью, в которой постараюсь все подробно объяснить, точнее похоже выйдет даже две — одна вгубь спецификаций OpenCL, другая больше практическая — что и как писать.
если Вы напишете эти 2 статьи я лично буду очень благодарен вам. так как про opencl действительно хочется знать побольше, а сейчас знание и понимание не полное.
Что кто то оптимизировать будет кроме меня я и не надеюсь. Я хотел сказать что оптимизировать программу под каждую платформу придется отдельно. А это значит разную производительность.
Что кто то оптимизировать будет кроме меня я и не надеюсь. Я хотел сказать что оптимизировать программу под каждую платформу придется отдельно. А это значит разную производительность.
Постараюсь как можно быстрее закончить работу над статьями, я и не думал что этот вопрос вызовет такой интерес.
Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя.
То есть чтобы использовать особенности архитектуры ускорителей AMD разработчик не должен учиться пользоваться Brook+, а должен изучить особенности архитектуры этих ускорителей (без этого-то совсем никуда) и написать OpenCL приложение так, чтобы оно использовало все доступные возможности.
Точно так же как MKL (математическая библиотека Intel) использует по максимуму возможности процессоров Intel, а ACML — аналог AMD — использует особенности процессоров AMD, хотя написаны обе они, вероятно, на С++
Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя.
То есть чтобы использовать особенности архитектуры ускорителей AMD разработчик не должен учиться пользоваться Brook+, а должен изучить особенности архитектуры этих ускорителей (без этого-то совсем никуда) и написать OpenCL приложение так, чтобы оно использовало все доступные возможности.
Точно так же как MKL (математическая библиотека Intel) использует по максимуму возможности процессоров Intel, а ACML — аналог AMD — использует особенности процессоров AMD, хотя написаны обе они, вероятно, на С++
«Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя. „
вот эту фразу всегда надо выделять тогда. если не делать акцент, то наверное не один я не до конца поймут смысл технологии.
Про математические библиотеки, я слышал, на той же летней школе в мфти, что mkl писали очень многое наши из (помоему даже из института системного программирования ран). так что узнать на чем писали я думаю можно у них при желании.
Желаю скорейшего написания статьи.
вот эту фразу всегда надо выделять тогда. если не делать акцент, то наверное не один я не до конца поймут смысл технологии.
Про математические библиотеки, я слышал, на той же летней школе в мфти, что mkl писали очень многое наши из (помоему даже из института системного программирования ран). так что узнать на чем писали я думаю можно у них при желании.
Желаю скорейшего написания статьи.
Большое спасибо за статью.
OpenCL полностью кроссплатформенная, а CUDA только на NVIDIA продуктах будет работать. Вот и вся разница. Иногда OpenCL может работать поверх CUDA, если хотим GPGPU, а графический процессор не поддерживает OpenCL, но поддерживает CUDA. Зато на OpenCL один раз написал хитрые алгоритмы и не паришься
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenCL. Что это такое и зачем он нужен? (если есть CUDA)