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

lexa - 08/Сен/2011 09:32

Читаю новость: 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% рынка? Что, уже все так плохо? А по серверам как?

Comments

maxim_milakov (not verified) - 08/Сен/2011 09:52

Я вот думаю, что тут расчет у AMD простой: Матрицы перемножать в больших количествах - это на ускорителях (скоро уже и 7xxx серия подоспеет с 2,000 ядрами). А SQL-серверу, web-серверу FPU (практически) не нужен. В последнем абзаце статьи по ссылке об этом как раз упоминается.

lexa - 08/Сен/2011 10:07

Оно как бы и да и нет, в смысле ускорителей. Матрицы перемножать - да, два GPU 6-тысячной серии раз в 6-7 быстрее, чем два 12-ядерных оптерона. И дешевле раза в четыре (6990 - 25k, оптерон 6176 - 45k, если я ничего не перепутал).
Но на эти два GPU - надо 6 ядер на I/O, четырех мало.

А как только начинаются ветвления, так сразу все не так однозначно.
Да и там где однозначно - может оказаться, что реализаций просто нет. Вот скажем для линпака - dgemm для Multi-GPU есть, а dtrsm - я нашел только single-GPU.

maxim_milakov (not verified) - 08/Сен/2011 10:12

> Но на эти два GPU - надо 6 ядер на I/O, четырех мало.

Пусть так. Но этим ядрам не особо то и нужны FPU, верно?

lexa - 08/Сен/2011 10:18

Ну так я о том и пишу там выше - для гибридной конструкции бульдозер получается примерно в самый раз.
Но имеющийся софт, который задачи по ядрам распределяет "как-то", придется допиливать.

maxim_milakov (not verified) - 08/Сен/2011 10:24

А, ага.

Да, софт придется делать, это не вопрос. Именно придется, потому что гетерогенные архитектуры - это неизбежное ближайшее будущее, да и настоящее уже, что уж там.

maxim_milakov (not verified) - 08/Сен/2011 10:35

А по вопросу:

Из новости на ФЦентре: "По сведению аналитиков компании IDC, доля AMD на рынке процессоров для серверов снизилась со второго квартала 2006 года с 25,9 % до 5,5 % во втором квартале 2011 года".

lexa - 08/Сен/2011 10:42

Но, кстати, конструкция Бульдозер+GPU в одном флаконе (т.е. APU, как они их называют) - для вычислений опять несбалансирована, потому что на I/O ничего тратить не надо.
Ну да она и для недорогих десктопов, с другой стороны.

maxim_milakov (not verified) - 08/Сен/2011 10:54

APU архитектура сбалансирована только для слабых интегрированных GPU. Потому как более мощным GPU будет не хватать пропускной способности глобальной памяти, которая, в случае интеграции GPU и CPU - это обычная RAM. Вон, в 7xxx серии будет память XDR2 с 256-битной шиной с пропускной способностью под 300 ГБ/с. Такой пропускной способности у обычной RAM (DDR3) нет.

lexa - 08/Сен/2011 11:10

Да, все так, но не все так плохо :)

Для алгоритмов, у которых отношение flops/memory небольшое и не растет с размером задачи - вы для внешних GPU окажетесь ограничены PCIe bandwidth. А для внутренних - memory bandwidth (которая в разы больше).

А если flops/mem растет с размером локального блока вычислений (как для dgemm, к примеру), то нагрузка на память уменьшается путем увеличения local/shared mem, что относительно недорого для производителей GPU/APU.

maxim_milakov (not verified) - 08/Сен/2011 11:18

Согласен почти со всем. Не согласен с последним. Локальная память/L1 - это дорого. В сумме сейчас в районе 64КБ на один compute unit. Думаете, если бы у производителей была возможность ее увеличить сравнительно недорого, они бы этого не сделали?

lexa - 08/Сен/2011 11:30

Ну "относительно" же.

8800GTX - 16kb shared, 32kb регистров (8k по 4 байта) на SM, всего 48kb быстрой памяти.
Fermi: 48k shared, 16k L1, 128k регистров. Всего 192kb на SM.

Да, SM тоже подрос, поэтому оно не учетверилось в расчете на единицу SIMD, а удвоилось. С точки зрения блочных алгоритмов - часть утроилась (shared), а часть - удвоилась (регистры).

Это за 4 года, с 2006 по 2010.

maxim_milakov (not verified) - 08/Сен/2011 11:40

Если сравнивать различные поколения ускорителей, то да, объем быстрой памяти на один вычислительный блок растет. Но что с того? В 2 раза за 4 года - это не так уж и много.

Ну и вот еще что, вернусь к одной Вашей фразе несколькими комментариями выше:

> Для алгоритмов, у которых отношение flops/memory небольшое и не растет с размером задачи - вы для внешних GPU окажетесь ограничены PCIe bandwidth

Это верно лишь в случае, если данные для работы ядра необходимо передать из хоста в устройство. Что совершенно не обязательно.

lexa - 08/Сен/2011 12:12

Два раза - это два раза. Для блочного gemm - это два раза по flops/mem.

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

Случай же, когда мы несколько kernels пускаем на одних данных - он неинтересный с точки зрения общей теории всего. Объедините эти ядра в одно, пусть в уме, и у вас опять будут три возможных случая
- flops/bytes растут с увеличением размера данных. Ура, надо просто задачу побольше
- flops/bytes константа. Караул, надо "усложнять алгоритм" (переносить больше стадий на GPU), чтобы появился смысл.
- данных пренебрежимо мало (подбор паролей, например). Опять ура.

Второй случай типичен для всякой мультимедии, чем и нехорош.

_slw (not verified) - 08/Сен/2011 12:01

а зачем нужно столько ядер на выгребание? у линуха ведь есть расштрения всякие типа zero copy.

lexa - 08/Сен/2011 12:44

Ну если интересуют подробности, то там жизнь устроена так (насколько я прочитал чужой исходник и дискуссию вокруг него):

Как бы хотелось:
- смэпили память GPU в адресное пространство
- и оттуда читаем очередную порцию данных, которая там образуется.

Но
- эта память приходится размэпливать (по дурости ATI) при каждом вызове вычислителя.
- когда ее мэпишь заново, каждую страничку там pagefault, что сильно мешает жить. И один thread не успевает с такой частотой PF.

Существуют хаки (бинарные) для драйверов 10.9 и 10.10, которые позволяют не размэпливать каждый раз, но эти драйвера, к сожалению, не работают с HD6xxx. В теории, хак для 10.10 работает с драйверами 11.2, но оный 11.2 с 6990 работает плохо (а формально - и не поддерживает).

Короче, все от дурости.