OpenCL

Про OpenCL-бенчмарки (опять, да!)

lexa - 21/Апр/2013 13:10

Злоба на эту тему у меня копится и периодически выплескивается.

История первая

В Mac OS X 10.8.3 поапгрейдили драйвера NVidia и у NVidia 6xx в LuxMark стало в полтора раза меньше попугаев.

Предполагая, что бенчмарка - нормальная (т.е. меряет время выполнения, никак его не нормализуя на конфигурацию железа), давайте попробуем разобраться что случилось:

  • Было (драйвер репортил): 28 юнитов
  • Стало: 7 юнитов (более широких, но не суть)
Само железо не изменилось. Мог, конечно, измениться (ухудшиться) OpenCL-компилятор, но у меня предположение другое: само приложение, увидев меньше юнитов, задает размеры грида (количество одновременно исполняемых Workgroups) поменьше. От этого происходит худшая утилизация железа (ну там латентность памяти не прячется) и уменьшаются попугаи. Проверить нетрудно, но лень читать исходники.

История вторая

Про Intel и OpenCL

lexa - 01/Апр/2013 17:30

И вторая за сегодня новость про OpenCL.

Вышел интеловский SDK (SDK for OpenCL Applications 2013 Release). А там, кроме всего прочего такое вот:

Support in dual adapter mode on Windows* 8: enables OpenCL workloads to be accelerated on Intel HD Graphics when the device is not directly connected to a display and fully enabled running Intel driver.
Я осуждаю то, что это только для Win8, а сам факт - одобряю. На Ivy Bridge/Haswell можно будет посчитать что-нибудь эдакое без чудовищного оверхеда по копированию по PCIe (а, всего-лишь, с небольшим оверхедом на double buffering :)

Про OpenCL-бенчмарки

lexa - 24/Фев/2013 11:55
Давно копил в себе злобу желание про это написать, а тут вот появился повод.

Вот есть такая ViennaCL, пакет линейной алгебры для "вычислительных ускорителей" (приходится писать так потому что Xeon Phi). На днях вышла версия 1.4.1 и про нее написано:

...and features a GEMM kernel reaching more than 1.3 TFLOPs on an AMD HD7970.
Я призадумался, как такое может быть, ведь HD7970 - это чуть меньше терафлопса на стандартных клоках, ну гигагерц-edition, но 1.3TFLOPs означает, что разогнали на ~35% (верю с трудом) и использовали на 100% (вовсе не верю).

Начал разбираться. Нашел вот это:

Our sample HD7970 reaches over 1.3 TFLOPs in single precision and 200 GFLOPs in double precision.
Теперь другое странно: на двух HD6990 (т.е. 4 чипа предыдущего поколения) лично добивался 1.72 терафлопса на HPL (но там основное - тот же DGEMM), т.е. по 430 GFLOPs на чип, а потом ту же систему довели до 2.053 TFLOPs т.е. по 500 на чип. При теоретической (прямо по AMD-шному сайту) 2x1.37=2.74. То есть эффективность была 75% от теоретической, а ViennaCL гордится 200/947=21%.

Да, то что я мучал полтора года назад - это было написано бодрыми немцами на CAL/IL, ViennaCL - OpenCL, но не должно же быть ТАКОЙ разницы, больше чем в три раза по эффективности?

Если посмотреть на Anandtech-овские тесты Titan GTX, то там для DGEMM приведена цифирка: HD7970 - 689 GFLOP/s и референс на 'Matsumoto et al'. Я поискал и нашел вот эту вот статью (и только потом увидел ссылку на нее прямо у Ананда), из которой получается что 689 GFLOPs - это производительность APPML, а этот самый Мацумото получил over 800 (т.е. вполне разумные ~80% от теоретической, что для одночиповой системы похоже на правду для GEMM).

Анандтеху - незачет (потому что из всех возможных цифирок конкурента - взяли самую маленькую), но про ViennaCL остаюсь в еще более тягостном недоумении, если библиотека от вендора (APPML) дает результаты вдвое выше, чем у Vienna, то чем они там гордятся то?

Еще большая катастрофа происходит с OpenCL-бенчмарками на сильно разной архитектуре (AMD/NVidia).

Вот, к примеру, Luxmark Database.

Про HD7970

lexa - 31/Янв/2012 21:04

Договорился с жабой и купил новую грелку для ног.

