GPGPU

Интел выкатил в опенсорс такую вот игрушку: Intel SPMD Program Compiler.

Это очередная попытка придумать параллельный язык C: пишете некую функцию, к примеру, обрабатывающую элемент данных, варез сам строит SIMD-представление (SSE, AVX), которое обрабатывает 4(8) элементов за раз. Ну как-то так:

И оно у вас пойдет фигачить шириной programCount, ну там дальше надо будет элементы out просуммировать уже снаружи.

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

Более того, реализаций для CPU уже две на виндах: AMD-шная входит в состав ATI Catalyst (драйверов для видеокарты) и даже при отсутствии подходящей видеокарты эта часть драйверов поставится. Кроме того, Intel-овский OpenCL на днях перешел из стадии альфа в бету. На Linux, кстати, есть еще IBM-овский OpenCL для CPU, все руки не доходят его ощупать.

Берем AMD-шный пример BitonicSort из APP SDK 2.4 (это AMD-шный SDK для GPGPU) и запускаем, без перекомпиляции, прямо на всех имеющихся в машине девайсах и реализациях. Сортируем 16 млн. элементов. В порядке падения быстродействия:

1. Intel OpenCL (процессор i7-2600k @4.5Ghz): 10.6 сек.
2. NVidia OpenCL (GTX480, драйвер 270.61): 16.4 сек.
3. AMD OpenCL (Radeon 5870, драйвер 11.4): 29.3 cек.
4. AMD OpenCL на CPU (тот же самый): 415 сек.

Я подозреваю, что AMD-шный OpenCL в случае CPU просто процессор не опознал и сгенерировал код для 8086 или что-то вроде этого. Для CPU AMD Kernel Analyzer показывает нам невекторизованый код, т.е. процессор не опознался и что под него генерировать AMD не знает. На предыдущем процессоре (i7-920) такой разницы с интеловским OpenCL (тогда он был в первой альфе) не было. При этом, при исполнении на AMD-OpenCL процессор загружен где-то на четверть, а "под интелом" - на 100%

Прикол тут в другом: по формальному быстродействию горшки ранжируются в обратном порядке: у AMD бешеные 2 терафлопса на float (по пресс-релизу AMD: 2.7 TFLOP/s), у NVidia - раза в два поменьше (в районе 1.35 TFLOP/s если формально считать), у CPU же, даже если AVX посчитать как 16 операций на такт (две AVX-операции на такт) получается 16 x 4 ядра x 4.5 гигагерца = 288 GFLOP/s.

Понятно, что сортировка - дело такое, для потоков плохо предназначенное.

Чтобы два раза не вставать: большинство AMD-шных примеров на GTX480 работает быстрее (и лишь некоторые - незначительно медленнее), чем на HD5870. Несмотря на формальные попугаи, говорящие об обратном. Обратного, чтобы OpenCL-примеры NVidia работали бы быстрее на AMD, - не наблюдается.

Update: Помучал тот же пример на машине с i7-920 и GTX280. AMD OpenCL/CPU никуда не годится и там, увы. Может быть надо kernel как-то иначе писать. Что же касается реализаций Intel (CPU) и NVidia (GPU), то на этой паре железок и BitonicSort они работают практически одинаково по скорости.

Капитан Очевидность Я в свое время почти угадал.

В том смысле, что я предсказывал 64-битную адресацию, она физически стала 40-битной. Хотя размер индекса в одном массиве остается 32-битным (собственно длинных int нету).

А так - забавно наблюдать, как оно эволюционирует. Нет, вполне разумно, но видно что первоначальная идея много очень простого железа оказалась слишком идеалистичной. Вот кэши на глобальную память добавили, притом сразу два уровня (был текстурный кэш L2, впрочем).

Сама же G200 GF100 (представленная вчера в виде GTX470/480) выглядит черезвычайно вкусно. Всяких текстов в сети навалом, сам я отпишусь когда куплю, жевать чужие тексты довольно бессмысленно.

В прошлом году я прощелкал, а в этом - нет, успеваю анонсировать.

С 24 февраля по 12 мая, еженедельно, по вторникам, на ВМиК МГУ (Москва, Воробьевы горы, м. Университет) будет читаться курс программирования NVidia CUDA для всех желающих.

Процитирую из анонса:

Московский Государственный Университет им. М.В. Ломоносова совместно с компанией NVIDIA приглашает заинтересованных студентов пройти специализированный курс "Архитектура и программирование массивно-параллельных вычислительных систем" на основе технологии CUDA. В рамках курса вы узнаете о современных многоядерных архитектурах, моделях программирования и основополагающих принципах, лежащих в основе построения эффективных параллельных алгоритмов. Вы также познакомитесь с реализациями типичных алгоритмов и задач, возникающих в цифровой обработке сигналов, математическом моделировании и гидродинамике. По окончании курса вы сможете применить свои знания на практике уже сегодня при решении вычислительноемких задач в ваших курсовых и дипломных работах. Приобретенные знания необходимы для всех, кто планирует связать свое будущее с высокими технологиями и высокопроизводительными вычислениями. Всем студентам, успешно завершившим курс "Архитектура и программирование массивно-параллельных вычислительных систем" будут выданы дипломы.

