Sandra Platinum Version 24.22(グラフ75～100)
SiSoftware
http://www.sisoftware.co.uk/
さて、ここからCache/Memoryの方向に。まずはMemory Bandwidth(グラフ75と76)。"256M-4G"は、グラフ77と78の256MB～4GBの結果を平均したものである。先のRMMTではその実利がきちんと判断できなかったメモリ帯域だが、きちんと全スレッドを利用するとThreadRipperでは最大で60GB/secを超える帯域が確保されているのが分かる。
|
|
DDR4-2666×4chで理論帯域は85.3GB/sec(これはThreadRipperもCore i9-7900Xも同じだ)に対しての63GB/secは、かなり効率が良い(74%近く)。面白いのはUMAよりもNUMAの性能が高いことであろうか。Streamでこれ、というのは(まぁSandraのことだから相当いじったStreamであろうとは思うが)、どういう実装になっているのか興味深いところだ。また1T(グラフ76)でもUMAよりNUMAの方が高速で、しかもThreadRipperがCore i9-7900Xに近い帯域を出しているのは興味深い。
グラフ77と78はL1 Cacheからの帯域一覧である。MT(グラフ77)当然L1～L3に関してはUMAもNUMAもないので、グラフはきれいに重なっている。余談だが、ThreadRipperはきれいにRyzen R7 1800Xと同じ傾向だが、Core i9-7900XはL1よりもL2を大幅に強化しており、この結果L1よりも帯域が大きいという訳のわからない結果になっている。これはCore i7-7700Kと比較すると顕著である。
|
もっとも1T(グラフ78)で比較するとまた傾向は異なっており、Core i7-7700KとCore i9-7900XはL2～L3回りが多少ちがう程度で、これはキャッシュ容量が異なっているから仕方ないところだろう。
|
不思議なのがRyzen R7 1800XとThreadRipperで、本来なら完全に重なっていても不思議ではないのに、実際にはL2領域でThreadRipperに若干の上乗せがあることだ。Revisionの違いでこのあたりが高速化されたという訳でもないと思うのだが。
グラフ79～90がCache/Memory Latencyである。こちらは全てMTで実施しているが、結果はCycleとnsの両方を示している。L1～L3はCycleを、メモリアクセスはnsを使ってみることにする。
まずGlobal Data(グラフ79～84)、Sequential(グラフ79と80)だと特にNUMAで大幅にLatencyが減っているのが見て取れる。7ns超が5ns未満だから、これはかなり大きなLatency削減である。
|
|
この傾向はIn-Page Random(グラフ81と82)やFull Random(グラフ83と84)でも同じであり、NUMA構成にするとLatencyが大幅に減るというAMDの説明が裏付けられた形になる。
|
|
|
|
ではInstruction/Code(グラフ85～90)は?というと、こちらもSequential(グラフ85と86)、In-Page Random(グラフ87と88)、Full Random(グラフ89と90)の全てのケースでLatencyが大幅に減っており、実際Core i9-7900Xとさして変わらないレベルまで改善しているのは非常に興味深い。というか、Ryzen 7 1800XよりもLatencyが下がっているのがちょっと不思議ではある。
|
|
|
|
|
|
さて、一番結果が興味深いのが次のMulti-Core Efficiency(グラフ91～98)である。まずグラフ91と92がBest ConditionにおけるOverallとDetail、93と94がWorst ConditionにおけるOverallとDetailである。
|
|
|
|
グラフ91と93、あるいは92と94を比較していただくと分かるが、Intel系に比べてAMD系はBestとWorstの落差が大きすぎる。グラフ91と93でInter-Core Latencyそのものはどちらもそう変わらないのだが、Inter-Core Bandwidthを比較してみると
| Integer | Best (GB/s) |
Worst (GB/s) |
性能比 (倍) |
|---|---|---|---|
| i7-7700K | 37.55 | 16.00 | 2.3 |
| i9-9700X | 79.48 | 17.46 | 4.6 |
| R7 1800X | 46.26 | 5.14 | 9.0 |
| TR 1920X | 87.79 | 7.84 | 11.2 |
| TR 1920N | 90.15 | 7.86 | 11.5 |
| TR 1950X | 94.36 | 8.63 | 10.9 |
| TR 1950N | 97.19 | 8.22 | 11.8 |
ということで、極端に差が大きい。ちなみにUMA/NUMAはあんまり関係ない感じである。
面白いのは次のLatency分布である。グラフ95と96がBest、97と98がWorstで、先のグラフ92と94からも判るとおりBestもWorstもLatencyそのものは大きな違いが無い。
|
|
|
|
ちなみにグラフ95と97は実際の頻度だが、そもそも母数がちがう(Core i7-7700Kは8×7÷2で28pair、Ryzen 7 1800Xは16×15÷2で120pair、Core i9-7900Xは20×19÷2で190pair、ThreadRipper 1920Xは24×23÷2＝276pair、ThreadRipper 1950Xは32×31÷2で496pair。ただしSandra 2017が256pairを超えると妙な結果を出すので、結果は256pairで足切りしている)ので数だけ比較しても仕方が無い。そこでグラフ96と98は全体に対する比率を示している。この比率を使ってもう少し分析してみたい。ちなみに同じ事はCore Xのレビューでもやっている。
Core i7-7700Kは14.3%が16n後、85.7%が40～48ns(中央値42ns)に分布している。つまり同じコア内のThread間通信が16ns、Ring Bus経由での隣のコアのアクセスが42nsということだ。
Core i9-7900Xになると、5.3%が16ns、94.7%が66ns～82nsに集中している。中央値は74ns程度で、やはりCore-XのMeshは相応にコストが掛かるということだ。とはいえ、この数字は10コアとしては十分小さい気がする。MCCとかHCCのコアもこのLatencyでアクセスできたらたいしたものだが。
さてRyzen 7 1800Xは? というと、16nsで6.7%、42ns～44ns(中央値は42ns)で40%、134ns～140ns(中央値は137ns)が53.3%となっている。これは、同じコア内のThread間が16ns、同じCCX内のコア間が42ns、同じダイの異なるCCX間が137nsのLatencyということになる。平均すれば90ns程度というところか。それなりにCCX間の通信にはコストが掛かることが再確認できた。
問題のThreadRipper、ThreadRipper 1920XのUMAの場合、14ns～16ns(中央値は14ns)で4.7%、42nsで16.4%、158ns～160ns(中央値は160ns)で14%、208ns～210ns(中央値208ns)で10.6%、224ns～240ns(中央値227ns)が54.3%となっている。
全体的にRyzen 7 1800XよりもLatencyが少ないのは、ThreadRipperには上位5%の性能の良いダイが利用されているためと思われる。ただダイ間の通信には相応に時間が掛かっている。10.6%の208nsと54.3%の227nsがこれで、ラフに言えば220ns程度の時間が必要となる。ダイ間にしては結構高速、というのが率直な感想ではあるが。
ではNUMAになるとということでThreadRipper 1920XのNUMAだと14ns～16ns(中央値は16ns)で3.5%、40ns～44ns(中央値は42ns)で16.4%、140ns～160ns(中央値は154ns)で14.1%、174ns～176ns(中央値176ns)で10.5%、228ns～258ns(中央値は236ns)が54.2%となっている。同様にまとめると
ThreadRipper 1950X UMA:14～16ns(中央値16ns)が3.5%、40～44ns(中央値42ns)が17.1%、156ns～160ns(中央値158ns)が7.9%、170ns～176ns(中央値172ns)が11%、202ns～204ns(中央値202ns)が4.7%、226ns～248ns(中央値243ns)が55.9%
ThreadRipper 1950X NUMA:14～16ns(中央値14ns)が3.5%、42～44ns(中央値42ns)が17.1%、146ns～160ns(中央値156ns)が4.7%、176ns～178ns(中央値176ns)が18.8%、234ns～254ns(中央値236ns)が56%
となっている。表2にこの結果をまとめたが、UMAかNUMAかの違いは、同一ダイ内でのCCXをまたいだ状態に影響があるようだ。ちょっとPhoto03に戻ると、UMAの場合はあるCCXからメモリアクセスする場合、一旦Scalable Data Fabric経由で、自分のUMC(Unified Memory Controller)にアクセスするか、もしくはxGMI PCS/E12G PHY経由で隣のダイのUMCにアクセスすることになる。
| i7-7700K | i9-9700X | R7 1800X | TR 1920X | TR 1920N | TR 1950X | TR 1950N | |
|---|---|---|---|---|---|---|---|
| 同一コア内 | 16ns | 16ns | 16ns | 14ns | 16ns | 16ns | 14ns |
| 異なるコア(同一CCX内) | 42ns | 74ns | 42ns | 42ns | 42ns | 42ns | 42ns |
| 異なるコア(同一ダイ、異なるCCX) | 137ns | 160ns | 176ns | 163ns | 172ns | ||
| 異なるダイ | 224ns | 236ns | 236ns | 236ns |
ところがNUMAの場合はダイをまたいでのUMCへのアクセスはできなくなるので、その分Scalable Data Fabric(というか、xGMI PCS/E12G PHY)のアクセス頻度が減って、コア間通信のLatencyが減ると思ったのだが、逆にLatencyが増える結果になっている。コア間のLatencyはほとんど変わっていないあたりも不思議である。なんと言うか、UMA/NUMAの切り替えは単にメモリアクセスの制限だけではなく、何かもうひとひねりありそうな感じがするのだが、今回はその正体ははっきりつかむことは出来なかった。
最後に2つ。まずグラフ99はMemory Transaction Throughputで、これはTSX命令を実装しているIntel系が有利なのはわかり切っているのだが、面白いのはRyzen 7 1800Xと比べてもThreadRipperが半分程におちこんでおり、しかもUMA/NUMAで差が無いことだ。これはちょっと不思議な結果である。
|
不思議といえばもう1つがVideo Memory Throughput(グラフ100)。これは要するにPCI Expressの転送帯域の確認のために実施しているのだが、なぜかCore i9-7900XとRyzen 7 1800XはDirectX 10で動作しなかったので結果から省いている。
|
それはともかくとして、ThreadRipperではUMAモードにするとDevice to System(GPUからCPUへのデータ転送が)2GB/secしか出ないという謎の現象が起こっている。NUMAモードだと11GB/secを超えているし、System to Device(CPUからGPUへの転送)は12GB/secだから、これは純粋にThreadRipperのUMAモードの問題だろう。
もっともこれが問題になるのはGPUカードをGPGPU的に使う場合で、しかも大量にデータを取り込む場合に限られるだろうが(なのでMiningとかだとおそらく影響は少ない)。
