Здравствуйте, Максим, Вы писали:
М>Да, но тогда получается что, время когда второй поток увидит эти изменения никому неизвестно. Если логика программы завязана на данной переменной, то возможны сюрпризы, Разве не так?
Это время практически константно для конкретной микроархитектуры, распределения потоков между ядрами, и сценария их совместной работы.
Тут сюрприза особо не для кого нет, гарантии модели памяти имеют некоторые издержки и одновременная работа двух потоков с одной и той же переменной даёт пенальти к скорости их совместной работы.
Re: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, Alexander G, Вы писали:
AG>Атомарность на самом деле гарантируется для правильно выровненных 32-битных типов, и 64-битных типов на x64.
Атомарные чтение или запись, но не чтение-модификация-запись.
AG>Memory ordering гарантии бесплатны на x86 и не бесплатны на ARM, поэтому логика в /volatile:iso для ARM понятна.
Не бесплатны они на x86, отсюда ноги и растут у нового макбука на арме который обгоняет x86.
Оно бесплатно с точки зрения компилятора, но выполняется аппаратно, что в общем тормозит
исполнение постоянными перезаписями в память на ровном месте.
AG>Вопрос собственно: а к чему приведёт включение /volatile:iso на x86?
AG> * компилятор не переставляет volatile переменные относительно другого кода (имеет право, но не был за этим замечен)
GCC был замечен, и это было крайне печальное зрелище. Код просто разодран на две части: всё остальное
и работа с volatile, которая съехала в конец функции, где у компилятора больше свободных регистров, видимо.
Но правда MIPS. Может на x86 и по-другому.
Re[4]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>поскольку компилятор ничего не обещает в плане атомарности. AG>>Платформа обещает ЕМ>Это лишь о чтении/записи, и только выровненных данных в пределах ширины магистрали. Разве такие операции не везде атомарны? Даже представить не могу, для чего могло бы потребоваться выполнять их иначе, чем за один цикл.
Обращение с невыравненными словами окажется не атомарным. Это физически два цикла с разными адресами.
И между ними во-первых может что-то вклиниться на аппаратном уровне (другой CPU). Во-вторых в некоторых
случаях (MIPS, старые ARM) процессор не умеет обращаться к невыравненному адресу вообще и формирует исключение.
И дальше процессор уходит в ядро ОС, где инструкция вызвавшая исключение эмулируется побайтово...
Работает такое адски медленно. Уже не за 2 цикла, а за все 2000.
Re[6]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, netch80, Вы писали:
N>RISC-V имеет атомарные операции на 32 и 64 бита, но не на более узкий тип. Реальный живой пример. CAS делается через LL/SC (ABA проблемы нет). N>x86 и ARM с атомарными операциями любого размера тут откровенно расслабили всех.
Кстати, интересно, что вспомнили LL/SC. Получается многие RISC позволяют реализовать семейства алгоритмов не реализуемые
на x86 в принципе. Как раз из-за ABA. Интересно, используется ли этот факт где-либо достаточно широко?
Re[2]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, fk0, Вы писали:
fk0>Здравствуйте, Alexander G, Вы писали
AG>>Вопрос собственно: а к чему приведёт включение /volatile:iso на x86?
AG>> * компилятор не переставляет volatile переменные относительно другого кода (имеет право, но не был за этим замечен)
fk0> GCC был замечен,
Ну как бы речь именно об MSVC, у GCC и опции /bolatile:iso нет, не удивлюсь, если он на x86 переставляет.
Русский военный корабль идёт ко дну!
Re[2]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, fk0, Вы писали:
fk0> GCC был замечен, и это было крайне печальное зрелище. Код просто разодран на две части: всё остальное fk0>и работа с volatile, которая съехала в конец функции, где у компилятора больше свободных регистров, видимо. fk0>Но правда MIPS. Может на x86 и по-другому.
Запросто.
int a;
volatile int b;
void foo()
{
a = 1;
b = 2;
a = 3;
}
Здравствуйте, Alexander G, Вы писали:
fk0>> GCC был замечен, AG>Ну как бы речь именно об MSVC, у GCC и опции /bolatile:iso нет, не удивлюсь, если он на x86 переставляет.
На всех. Clang туда же.
Чтобы обеспечить что-то похожее на собственный MSVC стиль — есть средства из C11 atomics.
Заметим, для чтения-записи атомарной переменной форсируется volatile.
MS, если верить доке, умеет это же. Но тогда непонятно, зачем эти извращения с volatile. Опять совместимость с глюками 20-летней давности?
The God is real, unless declared integer.
Re[7]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, fk0, Вы писали:
N>>RISC-V имеет атомарные операции на 32 и 64 бита, но не на более узкий тип. Реальный живой пример. CAS делается через LL/SC (ABA проблемы нет). N>>x86 и ARM с атомарными операциями любого размера тут откровенно расслабили всех.
fk0> Кстати, интересно, что вспомнили LL/SC. Получается многие RISC позволяют реализовать семейства алгоритмов не реализуемые fk0>на x86 в принципе. Как раз из-за ABA. Интересно, используется ли этот факт где-либо достаточно широко?
Про "в принципе" я бы не утверждал, TSX таки начало работать, с десятой попытки
И у него серьёзное преимущество, потому что LL/SC обычно ограничено одной локацией (почему-то команды типа "сбросить историю" к нему не завезли), а у TSX несколько (5, 10...) вполне норма.
У меня тут максимальное сомнение вызывает, насколько широко важны алгоритмы, которым ABA может что-то испортить. Я с ходу вообще ни одного примера не помню.
The God is real, unless declared integer.
Re[3]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Вот, кстати, по этой ссылке грузится версия 72 (май 2020). А если сходить по входной странице и выбрать хотя бы по-томную версию — будет 76-я.
А раньше я смог сгрузить однофайловую 73-ю.
Чего-то тут неладно...
The God is real, unless declared integer.
Re[4]: Что именно делают /volatile:ms и /volatile:iso на x86 ?
Здравствуйте, fk0, Вы писали:
AG>>Memory ordering гарантии бесплатны на x86 и не бесплатны на ARM, поэтому логика в /volatile:iso для ARM понятна.
fk0> Не бесплатны они на x86, отсюда ноги и растут у нового макбука на арме который обгоняет x86.
Ну что именно из этого растут ноги у преимуществ ARM в виде Apple — ещё толком неизвестно... мало данных.
Упорядочение записи нужно как минимум для precise exceptions. Если команда B идёт после A, и ещё неизвестно, что будет в результате A, не вылетит ли — мы не можем опубликовать результаты B.
И если A может затянуться на заметное время — откладывать внешнее прерывание тоже некошерно.
С imprecise exceptions игрались, например, в SPARC — в итоге не понравилось.
Поэтому почти гарантированное упорядочение операций записи согласно порядку вычитывания из потока исполнения — будет свойством всех реальных архитектур.
А вот с чтением интереснее. ARM упорядочение чтения не делает аж никак, если не попросили. X86 же делает сначала предвыборку, а потом слежение за изменением уже выбранного. Возможно, это слишком дорого...
Одно из объяснений возможного преимущества ARM перед x86 тут значительно более дешёвый декодер команд. Но и у него есть противники.
fk0>Оно бесплатно с точки зрения компилятора, но выполняется аппаратно, что в общем тормозит fk0>исполнение постоянными перезаписями в память на ровном месте.
"Постоянных перезаписей" на x86 нет, по крайней мере на нормальном коде. Чтобы было заметное торможение от этого, надо иметь или кучу подряд записей в (желательно перемежающиеся) потоки операций, типа:
a = 1;
b = 1;
a = 2;
b = 2;
a = 3;
b = 3;
их, конечно, соптимизирует на уровне L1, но по дороге от УУ к L1 через store buffer будут тянучки.
Даже несколько раздельных записей по байту в пределах одной строки кэша не дадут такой странный результат.