Мучал ATI Radeon HD5870 и NVidia GTX280 в одной машине на предмет взаимной поддержки OpenCL. Поддерживают. С оговорками, но жить можно. Написал на эту тему небольшой текст:

OpenCL, NVidia, ATI и все все все....

В процессе читал AMD-шные форумы, вычитал страшного, много думал:

OpenCL performance issues

There are known performance issues for HD4XXX series of cards on OpenCL and there is currently no plan to focus exclusively on improving performance for that family. The HD4XXX series was not designed for OpenCL whereas the HD5XXX series was. There will be performance improvements on this series because of improvements in the HD5XXX series, so it will get better, but it is not our focus.

For example, if you are using local memory, they are all currently emulated in global memory. So it is possible you are going out to main memory twice as often as you do on NVidia. This can cause a fairly large performance hit if the application is memory bound. On the HD5XXX series, local memory is mapped to hardware local and thus is many times faster than the HD4XXX series.

Короче, слушайте вашу группу валенки. Формально OpenCL на HD4xxx поддержан, а фактически нужно совершенно другой kernel писать, который локальную память не использует.

А 48xx - важный кусок рынка, их много навыпускали и формально они совсем неплохие. Теперь и в этом сорте не скажу чего придется разбираться. Хорошо хоть про 2xxx/3xxx просто рекомендовано забыть.

P.S. Сравнивая два SDK, видно что ATI в области GPGPU очень заметно отстает (disclaimer: это лично мое мнение по результатам одного дня изучения :). Речь именно о качестве SDK: документации, примерах и тому подобных вещах.

После появления первой доступной реализации OpenCL (доступна для зарегестрированных NVidia-девелоперов с девелоперского сайта) все кинулись смотреть (и я тоже).

Накопали всякого интересного:

• Бинарное представление OpenCL-кода - это практически CUDA PTX (ссылки: PDF-текст про это, ветка форума к которой этот текст относится).
• Возможно подсовывание PTX-кода от CUDA в OpenCL (ссылки те же), смысл может быть в использовании тех CUDA extenstions, которых нет в OpenCL. Правда, при этом можно использовать просто CUDA т.е. смысла не очень много.

Кроме того, многих фишек CUDA просто нет в текущей реализации OpenCL, что огорчительно:

• Нет работы с mapped pinned memory (что появилось в CUDA 2.2). Т.е. требуются пересылки в память видеокарты даже там, где эта память - на самом деле системная память (ноутбучные видеокарты), да и вообще без пересылок удобнее.
• В CUDA есть взаимодействие с OpenGL, в OpenCL - нету (в спецификации есть, но пока не поддержано). В результате, пример nbody в OpenCL-реализации работает вчетверо медленнее на GTX280 (80GFLOP/s вместо 320), ибо весь пар уходит в пересылку результата на хост, а с хоста - на отрисовку.

Вообще, со всеми этими extensions все выглядит пока весьма огорчительно. Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру. И на текущем разнообразии железа не видно выхода, слишком оно разное, чтобы из одной программы компиляцией получались эффективные решения под ATI и NVidia одновременно.

Простые юнит-тесты еще не делал, руки не дошли, пока только смотрел код из SDK.

Update Похоже, про nbody товарищи не правы. Т.п. в oclNBody какая-то работа с OpenGL objects есть. Либо недоделано, либо просто NBody нужно под OpenCL делать как-то иначе.

Update2 Предыдущий апдейт неверен, ибо (согласно Release Notes): 2. OpenCL - OpenGL Interop is not supported.

Пресс-релиз от NVidia, фанфары:

NVIDIA Corporation, the inventor of the GPU, today announced the release of its OpenCL driver and software development kit (SDK) to developers participating in its OpenCL Early Access Program.
....Developers can apply to become a GPU Computing Registered Developer at: www.nvidia.com/opencl

Ну ладно, иду и apply, мне несложно.

Заполнил форму и думаю, что надо заглянуть в уголок CUDA-девелопера (только для бе.. туда нужно тоже через Application, я больше двух лет назад вписался), вдруг там что новое.

Ага, есть новое:

Looking for OpenCL drivers?
You are in the right place. Registered developers with access to this web site will receive an email notification as soon as our Beta drivers are ready.

Маркетинг отстрелялся, а осадок у меня остался.....

А в OpenCL мне, помимо потенциальной многоплатформенности, люба трансляция из исходников на лету, у меня столько идей....

Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.

Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU. Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.

В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.

закрутившись, пропустил анонс новой видеокарты от NVidia. Из интересного мне - может считать с двойной точностью. Но что-то не очень быстро. Мои мысли про это - на GPGPU.ru

NVidia GTX 280, Tesla T10P