Внеочередное исполнение против спекулятивного исполнения

Я прочитал страницу wikipedia об исполнении вне спектакля и спекулятивной эксплоатации .

То, что я не понимаю, – это сходства и различия. Мне кажется, что спекулятивное выполнение использует исполнение вне порядка, когда оно не определило значение условия, например.

Смятение пришло, когда я прочитал статьи Meltdown и Spectre и сделал дополнительные исследования. В документе Meltdown указывается, что Meltdown основан на исполнении вне порядка, в то время как некоторые другие ресурсы, включая страницу вики-информации о спекулятивном исполнении, указывают, что Meltdown основан на спекулятивном исполнении.

Я хотел бы получить разъяснения по этому поводу.

Добро пожаловать в Quagmire

Вы найдете много статей, которые рассматривают спекулятивное выполнение как некое исполнение вне порядка (также называемое динамическим исполнением или динамическим планированием). Я могу найти это среди лучших результатов поиска:

Спекулятивное выполнение – это метод, который разработчики процессоров используют для повышения производительности процессора. Это один из трех компонентов исполнения вне порядка, также называемый динамическим исполнением. Наряду с outlookированием нескольких ветвей (используется для outlookирования команд, которые, скорее всего, понадобятся в ближайшем будущем) и анализа streamа данных (используется для выравнивания инструкций для оптимального выполнения, в отличие от выполнения их в том порядке, в котором они вошли), спекулятивное выполнение резкое повышение производительности по сравнению с предыдущими процессорами Intel.

Это неверно.

Историческая перспектива

Существует много патентов, которые были поданы и / или предоставлены в 60-е и 70-е годы по предсказанию ветвлений и аналогичным спекулятивным методам. Я заметил, что все они предполагали конвейерное выполнение, но ни один из них не требует исполнения вне очереди (большинство даже не упоминает об этом). Набрав пару минут, я смог найти их:

Цифровой компьютер с высокоскоростным ветвлением, 1966 год.

Блок обработки инструкций для филиалов программ, 1966 год.

Поисковая система обнаружения ветвей 1968 года.

Устройство обработки данных, 1968. (обратите внимание на это).

Компьютер outlookирования ветвей, 1981 г.

Таблица истории декодирования для инструкций условной ветви, 1982.

Взаимосвязь между условиями в соответствии с патентной classификацией США

Согласно US Patent Classification , номер classа G06F9 / 38 относится к «одновременному исполнению команд». Это включает в себя конвейерную обработку, динамическое выполнение, спекулятивное выполнение и все, что похоже на подобные вещи. Номер подclassа G06F9 / 3836 относится к «выдаче инструкции». Это специфические параллельные методы планирования инструкций, такие как выполнение вне порядка. Номер подclassа G06F9 / 3842, который является родственным для G06F9 / 3836, относится к выполнению спекулятивных команд. Следовательно, согласно этой classификации, они ортогональны. Учитывая, что патенты США полагаются на очень серьезную правовую систему, я думаю, что могу сказать, что их classификация очень точная и очень тщательно.

обсуждение

Спекулятивное выполнение и исполнение вне порядка ортогональны . Можно было бы спроектировать процессор этого OoO, но не спекулятивный или спекулятивный, но в порядке. Я объясню, как это сделать. Выполнение OoO – это модель исполнения, в которой инструкции могут выполняться в порядке, который потенциально отличается от порядка программы. Тем не менее, инструкции по-прежнему удаляются в программном порядке, так что наблюдаемое поведение программы совпадает с тем, которое интуитивно ожидал программист. (Хотя, с технической точки зрения, можно разработать процессор OoO, который убирает инструкции в некотором неестественном порядке с определенными ограничениями).

Спекулятивное выполнение – это модель исполнения, в которой инструкции могут вводить конвейер и даже начать выполнение, даже не зная наверняка, что им действительно потребуется выполнить (в соответствии с streamом управления программой). В более широком определении спекулятивного исполнения процессору разрешается спекулировать на что-либо действительно, включая операнды и ячейки памяти, используемые и доступные по инструкции.

Документ Meltdown действительно определяет эти термины на стр. 3:

В этой статье мы ссылаемся на спекулятивное исполнение в более ограниченном значении, где оно относится к последовательности команд, следующих за веткой, и использует термин «исполнение вне порядка» для ссылки на любой способ получения операции, выполненной до того, как процессор передал результаты всех предыдущих инструкций.

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

