スケジューラが性能の問題になっているのでは？という話

Core MicroArchitectureをもうすこし(14)で前から言っていたスケジューラがボトルネックになるのでは自説の理由みやたなものを紹介している
http://journal.mycom.co.jp/column/sopinion/190/

要するにトランジスタ数が2倍になっても、性能はルート2倍にしかならない、という話である。ここから逆に考えてみよう。今IPC=3に届くか届かないかといった話なので、まぁ仮にIPC=3とする。ここでIPC=4を目指すためには、性能を1.333...倍にすればよい。

個々の数字はまた後で触れるとして、既にConroeですら2800万トランジスタ余りである。ここでIPCを引き上げるために単純に1.777倍のトランジスタを費やすとすると、5100万ほどになる計算だ。

勿論時間が無制限にあれば良いが、現実には決められたタイムラインにあわせて製品を投入しないと会社の屋台骨が揺るぎかねないのが現在の半導体業界である。そこまでの冒険を犯す価値が、IPC=4の数字にあるかは結構疑問だ。

IPC4を目指して効率をあげるより、(かつては)クロックを上げる事やコアを増やす事、あるいはキャッシュ効率を上げること(なぜなら半分くらいの時間はメモリアクセスで休んでいるからhttp://journal.mycom.co.jp/articles/2006/12/11/sparc64/)に力を入れた方がよいということらしい。
1.7倍という推論のポラロックの法則はクロックの向上も込みした経験則だから、クロックあたりの命令数のみだと、さらに低くてルート３乗あたりになるのではないか。それよりは命令依存関係の確認の数にトランジスタ数が比例していると仮定したほうがロジカルだ。たぶん、完全に依存関係を確認しているのでなくて、すでに投入された命令に対してと貯めた命令のあいだの依存関係だけ計算しているだろう。現在20段くらいのパイプラインで貯めている命令数を12命令くらいで改定すると、IPC3だと20*3*3+50*49*48。なのでIPC4にすると(20*4*4+12*11*10*9)/(20*3*3+12*11*10)= 8.33倍のトランジスタが必要になる。ホットスポットになりやすい部分でこれじゃ真面目に増やすわけにいかない。12命令の中で3つ見つけると4つ見るけるではえらい違いだが。
それでもIntelが4命令、演算器を3つに増やしてきたのは最近のプログラムにスケジューラの負担が少ない単純に独立した計算がある程度あるということだろう。SPARC64VIやRockなどもそうだ。少なくとも4命令連続実行できる部分が局所的に存在しているはず。