Алло, это отладочная?

Во-вторых, авторы, кажется, слона то и не заметили. С тех пор, как для C/C++ появилась формальная модель памяти (а если точнее разные memory order), аргумент про "что этот компилятор себе позволяет" стали просто пугающе правдивыми. Известно, что C11 memory model отличается от Java memory model тем, что гонки по данным означают UB. По мне, так это очень хорошее изменение, которое делает понимание модели памяти куда проще. Ноооо, это ведь только когда мы говорим про конкурентный доступ к обычным переменным и полям. А вот если мы говорим про атомики, то все сильно сложнее: поведение при гонках полностью определено и сильно зависит от memory order.

Так вот есть другая, прекрасная статья (с еще более броским названием Common Compiler Optimisations are Invalid
in the C11 Memory Model and what we can do about it), в которой автор показывает, что безобидные вроде бы оптимизации* компилятора могут полностью поменять семантику программы и изменить множество потенциально наблюдаемых результатов при гонке на атомиках 🤯 Там много примеров, но все начинается с тривиального: когда код, исполняемый изначально в двух тредах просто выполняется в результате оптимизации последовательно в одном треде (и это меняет семантику!). Все это при условии гонки на атомиках с relaxed mo с участием третьего треда. Если не хотите читать полную статью и разбирать матан, то есть короткая преза про это от того же автора.

*речь про source-to-source оптимизации, либо отдельные фазы, до кодегена, понятно, тут дело не доходит, иначе было бы все хорошо.

—

В общем, аргументы любителей C в духе "я понимаю, в какой асм это будет скомпилировано" в современном мире звучат как-то слегка высокомерно. Между сишным кодом и получившимся асмом настоящая бездна, 50 лет разработки оптимизирующих компиляторов и слегка так сломанная модель памяти (бывает, че). Да и вообще, на это указывает само существование undefined behavior в спецификации языка. Так что стоит признать, что программирование на C тоже подразумевает некоторый абстрактный (а не железный) исполнитель, на котором исполнение этого кода и происходит.

Кстати, если хотите послушать про эволюцию моделей памяти в Java и не только (и вот в том числе про отличие JMM от C11 MM), то приходите на SnowOne на доклад Саши Ланцова 1 марта, который так и будет называться "Эволюция моделей памяти". Именно прогон черновой версии этого доклада меня и отправил в чтение статьи про сломанную модель памяти в сишечке нашей любимой. Рекомендую, доклад будет огонь!

#дух_машины

www.group-telegram.com/jp/gdb_dbg.com/379

621 viewsJan 12 at 14:23

Во-вторых, авторы, кажется, слона то и не заметили. С тех пор, как для C/C++ появилась формальная модель памяти (а если точнее разные memory order), аргумент про "что этот компилятор себе позволяет" стали просто пугающе правдивыми. Известно, что C11 memory model отличается от Java memory model тем, что гонки по данным означают UB. По мне, так это очень хорошее изменение, которое делает понимание модели памяти куда проще. Ноооо, это ведь только когда мы говорим про конкурентный доступ к обычным переменным и полям. А вот если мы говорим про атомики, то все сильно сложнее: поведение при гонках полностью определено и сильно зависит от memory order.

Так вот есть другая, прекрасная статья (с еще более броским названием Common Compiler Optimisations are Invalid
in the C11 Memory Model and what we can do about it), в которой автор показывает, что безобидные вроде бы оптимизации* компилятора могут полностью поменять семантику программы и изменить множество потенциально наблюдаемых результатов при гонке на атомиках 🤯 Там много примеров, но все начинается с тривиального: когда код, исполняемый изначально в двух тредах просто выполняется в результате оптимизации последовательно в одном треде (и это меняет семантику!). Все это при условии гонки на атомиках с relaxed mo с участием третьего треда. Если не хотите читать полную статью и разбирать матан, то есть короткая преза про это от того же автора.

*речь про source-to-source оптимизации, либо отдельные фазы, до кодегена, понятно, тут дело не доходит, иначе было бы все хорошо.

—

В общем, аргументы любителей C в духе "я понимаю, в какой асм это будет скомпилировано" в современном мире звучат как-то слегка высокомерно. Между сишным кодом и получившимся асмом настоящая бездна, 50 лет разработки оптимизирующих компиляторов и слегка так сломанная модель памяти (бывает, че). Да и вообще, на это указывает само существование undefined behavior в спецификации языка. Так что стоит признать, что программирование на C тоже подразумевает некоторый абстрактный (а не железный) исполнитель, на котором исполнение этого кода и происходит.

Кстати, если хотите послушать про эволюцию моделей памяти в Java и не только (и вот в том числе про отличие JMM от C11 MM), то приходите на SnowOne на доклад Саши Ланцова 1 марта, который так и будет называться "Эволюция моделей памяти". Именно прогон черновой версии этого доклада меня и отправил в чтение статьи про сломанную модель памяти в сишечке нашей любимой. Рекомендую, доклад будет огонь!

#дух_машины

BY Алло, это отладочная?