AMD

Sale: видеокарты для вычислений (но годятся и для игр)

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

NVidia Geforce Titan: продано

AMD Radeon 7970HD (3GB, Tahiti XT): продано

Про AMD FirePro W9100

Вот между прочим, AMD выступила очень достойно с FirePro W9100: они сделали чип у которого отношение производительности Single Precision : Double Precision 1:2, вместо обычных для AMD 1:4 (а на HD5xxx было 1:5)

В результате у них 2.6TFlops DP (теоретической), что в 1.85 раза больше, чем у (самой толстой на сегодня) NVidia Tesla K40 (1.4Tflops теоретических).

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

Я ожидаю, в первую очередь, взбодрения всяких CAD-ов. Это FirePro не выглядит картой для вычислительных кластеров (коим 6 видео-выходов без нужды), а вот на рабочих станциях, и 3D-графика и ее обсчет на одной карте - очень к месту ж.

Ждем, естественно, ответа NVidia. Так, по идее, Maxwell - хороший, 750Ti обгоняет 650Ti на вычислениях прилично так (при меньшем количестве cores и достаточно близких частотах).

P.S. Конечно, лидером по price/perf (DP) остается NVidia Титан, но это другая история (на Титан, в числе прочего, драйвера от Квадры не натянуть, т.е. всякие CAD-ы пролетают).

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

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

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

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

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

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

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

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

Давно копил в себе злобу желание про это написать, а тут вот появился повод.

Вот есть такая 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.

Если в одном месте убудет, в другом - обязательно прибудет

Интересно, когда кулеры станут больше материнских плат?

P.S. mini-ITX как идея - очень понравилось!

AMD CPU qs

С несерверными AMD-шными CPU как-то вообще никогда не приходилось сталкиваться (да и с серверными - приходится не очень часто), а их же больше четверти (по статистике Steam).

При этом, хочется всякие новые варезы писать с расчетом на относительно новые процессоры, SSE3+ или вроде того. И если интелы в хозяйстве есть, от Core2 и выше, то с AMD - провал. Отсюда у меня возникает серия вопросов (википедию быстро пролистал, но там реально много, я лучше уточню):

Как оно ваще

  • Верно ли я понимаю, что AMD Llano - это продолжение старой серии, которая началась с K8. Т.е. отлаживаясь-бенчмаркаясь на ней - можно результаты экcтраполировать на более старые горшки?
  • AMD Trinity - это уже бульдозер, другой сокет (?? см. ниже) и все другое.
  • 3Dnow! - един, как в K6 появился, так новых инструкций не добавлялось. Разобрался: These instructions have many names, including 3DNow!+, 3DNow!ext, 3DNow!2, 3DNow! Professional, но ничего существенного для моих нужд не добавилось, ура.
  • Насколько embedded-процессоры (вроде Fusion E-350) позорны относительно десктопных процессоров 5-6-летней давности (ну, скажем, Intel Core2 Duo 1.83)?
Практика
  1. Существует ли сокет, в который можно было бы сунуть и процессор на K10-K12 и процессор на бульдозере (AM3+?)
  2. Вопрос 1, но процессоры берем с графическим ядром (Llano/Trinity) (нет?)
  3. Вопрос 1 или 2, но бывают ли такие сокеты на Mini-ITX мамках? (нет?)
Ну то бишь чешутся руки собрать что-то на AMD-Llano в Micro-ITX корпусе размером с мак-мини или чуть больше, да еще и с возможностью апгрейда на бульдозерные горшки.

Вроде как получается, что полного счастья нету, не бывает чтобы и с GPU и один сокет и два поколения?

В целях упрощения текста, я бульдозер и копер (piledriver) не различаю, оба поддерживают AVX и SSE4.1/2, с моей точки зрения (как разработчика) - это интелы без SSSE3 (да и то не факт, битик этот есть у AMD, может быть в википедии недописали).

Про HD7970

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

Вкратце:

  • 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 - видят. Прямо хоть в сорцы лезь....

Об AMD 7970 и терафлопсах

Я тут, со всей этой суетой предновогодней, пропустил анонс HD7970, сегодня только прочитал.

