Подождите...Каталог
Улучшения в Loop Stream DetectionОдним из блоков, благодаря которым Core 2 работает быстро, является Loop Stream Detector (LSD). Забавное название ничего общего с наркотиками не имеет, а означает всего-навсего невинное “обнаружение зацикленных потоков”. Эта логика контролирует исполняемый код, и, как только находится незавершающийся цикл без выхода, прерывает предсказание ветвлений, останавливая неправильные безрезультатные действия:   Нельзя не отметить и улучшения, коснувшиеся стек-буфера, также напрямую относящиеся к предсказанию ветвлений. Ранее при ошибках в предсказаниях, которые случались даже несмотря на сложные алгоритмы, в возвратный стек Penryn (структура, следящая за тем, в какой области памяти должно начаться исполнение после обработки функции) попадали неверные данные. Теперь же обновленный возвратный буфер стал интеллектуальнее и препятствует неверному заполнению данных, тем самым удается избежать лишних ошибок и простоя при неверном предсказании условных переходов. Следует заметить, что все вышеназванные усовершенствования направлены в первую очередь на улучшение работы процессора в тяжелых серверных приложениях (Intel приводит пример баз данных), где особо критичны неверное предсказание ветвлений или лишние исполненные такты, пропущенные блоком LSD. Дело в том, что уже с моменты выхода K8 позиции Intel в серверном сегменте не были однозначно убедительными, и если превосходство Core 2 в десктопном сегменте было неоспоримо, консервативные корпоративные пользователи продолжали доверять AMD, выбирая серверы на K10. Nehalem призван исправить такой порядок вещей, и, несмотря на то, что произведенные модернизации несомненно окажут положительный эффект на быстродействие процессора при выполнении стандартных “домашних” задач, продиктованы они были именно серверными нуждами. К слову, этот момент достаточно интересен. Ведь если вспомнить историю, в большинстве поколений изначально все нововведения делались с оглядкой на наиболее производительные серверные решения. Затем новинки переходили в разряд стандартов для десктопов. С Core же ситуация абсолютно иная, как мы уже говорили, истоки архитектуры восходят к Pentium M, т.е. серверные решения стали следствиями нововведений в мобильной сфере. Теперь все снова возвращается “на круги своя” и серверный Nehalem становится законодателем мод для обычных ПК. Немаловажным достоинством архитектуры Nehalem является неукоснительное следование инженерами Intel золотому правилу соотношения производительности на ватт при проектировке CPU, которое они сами для себя же и установили при разработке Core. В цифрах выражается это правило просто – 1% рост энергопотребления должен соответствовать как минимум 2% повешения производительности. При этом если задуманное улучшение не соответствует таким пропорциям, от его введения либо полностью отказываются, либо кардинально перерабатывают. Правила жесткие, однако это позволяет избежать неконтролируемого роста потребляемой мощности при несоразмерном улучшении производительности, как в свое время было с Pentium 4 Prescott. [N6-Доработанная исполнительная логика] Что касается части ядра процессора, отвечающей за исполнение команд, как и в случае с конвейером серьезных изменений относительно Penryn сделано не было:   [N7-Новый TLB, быстрый доступ к инструкцям в кэше с неопределенным размером] Исторически так сложилось, что именно серверные приложения, такие как уже упомянутые базы данных, по максимуму используют логику трансляции виртуальных адресов памяти в физические, что и является основной работой TLB. Вспоминая о серверной направленности Nehalem, мы не удивляемся, видя в списке нововведений обновленный юнит TLB. Помимо простого увеличения размеров буфера страниц первого уровня, инженеры Intel применили при модернизации TLB тот же прием, что и при улучшении блока предсказания ветвлений – “надстроили” второй унифицированный уровень Translation Lookaside Buffer, отвечающий и за данные, и за код.  Когда компиляторы при обработке исходного кода не могут гарантировать попадание в 16-байтные границы, процессоры Core 2 получают серьезные просадки производительности, даже тогда, когда выполняется операция незаданного размера над данными известного объема. Этому должен препятствовать внутренний 64-байтный микробуфер для хранения обработанных 16-байтных контейнеров, но и на него накладываются ограничения по сложности инструкций. Ранее разработчикам приходилось писать дополнительный код, специально нацеленный на программное исправление данного явления. Теперь же в этом нет нужды – в Nehalem Intel удалось не только полностью избавиться от проблем при исполнении операций неизвестного размера над данными известного, но и кардинально снизить падение скорости, когда не определены ни размеры инструкции, ни данных. Даже если при компиляции всегда будут использованы операции необъявленного размера (кстати, это стандартная настройка во многих средах разработки), или же декодер каждый раз будет натыкаться на блоки свыше 16 байт, это не приведет к серьезным потерям производительности, а программистам сэкономит время.  [N8-Новое поколение Hyper Threading] Много времени утекло с того момента, когда корпорация Intel впервые представила процессоры Pentium 4 с первой версией технологии Hyper Threading. Когда еще не было прямых предпосылок к увеличению количества ядер в домашних ПК, Intel уже предопределяла будущее индустрии микропроцессоров, подготавливая программистов к “параллельному” будущему. HT – маркетинговое название технологии SMT (Simultaneous Multi-Threading, одновременная многопоточность), предполагающей благодаря специальным механизмам исполнение за один такт инструкций из двух потоков. Операционная система определяет ПК с Hyper Threading как многопроцессорную конфигурацию, разделяя команды в несколько линий (в случае с P4 – одно ядро могло обрабатывать две линии). При проектировании Core от HT решено было отказаться, ведь даже сейчас для большинства домашних потребностей достаточно и двух ядер. Сегодня Hyper Threading возвращается в Nehalem (опять же – серверная ориентация, только профессиональные приложения получают существенный прирост даже от увеличения количества физических ядер), однако теперь производительность новой инкарнации HT будет на порядок выше первой версии. На это есть несколько причин:
  [N9-Иерархия кэш-памяти] Вообще говоря, красноречиво говорит за себя данный слайд:  Кэш ядер L1 располагает таким же объемом, как и Penryn, однако скорость его работы снижена (3 такта против 4). Intel пришлось замедлить кэш L1, так как он серьезно ограничивал общую тактовую частоту CPU. Конечно, такое решение было принято после многочисленных исследований производительности. С учетом большой площади кристалла процессора и его общей сложности оказалось, что намного лучше принести в жертву низкие задержки кэша, нежели ограничивать верхнюю планку частоту. По данным Intel увеличение задержек L1 на треть приводит к потери всего 2-3% производительности. Придется проверить на слово, инструментов для проверки таких заявлений нет. L2 сравнивать напрямую с предшественниками особого смысла нет, ведь в предыдущих реализациях архитектуры Core основной массив набортной памяти ядер являлся как раз общим кэшем второго уровня, теперь же такую функцию выполняет L3, а L2 является локальным для каждого ядра, урезан с 6 Мб до 256 Кб и обладает задержкой в 10 тактов. Фактически, L2 является неким дополнительным буфером кэша L3, который сдерживает при нехватке данных одновременное обращение всех ядер в L3 (мгновенная потребность в огромной внутренней ПСП вполне может привести у резкому падению производительности). Как мы уже упоминали, L3 является общим для всех ядер и выполняет старые функции L2. В первых процессорах Core i7 его объем будет составлять 8 Мб, однако Intel уже сейчас говорит о том, что эта характеристика будет варьироваться в зависимости от количества процессорных ядер. В Bloomfield наличие 8 Мб L3 оправдано тем, что многопоточные приложения всегда получают прирост от большого объема кэша, доступ к которому есть у всех ядер. Следуя традициям, Intel сохраняет инклюзивную структуру кэша в Nehalem. Иными словами, в L3 содержатся все данные из L1 и L2. Очевидным достоинством такого подхода является то, что данные L1+L2 пропорционально занимают не так много места с учетом большого объема L3, при этом если ядро обращаясь в L3 не находит там нужных данных, не происходит дополнительных запросов в L1 и L2 других ядер. Это не только повышает производительность, но и снижает энергопотребление CPU. К тому же не стоит забывать, что если бы кэш третьего уровня был не инклюзивным, уже в Quad-Core процессоре каждое ядро искало бы данные в памяти трех других, что уж говорить о 8ми-ядерных конфигурациях Nehalem. [N10-Сниженное энергопотребление кэш-памяти] Еще одним фактом о Nehalem, который стал известен на IDF, является переход к использованию восьмитранзисторных ячеек (8-T) памяти SRAM для формирования массива кэша первого и второго уровней (L3 построен по старым нормам). Основное преимущество данного подхода состоит в снижении необходимого минимального напряжения для функционирования памяти, что в конечном итоге снижает энергопотребление, хотя и увеличивает площадь ядра. Нечто схожее было сделано и при проектировании Atom: “Вместо того чтобы поднимать напряжение и формировать небольшой массив из сигналов, в Intel применили специальный регистровый файл с одним портом на запись и одним на чтение, требующий меньшее напряжение для функционирования. Кэш теперь обладает большим размером ячеек (8 транзисторов на микро-матрицу), что позволяет без значимых затрат энергии сохранить приемлемый размер кэшей инструкций и данных L1. Но, так как при создании Atom приоритет отдавался энергопотреблению, все же пришлось, однако, несколько урезать быструю память и сделать L1 ассиметричным – 24Кб/32Кб. Только так оказалось возможным удержать планку уровня энергопотребления на низком уровне”. Итак, в Nehalem так же, как и в Atom, применены ячейки 8T для кэшей L1 и L2. Сделано это потому, что L1 и L2 занимают относительно мало места, и для них более чем рентабельно еще немного увеличить площадь, но при этом снизить минимальное необходимое ядру напряжение. С другой стороны массивный L3 и так огромен, расширять его неоправданно. Намного проще, заботясь об энергопотреблении, например, запитать его от отдельного канала. Как вы увидите дальше, Intel так и поступила, разделив питание ядер и остальных частей CPU.  |
Источник: www.anandtech.com/