今回のIDFの最大の目玉はMelom / Conroe / Woodcrestという来年後半投入のマルチコアCPUであるが、その話をする前に順序としてYonahの話を紹介したいと思う(Photo01)。

Photo01:既に公開済のYonahの詳細情報。ベースとなるのはここからである。

SmartCache

今回もまたYonahに関する詳細がいくつか公開された。まずはL2キャッシュに関する話である。Yonahが2MBのShared Cacheという話は既にレポートした通りであるが、これに関してもう少し詳細が出てきた。Yonahの場合、Shared L2キャッシュ構造を取るが、これをいかに二つのコアで分配するかと言う話である。基本的にL2キャッシュは完全なNon-blocking構造で、従って「コアが稼動する際に必要とするサイズを動的に確保する」というメカニズムとなっている。面白いのはこの配分が、ハードウェアベースで決定されることである(Photo02)。この構造が有利なのは、2つのコアが必ずしも同じだけのL2キャッシュを必要とするとは限らない事で、たとえば片方のCoreがIdle状態なら、L2キャッシュ全体が稼動中のコアに割り振られるし(Photo02)、両方のコアが動いていても稼働率に違いがある場合にはよりActiveに動く方に優先的にL2キャッシュが割り振られる事になる(Photo04)。

Photo02:CPUの稼働状態に応じてキャッシュ配分を決定するとしている。もっともこれはL2のInitial Allocationであって、実際はデータアクセスに応じて動的に割り当ては変わると見られる。	Photo03:右はSmithfield方式の分離L2キャッシュでのシチュエーション。この場合、片方のL2キャッシュは無駄に空いている事になる。

Photo04:「負荷が軽い」≠「L2キャッシュが空いている」ではないのは事実だが、だからといって「そのプログラムがどの程度のL2キャッシュを占有するか」はプロセス毎にしか管理できないから、CPUの知るところではない。実際にこの方式でインプリメントがなされた、ということはそれなりにこの方式でうまく行っている事が確認できたから、と考えるべきなのだろう。

勿論この方式で2つのコアが共に激しく動く場合には、結局各コアに割り振られるL2キャッシュは1MBづつという事になるが、こうしたケースを除けばむしろ効果的にL2キャッシュが利用できるという説明があった。面白いのはこのL2の割り当てサイズのGranularity(粒度とでもいうか。この場合は分割の最小単位)は特に決まっていないということで、実際にはL2キャッシュのラインサイズ(64Bytes)になると思うが、このラインサイズ単位で自由に割り当てを変えられる事になる模様だ。

Intel Digital Media Boost

Digital Media Boostと呼ばれる、命令セットに関する拡張はコチラで以前触れた通りだが、これに関する詳細が今回もう少し公開された。

まずSSE/SSE2 MicroOps Fusuionである。以前のレポートでも書いたとおり、従来のMicroOps Fusionはロード命令と演算命令を一緒に取り扱うというものだったが、SSE/SSE2のMicroOps Fusionはまたこれと異なる話であった。SSEやSSE2では128bit幅のXMMレジスタに対して操作を行うことになるが、従来のx86のパイプラインはこんな幅のデータを扱うことができないから、例えばメモリ内の値と加算する場合、2回に分けてロードと加算を行う形になっていたそうだ。従ってDothanでは、Photo05左側の様な形でMicroOpsが並ぶ事になる。しかし、この4つのMicroOpsは毎回同じ順で発行されることは決まっているので、これをPhoto05右側の様にしてしまえば、MicroOpsの大幅な節約になる。これがSSE/SSE2 MicroOps Fusionの動作であるという説明があった。

またIDIV(整数の除算)に関しては、Latencyを8cycle削減したことが示された(Photo06)。スループットは変わらないままの様だが、Latencyが削減できるということは早くOut of OrderのCompletionが完了する、つまり同時に発行できる命令を実質的に増やすことができるから、これは性能アップにつながると評価できる。

Photo05:ここから読み取れるのは、MicroOpsは64bit幅でロードを行うということだ。そもそもFSBやL2キャッシュはいずれも64bitのデータ幅なので、これはこれで整合性が取れているわけではあるが。	Photo06:16bit幅の除算のレイテンシが12cycles→4cyclesになったという事であり、そこにもう8bit加えると余分に8cycles消費することは変わらない。

あとの2つ、SSE3の搭載(Photo07)とFP Unitの高速化(Photo08)に関しては詳細な説明はなかったが、こちらは前の2つほど目を引くものではなかった。

Photo07:実はSSE3にはThread Syncronization関連のMonitor/MWaitという命令があるのだが、ここには含まれていない。なぜかという話は後述	Photo08:FCWレジスタをレジスタリネーミングの対象にしたこと、データプリフェッチを改良したこと、Write Output Bufferの数を増やした事の3つがFPU関連では挙げられている。実はこの程度の改良は世代の変わり目によくある話で(たとえばIDF Spring 2003でのPrescott技術セッションの資料を参照)、それほど珍しくはない。