«Идеальный» компьютер, или кое-что о Hammer…


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

Часть первая: мечты, мечты…

Как известно, вопрос «AMD или Intel» в какой-то мере перестал быть техническим и превратился в религиозный. Фанатики того или иного решения уже давно не обращают внимания на тесты (в самом деле, легко найти показательные примеры как в одну, так и в другую сторону). Собственно, причина этому одна — прошли те времена, когда архитектура на рынке х86 была одна — в данный момент и одна, и другая фирма все дальше удаляются друг от друга в своих разработках. С одной стороны — это хорошо, ибо позволяет получить более разнообразные (и более подходящие для конкретных задач) архитектуры. С другой — дезориентирует покупателей, которым все чаще приходится либо «верить на слово» продавцам, либо тратить большое количество времени на самостоятельную работу с информацией… Не говоря уже о том, что теперь нет однозначного ответа на вопрос всех времен и народов: «Кто же быстрее?». Все почему-то зависит от выбора задач для тестирования… Нет, такая ситуация никого не устраивает. Поэтому было бы неплохо разработать сугубо теоретический «идеальный процессор». Давайте попытаемся представить себе, каким он должен быть…

Для начала оговоримся — вряд ли имеет смысл увеличивать производительность процессора, не трогая всех остальных частей. Поэтому есть прямой смысл попробовать подумать обо всех важных компонентах компьютера. Таким образом, вопрос об «идеальном процессоре» плавно трансформируется в вопрос об «идеальном компьютере». Однако, по порядку. Итак, любой компьютер состоит из нескольких подсистем, влияющих на производительность. Среди важнейших — производительность ядра, подсистемы ввода-вывода, памяти. Давайте по очереди их и рассматривать.

Подсистемы ввода-вывода

Тут надо будет припомнить, какие варианты есть у нас. Их не так много — это PCI (например, в модификации PCI-X). Это HyperTransport и 3GIO. Собственно, это и все — поскольку других шин в ближайшем будущем вроде не предвидится. Что можно сказать по каждому из них?

  1. PCI-X хороша своей обратной совместимостью (хотя и ограниченной) с PCI. Это сильно упрощает жизнь разработчикам устройств. Однако есть другая сторона такой совместимости и относительно высокой скорости — малое количество поддерживаемых одновременно устройств. К тому же, при увеличении количества плат расширения падает скорость. Еще одна потенциальная проблема связана с тем, что расти в будущем этой шине некуда. А на сегодня скорости порядка гигабайта в секунду уже не выглядят чем-то сверхъестественным.
  2. Следующая шина — 3GIO (расшифровывается как third generation input/output — третье поколение систем ввода-вывода). В общем, про нее рано пока говорить, поскольку в железе она, в отличие от двух других конкурентов, не воплощена. Ключевые особенности — сравнительно малое число контактов и высокая эффективность передачи информации по ним. Шина по сути последовательная. Intel (один из активных участников консорциума, работающего над новой шиной) называет цифры порядка 10 Гбит/секунду для первого поколения этой архитектуры.
  3. HyperTransport. Ранее известна как LDT — lighting data transport (в смысле транспорт со скоростью света). На сегодняшний момент реально воплощенная в железе, хорошо масштабируемая (от 800 МБ/сек до 6,4 ГБ/сек) шина, в основе своей много взявшая от EV6. Разработана AMD. Ее преимущества очевидны — достаточная для шины первого поколения скорость (в ближайшем будущем пропускной способности 6,4 ГБ/сек будет достаточно), небольшие задержки, сравнительно простая реализация в железе, относительно небольшое (хотя и большее, нежели в 3GIO) количество контактов. Шина представляет из себя двунаправленную (т. е. 800 МБ/сек — это 400 в одну и 400 в другую сторону) магистраль точка-точка. Есть перспективы развития (слухи о HyperTransport II уже проскальзывали).

Фактически, выбор остается между пунктами 2 и 3, поскольку связывать себе руки устаревшей шиной PCI (пусть и в самой быстрой модификации) не имеет смысла. А из этих двух «вживую» есть только одна — таким образом, и выбора, собственно, не остается. На сегодняшний день стоит выбрать HyperTransport, тем более, что явных недостатков у него не видно… Важный вопрос — куда именно присоединять эту шину. Можно традиционно — к северному мосту чипсета. А можно присоединить к процессору (благо, HyperTransport нуждается в относительно небольшом количестве контактов) — в этом случае количество транзисторов увеличивается в процентном отношении ненамного — по сравнению с ранее имевшимся количеством. А скорость обработки информации возрастет — поскольку, во-первых, информация будет попадать именно туда, где она обрабатывается, а во-вторых — интеграция контроллера HyperTransport в процессор снимает все ограничения по необходимой его скорости. Ибо процессор — самое высокочастотное устройство современного компьютера. Таким образом, второй вариант, хоть и необычен — гарантирует более скоростную и своевременную обработку информации.

Еще одно соображение состоит в том, чтобы, по возможности, сделать несколько независимых шин — например, для периферии (в частности, контроллера PCI — ведь неразумно отказываться от огромного числа плат расширения) одна, а для AGP — другая… Зачем им сидеть на одной шине, когда запросы этих компонент кардинально отличаются? Так что наш идеальный процессор должен иметь несколько независимых шин — в данном случае HyperTransport. Одну для всевозможных PCI, «южных мостов» чипсетов, встроенного звука и прочего. А вторую — для AGP, которая уже сейчас жаждет 1,06 ГБ/сек, а в ближайшем будущем это число подрастет до 2,1 ГБ/сек (AGP 8x, введение которого не за горами). Если же мы попутно подумываем о многопроцессорных машинах, то нам просто необходима еще одна (как минимум) шина для организации связи между процессорами — либо напрямую, либо через специализированный коммутатор. В таком случае есть реальная возможность устроить на х86 действительно многопроцессорный (8 процессоров и более) сервер, в отличие от текущей ситуации (когда для 4-х процессоров используется общая (одна на всех) шина пропускной способностью 800 МБ/сек).

