さて、話を戻すとMemory AccessはともかくL1の帯域の低さが気になる部分だが、次がちょっと面白い。グラフ22~28はDecode Bandwidthの比較である。それぞれのテストの内容だが、久しぶりにまとめると、
NOP(1) | nop |
---|---|
SUB(2 | sub eax, eax |
XOR(2) | xor eax, eax |
TEST(2) | test eax, eax |
XOR/ADD(4) | xor eax, eax; add eax, eax |
CMP #1(2) | cmp eax, eax |
CMP #2(4) | cmp ax, 0x00 |
CMP #3(6) | cmp eax, 0x00000000 |
CMP #4(6) | cmp eax, 0x0000007f |
CMP #5(6) | cmp eax, 0x00007fff |
CMP #6(6) | cmp eax, 0x7fffffff |
Prefixed CMP #1(8) | <rep> <addrovr> cmp eax, 0x00000000 |
Prefixed CMP #2(8) | <rep> <addrovr> cmp eax, 0x0000007f |
Prefixed CMP #3(8) | <rep> <addrovr> cmp eax, 0x00007fff |
Prefixed CMP #4(8) | <rep> <addrovr> cmp eax, 0x7fffffff |
といった命令を延々と実行させたときに、どの位のスループットで実行できるかを測定し、そこから逆説的にデコーダの処理能力を見ようというものだ。()の中の数字は命令の合計バイト数である。以上の数字を念頭にグラフを見てみよう。
まずグラフ22のNOPについては、Nanoが1命令/cycleに留まっているのが判る。もっともグラフ23のSUBの結果を見ると、Atom/Nano共に1命令/cycleに留まり、Zacateはきっちり2命令/cycleとなっている。「んじゃNanoは1命令/cycleの能力しかないのか?」というと、グラフ24のXORではまたもや2命令/cycleであり、グラフ25のTESTではZacate/Atom/Nanoの全てが最大2命令/cycleを実現できている。XOR/ADDでは、再びZacate/Nanoが2命令/cycle、Atomが1命令/cycleといった具合になっており、
Zacate : 命令に関わらず概ね2命令/cycle
Atom/Nano : 命令によって1~2命令/cycle
という形の実装になっているようだ。AtomについてはMicroOps Fusionの実装の関係もありそうだが、Atom/Nanoに共通して実装のメリハリをつけている感じがある。例えばNanoの場合、NOPが使われるケースというのはタイミング調整がメインだけに、無理に高速化の必要もなく、1命令/cycleで済ませる一方で、XORなどはレジスタ初期化に多用されるから、こちらはちゃんと高速化をするといった具合だ。こうしたものに比べると、Zacateのデコーダはかなり優等生に見える。ではZacateにメリハリはないのか? というとそんな事はない、というのは続くグラフ27・28で明らかである。先ほど、L1 D-Cacheの帯域は8Bytes/cycle程度であるという事をグラフ15~17で示したが、CMP #6の場合は6Bytes/命令、Prefixed CMP #4の場合は8Bytes/命令なので、これを2命令/Cycleでデコードするためにはそれぞれ12Bytes/cycle・16Bytes/cycleの帯域が必要になる。で、グラフ27・28で明らかなようにZacateのL1 I-Cacheは少なくとも16Bytes/cycleの帯域を持っていることは明白である。前にPhoto03のスライドに"Fetch up to 32-bytes/cycle"とあったが、少なくとも16Bytes/cycleまでは間違いなくいけることを確認した形となる。つまり、ZacateにおいてはL1 I-CacheとL1 D-Cacheの帯域が異なる、というこれまであまり類のない実装になっていることがここから見て取れる。
デコード周りでもう一つ、グラフ29はPrefixed NOP Decode Efficiencyである。NOPそのものは勿論1Bytes/cycleだが、NOP命令の前にPrefixを無駄につけることで命令長を増して行った場合にデコーダはどれだけ効率よく処理できるか、を測定するものだ。結果を見ると、0、つまりPrefixなしの場合はグラフ22のL1の範囲とほぼ同等のスコアであるが、1、つまりPrefixがつくとマイクロコードでの処理になるためか、Zacateで0.33Bytes/cycle、Atom/Nanoでは0.08Bytes/cycleまで落ちる。つまりZacateではマイクロコードを使うと3cycle必要で、Atom/Nanoだと12.5cycleほど必要になるという計算だ。先のPhoto12でもマイクロコードを利用すると2cycle余分に要する事になっているので、これは妥当な結果だ。問題はその先である。例えばPrefixが14ポイント、つまり全体で15BytesになるNOP命令の場合、Zacateで2.5Bytes/cycleで処理できるということは、概ね6cycle程度でマイクロコードが処理完了を意味している。これがAtomだと0.42Bytes/cycleだから36cycle弱、Nanoでも0.56Bytes/cycleだから27cycle弱を要している計算だ。このマイクロコード処理の高速さ、もZacateの大きな特徴ではないかと思える。