Процессоры, предназначенные для выполнения простых задач и используемых во встроенных системах или IoT-устройствах, как правило, не являются спекулятивными, а не OoO. Настольные и серверные процессоры являются спекулятивными и OoO. В середине вычислительного спектра (мобильные телефоны и микроcontrollerы) вы можете найти процессоры, которые являются OoO, но не спекулятивными (например, ARM Cortex-A9 ). Некоторые процессоры Intel Atom являются спекулятивными, но в порядке . Спекулятивное выполнение особенно полезно при использовании с OoO.

Смятение пришло, когда я прочитал статьи Meltdown и Spectre и сделал дополнительные исследования. В документе Meltdown указывается, что Meltdown основан на исполнении вне порядка, в то время как некоторые другие ресурсы, включая страницу вики-информации о спекулятивном исполнении, указывают, что Meltdown основан на спекулятивном исполнении.

Уязвимость Meltdown, описанная в документе, требует как спекулятивного, так и внеочередного исполнения . Тем не менее, это действительно смутное утверждение, поскольку существует множество различных спекулятивных и нестандартных исполнений исполнения. Meltdown не работает с любым типом OoO или спекулятивным исполнением. Например, ARM11 (используется в Raspberry Pis) поддерживает некоторое ограниченное OoO и спекулятивное выполнение, но он не уязвим.

Связано: В чем разница между выполнением Superscalar и OoO? ,

Мне все еще трудно понять, как Meltdown использует спекулятивное исполнение. Пример в документе (тот же, который я упомянул ранее) использует только IMO только OoO – @Name в комментарии

Meltdown основан на процессорах Intel, которые оптимистично предполагают, что нагрузки не будут ошибочными, и что, если ошибка загрузки достигает портов нагрузки, это было результатом более ранней неверно предсказанной ветви. Таким образом, загрузочный uop получает отметку, поэтому он будет виноват, если он достигнет выхода на пенсию, но выполнение продолжается умозрительно с использованием данных, в записи таблицы страниц указано, что вам запрещено читать из пользовательского пространства .

Вместо того, чтобы запускать дорогостоящее восстановление исключений при загрузке, он ждет, пока он определенно не достигнет выхода на пенсию, потому что это дешевый способ для механизма обработки отказа ветви -> плохой нагрузки. В оборудовании трубам легче поддерживать трубопровод, если вам не нужно, чтобы он остановился / остановился на правильность. например, нагрузка, когда вообще нет записи на странице, и, следовательно, пропущен TLB, приходится ждать. Но ожидание даже при ударе TLB (для записи с разрешениями, которые блокируют ее использование) будет сложным. Обычно ошибка страницы возникает только после неудачной прохода страницы (которая не находит запись для виртуального адреса) или при выходе из загрузки или хранения, которая не разрешила права доступа к записи TLB.

В современном конвейерном процессоре OoO все инструкции рассматриваются как спекулятивные до выхода на пенсию . Только при выходе на пенсию инструкции становятся не спекулятивными. Механизм Out-of-Order не знает и не заботится о том, спекулирует ли он на одной стороне ветви, которая была предсказана, но еще не выполнена, или спекулирует прошлые потенциально опасные нагрузки. «Спекуляция», что нагрузки не являются ошибками или инструкции ALU не вызывают исключений, случается даже в процессорах, которые на самом деле не считаются спекулятивными , но полное исполнение вне порядка превращает это в еще один вид спекуляций.

Я не слишком беспокоюсь о точном определении «спекулятивного исполнения», и что подсчитывает / чего нет. Меня больше интересует, как работают современные проекты вне порядка, и что на самом деле проще даже не пытаться отличать спекулятивные от неспекулятивных до конца конвейера. Этот ответ даже не пытается найти более простые конвейеры в заказе с умозрительной инструкцией-выборкой (основанной на предсказании ветвей), но не исполнением, ни где-либо между этим и полномасштабным алгоритмом Томасуло с планировщиком ROB + с OoO exec + в – выход на пенсию для точных исключений.