Однако три контроллера HyperTransport потребуют уже ощутимого количества контактов — насколько нам известно, один контроллер в самом скоростном варианте (6,4 ГБ/сек) требует 144 контакта. Правда, нам отнюдь не нужны все шины такой пропускной способности — для PCI32/33MHz и «южного» моста достаточно 800 МБ/сек, а вот для AGP наверняка будет достаточно (даже с запасом) 3.2 ГБ/сек. Для связи же процессоров друг с другом (либо с коммутатором) возьмем самый быстрый вариант. Естественно, контроллеры шины HyperTransport должны быть достаточно умными, чтобы при необходимости суметь выполнять другую работу. Например, в случае многопроцессорной машины смысл нескольких шин PCI очевиден, а вот несколько AGP понадобится вряд ли. Хотя, как вариант — интересно.

Если подытожить, то мы пришли к выводу, что наш «идеальный процессор» должен содержать как минимум три шины HyperTransport для того, чтобы подсистема ввода/вывода не отставала от процессора (хотя рано или поздно это все равно произойдет).

Теперь перейдем к рассмотрению второй составляющей — подсистемы памяти.

Подсистема памяти

Подсистема памяти на сегодняшний день — самая благодатная почва для спекуляций и предположений. Всем участникам этих спекуляций ясно только одно — обычной SDRAM уже недостаточно для современных процессоров, как к этому ни относись. На сегодняшний момент сосуществуют несколько технологий памяти — SDRAM, DDR SDRAM, DR DRAM (Rambus). Однако вопрос о том, какой тип памяти выживет в ближайшем будущем, можно считать решенным — выпуском набора микросхем 845D Intel однозначно проголосовала за DDR SDRAM — слегка модифицированные микросхемы памяти, способные выдавать данные в два раза быстрее предыдущего поколения (на той же частоте). Хотя, в свете сегодняшних цен — еще неизвестно, кто выиграет… Собственно, если оценивать теоретически, то есть несколько характеристик, от которых зависит производительность памяти. Это:

  1. Теоретическая пропускная способность. В настоящий момент для SDRAM это 1064МБ/сек. Для DDR SDRAM это 2100МБ/сек (для 266(133)МГц памяти) или 2700МБ/сек (для 333(166)МГц памяти). Для DR DRAM это 1600МБ/сек для памяти типа РС800 (один 16-битный 400МГц канал).
  2. Задержки (Latency). Достаточно сложная тема — естественно, идеальная память должна выдавать данные с минимальными задержками. Однако для разных типов памяти эти задержки разные… Минимальны они для SDRAM, чуть больше для DDR SDRAM, а самые большие задержки у DR DRAM (имеются ввиду задержки произвольного доступа). Это один из фактов, объясняющих, почему, невзирая на максимальную скорость передачи информации, двухканальная Rambus с пропускной способностью 3,2 ГБ/сек (2 канала по 1,6 ГБ/сек каждый) мало отличается по результатам скорости в реальных приложениях от DDR SDRAM (на том же Pentium 4), при том, что пропускная способность у последней в полтора раза меньше.
  3. Эффективность использования. Другими словами, это показатель того, какую часть теоретической пропускной способности мы сумеем задействовать в «жизни». Например, для SDRAM максимальная эффективность (под эффективностью здесь мы понимаем пропускную способность, демонстрируемую практически реализованными решениями — она отличается от эффективности работы интерфейса, для Rambus составляющей порядка 98%) составляет порядка 60%, для DDR SDRAM — порядка 75%, а для Rambus порядка 85%. Все цифры приведены в пике последовательной пакетной передачи. Другими словами, трудно рассчитывать на SDRAM больше, чем на 600МБ/сек. Для DDR SDRAM эта цифра порядка 1700МБ/сек, для Rambus — порядка 2700МБ/сек (для 2-х каналов). Для повышения эффективности использования памяти активно применяются различные ухищрения, например, глубокая буферизация, interleave, и прочее.

Однако, как уже было написано, наиболее перспективной (частично по техническим, а частично по финансовым соображениям) на сегодня и завтра признана технология DDR SDRAM. Таким образом, выбор невелик — наш «идеальный компьютер» использует именно этот тип памяти. Однако, надо подумать, что возможно сделать для улучшения ситуации — ведь не секрет, что многие приложения (например, видеокодирование или научные расчеты) сильно зависят от скорости памяти (кроме всего прочего). Вариантов несколько — например, сделать несколько каналов памяти. Скажем, два. Однако это сильно подымет сложность создания и стоимость материнской платы, на которой придется разводить 128-битную шину памяти к чипсету, а затем еще думать, как эти данные доставить к процессору. Ведь первый контроллер HyperTransport у нас занят PCI и прочими устройствами, второй — шиной AGP. Третий мы планировали оставить для межпроцессорных соединений… Мда… Лепить на процессор четвертый? Перебор получается… Соединить чипсет с третьим? Не очень хорошее решение — даже в лучшем случае в каждом направлении HyperTransport прокачает только 3,2 ГБ/сек, а у нас четыре. 2 ГБ/сек при 2-х каналах памяти PC2100, и еще 1.06 или 2.1ГБ/сек для AGP. Не пройдет это по одному каналу… Собственно, текущего HyperTransport даже на одну память не хватает. Надо что-то побыстрее, чтобы доставить данные из памяти в чипсет, а из чипс… СТОП! А зачем нам данные в чипсете? Они ведь нам в процессоре нужны… К тому же, мы все периферию именно с процессором соединили… А если память присоединить к процессору?! Забавно получается…

