では、そのLSDはどうか? という話を見てみたい。LSDの目的は何か? というと、こちらでも書いたとおり、MicroOpsの形で命令をFIFO式に蓄えることで、小規模なループであればデコード段を動作させることなく実行できるようにして、省電力と高性能を両立しようという企みである。

では具体的にどんな場合にこれが役立つか? というと、例えば図6の様な単純なループである。ある処理をループで廻しながら実施する際に、その処理＋ループ判定までが18命令なり28microOpsに収まるのであれば、その一連の処理は全部LSD内に収まる事になる。

ところがこれ、外部からみてもその効用がわかりにくい。というのは、そもそも分岐予測メカニズムが動いて先読みを行うからだ。動的な場合はまた別だが、静的な分岐予測では、こうしたループがあると「かならず分岐する」と予測して次の命令のデコードの指示を行う。したがって、この分岐予測が正しく予測できていれば、LSDがあろうとなかろうと切れ目無く命令をデコードし、処理できることになる。こうした小さいサイズであれば、最初に命令をフェッチしたタイミングでループ全体がL1キャッシュに収まっていると考えるべきで、そうなると差はL1キャッシュ以下全部が動くか、LSDから先が動くかだけでしかない。一応この場合でも消費電力の差が出る可能性はあるが、それを正しく測定できるほどの精度の測定環境は手元にない。

そこでちょっと図6の構成を捻って、図7の様な構成としてみた。ループ内部にさらに分岐があるというものだ。

ここで、条件分岐が処理AとBで均等に割り振られるような仕組みとすると、理論上は半分の確率で分岐判断ミスが発生する(動的分岐予測がこのあたりをどう判断するか、は興味ある部分だが)。ループのサイズが小さければ、L1に収まりきるからパイプラインフラッシュが発生してもレイテンシは最小限で済むが、それでもペナルティが無しという訳にはいかない。

さて、問題はこのケースでLSDがあるとどうなるか? だ。条件分岐からループ判定までのプログラムサイズがLSD内に収まれば、このケースではパイプラインフラッシュが発生しない可能性がある。ただしサイズが大きくなれば、当然LSDに収まらなくなるので、急速に性能が悪化することになる。

というわけで、これを試してみる事にした。プログラムはこちら(Util38.exe)、ソースはこちら(Util38.cpp)である。要するに図7で言うところの「何かの処理A」「何かの処理B」のサイズをどんどん増やしながら、ループを１回廻るのに必要なcycle数を計測するというものである。処理A/Bには"xor eax,eax"をひたすら並べただけである。最初はこれをnopにしていたのだが、Visual studio.net 2005のRelease Buildだとnop命令が最適化されてしまい、全然比較にならないのでxorに切り替えてみた。ちなみに最終的なプログラムサイズは、xorが１個の場合で11命令/28Bytes、2個の場合で13命令/32Bytes...となっており、Core MAのLSDならば4個まで、Nehalem MAのLSDなら(1命令＝1microOpsとして)9個までは有効で、そこから成績が悪化する「筈」だ。

結果はグラフ21である。「あんれぇ?」という気分になるのは、処理のサイズが小さいケースだ。特に1～3個における数字のひどさは、あきらかにここまで説明してきたLSDの動き方にそぐわない。その一方で、4～9個のケースは、3～4cycleでループが一周しており、平均5cycleを要するCore MAよりも高速である。ここでもう一つ面白いのは、4～9個でのNehalem MAのグラフが、HT有効の場合と無効の場合ではっきり分かれることだ。LSDも、HTが有効の場合と無効の場合で動き方が変わるように思える。

一応LSDに関しては、確かにそれらしい動きをしていることそのものはここで確認できる。ただ、非常に小さなループに関してはむしろオーバーヘッドとなっているあたり、「LSDが有効に動作するためにはある程度大きなループでないといけない」という制約があるか、あるいはLSDが効果を発揮するための何か命令の組み合わせのセオリーがありそうに思える。こう考えると、Util29の結果の悪さにも頷けるものがある。Util29のTest1のサイズは6命令でしかなく、成績が悪化しても不思議ではない。思うにDecode段では、Test1はおそらく1cycleで処理できているのだと思う。ところがその後、LSDに入ったところで最適化が崩されてしまい、結果として性能がむしろ落ちているのではないか? と感じられる。

正直なところ、LSDによる性能面でのメリットというのはいまいち判らない、というのがグラフ21の結果から言えることだろう。