Например, только после выхода на пенсию хранилище когда-либо фиксирует из буфера хранения в кеш-память L1d, а не раньше. И чтобы поглощать короткие всплески и промахи в кеше, это не должно происходить как часть выхода на пенсию. Таким образом, одна из единственных неспекулятивных вещей, не входящих в порядок, заключается в том, чтобы хранить магазины в L1d; они определенно произошли с точки зрения архитектурного состояния, поэтому они должны быть завершены, даже если происходит прерывание / исключение.

Механизм выхода из строя с ошибкой – если это достижение – это хороший способ избежать дорогостоящей работы в тени неправильного предсказания отрасли. Он также дает CPU правильное архитектурное состояние (регистровые значения и т. Д.), Если исключение срабатывает. Вам действительно нужно, не позволяйте машинам OoO продолжать работать над инструкциями, выходящими за пределы того места, где вы обнаружили исключение.


Особенно важны промахи в ветви : есть буферы, которые записывают микроархитектурное состояние (например, распределение регистров) на ветках, поэтому восстановление ветки может вернуться к этому, вместо того, чтобы смывать конвейер и перезапускать из последнего хорошо известного состояния выхода на пенсию. Филиалы ошибочно предполагают справедливую сумму в реальном коде. Другие исключения очень редки.

Современные высокопроизводительные процессоры могут сохранять (вне порядка) выполнение uops с момента пропуски ветки, а затем отбрасывать uops и результаты выполнения после этой точки. Быстрое восстановление намного дешевле, чем отбрасывать и перезапускать все из состояния выхода на пенсию, которое потенциально намного отстает от того, где было обнаружено ошибочное предсказание.

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

Этот оптимизированный механизм восстановления используется только для филиалов (поскольку буферы состояния-моментального снимка ограничены), поэтому отраслевые промахи относительно дешевы по сравнению с полными streamами streamов. (например, на Intel, устройство для упорядочения памяти, счетчик производительности machine_clears.memory_ordering : каковы задержки и пропускные затраты между распределением между производителями и потребителями между machine_clears.memory_ordering памяти между гипер-братьями и сестрами?


Однако исключения не являются неслыханными; ошибки страницы происходят в нормальном режиме работы. например, хранить на странице только для чтения, запускает копирование при записи. Загружайте или сохраняйте на непроверенную страницу, запуская страницу или обрабатывая ленивое сопоставление. Но тысячи-миллионы инструкций обычно выполняются между ошибками каждой страницы даже в процессе, который часто выделяет новую память. (1 на микро или миллисекунду на 1 ГГц процессоре). В коде, который не отображает новую память, вы можете пройти гораздо дольше без исключений. В основном просто прерывание таймера изредка в чистом количестве хрустов без ввода-вывода.

Но в любом случае вы не хотите запускать флеш-конвейер или что-нибудь дорогое, пока не убедитесь, что исключение действительно срабатывает. И вы уверены, что имеете правильное исключение. например, возможно, адрес загрузки для более ранней нагрузки на сбои не был готов, как только это произошло, поэтому первая выполняемая ошибка загрузки не была первой в программном порядке. Ожидание до выхода на пенсию – это дешевый способ получить точные исключения. Дешево с точки зрения дополнительных транзисторов, чтобы справиться с этим делом, и позволяя обычным машинам по отставке в порядке выяснить, какое исключение пожаров происходит быстро.

Бесполезная работа, выполняемая инструкциями после инструкции, отмеченной ошибкой при выходе на пенсию, стоит крошечный бит власти и не стоит блокировать, потому что исключения настолько редки.

Это объясняет, почему имеет смысл разрабатывать аппаратные средства, которые в первую очередь были уязвимы для Meltdown. Очевидно, небезопасно продолжать делать это, теперь, о чем думал Meltdown.


Фиксация Meltdown дешево

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

Поэтому, если порты загрузки маскируют загруженные данные до нуля или что-то еще, а также устанавливают флаг сбоя при выходе из системы, выполнение продолжается, но не может получить информацию о секретных данных. Это потребует около 1 задержки задержек критического пути, что, вероятно, возможно в портах загрузки без ограничения тактовой частоты или добавления дополнительного цикла задержки. (1 тактовый цикл достаточно длинный, чтобы логика распространялась через многие логические схемы AND / OR на этапе конвейера, например, полный 64-разрядный сумматор).

Связанный: Я предложил тот же механизм для HW fix для Meltdown in Почему процессоры AMD не менее уязвимы для Meltdown и Spectre? ,

Давайте будем гением компьютера.