Средняя задержка инструкций atomics cmpxchg на процессорах Intel


Я ищу некоторую ссылку на средние задержки для инструкции lock cmpxchg для различных процессоров intel. Я не могу найти хорошую ссылку на эту тему, и любая ссылка очень поможет.

спасибо.

7
atomic lock-free multithreading x86

5 ответов

есть несколько, если таковые имеются, хорошие ссылки на это, потому что есть так много вариаций. Это зависит в основном от всего, включая скорость шины, скорость памяти, скорость процессора, количество процессоров, окружающие инструкции, ограждение памяти и, вполне возможно, угол между Луной и Эверестом...

Если у вас есть очень конкретное приложение, как в, известное (фиксированное) оборудование, операционная среда, операционная система в реальном времени и эксклюзивный контроль, то, возможно, это будет иметь значение. В это дело, бенчмарк. Если у вас нет такого уровня контроля над тем, где работает ваше программное обеспечение, любые измерения фактически бессмысленны.

Как говорится в ответы, блокировки реализованы с помощью CAS, поэтому, если вы можете уйти с CAS вместо блокировки (для чего потребуется как минимум две операции), это будет быстрее (заметно? только может быть).

лучшие ссылки, которые вы найдете, это руководства разработчика программного обеспечения Intel, хотя поскольку существует так много вариаций, они не дадут вам фактического числа. Тем не менее, они будут описывать, как получить максимальную производительность. Возможно, таблица данных процессора (например,здесь для i7 Extreme Edition в разделе "технические документы") даст вам фактические номера (или, по крайней мере, диапазон).

4

лучшая ссылка на задержку инструкций x86, вероятно, содержится в руководства по оптимизации Agner, на основе фактических эмпирических измерений на различных чипах Intel/AMD/VIA и часто обновляется для последних процессоров на рынке.

к сожалению, я не вижу CMPXCHG инструкция, перечисленная в таблицах задержки инструкций, но на странице 4 указано:

инструкции с префиксом блокировки имеют длительную задержку, которая зависит от кэша организация и, возможно, скорость ОЗУ. Если есть несколько процессоров или ядер или устройств прямого доступа к памяти (DMA), то все заблокированные инструкции заблокируют линию кэша для эксклюзивного доступа, который может включать доступ к ОЗУ. Префикс блокировки обычно стоит более ста тактов, даже в однопроцессорных системах. Это также относится к инструкции XCHG с операндом памяти.

3

Я изучал экспоненциальный отход в течение нескольких месяцев.

латентность CAS полностью зависит от того, может ли инструкция работать из кэша или должна работать из памяти. Как правило, заданный адрес памяти обрабатывается несколькими потоками (например, указателем записи на очередь). Если последний успешный CAS был выполнен логическим процессором, который разделяет кэш с текущим исполнителем CAS (L1, L2 или L3, хотя, конечно, выше уровни медленнее), то инструкция будет работать на кэше и будет быстрой-несколько циклов. Если последний успешный CAS был выполнен логическим ядром, которое не разделяет кэш с текущим excutor, то запись последнего CASer аннулирует строку кэша для текущего executor и требуется чтение памяти - это займет сотни циклов.

сама операция CAS очень быстрая-несколько циклов-проблема в памяти.

2

Я пытался сравнить CAS и DCAS с точки зрения NOP.

У меня есть некоторые результаты, но я им пока не доверяю - проверка продолжается.

В настоящее время я вижу на Core i5 для CAS/DCAS 3/5 NOPs. На Xeon я вижу 20/22.

эти результаты могут быть совершенно неверными-вас предупредили.

0

вы можете использовать программное обеспечение AIDA64 для проверки задержек инструкций (но вы не можете проверить, какие из инструкций проверить, у него есть жестко закодированный список инструкций). Люди публикуют результаты наhttp://instlatx64.atw.hu/

С lock инструкции, AIDA64 проверяет lock add инструкции и xchg [mem] (который всегда замок даже без явной блокировки prefix).

вот некоторая информация. Я также дам вам, для сравнения, задержки следующих инструкций:

  • xchg reg1, reg2 который не запирает;
  • add для регистров и памяти.

Как видите,замок инструкции только в 5 раз медленнее на Haswell-DT и только ~2 раза медленнее на Kaby Lake-S, чем неблокирующие хранилища памяти.

Intel Core i5-4430, 3000 МГц (30 x 100) Haswell-DT

LOCK ADD [m8], r8         L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
LOCK ADD [m16], r16       L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
LOCK ADD [m32], r32       L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
LOCK ADD [m32 + 8], r32   L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
LOCK ADD [m64], r64       L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
LOCK ADD [m64 + 16], r64  L: 5.96ns= 17.8c  T: 7.21ns= 21.58c

