В основном не оказывает существенного влияния на задержку между ядрами, , и определенно никогда не стоит использовать «вслепую» без тщательного профилирования, если вы подозреваете, что возможны конфликты из-за более поздних загрузок, отсутствующих в кэше.
Распространено заблуждение, что для фиксации буфера хранилища в кеше требуются asm-барьеры. Фактически, барьеры просто заставляют это ядро ждать, пока что что-то уже произойдет само по себе , прежде чем делать последующие загрузки и / или хранения. Для полного барьера блокирование позднее загружается и сохраняется до тех пор, пока буфер хранилища не будет исчерпан. Размер буферов магазина на оборудовании Intel? Что такое буфер хранения?
В старые добрые времена до std::atomic, барьеры компилятора были единственным способом помешать компилятору хранить значения в registers (приватно для ядра / потока ЦП, не связно), но это проблема компиляции, а не асм. В теории возможны процессоры с некогерентными кешами (где std :: atomi c потребуется сделать явную очистку, чтобы сделать хранилище видимым), но на практике на практике ни одна реализация не запускает std :: thread через ядра с не когерентные кеши .
Если я не использую ограждения, сколько времени может потребоваться ядру, чтобы увидеть записи другого ядра? тесно связано, я написал в основном этот ответ хотя бы несколько раз раньше. (Но это выглядит как хорошее место для ответа конкретно по этому поводу, не вдаваясь в сорняки, какие барьеры делают что.)
Могут быть некоторые очень незначительные вторичные эффекты блокирования последующих загрузок, которые могут конкурировать с RFO (для этого ядра, чтобы получить эксклюзивный доступ к строке кэша для фиксации хранилища). Процессор всегда пытается истощить буфер хранилища как можно быстрее (путем фиксации в кэше L1d). Как только хранилище фиксирует кэш L1d, оно становится глобально видимым для всех остальных ядер. (Поскольку они согласованы; им все равно придется сделать запрос на совместное использование ...)
Получение текущего ядра для обратной записи некоторых данных хранилища в кэш L3 (особенно в совместно используемом состоянии) может уменьшить штраф за промах, если нагрузка на другое ядро происходит несколько позже после фиксации этого магазина. Но нет хороших способов сделать это. Создание конфликта Мисс в L1d и L2 возможно, если производительность производителя не важна, кроме создания низкой задержки для следующего чтения.
На x86, Intel Tremont (низкая Power Silver Series) представит cldemote (_mm_cldemote), который записывает строку обратно до внешнего кэша, но не до DRAM. (clwb, возможно, может помочь, но вынуждает магазин к go вплоть до DRAM. Кроме того, реализация Skylake является просто заполнителем и работает как clflushopt.)
Интересный факт: non-seq_cst сохраняет / загружает в PowerP C может сохранять данные между логическими ядрами на одном физическом ядре, делая хранилища видимыми для некоторых других ядер, прежде чем они станут глобальными видимы для всех других ядер. Это AFAIK единственный реальный аппаратный механизм для потоков, чтобы не согласовать глобальный порядок хранилищ для всех объектов. Будут ли две записи atomi c в разные места в разных потоках всегда рассматриваться в одном и том же порядке другими потоками? . На других ISA, включая ARMv8 и x86, гарантировано, что хранилища становятся видимыми для всех других ядер одновременно (через фиксацию в кеше L1d).
Для нагрузок центральные процессоры уже распределяют приоритеты спроса загружает поверх любых других обращений к памяти (потому что, конечно, выполнение должно ждать их.) Барьер, прежде чем загрузка может только задержать его.
Это может оказаться оптимальным по совпадению времени, если это заставит его увидеть магазин, который он ожидал, вместо того, чтобы "слишком рано" и увидеть старое кэшированное скучное значение. Но, как правило, нет причин предполагать или когда-либо прогнозировать, что pause или барьер могут быть хорошей идеей перед нагрузкой.
Барьер после нагрузки также не должен помогать. Более поздние загрузки или хранилища могут быть в состоянии запускаться, но ЦП с ошибками обычно делают вещи с самым старым приоритетом, поэтому более поздние загрузки, вероятно, не смогут заполнить все оставшиеся буферы загрузки, пока эта нагрузка не получит шанс получить свой запрос на загрузку. отправлено вне ядра (при условии отсутствия кэша, потому что недавно было сохранено другое ядро).
Я думаю, я мог бы представить выгоду для более позднего барьера, если бы этот адрес загрузки не был готов некоторое время (ситуация с погоней за указателем) и максимальное количество неосновных запросов уже находилось в полете, когда адрес стал известен.
Любая возможная выгода почти наверняка не стоит; если бы было столько полезной работы, независимой от этой нагрузки, что она могла бы заполнить все буферы неосновных запросов (LFB на Intel), то это вполне могло бы быть не на критическом пути, и, вероятно, было бы хорошо иметь эти нагрузки в полете .