Arhn - архитектура программирования

Упорядочивание памяти x86: переупорядочение нагрузок с использованием более ранних хранилищ по сравнению с внутрипроцессорной пересылкой

Я пытаюсь понять раздел 8.2 Руководства по системному программированию Intel ( это Том 3 в PDF).

В частности, я вижу два разных сценария переупорядочения:

8.2.3.4 Грузы могут быть переупорядочены в более ранних магазинах в другие места

а также

8.2.3.5 Внутрипроцессорная пересылка разрешена

Однако я не понимаю отличия этих сценариев от наблюдаемых эффектов POW. Примеры, приведенные в этих разделах, кажутся мне взаимозаменяемыми. Пример 8.2.3.4 может быть объяснен как правилом 8.2.3.5, так и собственным правилом. И обратное мне тоже кажется верным, хотя в этом случае я не уверен.

Итак, вот мой вопрос: есть ли лучшие примеры или объяснения того, как наблюдаемые эффекты 8.2.3.4 отличаются от наблюдаемых эффектов 8.2.3.5?

x86 concurrency memory intel
03.01.2014

  • Просто нанесу удар, но я не думаю, что 8.2.3.5 можно объяснить с помощью 8.2.3.4. Неожиданный результат в примере для 8.2.3.5 не происходит из-за переупорядочения инструкций в отдельном ядре. Это происходит из-за задержки того, что одно ядро ​​видит обновление памяти, сделанное другим ядром. Кроме того, 8.2.3.4 может дать ожидаемый результат даже в одноядерной ситуации, тогда как 8.2.3.5 - это строго многоядерный феномен. 03.01.2014
  • @Aaron, 8.2.3.4 также является мульти-контекстным, отдельный процесс не должен заботиться о переупорядочении нагрузки, поскольку в случае конфликта адресов они не будут переупорядочены, а в противном случае переупорядочение не повлияет на результаты. 03.01.2014
  • @aaron: Понятно! загрузка в R2 не может быть перемещена до сохранения в [x], потому что загрузка в R1 мешает. Таким образом, 8.2.3.4 нельзя использовать для объяснения 8.2.3.5. Спасибо! Не могли бы вы написать это в качестве ответа? 03.01.2014
  • @Leeor, да, ты прав. При использовании одного ядра вы не увидите странного результата. 03.01.2014
  • @Arkadiy, я думаю, теперь я лучше понимаю, о чем вы спрашиваете ... Я думаю, что вы правы, в связи с 8.2.3.2. Без 8.2.3.2 пример из 8.2.3.5 мог бы быть результатом 8.2.3.4, даже если это разные лежащие в основе механизмы. 03.01.2014
  • По теме: Глобально невидимые инструкции по загрузке 19.09.2020

Ответы:


1

Пример в 8.2.3.5 должен быть «удивительным», если вы ожидаете, что упорядочение памяти будет полностью строгим и чистым, и даже если вы признаете, что 8.2.3.4 позволяет переупорядочивать нагрузки с сохранением разных адресов.

   Processor 0      |      Processor 1
  --------------------------------------
   mov [x],1        |      mov [y],1
   mov R1, [x]      |      mov R3,[y]
   mov R2, [y]      |      mov R4,[x]

Обратите внимание, что ключевым моментом является то, что вновь добавленные нагрузки посередине возвращают 1 (перенаправление из хранилища в загрузку делает это возможным в uarch без остановки). Таким образом, теоретически можно ожидать, что к моменту завершения обеих этих загрузок оба хранилища будут «наблюдаться» в глобальном масштабе (это было бы в случае с последовательной согласованностью, когда между хранилищами существует уникальный порядок, и все ядра его видят).

Однако наличие более позднего R2 = R4 = 0 в качестве действительного результата доказывает, что это не так - фактически магазины сначала наблюдаются локально. Другими словами, разрешение этого результата означает, что процессор 0 видит хранилища как time(x) < time(y), а процессор 1 видит противоположное.

Это очень важное наблюдение о непротиворечивости этой модели памяти, которое предыдущий пример не доказывает. Этот нюанс является самым большим различием между последовательной согласованностью и Total Store Ordering - во втором примере SC нарушается, в первом - нет.

