printfはメモリバリアなりや？

くまぎ @kumagi

printfは内部でlock取ってるので、printfそのものがメモリバリアの役目を果たす。略してprintfバリア。

くまぎ @kumagi

でもprintfによるメモリバリアって、x86の上にいるかぎりはmfence相当の意味しか無くて、mfenceの有無で走らないコードとかとてもbrain damagingなので僕は裸足で逃げ出したい。

くまぎ @kumagi

よく考えたらprintfはコンパイルタイムでのメモリバリアとして充分過ぎる作用があるじゃないか。コンパイルタイムでのメモリバリア、という用語が正しいのかは知らないけれど。

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@kumagi staticじゃない関数呼び出しは、コンパイラからすれば、何するか分からない点で一緒じゃないかな ﾟ+.(･ω･)ﾟ+.ﾟ

くまぎ @kumagi

@kosaki55tea 確かにprintfに限らず、インライン化されない関数はコンパイラにとってリオーダ不可能ですね。

鯉江 @koie

@kumagi constexprだったら可能かも?

くまぎ @kumagi

@koie あー、そうですね。コンパイラにとって挙動が全部分かっちゃう関数だと好きなだけリオーダは起こり得そうです。

とみながたけひろ @takehiro_t

@kosaki55tea freestandingじゃなければprintfはbuiltin扱いにできる(いまどきなgccはそうする)から「何するか分かる」んじゃ無いかな。かってにputsに置き換えたりするし

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@takehiro_t puts()でも副作用があることには変わりないので、gccタンには慰めになってないのでは？ attribute(pure)とかのほうが可能性がある気がする ﾟ+.(･ω･)ﾟ+.ﾟ

とみながたけひろ @takehiro_t

@kosaki55tea ああそうか、その先がどうなっているかまではわからんか。pure属性の方がよさそうですねえ。

中村 実 @nminoru_jp

@kumagi 「コンパイラ時のメモリバリア」はよくないと思いますよ。何と呼べばいいのか難しいですが、私なら「memory ambiguousを許すコンパイラ最適化を中断する記述orストップコード」とでも言うと思います。

くまぎ @kumagi

@nminoru_jp その表現は正確そうです。リオーダを許させない最適化抑制というだけなので、口で説明するなら言い方はありそうですが、メモリバリアという表現が適切でなさそうな気がするのは同感です。

中村 実 @nminoru_jp

@nminoru_jp @kumagi 明示的に記述する場合iccなら__memory_barrier、gccならasm volatile("" ::: "memory")ですね。これはメモリバリア命令とは関係ないです。

くまぎ @kumagi

@nminoru_jp iccはmemory_barrierと書かせてなおメモリバリア命令とは関係ないとかややこしいですね…iccってことはx86がメインでしょうけれどx64になったら多少はメモリバリアとして利用されるんでしょうか。

中村 実 @nminoru_jp

@nminoru_jp iccの__memory_barrierはメモリバリア命令を生成しない。メモリバリアを生成するのは__sync_synchronize。

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

キチガイ仕様としか思えない RT @nminoru_jp: @nminoru_jp iccの__memory_barrierはメモリバリア命令を生成しない。メモリバリアを生成するのは__sync_synchronize。

中村 実 @nminoru_jp

@kosaki55tea @kumagi プロジェクトに属する.cファイル全体をコンパイルするwhole-program optimizationやリンカ最適化があるので、非staticな関数で最適化が切れるとは限らないですよ。実用上printfを跨いだ最適化は無理だと思いますが

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@nminoru_jp @kumagi whole-program optimization でちゃんと安全な関数と安全じゃない関数とをよりわけたうえでreorderするならなんの問題もないので考えなくていいじゃまいか？

中村 実 @nminoru_jp

@kosaki55tea @kumagi そうなんですがwhole-program opt.は安全だと判断するとグローバル関数を越えてreorderしてしまうので、「非static関数の呼び出しはコンパイラがその先を読めないから、メモリ最適化を止める」と期待すると危ういのです。