Sandra 2013 Engineer Edition(グラフ1～23)
SiSoftware
http://www.sisoftware.co.uk/
ではセオリー通りSandraから。最初はDhrystone(グラフ1)/WhetStone(グラフ2)である。Nativeと.NETだけでJavaが無いのは、相変わらずJRE(今回はJRE-7u21をインストールした)を入れても"Out of Memory"でベンチが終了するためである。
|
|
さて、Native命令で猛烈に性能差があるのは、単に2コアと4コアという以外にZacateはSSE3を使うがKabiniはAVXを使う、という拡張命令の違いも関係している。なので、同じ命令同士の比較では.NETの方が実情に近い。
理論上だとどの程度の性能差になるか? というと、仮にIPCが同じだとすればZacateが1.65GHz×2、Kabiniが1.5GHz×4だから、
Zacate:Kabini＝3.3:6≒1:1.82
ということで80%ほどの性能差になる計算である。実際にはオーバーヘッドやらメモリのボトルネックやらがあるから、もう少し少ない1:1.6位の性能差が「動作周波数×コア数」の分と考えればいい。で、.NETの結果を見ると実際にはもう少し性能差があるため、これがIPC Improvementの分と考えることができる。
このあたりがさらに顕著に出ているのがProcessor Multi-Media(グラフ3)である。Nativeのスコアで差が大きいのはAVX系の拡張命令を使っているためだが、それとは無関係な.NET系でも、特にIntとかFloatでは2倍を超える性能差があり、単にIPC以外にも改善点があり、それが効果的に作用していると考えられる。
|
次のCryptography(グラフ4)も拡張命令の効果であって、特にAESのEncryption/DecryptionはAES命令のサポートの有無がそのまま性能差に繋がっているわけだが、それとは関係ないSHA-256のHasingでも２倍以上の性能差になっていることが分かる。
|
ではMulti-Core Efficiencyは? というのがグラフ5である。Bandwith(縦棒)の方はコアの数(というか、コアの対の数)に比例するから、2コアのZacateと4コアのKabiniではKabiniの方が有利なのは当然だが、それでも倍で収まらないとつじつまが合わない。Kabiniが3倍以上広い帯域というのは別の理由も関係してくる。
|
またLatencyはコア数と直接関係ない(というか、コア数が多いほどむしろ増えることになる)から、ここでも半分近くにLatencyが削減されているのは両者の内部構造の違いに起因すると考えられる。
そこでDetail(グラフ6)を見ると、特に256KB～1MBにおける帯域が極端に違うことが分かる。要するにL2が共有キャッシュ構成なので、ここ経由でのデータ交換が極めて迅速というのが、非共有キャッシュ構成のZacateに大きな差をつけた理由と思われる。これはL2を使わない、例えば4×4KBの構成でもデータ交換にL2を使えるから、ここで帯域が稼げることになる。
|
ただしL2だけではない、というのは例えば4×1MB～8×4MBの範囲は明らかに2MBのL2だと溢れるのでMemory Accessになるわけだが、こうなると律速段階になるのはメモリアクセスで、コアの数が増えたからといって性能が上がったりはしない。
それにもかかわらずKabiniがZacateの1.5倍近い性能を出しているのはメモリコントローラの改善もなされていると考えるべきで、このあたりも性能に寄与しているのだろう。
ではそのメモリ周りは? ということでまずグラフ7はStreamの結果、それと次のグラフ8に出てくるMemory Bandwidthの64MB～1GBの範囲の平均値をまとめたものである。グラフ7をみると、Zacateが4GB/secあたりで頭打ちなのに対してZacateでは6GB/secまで引っ張ることが可能になっており、このあたりは明確にZacateに対する改善点として挙げられるだろう。
|
グラフ8はCache領域まで含めたBandwidth比較であるが、L1～L2はコアの数に比例して性能があがることを勘案しても、性能差が4倍というのは要するにコアあたりの帯域が倍になったと考えるべきだろう。このあたりは後でもう少し細かく調べてみることにする。
|
では一方のLatencyは? ということで、まずグラフ9が6つのシナリオにおけるOveeallである。このグラフはLatencyそのものなので、グラフが短いほど高速であることを表している。
|
面白いのは、データ領域に関してはSequential Accessは高速なのに、RandomになるとむしろLatencyが増え、逆にCode領域ではIn-Page Randomは高速なのにそれ以外はむしろLatencyが増えること。
これをもう少し細かく示したのがグラフ10～15になる。
まずDataについては、L1領域は3cycleでこれはどちらも同じ。続くL2では明らかにKabiniとZacateでLatencyの傾向が変わっているが、これは独立L2か共有L2かで管理方式が変わっていることと無縁ではないだろう。
|
|
|
L2のサイズそのものはKabiniの方が大きい関係で、先にZacateが溢れてMemory AccessとなるからLatencyが増えるが、その先はKabiniの方がむしろLatencyが大きい場合が多い。
一方Inst/Codeに関しては、ZacateはL1の範囲は全部2cycleなのにKabiniでは2～4cycleに変動している。キャッシュの構成そのものはどちらも32KBの2-way set associativeだから、ここでの差があるわけではない。なのでこれはFetch段の構成変更、つまりIC Loop Bufferの搭載が関係しているのかもしれない。
|
|
|
またL2に関しては、Sequentialでは同等だがRandomだとKabiniの方がLatencyが大きいのは、L2の構成変更に起因しているだろう。メモリアクセスになると、Dataの方と傾向が同じになる。
というわけで、L2/Memoryに関しては、Kabiniは帯域こそ増えたものの、その分Latencyも増える傾向になったというのがここまでの結論である。
ついでにGPUに関してもテストをしたのだが、実はZacateの方が全テストでエラーを起こしてデータが取れなかった。GPGPU TestはともかくVideo Testまでコケるのはちょっと解せないのだが、そうは言ってもデータが取れない以上仕方が無いので、一応Kabiniの方だけ結果を示しておく。
まずグラフ16がOpenCL/Compute Shaderを使ってのマンデンブロ図形描画。グラフ3と同じテストを今度はGPUを使って行ったケースだが、Float/DoubleのどちらもNativeの倍以上の性能になっている。
|
比較対象としては、以前にZacateの評価を行った時のものがあるが、Sandraのバージョンが違うので完全に横並びでの比較はできない。とはいえ、Zacate世代に比べると随分改善しているのがわかる。
グラフ17はCryptographyで、これはグラフ4と同じテスト。こちらは、やはりAES命令を持っているKabiniのNativeの方が圧倒的に高速だが、こうした専用命令を持っていないSHA-256のHasingではNativeを圧倒する性能を出していることがわかる。こちらもZacate世代の結果と比較すると大幅に改善している。
|
次はGP Bandwidth(グラフ18)。Kabini世代の場合、Internal Memory Accessの際にGPU内部のキャッシュと、仕組み上はCPU Core側のL2キャッシュも技術的には利用可能(ただ、利用する意味があるだけの性能改善が見込めるか、というのはまた別の問題)である。
|
ただこのテストの場合、GPUのキャッシュだけではしばしば容量がたりないので、RADEON系列の場合は必ずMemory Accessが発生する。このときにPhoto32に出てきたGraphics Memory Busを経由する形でのAccessとなる。
このGraphics Memory Busは256bit幅なので500MHzコアの場合、理論上は16GB/secの帯域を持つことになる。しかし、肝心のメモリがDDR3-1600の1chで最大12.8GB/secだから、こちらが頭打ちになる。
そう考えると、9GB/sec前後の帯域はかなり高速な部類に入ると考えてよい。逆にSystem to Device/Device to Systemの方は、一度FCHを通るため、バス幅も128bitに半減するし、Latencyも増えるので、4GB/sec程度というのはリーズナブルな数字に思える。
グラフ19と20はDirectX/OpenGLを使ってのVideo Shaderの性能確認だが、おおむねこんなものだろうという結果になっている。取りあえずDirectX/OpenGLのバージョン違いで結果がぶれたりしない(ドライバの出来が悪いと、ここで意味もなくぶれが発生する)のは安心した。
|
|
グラフ21～23は、同じくVideo Shaderを使ってのInternal/ExternalのMmeory I/Oである。GPGPU的な使い方よりややオーバーヘッドが増えるためか、若干性能は落ちているが、これは致し方ないところ。傾向としてはほぼグラフ19の傾向を再確認することになったといえる。
|
|
|
