Почему на Ледовом озере MOVDIRx не похож на тремонт? У них уже есть лучшие?
Я заметил, что Intel Tremont имеет 64-байтовые инструкции хранения с MOVDIRI а также MOVDIR64B,
Это гарантирует атомарную запись в память, тогда как не гарантирует атомарность загрузки. Кроме того, запись слабо упорядочена, может потребоваться немедленное ограждение.
Я не нахожу MOVDIRx в ледяном озере.
Почему Ледяному озеру не нужны такие инструкции, как MOVDIRx?
(Внизу страницы 15)
Intel® ArchitectureInstruction Set Расширения и будущие функции Справочник по программированию
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
1 ответ
У Ice Lake есть AVX512, который дает нам 64-байтовую загрузку + хранилища, но не гарантирует атомарность 64-байтовых хранилищ.
Мы получаем 64-байтовые хранилища NT с movntps [mem], zmm / movntdq [mem], zmm, Интересно, что магазины NT не поддерживают маскирование слиянием, чтобы оставить некоторые байты неписанными. Это, в основном, нанесло бы ущерб цели хранилищ NT, создав частичные записи.
Вероятно, процессоры Ice Lake Pentium / Celeron все еще не будут иметь AVX1/2, не говоря уже о AVX512 (возможно, они могут продавать чипы с дефектами в верхних 128 битах блоков FMA и / или регистровый файл хотя бы на одном ядре), поэтому только rep movsb сможет внутренне использовать 64-байтовые загрузки / хранилища на этих процессорах. (IceLake будет иметь функцию "быстрого короткого повторения", которая может быть полезна даже для небольших 64-байтовых копий, полезна в коде ядра, который не может использовать векторные регистры.)
Возможно, Intel не может (или не хочет) предоставлять такую гарантию атомарности для своих основных процессоров, только для микросхем с низким энергопотреблением, которые не поддерживают несколько сокетов, но я не слышал никаких сообщений о разрыве, фактически существующем в строка кеша на процессорах Intel. На практике, я думаю, что кэшированные загрузки / хранилища, которые не пересекают границы строки кэша на современных процессорах Intel, всегда атомарны.
(В отличие от AMD K10, где HyperTransport создавал разрыв на границах 8B между сокетами, хотя разрывов между ядрами на одном сокете не наблюдалось. Инструкции SSE: какие процессоры могут выполнять атомные операции с памятью 16B?)
В любом случае, нет способа обнаружить это с помощью CPUID, и это не задокументировано, поэтому в принципе невозможно безопасно воспользоваться преимуществами. Было бы неплохо, если бы существовал лист CPUID, который сообщал бы вам ширину атомности для системы и для одного сокета, поэтому реализации, которые разделяют 512-битные операции AVX512 на 256-битные половины, все равно будут разрешены....
В любом случае, вместо того, чтобы вводить специальную инструкцию с гарантированной атомарностью хранилища, я думаю, что поставщики ЦП с большей вероятностью начнут документировать и обеспечить обнаружение CPUID более широкой атомарности хранилища для всех хранилищ степени 2 или только для NT магазины, или что-то.
Если для некоторой части AVX512 потребуется 64-байтная атомарность, AMD будет намного сложнее поддерживать, если они будут следовать своей текущей стратегии реализации вектора половинной ширины. (Zen2 будет иметь 256-битные векторные ALU, что делает инструкции AVX1/AVX2 в основном однопользовательскими, но, как сообщается, у него не будет поддержки AVX512, к сожалению. AVX512 - очень хороший ISA, даже если вы используете его только на 256-битной ширине, заполнение большего количества пробелов в том, что можно сделать удобно / эффективно, например, unsigned int <-> FP и [u] int64 <-> double.)
Так что IDK, если, возможно, Intel согласилась не делать этого или решила не делать этого по своим собственным причинам.
Вариант использования для атомарности записи 64B:
Я подозреваю, что основной сценарий использования - это надежное создание 64-байтовых транзакций PCIe, а не "атомарность" как таковая и не для наблюдения другим ядром.
Если вы заботитесь о чтении из других ядер, обычно вы хотите, чтобы кэш L3 поддерживал данные, а не обходил их DRAM. Seqlock - это, вероятно, более быстрый способ эмулировать 64-байтовую атомарность между ядрами процессора, даже если movdir64B доступен.
Skylake уже имеет 12 буферов для записи (по сравнению с 10 в Haswell), поэтому (возможно?) Не так уж сложно использовать обычные хранилища NT для создания полноразмерной транзакции PCIe, избегая ранних сбросов. Но, возможно, у процессоров с низким энергопотреблением меньше буферов, и, возможно, сложно надежно создать 64-битные транзакции для буфера NIC или чего-то еще.
Почему Ice Lake не нужны такие инструкции, как MOVDIRx?
Я бы не стал отвечать на этот вопрос с точки зрения необходимости, но как следствие практических реалий того, как разрабатываются функции архитектуры набора команд и продукты Intel.
Из предыдущего ответа:
Возможно, Intel не может (или не хочет) предоставить такую гарантию атомарности для своих основных процессоров,
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf говорит в Таблице 1-1, что эти инструкции будут поддерживаться в диапазоне микроархитектур:
"Прямые магазины: MOVDIRI, MOVDIR64B Tremont, Tiger Lake, Sapphire Rapids"
Tiger Lake был объявлен "новейшими мобильными процессорами Intel® Core™" на сайте https://newsroom.intel.com/news-releases/intel-ces-2020/.
Sapphire Rapids описывается как "10-нм процессоры Intel® Xeon® Scalable" на https://newsroom.intel.com/news-releases/intel-unveils-new-gpu-architecture-optimized-for-hpc-ai-oneapi/. См. Также https://s21.q4cdn.com/600692695/files/doc_presentations/2019/05/2019-Intel-Investor-Meeting-Shenoy.pdf.
Отказ от ответственности: я работаю в Intel и буду цитировать и обсуждать только официальные источники.