またもや前編から随分時間が空いてしまったが、AMDの最新APU「Kaveri」検証の後編をお届けしたいと思う。前編を出してからドライバがUpdateされ、Battlefield 4がMantle対応になったりした訳だが、今回はまだMantle対応前の状態でデータを取ったので、データとしてはやや古くなっていることそのものは御了承いただきたい。

■前回の記事はこちら
【特集】「Kaveri」徹底検証!! - 「A10-7850K」で探る新世代APUの実力(前編)

ちなみにテストの概要だが、Richland/Kaveriは前編のデータそのままで、環境も当然同じである。ただし今回はCore i5-4670Kを追加しての比較となっている。テスト環境は表1の通り。

■今回のテスト環境
APU A10-7850K A10-6800K A10-6800K
M/B ASUSTeK A88XM-A ASUSTek Z87-PRO V Edition
BIOS BIOS 1003 BIOS 1007
Driver AMD 13.30 RC2 Driver Intel Inf Driver 9.5.14.1724
グラフィックス　　　 内蔵
Memory XMP-1866 CL10 16GB (Corsair VENGEANCE CMZ16GX3M2A1866C10 8GB×2) ※DDR3-1600 CL10動作
Storage Intel SSD520 128GB(System) + HGST HDP725050GLA360 500GB(Data)
OS Windows 7 Ultimate 64bit 日本語版+SP1

グラフにおける表記は

  • Richland : A10-6800K
  • Kaveri : A10-7850K
  • Haswell : Core i5-4670K

となっている。

Sandra 2014その1(グラフ1～20)

SiSoftware
http://www.sisoftware.co.uk/

まずは絶対性能ということでグラフ1がDhrystone、グラフ2と3がWhetstoneのものである。動作周波数では

■動作周波数
周波数　　 定格 最大
A10-6800K 4.1GHz 4.4GHz
A10-7850K 3.7GHz 4.0GHz
Core i5-4670K 3.4GHz 3.8GHz

ということで、Dhrystone/Whetstone実行中はどのCPUもほぼ最大動作周波数に近いところで動いているのではないかと思うが、結果はというとKaveriの値はHaswellの半分強といったところ。

動作周波数の差を考えると、実質Haswellの半分としてもいいかもしれない。もっともこれは納得のいく結果だ。というのはHaswellではAVX2命令を利用しているのに対し、Richland/KaveriではSSE4命令どまりだからだ。このあたりが露骨に反映されたと考えるべきである。

これはJavaとか.NETでは、HaswellとKaveriの差がグンと縮まっていることからも推察できる。まだ絶対性能ではHaswellに届かないものの、Richland vs Haswellではダブルスコアに近かったのが、2割落ち程度まで接近してきているのは大きな改善として良いと思う。

一方FPUは? というと、Richlandと比較した場合性能差は10%以内で、これは動作周波数の差がそのまま表われたという気がする。つまりRichlandの世代からこれに関する性能改善はほとんどなされていない訳だが、これは仕方ない気もする。このあたりはBulldozer世代から引き継ぐ欠点というか弱点と割り切るべきなのだろう。

次にグラフ4～6がProcessor-Multi-Mediaである。こちらもNativeに関しては、特にIntegerではHaswellがAVX2のx32演算なのに対しRichland/KaveriはSSE4のx16演算どまりなので、致し方ないところか。

逆に言えば、これを勘案するとRichlandとHaswellは同等、Kaveriはやや低いという面白い結果になっている。またFloat/Doubleに関して、特にNattiveでは3倍近い性能差になっているのは、単にFPUの構成だけでなく、もうFPUのThroughputそのものに対する最適化の違い、と考えても良さそうだ。

当然ながら、こうした結果はScientific Analysis(グラフ7～9)でもモロに効いて来る。性能差はテストによって変わってくるが、Richland/Kaveriと比較した場合Haswellの性能は2～3倍という大差であって、これはグラフ4～6の結果を見る限り当然という気はする。

Cyptographyなどは後にして、次にProcessor Multi-Core Efficiency(グラフ10とグラフ11)。グラフ10は縦棒(左軸)がBandwidth、折れ線(右軸)がLatencyは同じである。面白いのは、Bandwidthそのものは随分差が縮まっていること。Latencyは大差があるが、これはHaswellのみL3を搭載していることが関係していると思われる。

