Про nVidia CUDA хабровчане уже наслышаны, теперь настал черед и AMD Brook+. Brook+ позволяет вам писать программы на С и запускать их на видеокартах AMD (ну и как опция — автоматически можно сгенерировать CPU версию со средним качеством кода). Достижимая производительность — порядка 600млрд операций на AMD 4870.

NB: Статья — краткое введение, не стоит ожидать освещения тут всех аспектов программирования на Brook+ :-)

Это первая публикация из цикла статей об использовании GPGPU и nVidia CUDA. Планирую писать не очень объемно, чтобы не слишком утомлять читателей, но достаточно часто.

Внутренняя модель nVidia GPU – ключевой момент в понимании GPGPU с использованием CUDA. В этот раз я постараюсь наиболее детально рассказать о программном устройстве GPUs.

В процессе работы с CUDA я практически не касался вопросов об использовании памяти видеокарты. Настало время убрать этот пробел.

Как известно, технология CUDA доступна только для видеокарт nVidia. Из-за этого факта часто возникают вопросы: как быть владельцам видеокарт ATI Radeon, и стоит ли вообще использовать решения, доступные на аппаратных средствах только одного производителя.

В связи с этим, я решил немного уточнить, что же из себя представляет CUDA,

Основная тема этой части – оптимизация работы с глобальной памятью при программировании GPU.

У GPU есть ряд особенностей, игнорирование которых может стоить многократной потери производительности при использовании глобальной памяти. Но если учесть все тонкости, то можно получить действительно эффективные CUDA-программы.

Приступаем.

Руководитель направления линейки продуктов Tesla с гордостью сообщил прессе, что будущие модели графических ускорителей nVidia будут ускорять не только 3D-графику в играх, но и некоторые задачи в операционных системах Mac OS X Snow Leopard и Windows 7.

В новой «анти-интеловской» терминологии nVidia графические процессоры следующего поколения следует называть не GPU, а GPGPU, то есть «универсальные графические процессоры» (General Purpose GPU). Это новая платформа, на которой возможно эффективное распараллеливание задач на сотни и тысячи вычислительных ядер CPU и GPU с помощью среды программирования OpenCL (Open Computing Language), основанной на языке C, которую в чём-то можно считать аналогом DirectX. Кстати, о поддержке OpenCL упоминает даже Apple на своём сайте в списке преимуществ новой операционной системы Snow Leopard.

Таким образом, новые ОС станут первыми, которые смогут полноценно использовать GPU в качестве нормального вычислительного юнита.

Здравствуй, уважаемое хабра-сообщество.

Многие, наверное, слышали или читали на хабре об OpenCL – новом стандарте для разработки приложений для гетерогенных систем. Именно так, это не стандарт для разработки приложений для GPU, как многие считают, OpenCL изначально задумывался как нечто большее: единый стандарт для написания приложений, которые должны исполняться в системе, где установлены различные по архитектуре процессоры, ускорители и платы расширения.

Здравствуй, уважаемое хабрасообщество.

В предыдущей статье про OpenCL был сделан обзор этой технологии, возможностей, которые она может предложить пользователю и ее состояния на настоящий момент.
Теперь рассмотрим технологию более пристально. Постараемся понять, как OpenCL представляет гетерогенную систему, какие предоставляет возможности по взаимодействию с устройством и какой предлагает подход к созданию программ.

Здравствуй, уважаемое хабрасообщество.

В предыдущих статьях мы рассмотрели OpenCL в целом, потом подробно вникли в суть стандарта и разобрали на каких идеях базируется эта технология.
OpenCL. Что это такое и зачем он нужен? (если есть CUDA)
OpenCL. Подробности технологии
Теперь настало время пощупать эту технологию живьем.

