Я хочу изучить, чем последние процессоры отличаются от стандартной реализации RISC V (RISC V имеет 5 этапов конвейера - выборка, декодирование, память, ALU, обратная запись), но не могу найти, как мне начать подход к проблеме, чтобы найти текущая реализация конвейерной обработки на процессоре
Я попытался сослаться на документацию Intel по документации i7-4510U, но это не сильно помогло
Сообщается, что длина конвейера Haswell составляет 14 этапов (при попадании в uop-cache), 19 этапов при выборке из L1i для устаревшего декодирования. Единственный жизнеспособный способ найти его - это найти его в статьях об этой микроархитектуре. Вы не можете точно измерить это.
Многое из того, что мы знаем о внутреннем устройстве процессоров Intel и AMD, основано на презентациях производителей на конференциях по чипам, их руководствах по оптимизации и их патентах. Вы не можете по-настоящему измерить это с помощью тестов, но это связано со штрафом за неверное предсказание ветки. Обратите внимание, что каждый из конвейерных исполнительных модулей имеет свои собственные конвейеры, и конвейер памяти также как бы отдельный.
Ядра вашего процессора - это микроархитектура Intel Haswell. См. Подробное описание его внутреннего устройства Дэвидом Кантером: https://www.realworldtech.com/haswell-cpu/ < / а>.
Это суперскалярный дизайн не по порядку, а не простой по порядку, как классический RISC. о чем вы думаете. Обязательная справочная литература: 90-минутное руководство по современным микропроцессорам! охватывает эволюцию ЦП. архитектура от простого неконвейерного к конвейерному, суперскалярному и внеплановому исполнению.
Он имеет большие буферы между некоторыми этапами конвейера, а не только простую защелку; его предсказание ветвлений работает настолько хорошо, что обычно более полезно скрывать пузыри выборки путем буферизации нескольких байтов машинного кода. Поскольку нигде нет остановок, этап выдачи / переименования является самым узким местом в конвейере, поэтому интерфейсные буферы между этапами будут иметь тенденцию к заполнению. (В Haswell, как сообщается, выборка из uop-кеша также составляет всего 4 мопа за такт. Skylake расширил это число до 6, до целой строки кэша uop, считываемой в IDQ.)
https://en.wikichip.org/wiki/intel/microarchitectures/haswell_(client) сообщает о длине конвейера как 14-19 этапов, считая от выборки из кэша uop или из кеша L1i. (Попадания в кэш Uop сокращают эффективную длину конвейера, исключая декодирование.) https://www.anandtech.com/show/6355/intels-haswell-architecture/6 говорит о том же.
Также https://www.7-cpu.com/cpu/Haswell.html измерил штраф за неправильное предсказание на уровне 15,0 цикла для попадания в кэш-память uop, 18-20 циклов для промаха в кеш-память uop (попадание в кеш L1i). Это связано с длиной части конвейера.
Обратите внимание, что фактические исполнительные блоки в серверной части имеют свой собственный конвейер, например Каждый из модулей AVX FMA на портах 0 и 1 имеет длину 5 ступеней. (vmulps / vfma...ps задержка в 5 циклов на Haswell.) Я не знаю, считает ли эта длина 14-19 циклов всего конвейера выполнение за 1 цикл, потому что типичные целочисленные инструкции ALU, такие как add, имеют задержку только в 1 цикл. (И пропускная способность 4 / такт.) Более медленные целочисленные инструкции ALU, такие как imul, popcnt и bsf, могут выполняться только на порту 1, где они имеют задержку в 3 цикла.
Буфер хранилища также полностью разделяется сохранить фиксацию в кэше L1d от выполнения инструкций хранилища. Это может повлиять на задержку прерывания, если буфер хранилища заполнен кучей списанных хранилищ промахов кэша. После выхода из ROB их нельзя выбросить, и они обязательно должны произойти. Таким образом, они будут блокировать любое хранилище, созданное обработчиком прерывания, от фиксации до тех пор, пока оно не истощится. Или заблокируйте удаление любой инструкции сериализации (включая iret); Инструкции сериализации x86 определяются как очистка всего конвейера.
Размер буфера хранилища Haswell составляет 42 записи, и он может фиксироваться в кеш-памяти L1d со скоростью 1 / такт, при условии отсутствия промахов в кэше. Или многое другое с промахами в кеше. Конечно, буфер хранилища не является конвейером, физически это скорее всего кольцевой буфер, который считывается некоторой логикой, которая пытается зафиксировать заголовок в кеш-памяти L1d. Эта логика полностью отделена от исполнительных модулей хранилища (которые записывают адрес и данные в буфер хранилища). Таким образом, размер буфера хранилища влияет на то, сколько времени может потребоваться для опорожнения конвейера в общем смысле, но с точки зрения конвейера связанных этапов от выборки до вывода на пенсию это не совсем так.
Даже серверная часть выполнения вне очереди может иметь очень длинную цепочку зависимостей в полете, ждать которой потребуется много времени. например цепочка из sqrtsd инструкций может быть самым медленным занятием, которое вы можете встать в очередь. (Максимальная задержка на муп). например как в этом примере эксплойта Meltdown, который должен создать длинную тень для спекулятивного исполнения после сбоя. ** Таким образом, время осушения серверной части может быть намного длиннее, чем длина конвейера . (Но в отличие от буфера хранилища, эти ошибки можно просто отбросить при прерывании , откат к стабильному пенсионному состоянию.)
(Также относится к длинным цепочкам депов: Переупорядочиваются ли только команды загрузки и хранения? и Понимание влияния lfence на цикл с двумя длинными цепочками зависимостей для увеличения длины)
Длина трубопровода не имеет прямого значения. Важной для производительности характеристикой, связанной с длиной конвейера, является штраф за неверное предсказание перехода. См. Что именно происходит, когда ЦП Skylake неверно предсказывает ветвь?. (И я предполагаю, что это также часть штрафа за промахи I-cache; через какое время после того, как данные поступят из внешнего ядра, серверная часть может начать что-либо выполнять.) частично перекрывается медленной реальной работой в back-end. Избегайте остановки конвейера, вычисляя условное раннее время
То, что люди обычно пытаются измерить, - это штраф за неверное предсказание ветки. Если вам интересно, https://www.7-cpu.com/ имеет открытый исходный код. . Вы можете взглянуть на их код для тестирования.
lfence для осушения вышедшего из строя бэк-энда имеет неизвестные объемы накладных расходов, выходящие за пределы длины конвейера, поэтому вы не можете просто использовать это. Вы могли бы сделать большой блок из просто встык lfence, чтобы измерить пропускную способность lfence, но, не имея ничего между lfences, мы получаем примерно 1 за 4,0 цикла; Я предполагаю, потому что ему не нужно сериализовать интерфейс, который уже в порядке. https://www.uops.info/table.html.
Сам rdtsc работает довольно медленно, что делает написание микробенчмарков дополнительной проблемой. Часто вам приходится помещать что-то в цикл или развернутый блок и запускать его много раз, поэтому накладные расходы по времени становятся незначительными.
Стандартные реализации RISC-V включают в себя ядро без конвейера, ядра с конвейером с 2, 3 и 5 этапами, а также реализацию вне очереди. (https://riscv.org//wp-content/uploads/2017/05/riscv-spec-v2.2.pdf).
Он не должен быть реализован как классический 5-ступенчатый RISC, хотя это сделало бы его очень похожим на классический MIPS и было бы нормальным для обучения архитектуре ЦП и конвейерной обработке.
Обратите внимание, что для классического конвейера RISC (с 1 этапом памяти и вычислением адреса в EX) требуется задержка доступа L1d в 1 цикл, так что это не очень подходит для современных высокопроизводительных проектов с высокими тактовыми частотами и большими кешами. например У Haswell задержка загрузки L1d составляет 4 или 5 циклов. (См. Есть ли штраф, когда база + смещение находится на другой странице, чем базовая? подробнее о четырехцикловом ярлыке для особого случая, когда он угадывает конечный адрес для запуска поиска TLB параллельно с генерацией адреса.)
