Хуже ли в любом аспекте использовать инструкцию CMPXCHG в 8-битном поле, чем в 32-битном поле? - PullRequest
6 голосов
/ 03 октября 2019

Я хотел бы спросить, будет ли использование инструкции CMPXCHG для 8-битного поля памяти хуже в любом аспекте, чем использование для 32-битного поля.

Я использую C11 stdatomic.h для реализации нескольких методов синхронизации.

1 Ответ

8 голосов
/ 03 октября 2019

Нет, штраф за lock cmpxchg [mem], reg 8 не взимается против 32-разрядного . Современные процессоры x86 могут загружать и сохранять в свой кэш L1d без штрафа за один байт против выровненного слова или слова. Может ли современное аппаратное обеспечение x86 не хранить один байт в памяти? ответ: оно может с нулевым штрафом 1 , поскольку они тратят транзисторы на быстрое выравнивание нагрузки / сохранения.

Окружающие ассемблерные инструкции, имеющие дело с узким целым числом в регистре, также должны иметь незначительное значение, если какие-либо дополнительные расходы против [u]int32_t. См. Почему GCC не использует частичные регистры? - большинство компиляторов знают, как быть осторожными с частичными регистрами, и современные процессоры (Haswell и более поздние, и все не-Intel) не переименовывают младшие 8 отдельноиз остальной части реестра, поэтому единственная опасность - ложные зависимости. В зависимости от того, что именно вы делаете, может быть лучше использовать unsigned локальные временные символы с _Atomic uint8_t, либо лучше сделать местных жителей также uint8_t.

Сноска 1: в отличие отна некоторых процессорах не x86, где хранилище байтов фактически реализовано с циклом RMW кэша ( Есть ли какие-либо современные процессоры, где хранилище байтов в кэше на самом деле медленнее, чем хранилище слов? ). На этих процессорах вы надеетесь, что атомарный xchg будет таким же дешевым для слова против байта, но это слишком много, чтобы надеяться на cmpxchg. Но почти все ISA, отличные от x86, имеют LL / SC вместо xchg / cmpxchg, так что даже атомный обмен - это отдельные инструкции LL и SC, и SC будет выполнять цикл RMW для фиксации в кэше.

...