Конфликт атомарных операций между потоками SMT/HT

Да, атомарные RMW гораздо дешевле, когда кеш-линия уже горячая, никакие RFO не нужны, чтобы достать ее с другого физического ядра. Каковы внутренние характеристики ЦП CAS-коллизии? похоже, об этом (разные и одинаковые физические ядра). Связано в целом, без перфомансов: Что будет использоваться для обмена данными между потоками, выполняющимися на одном ядре с HT?.   -  person Peter Cordes    schedule 13.06.2021

Ситуация с атомарными операциями чистой загрузки/чистого хранения отличается: кажется, что совместное использование физического ядра дает больше возможностей для очистки машины от ошибочных предположений о порядке памяти: Каковы затраты на задержку и пропускную способность при совместном использовании области памяти производителем и потребителем между гипер-родственными братьями и сестрами?. Это тестировало только загрузку и сохранение, а не RMW, такие как .fetch_add (x86 lock add или lock xadd)   -  person Peter Cordes    schedule 13.06.2021

Это очень хорошо для переваривания. Это заставляет меня задаться вопросом, стоит ли экспериментировать с амортизацией атомарных операций между парами HT в базовой локальной переменной, прежде чем преобразовать результат в глобальное межъядерное атомарное значение (в качестве первого или единственного уровня иерархической атомарной композиции для распределения нагрузки конкуренции). ).   -  person iam    schedule 13.06.2021

Для чего-то вроде сбора и сведения результатов параллельных фрагментов операции, например суммы массива? Да, если вы уже прикрепляете потоки к ядрам и пишете код с поддержкой HT, у вас могут быть пары потоков, которые совместно используют физическое ядро, совместно использующие соседние элементы массива результатов (с 16- или 32-байтовыми элементами, выровненными по 64, так что каждый физ. ядро разделяет выходную линию только с 0 или 1 другим физическим ядром), и, возможно, даже иметь общий все еще активный счетчик, чтобы последний из пары мог добавлять свой результат к другому?   -  person Peter Cordes    schedule 13.06.2021

Хм, этот последний бит, вероятно, глуп, если только не требуется значительная работа (больше, чем просто одно скалярное сложение суммы); если это все, просто позвольте одному потоку, собирающему результаты, взять оба из одной и той же строки кэша и добавить. Количество затронутых строк кэша является более важным фактором.   -  person Peter Cordes    schedule 13.06.2021

Да, я думал о параллельных операциях с данными в стиле графического процессора, таких как редукция и т. д. И на самом деле также с точки зрения обобщенной системы задач (где задачи даже не всегда могут быть так хорошо оптимизированы) — возможно, атомарные операции или примитивы синхронизации, используемые для учета, могли бы воспользоваться этим как-нибудь. Так как я никогда раньше не видел разговоров о системе задач, оптимизированной специально для HT.   -  person iam    schedule 13.06.2021