RightMark Memory Analyzer 3.8(グラフ22～143)
cpu.rightmark.org
http://cpu.rightmark.org/products/rmma.shtml
それでは今回の記事のメインであるRMMAの分析に入りたい。
■ Decode(グラフ22～37)
まずはDecode段を見てみたい。まず判りやすいところでグラフ22がNOPであるが、A10-4660MではL2が有効な2MB付近まで、激しく変動しているのが判る。元々Bulldozerコアは、NOPに関しては4命令/cycleでデコードが出来ることは以前解析した通りである。構造が大きく変わっていない以上、これはTrinityでも同じだと仮定すると、この変動はもっぱらTurbo Coreによるものだと判断できる。ためしに2MB付近までの結果をまとめてみると、
平均：4.81Bytes/cycle
最小：4.35Bytes/cycle
最大：5.54Bytes/cycle
という結果になった。で、定格だと4Bytes/cycleと考えた場合、それぞれの動作周波数は
平均：2.3×(4.81÷4)＝2.77GHz
最小：2.3×(4.35÷4)＝2.50GHz
最大：2.3×(5.54÷4)＝3.19GHz
という計算になる。要するに、ちゃんとTurbo Coreは動作しており、ピークでは3.2GHz近くまで跳ね上がるが、平均すると2.8GHz程度までしか上がらないというのが今回試用した機材の特徴なようだ。そこで、この平均値の分を元々のデータからさっ引いたのが「A10-6400M(補正)」という細い水色の線となる。以下のグラフは、特に説明を行わない限り、この2.8GHzという平均値を用いてA10-4600Mの結果に補正を行ったものも加味しているので注意されたい。
ということで話を戻す。以前も説明したが、このDecode段では、
| 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): |
cmp eax, 0x00000000 |
| Prefixed CMP #2(8): |
cmp eax, 0x0000007f |
| Prefixed CMP #3(8): |
cmp eax, 0x00007fff |
| Prefixed CMP #4(8): |
cmp eax, 0x7fffffff |
という15種類の命令のデコード速度を測定するものである。これの結果がグラフ22～36になるわけだが、まとめてみてみると、
- A10-4600Mのピークのデコード速度はFX-4100と同じ。少なくとも今回試した範囲の命令では、デコーダ段そのものにデコード速度改善の兆候は見られない。
- 各コアの2命令/cycleという実行速度もやはり変わらない。
- L2からのデコード速度は、FX-4100を上回っている様に思われる。これは特に命令長の長いPrefixed CMPの結果(グラフ33～36)で顕著である。L1 Miss/L2 Hitとなる64KB～2MBの範囲において、FX-4100は3.7Byte/cycle程度、A8-3870Kでも4.25Bytes/cycle程度なのに、A10-4600Mは補正前で6Bytes/cycle程度、補正後でも5Bytes/cycle程度の帯域を確保できている。実際にグラフの暴れ方を見ると、この領域でも多少Turboの影響はあると思うが、実際にはL2アクセス待ちが発生するのでTurboの効きは悪く、実際には補正値よりももう少し高い、5.4Bytes/cycle程度の帯域が確保されている可能性がある。
といったあたりがこれらの結果から読み取れる。
Decodeの最後はPrefixed NOP Efficiency(グラフ37)だが、こちらを見ると補正後のA10-4600MとFX-4100のグラフがほぼ重なっており、これに関しては残念ながら改善が殆どなされていないと見て良さそうだ。
