Считывание и декодирование инструкций

В отличие от перемен, которые произошли при переходе от микроархитектур с Core на Core 2, Intel не очень сильно переделала переднюю часть конвейера Nehalem. Здесь есть те же самые четыре блока декодирования, которые появились вместе с Conroe – три простых и один сложный. По-прежнему поддерживается функция слияния макроопераций (macro–ops fusion), обеспечивается теоретическая максимальная пропускная способность 4+1 инструкций x86 за такт.

На первый взгляд никаких революционных изменений не произошло, однако нужно обратить внимание на детали. Как мы уже не раз упоминали, повышение числа исполнительных блоков – очень неэффективный способ поднять производительность. Накладные расходы при этом очень велики, а прирост всё больше срезается с каждым добавлением. Поэтому вместо добавления новых блоков декодирования, инженеры сконцентрировали своё внимание на оптимизации существующих.

Начнём с того, что была добавлена поддержка слияния макроопераций (macro-ops fusion) для 64-битного режима, что вполне оправданно для архитектуры, подобной Nehalem. Но на этом не остановились. Если архитектура Conroe могла выполнять слияние только весьма ограниченного набора инструкций, архитектура Nehalem поддерживает большее число вариантов, то есть слияние макроопераций может выполняться чаще.

Ещё одна новая функция, представленная с Conroe, тоже была улучшена: Loop Stream Detector. За этим названием скрывается буфер, содержащий несколько инструкций (18 инструкций x86 в архитектуре Core2). Когда процессор определяет цикл, он отключает некоторые части конвейера. Поскольку цикл подразумевает выполнение одинаковых инструкций указанное число раз, вряд ли имеет смысл выполнять предсказание ветвлений или забирать инструкции из L1 Cache при каждой итерации цикла. Поэтому Loop Stream Detector работает как небольшая Cache-память, которая "замыкает" первые ступени конвейера в подобных ситуациях. При реализации этой техники получается двоякий прирост: снижается энергопотребление, поскольку процессор не работает над бесполезными задачами, а также увеличивается производительность путём снижения нагрузки на Cache инструкций L1.

С архитектурой Nehalem Intel улучшила функциональность Loop Stream Detector. Был увеличен буфер – теперь он вмещает 28 инструкций. Но, более того, изменилось его расположение в конвейере. В Conroe буфер располагался как раз за ступенью выборки инструкций (instruction fetch). Теперь же буфер находится после ступени декодирования; такое расположение позволило отключать большую часть конвейера. В Nehalem Loop Stream Detector хранятся уже не инструкции x86, а микрооперации. В данном отношении технология чем-то напоминает концепцию Cache с отслеживаниями (trace cache) как у Pentium 4. В Nehalem можно найти ряд инноваций, появившихся с архитектурой NetBurst, поскольку команда в Хиллсборо (Hillsboro), отвечающая за Nehalem, занималась и проектом Pentium 4. Однако если Pentium 4 использовал Cache с отслеживаниями эксклюзивно, поскольку он мог рассчитывать только на один декодер в случае промаха Cache, Nehalem выигрывает от мощи четырёх декодеров, хотя Loop Stream Detector можно назвать только дополнительной оптимизацией для некоторых ситуаций.

Исполнение инструкций.

Блоки, отвечающие за исполнение инструкций, в Nehalem оставлены практически без изменений. Из чего следует один простой вывод: в тех ситуациях, когда Core 2 и так успешно справляется с предвыборкой инструкций и данных, декодированием и предсказанием ветвлений — практически никакого преимущества все вышеперечисленные «новшества» Core i7 не дадут, и производительность его (при равной с Core 2 частоте) будет примерно такая же.

Однако некоторые изменения всё же были внесены, и связано это как раз с введением поддержки Hyper–Threading. Изменения, разумеется, самые что ни на есть очевидные: Reorder Buffer расширен до 128 микроопераций, Reservation Station – до 36 инструкций (было 32). Ну и буферы для данных, соответственно: Load с 32 до 48, Store – с 20 до 32. Для чего это нужно, также очевидно: чтобы увеличить количество команд и данных в очереди на исполнение, тем самым повысив вероятность того, что какие-то из них можно будет выполнить параллельно.