AMD

В результате у них 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-ы пролетают).

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

...and features a GEMM kernel reaching more than 1.3 TFLOPs on an AMD HD7970.

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

Our sample HD7970 reaches over 1.3 TFLOPs in single precision and 200 GFLOPs in double precision.

Да, то что я мучал полтора года назад - это было написано бодрыми немцами на 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.

С несерверными 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 мамках? (нет?)

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

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

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

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

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

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

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

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

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

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

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

Мониторю всяческие новости про 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

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

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

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

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

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