SiSoftware
http://www.sisoftware.co.uk/
さて、ここからはCPU周辺の話をしたい。まずはInter-Core Efficiency(グラフ56~60)。グラフ56はOverallで、コア間通信の平均BandwidthとLatcencyを、Best CaseとWorst Caseで示している(縦棒がBandwidth:左軸、折れ線がLatency:右軸)。
ちなみにBest Caseとは同じコア内の2つのThread間で通信を行うケース、Worst Caseは同じコア内の2つのThread間では通信を行わないケースである。そのため、HyperThreadingが無効のCore i5-8600Kでは、Best CaseとWorst Caseで差がない。
それはともかく、相変わらずRyzen系はBest CaseとWorst Caseでの差が激しいが、これはやはりCCXをまたいでの通信が相応に遅いからと想像される。
グラフ57・58がBandwidthの詳細である。Best Case(グラフ57)に関しては、Core i7-8700KとRyzen系でピークが異なるのはL1/L2容量の差であろう。興味深いのはWorst Case(グラフ58)で、ほぼ10~11GB/sec程度で一定になっていることだ。これはInfinity Fabricの帯域(というかData FabricとCCXの間の帯域)がネックになっているためと思われる。
ついでLatencyである(グラフ59・60)。こちらは縦軸を頻度(%)で、横軸をLatency(2ns刻み)で示している。グラフ59がBest Caseだ。相変わらずRyzen系はCCXをまたぐと大幅にLatencyが増えている。
これはInfinity Fabricの宿命ではあるが、面白いのはまたいだ場合のピークがRyzen 7 1800Xでは130ns程度になっているが、Ryzen 2では126ns程度と若干ではあるがLatencyの削減が出来ていることだ。
これはCCXをまたがない場合も同じで、Ryzen 7 1800Xでは(ちょっと見にくいが)44nsがピークなのに対し、Ryzen 2では40~42nsにピークがシフトしている。また同一コア内での交換はさらに高速で、16ns台のRyzen 7 1800Xに対し、Ryzen 2では14nsに、とそれぞれ若干ではあるがLatency削減が実現している。
Worst Case(グラフ60)では若干数字がばらけるし、特にCCXをまたいだ場合はわずかにLatencyが増えているが、同一CCX内あるいは同一コア内だと相変わらずLatencyはやや削減されている。もっとも頻度そのものが低くなり、幅が広がっているは分、その前後で数字がバラけているということだ。
原理的に単一のRing Busで構成されるCore i系に比べると、Ryzen系はやや分が悪いのは仕方ないが、それでもRyzen 2で若干とはいえ性能改善が確認できた。
次がメモリコントローラ周り。グラフ61~64がBandwidthである。グラフ61・62はStreamと、次のグラフ63・64のうち256MB~4GBレンジの平均値をまとめたものである。Multi Thread(グラフ61)では、先のRMMTの結果に非常に近い結果になっている。
面白いのは、Single Thread(グラフ62)でもやや数値は落ちるもののかなり高い結果になることだ。特にRyzen系ではグラフ34の1 Thread時の値を超えるほどの数値になっているのは、利用する命令(StreamはAVX/AVX2を利用、RMMTはSSE2)に関係しているのかもしれない。
Cache & Memory Bandwidth(グラフ63・64)では、Multi Threadで、Core i系が1TB/secを超えるピーク性能となっているが、L1が64Bytes/cycleで読み込めているからであって、32Bytes/cycleのRyzen系と異なるのは当然である。
もっともこれはAVX512対策であって、AVX512をサポートしないRyzen系がこの程度で留まっているのは理にかなっている。逆にL2以降に関しては、Ryzen系がCore i系を越える帯域を常時確保しており、これはRyzen 2でも変化はない。
Single Thread(グラフ64)における、Ryzen 7 1800XとRyzen 2の比較が興味深いことになっている。Ryzen系はData L1が32KBだから、64KBというとちょうどL1 Miss/L2 Hitの領域だ。ここでRyzen 7 1800XとRyzen 2の間に大きな差が生じている。16MBあたりで収束するのだが、これは自分のCCX内のL3ではMissして、異なるCCX側のL3にアクセスし始める段階だ。
要するに、自分のCCX内で完結する範囲ではL2/L3がより少ないLatencyでアクセスできるため、結果としてこれが帯域の向上として数値に出ていると考えられる。
Latencyは? ということでグラフ65~76まで。こちらはData(データ領域)とCode(命令領域)それぞれSequential/In-Page Random/Full Randomの3パターンで、結果をCycleとnsの両方で示している。L3まではコアの動作周波数に同期しているから、cycle表記で問題ないが、これを越えた部分はメモリアクセスになるのでns表記の方で見ることにする。
まずはData領域のSequential(グラフ65・66)。Ryzen 2のL2領域のLatencyが、Ryzen 7 1800Xの7cycleから6cycleに削減されている。またL3 Missにおけるメモリアクセスが5.2~5.3nsから3.5~3.6nsに削減されており、これは大きく効いてきそうな数値だ。
In-Page Random(グラフ67・68)でもこの傾向は同じだが、付け加えるとL3領域も5cycleほどLatencyが削減されている。また、メモリアクセスでも7nsほどLatencyが少ない。In-Page Randomでは、Core i系が優秀な結果を出している部分でもあり、これに比べるとRyzen系は改善の余地はある。とはいえ、確かにLatency削減の効果も確認できる。
グラフ69・70がFull Rondomで、こちらでは相対的にCore i系との差もなくなっている。それはともかくとして、Ryzen 2はRyzen 7 1800Xと比較して、L2では5cycle、L3では10cycleほどLatencyを減らしており、メモリ領域でも10ns以上(32MBあたりだと17ns近く)のLatencyの削減に成功している。これはなかなか見事だと思う。
次にCode領域を見る。Sequential(グラフ71・72)では、意外だがL2~L3領域で微妙にRyzen 7 2700XのLatencyが1cycleほど増えている。ただRyzen 5 2600Xは同じくらいということを考えると、実際は1cycle未満の揺らぎがあるということかもしれない。
グラフ71を見るとLatencyが増えているように見えるが、キャッシュミスした先では0.5~0.6nsほどLatencyが減っており、こちらではLatency削減の効果が確認できた。
In-Page Random(グラフ73・74)は? というと、Cycleで見るとRyzen 7 1800Xと変わらない(グラフ73)ように見えるが、実際のところ、メモリアクセスは若干(1ns程度)のLatency削減が確認できる(グラフ74)。
最後がFull Rondom(グラフ75・76)で、512KB(L2 Hit)まではほぼ同等だが、1MB(L2 Miss/L3 Hit)で2cycle、4MBで23cycle、16MBで30cycle強Latencyが減っており(グラフ75)、メモリアクセスも64MBで10ns、1GBで13nsほどのLatency削減になっている。Full Randomだから結構な頻度でTagをアクセスする必要があり、このアクセスを高速化できたことが、結果としてのLatency削減に繋がっているものと思われる。
おまけでMemory Transaction(グラフ77)とVideo Memory Bandwidth(グラフ78)も見てみよう。Memory Transactionの方は、TSX命令を実装していないRyzen系には意味がないテストではあるのだが、一応掛けてみた。実際にこうした処理だと、Ryzen 2系でも別に高速化されないことが確認できた。
最後がVideo Memory Bandwidthで、これはPCI Express経由によるGeForce GTX 1080のVRAMへのアクセスがどの程度の速度で行えるかの確認である。とりあえずここではCore i系とRyzen系(というか、Intel Z370とAMD X470)の間に違いが無いことが確認できた。