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

Вне всякого сомнения, идеи того же Волкова сильно выделяются на фоне остальной массы "докладчиков". Но это не потому что его идеи достойны восхищения абсолютно-объективно, а потому что в индустрии не так много людей, которые сочетают в себе понимание архитектуры устройств, критического мышления, базовых аналитических способностей, минимальной креативности (интересно, по каким причинам). У Волкова все это есть, вот на него и ссылаются как на гуру. Не подумайте, что я принижаю как то его заслуги, ни в коем случае. Но ориентироваться на него (и на авторов статьи о реализации SYMV в магме) как на абсолютных столпов в области - это прежде всего ограничивать самих себя.

Вот Вы можете сказать, в чем именно состоит новаторская идея в реализации SYMV в магме? Читать один элемент симметричной матрицы один раз, а не два? Хранить сравнительно небольшие промежуточные результаты в глобальной памяти и собирать их потом отдельным ядром? Организовать эту работу так, чтобы уложиться в давно усвоенные авторами ограничения аппаратной платформы?

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

Но ведь это не GEMM. Тут ведь необходимо приложить минимальные умственные усилия (удивительно, что люди пишут научные статьи на эту тему), чтобы начать таргетить (прошу прощения) теоретическую производительность. Но за ссылку на статью спасибо.

Два 12-ядерных AMD попались на пути.

Не знаю что такое mpstat, но может быть tuna поможет?
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.0/html/Realti...

Можно вроде kernelshark для этого приспособить...

Вот сорока принесла на хвосте свежую статью (4-й автор - Донгарра) про реализацию *SYMV в MAGMA 0.2/0.3

Никакой мультиплатформенности, ну кроме Fermi/не ферми, однако
"наша реализация SSYMV в 7 раз быстрее чем CUBLAS4 на GTX280 и в 4.5 раза быстрее на Тесле, наша DSYMV в 2 раза быстрее чем CUBLAS4 на тесле"

А ведь CUBLAS, по идее, тоже не левой ногой делалась, это вендорская библиотека для вендорского оборудования, если она будет неэффективной, то оборудования меньше купят.

А причем тут ставка рефинансирования, по ней разве кто-то занимает?

А зачем она тогда нужна?

Вроде бы уже как почта россии пролобировала закон по которому единственное ограничение не больше чем на 40000р посылок в месяц, а однотипного товара сколько хотите, хотя на практике не проверял.

Из общих соображений имею возразить следущее:
1) *GEMM (и matrix multiplication) достаточно просто устроен: как правило bandwidth limited и секрет успеха - это побольше насосать в блок, чтобы за 2*K^2 чтений сделать K^3 операций (K - размер блока, считая его квадратным)
2) Блок может быть в local storage, в регистрах и (для GPU) в текстурном кэше.
3) Из параметров этой быстрой памяти нам доступен размер local storage. Ни количество регистров, ни размеры (и свойства) кэшей - не известны. А для local (shared в терминах NVidia) мы кроме размера не можем узнать другие важные свойства (такие как конфликты банков через 16 /или через 32 для Fermi/)

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

Возможно, что вышеуказанные соображения существенны, когда мы хотим шагнуть далеко за 50% от теоретического peak.

Правда вот сегодня я весь день мучал поминавшийся выше CALDGEMM на 6990 (который вовсе даже не OpenCL, а даже немножко тюнился под HD6xxx, хотя основная платфрма у авторов - HD5870) и получил 62% от теоретического пика на одном GPU и чуть больше 50% на четырех GPU (2x 6990).

Вот тут интервью австралийской фирмы Euclideon, которые смогли на современном уровне сделать воксельную графику, которую лет 10 назад похоронили. Вам подробности не попадались?

Если генерировать код "под размер" (и под особенности архитектуры, скажем "тут - на регистрах, а в этой архитектуре - на LDS"), что OpenCL позволяет, то ситуация сильно лучше.
Но это тот самый подход, который я назвал "много ifdef"

А acml-gpu - ну да, ~220 GFLOP/s на 8k-матрицах (double) при том что peak - 550 или около того.
Только там дело не столько в самом коде GPU, сколько в обвязке (асинхронный трансфер, оптимальный merge результатов на CPU, прибавление 3-го аргумента тоже на CPU т.к. это линейная от данных операция и можно ее сделать прямо при трансфере). Если судить по CALDGEMM, который я не весь понял, но хотя бы частично прочитал.

ну, естественно на него же. со своими в ауле за жизнь поразговаривать:)

Я не думаю что так быстро, все-таки оно как-то распространено.

Мое предсказание: только с полной сменой архитектуры, так что CAL придется эмулировать и оттого станет медленно.

Библиотеку, в которой такой default size для тайла, явно писали какие-то люди из музея вымерших цивилизаций.

Этот музей называется Rhythm & Hues :)