В процессоре нужен контроллер памяти (это его усложняет), к тому же, контактов побольше надо — это минус. Есть и плюсы — теперь контроллер памяти сможет работать с максимально возможной скоростью и минимальными задержками, поскольку работает на скорости процессора. К тому же, теперь скорость работы с памятью будет зависеть (частично) от скорости процессора (и, естественно, от частоты работы самой памяти), а не от чипсетов третьих фирм, создающих то более, то менее удачные продукты. А на долю строителей чипсетов можно отвести разработку мостов HyperTransport-PCI, HyperTransport-IDE, HyperTransport-AGP, и прочих менее критичных устройств. И еще следствие — с ростом частоты процессора скорость работы с памятью должна расти, хоть и не пропорционально скорости. Естественно, рано или поздно она выйдет на насыщение, но пока современные процессора 4,2 ГБ/сек «переварить» не успевают. Еще плюс — теперь память будет «поближе» к процессору, это позволит поднять частоту ее работы (например, до 166 МГц). А это дает уже 5,4 ГБ/сек (теоретических), что уже вполне красиво. Еще следствие: теперь понятие FSB (front side bus) попросту теряет смысл, ибо больше нет общей шины, соединяющей процессор и чипсет с памятью. Каждое периферийное устройство присоединено либо к шине PCI, либо к HyperTransport. Собственно, и чипсет как таковой не нужен — нужны несколько гораздо более простых мостов. Интересно…

Подытожим: в процессе конструирования «идеального процессора» наиболее предпочтительным местом для контроллера памяти оказался главный потребитель данных — сам процессор. Только это гарантирует своевременную доставку данных без дополнительных задержек. Собственно, контроллер может быть одно- или двухканальным (он может быть и 4-канальным, но разводить его будет крайне сложно и дорого). К тому же, частота работы памяти нигде особо не оговаривалась — появится 166 МГц память — можно ее. Начнут производить 200 МГц — несложно и такую. Если сделать его программируемым — то можно даже в произвольный момент времени менять частоту памяти (например, для уменьшения нагрева). Вроде неплохо получилось…

Ядро процессора

И, наконец, перейдем к наиболее спорной части — ядру процессора. По части доставки данных у нас все в порядке — все узкие места современных компьютеров мы расширили. Осталось выбрать «идеальное» ядро, которое сможет эти данные переварить. Попробуем сформулировать необходимые свойства этого ядра:

  1. Оно должно быть достаточно универсальным и показывать хорошие скоростные характеристики с программами любого типа. То есть, и целочисленная часть, и х87 должны быть достаточно быстрыми, чтобы выводить это ядро в лидеры среди соперников.
  2. Оно должно содержать все наиболее распространенные расширения х86, включая те, которые могут понадобиться в ближайшем времени.
  3. По возможности, это ядро должно иметь относительно небольшие размеры, чтобы стоимость его производства была невелика.
  4. Естественно, крайне желательно, чтобы данное устройство не нуждалось в специфических средствах для охлаждения, и было достаточно прочным, дабы не иметь механических проблем при установке. (Камень в огород AMD).
  5. Желательно, чтобы наше ядро имело хорошие перспективы развития, в том числе по частоте.

Собственно, давайте попробуем выбрать отвечающее нашим требованиям ядро. Вариантов не так уж много — это Pentium III «Tualatin», Pentium 4 «Northwood» , Athlon XP. Именно эти процессоры имеют максимальное быстродействие. И именно из них попробуем выбрать самого достойного представителя. По поводу Pentium III «Tualatin» соображения следующие:

  1. В целочисленной части — достаточно производителен. В основном заслуга принадлежит сравнительно большому кэшу и высокой скорости работы с ним, тогда как по вычислительной мощности уступает Athlon XP. Причем, как в целочисленной части, так и в х87, где Athlon XP — абсолютный лидер.
  2. Поддерживает только SSE. Не поддерживает SSE2, 3Dnow!, Enhanced 3DNow. По этому пункту проигрывает остальным конкурентам.
  3. Здесь все вполне нормально — хотя точный размер кристалла нам не попадался, он находится в районе 100 мм2.
  4. Все в порядке — термодатчик не позволит повредить процессор перегревом. Для прочности ядро защищено металлической пластиной.
  5. Немаловажный момент — мало иметь хороший процессор. Важно еще вовремя «кормить» его данными. В этой части ничего замечательного данный процессор не демонстрирует. Из трех конкурентов у него минимальная скорость процессорной шины.

    Здесь все плохо — Intel прекращает использование этого ядра на рынке (по необходимости оставляя его только на серверах и рынке Low-end). Таким образом, особых перспектив нет.

