Реализация std :: atomic_thread_fence (std :: memory_order_seq_cst) на x86 без дополнительных потерь производительности

Краткий ответ, не вдаваясь в подробности почему. См., В частности, обсуждение в комментариях этого связанного вопроса.

lock orb $0, -1(%rsp), вероятно, хорошая ставка, чтобы избежать удлинения цепочек зависимостей для локальных варов, которые проливаются / перезагружаются. См. https://shipilev.net/blog/2014/on-the-fence-with-dependencies для тестов. В Windows x64 (без красной зоны) это пространство не должно использоваться, кроме как для будущих инструкций вызова или push.

Перенаправление хранилища на загрузочную сторону операции locked может иметь значение (если это пространство использовалось недавно), поэтому хорошо сохранять узкую заблокированную операцию. Но, будучи полным барьером, я не ожидаю, что может быть какая-либо переадресация хранилища с его вывода на что-либо еще, поэтому, в отличие от обычного, узкий (1 байт) lock orb не имеет этого недостатка.

mfence - это довольно дерьмо по сравнению с горячей линией пространства стека даже на Haswell, возможно, хуже на Skylake, где он даже блокирует OoO exec. (И тоже плохо на AMD по сравнению с lock add).

При переходе по маршруту взаимосвязанной работы в фиктивном местоположении необходимо учитывать несколько моментов:

1. Находясь в L1d этого ядра,
2. Не используется другими ядрами
3. Не создавать длинные цепочки зависимостей
4. Избегайте задержек из-за пропуска переадресации магазина

Без контекста все является лишь предположением, поэтому цель состоит в том, чтобы сделать наилучшее предположение.

Место в верхней части стопки - хорошее предположение для 1 и 2.

Преднамеренно назначенная переменная стека, скорее всего, исправит 3, а поскольку других хранилищ в полете нет, 4 не проблема. Лучшая операция выглядит как lock not.

Для того, чтобы не выделять переменную стека, необходимо, чтобы операция не выполнялась, поэтому lock or [mem], 0 - хороший вариант. Операнд должен быть байтовым, чтобы избежать проблем с 4. Для 3 это всегда предположение. (Хотя можно было использовать обратный адрес, сборка без контекста не знает этого. Но MSVC _AddressOfReturnAddress может быть хорошей идеей)

Я читал про красную зону. Отсутствие его в Windows дает возможность дополнительной оптимизации.

lock not byte ptr [esp-1] без дополнительной переменной подходит для Windows, так как данные считаются непостоянными и не должны использоваться. Нет проливных регистров, поэтому нет зависимости от ложных данных.

ABI с 128-байтовой красной зоной исключает использование lock not byte ptr [esp-1]. 128 байтов вне стека, вероятно, не будут L1d. Тем не менее, поскольку красная зона вряд ли будет использоваться в качестве обычного стека, ответ, данный @Peter Cordes, выглядит хорошо.

TSX в первую очередь вызывает сомнения из-за его отсутствия (не поддерживается на данном ЦП или отключен в результате исправления ошибок или снижения безопасности). В обозримом будущем будет существовать только RTM (Исчезла ли Hardware Lock Elision навсегда из-за Spectre Mitigation?). Согласно Обзор RTM, пустая транзакция RTM все еще является забором, поэтому ее можно использовать.

Успешно зафиксированная область RTM, состоящая из XBEGIN, за которым следует XEND, даже без операций с памятью в области RTM, имеет ту же семантику упорядочения, что и инструкция с префиксом LOCK.

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

if (rtm_supported && _xbegin() == 0xFFFFFFFF)
  _xend();
else
  dummy_interlocked_op();