XCHG r8, [m8]             L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
XCHG r16, [m16]           L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
XCHG r32, [m32]           L: 5.96ns= 17.8c  T: 7.21ns= 21.58c
XCHG r64, [m64]           L: 5.96ns= 17.8c  T: 7.21ns= 21.58c

ADD r32, 0x04000          L: 0.22ns=  0.9c  T: 0.09ns=  0.36c
ADD r32, 0x08000          L: 0.22ns=  0.9c  T: 0.09ns=  0.36c
ADD r32, 0x10000          L: 0.22ns=  0.9c  T: 0.09ns=  0.36c
ADD r32, 0x20000          L: 0.22ns=  0.9c  T: 0.08ns=  0.34c
ADD r8, r8                L: 0.22ns=  0.9c  T: 0.05ns=  0.23c
ADD r16, r16              L: 0.22ns=  0.9c  T: 0.07ns=  0.29c
ADD r32, r32              L: 0.22ns=  0.9c  T: 0.05ns=  0.23c
ADD r64, r64              L: 0.22ns=  0.9c  T: 0.07ns=  0.29c
ADD r8, [m8]              L: 1.33ns=  5.6c  T: 0.11ns=  0.47c
ADD r16, [m16]            L: 1.33ns=  5.6c  T: 0.11ns=  0.47c
ADD r32, [m32]            L: 1.33ns=  5.6c  T: 0.11ns=  0.47c
ADD r64, [m64]            L: 1.33ns=  5.6c  T: 0.11ns=  0.47c
ADD [m8], r8              L: 1.19ns=  5.0c  T: 0.32ns=  1.33c
ADD [m16], r16            L: 1.19ns=  5.0c  T: 0.21ns=  0.88c
ADD [m32], r32            L: 1.19ns=  5.0c  T: 0.22ns=  0.92c
ADD [m32 + 8], r32        L: 1.19ns=  5.0c  T: 0.22ns=  0.92c
ADD [m64], r64            L: 1.19ns=  5.0c  T: 0.20ns=  0.85c
ADD [m64 + 16], r64       L: 1.19ns=  5.0c  T: 0.18ns=  0.73c

Intel Core i7-7700K, 4700 МГц (47 x 100) Кабы Озеро-S

LOCK ADD [m8], r8         L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
LOCK ADD [m16], r16       L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
LOCK ADD [m32], r32       L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
LOCK ADD [m32 + 8], r32   L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
LOCK ADD [m64], r64       L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
LOCK ADD [m64 + 16], r64  L: 4.01ns= 16.8c  T: 5.12ns= 21.50c

XCHG r8, [m8]             L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
XCHG r16, [m16]           L: 4.01ns= 16.8c  T: 5.12ns= 21.50c
XCHG r32, [m32]           L: 4.01ns= 16.8c  T: 5.20ns= 21.83c
XCHG r64, [m64]           L: 4.01ns= 16.8c  T: 5.12ns= 21.50c

ADD r32, 0x04000          L: 0.33ns=  1.0c  T: 0.12ns=  0.36c
ADD r32, 0x08000          L: 0.31ns=  0.9c  T: 0.12ns=  0.37c
ADD r32, 0x10000          L: 0.31ns=  0.9c  T: 0.12ns=  0.36c
ADD r32, 0x20000          L: 0.31ns=  0.9c  T: 0.12ns=  0.36c
ADD r8, r8                L: 0.31ns=  0.9c  T: 0.11ns=  0.34c
ADD r16, r16              L: 0.31ns=  0.9c  T: 0.11ns=  0.32c
ADD r32, r32              L: 0.31ns=  0.9c  T: 0.11ns=  0.34c
ADD r64, r64              L: 0.31ns=  0.9c  T: 0.10ns=  0.31c
ADD r8, [m8]              L: 1.87ns=  5.6c  T: 0.16ns=  0.47c
ADD r16, [m16]            L: 1.87ns=  5.6c  T: 0.16ns=  0.47c
ADD r32, [m32]            L: 1.87ns=  5.6c  T: 0.16ns=  0.47c
ADD r64, [m64]            L: 1.87ns=  5.6c  T: 0.16ns=  0.47c
ADD [m8], r8              L: 1.89ns=  5.7c  T: 0.33ns=  1.00c
ADD [m16], r16            L: 1.87ns=  5.6c  T: 0.26ns=  0.78c
ADD [m32], r32            L: 1.87ns=  5.6c  T: 0.28ns=  0.84c
ADD [m32 + 8], r32        L: 1.89ns=  5.7c  T: 0.26ns=  0.78c
ADD [m64], r64            L: 1.89ns=  5.7c  T: 0.33ns=  1.00c
ADD [m64 + 16], r64       L: 1.89ns=  5.7c  T: 0.24ns=  0.73c
0