Следующий кандидат — Pentium 4 «Northwood». Рассмотрим его поподробнее:

  1. С производительностью ситуация странная — из-за определенных особенностей ядра (очень длинный конвейер) в одних программах показывает очень высокие, в других — очень низкие результаты, иногда проигрывая предыдущему поколению, имеющего гораздо более низкую частоту. Ситуация несколько сглаживается большим (и самым быстрым на сегодня) кэшем, но в целом — результаты очень неровные. На сегодняшний день для максимальной производительности нуждается в перекомпиляции программ. В х87 — попросту аутсайдер. Единственное преимущество заключается в наборе команд SSE2, при использовании которых становится лидером (программы при этом требуют перекомпиляции и оптимизации) в скорости FPU.
  2. Поддерживает только SSE и SSE2. Не поддерживает 3DNow!, Enhanced 3DNow.
  3. Даже при использовании 0.13 микронной технологии ядро великовато — 145 мм2. Это довольно много для современных процессоров.
  4. Лучшая на современном рынке технология термоконтроля — в данном вопросе абсолютный лидер среди конкурентов. Для прочности ядро защищено металлической пластиной.
  5. Скорость процессорной шины максимальна на сегодняшний момент — 3,2 ГБ/сек.

    Здесь все в порядке — компания Intel демонстрировала данный процессор на частоте 3 ГГц, и, судя по всему, потолок этой архитектуры еще выше.

И, наконец, последний соискатель — Athlon XP. Рассмотрим и его:

  1. В большинстве случаев лидер по производительности. Этому способствуют как самый производительный FPU, так и три целочисленных конвейера, неустанно перемалывающих данные. В отдельных случаях проигрывает конкурентам, в основном из-за менее скоростного кэша второго уровня, к тому же, обладает меньшим его количеством. В общем, его можно признать лидером по скорости, с небольшими оговорками.
  2. Поддерживаются все наборы расширений, кроме SSE2.
  3. По технологии 0,18 микрон имеет размер 129 мм2. При переходе на 0,13 микрон площадь уменьшится ориентировочно до 89 мм2.
  4. Термодатчик для использования требует специального дизайна материнских плат. Прочность ядра неудовлетворительна.
  5. Находится посередине по пропускной способности шины — 2,1 ГБ/сек. На сегодняшний момент неплохо, однако, при возможности стоит расширить.

    Перспективы недостаточно ясны, но, судя по всему, до 2,5 ГГц ядро (по 0,13 микрон) доживет. Способны помешать этому в основном трудности технологического или финансового плана.

Однако… Ни одно из имеющихся решений на рынке не удовлетворяет всем пунктам наших требований. Что делать? Не снижать же требования! Ну что ж, припомним, что это всего лишь мечты — и попытаемся собрать из кусочков «идеальный» процессор. Итак, за основу имеет смысл взять Athlon XP — у него максимальная (в большинстве случаев) скорость на единицу частоты. Только проделаем над ним несколько операций, а именно:

  1. Для того, чтобы увеличить скорость процессора в целочисленных операциях — увеличим объем кэша второго уровня, его скорость (каким-либо аналогом Advanced Transfer Cache — например, расширим шину кэша до 256 бит и уменьшим задержки). Кроме этого, необходимо добавить поддержку полезного во многих областях SSE2 — это позволит перейти со временем от «доставшегося в наследство» слегка уродливого х87 к RISC-оподобному FPU, основанному на SSE2 командах. Сопроцессор можно не трогать, тем более, что особого выигрыша от переделки ожидать не стоит. В самом деле, припомним: несмотря на то, что в Athlon XP фактически вдвое больше исполнительных блоков FPU (2 FPU/SSE/3DNow + 1 Load/Store Unit против 1 FPU/SSE + 1 Load/Store у Pentium III), выигрыш редко превышает 30% (при равной частоте). Таким образом, прямое наращивание «математических мускулов» особого смысла, на наш взгляд, не имеет. Собственно, можно слегка косметически подправить еще ряд блоков. Например, увеличить размер BPU (таблицы истории переходов) и т. д. Благодаря всему этому получившийся гибрид будет непревзойден никаким процессором х86 архитектуры.
  2. Перерабатываем упаковку процессора и его термоконтроль таким образом, чтобы приблизиться к лидеру в этом вопросе — Pentium 4. Тогда этот процессор можно будет рекомендовать для всех уровней покупателей.
  3. Возможно, придется внести косметические изменения в конвейер (однако, не удлиняя его сверх меры), чтобы процессор имел запас роста по тактовой частоте.
  4. Надо бы расширить шину ввода/вывода данных — помешать это не может, а помочь — способно.

Уфф! Наконец-то! Мы сформулировали для себя требования к идеальному процессору, и теперь можем оглянуться. У нас есть быстрая и перспективная система ввода/вывода, есть быстрая память с минимальными задержками и есть великолепный быстрый процессор. Перечислим подряд все ключевые пункты:

  1. Процессор на основе Athlon XP с увеличенным и ускоренным кэшем, а также поддержкой SSE2. Возможно, придется слегка видоизменить и удлинить конвейер.
  2. Интегрированные в процессор контроллеры HyperTransport (в процессорах начального уровня — один или два, в более высокоуровневых — три и более).
  3. Память со встроенным в процессор (для уменьшения задержек) контроллером. При этом, по видимому, имеет смысл в младших процессорах сделать 64-битовую шину памяти, а в старших — 128-бит и более. Тем самым попутно мы сильно увеличиваем скорость обмена с памятью, что должно благотворно сказаться на показателях скорости системы (например, в SPEC_int2000 и SPEC_fp2000).
  4. В связи с дополнительными контроллерами HyperTransport внутри процессора, есть возможность строить многопроцессорные системы, с числом процессоров 4 и более — и при этом не снижать скорость и масштабируемость системы общей шиной, как в нынешних 4-х процессорных системах. Собственно, уровень производительности на такой системе должен быть беспрецедентным для рынка х86.

