+J
терминал
system("chcp 1251") если терминал такое поддерживает xD
Size: a a a
2021 February 16
VS
терминал
Обычно терминалы сразу в утф-8 работают
VS
++ Joka;
system("chcp 1251") если терминал такое поддерживает xD
cmd.exe это не терминал
VS
Блин вроде где-то мелькал универсальный гайд по дружбе кириллицы, винды и с++
CD
++ Joka;
Можете подсказать, в многопоточной разработке с использованием lock-free алгоритмов и атомиков, если у моей архитектуры точно работает протокол MESI, нужно ли мне парится за реордеринг внутри комманд процессора (Конкретнее за инвалидацию кэшей)? Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором.
> Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором
не очень понятен вопрос, если речь про C/C++, то речь идёт о программировании виртуальной машины, и гарантии в барьерах атомиков распространяются на итоговый сгенерированный код
не очень понятен вопрос, если речь про C/C++, то речь идёт о программировании виртуальной машины, и гарантии в барьерах атомиков распространяются на итоговый сгенерированный код
+J
> Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором
не очень понятен вопрос, если речь про C/C++, то речь идёт о программировании виртуальной машины, и гарантии в барьерах атомиков распространяются на итоговый сгенерированный код
не очень понятен вопрос, если речь про C/C++, то речь идёт о программировании виртуальной машины, и гарантии в барьерах атомиков распространяются на итоговый сгенерированный код
Имеется в виду код, кт в теории может соблюдать порядок проверки каких-то флагов, но не соблюдать порядок их инициализации относителтно друг друга. (Потому что они например в разных потоках инциализируются и оба получаются release). Условно говоря, они могут порождать ситуацию, когда f1 у одного процессора true, f2 - false, а у другого наоборот. Фиксится ли это самой системой (каким-нибудь умным протоколом)?
CD
то есть, скажем, если некоторый барьер запрещает переупорядочивать load двух переменных, то компилятор должен сгенерировать код так, что процессор гарантированно выполнит этот load в этом же порядке
AB
Правильно я понимаю, что reinterpret_cast для случаев подобных тому, когда хочется float поместить в 4 char например побитово?
Для этого есть memcpy или биткаст
AB
CD
++ Joka;
Имеется в виду код, кт в теории может соблюдать порядок проверки каких-то флагов, но не соблюдать порядок их инициализации относителтно друг друга. (Потому что они например в разных потоках инциализируются и оба получаются release). Условно говоря, они могут порождать ситуацию, когда f1 у одного процессора true, f2 - false, а у другого наоборот. Фиксится ли это самой системой (каким-нибудь умным протоколом)?
Я о чём пытаюсь сказать. Если формально C/C++ код допускает такое состояние (а, как я понимаю, запись с release его допускает), то компилятор считает такой результат допустимым, иначе нет
se
все равно не принимает кириллицу, только вывод кириллицы исправляется
CD
++ Joka;
Имеется в виду код, кт в теории может соблюдать порядок проверки каких-то флагов, но не соблюдать порядок их инициализации относителтно друг друга. (Потому что они например в разных потоках инциализируются и оба получаются release). Условно говоря, они могут порождать ситуацию, когда f1 у одного процессора true, f2 - false, а у другого наоборот. Фиксится ли это самой системой (каким-нибудь умным протоколом)?
То есть нет никакой разницы между "ограничениями для компилятора" и "ограничениями, которые соблюдаются в результирующем коде", если речь не идёт о volatile-операциях
D
++ Joka;
Можете подсказать, в многопоточной разработке с использованием lock-free алгоритмов и атомиков, если у моей архитектуры точно работает протокол MESI, нужно ли мне парится за реордеринг внутри комманд процессора (Конкретнее за инвалидацию кэшей)? Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором.
Что именно подразумевается под "париться"?
+J
Что именно подразумевается под "париться"?
Ну писать таким образом чтобы быть уверенным, что такой ситации не будет
D
++ Joka;
Ну писать таким образом чтобы быть уверенным, что такой ситации не будет
Какой "такой"?
Я все еще не вижу конкретики, которую можно обсудить в рамках Стандарта)
Я все еще не вижу конкретики, которую можно обсудить в рамках Стандарта)
+J
Какой "такой"?
Я все еще не вижу конкретики, которую можно обсудить в рамках Стандарта)
Я все еще не вижу конкретики, которую можно обсудить в рамках Стандарта)
При которой разные ядра в какой-то тик видят разные значения, ща найду пример и мб вы мне объясните что я неправильно понял
+J
А ссылку на гит можно отправить?
D
++ Joka;
А ссылку на гит можно отправить?
Думаю, да
Лучше прямо на строку, не на портянку
Лучше прямо на строку, не на портянку
+J
То есть нет никакой разницы между "ограничениями для компилятора" и "ограничениями, которые соблюдаются в результирующем коде", если речь не идёт о volatile-операциях
https://github.com/anthonywilliams/ccia_code_samples/blob/main/listings/listing_5.7.cpp - там мало строк, это из уильямса, кт утверждает, что тут ассерт может и сработать, хотя для компилятора все ясно в плане реордеринга, для процессора может быть ситуация с противоположными значениями. Подробно он не называет причину, но как я понял - инвалидация кэшей. Вот тут то и вопрос, а нужно ли о таком переживать, если есть MESI? Иначе я не понимаю почему assert может и сработать :/
CD
++ Joka;
https://github.com/anthonywilliams/ccia_code_samples/blob/main/listings/listing_5.7.cpp - там мало строк, это из уильямса, кт утверждает, что тут ассерт может и сработать, хотя для компилятора все ясно в плане реордеринга, для процессора может быть ситуация с противоположными значениями. Подробно он не называет причину, но как я понял - инвалидация кэшей. Вот тут то и вопрос, а нужно ли о таком переживать, если есть MESI? Иначе я не понимаю почему assert может и сработать :/
нужно переживать хотя бы потому, что с точки зрения компилятора это возможный результат исполнения