Вкратце:

  • OpenCL 1.1, поддерживается, работает. Посмотреть что там за код не получается, Kernel Analyzer не умеет это место.
  • Драйвера: под винды есть, бета, в основной Catalyst не включены (и, похоже, войдут не раньше чем в 12.3 т.е. через два месяца т.к. даже в 12.2-preview поддержки 79xx нет). Драйвера под линукс поискал для проформы (мне не надо) - и не нашел.
  • Сцуко, быстрая. Один и тот же OpenCL-код (написанный с оглядкой на NVidia Fermi) работает в-среднем раза в полтора быстрее, чем на GTX480 (single precision). Предыдущая моя ATI-шная карта, HD5870 была в 1.5-2 раза медленнее 480-й нвидии.

    На примере MatrixMultiplication из AMD APP - быстрее в 4 раза (single).

    С double не все так радужно - нужно явно как-то иначе оптимизировать, а может просто драйвера кривые. На всем что попробовал, 7970 получается непринципиально быстрее GTX480, а на каких-то задачах и помедленнее.

  • Сцуко, холодная. Idle temp 44C, прогреть больше чем до 80 счетным кодом не удалось. Наверное, если получше пооптимизироваться, то удастся подогреть больше. Ноги, короче, не греет.
  • Сцуко, тихая. Ну то есть если вручную вентиляторы поставить на 100%, то громкая, как и любая современная видеокарта со штатным охлаждением, но вышеуказанные 80 градусов были при скорости вентилятора чуть больше 2500RPM, это меньше половины (100% - 5400) и на этой скорости она тихая.
Заодно выяснил, что за тот год, что я туда не заглядывал - AMD'шный гайд по OpenCL стал из вообще никакого - довольно интересным чтением. Сижу, читаю. Про Tahiti там пока мало и невнятно, но какой-то раздел по оптимизации уже есть.

P.S. В игры - не играю, ничего не проверял. С картой был купон на DiRT3, но годный до 31 декабря. Смешно, в продаже они появились за неделю до этого....

P.P.S. Lux Render отчего-то вторую карту не видит, как и 5870 не видел. Все прочие разумные тулзы, вроде clinfo и CPU-Z - видят. Прямо хоть в сорцы лезь....

Про AVX и OpenCL

lexa - 27/Сен/2011 15:04

Вчера вышел Intel OpenCL SDK 1.5 с соответствующим анонсом: Increase OpenCL application performance with the new Intel OpenCL SDK 1.5

Пытаюсь enlarge increase эту самую performance, сую в бензопилу лом туда AMD-шные примеры, которые на предыдущей версии работали очень бодренько (и временами почти догоняли AMD-шную видеокарту) и вижу замедление в 2-3 раза для половины примеров.

Начинаю читать код и не вижу там 256-битности. Ну, почти не вижу. Кое-где есть 256-битные load/store, нашел даже один vandps ymm1,ymm1,[memory], но в подавляющем большинстве код - 128-битный.

Он и в прошлой версии был 128-битный, но какой-то более человеческий.

Зато есть пошаговый отладчик, если бы не он, я бы версию 1.5 сразу бы снес, а так - еще подумаю.

Ну то есть понятно, производительность не переносится, но 2-3 раза просадки - это беспредел.

Единственный пример, который стал быстрее, называется Histogram. Но его и старая версия отказывалась векторизовать (немудрено) и новая тоже не хочет.

Об Intel ISPC

lexa - 27/Июн/2011 19:15

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

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

void vector_sum(uniform float in[], uniform int count, reference uniform float out[]) {
    float sum = 0.0;
    for (uniform int i = 0; i < count; i += programCount) {
        int index = i + programIndex;
        sum+= in[index];
    }
    out[programIndex] = sum;
}
И оно у вас пойдет фигачить шириной programCount, ну там дальше надо будет элементы out просуммировать уже снаружи.

Об Intel OpenCL

lexa - 23/Июн/2011 22:48

Щупаю тут за вымя Intel OpenCL (для CPU) и эта игрушка мне все больше нравится.

Помимо оффлайн-компилятора (который выдает ассемблер или LLVM-код) эту хреновину можно профайлить при помощи VTune (нужно пару переменных окружения поставить, см. доку).

