いつまでも非力であり続けるのかは判らないが、そんな雰囲気になっている。
今のCPUはDDRの様な遅いメモリに直接アクセスしない様にすることでクロックに見合った性能を上げている。
簡単に云えば、よく使うデータをかき集め、CPUの周囲にある高速なメモリにストックすれば、とりあえず遅いDDRに合わせて一緒に低速で処理を進める必要は無くなっているのだ。
だからDDRのクロックを上げても同様に処理速度があがる訳では無い。
GPUの場合はとにかくDDRからポリゴンをどんどん吸い取らないといけないのでDDRのクロックがあがるとGPUのコアの休憩時間をより短くでき効果が期待できる。
今のAPUの中のCPUはその高速なメモリにINTELよりゆっくりアクセスしている（大体半分未満）。
これは、CPUとL1キャッシュ間のメモリ転送のクロックの差と云うより、CPUとL1キャッシュ間のメモリアクセスの方式の違いなのだろう。
マシン語を解釈するデコーダが吐き出すマイクロコードもL1キャッシュアクセス方式に応じて組み上げられるだろうから、そこが遅いとどうしようも無い。
では何が足りないのだろう。
推測するしかないけど、
- 次のマイクロコードのためにL1キャッシュからメモリをLoadするアドレスを計算する。
- 先のアドレスのL1キャッシュのメモリをアクセスしデータを読む。
- 前のマイクロコードで処理した結果をL1キャッシュのメモリにSaveするアドレスを計算する。
- 先のアドレスのL1キャッシュのメモリをアクセスしデータを書き込む。
の４つをパイプライン化し１クロックで一度にできる様に見せかけるだけでも効果があるような気がする。
だがすでにそうなっているのかもしれないし、そのためにアクセス速度が低下しているのかもしれない。
なぜなら、先のアドレスが同じなら、LoadせずSaveデータをループバックして読み取る必要がある。
実際どうなっているかは全く判らないので、仮にSave、Loadを同時並行可能だとしよう。
その場合でもL1キャッシュの向こう側にはL2キャッシュがあるのでL1-L2間のデータの同期処理が起きれば、２モードアクセスであってもCPUは待機するしかないし、２モードアクセスであるからこそ待ち時間が2倍になっているのかもしれない。そうなるとL1-L2キャッシュ間のデータの同期処理がすぐ完了するか、マイクロコードの指示で同期の先延ばしも必要なのかもしれない。
そう考えると事前（何クロックも前）にLoadデータの取得要求を出す様にマイクロコードのパイプラインを緻密に埋め合わせ、一見CPUを待たせない様に見える感じでL1キャッシュを使い倒す技術が重要な気がする。しかしそれは経験がモノを云うのだろう。高機能なL1キャッシュコントローラを作ればCPUの処理としては大変楽になりそうだがコントローラの処理自体が重くなりCPUはコントローラーの応答をただ待っている（ストール）しかなくなりメモリ転送速度の高速化にあまり寄与しないだろう。
たぶん大幅なCPUの改訂が行われるまで今の状態は続くのだろう。そしてそれ（改訂）がやってくるのはいつなんだろう？