«подклеиванию» (стр. 5 из 7)

#0 — то будет пропущена одна позиция

#1 — три

#2 — две.

Таким образом, здесь, в среднем, будет теряться [(1 + 3 + 2)/3] / 2 = половина ресурсов «line»!

1. ALIGN2 «Выравнивание 2»: разбор (синтаксический анализ) инструкции в каждом из трех каналов с выделением префиксов, кода операции, байтов ModR/M и SIB и отсылка отсортированной информации на следующий этап для завершения раннего декодирования и генерации mOP-а. Инструкции типа VectorPath одновременно обрабатываются в своем устройстве декодирования. На этапах 3 (MECTL) и 4 (MEROM) происходит адресация и выборка «микрокода», необходимого для генерации mOP-ов на следующем этапе.
2. EDEC «Раннее декодирование»: окончательное декодирование и определение структуры x86-инструкции в каждом из трех каналов и генерация соответствующего mOP-а. Если на данном этапе обрабатывается VectorPath-инструкция (которая занимает все три канала декодирования), то соответствующие ей mOP-ы генерируются в Microcode Engine (этап 5 — MEDEC/MESEQ), и подставляются в выходной поток группами по три (собственно, детали мы описывали выше).
3. IDEC «Декодирование инструкций»: прием трех mOP-ов из предыдущего этапа (из трех каналов декодера DirectPath либо из Microcode Engine) и помещение их в очередь (reorder buffer) длиной 24 элемента по три mOP-а. Из этой очереди до трех mOP-ов могут быть пересланы на следующем этапе в блок целочисленной арифметики либо FPU для последующего запуска на выполнение. Информация обо всех mOP-ах остается в этой очереди (буфере) вплоть до их «отставки», которая должна происходить в исходном порядке следования инструкций. Устройство, которое управляет выполнением mOP-ов, начиная с их попадания в данный буфер и завершая их «отставкой», называется Instruction Control Unit (ICU).

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

1. SCHED «Планирование»: буферизация mOP-ов в очереди на исполнение (6 элементов по три mOP-а) и ожидание готовности операндов. По мере готовности, производится запуск ROP-ов типа IEU и/или AGU, на которые расщепляется mOP. ROP-ы запускаются в произвольном порядке и всегда выполняются в устройстве с номером, соответствующем номеру канала декодирования mOP-а (0/1/2).
2. EXEC «Исполнение»: исполнение целочисленного ROP-а. Если ROP требует обращения в L1-кэш, то в текущем и двух последующих этапах производится подготовка адреса и выборка данных. Таким образом, содержательная часть инструкции может быть выполнена на этапе EXEC с задержкой в три такта. При обращении к данным в L2-кэше либо в оперативной памяти задержка может составлять десятки и сотни тактов.

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

1. STKREN «Отображение стека»
2. REGREN «Переименование регистров»

Отображение стека x87-регистров на файл с плоской адресацией и последующее переименование (отображение номера) архитектурного регистра с плавающей точкой в аппаратный регистр для каждого из трех (максимум) mOP-ов.

1. SCHEDW
2. SCHED «Планирование» На этих стадиях происходит буферизация mOP-ов в очереди на исполнение (12 элементов по три mOP-а) и ожидание готовности исполнительных устройств и операндов. Для инструкций с плавающей точкой устройство выбирается уже не по номеру канала декодирования, а по требуемой функциональности (FADD/FMUL/FSTORE).
3. FREG «Чтение регистрового файла»: выборка данных, необходимых для выполнение запущенного MOP-а, из регистрового файла, и последующий запуск на исполнение в соответствующее функциональное устройство. Если mOP ожидает результатов выполнения предшествующей операции с плавающей точкой, то он запускается из предыдущей стадии SCHED на один такт раньше их ожидаемой готовности, и данные передаются на вход устройства в обход регистрового файла.
4. 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 удалось не только создать дополнительное конкурентное преимущество, но и добиться увеличения производительности системы без увеличения тактовой частоты.