グラフ11を見ると、一番値の少ない1×64Bytesでは、3つのCPUの差はそれほど大きくない。面白いのは、そこから64KBくらいまでの範囲は、HaswellよりもRichlandの方が高速な事だ。L2の領域になると再びHaswellが優位に立ち、特に2MB(8×256KB)以上になるとL3で通信できるHaswellが圧倒的な優位にたつが、逆に言えばL2の範囲で言えばKaveriとHaswellがいい勝負、ということになる。これはMulti-Thread動作のアプリケーション性能を考えたときに興味深い。

ところでグラフ11でも8MB以上ではやはりHaswellの帯域がRichland/Kaveriを圧倒している。ということで、グラフ12とグラフ13がMemory Bandwidthの結果である。グラフ12がOverallで、64MB-1GB Avg.は次のグラフ13の結果をまとめたものだが、Kaveriでは確実にLoad/Store性能が上がってはいるものの、Haswellと比較するとまだ大差がある。ただRichlandだとHaswellが倍以上の性能を出していたのに、今度はおおむね50%程度の差しか無いとも言える訳で、まだ差はあるとは言え確実に詰めてきた感がある。

グラフ13はRead Accessにおける帯域の変化を見たものだが、L1範囲では大きな差があるのがL2範囲になると随分差が縮まっている事が分かる。L1に関しては単にキャッシュの速度というだけでなくLoad/Storeユニットの性能も関係していると思うが、L2の範囲だとそれほど大きな差がない。

相対的にKaveri/RichlandはL2が高速(というか、HaswellのL2はそれほど速くない)という言い方もできるかもしれない。とはいえ、1GBの範囲まで全てのエリアでHaswellがKaveriより明確に高速なのも事実で、このあたりは厳然たる性能差があることも確認できた。

続いてはLatency。前回は省いたが今回は見てみたいと思う。グラフ14～16がまずGlobal Data Memoryのものである。まずRandom2つを見てみると、L2領域でRichland→Kaveriで1cycleのLatency削減が実現されている。

とはいえ、20cycleが19cycleだから、13cycleほどのHaswellよりは遅いのだが、Haswellは逆にL3領域が42～43cycleほどになり、部分的にRichland/Kaveriと逆転しているのは面白い。またL2 MissでメモリアクセスになるとKaveriがRichlandよりもLatencyが大きくなっているのは、帯域を上げた代償なのだろうか?

面白いのはグラフ16でこれはSequentialだが、L1/L2領域でKaveriとHaswellのLatencyが同じほどになっている(L1/L2容量が違うからグラフの立ち上がり位置は異なるが)。L2 MissでメモリアクセスになるとKaveriが一番Latencyが大きいのは変わらずである。

次は命令キャッシュ側のアクセス(グラフ17～19)。Haswellが2KBの時に1cycleという驚異的な数字なのは、これはL1ではなくL0相当となる1.5K μOp分のDecoded μOp Cacheにヒットしているためと考えられる。

面白いのはここからL2/L3の領域でHaswellの方がLatencyが多いこと。L1はともかくL2に関してはRichland/Kaveriとも原則UnifiedでCPUパイプラインから外れた場所にあるわけだが、L2からの読み込みLatencyが大幅に削減されているというのはちょっと面白い。逆にHaswellではむしろLatencyが増えているあたりは、L1/L2間のI/Fの構成の違いが明確に思える。

最後にMemory Transaction周りの確認(グラフ20)を。これに関してはTransaction Memoryの機構を内蔵するHaswellが有利というのはテストする前から分かっていたが、一応確認ということで。

本来は6種類のテストでそれぞれProbabiltyに応じたトランザクションのスループットを測定するのだが、結果はいずれもほぼ平坦(Probabiltyに関わらず一定)だったので、それぞれのテスト結果の平均をまとめている。

結果はHaswellが有利なのは当然だが、これはTransaction Memoryうんぬんの前に、動作するLoad/Store Unitの能力そのものの比較といった結果になっている気がする。実際、例えばRecord Update Onlyの結果を見ると、HLEを使った場合とS/WのみでClassicのケースがほぼ同じ結果というあたりからもこれは確認できる。