Свежие комментарии

ох уж эти benchmarks и их цифры, Wikipedia показывает
( теор. скорее всего ) :

Tahiti XT2

GFLOPS (Single-precision) : 4300
GFLOPS (Double-precision) : 1075

http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units...

Не, ну конечно на GPU сложнее, о чем я и пишу.

Вместе с этим - есть проблема. Допустим, мы пишем программу для end-user и какое у него GPU - не знаем. Если мы при этом еще и под конкретные архитектуры (обе, хотя на самом деле, наверное, десяток) не оптимизируем, то разброс по относительной (относительно пиковой/теоретический) производительности будет чудовищным.

И это, собственно, и есть проблема. "Производительность не переносится"

более-менее честный тест на CPU, например HPL, делается примерно так: есть некая реальная задача (СЛУ), она использует некие критические по производительности примитивы (FFT, BLAS), тогда берём лучшую реализацию этих примитивов под данный CPU, запускаем и сравниваем. получается относительно честно. по отдельности FFT, BLAS можно считать синтетическими тестами, но в случае их "реального" использования это уже достаточно практический benchmark.

есть ещё подход SPEC INT/FP с исходными текстами, но он работает только потому, что CPU и их компиляторы всё равно внутренне более-менее похожи. скажем, можно скомпилировать SPEC INT и для CUDA, но результат будет не показательным.

на GPGPU сложнее, аппаратно архитектуры GPU все сильно разные, некоторые реализуют свою API (CUDA), много важных технических ограничений (размеры кешей, буферов, регистры, возможности синхронизации).

А что, 2 млн транзисторов на приличное ядро - это уже совсем мало-мало? Например PPro - 5.5 млн, но там бог знает сколько на внешние интерфейсы, кэши и общесистемные невычислительные штуки (TLB, rings, поддержка 16-bit, что-то еще в количестве). В общем, по идее туда влезает не совсем уж простое вычислительное ядро.

Atomic syncro

Нормальной - не было в тот момент (середина 2011 и чуть позже).

Насколько я помню (но мог и перепутать), была ACML-GPU (плохо совместимая с жизнью) а вот APPML появилась позже и первое время с жизнью тоже была совместима не очень (а потом меня HPC на AMD интересовать перестало :)

Вот когда мы полтора года назад выжимали терафлопсы из AMD - там речь шла именно о специально написанной (не нами) реализации DGEMM для AMD. Которая CALDGEMM

Это, понятно, бодрые немцы, которые собрали суперкомпьютер на картах AMD. Либо по пьяной лавочке, либо AMD их спонсировало железом. Кем надо быть, чтобы сделать такое за деньги - я не представляю.

Не, ну а какой смысл в том что они делают, если вендоровый APPML сильно быстрее?

И еще вдогонку:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6...
(не стал скачивать статью, абстракта достаточно)

На трех 7970 добились небольшого превосходства над одним условным титаном. Т.е. электричество втрое, слоты - втрое, а перформанс на 20% выше в DP (чем анандтех намерял) и в ~1.6 в SP.

Когда вы эту экономику попытаетесь поскейлить даже на небольшой датацентр и выясните что вам нужно ~2x по стойкам и по питанию, разница в цене карт перестанет волновать совсем.

Да, я естественно видел эти варианты с 16 units.
Если недогружать карту (давать в SM меньше threads) - то производительность для большинства kernels будет хуже. Т.е. общее правило - прятать латентность в большом количестве threads.
Еще я увидел, что 64 units - это все на маке. Надо в хакинтош сунуть 480-ю (580-й у меня нет) и посмотреть.

Что же касается "вообще вычислений", то ситуация не столь проста, как кажется. Да, естественно, 6990 выигрывали у современной им Tesla M2070 в разы в гигафлопсах DP на доллар (практическими сравнениями 7970 с K20 я не занимался, а вот с предыдущим поколением - был грех). И на единицу карт тоже выигрывали: c одной 6990 в HPL можно было снять терафлопс в DP, а с M2070 - 500 или 600б не помню уже. Т.е. по цене терафлопса там разница была раз в 10 (или 6, не суть важно).

