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) поменьше. От этого происходит худшая утилизация железа (ну там латентность памяти не прячется) и уменьшаются попугаи. Проверить нетрудно, но лень читать исходники.

История вторая На Tomshardware большой тест скорости работы Titan GTX на вычислительных задачах.

Что мы видим:

  • На OpenCL-тестах: Titan в некоторых случаях хуже, чем 580GTX (и лишь незначительно лучше, чем 680GTX), а в некоторых - хуже 680GTX (у которой, заметим, поменьше юнитов и вообще всего поменьше при примерно той же архитектуре).
  • На CUDA-тестах: Titan всегда лучше всех, а вот второе место может быть как у 580GTX (двойная точность?), так и у 680GTX
CUDA - дает ожидаемые результаты (Titan ожидаемо быстрее всех), а с OpenCL - привычный бардак.

В очередной раз хочу сообщить, что тестировать один и тот же OpenCL-код на разном железе (без специфичных оптимизаций под конкретное железо) - бессмысленно.

Про 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 означает,...

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

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

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

AMD CPU qs

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

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

Как оно ваще...

Про HD7970

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

Вкратце:

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

Об 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
Просто гигантский...

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

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

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

Берем AMD-шный пример 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