Очень хотелось, но кажется терафлопса (на DP) на одной карте таки не будет. Т.е. формально там что-то в районе 950 Gflop/s на штатной частоте, вроде можно разогнать где-то до 1100Mhz (а там на DP аккурат один килофлопс на такт: 2048 юнитов, 512 DP-операций, уможаем на 2 т.к. MAD), но маловероятно, что реальная эффективность на DGEMM будет выше 90%, а на HPL - выше 75-80. Потому что оверхед таки есть, на DMA, да много на что (на 6990, например, DGEMM получается эффективнее 90% только если найти те правильные ядра, которые с PCIe наиболее эффективно работают, по меньшей мере на оптеронах жизнь именно так устроена).

А жаль, счастье было так близко! Терафлопс на десктопе - это хороший такой рубеж.

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

Ибо если они совсем независимы (просто такой multi-core девайс, с регистрами, локальной памятью доступной группе ядер, ну и медленной глобальной памятью) - то это совсем другой разговор.

О бульдозерах

Я редко анонсирую читаемые ссылки с веба (как бы, блин, автоматизировать выкладку закладок из Evernote в твиттыр, с удобным редактированием?), но тут - тот самый случай.

Читаю Арстехнику: Can AMD survive Bulldozer's disappointing debut?, много думаю:

  • Один FPU на два ALU мне изначально казались какой-то фиговой идеей, ибо аккуратно программируя этот самый SSE зачастую удается порядок прироста в хотспотах получить (раза три на SSE и еще столько же на 4x ядрах), не делая всю программу многопоточной. А тут выясняется еще, что старый FPU имел 3 одинаковых юнита и формально умел 3 операции на такт (ограничений я точно не знаю, но подозреваю что как у Интела - 1 load/store, 2 математики, во всяком случае всякие тесты вроде GEMM давали ~1.8 op/clock что похоже на 2 теоретических операции). А у нового - 4 юнита, но два из них целочисленные, а два - плавучка. Это что, 1 op/clock будет? Ну ладно, для GEMM спасемся FMA, а для всего остального?
  • Идея AMD в том, что вместо SSE-операций надо переползать на APU. Идея отличная, APU умеет scatter-gather, в отличие от SSE, но беспокоят такие вот мелочи:
    • Где, собственно, бульзозер с APU?
    • APU - это же OpenCL, со всеми прелестями двойной буферизации, прямо in-place не поработаешь.
    • Ну и переносимость тоже тревожит. Старый код будет работать плохо, да?
  • Порадовала мысль о том, что в "несколько-поточном" (threads меньше чем cores) приложении планировщик должен их раскидать так, чтобы часть модулей освободить от нагрузки, тогда можно у загруженных частоту поднять.
  • Вместе с тем, планировщик потоков должен еще знать, какие из threads жрут много FPU - чтобы раскидать по одному такому потоку на модуль. А откуда планировщику это знать? Должен быть какой-то API, позволяющий это сказать....
Короче, бардак какой-то с этими бульдозерами, августовские анонсы оставляли лучшее впечатление.

О нагреве видеокарт

Читаю доку (техрепорт) к CALDGEMM и внезапно вычитываю такое (по смыслу, не близко к тексту):

  • в readme: ключ -f заливает входные матрицы нулями, а не случайными данными, отчего инициализация проходит быстрее (ну да, попробуйте 60Gb random нагенерировать).
  • в техрепорте: если входные матрицы нулевые, то конструкция сильно меньше греется т.к. в результате вычислений не меняется ни одного бита памяти.

Ну, собственно, так и есть, проверено на себе: с минус -f все работает как из пушки, а без оного - уносит нафиг, если вентилятор заранее не раскрутить (время реакции системы термосенсор - думатель - вентилятор недостаточно, нагрев практически мгновенно происходит).

Остается понять - это нулевые биты меньше греются или достаточно того, что содержимое не меняется?

День бульдозериста

