次に実行ユニットであるが、Core Microarchitectureの5(ALU×3、Load×1、Store×1)から6(ALU×3、Load×1、Store×2)に増強されたことが明らかにされた(Photo13)。ALUそのものは依然3命令のままである事を考えると、サーバー向けアプリケーションなどで広大なデータ領域をハンドリングする場合はともかく、MobileやDesktop向けでこれが大きく性能に影響する理由はにわかに想像しにくい。勿論サーバー向けを考慮していない訳ではないだろうが、もう少し理由がありそうだ。

ここからは筆者の想像であるが、これによるメリットは、SMTの性能向上ではないかと思う。複数のThreadが同時にStoreを呼び出すようなケースで、Storeユニットがボトルネックになる事を嫌ったのではないかと考えられる。同じ事はLoadでも発生しえるのだが、こちらはそもそも帯域がStoreの倍ある(こちらのグラフ19と20を比較していただければ判りやすい筈だ)から、相対的にStoreがネックとなりやすい。勿論K8の様に、同じStoreユニットを2つ並べるほうが効果的だろうが、構成としては複雑になる。Store AddressとStore Dataを分離するだけで、それなりの効果が得られたのではないか、と想像される。ちなみにALUが増強されないのは、そもそもSMTの目的がALUの利用効率を上げることだから、ここでALUまで増強したらむしろ利用効率が下がりかねないわけで、こちらは手付かずなのだろう。

これに関係する話だが、Nehalemでは様々なBufferが増強されている。Reservation Stationは32→36とそれほど大きくは増えないが、トータルとしてのWindows sizeは128まで増えており、より命令発行効率を上げる事が可能になった、としている。もっともWindow sizeについては、SMTであることを考えると、ThreadあたりのWindow Sizeは事実上半分の64に減るとも言えるわけで、このあたりの損得勘定はちょっと微妙にも感じる。