О бульдозерах

Я редко анонсирую читаемые ссылки с веба (как бы, блин, автоматизировать выкладку закладок из 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, позволяющий это сказать....
Короче, бардак какой-то с этими бульдозерами, августовские анонсы оставляли лучшее впечатление.

Comments

http://www.guru3d.com/article/amd-fx-8150--8120-6100-and-4100-performanc...

в общем i7-980 рвёт топового бульдозера как тузик грелку

Ну меня серверные интересовали.

А там у AMD с 12-ю яйцдрами и так все было неплохо (Magny-Cours), и 16-яйцевые обещали интересное. Но оно какое-то сомнительное получается.

_было_ неплохо . Новые ядра медленные старых , Феномовских.
Так что новые серверные тоже будут... не очень.
Разве что АМД вдруг уценит все Оптероны новой линейки, на серверном поле хотя бы есть, куда те 8-16 тормозных ядер эффективно использовать.

В серверах буль должен как раз нормально себя показать (если сервер не для HPC). 16 потоков бульдозера в целочисленных задачах будут ощущаться как 16 ядер, а лимит в 2 IPC для PHP/Java кода всё равно недосягаем

его на большинстве задач 4х ядрёный Коре 2400-2500 обходит, какие там 6ти ядерники...

Почему бардак ?
Манагеры АМД поставили задачу - сделать побольше ядер и побольше частоту.
Ну, вот вам. Любой ценой ? Урезали ядра, стали они медленные, зато их много.
Сопроцессор ? перебьётесь.
А теперь бы как-то ускорить... вот вам огромный кэш, больше половины по площади от общей пл. кристалла.

>>А у нового - 4 юнита, но два из них целочисленные, а два - плавучка.

Судя по результатам тестов, на плавающей оно более-менее сравнимо с 4х ядрёным Коре.
Так что сопроцессор не такой уж и плохой, как основные горе-ядра, но их 4, а не 8 штук.

Ну да, может быть и манагеры.

В Арстехнике еще ссылаются на то, что раньше какие-то блоки руками разводили, а сейчас полный автомат, который на 20% хуже.

Смешно. Опять же - может, вместо игр с миллиардами денег на покупку Ати и потом на разделение компаний ( ++лярды затрат, ++директора и манагеры) надо было толковых инженеров покупать ?
Тут явно ущербный дизайн. Сделать ядра хуже предыдущих - это не ошибка, а изначально заложенные в проект идеи. И ничем, кроме как кардинально новым дизайном, это не исправить. А это минимум пара лет, даже если осознать и начать прямо сейчас.

Интел свою ошибку осознал где-то в 2003-05 гг. Сначала в мобильном сегменте (там Пню4 вообще было нечего ловить), а потом и в остальных.
В итоге с 2006г и по сей день каждая новая модель Коре лучше предыдущей по удельной производительности на Ггц и (почти всегда) на ватт.

Кстати, я в своем Коре выключил нафиг энергосбережение (с1-с6), потому как цепи питания еле слышно свистят при вкл-выкл ядер (у меня хороший слух, в тишине слышно.)
Риторический вопрос - можно ли такое сделать с Бульдозером (с его 120+Вт в нагрузке), и чтобы среднего скайс-карлсона на 800-900 оборотах всегда хватало ? А тут - хватает.

Из ATI получился APU, что само по себе - очень благородная идея. Хотя по дороге случился бардак с CTM-CAL/IL-а что будет в HD7xx вообще непонятно.

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

А кому на практике хорошо от этой благородной идеи ?
+полтинникк к цене процессора, который в итоге сам по себе медленный, и графика чуть лучше, чем у самых начальных видеокарт за тот же полтинник, но хуже, чем у карт за сотню. И ограничение тут принципиальное - скорость памяти.
Немного улучшить можно, догнать карты за 100-150уе - нет.

Да кто ж спорит, Оптероны ещё недавно были хороши. Кстати, все разы, что я пытался рассматривать их как вариант для покупаемого сервера, они пролетали с треском - предложение серверов с ними на рынке Украины очень скудное (манагерам АМД недосуг шевелиться).

>>программировать под него явно надо иначе,

А вот этим почти никто не будет заниматься. Именно потому, что нахрен не нужно.

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

А в той же памяти, да еще если Zero-copy - очень даже осмысленно.

Ну вот для A8-3800 прикидка по FP/single:
CPU: 4 core x 2.4 Ghz * 8 ops/clock = 76.8 Gflops
APU: 400 core x 0.6 Ghz * 1ops/clock = 240 Gflops
Понятно, что APU куда быстрее упрется в память, т.е. код должен иметь в районе 8 ops/байт, чтобы упереться именно в математику, ну да.

240Gflops - это, приблизительно, текущий 12-ядерный magny-cours на 2.33, 6180.

Т.е. потенциал у штуки есть, другой вопрос что оно пока недоделаное сильно, поддержки double нет, поддержка zero copy какая-то невнятная (или пресс-релиз про нее был невнятный), но к чему это дело применить - вполне есть.

> 400 core x 0.6 Ghz * 1ops/clock = 240 Gflops

А что всего 1 ops/clock? Обычно все-таки mad считают за 2. Так что 480 Gflops.

Ну, тем более. MAD редко где вылазит в полный рост (кроме GEMM), но формально - да.

Я, кстати, сильно сомневаюсь, что у интела в Ivy Bridge получится что-то близкое по флопсам.

Мне кажется это инженеры AMD сначала решили запилить наконец-таки HT, только лучше чем у Интела, а потом маркетологи решили обозвать каждый поток исполнения ядром.

я тоже разочарован и писал по этому поводу. думаю никакой большой идеи не было, просто хотелось как-то ответить на HT у Intel, чтобы догнать и перегнать по кол-ву потоков на процессор.
в десктопном сегменте это однозначно слив. многие однопоточные приложения будут работать хуже, чем на старых процах.
на серверах может будет и не хуже, особенно в случае каких-нибудь веб-серверов и БД, где всегда много потоков, крутятся Java, PHP, Apache и прочее, где FPU и SSE особо никому не нужны. для них может даже будет плюс относительно старых процессоров или HT от Intel.

FPU/SSE внезапно вылезает в memmove. Или в AES/CRC32. Не говоря о кодировании видео и многом тому подобном.
Даже сортировки SSE-ные есть и выигрыш там вполне ощутимый (2.5-3 раза на 4-way).

То есть грабля может ударить из совершенно неожиданного угла.

согласен. но не думаю, что для Java и PHP это всё актуально.

Так-то оно так, да вот загвоздка - Java (по факту) прекрасно себя чувствует на интелёвых многоядерниках с НТ.
И бороться новым Оптеронам, с 8-12-16 бульдозерными ядро-ковшами, прийдётся с отличными Ксеонами, которые , имея 8-12 (и более , в ближайшей перспективе) потоков, запросто их обходят.

не надо сравнивать HT с чесными x86 ядрами, которыми являются ядра Бульдозера.
>>с отличными Ксеонами, которые , имея 8-12 (и более , в ближайшей перспективе) потоков, запросто их обходят.
пока нет тестов, я бы не стал это утверждать.

сложно назвать эти обрезки " честными x86 ядрами"
А тк. в итоге ядра Интела с НТ быстрее на большинстве задач, вопрос, кто именно там честный, становится особенно пикантным.

ну посмотрите на сравнение с 6ти ядрёными i7 900-й серии , с 4х ядрёным i7-2600.

Они же поверх системных библиотек сидят. А библиотекам - актуально.

Идею они озвучили где то в 2005 году, потом озвучившему видимо зубы выбили, за болтливость, они сказали что несколько целочисленных ядер они оснастят несколькими спецпроцессорами (плавающий криптующий графический), процент использования гипертрейдинга 20% вот на пять ядер одного и хватит.

Вместе с тем, планировщик потоков должен еще знать, какие из threads жрут много FPU - чтобы раскидать по одному такому потоку на модуль. А откуда планировщику это знать? Должен быть какой-то API, позволяющий это сказать....

Внезапно...LWP!

Ну я про профайлинг думал, когда писал.

Но получается тоже как-то некрасиво. Вот допустим у меня есть два потока, в которых точечные вкрапления SSE-математики.
- Сначала их запускают на одном модуле, с целью экономии нагруженных модулей и поднятия частоты. Прекрасно.
- Потом доходит до математики, профайлер это считает и треды надо разносить по модулям.
- прощайте кэши?

В очень пессимистичном случае нужно заполнить все 2 МБ L2 кэша (16кб L1 можно пренебречь), тогда данные берём из L3 (задержка доступа 30 тактов); предположим что читаются они по 4 байта, и все чтения зависимые. Тогда нужно 2*1024*1024 / 4 * 30 тактов чтобы запонить L2. На FX 8120 (самом медленном по частоте из нынешних FX-ов) обычная (не Turbo Boost) частота составляет 3.1 ГГц, и т.о. заполнение кэша займёт 5 мс. Если планировщик перекидывает потоки не очень часто (скажем, раз в секунду), и выделение отдельного FPU каждому потоку ускоряет программу хотя бы 0.5% имеет смысл переносить поток на отдельный модуль.
Планировщик скорее всего будет учитывать не факт исполнения FPU/SIMD инструкций, а либо отношение количества исполненных FPU/SIMD инструкций к общему количеству исполненных инструкций, либо количество тактов, которые конвеер простаивал из-за загруженности общего кэша. Вообщем, это можно сделать очень эффективно.

Для долгоживущих тредов, по которым есть долгоживущая статистика - набор статистики, естественно, сработает.

Но я держу в голове другой паттерн: что-то вроде OpenMP или tbb, запуск нужного количества потоков в CPU-intensive местах, после чего возврат в однопоточный режим (или режим "один поток на обрабатываемый запрос/объект").

Типичное время жизни таких потоков - ну десять миллисекунд. Плюс-минус порядок, конечно.
И если их у меня было, скажем, 4 (по числу FPU), а выполняли их на двух модулях из четырех (оптимизируя частоту) - то я обижусь.

Ну, OpenMP может и сам треды раскидать по своему усмотрению

Ну да, но там нужна поддержка бульдозера, чтобы это было правильно.

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

Сохраняются - регистры. А кэши - "сами".

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

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

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

А вот у меня плата, через 9 лет, с двумя оптеронами подохла, теперь сижу на ноутбуке, жду бульдозеров, процессор у ноутбука раза в три быстрее, и памяти 6 гигов, а сам он работает раза в три медленнее, вот сижу и страдаю, а на старой машине и память меделенная и винты не ах. В общем это как газель против жигулей или даже феррари, как 6 кубов сороковки надо перевезти так и задумаешся. На ксеонах очень дорого получается и апгрэйт не возможен. Ну и в защиту АМД (хотя мне брэнды по барабану) 64 бит она заставила сделать, контроллер памяти она заставила сделать, за энегрго сбережение, ей спасибо, за нормальные шины котрые из процессора торчат тоже ей :-)

