Sandra 2016 SP3(グラフ1～26)
SiSoftware
http://www.sisoftware.co.uk/
さて、それではここからテストの結果を紹介しよう。IPCを無視してコアの数と動作周波数だけ比較すると、Core i7-6950X : Core i7-7700K : RYZEN 7 1800Xは
- 3×10 : 4.2×4 ：3.6×8＝30:16.8:28.8≒1.79:1:1.71(定格動作)
- 3.5×10 : 4.5×4 ：4×8＝35:18:32≒1.94:1:1.78(定格動作)
といった比率になるので、これに近い結果が出ればIPCはKabylake相当という計算になる。ということで、まずはDhrystone(グラフ1)とWhetstone(グラフ2)を見てみると、確かにCore i7-7700Kを上回る性能ではあるが、Core i7-6950Xにはちょっと遠いという結果が出ている。
ラフに言って、Core i7-6950X : Core i7-7700K : RYZEN 7 1800Xが2:1:1.5、というあたりに収束している。もっともこれはテスト項目によって傾向が違っており、例えばWhetstoneのSingle .NETだとRYZEN 7 1800XがCore i7-7700Kのダブルスコアに近かったりするから一概には言いにくいのだが、IPCは改善しているが、まだKabylakeには及ばないと言える。
次がProcessor Multimedia(グラフ3とグラフ44)だが、こちらは特に性能の出やすいInteger Native x32やSingle Nativeでは、Core i7-7700KとRYZEN 7 1800Xがほぼ似たようなスコアになっている。
こうなる理由は簡単で、メモリ帯域がボトルネックになるからだ。逆に演算性能がボトルネックになるような、IntegerのLong JavaやQuad .NET、あるいはFloatのSingle Java/Double Javaなどでは、Core i7-6950XとRYZEN 7 1800Xがいい勝負をしていいる。
この「メモリ帯域が足を引っ張る」という現象は、次のCryptography(グラフ5とグラフ6)の中のAES Encryption/Decryptionでも顕著である。AES命令を利用するとEncryption/Decryptionの処理そのものの負荷は低いから、メモリ帯域の差がモロに出ると言う訳だ。面白いのHasing(グラフ6)で、RYZEN 7 1800XはSHA1とSHA2-256がほぼ同じ性能で、SHA2-512になるとガクンと性能がさがる。これは内部のMemory Pathの問題に見える。
案外に検討しているのがFinancial Analysis(グラフ7～9)で、Black-Scholes(グラフ7)ではCore i7-6950Xにはやや及ばないが、Core i7-7700Kの倍近い性能であるし、Binominal(グラフ8)のSingle FloatだとCore i7-6950Xすら派手にぶっちぎっている。Monte Carlo(グラフ9)は妥当な数字であるが、これもCore i7-7700K比だと同等近いIPCが実現できている。
Scientific Analysis(グラフ10～12)で言うと、GEMM(グラフ10)がいまいちかんばしくないのは最適化の問題もある気がする。「SGEMMとDGEMMで性能差がない」というのがその理由で、普通に最適化が済んでいれば、こんな結果になることはちょっと考えにくいので、これはSandra側の問題ではないかと思う。
次のFFT(グラフ11)は、明確にメモリ帯域がボトルネック、N-Body Simulation(グラフ12)はこれまでも良く出てきた数値で、純粋にCPU性能という意味では、この結果は典型的なものだ。
処理性能の最後はImage Processing(グラフ13)だが、Convolution～Sobelまではメモリ帯域がネックになり、その先は処理性能差という感じの結果になっている。
さて、次はInter-Core Efficiency(グラフ14とグラフ15)だが、相変わらずAMDのコアはLatency多めという伝統は変わらない(グラフ14)。ただ帯域はCore i7-7700Kを上回るものになっている。
詳細(グラフ15)を見ると、IntelのコアはL1で収まるサイズ(4×4KB)にピークが来ているのに対し、RYZEN 7 1800Xは4×64KBがピークになっている点が面白い。これはL2/L3の排他制御に絡む部分の影響だと思われる。
小サイズの交換だと排他制御のボトルネックが大きめに出てしまい性能が上がらない。またL3まで使う必要があるほどのサイズだと、今度はL2との帯域がボトルネックになる。つまり、排他制御の頻度を最小にしながら、一番効率が良いのが256KBというあたりではないかと推測できる。このあたり、Intelとは明確に最適化の方法が変わってくることを示す良い結果ではないだろうか。
絶対的なメモリ帯域(グラフ16とグラフ17)であるが、これはあまりかんばしくない。この理由は分かりやすい。以前にこちらでも紹介したが、ZENコアはLoad/Storeユニットが2つしか搭載されておらず、4つ搭載されるSkylake/Kabylakeに見劣りする。特にL1～L2における性能が芳しくないのはこのためだ。
ただ、Load/Storeがフルに動くケースが一般のプログラムでどれだけあるか? というとかなり怪しい。それでは、Skylake/Kabylakeはなぜ4つ搭載したかというと、512bit幅のAVX512命令を処理するためにはLoad/Storeユニットが4つないと間に合わないからだ。
これに関してはCTOのMike Papermaster氏に直接聞いたのだが2つの答えが返ってきた。1つ目は「AVX512命令を実装するのはコストが高すぎる(Load/Storeユニットだけでなく、L2以降の帯域も全部増やさないと効果的な性能を出すのが難しく、これはダイエリアだけでなく消費電力などへのペナルティが大きい)」からとのことで、最初から実装するつもりがないということだ。そうであれば、Load/Storeは256bit/cycle×2があれば十分である。
ちなみにもう1つは「数値演算を主体にするなら、AVXを強化しなくてもGPUを使えばOKだから」とのことだ。このあたりは強力なGPUコアを持つAMDと、持たないIntelのアプローチの違いというべきか。Memory Bandwidth(グラフ17)もほぼメモリ帯域をそのまま反映する結果になった。
そんなわけで、帯域には明確な差が出たRYZENだが、Latencyは? ということでグラフ18～23を見てみると非常に面白い結果になった。まずDataでは、Sequenctial(グラフ18)の場合、L3でもアクセスは7cycleと非常に少ない。
ただMemory Accessになるとある程度大きくなる。これがIn-Page Random(グラフ19)だと全体的に数値が大きめになり、特にMemory Accessが非常に悪くなる。Full Random(グラフ20)だとCore i7-7700Kとどっこいどっこい(メモリアクセスを除く)という結果になる。
Codeは? というとSequential(グラフ21)でもLatencyは高めで、L2/L3だと20cycleというのはちょっと驚きである。ただIn-page Random(グラフ22)だとL1こそ高めだがその後は妥当だし、Full-Random(グラフ23)だとL3まではほかと区別が付かない。
なんでこんな面白い結果になったのか。まずData Cacheに関しては、Prefetchユニットが非常に効果的に動くが、In-Page RandomではこのPrefetchユニットがうまく働かない(Sandraの発行するアクセスパターンをうまく推定できない)ようだ。これがFull-Randomになると、もうPrefetchが関係なくなるので、素の性能が出るというあたりが考えられる。
またInstruction Cacheに関しては、Sequential Accessは想定していない様に思える。というのは、こうしたケースでは基本的にOp CacheからのFetchになるから、愚直にL1をシーケンシャルアクセスする必要がないためだ(もちろん一番最初だけは愚直にアクセスする必要があるが、その最初の一回だけだからだ)。メモリアクセス時のLatencyが全体的に大きめなのは、Zenコアの特性というか、AMDの伝統的な感じはちょっとある。
グラフ24とグラフ25は、Memory Transactionのテストだが、TSX命令を持たないRYZEN 7 1800Xはソフトウェアでこれを行うので、スループットが一桁低いのは致し方ないところだろう。最後がPCI Express経由のスループット(グラフ26)であるが、Kaveri世代と比較すると大分改善したとはいえ、まだちょっとだけIntelのCPUには及ばない感じだ。