(Однако, есть впечатление, что интеграция всего вышеперечисленного сделает пункт о небольшой стоимости такого процессора по меньшей мере спорным — примечания автора)

Ну что ж, сформулированное самим себе задание благополучно выполнено. Свои мечты мы сформулировали. Но перечитывая их, не получается избавиться от чувства deja vu — где-то что-то очень похожее уже встречалось… Точно! Hammer!!! Представленная недавно новая парадигма от AMD очень напоминает сформулированную нами идеальную платформу — возможно, они рассуждали похожим образом?! Что ж, великолепный повод перемыть косточки потенциальному хиту от AMD. Только теперь мы будем глядеть на него не только восхищенным, но и критическим взглядом, попутно оценивая — а насколько он удовлетворяет требованиям к идеальному процессору?

Часть вторая: Что год грядущий нам готовит?

Для начала попробуем воспользоваться официальной информацией от AMD — презентацией архитектуры Hammer на Микропроцессорном Форуме в 2000-м году. О ключевых особенностях этого процессора, и о том, что это может ему дать — мы говорили в первой части. Теперь давайте взглянем на это изделие в презентации: http://www.platformconference.com/AMD-Hammer.pdf

Hammer как продукт имеет две особенности. И, если аппаратное решение по большей части логично и предсказуемо, в программной AMD приготовила изрядный сюрприз. Hammer поддерживает новое расширение архитектуры х86 — х86-64. Как нетрудно догадаться по названию, это расширение адресного пространства и операндов, сравнимое с переходом с 286-го на 386-ой. Когда-то такую операцию индустрия под чутким руководством Intel достаточно безболезненно проделала (в основном по причине большей производительности даже в «старых» кодах) — посмотрим, как это получится у AMD. Но позвольте, — скажет начитанный читатель, — на рынке уже есть 64-битная архитектура от Intel. Как же называть Itanium? Есть-то она есть, да только вот х86 там и не пахнет — режим совместимости с х86, хотя и присутствует формально, имеет крайне низкую скорость. Но самое неприятное не в этом — с низкой скоростью можно было бы примириться. Совместное исполнение х86 кодов и 64-разрядных команд Itanium приводит к падению производительности на порядки. Если немного утрировать — один единственный 32-битовый драйвер мыши способен превратить скоростной процессор (во многих областях перегнавший конкурентов из Sun, Compaq, HP) в дорогостоящий тормоз. Причина, в общем-то, понятна — Intel всеми силами пытается забыть х86 на рынке высокопроизводительных вычислений. Вот только вопрос — согласится ли на это остальная индустрия…

С этой точки зрения решение AMD гораздо менее революционно — просто введено еще одно расширение хоть и не лучшей, но, без сомнений, самой распространенной архитектуры. Собственно, это решение назрело давно — у многих пользователей потребности давно переросли куцые ограничения х86. Чего, например, стоят ограничения (адресуемого) объема оперативной памяти в 4 ГБ (при помощи специальных, но дорогих в смысле производительности методов отодвигаемые до 64 ГБ)? И это при том, что многие базы данных уже давно переросли не только 4, но и 64 ГБ? А если нет возможности поместить всю базу в оперативную память — нет возможности обрабатывать ее с приемлемой скоростью. Поэтому решение от AMD позволяет обойтись без дорогостоящего перехода на новую систему команд — необходимо сделать лишь минимальные правки в относительно небольшом количестве мест, чтобы воспользоваться преимуществами расширенного адресного пространства. А 32-разрядные программы вообще не нуждаются ни в какой адаптации и работают абсолютно прозрачно. Для них Hammer — обычный процессор х86.

К этой бочке меда, однако, надо добавить ложку реальной ситуации. А она такова — к сожалению, наборы IA64 от Intel и x86-64 от AMD несовместимы друг с другом. А посему только рынок рассудит, кто же из них выживет. С этой точки зрения, для AMD крайне важно, чтобы процессор получился бы быстрым как в 32-, так и в 64-битовом режиме. Это необходимо для того, чтобы даже при провале х86-64 (а мощь маркетинговой машины Intel мы с вами знаем) скоростные характеристики Hammer сделали AMD лидером по скорости на рынке х86-32. Только тогда AMD может рассчитывать на хорошие продажи своего продукта. Хотя, думается, в реальности все три архитектуры будут сосуществовать — подавляющее большинство пользователей, включая вашего покорного слугу, абсолютно не нуждается в ближайшем будущем в 64-х битах ни под каким соусом. Те пользователи, которые в силу финансовых, исторических, или иных причин привязаны к х86, но нуждаются в максимальной скорости — будут использовать х86-64. Те же пользователи, которые планируют свои задачи с нуля — будут присматриваться к Itanium. Кстати, эта ситуация будет подстегивать Intel — для того, чтобы оправдать заведомо более высокую цену системы на Itanium, корпорации придется демонстрировать непревзойденный уровень производительности. Что, учитывая великолепные «ходовые» качества конкурентов, будет крайне нелегко. Однако нам, пользователям, такая ситуация пойдет только на пользу.