От AMD было много хорошего принесено.

Но конкретно бульдозеры - сомнительные какие-то.

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

я думаю к Бульдозеру будет правильно относиться не как к новой архитектуре, а как к Phenom2 + HT.
посмотрите http://www.ixbt.com/cpu/amd-fx-8150.shtml, здесь хорошо видно, что результаты Phenom2 980 vs FX-8150 хорошо коррелируют с результатами Intel i5 vs i7, там где HT даёт ускорение, FX-8150 тоже даёт ускорение, и наоборот.
в этом смысле, у FX-8150 получилась хорошая реализация HT.

Там еще остается непонятность с FPU.
Было - 3 универсальных юнита (x87, integer SSE, float SSE) на ядро.
Стало 2 целочисленных + 2 FPU юнита на "HT-процессор".

Т.е. задачи FPU-only или int-SSE-only должны заметно просесть, даже если нормировать не на число формальных ядер (2 на модуль), а на число модулей.

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

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

Куда делась объективность?

* Один FPU на два ALU мне изначально казались какой-то фиговой идеей
Два там FPU, присмотритесь внимательней.

* Идея AMD в том, что вместо SSE-операций надо переползать на APU
Это вообще взято с забора. Авторам статей ничего неизвестно про идеи AMD, как и нам с вами.

Четвертый пункт отпадает в виду пересмотра первого пункта.

От себя
* Процессоры от AMD всегда были лучше, если считать по соотношению единица производительности на один доллар стоимости.

Не буду спорить что топовые процессоры интелла производительней, но хотят за них больше $1000. И позволить их может 2% покупателей.

Я же вот беру арстехнику, там схема: на два ALU есть 2 MMX-модуля и 2 128-битных float.

Если считать это за "два FPU" (на два ALU), то в предыдущих оптеронах их было три (на один ALU). Собственно, вот цитата

Each K10 core had three 128-bit floating point units. These could perform x87 scalar floating point, 128-bit SSE vector floating point, 64-bit MMX vector integer, and 128-bit SSE vector integer operations. Bulldozer has four units in its floating point pipeline. Two are for integer operations (64-bit MMX and 128-bit SSE); the other two are for floating point. In addition to the scalar x87 and vector SSE instructions, the two floating point units can be ganged together, to perform new 256-bit Advanced Vector Extensions (AVX) floating point instructions. Given that this pipeline is now shared between two threads, it's a big reduction in per-thread execution resources.

Как это еще понимать то?

Add new comment