Компания Intel объявила об отказе от разработки потребительской версии своего перспективного general purpose GPU чипа Larrabee.
Разработки, впрочем, пока не совсем заброшены: Larrabee будет использоваться как платформа для разработки софта, а также как компонент высокопроизводительных компьютеров. Но купить для домашнего компьютера видеокарту, построенную на основе большого количества х86 процессоров, в обозримом будущем нам не светит.

Жаль, что революция в области графических акселераторов провалилась (пока), однако подобное развитие событий было ожидаемо: постоянные задержки разработки уже отложили выход чипа на год, а в полупроводниковой индустрии год — это обычно навсегда. В то же время не удивительно, что столь амбициозный проект не получилось довести до финального продукта и массового производства сразу. Наверняка, если при использовании GPGPU в высокопроизводительных компьютерных системах будет достигнут прогресс, то Intel вернется к разработке чипа для «простых людей».

Интересно, что всего два месяца назад сотрудники Intel рассказывали на Хабре о скором появлении чипа в продаже. Интересно, они так хорошо соблюдают NDA или это политика компании — не делиться со своими сотрудниками, работающими над проектом, планами по его закрытию?

источники 1, 2

Казалось, еще вчера я писал статью о высокопроизводительных вычислениях на видеокартах AMD с использованием технологии Brook+. Тогда она выглядела оптимистично, хоть и с некоторыми детскими проблемами…

В начале этого года AMD выпустила релиз 2-й версии своего Stream Computing SDK. Я радостно пошел обновляться и перекомпилировать свой софт в надежде получить устранение некоторых проблем, которые мне мешали, но…

Продолжению быть!
Часть 1

---

Задачи поставлены, и вроде бы самое время перейти к чтению различных обзоров и тестов, но…
С чего начать? В какую сторону вообще смотреть?

Вторая часть опуса будет посвящена ключевым компонентам современной системы — центральному процессору, оперативной памяти и видеокарте. В том, что эти компоненты основные, вряд ли кто-то сомневается, вопрос стоит в другом — кто из них главнее? На что следует обратить внимание в первую очередь при сборке машины под определенные задачи? На какой девайс и какие его характеристики?

На хабре уже рассказали о том, что такое OpenCL и для чего он нужен, но этот стандарт сравнительно новый, поэтому интересно как соотносится производительность программ на нём с другими решениями.

В этом топике приведено сравнение OpenCL с CUDA и шейдерами для GPU, а также с OpenMP для CPU.

Тестирование проводилось на задаче N-тел. Она хорошо ложится на параллельную архитектуру, сложность задачи растёт как O(N²), где N — число тел.

История

Гетерогенные вычисления уже есть во плоти и крови много лет — архитектура Cell. Там есть один проц в котором 1 ядро умное и выполняет функции которые в современных PC выполняет CPU, и 8 ядрышек которые гораздо проще, чуть-чуть сложнее чем ядра в видахе, у них у каждого свой поток инструкций, но он определяется управляющим ядром, сами эти ядра походу даже прерывания не обрабатывают, только считают циферки. Но с этой архитектурой возникли проблемы масштабирования, ибо если просто сделать 2 таких ядра, то появится проблема — поток выполняемый на одном главном ядре может иметь больше работы для своих «дочерних» ядер, чем другой и таким образом ухудшается утилизация чипа. Да под такие штуки сложно писать, но эту архитектуру можно развивать различными способами.

Введение
Как-то стояла задача отсортировать уникальный массив строк с использованием GPU с минимум кода и максимально возможной скоростью…
В данном посте опишу основную идею ее решения. В качестве элементов массива сортировки в данном посте выступают числа.
Случай с уникальными элементами небольшого массива
В качестве платформы была выбрана CUDA по причинам, которые можно считать брэндовыми или индвидуальными. По факту, здесь много примеров именно на CUDA, и она на данный момент получила большее развитие в GPU-вычислениях, чем аналогичные платформы от ATI и OpenCL.
Поиск в сети по алгоритмам сортировки на CUDA дал разные результаты. Вот наиболее интересный. Там есть рисунок