Однако, со скоростными качествами Hammer все более или менее понятно — Pentium 4, если и сможет с ним конкурировать, то только за счет намного более высокой частоты. Гораздо интересней ситуация c многопроцессорными системами — архитектура Hammer смотрится в таких системах намного предпочтительней современных решений от Intel. Тому есть несколько причин:

  1. Первая (и, пожалуй, самая важная) — разные подходы, используемые AMD и Intel. Суть их в том, что, как и текущее решение на Athlon, AMD использует в многопроцессорных системах на Hammer соединение точка-точка. В отличие от этого, Intel остается приверженцем общей шины.
  2. Вторая — вытекающая из первой причины совершенно новая (для х86) архитектура многопроцессорных систем.

Однако об этом мы поговорим позднее, а пока глянем — что же внутри Hammer. Для начала смотрим на страницу 11 pdf-файла — и видим все то, о чем мечталось… И контроллер DDR памяти, и контроллер HyperTransport. Осталось выяснить, а что же скрывается под таинственным названием Hammer core. Следующая страница проясняет этот вопрос. Как мы видим, в основном ядро похоже на ядро Athlon XP, но многие буферы и емкость планировщика увеличены. Далее, интересная для нас информация расположена на странице 15 — как видно, длина конвейера слегка увеличена. Двенадцать стадий у Hammer взамен десяти у Athlon, причем удлинили стадию декодирования (превращения х86 инструкций в микрокоманды). Что ж, это должно помочь наращивать частоту. Однако, чтобы снизить негативные последствия неправильного предсказания переходов, которые из-за более длинного конвейера Hammer опаснее таковых для Athlon — необходимо увеличить точность предсказаний. Что ж, страницы 20 и 21 рассказывают, что планирует сделать AMD для снижения негативных последствий неправильных переходов. Собственно, это очевидно — надо снизить количество таких переходов. Для этого и предназначены увеличивающиеся кэши всех уровней, увеличенные буферы и более длинная история переходов.

Теперь заглянем на страницу 22, где AMD поясняет, какие именно прелести ждут нас от переноса контроллера памяти в ядро. Ну а мы с облегчением замечаем, что наши достаточно смелые предположения оправдываются — поддерживается как 64-битовая, так и 128-битовая архитектура памяти и память РС2700. То, что поддерживается ECC — просто необходимость для систем такого уровня, поэтому преимуществом это не считаем.

Ну и, наконец, со страницы 40 начинается самое для нас интересное. Построение систем на Hammer. Итак, встречайте:

Однопроцессорные системы

Особо комментировать здесь нечего — взглянем на рисунок. К процессору присоединена память (скорее всего 64-бит каналом для уменьшения стоимости). К процессору же присоединены PCI шина (один HyperTransport контроллер) и AGP 8х (второй HyperTransport контроллер). К первому присоединен еще «южный мост» чипсета, в котором, по видимому, и находятся всякие USB, Monitoring и прочее. Возможно, при необходимости в максимальной производительности память сделают 128-бит, а PCI — 64/66.

Двухпроцессорные системы

Здесь начинается более интересная ситуация — системы на AMD и Intel сильно отличаются по идеологии. Для Intel характерна общая шина для 2-х процессоров и памяти. Это приводит к двум следствиям:

  1. Монтаж двухпроцессорной платы для систем от Intel проще и дешевле. Соответственно, у AMD — сложней и дороже.
  2. Поскольку шину делят 2 процессора и память, процессоры в такой системе практически всегда недогружены. Слегка исправляют ситуацию большие кэши, которые Intel интегрирует в процессоры. Однако кардинально исправить ситуацию они не в силах — такова, увы, идеология построения двухпроцессорных систем от Intel. Отсюда же понятно, почему не имеет смысла использовать память с пропускной способностью, большей, чем шина — она просто не будет использована (разве что теоретически есть возможность другим устройствам, минуя процессор, обратиться к памяти, пока процессор читает или пишет данные. Практически прирост не превышает нескольких процентов.)

Теперь посмотрим на систему конкурента — к каждому процессору подведена своя память. Причем 128-битным каналом. К одному из процессоров подключены PCI64/66, AGP; ко второму — PCI64/66.

Интересно — ранее аналогичной системы на х86 рынке не было… Собственно, из такой технологии подключения вытекает несколько следствий:

  1. Когда процессор обращается к своей локальной памяти — все понятно. Когда к чужой — он по HyperTransport запрашивает данные у контроллера памяти второго процессора. Поскольку тому необходимо попутно обслуживать свой собственный процессор — этот самый контроллер должен быть достаточно умным, дабы уметь обслуживать несколько процессоров.
  2. Для достижения максимальной производительности имеет смысл следить за «локальностью» данных той или иной задачи — то есть по возможности следует размещать данные и команды того или иного процесса в памяти того процессора, который его обслуживает. Имеет смысл научить операционную систему сортировать процессы таким образом, чтобы выполнялось это правило. В случае, если данные в локальной памяти не помещаются — придется обратиться к соседнему процессору (его памяти), что замедлит работу. Правда, AMD обещает, что замедление от подобной неприятности будет скомпенсировано уменьшившейся латентностью контроллера памяти (по сравнению с текущими контроллерами в чипсетах).
  3. При обращении к PCI и AGP, находящихся у соседнего процессора — ситуация не ухудшается, поскольку дополнительные задержки из-за обращения к не локальной памяти намного меньше времени отклика устройств на PCI и AGP шинах.
  4. Самой нагруженной магистралью будет межпроцессорная шина HyperTransport. Именно ее имеет смысл делать самой быстрой. В идеале она должна позволить читать процессорам данные из памяти друг друга, плюс периферия должна иметь возможность делать тоже самое. Таким образом, получаем, что эта шина должна пропускать удвоенный трафик памяти плюс трафик AGP и PCI. Однако… Для этого надо почти 14,4 ГБ/сек (в случае 128-битной памяти РС2700). Таким образом, цифра 6,4ГБ/сек у старшего варианта HyperTransport уже не кажется слишком большой… Правда, пока не задействован третий контроллер — ему имеет смысл быть подключенным так же, как и второму — как шина между процессорами. Тогда вместе они обеспечат 12,8 ГБ/сек, что уже гораздо лучше. Впрочем, будет ли реализован такой вариант — непонятно…
  5. Естественно, создание плат под эту систему — гораздо более сложное и дорогое занятие. Поэтому на первом этапе такие системы наверняка будут относительно дороги. Бонусом, однако, практически наверняка станет непревзойденная производительность.
  6. Начиная с двухпроцессорных систем — появляется такой сектор оборудования, как сервера. А для этого сектора одним из самых важных параметров является надежность. Что предлагает нам архитектура Hammer в этой связи? В общем случае, архитектура точка-точка (реализованная уже в сегодняшних Athlon) позволяет «отключать» на ходу процессоры или, скажем, память. То есть, при выходе процессора или модуля из строя есть возможность продолжать работу. При восстановлении работоспособности или замене оборудования работу можно продолжить. Для этого необходима поддержка со стороны материнской платы (она должна отключить питание на устройствах) и операционной системы, которая должна отключить процессор/не использовать адреса памяти…

