この質問のタイトルを決めるのに本当に苦労しましたが、うまくできたとは思いません。もし誰かがより良いアイデアを持っているなら、編集ボタンはあなたのものです.
メモリ操作のコストが絶対的に最適なシナリオで 3 ～ 4 サイクル、潜在的にそれ以上であること、およびメモリ バスよりも「狭い」データの読み取りが最適ではないことを考慮すると、現在生成されているアセンブリ言語の構造は最適ではありません。それも？
登録操作にかかる時間は大幅に短縮されます。そのため、式の前に式を評価して迅速に実行するために必要なすべてのデータをアセンブリがフェッチしないのはなぜでしょうか。これにより、スレッドの切り替えが減り、プロセッサが他のスレッドを実行できるようになります。
get data 1 - 4 cycles
perform calculation 1 - 1 cycle
get data 2 - 4 cycles
perform calculation 2 - 1 cycle
get data 3 - 4 cycles
perform calculation 3 - 1 cycle
最終的に、15 サイクルの CPU 使用があります。
get all data sequentially - 8 cycles
perform calculation 1 - 1 cycle
perform calculation 2 - 1 cycle
perform calculation 3 - 1 cycle
11 サイクルが使用され、これは 25% の改善です。また、メモリは専用のオンチップ ハードウェア コントローラによってフェッチされ、はるかに長い時間アイドル状態になるため、実際の CPU は 3 サイクルだけビジーになります。
最初の「例」でもデータを待っている間にCPUが他のコードの実行をスケジュールできると思いますが、ウィンドウがはるかに短く、コンテキストを切り替えるためのサイクルペナルティがあれば、ほとんど価値がないと思います.2番目の例このアプローチは、より多くのレジスターを消費しますが、全体的な CPU パフォーマンスが向上するはずです。結局のところ、最新のプロセッサにはすべて少なくとも 16 個のレジスタがあり、現在の世代の新しいモバイル デバイス ARM チップでさえ 32 個のレジスタがあります。では、なぜ保守的なのでしょうか。おそらく、コンパイラは 8 レジスタ マシンの時代にまだ残っているのでしょうか?
この仮定は当てはまりますか、それとも現在の CPU アーキテクチャはそのようなメカニズムを利用するように設計されていないのでしょうか? CPU がデータを待機している間、他のコードを実行できると仮定します。特に最新のプロセッサのほとんどが順不同であることを考慮すると、最終的に最悪のシナリオでは、データの取得に同じ時間を無駄にしますが、すべてのデータがあれば、コード フラグメントをより高速に実行できるため、プロセッサが停止する時間が短くなります。