Средняя задержка атомарных команд cmpxchg на процессоре Intel

Question

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

Спасибо.

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

• xchg reg1, reg2 не блокируется;
• add к регистрам и памяти.

Как видите, инструкции lock всего в 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

Answer 4

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

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

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

Answer 5

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

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

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

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