Собственно, по неподтвержденным пока данным, подобные материнские платы под Athlon есть уже сейчас. При тестировании сэмплов нового ядра Athlon (сделанного по 0,13 микронной технологии) на сэмплах новой двухпроцессорной материнской платы с процессоров снимались вентиляторы — работа продолжалась, но замедлялась. Отключался один из процессоров — и Windows XP продолжала работу, сообщив, что один из процессоров занят на 100%. OS/2 Warp 4.0 тоже нормально пережила подобный садизм, а вот Windows 2000 — увы, нет. При возвращении процессора на место работа в Windows XP и OS/2 Warp 4.0 нормально продолжалась.

Кардинальное отличие такой системы от общей шины в архитектуре Intel — в случае выхода из строя одного из процессоров нормальная работа в шинной архитектуре невозможна. Собственно, наверняка Hammer будет поддерживать еще более развитые варианты подобного сервиса — например, добавлять процессоры при нехватке вычислительной мощности — или на «горячую» менять их на более мощные, не выключая и не останавливая системы… Добавим сюда Hot Plug PCI — и мы получим почти идеальный (с точки зрения надежности) вариант. Осталось разве что придумать, как на ходу поменять материнскую плату…

Ну что ж, некоторые последствия мы описали. Собственно, в определенной степени это развитие идей сегодняшних двухпроцессорных систем на Athlon — большинство идей логичны и расширяют «узкие» места современных архитектур.

Четырехпроцессорные системы

Ну что же, взглянем на 4-х процессорную систему. Вот процессоры, каждый из которых снабжен локальной памятью со 128-битовой шиной. Вот по 2 шины HyperTransport — процессоры расположены квадратом, каждый присоединен к двум соседям. По одной шине HyperTransport процессоры выделяют периферии.

Собственно, ряд следствий можно продолжить из предыдущей части. Итак:

  1. Межпроцессорные шины нагружены еще сильнее, чем в предыдущем примере. Это приведет к дефициту пропускной способности, и снижению масштабируемости. То есть, производительность системы подрастет меньше, чем могла бы, например, в случае присоединения каждого процессора к центральному межпроцессорному маршрутизатору (по аналогии с решениями от Sun — правда, цена такого решения явно больше). Однако производительность системы из 4-х Hammer по отношению к двухпроцессорной на тех же Hammer вырастет намного больше (в среднем), чем в случае системы на процессорах Intel. Это очевидно.
  2. Интересная ситуация возникает с памятью — поскольку каждый процессор владеет только четвертью общей памяти, в большинстве случаев необходимые ему данные будут находиться у других процессоров. Не совсем понятно, как AMD собирается реализовать эффективную пересылку данных. Еще создается ничем не подкрепленное впечатление, что локальная память каждого процессора для всех остальных выглядит кэшем третьего уровня. Это позволило бы применить давно отработанные алгоритмы слежения за когерентностью данных, что крайне важно.
  3. С ростом скорости процессоров и, особенно, скорости HyperTransport, задержки, связанные с пересылкой данных из «чужой» памяти, будут уменьшаться. И, наоборот, задержки при большой нагрузке будут расти, но медленнее, чем у стандартных шинных систем сравнимой производительности (т. е. около 6,4 ГБ/сек, по данным AMD).

Кстати, достаточно интересен вот какой вопрос — может ли 4-х процессорная ситема на базе Hammer изображать из себя два компьютера? Согласитесь, было бы достаточно красиво — ведь далеко не все приложения могут пользоваться 4-мя процессорами. А в этом случае у нас было бы два компьютера в одном флаконе, на каждом при этом могла бы исполняться своя операционная система со своими задачами… Кстати, это соотношение может быть и три к одному — например, запустили мы сложную и ресурсоемкую расчетную задачу на трех процессорах, предварительно выделив 4-ый процессор в BIOS как отдельный процессор — и вперед, во время сложнейших расчетов мы играем в 3D Action (ведь научным расчетам 3D ускоритель ни к чему). Более того, за корректностью поведения программ следит не операционная система, которая сама подвержена ошибкам, а просто эти два «компьютера» имеют физически разные процессоры и память. Общего у них только системы ввода-вывода. Впрочем, эта проблема тоже решаема. Вот уж действительно история развивается по спирали — сначала были большие машины, потом стали распространенными персоналки, а теперь мы фактически идем опять к большим машинам. Только уже на столе :-).