Беру я, значит, прямо тамошний пример MedianFilter и начинаю профайлить. Он содержит "CPU"-реализацию (в том смысле, что компилятор C++ ее превратит в обычный код) и OpenCL-вариант (который будет скомпилирован на лету). Обе реализации имеют настолько одинаковый C/C++ код внутри, насколько это вообще возможно (OpenCL-ядро - это обработка одной строки изображения, а CPU-код имеет еще цикл по всем строкам). Код, собственно, простой как пробка: берем пикселы из окрестности +-1, слегка сортируем (unrolled), вот и медиана.

И вот что я вижу:

  • CPU-вариант при компиляции Visual C++ 2008: 389 msec на исполнение. Это без processor-specific оптимизаций и без распараллеливания.
  • OpenCL-вариант: 15 msec.
В 26 раз быстрее, однако.

Ну ладно, VC++2008 - не самый новый, да и процессора моего не знает. Переключаю компилятор на Intel C++ 12-й версии (который Composer XE), включаю оптимизацию для AVX, уже лучше: 151 msec. Но тоже в 10 раз.

Не все йогурты одинаково полезны

lexa - 07/Май/2011 21:23

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 они работают практически одинаково по скорости.

AMD/ATI и GPGPU

lexa - 12/Янв/2010 21:50

Я как-то не уследил, потому что AMD/ATI-шными видеокартами начал интересоваться с выходом HD5xxx, а оказывается все очень весело. На gpgpu.ru это уже пообсуждали, ну я сюда наброшу, в более концентрированном виде.

Раньше высокоуровневым средством для разработки считалок на видеокартах у ATI был Brook+. Однако начиная с какой-то беты ATI Stream SDK 2.0 Brook из SDK исчез.

Читаем в ATI-шном форуме (это август-2009):

Yes, this SDK 2.0 beta is for CPU only. It focuses on OpenCL 1.0 for CPU. Brook+ is now available on SourceForge: http://sourceforge.net/projects/brookplus

Ну ладно, Stream SDK Beta-1 вообще не поддерживает никаких видеокарт, смешно.

Коня и трепетную лань

lexa - 20/Дек/2009 19:40

opencl.jpg Мучал 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: документации, примерах и тому подобных вещах.

CUDA vs OpenCL

lexa - 04/Июн/2009 11:39

Во-первых, сравнение производительности в предыдущем посте неверное. Действительно nBody/CUDA показывает 320+ GFLOP/s (на 280GTX), но это при количестве частиц в 32к. А при 8к - вдвое меньше, около 159 GFLOP/s.

Во-вторых, в свежих бетах (вчера вышла Beta 1.2) NVidia OpenCL производительность или самого примера или компилятора или обоих - тоже подтянули и сейчас на 8к частиц oclNBody показывает 129 GFLOP/s. Что уже вполне объясняется тем, что картинку для показа приходится гонять между OpenCL и OpenGL буферами.

Мораль: под OpenCL уже вполне можно девелопить, с тем чтобы когда все это счастье появится публично - уже быть готовым.

NVidia: CUDA и OpenCL

lexa - 24/Май/2009 11:02

После появления первой доступной реализации 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.

Угадал, блин

lexa - 13/Май/2009 11:59

Довелось оказаться пророком.

В комментариях к записи про анонс NVidia работающего OpenCL я предположил, что

Конечно, сейчас начнется, они вполне могут начать с драйверов для Линукса (или для 32-битной XP, что от меня столь же далеко)
И угадал, блин. Именно XP-32 и Linux-32. XP-шные бинарники на Висте не работают, несмотря на драйвер нужной версии, ругаются что не могут создать OpenCL context

А у меня Vista (32/64) и MacOS. Ну в Маке, ладно, обещали в заснеженном леопарде, а с вистой что? Руки же чешутся....

На закуску: согласно спекам OpenCL, его можно/нужно кормить исходником прямо на этом самом OpenCL (а это практически C). То бишь компилятор этого самого C сидит прямо в драйвере....

Интересно, насколько успешно это пойдет в индустрию, ведь получается что computing kernel засекретить не выйдет, можно же подсунуть приложению драйвер похожий на настоящий и почитать им исходника. Видятся мне OpenCL-обфускаторы.

Пеар и моркетинг

lexa - 21/Апр/2009 09:20

Пресс-релиз от 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 мне, помимо потенциальной многоплатформенности, люба трансляция из исходников на лету, у меня столько идей....

Subscribe to OpenCL