Сообщение Re[7]: Memory barrier не могу понять что это от 08.04.2023 22:21
Изменено 08.04.2023 22:23 Философ
Re[7]: Memory barrier не могу понять что это
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Философ, Вы писали:
Ф>>Интересно, откуда инфа? Можно какие-нибудь доказательства [...] или дизасм получающегося кода, или объяснение того, что именно будет делать функция типа
Ф>>
Ф>>Я ОООчень бы хотел узнать, почему вы так думаете, откуда вы это взяли и где тут логика.
Ф>>Т.е. если платформа не AMD64 будет действительно xchg. Но логики я тут всё равно не вижу.
O>Прежде всего, откуда я это взял. Работа такая
O>Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Видел что? Во что превращается c++ intrinsic _mm_mfence?
O>И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.
Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.
O>sfence/lfence/mfence, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.
О таков варианте использования в мануале по оптимизации для Pentium-4, где они впервые появились. К несчастью полную докуменацию по Pentium-4 мне не удалось найти — не могу ни подтвердить, ни опровергнуть
O>В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
O>locked-инструкциями типа xchg.
Весьма примерно представляю, как это проверить. Буду рад примеру кода, который подтвердит или опровергнет эту гипотезу.
O>Вообще, тема эта очень обширная и сложная, в двух-трех предложениях и малой части не описать.
Ооо! Это точно.
O>Например, очень часто компилятор не вставляет никаких специальных
O>барьеров туда, где ты вроде бы их ожидаешь. Например потому, что определенные гарантии предоставляет сама архитектура: "stores are not reordered with other stores" и т.д.
Не понимаю о чём идёт речь. Что и где должно теоретически быть, но не вставляет? Я думал, что синхронизация целиком и полностью ответственность программиста.
O>Здравствуйте, Философ, Вы писали:
Ф>>Интересно, откуда инфа? Можно какие-нибудь доказательства [...] или дизасм получающегося кода, или объяснение того, что именно будет делать функция типа
Ф>>
Ф>>void Foo(){
Ф>>Thread.MemoryBarrier();
Ф>>}
Ф>>Ф>>Я ОООчень бы хотел узнать, почему вы так думаете, откуда вы это взяли и где тут логика.
Ф>>Т.е. если платформа не AMD64 будет действительно xchg. Но логики я тут всё равно не вижу.
O>Прежде всего, откуда я это взял. Работа такая
:-)O>Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Видел что? Во что превращается c++ intrinsic _mm_mfence?
O>И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.
Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.
O>sfence/lfence/mfence, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.
О таков варианте использования в мануале по оптимизации для Pentium-4, где они впервые появились. К несчастью полную докуменацию по Pentium-4 мне не удалось найти — не могу ни подтвердить, ни опровергнуть
O>В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
O>locked-инструкциями типа xchg.
Весьма примерно представляю, как это проверить. Буду рад примеру кода, который подтвердит или опровергнет эту гипотезу.
O>Вообще, тема эта очень обширная и сложная, в двух-трех предложениях и малой части не описать.
Ооо! Это точно.
O>Например, очень часто компилятор не вставляет никаких специальных
O>барьеров туда, где ты вроде бы их ожидаешь. Например потому, что определенные гарантии предоставляет сама архитектура: "stores are not reordered with other stores" и т.д.
Не понимаю о чём идёт речь. Что и где должно теоретически быть, но не вставляет? Я думал, что синхронизация целиком и полностью ответственность программиста.
Re[7]: Memory barrier не могу понять что это
Здравствуйте, okman, Вы писали:
O>Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Видел что? Во что превращается c++ intrinsic _mm_mfence?
O>И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.
Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.
O>sfence/lfence/mfence, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.
О таков варианте использования в мануале по оптимизации для Pentium-4, где они впервые появились. К несчастью полную докуменацию по Pentium-4 мне не удалось найти — не могу ни подтвердить, ни опровергнуть
O>В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
O>locked-инструкциями типа xchg.
Весьма примерно представляю, как это проверить. Буду рад примеру кода, который подтвердит или опровергнет эту гипотезу.
O>Вообще, тема эта очень обширная и сложная, в двух-трех предложениях и малой части не описать.
Ооо! Это точно.
O>Например, очень часто компилятор не вставляет никаких специальных
O>барьеров туда, где ты вроде бы их ожидаешь. Например потому, что определенные гарантии предоставляет сама архитектура: "stores are not reordered with other stores" и т.д.
Не понимаю о чём идёт речь. Что и где должно теоретически быть, но не вставляет? Я думал, что синхронизация целиком и полностью ответственность программиста.
O>Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Видел что? Во что превращается c++ intrinsic _mm_mfence?
O>И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.
Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.
O>sfence/lfence/mfence, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.
О таков варианте использования в мануале по оптимизации для Pentium-4, где они впервые появились. К несчастью полную докуменацию по Pentium-4 мне не удалось найти — не могу ни подтвердить, ни опровергнуть
O>В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
O>locked-инструкциями типа xchg.
Весьма примерно представляю, как это проверить. Буду рад примеру кода, который подтвердит или опровергнет эту гипотезу.
O>Вообще, тема эта очень обширная и сложная, в двух-трех предложениях и малой части не описать.
Ооо! Это точно.
O>Например, очень часто компилятор не вставляет никаких специальных
O>барьеров туда, где ты вроде бы их ожидаешь. Например потому, что определенные гарантии предоставляет сама архитектура: "stores are not reordered with other stores" и т.д.
Не понимаю о чём идёт речь. Что и где должно теоретически быть, но не вставляет? Я думал, что синхронизация целиком и полностью ответственность программиста.