А можно еще помечтать — ведь у нас можно из 4-х процессорной системы сотворить две двухпроцессорных, сделать их серверами, повесить на них разные задачи — и разрешить обмениваться данными не по сети, а по HyperTransport — что гораздо быстрее… Да много можно придумать применений такому подарку судьбы, как архитектура Hammer — лишь бы AMD справилась. И финансово, и с технической стороной.

Крещендо

Восьмипроцессорная система

Ухх! Если эта штука станет действительностью — обладателям многих серьезных RISC серверов и станций придется стереть снисходительные ухмылки и судорожно пересчитывать деньги :-). Потому как придется туго — х86 уже не мелкая сошка с «несчастными» 4 ГБ адресуемого пространства. Эта архитектура подросла, окрепла в боях в «гражданской войне» между Intel и AMD — и готова продемонстрировать окрепшие мышцы и зубы. Теперь понятно, для чего пришлось вводить х86-64 — действительно, городить такое на х86-32 просто незачем. Необходима такая система команд, которая действительно почувствует прирост от возможности использования (как скромно пишет AMD) до 64-х модулей памяти общим объемом до 128 ГБ.

Перейдем, однако, к системе, описанной в заголовке части. Восемь процессоров… Чем их можно нагрузить? :-) Посмотрим на рисунок:

— есть некоторое отличие от предыдущих систем — центральные процессоры не имеют периферийных шин. Потому что все три HyperTransport шины заняты межпроцессорными связями.

Кстати, еще раз обратим внимание на неодинаковость центральных и периферийных процессоров. До этого момента мы неявно полагали, что все процессоры у нас одинаковы. Но почему? Вроде этого в явном виде никто не требовал. На периферию системы (для работы с памятью и периферией) есть смысл поставить более быстрые процессоры. А вот в центр — можно и помедленнее. Гм… Интересно.

N-процессорные системы

А действительно — к чему мелочиться? Попробуем представить себе систему из действительно большого количества процессоров. Так… Вариантов два:

  1. Интегрировать в процессор еще одну (или больше) шину HyperTransport и создать трехмерную структуру (вернее, слоистую — процессоры будут расположены плоскостями друг над другом). Конечно, под эту конструкцию еще операционную систему соответствующего уровня написать надо. А можно выделять нужное количество процессоров — и запускать в «локальном» компьютере нужную задачу. Зато самый что ни на есть Hi-End. Правда, проблема загрузки межпроцессорных шин HyperTransport остается острой, вернее, становится гораздо более острой.
  2. Можно также не переделывать процессоры, а создать дополнительную логику обвязки, аналог GigaPlane от Sun. Т.е. коммутатор с огромной пропускной способностью внутренней шины (что намного легче сделать) соединяет несколько — например, 8 процессоров. При этом каждая шина HyperTransport от каждого процессора несет на себе только нагрузку от родного процессора — и ничего лишнего. А от одного процессора к другому передает коммутатор — так оно получше с масштабируемостью будет. А теперь еще припомним, что у каждого процессора три шины HyperTransport, и его, соответственно, можно присоединить к трем коммутаторам. Делая эти подключения частично перекрывающимися, можно добиться того, что путь данных в системе будет, во-первых, очень быстрым, а во-вторых — не единственным. Что кардинально меняет представление о надежности системы — теперь незаменимых узлов попросту нет. К тому же, это сильно снижает (а для небольшого количества процессоров — полностью убирает) проблему нехватки скорости внутренних межпроцессорных шин HyperTransport. Да, коммутаторы желательно сделать достаточно умными, чтобы планировать маршрут данных с минимальными задержками — например, при перегрузке какого-либо массива процессоров данными коммутатор должен пустить данные в обход.

Так, стоп — пора возвращаться на землю. А то из одного презентационного файла мы уже почти построили суперкомпьютер. :-) Буквально замок на песке — хотя каждый наш шаг был логичным и предсказуемым. Если при разработке этой архитектуры инженеры AMD все это предвидели (а сомневаться причин вроде нет) — нам остается только снять шляпу. На сегодняшний день это, пожалуй, самое масштабируемое решение в истории компьютеров (среди известных нам).

Вместо эпилога

Автор специально пошел на слегка провокационное окончание — ибо дискуссия на эту тему обещает быть интересной. :-)

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

Не хотелось бы, чтобы автора отнесли к фанатам AMD — напротив, автор консервативен, уныл, и практически не поддается уговорам купить что-то новое. :-) Тем более он не склонен к фанатизму в каком бы то ни было виде. Просто хотелось бы отойти от тривиального спора «кто сильнее — слон или кит» и оглянуться — а что изменилось на компьютерном горизонте?



P.S. Автор выражает огромную благодарность следующим людям за терпение, понимание, и здоровую :-) долю придирчивости:

  • Максиму Леню aka C.A.R.C.A.S.S
  • Илье Вайцману aka Stranger_NN
  • Олегу Бессонову aka bess

P.P.S. Особая благодарность (за мужество) — самоотверженному борцу за чистоту русского языка Овдеенко Елизавете aka Bitter




Дополнительно

iXBT BRAND 2016

«iXBT Brand 2016» — Выбор читателей в номинации «Процессоры (CPU)»:
Подробнее с условиями участия в розыгрыше можно ознакомиться здесь. Текущие результаты опроса доступны тут.

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.