Неисправное выполнение и ограждения памяти

Я знаю, что современные процессоры могут работать не по порядку, однако они всегда удаляют результаты по порядку, как описано в Википедии.

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

Теперь при использовании многоядерных платформ требуется ограничить память, потому что из-за выполнения Out of Order здесь может быть напечатано неправильное значение x.

Processor #1:
 while f == 0
  ;
 print x; // x might not be 42 here

Processor #2:
 x = 42;
 // Memory fence required here
 f = 1

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

Я имею в виду, что в приведенном выше примере, когда Процессор 2 в конечном итоге удалит результаты, результат x должен стоять перед f, верно? Я знаю, что во время исполнения вне очереди он мог изменить f до x, но он не должен был удалить его до x, верно?

Теперь с упорядоченным упразднением результатов и механизмом согласованности кеша, зачем вам когда-либо понадобились ограждения памяти в x86?


person MetallicPriest    schedule 08.09.2011    source источник
comment
Обратите внимание, что в правильном коде ограничения памяти всегда идут парами: когда два потока обмениваются данными, каждый поток должен выполнить некоторый порядок доступа к памяти (= ограждения). Обычно одна из этих ограждений имеет семантику выпуска, другая - семантику приобретения. В вашем псевдокоде Процессор №2 должен выполнить ограничение записи между назначениями (семантика выпуска), а Процессор №1 должен добавить барьер чтения (семантику получения) между циклом и print. Некоторые ограждения могут быть ненужными на определенных платформах, но любой исходный код должен содержать оба ограждения (которые могут компилироваться в noops).   -  person cmaster - reinstate monica    schedule 27.12.2017


Ответы (3)


В этом руководстве объясняются проблемы: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf

FWIW, где проблемы с упорядочением памяти возникают на современных процессорах x86, причина в том, что, хотя модель согласованности памяти x86 предлагает довольно сильную согласованность, необходимы явные барьеры для обеспечения согласованности чтения после записи. Это происходит из-за того, что называется «буфером хранилища».

То есть x86 последовательно согласован (приятно и легко рассуждать), за исключением того, что загрузки могут быть переупорядочены по сравнению с более ранними хранилищами. То есть, если процессор выполняет последовательность

store x
load y

то на шине процессора это можно увидеть как

load y
store x

Причина такого поведения - вышеупомянутый буфер хранилища, который представляет собой небольшой буфер для записи перед тем, как они отправятся на системную шину. Задержка загрузки - это, OTOH, критическая проблема для производительности, и, следовательно, нагрузкам разрешено «перескакивать из очереди».

См. Раздел 8.2 в http://download.intel.com/design/processor/manuals/253668.pdf

person janneb    schedule 08.09.2011
comment
Janneb, не могли бы вы немного объяснить буфер хранилища и почему они важны в этом контексте? - person MetallicPriest; 08.09.2011
comment
Разве согласованность кеширования не обеспечивает согласованность чтения после записи в x86? - person MetallicPriest; 08.09.2011
comment
@MetallicPriest: А, во-вторых, я подозреваю, что в вашем конкретном примере барьеры на самом деле не нужны. Я отредактировал сообщение, чтобы отразить это, а также добавил объяснение разрешенного переупорядочения в модели памяти x86. - person janneb; 08.09.2011
comment
@janneb, он взял пример из статьи в Википедии о барьерах памяти. - person Tony The Lion; 08.09.2011
comment
@Tony The Tiger: Дело в том, что модель памяти x86 не позволяет переупорядочивать записи по сравнению с другими записями, поэтому барьер не нужен на x86. - person janneb; 08.09.2011
comment
Минус один для FWIW и OTOH. - person insumity; 15.05.2015
comment
Я написал ответ, в котором объясняется для чего нужны буферы хранения с точки зрения архитектуры ЦП. Также Как переупорядочение памяти помогает процессорам и компиляторам? объясняет, почему разрешение аппаратного переупорядочивания StoreLoad важно для производительности. - person Peter Cordes; 12.10.2020

Ограничение памяти гарантирует, что все изменения переменных перед ограничением будут видны всем остальным ядрам, так что все ядра будут иметь актуальное представление данных.

Если вы не поставите забор памяти, ядра могут работать с неправильными данными, это особенно заметно в сценариях, где несколько ядер будут работать с одними и теми же наборами данных. В этом случае вы можете гарантировать, что, когда ЦП 0 выполнил какое-либо действие, все изменения, внесенные в набор данных, теперь будут видны всем другим ядрам, которые затем могут работать с актуальной информацией.

Некоторые архитектуры, включая широко распространенные x86 / x64, предоставляют несколько инструкций по ограничению памяти, включая инструкцию, иногда называемую полным забором. Сплошное ограждение гарантирует, что все операции по загрузке и хранению до ограждения будут выполнены до отправки любых грузов и припасов после ограждения.

Если бы ядро ​​начало работать с устаревшими данными в наборе данных, как оно могло бы получить правильные результаты? Не имело значения, если бы конечный результат был представлен так, как будто все было сделано в правильном порядке.

Ключ находится в буфере хранилища, который находится между кешем и ЦП, и делает следующее:

Буфер хранилища невидим для удаленных процессоров

Буфер хранилища позволяет сохранять записи в память и / или кеши для оптимизации доступа к межсоединениям.

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

РЕДАКТИРОВАТЬ:

Для кода, который вы использовали в качестве примера, Википедия говорит следующее:

Барьер памяти может быть вставлен перед назначением процессора №2 функции f, чтобы гарантировать, что новое значение x будет видно другим процессорам во время или до изменения значения f.

person Tony The Lion    schedule 08.09.2011

Чтобы сделать явным то, что подразумевается в предыдущих ответах, это правильно, но отличается от доступа к памяти:

Процессоры могут работать не по порядку, однако они всегда удаляют результаты по порядку.

Удаление инструкции осуществляется отдельно от выполнения доступа к памяти, доступ к памяти может завершиться в другое время по сравнению с удалением инструкции.

Каждое ядро ​​будет действовать так, как если бы его собственные обращения к памяти происходили при выводе из эксплуатации, но другие ядра могут видеть эти обращения в разное время.

(На x86 и ARM, я думаю, это наблюдаемо только для хранилищ, но, например, Alpha может загружать старое значение из памяти. X86 SSE2 имеет инструкции с более слабыми гарантиями, чем нормальное поведение x86).

PS. По памяти заброшенный Sparc ROCK мог фактически выйти из строя, он тратил энергию и транзисторы на определение, когда это было безвредно. От него отказались из-за энергопотребления и количества транзисторов ... Я не верю, что какой-либо ЦП общего назначения был куплен на рынке с выведением из строя.

person user1998586    schedule 27.12.2017
comment
Были теоретические предложения по изъятию из эксплуатации вне очереди, чтобы сделать возможным скрыть задержку памяти с помощью окна нарушения порядка 1k инструкций без простого увеличения обычного ROB до непрактичных 1k записей. В частности, процессор кило-инструкций. Google нашел эту статью на каком-то случайном сайте: cgi.di.uoa.gr/~halatsis/Advanced_Comp_Arch/. А также csl.cornell.edu/~martinez/doc/taco04.pdf < / а>. - person Peter Cordes; 27.12.2017