Но все эти рассуждения не учитывают существенных вещей:
а) технологичность. Теслы - с пассивным охлаждением, ставятся нормально в сервера по несколько штук, выпасание их освоено, включаешь и все работает. 6990 в реальной эксплуатации в многочасовых расчетах - перегреваются и или снижают частоту или просто виснут, много приколов.
б) драйвера (речь про Linux). Тесла просто работает. ATI нужно чтобы были запущены графические драйвера, чтобы на всех картах был бы какой-то виртуальный десктоп (а на винде - и подключенный монитор), это временами странно глючит.
в) Всякие странные хреновины, вроде GPU Direct (обмен данными карта-карта по сети Infiniband, вообще минуя CPU, все по PCIe). Понятно, нужно чтобы софт это умел, но если умеет, это многое облегчает.

г) Софт. Да, для OpenCL сейчас потихоньку начали писать, но вообще процентов 95 рассчетного - это CUDA.
И вот NVidia-библиотеки (и BLAS, и генератор случайных числел, и FFT, и, наверное, CuPP /не пробовал/ и Thrust) - можно брать и пользовать. У AMD с этим все гораздо печальнее: подвижки есть, но медленные. Это я про ситуацию лета-осени 2011, с тех пор с AMD плотно не работал.

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

На фоне перечисленного, разница в стоимости терафлопса, ну там 7970 стоит $400, а K20X - $5000 (а Титан - 1000) - вообще не играет роли. Если вы сами что-то разрабатываете. Потому что разница в цене одной карты, даже K20X против 7970, отбивается месяцем работы разработчика.

А если софт готовый и дописывать его не планируется - то надо его и бенчмаркать. Может оказаться, что там не 1.3-2 раза разница (как между Титаном и 7970 по анандтеху), а в 6 (потому что в пузе живет ViennaCL :)

Да ясно, что нужна команда. И минимум один интерфейсный ДИЗАЙНЕР. А то интерфейс сделанный професисональными программистами -- это же такой же мем, как озвучка игры профессиональными дизайнерами.

GeForce GTX 580 [64 units @ 1800MHz] по ссылке в базе luxmark бенчмарков это что-то странное. Если искать 580 поиском отдельно, то находятся результаты примерно 800-1000 для medium сцены, у них у всех 16 юнитов. Википедия тоже говорит что у 580 -- 16 SMов. Так что luxmark скорее под AMD "заточен", а этот результат скорее outlier, наверно неправильно записанный multigpu.

Про 680 на бенчмарк-сайтах устоялось мнение, что у него урезан compute сознательно, и поэтому он значительно хуже пред. версии. Чтобы продавать титан и теслу.

На luxmark у AMD растет производительность от драйвера к драйверу. На моем 7950 при смене 12.10 драйвера на 13.1, результат на medium sala подскочил с 1700 до 1900 с чем-то. Возможно AMD начали вводить "специализации" под отдельные бенчмарки, как они это делают для игр. На линуксе та же сцена дает почему то только 1200, что неприятно. В целом впечатление от драйверов AMD после длительного использования NVIDIA крайне негативное. NVIDIA может и гады что не дают нам compute и DP, но по крайней мере у них драйвер работает. Из OpenCl related, например, АMDшный драйвер при попытке скомпилировать рендерер blender cycles, драйвер съедает больше 8 гигабайт памяти, и много минут компилирует (не помню успешно или нет). На http://devgurus.amd.com много жалоб на мискомпиляцию, а поддержка линукс драйвера (в целом) просто ужасна. Алсо вот http://techreport.com/review/24218/a-driver-update-to-reduce-radeon-fram... , про то как без специализаций драйвера под игру, у AMD была большая неоднородность в времени рендеринга кадров, из-за несовершенства менеджера памяти, который был недостаточно переделан с предыдущих более простых vliw архитектур, и пока эти журналисты не подняли шум, пользователи играли в запинающиеся игры.

AMD и партнеры планируют развивать Heterogeneous System Achitecture с llvm-derived стандартом, для будущих APU в которых обещано сократить стоимость коммуникации акселератора с CPU. Но хочется чего-то вроде xeon phi,в качестве стандарта распараллеливаемых вычислений будущего, чтобы меньше зависеть от особенностей компилятора, проще предсказывать производительность (в теории).

не думал, что для обработки фоток требуются такие высокие технологии)

Ну раздумья - да, ломаются о маску.

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

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