Цитата из Векторная микроархитектура сопроцессора Intel® Xeon Phi™ :
Как правило, для записи в строку кэша сопроцессор Xeon Phi™ должен прочитать строку кэша перед записью в нее. Это известно как чтение для владения (RFO). Одна проблема с этой реализацией заключается в том, что записанные данные не используются повторно; мы излишне занимаем BW для чтения невременных данных. Сопроцессор Intel® Xeon Phi™ поддерживает инструкции, которые не считывают данные, если данные представляют собой потоковое хранилище. Эти инструкции VMOVNRAP*, VMOVNRNGOAP* позволяют указать, что данные должны быть записаны без предварительного чтения данных. В Xeon Phi ISA инструкции VMOVNRAPS/VMOVNRPD способны оптимизировать полосу пропускания памяти в случае промаха кеша, не выполняя ненужный шаг чтения.
Инструкции VMOVNRNGOAP* полезны, когда программист допускает слабый порядок записи данных приложения, то есть сохранения, выполняемые этими инструкциями, не упорядочены глобально. Это означает, что последующую запись тем же потоком можно наблюдать до выполнения инструкций VMOVNRNGOAP. Операцию ограждения памяти следует использовать в сочетании с этой операцией, если несколько потоков читают и пишут в одно и то же место.
Кажется, что "Подсказки о непрочтении", "Потоковое хранилище" и "Вневременное потоковое/хранилище" взаимозаменяемы в некоторых Ресурсы.
Так что да, это когерентная запись без кеша, хотя с Knights Corner (KNC, где принадлежат как vmovnrap*, так и vmovnrngoap*) сохранения происходят в кеше L2, он не обходит все уровни кеша.
Как объяснено в приведенной выше цитате, vmovnrngoap* отличается от vmovnrap* тем, что слабоупорядоченная модель согласованности памяти позволяет «следующую запись одним и тем же потоком можно было наблюдать до того, как Инструкции VMOVNRNGOAP выполняются", поэтому да, доступ другого потока или процессора является несогласованным, и следует использовать операцию ограждения. Хотя CPUID можно использовать в качестве операции ограждения, лучшими вариантами являются «LOCK ADD [RSP],0» (фиктивное атомарное добавление) или XCHG (сочетающий в себе хранилище и ограждение).
Еще несколько деталей:
Сохранение NR. Инструкция сохранения NR (vmovnr) — это стандартная инструкция сохранения векторов, которую всегда можно безопасно использовать. Команда сохранения NR, которая отсутствует в локальном кеше, приводит к тому, что все потенциальные копии строки кеша в удаленных кешах становятся недействительными, строка кеша выделяется (но не инициализируется) в локальном кеше в монопольном состоянии, а данные записи в инструкция, которая будет записана в кэшлайн. Нет передачи данных из основной памяти, что экономит пропускную способность памяти. Инструкция сохранения NR и другие инструкции загрузки и/или сохранения из того же потока упорядочены глобально, что означает, что все наблюдатели этой последовательности инструкций всегда видят один и тот же фиксированный порядок выполнения.
Инструкция сохранения NR.NGO (не глобально упорядоченная) (vmovnrngo) ослабляет глобальное ограничение упорядочения инструкции сохранения NR. Это ослабление делает задержку инструкции NR.NGO меньше, чем инструкцию NR, которая может использоваться для достижения более высокой производительности в приложениях с интенсивным использованием хранилища. Однако снятие этого ограничения означает, что инструкция сохранения NR.NGO и другие инструкции загрузки и/или сохранения из одного и того же потока могут наблюдаться двумя наблюдателями как имеющие два разных порядка. Использование инструкций магазина NR.NGO безопасно только в том случае, если изменение порядка этих инструкций проверено, чтобы не изменить результат. В противном случае использование хранилищ NR.NGO может привести к некорректному выполнению. Наш компилятор может генерировать инструкции сохранения NR.NGO для инструкций сохранения, которые, по его мнению, имеют вневременное поведение. Например, параллельный цикл, который определяется нашим компилятором как невременной, может использовать инструкции NR.NGO. В конце такого цикла, чтобы убедиться, что все ожидающие неглобально упорядоченные сохранения завершены и все потоки имеют согласованное представление памяти, наш компилятор генерирует блокировку (инструкцию блокировки) после цикла. Это ограждение необходимо перед продолжением выполнения последующего фрагмента кода, чтобы гарантировать, что все потоки имеют точно такое же представление памяти.
Общее эмпирическое правило заключается в том, что невременное хранилище выгодно для блоков доступа к памяти, которые не используются повторно в ближайшем будущем. Так что да переиспользование будет дорого в обоих случаях.
person
veritas
schedule
16.08.2017