, из которого видно, что наилучший результат дал алгоритм QSORT, который дает сложность порядка от O(NlogN) до O(N^2). И хотя распараллеливание на GPU дало лучший в статье результат, закралось сомнение, что QSORT — не лучший способ использовать ресурсы видеокарты для данной задачи (особенно испугал размер приведенного кода). Далее описывается решение задачи, по сути «в одну строчку» с сложностью временной сложностью O(N) в худшем случае.

Компьютеры, даже персональные, становятся все сложнее. Не так уж давно в гудящем на столе ящике все было просто — чем больше частота, тем больше производительность. Теперь же системы стали многоядерными, многопроцессорными, в них появились специализированные ускорители, компьютеры все чаще объединяются в кластеры.
Зачем? Как во всем этом многообразии разобраться?
Что значит SIMD, SMP, GPGPU и другие страшные слова, которые встречаются все чаще?
Каковы границы применимости существующих технологий повышения производительности?

Введение

Откуда такие сложности?

Компьютерные мощности быстро растут и все время кажется, что все, существующей скорости хватит на все.
Но нет — растущая производительность позволяет решать проблемы, к которым раньше нельзя было подступиться. Даже на бытовом уровне есть задачи, которые загрузят ваш компьютер надолго, например кодирование домашнего видео. В промышленности и науке таких задач еще больше: огромные базы данных, молекулярно-динамические расчеты, моделирование сложных механизмов — автомобилей, реактивных двигателей, все это требует возрастающей мощности вычислений.
В предыдущие годы основной рост производительности обеспечивался достаточно просто, с помощью уменьшения размеров элементов микропроцессоров. При этом падало энергопотребление и росли частоты работы, компьютеры становились все быстрее, сохраняя, в общих чертах, свою архитектуру. Менялся техпроцесс производства микросхем и мегагерцы вырастали в гигагерцы, радуя пользователей возросшей производительностью, ведь если «мега» это миллион, то «гига» это уже миллиард операций в секунду.
Но, как известно, рай бывает либо не навсегда, либо не для всех, и не так давно он в компьютерном мире закончился. Оказалось, частоту дальше повышать нельзя — растут токи утечки, процессоры перегреваются и обойти это не получается. Можно, конечно, развивать системы охлаждения, применять водные радиаторы или совсем уж жидким азотом охлаждать — но это не для каждого пользователя доступно, только для суперкомпьютеров или техноманьяков. Да и при любом охлаждении возможность роста была небольшой, где-то раза в два максимум, что для пользователей, привыкших к геометрической прогрессии, было неприемлемо.
Казалось, что закон Мура, по которому число транзисторов и связанная с ним производительность компьютеров удваивалась каждые полтора-два года, перестанет действовать.
Пришло время думать и экспериментировать, вспоминая все возможные способы увеличения скорости вычислений.

Здравствуй, уважаемое хабра-сообщество.

Многие, наверное, уже слышали о вычислениях на GPGPU(видеокартах), на текущий момент существует много реализаций этой техники программирования. Мы остановимся на двух из них — это небезызвестная CUDA от компании Nvidia, и я думаю чуть менее популярный, но также известный фреймворк OpenCL. На хабре уже есть достаточное количество статей, в которых описан основной принцип работы этих технологий, поэтому мы не будем заострять на этом внимание. В статье я хочу поделиться результатами, полученными при использовании GPGPU в сравнении с CPU для сжатия данных.

На Хабре уже были статьи об OpenCL, CUDA и GPGPU со сравнениями производительности, базовыми понятиями и примерами, поэтому рассказывать об основах и принципах работы я тут не буду, даже код не покажу. Но я хочу описать в чем заключаются реальные трудности при использовании GPU (про ограничения и их последствия), почему нельзя сравнивать производительность CPU и GPU, а также про то насколько “универсален” OpenCL на самом деле.