承前

この連載、ほぼ4年近くに渡って延々とハードウェアの下回りばっかりやってて、いい加減飽きてきた事もあり、「次はソフトウェア」と決めていた。で、そのための仕込みも順調に進んでいる(というか、概ね準備も出来た)のだが、それとは無関係に最近盛り上がったのがコチラの記事。読者の方からの反応もよく、あちこちで色々言及いただき、それに対して筆者のblogでお返事(1、2、3)させていただいたりしたのだが、これを見て担当編集者から「勿体無いのでこちらに送ってください。次からは本当に記事にするので(笑)」というメールが。いや別に勿体無いとは思わないんだが(笑)。

焦点となっているのは「Core MicroarchitectureのIPCって一体幾つよ?」という話で、これだけをネタに特集をやるのはいくらなんでもちょっと難しいし、レビューという感じでもない。「んじゃセカンド・オピニオンでやるか」という事で、「息抜き」にこのあたりをもう少し考察してみたいと思う。

で、連載しょっぱなからアレであるが、しばらく実験には入りません。これは純粋に筆者の都合なのだが、9月25日の週はIDF Fall 2006、10月9日の週はMPF Fall 2006の取材で渡米してしまう関係で、おちついてベンチマークをやってる暇がない。かつてIDFの取材の時、現地(つまりアメリカのホテルだ)までモニター以外の全ての機材を持参し、Fry'sかどっかでモニター買ってきて、取材をしながら夜にベンチマークを廻すという曲芸をみせたライターが居たが(だれとは言わないが、時期的にはこの記事の時だ)、そんなしんどいことはとてもやってられない。ということで、実験に入るのは10月後半以降の予定。しばらくは座学が続くことになるが、ご了承いただきたい。

問題点の整理

ということで、まずは問題になっている事をまとめてみよう。最大のテーマは筆者が特集の考察で述べた「実質的にはx86命令で3命令/Cycleを狙ったアーキテクチャである」が妥当か否か、というあたりであろう。で、具体的にはここで触れた、Core MicroArchitectureのフェッチ/デコード・スケジュール・実行という各ブロックのどれがボトルネックになって、3命令/Cycleになっているか、が焦点である。特に突っ込みが多く入ったのは、Core MicroArchitectureではx86命令換算で4命令/Cycleのデコード能力を持っている筈で、例えばグラフ3の性能がピークで3命令/Cycleそこそこなのは、実行ユニット側がボトルネックになってしまっているためではないか? というあたりだ。実のところ、この指摘は間違ってはいない。Photo01を見ていただくと判るとおり実行段は5つのユニットから構成されるが、このうち汎用の実行ユニット(ALU)は3つしか用意されていない。従ってLoad/Storeを伴わない命令(例えばNOPなんか典型例だろう)の場合、どんなに頑張っても1サイクルあたり3命令までしか実行できない。従って実行ユニットがボトルネックになっている事そのものは間違いない。では、ボトルネックは実行ユニット「だけか?」というのが、次なる問題である。簡単なALU命令では判らないが、複雑な命令になってくるとデコーダ部やスケジューラにも当然何らかの制約が出てくると思われる。実際、こちらでもいくつか触れている通り、デコード段やスケジューラにも割と制約がいくつかある。こうしたものがどの程度ボトルネックになっているか、は特集のテストだけでは不可能である。まずは、このあたりをじっくりと見てゆくのが最初のステップとなるだろう。