ЗНТУ
Реферат
Архитектура процессоров семейства
Athlon
-64
Выполнила: ст. гр. ИВТ-523
Лукашевич А. С.
Принял: Рыбин В. О.
г. Запорожье
2005 год
Впервые со времен i386 архитектура х86 подвергается расширению — подчеркиваем, не «подклеиванию» новых наборов команд, а полноценному расширению. Дело здесь даже не в том, что теперь на каждом рабочем столе может стоять 64-битный компьютер — само по себе это не прибавляет производительности. Да и не так уж много у обычного потребителя задач, в которых это важно (разве что криптография, поскольку при переходе на 64 битовые вычисления она выигрывает едва ли не больше всех). Дело в том, что теперь архитектуре х86 (обновленной) вновь есть, куда расти. Кроме того, данная архитектура исправляет некоторые огрехи, присущие х86 от рождения — например, в 64 битном режиме применяется «плоская» модель памяти, количество регистров общего назначения расширено до 16 (чуть дальше автор покажет, какие дивиденды это приносит). Так что самое время задаться вопросом — а кто же выиграет от подобного расширения архитектуры? Для начала перечислим группы пользователей, которым 64 адресация и 64 битовые вычисления нужны уже сейчас:
пользователи CAD, систем проектирования, симуляторов уже давно нуждаются в объеме оперативной памяти больше 4 гигабайт. Хотя способы обходить это ограничение известны (к примеру, Intel PAE), за эти способы приходится расплачиваться производительностью. Действительно, процессоры Xeon поддерживают режим 36 битной адресации, в которой могут адресовать до 64GB оперативной памяти. Суть этой поддержки вкратце состоит в том, что оперативная память разбита на сегменты — и адрес состоит из номера сегмента и адреса ячейки внутри сегмента. Этот способ приводит к потере минимум 30% производительности при операциях с памятью. Да и программирование для «плоской» модели памяти в 64 разрядном адресном пространстве значительно проще и удобнее — благодаря большому адресному пространству ячейка имеет простой адрес, обрабатываемый за один раз. Не зря многие конструкторские бюро используют достаточно дорогие рабочие станции на RISC процессорах — там поддержка 64 битной адресации и большого объема памяти реализована давно.
в подобной же ситуации находятся пользователи баз данных. Любое крупное предприятие имеет немаленькую базу данных, и расширение максимального объема памяти плюс возможность адресовать данные в базе данных напрямую для них дорогого стоят. Как уже говорилось выше, хотя в специальных режимах 32 битная архитектура IA32 и может адресовать до 64GB памяти — но переход на «плоскую» модель памяти в 64 битном пространстве гораздо выгоднее. Переход на 64 битовую адресацию выгоден и с точки зрения скорости, и с точки зрения удобства программирования.
научные вычисления. Здесь ценен объем памяти, «плоская» модель памяти, и отсутствие ограничений на размер обрабатываемых данных. Кроме того, некоторые алгоритмы в 64 битном представлении имеют значительно более простой вид.
есть область, которая очень выигрывает от 64 битных целочисленных вычислений. Это криптография и приложения, созданные для обеспечения безопасности. В этой области применение х86-64 способно привести если не к революции, то к огромному рывку вперед.
Таким образом, некоторый круг потенциальных потребителей новой архитектуры сложился уже сейчас. Тем же из покупателей, которым эти возможности не нужны, нет нужды использовать их в данный момент — для 32 битовых приложений ничего не меняется. Вообще ничего. Кроме того, вполне можно пользоваться 32 битными приложениями в 64 битной операционной системе — эдакие 64 бита «в рассрочку». Похоже, добавление этой технологии не так дорого — по заверениям AMD, данная технология увеличивает количество транзисторов на 2%-3%. Это связано в основном с расширением TLB (сокращение от Translation Lookaside Buffer — буфер быстрого преобразования адреса, представляющий собой специальную кэш-память; используется для ускорения страничного преобразования), а также всевозможных буферов всех видов и сортов, да расширение всех конвейеров и путей данных до 64 бит. Кстати, AMD слегка «хитрит» в этой оценке — по количеству транзисторов они, возможно, и правы (тем более что есть кэш, в котором транзисторов немало), но вот прирост площади кристалла будет явно больше.
Не будем таить греха — хороша х86, или нет, но именно эта архитектура является доминирующей по числу и инсталлированных систем, и существующего программного обеспечения. До сих пор, во многом с подачи Intel, бытовала точка зрения, что, дескать, х86 доживает последние дни (забавно, но такой точке зрения уже больше десяти лет — хоронили х86, хоронили, а она многие RISC процессоры пережила) — в дальнейшем все будем постепенно переезжать на новую архитектуру. В роли таковой, вполне естественно, прочили IA64. Однако AMD продемонстрировала, что архитектуре х86 еще есть куда расти и развиваться, при этом сохраняя свое самое важное преимущество - инсталлированную базу программного обеспечения. Что ж, это хорошие новости — сомневаемся, чтобы даже наиболее оптимистично настроенные пользователи пришли в восторг, узнав, что для перехода на новую, совершенно замечательную и прогрессивную архитектуру IA64 ему нужно выложить немаленькую сумму за оборудование и намного большую сумму за программное обеспечение. Так что эволюционный подход надо признать правильным и щадящим для пользователя. Не говоря уже о том, что такой подход дает возможность нацелить продукт сразу на несколько сегментов рынка, что явно выгоднее с финансовой точки зрения….
Режимы работы процессора – что изменилось?
Фактически, кроме стандартных и известных со времен i386 режимов, введен особый режим — Long mode. Когда он включен (бит LME выставлен в единицу), есть два «частных» режима работы процессора. В одном из них процессор находится в режиме совместимости, во втором — в «честном» 64 битном режиме. Для чего понадобилось делать 2 «частных» режима для 64 битного режима? Все очень просто — когда Вы используете 32 битную операционную систему, тогда пользоваться 64 битовым режимом нет никакого смысла. Но как только вы стали работать на 64 битной ОС, далее у вас два варианта — вы можете использовать старое, 32 битное программное обеспечение (и тогда и нужен режим совместимости), а можете использовать новое, 64 битное. Кроме того, переключения «частных» режимов Long mode происходят весьма быстро, в отличие от переключения режимов работы процессора. Таким образом, введение таких режимов становится целесообразным. По-видимому, есть смысл привести таблицу, поясняющую доступные программисту режимы процессора, и режим работы в них:
| LME |
Атрибут сегмента кода |
Режим |
|
| бит L |
бит D |
||
| 0 |
х |
0 |
Обычный 16-битный |
| 0 |
х |
1 |
Обычный 32-битный |
| 1 |
0 |
0 |
Совместимый 16-битный |
| 1 |
0 |
1 |
Совместимый 32-битный |
| 1 |
1 |
0 |
«Честный» 64-битный |
| 1 |
1 |
1 |
Зарезервировано |
Символ «х» обозначает, что при выставленном бите LME в значение «0» значение бита L игнорируется.
Как видно, у процессора есть и 64 битный режимы работы, и 32 битный, и 16 битный — собственно, поддерживаются все предыдущие режимы. Это и есть условие совместимости, не так ли?
Нельзя не отметить, что для того, чтобы пользователи смогли воспользоваться преимуществами х86-64, 8-ми дополнительными регистрами общего назначения, 8-ми дополнительными регистрами SSE2, и прочими программными «вкусностями» этих процессоров, необходим компилятор. И он — достаточно важная часть программы по продвижению этого процессора, и даже более важная для архитектуры х86-64! Ибо, если компилятора не будет, то мало кто начнет программировать под этот процессор вручную…. Если он будет, но будет неудобным — опять же, это скажется на количестве программистов, и, как следствие, на количестве пользователей (и финансовых показателях компании AMD). Таким образом, требования к компилятору достаточно высоки.
Надо отметить, что AMD хорошо это понимает — и работы над несколькими независимыми версиями компиляторов ведутся, вместе со всемирно известными компаниями-разработчиками программного обеспечения.
Чтобы продемонстрировать полную совместимость своего детища, AMD проверила системы на новом процессоре в более чем 50 (!) операционных системах. Вот некоторые примеры систем, совместимость с которыми проверена:
Windows (3.1, 9x, Me, 2000 Pro, 2000 Server, 2000 Advanced Server, WfW, XP)
Windows NT (3.51 WS, server, 4.0 w/SP6, NT 4 Workstations)
DOS (MSDOS 6.21, Novell DOS 7.0, PC DOS 6.1, 6.3, 7.0
Linux (Mandrake 7.0, 7.1, Redhat 6.0, 6.1, 6.20, 7.0, Slackware 1.2, 2.0, SuSE 7.0)
Unix (SCO, FreeBSD 3.0, Solaris 2.5, 2.6, 7, 8)
Misc (OS/2 Warp3.0, 4.0, BeOS 4.5, 5.0, Netware 4.11, 4.2, 5.0, 5.1)
Тем временем перейдем непосредственно к процессору, к его ядру.
Для начала дадим общую схему ядра, и затем пройдемся по некоторым блокам. Наибольший интерес представляют кэш и конвейеры декодирования.
Общая схема ядра
Сразу отметим несколько особенностей:
Контроллер памяти интегрирован
в процессор.
Кэш первого уровня разбит на 2 части - кэш команд и кэш данных (впрочем, так было и в поколении K7 (Athlon/Athlon XP).
Главный конвейер содержит 3 канала декодирования. Как это используется мы рассмотрим ниже.
На каждый канал конвейера приходится по своему ALU ( Arithmetical & Logical Unit, арифметико-логическому устройству) и AGU (Address Generation Unit, устройство вычисления адреса).
Здесь необходимо сделать очень важный комментарий. Дело в том, что достоверно изветсно, что процессор имеет 3 FPU (опять же, по одному на канал), и отдельный (!) блок умножения. Если внимательно проследить по схеме, то так и есть (заметьте три стрелки, входящие в 36-entry Sceduler).
С помощью этой схемы можно легко записать формулу структурной нотации:
C(Athlon 64) = Ip
[Mc – Csh2 – Csh1 – Rg64bitx16
– Rg128bitSSEx16
Ep
]
Mc – констроллер памяти
Csh1 = {iCsh11024x64b
, dCsh11024x64b
}
Ep
= {3Dcdp
, 3ALU, 3AGU, 3FPU, 1FMUL}
iCsh1 – кэш команд первого уровня.
dCsh1 - кэш данных первого уровня.
Dcdp
– конвейер декодирования команд.
ALU – арифметико-логическое устройство.
AGU – adress generation unit – устройство вычисления адреса.
FPU – устройство обработки значений с плавающей точкой.
FMUL – блок умножения с плавающей точкой.
Теперь, разобрав общие блоки, рассмотрим некоторые из них поподробнее. Начнем, пожалуй, с кэша.
Кэш.
Начнем с I-cache, он же кэш инструкций. Его размер остался таким же, как и в Athlon — 64КВ. Он так и остался 2-х канальным частично-ассоциативным. Размер блока — 64 байта. Содержимое защищено при помощи проверки четности.
D-cache, он же кэш данных, также 2-х канальный частично-ассоциативный. В текущей модификации поддерживается 40-битовый физический и 48-битовый линейный адрес — впрочем, при необходимости этот параметр можно увеличить. Размер блока данных также 64 байта. Из нововведений — MOESI протокол работы кэша первого уровня, ранее использовавшийся в чипсете AMD760MP(X). Поддерживает две 64-битовых операции чтения/записи каждый такт в различные банки! Три набора тэгов — port A, port B, snoop. Задержка выборки из этого кэша — 3 такта при выровненных обращениях, и плюс 1 такт, если данные не выровнены. Кстати, это достаточно низкое пенальти за то, что данные не выровнены — в Pentium 4, насколько известно автору, это пенальти значительно больше — по измерениям различных тестеров, цифры получаются от 6 до 10 тактов, в зависимости от методики. Сама Intel хранит гордое молчание на сей счет. Поддерживается hardware prefetch (блок предвыборки). Все данные защищены ECC.
Теперь перейдем к TLB — здесь есть некоторые разночтения. Одни источники утверждают, что TLB имеют емкость 40 входов, другие говорят о 32.... Но и те, и другие сходятся на том, что L1 TLB полностью ассоциативные, и поддерживают как 4К, так и 2М/4М страницы. Это должно особенно порадовать любителей «как следует посчитать» — в научных расчетах частенько используются страницы большого размера.
Прежде, чем перейти к описанию кэша второго уровня, необходимо отметить одну особенность связки «1й уровень/2й уровень» у процессоров семейства Athlon.
Дело в том, что кэши экслюзивные
(exclusive) по отношению друг к другу. Это означает, что данные в L1 не повторяют L2 – они просто другие, и лежат «ближе» к конвейеру, что ускоряет доступ.
Поскольку в процессе работы затребованные или обработанные данные прежде всего «складываются» в кэш L1, то может возникнуть (и практически всегда возникает, кстати) нехватка места в L1. В этом случае кэш L1 должен сбросить самые «старые» или ненужные данные в L2, а уже затем принять новые данные (поскольку данные не дублируются в кэшах, мы не можем просто очистить строку кэша). Для того чтобы процесс «сбрасывания» данных происходил быстрее, в процессоре есть специальный буфер — Victim buffer, задача которого как раз и состоит в том, чтобы запомнить данные, которые будут сброшены в L2. Тем самым освобождается место в L1, которое займут свежие, только что поступившие данные. Собственно, необходимость в таком буфере возникает потому, что кэши L1 и L2 работают с разными задержками — в результате Victim buffer освобождает L1 cache от необходимости ожидать более медленный кэш L2.
Итак, L2 cache. Он, как и следовало ожидать, exclusive по отношению к L1. Сохранена 16-канальная частично-ассоциативная организация — по-видимому, AMD сочла бессмысленным дальнейшее увеличение этого параметра. Кроме того, он теперь использует pseudo-LRU схему, которая уменьшает вдвое количество LRU битов. Это скорее плохо, чем хорошо — но влияние этого параметра должно быть невелико. Зато, по-видимому, в таком случае удается ускорить предшествующую декодированию обработку этих битов — а вот это уже точно хорошо. Кроме того, L2 cache содержит предварительно декодированные инструкции (термин непонятен — по-видимому, тем или иным образом предварительно «склеиваются» инструкции вместе с данными) и branch prediction bits (своего рода указатели, или просто «флаги» предсказания ветвления). Все это вместе составляет некоторый уникальный (по словам AMD) механизм, увеличивающий производительность процессора.
Интересно, что фактически декодирование (вернее, подготовка к нему) начинается прямо в L2 cache. Это означает, что при «выселении» данных из I-кэша эта информация перемещается в L2 cache, где для нее зарезервировано место.
Вдвое увеличена скорость передачи данных из L2 в L1 кэш (по сравнению с Athlon XP) — это должно здорово помочь на многих операциях. А вот каким образом это было достигнуто?
Результаты были следующими:
Можно констатировать, что в архитектуре К8 AMD модернизировала шину L1-L2 cache. Теперь вместо одной двунаправленной шины шириной 64 bit мы получили две встречных шины по 64 бита (64 + 64), что сильно снижает вероятность возникновения «затора» в этом месте. Неплохо! Кстати, это не замедлило сказаться на низкоуровневых тестах — скорость кэша второго уровня выросла как минимум на четверть при тех же частотах
[имеется в виду по сравнению с Athlon (K7)]. Не менее важно то, что теперь снижены (собственно, практически полностью нивелированы) отрицательные эффекты от «перегруза» шины L1-L2, то есть теперь вероятность возникновения «худшего случая» сведена к минимуму, кроме того, заметно снижена латентность в «худшем случае».
Объем кэша второго уровня зависит от модификации процессора. Минимум – 256К, однако такой модификации мы не встречали – реально все процессоры, что сейчас есть на рынке в Москве, имеют 1М кэша второго уровня.
Декодеры и конвейеры. Идеология работы внутренних блоков.
Перед тем как рассматривать, как же все работает, хотелось бы немного поговорить об «идеологии» архитектур. Впрочем, слово «идеология» слишком громкое — пожалуй, больше подойдет слово «концепция».
Дело в том, что уже давно не секрет, что внутренняя система команд у всех нынешних процессоров х86 кардинально отличается от внешней. И, если с внешней системой команд все ясно — она по определению «х86» с теми или иными расширениями — то вот с внутренней ситуация далеко не такая ясная. То есть, практически все интересующиеся этой темой знают, что внутри процессоров х86-команды «раскладываются на более простые» команды (кстати, упомянем, что, говоря о х86-инструкциях, мы подразумеваем и AMD64-инструкции, просто в дальнейшем не будем специально этого оговаривать). Но, оказывается, в этом направлении современные процессоры отличаются настолько сильно, что давно пришла пора упорядочить имеющуюся информацию. Вначале ознакомим читателя с сутью проблемы, из-за которой вообще возникла необходимость превращать «внешнюю» систему команд во внутреннюю. Так ли это необходимо? Судите сами!
Вообще говоря, любая микропроцессорная архитектура имеет в качестве конечной объявленной цели максимальную производительность (речь в данный момент не идет о микропроцессорах «специального назначения»). В процессе достижения этой самой максимальной производительности неизбежны некоторые компромиссы. Соответственно, надо понимать, что многие «недостатки» тех или иных процессоров возникли не потому, что разработчики «сглупили» при проектировании, а потому, что вынуждены были пойти на компромисс, и, прежде всего, реализовать те вещи, которые показались им наиболее важными. Если вернуться к любимым «х86» процессорам, и поглядеть, то заметно, что Intel и AMD выбрали различные пути достижения максимальной производительности. Припомним, что производительность в упрощенном виде можно представить в виде произведения частоты на среднее число инструкций за такт. Соответственно, для увеличения произведения нам надо увеличивать один из множителей (либо оба, конечно). Соответственно, дальше дороги фирм разошлись — Intel склонилась скорее к увеличению частоты, AMD более привержена увеличению среднего числа исполняемых за такт инструкций.
Соответственно, все дальнейшие различия между микропроцессорными архитектурами этих фирм напрямую следуют из концепции, закладываемой в архитектуру. Не стали исключением и декодеры х86-инструкций в микропроцессорах Pentium 4, К7 и К8. Их особенности и отличия друг от друга связаны как раз с различием подходов к построению высокопроизводительных архитектур.
Кроме всего прочего, на конструкцию декодеров оказал влияние тот факт, что система х86-команд весьма неудобна для конструкторов микропроцессоров. Связано это с несколькими вещами:
Инструкции «х86» имеют нерегулярную длину (вплоть до 15 байт (!))
Кроме того, х86-инструкции еще и имеют нерегулярную структуру — к примеру, в первой команде первым стоит код операции, а во второй команде этот код находится на втором месте.
Все это привело к тому, что х86-инструкции оказалось выгоднее вначале «переводить» в некий внутренний набор регулярных команд заранее заданной структуры, которые затем и будут направлены в функциональные устройства микропроцессора. Кроме всего прочего, в такой внутренней команде можно предусмотреть дополнительные поля (например, облегчающие нахождение операндов). Если привести некую, достаточно условную, аналогию, представьте себе конвейер, на который беспорядочно свалены куски материалов и листики с инструкциями по сборке. Весь этот поток движется по конвейеру, а в результате должен получиться автомобиль. Не нравится?! То-то же! Вот и производителям не нравится. В результате они вынуждены некоторые усилия тратить на «разгребание» конвейера — данные (детали) отдельно, инструкции (листики с инструкциями по сборке) отдельно. И, только упорядочив это все, разложив по стадиям вдоль конвейера, можно продолжать сборку. Вроде бы понятно — для высокопроизводительной работы нужен порядок, с этим разобрались.
Теперь припомним, что уже довольно давно (с микропроцессора Pentium, если быть точнее), с 1993 года, х86-совместимые микропроцессоры стали «суперскалярными». То есть умеют исполнять более одной инструкции за такт. В нашем примере это равносильно существованию двух (трех, и так далее) сборочных конвейеров для автомобилей. Само по себе это усовершенствование подняло производительность микропроцессоров. Но и послужило источником новой проблемы.
Проблема оказалась связана с переменной длиной х86-команд. Это весьма крупное неудобство в плане суперскалярного исполнения. При этом сам перевод х86-инструкций во внутренние команды не вызывает особых трудностей. Неприятность же заключается в необходимости одновременной выборки сразу нескольких команд. Источник неприятности: местоположение второй команды можно определить только после анализа первой (в простейшем случае на это уйдет 1 такт или более, т.о. темп выдачи окажется неприемлемо низким — ~1 команда / такт вместо нескольких). Можно одновременно анализировать сразу байтовый набор в потоке инструкций, но отношение эффективность/затраты оказывается весьма неудовлетворительным. Поэтому используются комбинированные подходы к решению этой проблемы.
Вначале рассмотрим отличия идеологий в Pentium 4 и К7, а затем перейдем к «виновнику торжества» — архитектуре К8. На первом этапе и К7, и Pentium 4 используют довольно простой вариант одновременного анализа команд. А вот позднее пути этих архитектур расходятся.
Pentium 4: базовая концепция состоит в переводе х86-инструкций в более регулярные, «RISC-подобные» микрооперации фиксированной длины.
Выбирая х86-инструкции из куска кода, декодеры переводят х86-инструкции в микрооперации. Чтобы избежать потери времени при повторном просмотре этого же куска, выбирая вторую команду (как мы писали выше, здесь одна из основных трудностей в декодировании), Pentium 4 после перекодирования записывает полученную микрооперацию в Trace cache. Декодеры работают асинхронно (в данном случае имеется ввиду темп, а не частота работы) с исполнительными конвейерами. Все это следствие ключевой концепции микроархитектуры Pentium 4 — достичь как можно большей частоты. Естественно, что специальным образом подготовленные микроинструкции можно исполнять более эффективно и с большим темпом, нежели нерегулярные и весьма разнообразные по форме х86-инструкции. Таким образом, Pentium 4 старается держать как можно больше готовых «переведенных» команд для исполнения в Trace Cache. Да-да, в том самом, который может хранить до 12 000 микроопераций. Ну а поскольку одна х86-команда может превратиться в одну, две, или последовательность микроопераций, теперь бессмысленно оперировать такой привычной нам вещью, как «объем» кэша команд. Ведь в зависимости от того, какие команды нам встретились, количество х86-команд, уместившееся в Trace cache, будет от раза к разу совершенно различным. Таким образом, прямое сравнение «объема» кэша команд между Pentium 4 и его конкурентами становится попросту невозможным.
Правда, никто не мешает провести сравнение хотя бы по среднему количеству хранящихся инструкций, взяв широкий спектр задач; насколько нам известно, это мало кто делал — а от Intel мы подобных сравнений не дождемся, поскольку обычно по этому параметру Pentium 4 проигрывает в полтора-два раза конкурентам.
Другими словами, если подытожить, то Pentium 4 заранее превращает х86-инструкции в микрооперации, которые записываются в Trace Cache. Использование Trace Cache является, таким образом, одной из ключевых концепций в Pentium 4.
К7: этот микропроцессор поступает не так. Кэш команд (I-cache) по-прежнему выполняет свое главное назначение — хранит х86-инструкции. В конечном итоге х86-инструкции также превращаются во внутренние команды, но детали этого превращения у К7 отличаются. Выбрав и проанализировав инструкцию, К7(К8) записывает полученную информацию о её границах в специальный битовый массив, Decode Array; инструкция же подвергается дальнейшим преобразованиям во внутренний формат. После этого, при повторном просмотре участка кода, делать самую тяжелую работу по нахождению границ инструкций уже не нужно. Decode Array ассоциирован с I-cache, но физически, на кристалле, располагается отдельно. Каждому байту х86-инструкции (находящейся в I-cache) соответствуют три бита, хранящиеся в Decode Array. Эта запись содержит информацию о том, является ли данный байт первым (последним) байтом инструкции, является ли он префиксом, следует ли направлять инструкцию по особому пути декодирования (подробнее об этом дальше).
Таким образом, мы имеем два совершенно различных подхода: Pentium 4 сохраняет практически результат работы декодера (микрооперацию), в то время как K7/K8 — полезную информацию, существенно облегчающую повторное декодирование. Отсюда автоматически следует, что для того, чтобы система K7/K8 могла использовать все преимущества (и в первую очередь — высокую «емкость» I-кэша), она должна обладать самым совершенным аппаратом, позволяющим проводить повторное декодирование быстро и незаметно. Но мы пока отложим рассмотрение этих методов, так как сейчас нам надо взглянуть на те структурные единицы, которые в конечном итоге будут выданы декодером, и кратко проследить их дальнейшую судьбу.
Первоначальные х86-инструкции на завершающих этапах работы декодера К7/К8 «переводятся» в специальные внутренние команды — макрооперации, или mOP-ы. Большинству х86-инструкций соответствует одна макрооперация, некоторые инструкции преобразуются в два или три mOP-а, а наиболее сложные, например деление или тригонометрические, — в последовательность из нескольких десятков mOP-ов. Макрооперации имеют фиксированную длину и регулярную структуру. В то время как ROP, микрооперация, соответствует одной примитивной команде, посылаемой на исполнение функциональному устройству процессора, mOP соответствует двум командам, которые будут выполнены в двух «спаренных» функциональных устройствах. Очень условно можно считать что в определенный момент mOP может «расщепляться» на два ROP-a, или «выдавать» два ROP-a — по крайней мере, mOP содержит всю необходимую для запуска двух команд информацию, включая служебную. Откуда возникла идея использования более сложной, чем ROP, структурной единицы? Вспомним, что многие х86-инструкции производят сложные действия над значениями в памяти, — действия, включающие не только считывание или запись, но и изменение значения (например, увеличение значения переменной — счетчика, находящейся в памяти). После преобразования такой инструкции во внутренний формат можно либо сразу же дать ROP-ам относительную независимость в плане дальнейшего передвижения по блокам процессора, либо можно объединить всю содержащуюся в них информацию в одной «макрокоманде». В последнем случае мы получим выигрыш не только по количеству «перемещаемых» элементов и, соответственно, логики, отвечающей за такое «перемещение», но и выигрыш за счет того, что сможем существенно сократить число промежуточных операций записи/считывания результата. Наконец, кое-где мы сможем сократить даже число реально выполняемых команд — так, в нашем примере с переменной-счетчиком понадобится всего лишь одно вычисление адреса (вместо двух, как это было бы в случае «разъединенных» ROP-ов). Собственно, и в K7, и в K8 mOP содержит две команды — одну для ALU (или FPU), другую — для AGU (устройства вычисления адреса, Address Generation Unit). Если по каким либо причинам одной команды нет — например, инструкция не обращается к памяти и ей не требуется вычислять адрес — то соответствующие поля mOP-а будут содержать пустышку, NULL-ROP. Обратим внимание, что сошедший с декодера mOP в дальнейшем будет «путешествовать» по конвейеру процессора передвигаясь по своему «каналу» — в конце которого и доберется до пары функциональных устройств (естественно, ALU/FPU и AGU). Точнее, непосредственно перед этим знаменательным событием mOP окажется в очереди (reservation station), где и «выдаст» два нужных ROP-a. ROP-ы будут направляться на исполнение в том порядке, который окажется наиболее удобным, а не в том, какой задает жесткий текст выполняемой программы (конечно же, порядок отправки на исполнение не будет противоречить логике программы, а удобство будет определяться готовностью операндов и занятостью функциональных устройств, ФУ). Поэтому вполне допустимы ситуации, когда между выполнением ROP-ов, относящихся к одному mOP-у, будут выполняться и другие ROP-ы, порожденные совсем другими инструкциями — предшествующими нашей инструкции, или следующими за ней. И, наконец, заметим, что соотнесение 1mOP = ROP для ALU(FPU) + ROP для AGU — лишь частный случай более общей концепции: в последующих поколениях процессоров может быть добавлено, например, третье устройство на «канал» — и mOP уже будет иметь более сложную структуру.
Хорошо. Запуская mOP по «каналу» мы сможем в конечном итоге добиться одновременного запуска двух команд. Как достичь большего? Правильно — добавим параллельные каналы, и одновременно на каждый из них выдадим по макрооперации. Так поступила AMD в процессорах К7/К8. Каналов — три, они симметричны, каждый содержит свою очередь и свою пару функциональных устройств. В результате можно одновременно запускать команды сразу на шесть функциональных устройств (ФУ).
Мы говорим именно про отправку команд на исполнение, так как за счет конвейеризации возможны ситуации, когда одновременно в разных блоках процессора будут выполняться и два десятка команд. Также для полноты картины заметим, что и в К7, и в K8 имеется десять функциональных устройств — три ALU, три FPU, три AGU и отдельный блок умножения. Каждый канал разветвляется: в зависимости от того, какие значения обрабатывает инструкция, mOP пойдет либо по направлению к целочисленным блокам, либо — к блокам плавающей точки; блок же AGU останется общим.
Здесь мы подошли к фундаментальной концепции микроархитектуры К7/К8. Мы уже видели, что объединение двух отдельных микроопераций в одну макрооперацию даёт явные преимущества. Точно также дела обстоят и с самими макрооперациями — практически везде они выступают не в виде самостоятельных единиц, а в виде группы. Группу образуют как раз те 3 mOP-а, которые одновременно запускаются на параллельные каналы. Вся дальнейшая работа идет не с одиночными mOP-ами, а с «тройками» mOP-ов («line»). Такая тройка mOP-ов, «line», с точки зрения центрального управляющего блока процессора, ICU (Instruction Control Unit) воспринимается как единое целое: все основные действия выполняются именно над «line», в первую очередь — выделение внутренних ресурсов. Так, под «line» одним приемом выделяется группа из трех позиций в очередях (как мы помним, у каждого канала своя очередь). Здесь mOP-ы на короткое время приобретает независимость — точнее, самостоятельными оказываются ROP-ы, которые выбираются для запуска на ФУ в наилучшей последовательности. Когда окажутся запущенными составляющие всех трех mOP-ов, относящихся к «line», соответствующие позиции в очередях будут одновременно освобождены. Точно также, одновременно будет происходить и «отставка» — освобождение ресурсов после исполнения, сопровождающееся окончательной записью результатов в регистровый файл.
Этот дизайн сама AMD характеризует как «line-orient
Итак, мы имеем три симметричных канала, работающих синхронно и параллельно. Макрооперации проходят конвейер, оставаясь прикрепленными к своим каналам — таким образом практически исключаются поздние стадии переброски и распределения команд по тем портам, к которым подсоединены специфические функциональные устройства, необходимые для исполнения конкретной команды (как правило — это самый «горячий» участок процессора). Далее, «line-oriented» подход позволяет кардинально снизить количество управляющей логики и количество «контролируемых элементов». Использование макроопераций, а не ROP-ов, в качестве элементов «line» позволяет увеличить её эффективную ширину, то есть, в конечном счете — количество команд, обрабатываемых за один такт. Наконец, количество параллельно обрабатываемых элементов в дальнейшем без особых сложностей может быть расширено просто за счет увеличения числа каналов (и, соответственно, количества ФУ). И, последнее: важно отметить, что хотя основные концепции и направлены на построение «широкого» эффективного конвейера, с равным успехом они могут быть применены к конвейерам самой разной длины.
И в этом моменте становится заметным ключевое отличие концепции К7 от концепции Pentium 4: если Pentium 4 спроектирован на достижение максимальной частоты, то К7 (да и К8, вообще говоря) в первую очередь рассчитан на исполнение максимального количества mOP-ов за такт (в конечном итоге, большее количество исполненных mOP-ов означает большее количество исполненных х86-команд, хотя зависимость здесь нелинейная).
Чтобы проиллюстрировать ситуацию, припомним наш конвейер. Представим себе, что мы для увеличения производительности сделали наш конвейер втрое более широким — то есть теперь на нем параллельно собирается три автомобиля. Соответственно, «листики с инструкциями» на конвейере лежат по три, равно как и «детали для сборки». Более того, «детали» теперь на каждое из трех мест можно класть по две! И, наконец, весь процесс укладки деталей производится одновременно одним механизмом, равно, как и готовые автомобили снимаются одновременно по три штуки.
Микроархитектуру Pentium 4 тогда очень условно можно представить как выстроенную в ряд последовательность из нескольких конвейеров разной ширины, между которыми «детали» и «полусобранные конструкции» перебрасываются специальными методами. Впрочем, не будем отвлекаться от основной задачи — тем более, что ситуация с Pentium 4 требует особого рассмотрения, да и не он является героем сегодняшнего рассказа.
Собственно, вот мы и пришли к идеологии микроархитектуры К7/К8. Надо отдать должное инженерам AMD, конструкция получилась элегантная и эффективная, при этом существенно расширена «параллельность» конвейера. Также весьма интересно, что концепция позволяет рост как «вширь», так и «вглубь».
Теперь понятно, что даже сходным образом звучащая фраза, справедливая для обеих архитектур — в современных процессорах х86-команды превращаются в «RISC-подобные» команды — означает в действительности совершенно разные вещи. Что же, согласитесь, это достаточно интересные сведения, на которых стоило остановиться!
Декодеры и конвейеры, ч.2. К7 и К8.
Здесь мы столкнулись с достаточно сложной ситуацией – т.к. точной информации по работе декодеров, а точнее, пути, который проходит команда, превращаясь в mOPы, просто нет. Есть только несколько общих наметок и результаты синтетических тестов.
Так как общие принципы работы декодеров остались неизменными, мы решили подробно рассмотреть работу декодеров К7 и указать отличия, которые присутствуют в К8 и потдверждены экспериментально или известны из официальных источников.
Прежде всего определимся с терминологией; дело в том, что в архитектуре К7 термин «декодер» употребляется в нескольких контекстах, а именно:
Предекодер (Predecoder) анализирует инструкции до их записи в I — cache, определяет адреса их начала и конца, местоположение префиксов и путь (способ) декодирования (DirectPath либо VectorPath). Вся эта информация записывается в специальные биты предекодирования (Decode Array) и помещается в L1-кэш. Одновременно производится распознавание инструкций перехода и подготовка специальных селекторов (branch selectors) для последующего быстрого предсказания и вычисления адресов переходов. Предекодирование осуществляется в темпе не более 4 байтов за такт. Здесь у нас возникли новые термины, DirectPath и VectorPath, значение которых будет пояснено ниже.
Собственно декодер, который и занимается преобразованием х86-инструкций, считанных из I-кэша, выровненных и размеченных, в макрооперации. На выходе мы имеем сформированные тройки mOP-ов, которые движутся дальше по конвейеру
Мы видим, что уже в К7 декодирование представляет собой фактически целую совокупность операций. Эту совокупность мы будем обозначать термином «декодер», пока не вдаваясь в подробности. Теперь поясним два новых термина, DirectPath и VectorPath, которые мы ввели в пункте 1. Сам декодер в К7 может обрабатывать х86-инструкции двумя путями, DirectPath и VectorPath. Первый из них, DirectPath, занимается теми и только теми х86-инструкциями, которые превращаются ровно в одну mOP, и ни копейкой больше. Все остальные инструкции в К7 обрабатываются VectorPath декодером, который превращает их в последовательность двух и более mOPs. Для таких х86-инструкций (включая самые сложные, например, целочисленное деление), используется устройство Microcode Engine («микрокодовое устройство»), которое, пользуясь встроенными таблицами, заменяет х86-инструкцию на целую последовательность mOPs.
Рассмотрим, как происходит работа декодера и конвейера в К7 (называя попутно этапы конвейера):
FETCH «выборка»: предекодер считывает 16 байт инструкций из I-cache, попутно определяя адрес следующего блока для выборки. Кстати, для К8 считывается также 16 байт. В определенных случаях (если размер одной х86 инструкции больше, чем 16/3 байт) эта стадия может стать ограничивающим фактором; правда, обычно средний размер х86-инструкции порядка 5 — 6 байт.
SCAN «сканирование»: на этом этапе при помощи записанных ранее битов предекодирования инструкции отделяются друг от друга, разделяются по пути декодирования (DirectPath или VectorPath). До 6 отделенных друг от друга инструкций отправляются на дальнейший этап DirectPath, и не более одной инструкции отправляется в VectorPath, в Microcode Engine.
ALIGN1 «выравнивание 1»: на этом этапе возможна буферизация до 9 DP инструкций (до 24 байт), три из которых каждый такт могут отсылаться дальше на исполнение в трех каналах исполнения. Номер этого канала 0/1/2 закрепляется за mOP-ом, в который трансформируется DP инструкция, на все последующие этапы, вплоть до «отставки» (retirement). Общая скорость исполнения на этой стадии для DP инструкций составляет 3 инструкции за такт. Инструкции типа VectorPath также проходят через этот этап для того, чтобы на выходе из декодера обеспечить порядок следования mOP-ов, соответствующий исходному порядку инструкций. VectorPath-инструкция занимает (блокирует) сразу все три канала декодирования и не может сочетаться с предшествующими DirectPath инструкциями. Если в предшествующем такте набралось меньше трех DirectPath-инструкций, то в оставшиеся каналы ничего не отсылается и они остаются незанятыми.
Здесь прервемся на секунду, и обратим внимание, что недостаток VectorPath инструкции состоит в том, что она «занимает» все три канала декодирования, не позволяя работать DP декодерам параллельно. Важно отметить, что сама по себе VectorPath инструкция не является «плохой» — Microcode Engine работает с той же скоростью «3 mOP-а в такт», что и DP декодеры, при этом полученные из VectorPath mOP-ы ничем не хуже полученных из DirectPath. Напротив, для сложных инструкций, дающих десятки команд (для деления, или для многих системных инструкций), VectorPath - прекрасное решение! Проблема в VectorPath заключается в побочных эффектах, связанных с положением VP инструкции в «тройке». А именно:
Если VP инструкция — первая в тройке (имеет нулевую позицию), то она направляется на Microcode Engine, которая и генерирует последовательность mOP-ов (используя внутренние таблицы). mOP-ы выдаются тройками; если в последней тройке меньше трех mOP-ов, то в пустующие позиции проставляется NULL-ROP («пустышка»). Оставшиеся две инструкции из блока, содержащего обработанную VP-инструкцию, сдвигаются на одну позицию влево (т.е. в нулевую позицию) и дополняются до тройки следующей инструкцией.
Если VP инструкция не является первой в тройке, то сперва декодируются предшествующие ей DP инструкции, причем недостающие позиции mOP-ов дополняются до тройки нужным числом NULL-ROP (одним или двумя). Далее — как в предыдущем пункте, то есть VP инструкция начинает обрабатываться со следующей «строки».
Нетрудно заметить, что, если, например, двух-mOP-овая VP-инструкция в потоке DP-инструкций занимает позицию #
#0 — то будет пропущена одна позиция
#1 — три
#2 — две.
Таким образом, здесь, в среднем, будет теряться [(1 + 3 + 2)/3] / 2 = половина ресурсов «line»!
ALIGN2 «Выравнивание 2»: разбор (синтаксический анализ) инструкции в каждом из трех каналов с выделением префиксов, кода операции, байтов ModR/M и SIB и отсылка отсортированной информации на следующий этап для завершения раннего декодирования и генерации mOP-а. Инструкции типа VectorPath одновременно обрабатываются в своем устройстве декодирования. На этапах 3 (MECTL) и 4 (MEROM) происходит адресация и выборка «микрокода», необходимого для генерации mOP-ов на следующем этапе.
EDEC «Раннее декодирование»: окончательное декодирование и определение структуры x86-инструкции в каждом из трех каналов и генерация соответствующего mOP-а. Если на данном этапе обрабатывается VectorPath-инструкция (которая занимает все три канала декодирования), то соответствующие ей mOP-ы генерируются в Microcode Engine (этап 5 — MEDEC/MESEQ), и подставляются в выходной поток группами по три (собственно, детали мы описывали выше).
IDEC «Декодирование инструкций»: прием трех mOP-ов из предыдущего этапа (из трех каналов декодера DirectPath либо из Microcode Engine) и помещение их в очередь (reorder buffer) длиной 24 элемента по три mOP-а. Из этой очереди до трех mOP-ов могут быть пересланы на следующем этапе в блок целочисленной арифметики либо FPU для последующего запуска на выполнение. Информация обо всех mOP-ах остается в этой очереди (буфере) вплоть до их «отставки», которая должна происходить в исходном порядке следования инструкций. Устройство, которое управляет выполнением mOP-ов, начиная с их попадания в данный буфер и завершая их «отставкой», называется Instruction Control Unit (ICU).
Дальнейший путь по конвейеру отличается для целочисленных инструкций, и инструкций с плавающей точкой. Вначале приведем стадии для целочисленных инструкций:
SCHED «Планирование»: буферизация mOP-ов в очереди на исполнение (6 элементов по три mOP-а) и ожидание готовности операндов. По мере готовности, производится запуск ROP-ов типа IEU и/или AGU, на которые расщепляется mOP. ROP-ы запускаются в произвольном порядке и всегда выполняются в устройстве с номером, соответствующем номеру канала декодирования mOP-а (0/1/2).
EXEC «Исполнение»: исполнение целочисленного ROP-а. Если ROP требует обращения в L1-кэш, то в текущем и двух последующих этапах производится подготовка адреса и выборка данных. Таким образом, содержательная часть инструкции может быть выполнена на этапе EXEC с задержкой в три такта. При обращении к данным в L2-кэше либо в оперативной памяти задержка может составлять десятки и сотни тактов.
Теперь перечислим стадии для инструкций с плавающей точкой.
STKREN «Отображение стека»
REGREN «Переименование регистров»
Отображение стека x87-регистров на файл с плоской адресацией и последующее переименование (отображение номера) архитектурного регистра с плавающей точкой в аппаратный регистр для каждого из трех (максимум) mOP-ов.
SCHEDW
SCHED «Планирование» На этих стадиях происходит буферизация mOP-ов в очереди на исполнение (12 элементов по три mOP-а) и ожидание готовности исполнительных устройств и операндов. Для инструкций с плавающей точкой устройство выбирается уже не по номеру канала декодирования, а по требуемой функциональности (FADD/FMUL/FSTORE).
FREG «Чтение регистрового файла»: выборка данных, необходимых для выполнение запущенного MOP-а, из регистрового файла, и последующий запуск на исполнение в соответствующее функциональное устройство. Если mOP ожидает результатов выполнения предшествующей операции с плавающей точкой, то он запускается из предыдущей стадии SCHED на один такт раньше их ожидаемой готовности, и данные передаются на вход устройства в обход регистрового файла.
12-15. FEXEC1-4 «Исполнение FP»: конвейеризованное исполнение операции с плавающей запятой. Для операций с плавающей точкой, требующих обращения в память (кэш), происходит также обработка соответствующего mOP-а в блоке целочисленной арифметики для вычисления адреса и управления блоком загрузки-выгрузки (Load/Store Unit, LSU), который производит непосредственный доступ к данным.
Все эти стадии относятся к архитектуре К7, про архитектуру К8 известно значительно меньше подробностей. Стадии, не относящиеся к декодеру, формально не изменили своего назначения. Напротив, вместо первых шести стадий К7 в К8 мы видим следующие:
FETCH1 (соответствует FETCH К7)
FETCH2
PICK
DECODE1
DECODE2
PACK
PACK/DECODE
DISPATCH (соответствует IDEC К7)
В конечном итоге, на стадии 8 — К8 (и соответствующей ей стадии 6 — К7) декодером будет выдана тройка макроопераций. В этой статье, не строя предположений о том, что стоит за новыми стадиями, мы посмотрим на практический выигрыш от нововведений.
Вначале рассмотрим изменения качественные. Помимо двух путей декодирования, Direct Path (DP) и Vector Path (VP), уже знакомых нам по К7, в К8 мы видим новый тип — Direct Path Double (DD). Это действительно важное изменение: теперь большинство тех инструкций, которые раскладываются на 2 mOP-а и, следовательно, ранее направлялись по VectorPath, сейчас обрабатываются по-другому, как DirectPath Double. Как раз те самые «бывшие» VectorPath инструкции, которые ранее блокировали декодер, попусту «разбазаривая» часть его ресурсов. Теперь же они могут стартовать с любой позиции. Они дополняются до тройки как mOP-ами, полученными из DP-инструкций, так и отдельными mOP-ами из других DD. Последнее, но иными словами: эффективная скорость декодирования потока DD — 1.5 х86-инструкции в такт, соответствующая скорости выдачи 3 mOP-а в такт, то есть полностью заполненной «line». Замечательно! Среди DD-инструкций мы видим такие часто встречающиеся, как, к примеру, POP reg, RET, умножение (некоторые формы), а также packed-SSE2- и packed-SSE-инструкции. Отметим, что таким образом, K8 имеет существенные преимущества перед К7 при выполнении 128-разрядных SIMD-инструкций.
Теперь — изменения количественные. Скорость загрузки кода, находящегося в L2, но не в L1 I-Cache, заметна подросла — в К8 она увеличилась практически на две трети. Причины: как расширение интерфейса L2 — L1, так и появившаяся возможность сохранения битов предекодирования в L2.
И, наконец, скорость обработки последовательности DirectPath-инструкций. Алгоритм выравнивания инструкций, применявшийся в К7, не всегда обеспечивал 100%-ю эффективность (хотя, надо сказать, эффективность была достаточно высокой, в среднем выше 80-90%). Теперь, в К8, ситуация существенно изменилась. Из результатов тестов, проведенных, опять же, ixbt.com, видно, что для всех не слишком длинных инструкций (5 байт и менее) темп оказывается предельным. Для многих комбинаций из инструкций большего размера эффективность также 100%. В некоторых случаях, правда, стало немного хуже на длинных инструкциях. Но главное, что среднее число mOP-ов за такт заметно подросло! Браво инженерам AMD! И очень жаль, что все это пришлось выяснять в ходе многочисленных синтетических тестов, а не читать в документации — право, подобными достижениями можно и нужно гордиться!
Осталось добавить, что в декодере добавились этапы «переупаковки» и совместного анализа нескольких инструкций (Inter-instruction decoding). Эти этапы отвечают за переназначение потоков (lanes), в которых выполняются MOP-ы, с целью оптимизации использования функциональных устройств. Теперь за счет разнесения MOP-ов, не зависящих друг от друга, по разным потокам, удается повысить «КПД» использования исполнительных устройств. Также на этих этапах проводятся некоторые мелкие преобразования групп зависимых MOP-ов для уменьшения задержек при совместных обращениях к регистрам и к стеку.
Пресловутая "гонка гигагерц" утомила, похоже, даже ее непосредственных участников - разработчиков центральных процессоров, корпорации Intel и AMD. Постоянное увеличение тактовой частоты привело к тому, что обе компании неожиданно оказались в заложниках этой "гонки": не выпускать новые процессоры нельзя, но и продолжать увеличение тактовой частоты прежними темпами неэффективно с маркетинговой точки зрения и тяжело с технологической.
Не секрет, что подавляющему большинству бизнес приложений сегодня для комфортной работы достаточно процессора среднего уровня. Процессоры стоимостью около $100 в целом справляются с офисными и мультимедийными задачами, их производительности хватает и для игр. Разумеется, остаются еще вычислительные задачи, обработка графики, видео, звука - словом, те приложения, которым всегда необходима максимальная производительность центрального процессора. Остаются так называемые "хардкоровые" геймеры, энтузиасты... Но не они формируют спрос и не они являются ключевыми потребителями.
Отсутствие финишной прямой в "гонке гигагерц" понимают, похоже, и разработчики. Недаром же и AMD, и Intel отказались от использования тактовой частоты для маркировки процессоров. Видимо, даже в маркетинговых отделах наконец поняли, что для привлечения внимания рынка одной лишь частоты мало - необходимы качественные новшества.
64 разряда - новый вектор развития
И новшества были предложены. В 2003 году корпорация AMD выпустила Athlon 64 и Athlon 64 FX - первые настольные 64-разрядные процессоры, совместимые с архитектурой x86. Можно долго дискутировать - и мы еще этим займемся - о востребованности и целесообразности перехода на 64-разрядную среду в настольных системах. Однако факт остается фактом - предложив в сентябре 2003 года Athlon 64 и Athlon 64 FX, AMD сумела найти качественное отличие от продуктов других разработчиков процессоров. AMD удалось не только создать дополнительное конкурентное преимущество, но и добиться увеличения производительности системы без увеличения тактовой частоты.
С тех пор минуло уже больше полугода. Это время было потрачено AMD на развитие инфраструктуры, насыщение рынка как самими процессорами, так и системными платами для них. Примечательно, что до недавних пор AMD не форсировала увеличение тактовой частоты. Наоборот, корпорация без лишней помпы выпустила процессоры Athlon 64 3000+, а чуть позже - 2800+, содержащие вполовину урезанный кэш второго уровня. Благодаря отличному соотношению цены и производительности, Athlon 64 3000+ приобрел огромную популярность; по-видимому, аналогичная судьба уготована и 2800+.
Но речь сейчас не о них. Предложив качественное улучшение - 64-разрядные расширения - AMD начинает постепенно наращивать производительность семейства Athlon 64 традиционным способом, путем увеличения тактовой частоты. Следующим представителем линейки стал процессор Athlon 64 3400+, главным и единственным отличием которого от модели с индексом 3200+ стала увеличенная до 2.2 ГГц тактовая частота. Выпущен и новый процессор Athlon 64 FX-53, тактовая частота которого составляет 2.4 ГГц.
Как поступить в такой ситуации Web-сайту COMPOSTER? Не проводя никакого тестирования, можно утверждать, что Athlon 64 3400+ окажется быстрее Athlon 64 3200+, а Athlon FX-53, соответственно, Athlon FX-51. Также, без безо всякого тестирования можно утверждать, что производительность Athlon 64 3400+ окажется сопоставима с Pentium 4 3.4 ГГц, а Athlon FX-53 будет сравним с Pentium 4 3.4 ГГц Extreme Edition. В некоторых приложениях быстрее окажется Athlon 64, в других же - Pentium 4. Вспомнив особенности архитектуры обоих процессоров, можно даже сказать, что Pentium выиграет на задачах, связанных с обработкой потоковых данных, а Athlon - там, где требуется математический блок.
Исходя из этих предпосылок, мы решили не тратить время на получение баллов, которые соответствуют приросту частоты в 200 МГц. Гораздо более интересной показалась нам возможность посмотреть на систему, основанную на процессорах AMD Athlon 64 и Athlon 64 FX, в родной 64-разрядной среде. Благо 64-разрядная версия Windows XP уже доступна на сайте Microsoft для бесплатной загрузки и ознакомления.
Для чего нужны 64 разряда?
И в самом деле - для чего? Пропагандируя 64-разрядную платформу, AMD говорит о преемственности технологий, подчеркивая, что процессоры Athlon 64, Athlon 64 FX и Opteron способны выполнять как 32-, так и 64-разрядные вычисления. Это позволяет использовать процессоры уже сегодня, с 32-разрядными операционными системами и приложениями, а затем осуществить плавную миграцию на 64-разрядную вычислительную среду.
Нет никаких сомнений в том, что массовое появление 64-разрядного программного обеспечения не за горами. Если еще недавно кто-то и сомневался в способности AMD "убедить" разработчиков аппаратного и программного обеспечения в необходимости использования технологии AMD64, то теперь все сомнения должны исчезнуть сами собой - о своем намерении выпустить процессоры с 64-разрядными расширениями заявил Intel.
Расширения эти будут совместимы с AMD64, хоть Intel это прямо и не признает. По словам Intel, приложения, использующие AMD64, будут работать на процессорах с 64-разрядными расширениями IA32e, но не наоборот. Расшифровываем: набор инструкция IA32e полностью совместим с AMD64, но, возможно, будет содержать некоторые дополнительные команды или регистры, не предусмотренные в данный момент AMD. Сути дела это не меняет - поддержка корпорацией Intel 64-разрядых инструкций, совместимых с AMD64, является четким и понятным сигналом всем разработчикам ПО: пора активнее переводить приложения на 64-разрядную архитектуру. Очень скоро поддержка 64-разрядных инструкций станет не просто красивой "добавкой", но свойством, необходимым любому коммерческому приложению.
Чем же так хороши 64-разрядные инструкции? Главное преимущество технологии AMD64 перед традиционной 32-разрядной архитектурой состоит в способности линейной адресации гигантских объемов ОЗУ. Процессоры Pentium III, Pentium 4, Xeon, Athlon и Athlon MP, использующие 36-разрядную адресную шину, способны работать с 64 ГБ памяти, причем для доступа к областям выше 4 ГБ применяется сегментация (на самом деле, шина состоит из 32 базовых и 4 сегментных бита). Это означает, что каждый раз, когда система запрашивает данные из области памяти выше 4 ГБ, процессору и контроллеру памяти приходится выполнять дополнительные операции, что уменьшает скорость доступа. 64-разрядная схема адресации позволяет одинаково хорошо работать с любыми областями памяти, в т.ч. и свыше 4 ГБ. Общий объем памяти, работа с которым возможна по 64-разрядной шине, составляет 2 в 64 степени байт.
На самом деле процессоры AMD Athlon 64 и Opteron используют адресную шину шириной 40 бит. Этого достаточно для линейной работы с 1 ТБ оперативной памяти. По словам AMD, шина может быть расширена, если в этом возникнет необходимость ;-)
Плоская модель адресации памяти уже находит применение в серверных системах, там, где необходима обработка больших объемов данных (например, в "тяжелых" корпоративных СУБД). Понятно, что в бизнес приложениях и играх вопрос об адресации гигантских объемов памяти пока не стоит... Настольная индустрия не дошла пока даже до 4 ГБ рубежа. Но рано или поздно это случится, и хорошо, что у AMD уже сегодня есть готовый ответ.
Переход на 64-разрядную архитектуру позволяет процессору оперировать с 64-разрядными данными: производить операции сложения, деления, умножения, записи и чтения из памяти и т.п. Если в классической 32-разрядной архитектуре для записи в память 64-бит данных требуется выполнить две команды процессора, то в 64-разрядной - только одну. Ну а арифметические операции с 64-разрядными числами могут пригодиться в задачах, связанных с криптографией, возможно - 3D-рендерингом.
Операционная система, драйверы, приложения
Дальнейшее продвижение 64-разрядных процессоров AMD напрямую зависит от позиции Microsoft. До тех пор, пока Microsoft не выпустит 64-разрядную операционную систему, использующую набор инструкций AMD64, корпорации AMD придется продолжать говорить о преемственности технологий вместо того, чтобы демонстрировать эти технологии в деле. Да, уже давно доступны дистрибутивы Linux, использующие AMD64. Но все же, без 64-разрядного Windows не обойтись.
"Информированные источники" утверждают, что у Microsoft уже сейчас есть готовая к выпуску 64-разрядная версия Windows XP. Однако, ее появление откладывается до тех пор, пока Intel не выпустит свои процессоры с 64-разрядными расширениями. Intel же до сих пор не назвал конкретные сроки - поговаривают, серверные процессоры Xeon с 64-разрядными расширениями могут появиться где-то осенью, а настольные Pentium 4 - лишь к Новому Году.
В идеальном мире система на 64-разрядных процессорах AMD Athlon 64, Athlon 64 FX работает под управлением 64-разрядной версии ОС, использует 64-разрядное програмное обеспечение и 64-разрядные версии драйверов (да, 32-разрядные драйверы в 64-разрядной ОС работать не будут). Но неизвестность относительно сроков выхода Windows для AMD64 тормозит разработчиков ПО. Они и рады бы выпустить 64-разрядные версии своих приложений, но сделать это невозможно, пока нет операционной системы.
Появление 64-разрядной версии Windows для AMD64 разом сняло бы все вопросы. Разработчики получили бы возможность выпустить 64-разрядные приложения в дополнение к 32-разрядным, которые, напомним, могут беспрепятственно работать в 64-разрядной операционной системе.
Процессоры AMD Athlon 64 3400+ и Athlon 64 FX-53
Приведем краткие технические характеристики процессоров AMD Athlon 64 3400+ и Athlon 64 FX-53.
| Athlon 64 3400+ |
Athlon 64 FX-53 |
|
| Технология производства |
0.13 мкм |
0.13 мкм |
| Тактовая частота |
2.2 ГГц |
2.4 ГГц |
| Объем кэш-памяти первого уровня |
128 КБ |
128 КБ |
| Объем кэш-памяти второго уровня |
1 МБ |
1 МБ |
| Интегрированный контроллер памяти |
одноканальный |
двухканальный |
| Конструктив |
Socket 754 |
Socket 940 |
Windows XP beta для AMD64
Как мы уже упоминали, Microsoft выложила у себя на сайте предварительную версию Windows XP для процессоров на основе технологии AMD64. Этот предварительный вариант, предназначенный для ознакомления, можно бесплатно скачать с сайта Micrsoft или же заказать на компакт-диске. Работать он будет на системах, оборудованных процессорами AMD Athlon 64, Athlon 64 FX, Opteron и... гм... несуществующими пока процессорами Intel с 64-разрядными расширениями.
Получив в свое распоряжение процессоры AMD Athlon 64 3400+ и Athlon 64 FX, мы поспешили воспользоваться случаем и установить публично доступную 64-разрядную бета-версии Windows XP. К сожалению, единственным 64-разрядным тестов, который нам удалось раздобыть, стала SiSoft Sandra 2004. Все остальные тесты и приложения были 32-битными.
Сама же Windows XP на поверку оказалась вполне устойчивой и работоспособной системой. Она установилась безо всяких проблем, нашла необходимые драйверы. Большинство программных пакетов работало под управлением Windows XP 64 bit вполне адекватно: лишь некоторые при установке заявляли, что под этой версией операционной системы они работать не могут. Вероятно, просто от незнания.
Конфигурация тестовых стендов
Процессоры: AMD Athlon 64 3400+, AMD Athlon FX-53
Системные платы: Gigabyte GA-K8N, ASUS SK8V
Оперативная память: 512 МБ Corsair XMS 3205 PC3200, Samsung Registered PC3200 (напомним, Athlon 64 FX работает исключительно с регистровой памятью)
Жесткий диск: Western Digital 400JB
Графический адаптер: Gigabyte GeForce FX 5900 XT
Драйверы: nVidia Detonator 53.04, VIA Hyperion 4.51 и VIA VIA Hyperion 64-bit beta
Результаты в 64-разрядной версии теста SiSoft Sandra 2004.
На єтой диаграмме видно, что на целочисленных операциях оба процессора - Athlon 64 3400+ и Athlon FX-53 - демонстрируют увеличение производительности порядка 10% при переходе от 32- к 64-разрядным вычислениям. В то же время, производительность блока FPU, который, как уже отмечалось, по-прежнему оперирует с 32-разрядными данными, остается неизменной. Это же справедливо и в отношении блока SSE2.
Заключение
Многое из информации, приведенной здесь, является результатом систематических синтетических тестов, т.к. никто их производителей не заинтересован раскрывать особенности микроархитектуры своих продуктов. В любом случае, порог в 32 бита преодолен, и можно лишь гадать, какие новые возможности откроют нам полноценные 64-битные приложения. Анализируя результаты тестирования, следует, прежде всего, помнить, что изучалась работа предварительной версии Windows XP для 64-разрядных систем, от которой нельзя требовать высокой скорости работы. Но даже под управлением этой бета-версии в 64-разрядных тестах (пока, увы, синтетических) мы наблюдаем увеличение производительности. 32-разрядные приложения, связанные со счетными задачами, работают в 64-разрядном Windows практически с той же скоростью, что и в 32-разрядной версии. А вот 32-разрядные графические приложения демонстрируют падение производительности, связанное, по-видимому, с недостаточной оптимизацией драйвера видеокарты. С уверенностью можно говорить о том, что к моменту официального выхода 64-разрядной версии Windows XP необходимые оптимизации будут проведены.
В то же время приятно отметить высокую стабильность 64-разрядной версии Windows XP - как уже упоминалось, ОС установилась безо всяких проблем, корректно распознала оборудование и в дальнейшем прошла все тесты без сбоев. Это вселяет определенный оптимизм.
Наконец, можно сделать вывод о том, что переход к 64-разрядным приложениям в 64-разрядной операционной системе должен дать определенный прирост в производительности. Количественно оценить этот прирост сложно. Можно лишь предположить, что наиболее заметен он будет в приложениях, производящих интенсивные операции с памятью. К ним относятся игры, системы документооборота, графические пакеты, ПО для обработки видео. Осталось лишь дождаться, когда оно станет повсеместно доступно. А произойдет это не ранее, чем появится 64-разрядная версия Windows XP, чего мы все с нетерпением ждем.
В подготовге данного материала были использованы материалы сайта ixbt.com, конкретно:
http://www.ixbt.com/cpu/amd-hammer-family.shtml
http://www.ixbt.com/cpu/amd-hammer-family2.shtml,
а также сайт (вернее, его раздел) http://www.amdboard.com/opteron.html.