5年前C言語のソースコードにA=B=C=D=100;のような書き方ありますよね。コンパイル結果として下記のどれに相当でしょうか。B;(1)のほうが好ましいですが、(2)には問題二つあります:一つは頻繁にメモリをアクセスして遅い、また順番にD,C,Bをアクセスしなければならないので、その内に他のthreadにD,C,Bのどれかを別の値で更新しちゃう可能性もあるので、データの整合性問題が起きます。それでは実際(1)と(2)のどっちでしょうか。5年前コンパイラによると思いますが、A,B,C,Dが全てint型の変数であると仮定すると、gcc4.8.1では最適化オプションなし、-O2ともに(2)相当になりました。順番にD,C,Bをアクセスしなければならないので、その内に他のthreadにD,C,Bのどれかを別の値で更新しちゃう可能性もあるので、データの整合性問題が起きます。ロックなど、他の対策を考えてください。何を以って遅いといえるのでしょうか。実測したのでしょうか。D;だった場合、数値リテラルを代入するのであれば、A=100;B=100;C=100;D=100;とした場合より遅いことはまず無いと思います。確かに、単純な命令数では多くなることも多いかもしれません。レジスタアクセスや1クロックで済む命令などは、昨今では本当に誤差のレベルです。他の要因によってあっさりと逆転してしまうようなほどの軽微なものです。メモリをアクセスして遅い、と言いますが、大抵のアーキテクチャでレジスタアクセスは1クロックレベルで超高速ですし、整数の変数であればコンパイラ次第でキャッシュを仕込むかもしれません。コンパイラやコードの状況によっては最適化され、結果的に同じコードになることも多いはずです。「速くなると断言もできないし、遅くなる可能性すらある」ことです。そのようなことを気にして、1のような定数ハードコーディングを行う事は、返ってプログラムの見通しや保守性を落とす結果を招くことがほとんどです。それでプログラムにバグが生まれれば本末転倒です。開発効率を犠牲にしてまでクロック単位で最適化をする開発など、それこそ天文学などの科学計算の分野か、よほど速度の出ない組み込み開発くらいです。昔はそれが当たり前な時代もあったでしょうけども、今の時代でそれは稀なことです。確かに実行コストの高い命令を気にしてコーディングすることはありますが、今回の件は過剰すぎます。高速な部類の命令すらネックになるのなら、根本的にそのプログラムの設計が間違っているか、スーパーコンピュータでも買うべきです。順番にD,C,Bをアクセスしなければならないので、その内に他のthreadにD,C,Bのどれかを別の値で更新しちゃう可能性もあるので、データの整合性問題が起きます。それは全く話の違う問題です。代入の問題ではありません。他のスレッドから値が更新される可能性があるのであれば、排他制御を行えば良いだけの話です。それはマルチスレッドの問題であって、C言語の代入構文のせいではありません。仮に他のスレッドからアクセスされる可能性があるのであれば、A=100;B=100;C=100;D=100;と書いたとしても同様にデータレースの可能性があるからです。(1)の方が好ましいというのは、勘違い、思い込みかと思われます。(1)がマルチスレッドで安全だと思ってコーディングしているのなら、そのコードではスレッドセーフではない可能性が高いです。非常に有益な議論と教授をいただきまして、本当にいい勉強になりました。これからはアセンブラ言語を勉強して、さらに研究していこうと思います。解決となっていますし,今まで投稿していない人間がしゃしゃり出てきて書くのもなんですが,結論の方向が明後日を向いているような気がしたので......。これからはアセンブラ言語を勉強して、さらに研究していこうと思います。理解した方がよいかと思いますよ。そもそも,速度が出るようにアセンブリ言語で書こうとすると,対象プロセッサを決定し,そのプロセッサの特性を理解し,各命令がどのようにパイプラインを使うかも知った上で,その時点でのキャッシュがどうなっているかも勘案して実行順序も決めていく必要があります。8086とかの牧歌的な時代ならクロックの総和である程度速度がわかりましたが,今どきのプロセッサはそう簡単に速度がわかる物ではないです。順番にD,C,Bをアクセスしなければならないので、その内に他のthreadにD,C,Bのどれかを別の値で更新しちゃう可能性もあるので、データの整合性問題が起きます。ロックなど、他の対策を考えてください。さんが書きました:また順番にD,C,Bをアクセスしなければならないので、その内に他のthreadにD,C,Bのどれかを別の値で更新しちゃう可能性もあるので、データの整合性問題が起きます。それは全く話の違う問題です。代入の問題ではありません。他のスレッドから値が更新される可能性があるのであれば、排他制御を行えば良いだけの話です。それはマルチスレッドの問題であって、C言語の代入構文のせいではありません。とお二方ともから指摘されているとおり,スレッド間でのアクセス競合の問題はアセンブリ言語を勉強したところでどうにかなるものではないです。CPU命令を直接使う必要はないでしょう。これからはアセンブラ言語を勉強して、さらに研究していこうと思います。...どうしてそうなったんでしょう...?別にアセンブラがやりたいならやめろとは言いませんけど、もしも、アセンブラを自分で書けば速くなると思っているのなら、大間違いです。実験をしたりデータシートなどで調べたりしてください。実験の結果は環境依存ですが、全く根拠がない推測よりはマシだと思います。ミクプラは自由にリンクできます。