ちょっと、疑問に思いました
あたりまえですが、中央装置(CPU)に近い言語の方がスピードが速く
中央から離れていくにしたがって、少しずつではあるけれども、スピードが若干遅くなっているという
仕組みが成り立っているのでしょうか?
マシン言語 > アセンブリ言語 > C/C++言語 > OS特有言語(スクリプトなど) > ユーザー操作
という感じに中心部が一番早く、中心部から離れるにしたがって
だんだんと遅くなっていくイメージという理解でよかったでしょうか?
特にこれといった理由はなく、ただ聞いて確認してみたいだけです
言語 ハードウェアのスピードについて
Re: 言語 ハードウェアのスピードについて
ユーザー操作が遅いのは確かなのですが,それ以外に関しては難しいです。dic さんが書きました:あたりまえですが、中央装置(CPU)に近い言語の方がスピードが速く
中央から離れていくにしたがって、少しずつではあるけれども、スピードが若干遅くなっているという
仕組みが成り立っているのでしょうか?
マシン言語 > アセンブリ言語 > C/C++言語 > OS特有言語(スクリプトなど) > ユーザー操作
という感じに中心部が一番早く、中心部から離れるにしたがって
だんだんと遅くなっていくイメージという理解でよかったでしょうか?
まず,間違いなく言える点から。
アセンブリ言語は,マクロや疑似命令などを除くと機械語と一対一で対応します。
そのため,(実行時の) 速度差という点では同等です。
# よっぽどの変人以外,記述速度は機械語よりアセンブリ言語の方が速いので,実行時の速度の話と仮定します。
ターゲットCPUへ直接コンパイルする言語 (C/C++等) は,コンパイルされた時点で機械語になります。
もちろん,機械語と一対一というわけではないのですが,ターゲットCPUの設定を間違えなければ,
一般人がアセンブリ言語で書くよりも効率的なコードが生成されます。
# 最近のCPUは速度を考え出すと難解で,昔のようにクロックサイクルを足していくことで速度を測定できません。
ターゲットCPUへ直接コンパイルしないコンパイル言語 (Java/C#等) は,コンパイルされた時点では仮想機械の機械語になります。
実行時に再度ターゲットCPUの機械語に再翻訳されるので,そういう意味では遅くなります。
ただし,実際の環境情報や実行パスを参照して最適化できるので,場合によっては直接コンパイルするより速度が速くなります。
インタプリタ言語・スクリプト言語も最近は大抵実行時コンパイルなので,上記 (ターゲットCPUへ直接コンパイルしないコンパイル言語) に準じます。
ただし,実行時にパースする都合上,効率は先にコンパイルしておくよりも悪くはなります。
さらに,操作がCPU束縛されない場合などは,上記の話が全く関係なくなる可能性があります。
マルチスレッド,GPGPUなども関係をややこしくします。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 言語 ハードウェアのスピードについて
少なくともマシン語とアセンブリ言語は同速です。記法が違うだけですからね。
マシン言語 = アセンブリ言語 > コンパイラ言語(C/C++等) > コンパイル&中間言語の言語(Java、C#) > インタプリタ言語 > ユーザー操作
コンパイラ言語の中でもC/C++も早いですが、FORTRANとかも早いですね。
コンパイラの最適化の出来る能力にもよるので、同じ言語でもコンパイラの性能次第で速度は変わります。
速度の要因は、どうやって実行しているかなのでインタプリタ言語がなぜ遅いのかはインタプリタの動作を考えてみれば分かると思います(作ってみるのが一番早いですが)。
マシン言語 = アセンブリ言語 > コンパイラ言語(C/C++等) > コンパイル&中間言語の言語(Java、C#) > インタプリタ言語 > ユーザー操作
コンパイラ言語の中でもC/C++も早いですが、FORTRANとかも早いですね。
コンパイラの最適化の出来る能力にもよるので、同じ言語でもコンパイラの性能次第で速度は変わります。
速度の要因は、どうやって実行しているかなのでインタプリタ言語がなぜ遅いのかはインタプリタの動作を考えてみれば分かると思います(作ってみるのが一番早いですが)。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 言語 ハードウェアのスピードについて
アセンブリ言語というのはニーモニック記述ということですか?
マクロアセンブラとかgccのインラインアセンブラとか最適化があるのでニーモニックとオペコードが一対一だったのはずっと昔の話だと思います。
一対一にアセンブルさせることもできますが、大局的には実行速度が落ちます。
ですからマシン語(オペコードのバイナリ羅列)でプログラミングしたら最高速というのも成り立ちません。
CPUがRISC化して以降、命令の配置が実行速度に大きく影響を与えるようになりましたから、極一部のクリティカルな処理をニーモニックで記述することはあっても、C/C++で書いたコードと比較してより高速に実行できるコードをニーモニックで記述できるプログラマなんていまやほとんど存在しないと思います。
言語の問題ではなくて、実行される際の事前処理の量が多いものが遅いということです。
例えばケータイやスマートフォンでは、JITコンパイルのないJavaアプリより、JITコンパイルのあるJavaScriptのほうが高速動作する可能性があります。
マクロアセンブラとかgccのインラインアセンブラとか最適化があるのでニーモニックとオペコードが一対一だったのはずっと昔の話だと思います。
一対一にアセンブルさせることもできますが、大局的には実行速度が落ちます。
ですからマシン語(オペコードのバイナリ羅列)でプログラミングしたら最高速というのも成り立ちません。
CPUがRISC化して以降、命令の配置が実行速度に大きく影響を与えるようになりましたから、極一部のクリティカルな処理をニーモニックで記述することはあっても、C/C++で書いたコードと比較してより高速に実行できるコードをニーモニックで記述できるプログラマなんていまやほとんど存在しないと思います。
言語の問題ではなくて、実行される際の事前処理の量が多いものが遅いということです。
例えばケータイやスマートフォンでは、JITコンパイルのないJavaアプリより、JITコンパイルのあるJavaScriptのほうが高速動作する可能性があります。
Re: 言語 ハードウェアのスピードについて
>>ISLeさん
>>YuOさん
そこまで細かいところは勉強していないので、参考になりました
>>softyaさん
コンパイラの性能の差もありますが、処理速度の順序としては
おおむね softyaさんがおっしゃっている順序のようですね
Java, C# は盲点でした
中間言語も最近は活躍してきてますね
インタプリンタ言語は、まだやったことがないです やってみたいですけど
スクリプト言語と混合していました
なかなか知識がおいついていないのが、確認とれて参考になりました
ありがとうございました
===追加
なるほど、CPU近く、中心部に近づく処理が豊富にあるともいえますね
どんどんCPUから離れていって、中間層を理解することも重要になってきているのですね
>>YuOさん
そこまで細かいところは勉強していないので、参考になりました
>>softyaさん
コンパイラの性能の差もありますが、処理速度の順序としては
おおむね softyaさんがおっしゃっている順序のようですね
Java, C# は盲点でした
中間言語も最近は活躍してきてますね
インタプリンタ言語は、まだやったことがないです やってみたいですけど
スクリプト言語と混合していました
なかなか知識がおいついていないのが、確認とれて参考になりました
ありがとうございました
===追加
なるほど、CPU近く、中心部に近づく処理が豊富にあるともいえますね
どんどんCPUから離れていって、中間層を理解することも重要になってきているのですね