Sandra 2016 SP3(Discrete GPU)

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

もう少しするとSandra 2017が出そうな感じだが、とりあえず今回は2016年11月にリリースされた2016 SP3を使った。このSP3からいろいろ変わっていて、例えばAESのEncryptionとDecryption、あるいはPCIe経由でのVideo Memory BandwidthのUp/Downはまとめて平均値を出すようになっている。

まずは純粋にCPU性能ということで、Dhrystone(グラフ1～2)とWhetstone(グラフ3～4)、それとProcessor Multi-Media(グラフ5～10)を見てみる。綺麗なほどに動作周波数の比がそのまま結果になって現れている形だ。

しいて言えばNative(AVX命令)よりも.NETやJavaなどを使った場合で差が出にくくなってはいるが、これはインタープリタの処理が入る以上、当然である。ちなみにNativeよりもJavaの方が高速という謎の結果が出ているが、これはSandraのスコアの出し方が良く分からない。とりあえずNativeと比較するのではなく、Java同士での性能差の比較をしてもらうのが正しい見方と考えて欲しい。

Encryption/Decryption(グラフ11)では余り差が出ないが、これはメモリ帯域がボトルネックになっているためと思われる。SHA Hasing(グラフ12)ではもう少し差が明確になっているが、こちらは処理がボトルネックになっているためだろう。

Financial Analysis(グラフ13～15)、Scientific Analysis(グラフ16～18)、Image Processing(グラフ19)も傾向は同じである。

Multi-Core Efficiency(グラフ20と21)では、特にL2にFitする程度の容量における帯域がKabyLakeの方がやや上(これは動作周波数そのまま)で、これより小さいサイズは通信のオーバーヘッドの方が大きく、大きなサイズはメモリ帯域がボトルネックになるから、結果は妥当な範囲である。

そのメモリ帯域であるが、Cache/Memory Bandwidth(グラフ22)で見ると、一応L3の範囲まではほぼ動作周波数に比例する形で帯域が増えており、これもセオリー通り。さらにStreamのInt/Floatと、グラフ22の64MB～1GBの範囲の平均値をまとめたもの(グラフ23)で見ると、さすがにここではほとんど差がない。

一応動作周波数が高いKabyLakeの方が、単位時間あたりでより多くのMemory Access要求を出せる分、若干性能が上がっているが、これは本当に若干であって、要するにメモリアクセスがボトルネックになるような処理に関してはあまり性能改善が期待できないという、これまた当然の結果となっている。

ではLatencyは? ということでグラフ24～26がData Cache/Memoryの、27～29がInstruction/Code Cache/MemoryのLatencyである。特にL3以上でKabyLakeのLatencyが増えて見えるのは、縦軸がcycle換算になっているためである。

定格4GHzのCore i7-6700Kと4.2GHzのCore i7-7700Kでは、あるLatencyの値(本来はnsとかμsecで表記するもの)に相当するcycle数が異なる。例えば10nsのLatencyの場合、4GHzだと1cycleが0.25ns相当だから40cycleになるが、4.2GHzだと1cycleが2.381ns程度になり、10nsだと42cycleと5%ほどcycle数が増える計算になる。

今回のグラフで言うと、4MBまでは問題なくL3 Cacheに収まるが、8MB以上になるとL3が溢れる(L3にはプログラムなども格納されているから、8MB分のデータ全部は収まらない)ためにメモリアクセスが発生する。

このメモリアクセスはCPUの動作周波数に無関係なので、こちらのアクセスが発生するとKabyLakeの方が多めのLatencyとして測定されると言うだけの話である。

話を戻すと、逆に4MBあたりまではSkylakeとKabyLakeの間に明確な差が無い(グラフ28が唯一の例外だが、ここの256KB/512KBでの数値の差は0.66cycle程度で、たまたま測定中に何か割り込みが入って遅くなったとかその程度の差に思える)事が確認できたことになる。

メモリアクセス繋がりで、TSX命令を利用したメモリトランザクションの結果がグラフ30であるが、ここでは当然動作周波数の差に近い性能差がある。逆にPCIe経由でのGPUのVideo Memory Access(グラフ31)は全く性能差が無い、という結果になっている。このあたりもセオリー通りだ。

ここまで見る限り、KabyLakeでは内部には手が入っていない様に思える。実は今回結果は示していないのだが、RMMAを使ってSkylakeとKabyLakeのデータを取って確認を行っている(RMMAの動作に必要なRTCore64.sysがWindows 10でロードできないので、わざわざ別のHDDにWindows 7の環境を構築してテストを行った)。

結果から言うと、メモリアクセスが絡む部分では当然違うLatency(cycle数)が出るが、それ以外では一切違わないという結果になっており、さすがにグラフをそのためにウン十枚増やすのも憚られたので割愛した。ただ内部的には(細かなバグの修正などを除くと)全く同じに近い構成なようで、Sandraの結果も納得である。