03.01.2014
  • Вы говорите, что обе вновь добавленные нагрузки в середине возвращают 1. Если это действительно так, то пример имеет больше смысла. Однако я не вижу этого (return 1) в тексте. Где это находится? 03.01.2014
  • @Arkadiy, я предполагаю, что это подразумевается неявно, поскольку они говорят о пересылке. Если он не вернул 1 после того, как просто сохранил его, вы нарушите всю согласованность 03.01.2014
  • Отличный ответ. Я считаю, что это мало понятно, и ответ приходит в голову: существует два типа переупорядочения в x86: переупорядочение StoreLoad (в значительной степени требуется, если у вас есть буфер хранилища), продемонстрированное 8.2.3.4 и это переупорядочение переадресации в магазине, которое не вполне объяснимо с точки зрения 4 стандартных переупорядочений. Вам действительно нужно просто объяснить, что нагрузки могут принимать свое значение из более раннего хранилища с того же процессора, очевидно, не в порядке (считывание более позднего значения) по отношению к окружающим нагрузкам. Или что-то. 01.06.2018
  • Я действительно не согласен с одним: переупорядочение StoreLoad в 8.2.3.4 уже нарушает последовательную согласованность, потому что SC требует, чтобы каждая операция появлялась в программном порядке в общем произвольном общем порядке операций. Чтобы получить результат r1==r2==0, нет порядка, согласованного с программным порядком, который его производит - по крайней мере, одно из чтений должно быть переупорядочено с записью от того же ЦП. 01.06.2018
  • @BeeOnRope, я не уверен, что SC заботится об исходном порядке программы, что плохого в предположении, что обе загрузки в 8.2.3.4 выполняются первыми в глобальном порядке? Это не нарушает никаких правил. Между прочим, я видел различие между концепцией SC, используемой в некоторых местах (включая модель памяти C ++ SC, я думаю), где глобальный порядок относится к модификациям, видимым всем, в отличие от классическое определение СК, включающее в себя все операции (включая нагрузки). 01.06.2018
  • @Leeor - все, что я видел о SC, говорит о том, что он сохраняет порядок проблем, включая ссылку, которую вы указали выше. Если он не соблюдает порядок программ, это действительно очень слабая модель, и вы не можете легко рассуждать о ней. На практике это самая сильная модель, и по этой причине ее легко рассуждать. Единственный недетерминизм в SC - это относительный порядок операций из разных потоков. 01.06.2018
    • Новые материалы
    Коллекции публикаций по глубокому обучению
    Последние пару месяцев я создавал коллекции последних академических публикаций по различным подполям глубокого обучения в моем блоге https://amundtveit.com - эта публикация дает обзор 25..
    Представляем: Pepita
    Фреймворк JavaScript с открытым исходным кодом Я знаю, что недостатка в фреймворках JavaScript нет. Но я просто не мог остановиться. Я хотел написать что-то сам, со своими собственными..
    Советы по коду Laravel #2
    1-) Найти // You can specify the columns you need // in when you use the find method on a model User::find(‘id’, [‘email’,’name’]); // You can increment or decrement // a field in..
    Работа с временными рядами спутниковых изображений, часть 3 (аналитика данных)
    Анализ временных рядов спутниковых изображений для данных наблюдений за большой Землей (arXiv) Автор: Рольф Симоэс , Жильберто Камара , Жильберто Кейрос , Фелипе Соуза , Педро Р. Андраде ,..
    3 способа решить квадратное уравнение (3-й мой любимый) -
    1. Методом факторизации — 2. Используя квадратичную формулу — 3. Заполнив квадрат — Давайте поймем это, решив это простое уравнение: Мы пытаемся сделать LHS,..
    Создание VR-миров с A-Frame
    Виртуальная реальность (и дополненная реальность) стали главными модными терминами в образовательных технологиях. С недорогими VR-гарнитурами, такими как Google Cardboard , и использованием..
    Демистификация рекурсии
    КОДЕКС Демистификация рекурсии Упрощенная концепция ошеломляющей О чем весь этот шум? Рекурсия, кажется, единственная тема, от которой у каждого начинающего студента-информатика..