С помощью этой схемы можно легко записать формулу структурной нотации:
C(Athlon 64) = Ip [Mc – Csh2 – Csh1 – Rg64bitx16 – Rg128bitSSEx16Ep]
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-инструкции оказалось выгоднее вначале «переводить» в некий внутренний набор регулярных команд заранее заданной структуры, которые затем и будут направлены в функциональные устройства микропроцессора. Кроме всего прочего, в такой внутренней команде можно предусмотреть дополнительные поля (например, облегчающие нахождение операндов). Если привести некую, достаточно условную, аналогию, представьте себе конвейер, на который беспорядочно свалены куски материалов и листики с инструкциями по сборке. Весь этот поток движется по конвейеру, а в результате должен получиться автомобиль. Не нравится?! То-то же! Вот и производителям не нравится. В результате они вынуждены некоторые усилия тратить на «разгребание» конвейера — данные (детали) отдельно, инструкции (листики с инструкциями по сборке) отдельно. И, только упорядочив это все, разложив по стадиям вдоль конвейера, можно продолжать сборку. Вроде бы понятно — для высокопроизводительной работы нужен порядок, с этим разобрались.