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

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

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

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

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

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

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

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

Я изучаю экспоненциальную отсрочку уже несколько месяцев.

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

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

Вы можете использовать программное обеспечение 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) Kaby Lake-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

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

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

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

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