Читаю новость: AMD's Bulldozer processors now shipping; in servers by end of month, много думаю:

  • С одной стороны, 1 FPU на два ALU - это как-то обидно. Даже с учетом появления там FMA, не факт что производительность значительно вырастет в сравнении с текущими 12-ядерными оптеронами у которых 12 FPU на камень. Частота, правда, несколько повыше.

    Нет, понятно, не плавающей точкой единой, но мне интересна именно она.

  • А с другой стороны, в гибридных случаях (CPU+GPU) изрядное количество ядер занято именно тем, что нагребают в GPU данные и выгребают их оттуда. В моих последних экспериментах, двух core на GPU не хватает, нужно три (одно засовывает, два - высовывают). В этих ядрах, соответственно, FPU простаивает, а значит и не нужен там.

    Соответственно, три бульдозерных модуля (6 ALU, 3 FPU) на один GPU - будет прекрасная пропорция: трое выгребальщиков-нагребальщиков а еще три ядра тоже что-то считают. Скажем, 8 операций на такт (2 128-битных FMA), да на 3 гигагерца - получается заметная прибавка к скорости GPU (которая в районе 500GFLOP/s на double на сегодня).

Только вот программировать это место придется особо, с явным мэппингом вычислительных/IO threads к парам ядер, чем сложнее оборудование, тем больше гемороя...

Из той же новости:

... but where Intel currently outsells AMD by about 19 to 1. In 2006, the ratio was about 3 to 1 in Intel's favor.
5% рынка? Что, уже все так плохо? А по серверам как?

I like to move it, move it

Мониторю всяческие новости про OpenCL, CUDA и прочие GPGPU и в последние дни просто засыпан новостью про то, что GEGL is getting GPU-based image rendering and processing.

Довеском к этой новости идет ссылка на OpenCL on GEGL: Results up to now, где сравнивается реализация brightness-contrast фильтра на CPU и на GPU (и не каком-то, а Tesla 2050 ценой 2 килобакса) и получается для 1-мегапиксельного изображения:

  • 526 msec на CPU
  • 483 msec на GPU
Просто гигантский выигрыш, почти 10% !!! Притом, как я понял (может быть и неправильно), во время исполнения на GPU не посчитана пересылка "обратно", с карты в RAM.

При этом, заметим, на CPU оно работает на одном ядре (хоть и на SSE2), а значит на 4 ядрах оно банально будет быстрее разика в три.

Причина тривиальна и прямо в том блог-посте описана, весь пар ушел в свисток, а все время исполнения - на пересылку данных. Собственно исполнение обработки на GPU занимает около 1/10 всего времени.

При этом, само время исполнения - чудовищно. Полсекунды на 1 мегапиксель, даже если пиксели 16-байтные (4 float) - это 32 мегабайта в секунду. Э.... По PCIe обычно ходит 4-5 гигабайт/сек..... Проблема, судя по всему, кроется в тайлововой организации картинки в GEGL, тайл при этом мелкий (128x64) и даже на CPU обрабатывать их эффективно не получается, что уж говорить про GPU, где под каждый тайл аллоцируется текстура.

На эту тему имею рассказать следующую историю:

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

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

Я как-то не уследил, потому что 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 вообще не поддерживает никаких видеокарт, смешно.

Видеокарта с двойной точностью или AMD strikes back

Одна из наиболее неприятных проблем при расчетах на видеокартах — это поддержка только 32-битных чисел с плавающей точкой (single precision).

Несмотря на то, что все ожидали прорыва от NVidia (более того, это обещали к концу года), первой о поддержке FP64 объявила AMD/ATI, анонсировав FireStream 9170.

Вкратце:

  • поддержка FP64;
  • $1999 (MSRP);
  • 2 гигабайта памяти;
  • 500 GFLOP/s на одинарной точности, сколько на двойной - не пишут;
  • 150 ватт, PCIe 2.0, x16 ;
  • асинхронная (от расчетов) передача данных из/в карту;
  • В SDK обещают наличие Brook+ с поддержкой CTM (то, что в public пока было в глубочайших альфах);
Доступность, как я понял, в первом квартале 2008.

С нетерпением ждем ответа NVidia, ибо CUDA конечно куда человечнее, чем StreamProcessing.

Subscribe to AMD