что такое hardware prefetcher в биосе
Железный сайт
В разделе Advanced Вы можете включить / отключить все функции CPU, такие как C1E, SpeedStep, Turbo Mode, C-STATE, а также интегрированные устройства: аудио, LAN, FireWire, eSATA, RAID и т.д.
Ниже приводится краткое описание основных функций относящихся к процессору:
Также Вы можете допустить / отключить многочисленные светодиоды, размещенные на материнской плате и даже логотип RoG, на центральном радиаторе. Данная возможность позволит Вам немного сэкономить на энергопотреблении, ведь если Вы будете использовать плату в корпусе, то толку от данных «фишек» практически нет.
Раздел Power содержит настройки управления питанием, связанные с энергосбережением в режиме ожидания. Так как эта модель относится к серии ROG, в данном разделе широко представлен раздел мониторинга температур и напряжений материнской платы.
Основное назначение раздела Boot это установка устройства для начальной загрузки. Также здесь Вы можете установить пароли и отключить логотип при загрузке.
Раздел Tools содержит подраздел Speeding HDD Configuration для организации RAID на двух красных портах SATA. Также в данном разделе размещается ASUS O.C. Profile для сохранения пользовательских профилей с настройками BIOS под различные нужды. Как уже отмечалось, данные профили могут быть перенесены на другую плату Maximus III Formula. Опция MemPerfect позволяет установить проверить установленные Вами настройки памяти на наличие ошибок.
Резюмируя возможности BIOS можно сказать, что она соответствует материнской плате из серии ROG. Большой выбор параметров для разгона, широкие возможности мониторинга и множество дополнительных инструментов.
Adjacent cache line prefetch что это
Привет. Quiet Boot — настройка, которая позволяет выполнить тихую загрузку без вывода служебной информации. При включении ПК запускается поверхностный тест железа — POST (Power-On Self-Test), при котором проверяется работа главных устройств.
В некоторых материнках есть интересная функция — при проверке POST, когда проверяется определенное устройство, возле него загорается светодиод. Вот у меня плата Asus Gryphon Z87 и такая фишка есть, скажу что мелочь, а приятно)
Будьте осторожны при изменении параметров биоса — если не знаете, лучше пусть стоит по умолчанию, чем пытаться сделать лучше. Особенно осторожно с опциями, в названии которых есть слова CPU, GPU, Voltage, FSB, DRAM, RAM, Memory. Если возникли какое-то проблемы, то сбросьте настройки при помощи пункта Load Setup Defaults (может быть в разделе Exit).
Если включить Quiet Boot, то при проверке POST на экране может быть отображен логотип производителя материнской платы или биоса. Логотип производителя можно отключить. В таком случае предположительно будет отображено лого производителя биоса, например Phoenix.
Quiet Boot не ускоряет запуск ПК, а убирает вывод служебной информации от проверки POST.
Как выглядит Quiet Boot в биосе
Нужно ли включать? Честно сказать даже не знаю. С одной стороны включение избавит от лишней информации. С другой — эта информация ничем не мешает и отключение ее вывода не повлияет на скорость загрузки. Поэтому мой совет — не выключать. Просто нет смысла.
Обычно Quiet Boot имеет два значения — Enable (включено) и Disable (отключено).
Еще есть опция Quick Boot — если включить то начальные тесты проводиться не будут и время загрузки может сократиться. Опцию нужно включать если вы добавили новое устройство, или убрали, или заменили — тогда нужно включить опцию, чтобы заново протестировать конфигурацию ПК. Стоит ли включать? Нужно поэкспериментировать — если скорость загрузки заметно возрастет, то можно оставить включенной. Если разницы нет — лучше отключить Quick Boot.
Hardware Prefetcher что это в биосе?
Hardware Prefetcher — механизм аппаратной предвыборки инструкций и данных из оперативной памяти. Используется для предсказывания дальнейших операций. Инструкции для процессора записываются в кэш второго уровня. В принципе современные процессоры при помощи данной технологии работают действительно заметно быстрее.
Отключать опцию Hardware Prefetcher нет смысла. Но пункт отключения сохранился со времен процессоров Pentium 4 — в некоторых моделях происходил аппаратный сбой при использовании Hardware Prefetcher.
Производство процессоров сегодня уже как бы.. достигло потолка в плане частоты. Ну сколько? 5 ГГц для дома — как бы потолок. Но производительность нужно наращивать дальше, не стоять же на месте. Вот и, помимо количества ядер, создаются технологии предсказания команд, инструкций, предварительная подготовка данных для дальнейшего использования. Среди новшеств, как по мне, так это еще память eDRAM, которая есть в процессоре i5-5675C и i7-5775C — улучшила производительность. Жаль что потом почему-то в следующих процессорах памяти этой нет. Эта память — что-то вроде кэша процессора, обьем которой 128 мб.
Опция Adjacent Cache Line Prefetch в биосе
Это тоже опция, которая помогает ускорить работу процессора. Но тут очень интересно все и просто — процессор запрашивает определенный обьем данных из оперативной памяти, длиной в 64 байт. Эти данные процессору отправляются. Но вслед за ними отправляются и следующие 64 байт данных, так бы сказать тех, которые рядом стоят. Есть высокая вероятность, что в следующий раз процессор запросит именно их.
Возможно управление этой опцией поддерживается программой RightMark Memory Analyzer:
Лично у меня недоверие к программам, которые могут менять настройки в биосе. Как-то это не по фен-шую что ли. Настройки биоса меняются только в биосе, но это сугубо мое личное мнение) Также мне кажется несерьезным разгон процессора не через биос, а при помощи программы..
Adjacent Cache Line Prefetch можно встретить как в биосе старого образца, так и нового
На этом все, надеюсь информация была полезной — удачи вам!
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
Тема измерения латентности оперативной памяти на платформах с процессорами семейства Intel Pentium 4 затрагивалась нами неоднократно. Ничего удивительного в этом нет проблема имеет место быть, объективно измерить латентность памяти с этими процессорами весьма затруднительно ввиду значительных ухищрений, реализованных производителем, особенно в последних ядрах процессоров Prescott/Nocona с целью сокрытия этой самой «латентности» т.е. задержек при доступе к оперативной памяти. Под этими ухищрениями мы прежде всего имеем в виду алгоритм аппаратной предвыборки (Hardware Prefetch) данных из памяти как таковой (детали реализации которого неизвестны), а также его важнейшую особенность предвыборку сразу двух строк кэша из памяти в L2-кэш процессора.
Последняя «официальная» методика, изложенная в статье «DDR2 грядущая замена DDR. Теоретические основы и первые результаты низкоуровневого тестирования», насчитывает примерно полгода и успешно применялась нами на протяжении всего этого времени. Ничего не мешает ей существовать и дальше в качестве одной из возможных методик оценки латентности оперативной памяти в реальных условиях. Поэтому изложим основную суть этой методики.
Итак, главная трудность измерения латентности памяти на рассматриваемой платформе обусловлена двумя отмеченными выше обстоятельствами: наличием у процессора механизма Hardware Prefetch и предвыборкой сразу двух соседних 64-байтных строк из памяти в кэш процессора.
Приведенный выше рисунок поясняет суть проблемы. На нем представлена зависимость латентности чтения двух 32-битных элементов из оперативной памяти от расстояния между этими элементами (в байтах). Именно такой тест используется программным пакетом RMMA в качестве внутреннего метода определения эффективной длины строки L2-кэша, которая в нашем случае составляет 128 байт. Предвыборка двух 64-байтных строк видна во всех случаях величины латентности прямого и обратного линейного, псевдослучайного и случайного обхода лишь незначительно возрастают при превышении расстояния между элементами в 64 байта. Дальнейшее возрастание латентностей от 128 байт и выше протекает совершенно неочевидным образом. И здесь виновато другое обстоятельство (первое по списку): наличие алгоритма аппаратной предвыборки.
Достаточно четко и предсказуемо картина выглядит лишь при полностью случайном обходе, таким образом, наиболее корректные значения латентности следовало бы ожидать именно в этом случае, если бы не еще одно «но». На сей раз довольно малый размер буфера трансляции виртуальных адресов памяти в физические адреса (D-TLB). Дело в том, что истинно случайный обход памяти исчерпывает его очень быстро. Ведь загрузка страниц памяти в этом случае также полностью случайна, таким образом, D-TLB может эффективно «кэшировать» количество страниц, не превышающее его собственный размер. Получаем всего 128 (размер буфера) x 4 (размер страницы) = 512 КБ памяти. А в тесте используется сравнительно большой 16-МБ блок… Нетрудно посчитать, что процент промахов D-TLB в этом случае будет составлять (16384 512) / 16384 = 96.88%, что обходится данному семейству процессоров весьма и весьма «дорого». Заметим, что данное ограничение не относится к линейным режимам обхода, где замещение записей в D-TLB идет последовательно и плавно. Отсутствует оно и при псевдослучайном обходе с той целью он и разрабатывался. В этом методе загрузка страниц из памяти идет прямо и последовательно, а обход элементов страницы полностью случаен.
Учитывая изложенную выше теоретическую базу, в нашей первой «официальной» методике было решено использовать следующие параметры для теста латентности оперативной памяти.
Название пресета: Minimal RAM Latency, 16MB Block, L2 Cache Line
Размер блока: 16 МБ
Размер шага: эффективная длина строки L2-кэша (128 байт для Pentium 4)
Режим обхода: псевдослучайный
Использование данного режима позволяет получить примерно следующий результат.
Кривые псевдослучайного и случайного обхода сохраняются на почти постоянном уровне, т.е. эффективность алгоритма Hardware Prefetch не изменяется при увеличении разгрузки Bus Interface Unit (BIU) процессора. В отличие от кривых прямого и обратного линейного обхода памяти, где разгрузка шины явно увеличивает эффективность Hardware Prefetch. На основании анализа этих данных в свое время был сделан вывод о том, что измерение латентности памяти данным образом (используя данные псевдослучайного обхода) можно считать вполне адекватным.
Итак, вроде бы все хорошо что же еще можно придумать, чтобы обмануть весьма хитрый алгоритм предвыборки, и зачем? Начнем с вопроса «что». Обмануть алгоритм Hardware Prefetch, пожалуй, уже никак нельзя, но можно ведь… совсем отключить аппаратную предвыборку! Такая возможность заложена во всех процессорах Pentium 4 и Xeon, но соответствующие настройки в BIOS доступны, как правило, только для последних. С них-то все и началось, мы решили провести небольшое исследование влияют ли они на результаты тестов, и если да, то как оказалось, что очень даже влияют! В связи с чем, в новой версии RMMA 3.45 было решено добавить их в виде отдельной закладки (в последнее время мы очень любим «играться» со специфическими настройками процессоров Pentium 4). Вот как выглядит эта закладка.
Сразу отметим: данные настройки рассчитаны исключительно для тестовых целей, о чем говорится в самой программе. Для нормального режима работы процессора в частности, и всей системы в целом трогать их не рекомендуется. Опишем вкратце каждую из них.
Hardware Prefetch Queue (Enabled/Disabled) включение/выключение очереди аппаратного префетчера, проще говоря механизма аппаратной предвыборки данных из памяти.
Adjacent Cache Line Prefetch (Enabled/Disabled) включение/выключение режима предвыборки смежной строки. В случае Disabled осуществляется предвыборка только одной (содержащей запрашиваемые данные) 64-байтной строки 128-байтного сектора, в случае Enabled обе строки вне зависимости от наличия/отсутствия необходимых данных.
L1 Data Cache Context Mode (Adaptive/Shared) изменение режима работы L1-кэша данных процессора. Эта настройка практически на результаты теста латентности памяти влиять не должна, тем не менее, она явно относится к тому, с чем имеет дело тестовый пакет RMMA. Данная настройка доступна только для процессоров с технологией Hyper-Threading и задает способ использования L1-кэша данных процессора логическими процессорами. В случае Shared L1-кэш представляется логическим процессором в полном объеме, но содержит данные, принадлежащие обоим процессорам. В режиме Adaptive каждый логический процессор получает свою часть L1-кэша, содержащую данные только этого логического процессора, размер которой варьируется по мере необходимости.
Заметим, что настройки применяются лишь к данному системному процессору, номер которого задается выбором CPU Index. В случае «истинных» многопроцессорных систем (SMP) рекомендуется применять одинаковые настройки для всех физических процессоров. Для систем с технологией Hyper-Threading, напротив, достаточно изменить настройки одного из логических процессоров (любого), составляющих физический процессор.
Итак, отметим главное: отныне у нас есть способ отключить обе особенности механизма аппаратной предвыборки данных: как сам алгоритм, так и предвыборку смежной строки (которая, заметим, может осуществляться независимо от использования Hardware Prefetch).
Последовательность действий для измерения латентности памяти вторым методом будет выглядеть следующим образом.
Размер блока: 16 МБ
Размер шага: эффективная длина строки L2-кэша (128 байт для Pentium 4)
Режим обхода: псевдослучайный
Результат весьма интересный. Кривая случайного обхода осталась почти без изменений как качественных, так и количественных. Следовательно, в случае истинно случайного доступа к памяти Hardware Prefetch действительно практически не работает, даже если он включен. Но… как же быть с псевдослучайным обходом? Качественно соответствующая кривая выглядит так же, как и ранее, но количественно… «поднялась» примерно на 30 нс вверх! Вывод? Hardware Prefetch, когда он включен, работает с некоторой эффективностью и при псевдослучайном обходе! По-видимому, имеет место предвыборка на уровне целых страниц памяти. Избежать которую можно только двумя способами: либо использовать истинно случайный обход (но здесь вспоминаем накладываемые ограничения размера D-TLB), либо отключить предвыборку вообще. Другое дело, а есть ли в этом необходимость?
Вот мы и подходим к другому заданному выше вопросу «зачем». Какие результаты следует считать более «правильными» с аппаратной предвыборкой, или без таковой? Иными словами, нужно ли отключать Hardware Prefetch на время измерения? Ответ на этот вопрос будет предельно прост: все зависит от того, что мы хотим измерить. Если нам требуется оценить реальные задержки при чтении процессором данных из памяти в одной из моделируемых тестом ситуаций прямого, обратного, случайного или псевдослучайного обхода блока памяти (первые две из которых соответствуют кодированию видео или какой-либо другой потоковой обработке данных, а две последних например, поиску в базе данных) то следует остановиться на первом варианте. Именно этот вариант будет отражать действительность, т.е. стандартный режим работы процессора: Hardware Prefetch включен, а считывание данных из памяти осуществляется по 128-байтным секторам, составляющим две строки кэша процессора. Резюмируя, первый метод позволяет нам оценить реальную латентность подсистемы памяти в целом, т.е. включая функциональные блоки процессора, ответственные за обмен данными с оперативной памятью.
Если же нам требуется оценить некую характеристику, ближе соответствующую истинным задержкам при доступе к массиву ячеек памяти, нам больше подойдет вторая методика. Ибо она охватывает более узкую часть подсистемы памяти непосредственно носитель (микросхемы модулей), а также чипсет, таким образом, она позволяет оценить задержки при доступе в память безотносительно возможностей процессорного интерфейса, осуществляющего обмен с памятью (BIU).
Наконец, можно использовать комбинированную методику, сочетающую оба метода: измерение латентности псевдослучайного доступа к 16-МБ блоку со 128-байтовым шагом сначала с Hardware Prefetch, затем без него. И использовать полученный интервал значений в качестве оценки возможных реальных задержек при доступе к подсистеме памяти в различных ситуациях.
Навигация
Официальный сайт Superfetch
Новости
22 октября, 2018
По просьбе пользователей, мы описали основные причины: Почему зависает или тормозит компьютер, и что с ним делать?
16 октября, 2018
Мы выпустили вторую версию программы superfetch.exe. Теперь можно отключить: SuperFetch, Prefetch, ReadyBoot, это возможно существенно ускорит скорость работы Вашего компьютера!
28 Сентября, 2018
Мы выпустили первую версию программы superfetch 1.00 для быстрого включения/отключения superfetch.
Ждем Ваших отзывов и предложений!
Что такое prefetch и почему его отключают?
Изначально служба prefetch разрабатывалась как отдельный компонент ОС Windows (начиная с ОС Windows XP) для ускорения запуска системы и приложений. Все это было в далеком 2001 году. Представляете конфигурацию компьютеров в те времена?
Теперь вернемся в наш 2018 год.
Проблема кэширования данных уже давно решена на аппаратном уровне и заложена в любой жесткий диск с магнитным накопителем. Где для кэширования данных есть собственная память, объем которой рассчитывается исходя из скорости вращения диска, чтобы соответсвовать максимальной пропускной способности для интерфейсов подключения (IDE, далее SATA и прочие).
Почему надо отключать эту службу? Служба prefetch (в списке служб она называется prefetcher) наблюдает за запуском приложений и создает файлы трассировки оптимизации кода. Эта сложная структура кэша исполняемого кода, которая собирается ограниченное время (10 секунд после запуска) и подставляется в память при повторном запуске приложений. Отключают эту службу потому, что время потраченное на создание трассировки, намного больше, чем время и скорость считывания данных с современных жестких дисков. Тем более появились более быстрые SSD диски.
Microsoft в принудительном порядке отключает prefetch на собственных планшетах линейки Surface.
Так как, это обусловлено экономией места на накопителях и увеличением производительности системы! Почему Microsoft не дает возможность отключать самостоятельно prefetch — загадка, скорей всего это делается в маркетинговых целях.
Superfetch
Навигация
Официальный сайт Superfetch
Новости
22 октября, 2018
По просьбе пользователей, мы описали основные причины: Почему зависает или тормозит компьютер, и что с ним делать?
16 октября, 2018
Мы выпустили вторую версию программы superfetch.exe. Теперь можно отключить: SuperFetch, Prefetch, ReadyBoot, это возможно существенно ускорит скорость работы Вашего компьютера!
28 Сентября, 2018
Мы выпустили первую версию программы superfetch 1.00 для быстрого включения/отключения superfetch.
Ждем Ваших отзывов и предложений!
Что такое prefetch и почему его отключают?
Изначально служба prefetch разрабатывалась как отдельный компонент ОС Windows (начиная с ОС Windows XP) для ускорения запуска системы и приложений. Все это было в далеком 2001 году. Представляете конфигурацию компьютеров в те времена?
Теперь вернемся в наш 2018 год.
Проблема кэширования данных уже давно решена на аппаратном уровне и заложена в любой жесткий диск с магнитным накопителем. Где для кэширования данных есть собственная память, объем которой рассчитывается исходя из скорости вращения диска, чтобы соответсвовать максимальной пропускной способности для интерфейсов подключения (IDE, далее SATA и прочие).
Почему надо отключать эту службу? Служба prefetch (в списке служб она называется prefetcher) наблюдает за запуском приложений и создает файлы трассировки оптимизации кода. Эта сложная структура кэша исполняемого кода, которая собирается ограниченное время (10 секунд после запуска) и подставляется в память при повторном запуске приложений. Отключают эту службу потому, что время потраченное на создание трассировки, намного больше, чем время и скорость считывания данных с современных жестких дисков. Тем более появились более быстрые SSD диски.
Microsoft в принудительном порядке отключает prefetch на собственных планшетах линейки Surface.
Повышение производительности с использованием uop-кэша на Sandy Bridge+
В современных x86 процессорах Intel конвеер можно разделить на 2 части: Front End и Back End.
Front End отвечает за загрузку кода из памяти и его декодирование в микрооперации.
Back End отвечает за выполнение микроопераций, пришедших от Front End. Поскольку эти микрооперации могут выполняться ядром не по порядку, то Back End также следит за тем, чтобы результат выполнения этих микроопераций строго соответствовал порядку в котором они идут в коде.
В большинстве случаев неэффективное использование Front End’a не оказывает заметного влияние на производительность. Пиковая пропускная способность на большинстве процессоров Intel — 4 микрооперации за такт, поэтому, например, для Memory/L3-bound кода ЦПУ не сможет полностью ее утилизировать.
Однако в некоторых случаях различие в производительности может быть достаточно существенно. Под катом — анализ влияния кэша микроопераций на производительность.
Содержание статьи
Окружение
Обзор Front End’a процессоров Intel
Высокоуровневая организация конвеера — публично доступная информация и опубликована в официальной документации Intel по оптимизации софта. Более детальное описание некоторых особенностей, которые опущены в официальной документации можно найти в других авторитетных источниках, таких как Agner Fog или Travis Downs. Так, например, схема конвеера для Skylake в документации Intel имеет вид:
Рассмотрим подробнее верхнюю часть данной схемы — Front End.
За декодирование кода в микрооперации отвечает Legacy Decode Pipeline. Он состоит из следующих компонентов:
Instruction Fetch Unit.
Отвечает за загрузку кода, предекодирование (определение длины инструкции и свойств типа «является ли инструкция ветвлением») и доставку в очередь пре-декодированных инструкций.
Кэш инструкций первого уровная — L1i
Для загрузки кода IFU использует L1i — кэш инструкций первого уровная и L2/LLC — кэш второго и offcore-кэш верхнего уровня, общие для кода и данных. Загрузка выполняется кусками по 16 байт, также выровненные на 16-байт. При загрузке следующего по порядку 16-байтного куска кода происходит обращение к L1i и, если соответствующая линия не найдена, то выполняется поиск в L2 и, в случае неуспеха, в LLC и памяти. До Skylake LLC кэш был инклюзивным — каждая линия в L1(i/d) и L2 должны была содержаться в LLC. Таким образом LLC «знал» про все линии во всех ядрах и, в случае LLC промаха было известно, содержат ли кэши в других ядрах требуемую линию в состоянии Modified, а значит данная линия могла быть загружена из другого ядра. В Skylake LLC стал не инклюзивным L2-victim кэшем, однако в 4 раза был увеличен размер L2. Мне неизвестно, является ли L2 инклюзивным по отношению к L1i. L2 не инклюзивный по отношению к L1d.
Кэш трансляций логических адресов инструкций — ITLB
The software-controlled prefetch is intended for prefetching data, but not for prefetching code.
Однако Travis D. упоминал, что подобный префетч может быть весьма эффектиным (и скорее всего это так и есть), но мне пока что это неочевидно и для того, чтобы в этом убедиться нужно будет отдельно исследовать этот вопрос.
Загрузка данных в кэш (L1d/i, L2, etc) происходит при обращении к незакэшированному участку памяти. Однако, если бы это происходило только при таких условиях, то в результате мы бы получили неэффективное использование пропускной способности кэша. Например, на Sandy Bridge для L1d — 2 операции на чтение, 1 на запись по 16 байт за такт; для L1i — 1 операция на чтение по 16 байт, пропускная способность на запись не указана в документации, у Agner Fog также не обнаружилось. Для решения этой проблемы существуют Hardware префетчеры, которые умеют определять паттерн доступа к памяти и подтягивать нужные линии в кэш до того, как код по факту к ним обратится. Документация Intel определяет 4 префетчера: 2 для L1d, 2 для L2:
У Agner Fog каких-либо деталей также не просматривается.
Префетч кода в L2/LLC явно определены только для Streamer. Optimization Manual/2.5.5.4 Data Prefectching:
Streamer: This prefetcher monitors read requests from the L1 cache for ascending and descending sequences of addresses. Monitored read requests include L1 DCache requests initiated by load and store operations and by the hardware prefetchers, and L1 ICache requests for code fetch.
Spatial Prefetcher: This prefetcher strives to complete every cache line fetched to the L2 cache with the pair line that completes it to a 128-byte aligned chunk.
Используя данный MSR можно исследовать вопрос реакции L2 Spatial на обращения из L1i. Я сам этого не проделывал. Выключение префетчеров я использовал для исследования различий в производительности при обработки больших массивов данных, не влезающих в LLC. В данном случае отключение L2 Streamer вызывало падение производительности в среднем в 2.5 раза.
После того как очередные 16-байт кода загружены, они попадают в пре-декодер инструкций. Его задача — определить длину инструкции, декодировать префиксы и пометить, является ли соответствующая инструкция ветвлением (скорее всего еще много разных свойств, но документация о них умалчивает). Intel Software Optimization Manual/2.6.2.2:
The predecode unit accepts the sixteen bytes from the instruction cache or prefetch buffers and carries out the following tasks:
Очередь пре-декодированных инструкций.
Из IFU инструкции складываются в очередь предекодированных инструкций. Данная очередь появилась начиная с Nehalem, в соответвствии с документацие Intel ее размер — 18 инструкций. Agner Fog также упоминает, что в эту очередь вмещается не больше 64 байт.
Также в Core2 данная очередь использовалась как кэш циклов (loop cache). Если все микрооперации из цикла содержатся в очереди, то в ряде случаев можно было бы избежать затраты на загрузку и предекодирование. Loop Stream Detector (LSD) может доставлять инструкции, которые уже есть в очереди до тех пор, пока BPU не просигналит, что цикл закончился. У Agner Fog есть ряд интересных замечаний касательно LSD на Core2:
Декодеры пре-декодированных инструкций в микрооперации
Из очереди пре-декодированных инструкций код поступает на декодирование в микрооперации. За декодирование отвечают декодеры — всего их 4. В соответствии с документацией Intel, один из декодеров умеет декодировать инструкции, состоящие из 4-х микроопераций и менее. Остальные декодируют инструкции состоящие из одной микрооперации (micro/macro fused), Intel Software Optimization Manual/2.5.2.1:
There are four decoding units that decode instruction into micro-ops. The first can decode all IA-32 and Intel 64 instructions up to four micro-ops in size. The remaining three decoding units handle single-micro-op instructions. All four decoding units support the common cases of single micro-op flows including micro-fusion and macro-fusion.
Инструкции, декодируемые в большое количество микроопераций (напр. rep movsb, используемая в реализации memcpy в libc на определенных размерах копируемой памяти) поступают из Microcode Sequencer (MS ROM). Пиковая пропускная способность секвенсера — 4 микрооперации за такт.
Как можно видеть на схеме конвеера, Legacy Decode Pipeline может декодировать до 5 микроопераций за такт на Skylake. На Broadwell и старше пиковая пропускная способность Legacy Decode Pipeline’a была 4 микрооперации за такт.
После того, как инструкции декодированы в микрооперации, из Legacy Decode Pipeline они попадают в специальную очередь микроопераций — Instruction Decode Queue (IDQ), а также в так называемый кэш микроопераций (Decoded ICache, µop cache). Кэш микроопераций изначально появился в Sandy Bridge и используется для того, чтобы избежать фетчинга и декодирования инструкций в микрооперации, повышая тем самым пропускную способность доставки микроопераций в IDQ — до 6 за такт. После попадания в IDQ, микрооперации уходят в Back End на выполнение с пиковой пропускной способностью 4 микрооперации за такт.
В соответствии с документацией Intel, кэш микроопераций состоит из 32-х сетов, каждый сет содержит по 8 линий, каждая линия может кэшировать до 6 микроопераций (micro/macro fused), позволяя в общей сложности кэшировать до 32 * 8 * 6 = 1536 микроопераций. Кэширование микроопераций происходит с гранулярностью в 32 байта, т.е. микрооперации, которые соответствуют инструкциям из разных 32-байтных регионов не могут попасть в одну линию. Тем не менее, одному 32-байтному региону может соответствовать до 3-х различных линий кэша. Таким образом каждому 32-байтному региону может соответствовать до 18 микроопераций в µop cache.
The Decoded ICache consists of 32 sets. Each set contains eight Ways. Each Way can hold up to six micro-ops. The Decoded ICache can ideally hold up to 1536 micro-ops. The following are some of the rules how the Decoded ICache is filled with micro-ops:
Agner Fog также упоминает, что за такт может быть загружены микрооперации только из одной линии (явно не прописано в документации Intel, хотя и легко проверяется в ручную).
Для тестирования пропускной способности объявим функцию
с реализацией на nasm :
Для замеров нам понадобятся следующие perf эвенты:
1. uops_issued.any — Используется для подсчета микроопераций которые Renamer забирает из IDQ.
Intel System Programming Guide документирует этот эвент как количество микроопераций, которые Renamer кладет в Reservation Station:
Counts the number of uops that the Resource Allocation Table (RAT) issues to the Reservation Station (RS).
2. uops_retired.retire_slots — итоговое количество retired микроопераций с учетом micro/macro-fusion
3. uops_retired.stall_cycles — количество тактов, за которые не было ни одной retired микрооперации
4. resource_stalls.any — количество тактов простаивания конвеера по причине недоступности любого из ресурсов Back End
В Intel Software Optimization Manual/B.4.1 приведена содеражательная схема, которая характеризует описанные выше эвенты:
5. idq.all_dsb_cycles_4_uops — количество тактов, за которые из µop cache было доставлено по 4 (и более) инструкции.
То, что данная метрику учитывает доставку более 4х микроопераций за такт — не прописано в документации Intel, однако очень хорошо согласуется с экспериментами.
6. idq.all_dsb_cycles_any_uops — количество тактов, за которые доставлялась хотя бы одна микрооперация.
7. idq.dsb_cycles — Итоговое количество тактов, при которых была доставка из µop cache
8. idq_uops_not_delivered.cycles_le_N_uop_deliv.core — Количество тактов, за которые Renamer забирал по N или меньше микроопераций и не было простоя на стороне Back End, N — 1, 2, 3.
Что сразу бросается в глаза, так это проседание пропускной способности retirement’a при размере цикла в 7 микроопераций. Для того, чтобы понять в чем дело, рассмотрим как меняется средняя скорость доставки из µop cache — idq.all_dsb_cycles_any_uops / idq.dsb_cycles :
и как связаны общее количество тактов и тактов за которые µop cache доставлял в IDQ:
Таким образом можно заметить, что при цикле из 6 микроопераций мы получаем эффективное использование пропускной способности µop cache — 6 микроопераций за такт. В силу того, что Renamer не может забрать столько, сколько доставляет µop cache, то часть тактов µop cache ничего не доставляет, что хорошо видно на предыдущем графике.
При цикле из 7 микроопераций мы получаем резкое падение пропускной способности µop cache — 3.5 микрооперации за такт. При этом, как видно из предыдущего графика, µop cache постоянно находится в работе. Таким оразом, при цикле размером в 7 микроопераций мы получаем неэффективную утилизацию пропускной способности µop cache. Дело в том, что, как было отмечено ранее, µop cache за такт может доставлять микрооперации только из одной линии. В случае, если микроопераций 7 — первые 6 попадают в одну линию, а оставшаяся 7я — в другую. Такими образом и получаем 7 микроопераций за 2 такта, или же 3.5 микрооперации за такт.
Рассмотрим теперь каким образом Renamer забирает микрооперации из IDQ. Для этого нам понадобятся idq_uops_not_delivered.core и idq_uops_not_delivered.cycles_le_N_uop_deliv.core :
Можно заметить, что при 7-ми микрооперациях, половину тактов Renamer забирает только 3 микрооперации за раз. Отсюда мы и получаем пропускную способность retirement’а в среднем 3.5 микрооперации за такт.
Другой интересный момент, связанный с данным примером можно увидеть, если рассмотреть эффективную пропускную способность retirement’а. Т.е. не учитывая uops_retired.stall_cycles :
Можно заметить, что при 7-ми микрооперациях, каждые 7 тактов выполняется retirement 4-х микроопераций, а каждый 8-й такт происходит простаивании с отсутствием retired микроопераций (retirement stall). Проведя ряд экспериментов, удалось обнаружить, что такое поведение наблюдалось всегда при 7-ми микрооперациях, вне зависимости от их компоновки 1-6, 6-1, 2-5, 5-2, 3-4, 4-3. Мне неизвестно, почему происходит именно так, а не, например за один такт выполняется retirement 3-х микроопераций, за следующий — 4-х. Agner Fog упоминал, что переходы по ветвлениям могут использовать только часть слотов retirement station. Может быть это ограничение и есть причина такого поведения retirement’а.
Пример
Даны два массива unsigned ‘ов. Необходимо накопить сумму средних арифметических для каждого индекса и записать ее в третий массив.
Пример реализации может выглядеть следующим образом:
Скомпилируем с gcc-флагами
Вполне очевидно, что функция arithmetic_mean не будет присутствовать в коде и будет вставлена напрямую в main :
Заметим, что компилятор выравнил код цикла на 32 байта ( nop DWORD PTR [rax+0x0] ), а это как раз то, что нам нужно. Убедившись в отсутствии resource_stalls.any на Back End (все замеры выполнены с учетом прогретого L1d кэша) можно приступать к рассмотрению каунтеров, связанных с доставкой в IDQ:
Заметим, что retirement badwidth в данном случае = 15147004678 / 4724790623 = 3.20585733562, а также, что половину тактов Renamer забирает только по 3 микрооперации.
Добавим теперь ручную раскрутку цикла в реализацию:
Получившиеся перф каунтеры имеют вид:
В данном случае имеем retirement bandwidth = 13037919196 / 3444833440 = 3.78477491672, а также эффективную утилизацию пропускной способности Renamer.
Таким образом мы не только избавились от одного ветвления и одной операции инкремента в цикле, но и увеличили retirement bandwidth используя эффективную утилизацию пропускной способности кэша микроопераций, что дало итоговые 28% прироста к производительности.
Заметим, что только лишь сокращение одного ветвления и операции инкремента дает прирост производительности в среднем на 9%.