 |
Устройство процессоров Intel Ivy Bridge
|
|
|
|
Часть 1
Статья одной страницей
Продолжая почивать на лаврах лидера после выпуска архитектуры Sandy Bridge (SB) в 2011 г., Intel продолжает следовать своей стратегии «тик-так», приготовив очередной «тик»: переход на новый, 22-нанометровый техпроцесс с 3-сторонними затворами у транзисторов (описанный в третьей части нашего микроэлектронного обзора) совмещён с небольшими изменениями в архитектуре. Причём большая часть изменений касается помощневшего графического (со)процессора (ГП): версия HD2000 обновилась до HD2500 (оставив те же 6 графическихтрактов), а HD3000 (12 трактов) доросла до HD4000 (16 трактов). QuickSync (аппаратный перекодировщик видео) обновлён до версии 2.0, которой рекламируют удвоенную скорость. Заявлена поддержка библиотек DX11, OpenGL 3.1, OpenCL 1.1 (на этот раз — настоящая, т. е. аппаратная, а не эмуляция на x86-ядрах) и MFX (Multi-Format Codec), а также разрешений до 4096×4096 и до трёх экранов. Детали производительности ГП описаны в этих двухтестированиях, а сила x86-ядер изучена как в абсолюте, так и в равных условиях. Нам же осталось посмотреть, какие мелочи решила добавить Intel к и так передовому «песчаному мосту», превратив его в «плющевый».
Устройство процессоров Core 3-го поколения с x86-ядрами архитектуры Ivy Bridge. Иллюстрация PC watch (с исправленной ошибкой).
Ядро
С точки программно доступных изменений, Ivy Bridge (для краткости будем называть его IB) получил несколько мелочей:
· поддержка мини-поднабора CVT16 (ранее доступного лишь последним ЦП AMD), причём сразу в полноконвейерном режиме (преобразование вектора имеет задержку 6–10 тактов);
· быстрый доступ к сегментным регистрам FS и GS (только эти из 6 сегментных регистров разрешены к использованию после внедрения x86-64) с помощью 4 новых команд — пригодится для ускоренного управления переключением контекста задач со стороны программы;
|
|
|
· DRNG (digital random number generator) — цифровой генератор случайных чисел (ГСЧ) икоманда для их чтения (строго говоря, сам ГСЧ расположен во внеядре, но командно доступен всем ядрам);
· SMEP (supervisory mode execution protection) — защита исполнения в режиме супервизора.
О ГСЧ и SMEP, наличие которых удостоено дополнительными битами в паспорте ЦП (читаемому командой CPUID), детально напишем ниже.
Что касается чисто аппаратных улучшений, то начнём с блока, ускорение которого в тестах едва чувствуется: один из двух видов предзагрузчиков для кэша L1D теперь может переходить через 4-килобайтовые границы виртуальных страниц. В момент пересечения он инициирует (как при явном обращении в L1D) чтение(я) из TLB (и L1, и L2), а если там будет два промаха — то даже и трансляцию адреса в PMH. Причём если PMH наткнётся на ошибку доступа или нерезидентную страницу (перемещённую из ОЗУ в файл подкачки), то вместо фиксирования исключительной ситуации и вызова её обработчика PMH просто остановится. Ведь предзагрузка это упреждающее действие, поэтому ЦП не может быть уверен, что данные по этому адресу точно потребуются, так что преждевременное прерывание делать неверно. Вподсистеме кэшей есть также некие улучшения при чтении невыровненных 32-байтовых словиз L2, о чём в официальных документах ничего не сообщается — видимо, из-за крайне малого влияния на что-либо.
Ну а остальные улучшения измерены куда детальней и приносят бо́льшую пользу. Во-первых, ускоренный вещественный делитель-корнеизвлекатель: деление для точностей SP, DP и EP теперь исполняется за 7, 14 и 18 тактов (было — 14, 22 и 24); почти так же ускорено и извлечение квадратного корня. Тем не менее, это ФУ осталось единственным крупным 128-битным в векторном тракте — все остальные имеют полную ширину в 256 бит. Также сюда можно добавить несколько команд (таких как некоторые простые битовые сдвиги и вращения), ускоренных на 1 такт или исполняющихся парами, а не по одной, что из всех алгоритмов пока заметно ускоряет лишь вычисление хэшей типа SHA1 и SHA256.
|
|
|
Пара (по одному на поток) буферов мопов (IDQ), находящихся между декодером и кэшем мопов со стороны фронта и диспетчером со стороны тыла конвейера, теперь для 1-поточной нагрузки умеет притворяться единым буфером на 56 мопов — SB в таком случае просто отключал второй буфер. В идеале, конечно, было бы ещё лучше, если бы это физически был единый буфер, который при 2-поточной загрузке делился бы не поровну, а динамически, как большинство остальных структур ядра. На производительность это почти не влияет (ибо кэш мопов и так гарантирует, что тыл почти всегда сможет получать по 4 мопа/такт), однако становится ясно, почему Intel оставила эту структуру — при блокировке цикла в буфере (за счёт функции LSD) можно отключить даже кэш мопов, экономя таким образом ещё немного энергии. И если для 1-поточной нагрузки буфер оказывается вдвое больше, то шансов на то, что очередной цикл там поместится, куда больше. За подробностями о правилах работы IDQ и о 4 видах разделения ресурсов между потоками отправляем к соответствующим описаниям в обзоре SB по данным тут ссылкам.
Также появились «бесплатные» копирования из одного регистра в другой, «исполняющиеся» уже на стадии переименования регистров и не занимающие ресурсы планировщика и ФУ:
· скалярные MOV для 32- и 64-битных РОНов (8- и 16-битные копирования — обычные);
· скалярные MOVZX (беззнаковое расширение РОНов с заполнением старших битов нулями) типа 8→32 и 8→64, кроме случаев, когда 8-битный источник это регистр AH/BH/CH/DH (т. е. старшие байты младшего слова первых 4 РОНов) — такие варианты исполняются штатно, как и все виды MOVSX (знаковое расширение с заполнением старших битов копией бита знака аргумента);
· векторные MOV*** (6 видов) для xmm и ymm и обоих типов элементов (целые или вещественные).
Таким образом, к обнуляющим идиомам в SB, которые также «бесплатны» и могут исполняться до 4 за такт, в IB добавили и самые частые копирования, что в некоторых программах может чуть поднять среднюю величину IPC и сэкономить несколько миллиджоулей. Физическая реализация очевидна: т. к. планировщик (как и у SB) оперирует не содержимым регистров, а ссылками на физический РФ, то копирование регистра можно заменить копированием 8-битной ссылки, и реализовать это можно было ещё в SB.
|
|
|
Сложнее с частичным доступом в эти регистры (детали этого непростого действия описаны в конце этой главы). Согласно требованиям x86-64, запись в 32-битную младшую половину РОНа обнуляет его старшую часть (а обнуление, как мы помним, также бесплатно), а вот запись в 16- или 8-битные порции сохраняет остальные биты. Однако команда MOVZX всё же их обнуляет, и потому она в «бесплатном» варианте допустима с 8-битным источником. Могла бы сработать и с 16-битным, но по историческим причинам (восходящим к далеко не идеальному способу, которым Intel в 1985 г. свою изначально 16-битную архитектуру IA-16 доработала до 32-битной IA-32, ныне называемой x86) почти все 16-битные команды в современных x86-ЦП давно попали в разряд вредных и медленных.
Данное выше описание считалось верным до тех пор, пока независимое тестирование не показало странности работы этой «копировальной машинки». Запустив простой цикл, тело которого состоит из 2–4 команд MOV в разных вариантах, а эпилог — в виде макросливаемойпары команд (генерирующей только 1 моп), обнаружено, что обещанный в документах темп в 4 копирования за такт не получается нигде. Для РОНов 1-тактное исполнение итерации цикла выходит с одной-двумя командами MOV, а с тремя — уже за 2 такта (хотя такой цикл займёт 4 мопа, передающиеся из фронта в тыл за такт). Добавление 4-го MOV увеличивает темп до 2,33 тактов на итерацию.
При копировании векторных регистров все задержки увеличиваются ещё на 1 такт, причём уже проявляется зависимость от операндов (далее цифрами обозначены номера регистров xmm): перемещение 0→1→2 + 0→1→2 — 3 такта, 0→1→2→3→0 — 3,33, 0→1→2→3→4 — 3,5, а 0→1 + 2→3 + 4→5 + 6→7 — 3,67. Т. е. 4 копирования в цикле будут исполняться за 2,33–3,67 такта, хотя в идеале должно быть 1,25 (5 мопов). Есть, конечно, остаточная надежда, что тесты оказались неточными (как это уже бывало), но пока результаты по этому пункту крайне странные…
|
|
|
Ещё одно видимое улучшение (тоже отдельно отмеченное в паспорте ЦП битом ERMSB) — скоростные операции со строками. Речь идёт не об обработке текста, а об особом виде данных из терминологии x86. Для программиста «строки» это располагаемые в памяти линейные массивы произвольной длины с целочисленными элементами размером 1, 2, 4 или 8 байт. Для их обработки ещё со времён самого первого ЦП «нашей эры» — i8086 — существует 7 команд, обрабатывающих 1 элемент строки (и неявно использующих почти все нужные им регистры), REP-префиксы для их повторения (в т. ч. с досрочным выходом из цикла) и специальный бит управления в регистре флагов. Команды позволяют копировать строку (MOVS), сравнивать строки до первого (не)совпадения (CMPS), заполнять строку константой (STOS), загружать очередной элемент строки в регистр (LODS), сравнивать строку с константой (SCAS) и выводить или вводить строку в/из порт(а) ввода-вывода (OUTS и INS, добавленные уже в 286).
Из этого разнообразия сегодня наиболее употребительными остались лишь комбинации REP MOVS и REP STOS, используемыми библиотечными функциями языка Си memcpy(), memset() иmemmove(), которые в том или ином виде встречаются почти везде, выполняя, например, копирование объектов. Поэтому за последние лет 5 процессоры научились ускорять эти команды (особенно, когда копируются или заполняются десятки элементов, расположенные как минимум в нескольких строках кэша) за счёт переноса данных только в пределах самого кэша. В IB такой аппаратный ускоритель оптимизирован, причём только для байтовых элементов (т. е. наиболее общего случая). При обработке ≥256 байт экономия составит аж 30–50 тактов. Однако Intel предупреждает, что не смотря на скорость режима ERMSB и компактность спецкоманд, обработка строк векторными командами всё равно оказывается чуть быстрее, если операнды выровнены, а их размер нацело делится на длину вектора.
Режим SMEP
SMEP является защитой от атак типа «повышение привилегий», когда вредоносный код с уровнем привилегий 3 (пользовательский и самый низкий), не имея возможности запуститься на высоком уровне, разными способами передаёт ссылку на себя в ОС, чтобы исполниться с более высокой привилегией (обычно уровни 2 и 1 занимают компоненты ОС, а 0 — её ядро). При включении режима SMEP (через бит в одном из управляющих регистров) ядро не сможет исполнять команды из линейного адресного пространства, в дескрипторе виртуальной страницы которого выставлен бит её принадлежности к пользовательскому коду. Проще говоря, если ядро ОС поддерживает включение SMEP, то система с имеющим этот режим процессором станет чуть более защищённой. По крайней мере, так обещали в прошлый раз, когда внедряли похожую защитную функцию — бит NX, который разные вирусы и трояны весьма быстро научились обходить. На этот раз взлом произошёл ещё быстрее.
|
|
|
IB был официально объявлен в продаже 29 апреля 2012 г., а уже в сентябре Артём Шишкин, эксперт компании Positive Research, специализирующейся на инфобезопасности и защите, опубликовал подробный отчёт о частичном обходе SMEP на Windows 8 (пока ни для какой другой ОС поддержка SMEP не заявлена). Более того, автор указывает, что могут существовать и другие способы обхода — с помощью сторонних драйверов. «Тем не менее, в том виде, в каком реализована поддержка SMEP на x64-версиях Windows 8, она может считаться достаточно надёжной и способной предотвратить различные атаки.» В общем, бой меча и щита никогда не закончится, как и ожидалось.
|
|
|
