Ryzenの得意あるいは不得意
この前ゲットしたRyzenは、cinebenchやx264エンコではかなりの速さを発揮していた。
一方、これまで出ているいろいろなベンチマークを見ると、メモリアクセスが遅いとか、特にprefetchが働かない場合のレイテンシが大きいとかいう話を聞く。そこで、実際にRyzenがメモリアクセスが苦手なのか、確認してみた。
また、RyzenはSMTの効果が比較的高い、という話もある。そこで、並列で動作するスレッドの各コアへの割り当てを調整して、速度がどう変化するか調べた。
確認には姫野ベンチマークを使用した。
姫野ベンチは、ポアソン方程式をヤコビ反復法で解く場合の速度をはかるもの。結果はMFLOPSで取得され、値が大きいほどはやいことになる。いくつかの計算サイズが用意されていて、計算サイズが小さい場合には、キャッシュにデータが乗りやすくなり、演算律速となる一方、行列サイズが大きくなると、データがキャッシュに乗らなくなり、メモリ律速になる。
今回は、こちらのページにある"C + OMP, dynamic allocate version"を少しいじったものを使用した。いじった部分はOpenMPのスレッド数を指定した数にしたり、各コアへの割り当てを調整する部分で、計算そのものは変更していない。
VC2017を使ってOpenMPを有効にして、64bitでビルドした。一応、 /arch:AVXもつけたが、ループが複雑なため自動ベクトル化はされてないみたい(逆アセンブルで確認)。
テストしたのはXSサイズとLサイズ。それぞれスレッド数とその割り当てを8通りほど試した。数字がスレッド数、"P"(Physical)は物理コアを優先して割り当てることを意味し、"L"(Logical) は論理コアに優先して割り当てることを意味する。
実際にその様子をタスクマネージャーで確認するとこんな感じ。
P1↓
L2↓
P2↓
L4↓
P4↓
L8↓
P8↓
L16↓
比較環境は以下の通り。前回とだいたい同じだが、今回はメモリ帯域が影響しそうだったので、5960X @ 3.6Ghzについては、メモリを2chのものと4chのものをそれぞれ別に測定した。
・Ryzen7 1700 @ 3.6GHz
・i7 5960X @ 3.6GHz, 2ch (Ryzen合わせ)
・i7 5960X @ 3.6GHz, 4ch
・i7 5960X @ 4.2GHz, 4ch
・i7 7700K @ 4.8GHz
詳細はこんな感じ。
結構、実行するたびに値がブレることがあるので注意。2回ほどやって速い方の値だが、まだバックグラウンドのタスクなどで遅くなってしまっているのがあるかもしれない。
まずは、XSの結果から。
・5960X@3.6GHz,2chと5960X@3.6GHz,4chがほぼおなじで、このサイズだとキャッシュが効いてほとんどメモリは関係ない模様。
・8コア使い切ったときはR7 1700@3.6GHzのほうが、5960X@3.6GHzより高速で、これはx264とかでも同じ。Ryzenの演算力の高さが表れている。さすがに5960X@4.2GHzには勝てない。
・5960XでもR7 1700でも、P2 > L4, P4 > L8などとなっていて、この場合にはSMTを切ったほうがいいらしい。これは同じコアにスレッドが入ることで、L1/L2キャッシュで競合がおき、遅くなってしまっていると思われる。
次にLサイズの結果。
・5960X@3.6GHz,2chと5960X@3.6GHz,4chでそこそこ差が出ていて、Lサイズではメモリ帯域が重要になってきている事がわかる。
・メモリが効くようになったためか、R7 1700@3.6GHzはだいぶ遅くなってしまい、同じクロックの5960X@3.6Ghz,2chと互角、あるいはやや遅いぐらいまで後退してしまった。また、5960X@3.6Ghz,4ch相手では歯が立たない感じになっている。特にスレッド数を増やした場合に顕著。
・5960Xでは相変わらずP2 > L4, P4 > L8などとなっていて、やはりこの場合にはSMTを切ったほうがいいらしい。
・R7 1700では、XSサイズのときと異なり、P2 < L4, P4 < L8となっていて、面白い。7700Kも同様。原因はよくわからないが、どうせキャッシュミスするのだから、キャッシュの競合は大きな問題にならず、逆にSMTによってメモリアクセスのレイテンシが遮蔽できたのかもしれない。
というわけで、演算中心のときはやはりRyzenは速いが、メモリアクセスが重要な場面では遅くなるのかもしれない、ということがわかった。メモリをDual channelに揃えた5960X@3.6Ghz,2chと比較しても、XSサイズでは優勢なのに対し、Lサイズでは互角あるいは劣勢となってしまっている。
SMTについては効果のあるときとないときがはっきり出た。やはり演算対象によって効果がだいぶ変わってくるようだ。
まあ、x264エンコードなら前の記事のように、Ryzenは優秀だし、SMTも有効な方がいいに決まっている。ただ、姫野ベンチのメモリアクセスパターンが複雑なのもあるだろうけど、メモリアクセスが中心の計算になってくると不得意なものもあるよ、ということがわかった。
一方、これまで出ているいろいろなベンチマークを見ると、メモリアクセスが遅いとか、特にprefetchが働かない場合のレイテンシが大きいとかいう話を聞く。そこで、実際にRyzenがメモリアクセスが苦手なのか、確認してみた。
また、RyzenはSMTの効果が比較的高い、という話もある。そこで、並列で動作するスレッドの各コアへの割り当てを調整して、速度がどう変化するか調べた。
確認には姫野ベンチマークを使用した。
姫野ベンチは、ポアソン方程式をヤコビ反復法で解く場合の速度をはかるもの。結果はMFLOPSで取得され、値が大きいほどはやいことになる。いくつかの計算サイズが用意されていて、計算サイズが小さい場合には、キャッシュにデータが乗りやすくなり、演算律速となる一方、行列サイズが大きくなると、データがキャッシュに乗らなくなり、メモリ律速になる。
今回は、こちらのページにある"C + OMP, dynamic allocate version"を少しいじったものを使用した。いじった部分はOpenMPのスレッド数を指定した数にしたり、各コアへの割り当てを調整する部分で、計算そのものは変更していない。
VC2017を使ってOpenMPを有効にして、64bitでビルドした。一応、 /arch:AVXもつけたが、ループが複雑なため自動ベクトル化はされてないみたい(逆アセンブルで確認)。
テストしたのはXSサイズとLサイズ。それぞれスレッド数とその割り当てを8通りほど試した。数字がスレッド数、"P"(Physical)は物理コアを優先して割り当てることを意味し、"L"(Logical) は論理コアに優先して割り当てることを意味する。
実際にその様子をタスクマネージャーで確認するとこんな感じ。
P1↓
L2↓
P2↓
L4↓
P4↓
L8↓
P8↓
L16↓
比較環境は以下の通り。前回とだいたい同じだが、今回はメモリ帯域が影響しそうだったので、5960X @ 3.6Ghzについては、メモリを2chのものと4chのものをそれぞれ別に測定した。
・Ryzen7 1700 @ 3.6GHz
・i7 5960X @ 3.6GHz, 2ch (Ryzen合わせ)
・i7 5960X @ 3.6GHz, 4ch
・i7 5960X @ 4.2GHz, 4ch
・i7 7700K @ 4.8GHz
詳細はこんな感じ。
| CPU | Ryzen 7 1700 @ 3.6GHz | i7 5960X @ 3.6GHz, 2ch | i7 5960X @ 3.6GHz, 4ch | i7 5960X @ 4.2GHz, 4ch | i7 7700K @ 4.8GHz |
| コア数 | 8C/16T | 8C/16T | ← | ← | 4C/8T |
| 定格 | 3.0GHz | 3.0GHz | ← | ← | 4.2GHz |
| Turbo | 3.7GHz | 3.5GHz | ← | ← | 4.5GHz |
| 設定Clock | 3.6GHz | 3.6GHz | ← | 4.2GHz | 4.8GHz |
| 設定電圧 | 1.225V | 1.100V | ← | 1.164V | 1.296V |
| 設定Uncore | - | 3.6GHz | ← | 3.8GHz | 4.4GHz |
| メモリ | G.Skill F4-3400C16Q-16GRBD | Avexir AVD4U24001608G-4M | ← | ← | Corsair CMK16GX4M2B4000C19R |
| メモリ速度 | DDR4-2400, 2ch | DDR4-2400, 2ch | DDR4-2400, 4ch | DDR4-2666, 4ch | DDR4-3600, 2ch |
| メモリタイミング | 15-15-15-36 | 15-15-15-35 | ← | 16-16-16-39-2 | 16-16-16-36-1 |
| メモリ電圧 | 1.20V | 1.20V | ← | 1.255V | 1.35V |
| マザーボード | Asrock AB350 Pro4 (1.50) | Asrock Fatal1ty X99 Professional Gaming i7 | ← | ← | Asrock Z270 Extreme4 |
| SSD | Plextor PX-128M3 128GB | Plextor M8Pe 1TB (PX-1TM8PeY) | ← | ← | Plextor M6 Pro (PX-256M6Pro) |
| ケース | Antec P100 | Corsair Carbide 330R | ← | ← | Antec P100 |
| 冷却 | 純正 (Wraith SPIRE) | Cooler Master Nepton 280L (簡易水冷 280mm) | ← | ← | CRYORIG A80 (簡易水冷 280mm) |
| 電源 | Enermax EPM600AWT | Seasonic SS-760XP2 | ← | ← | Seasonic SS-660XP2S |
| OS | Win10 x64 | Win10 x64 | ← | ← | Win10 x64 |
結構、実行するたびに値がブレることがあるので注意。2回ほどやって速い方の値だが、まだバックグラウンドのタスクなどで遅くなってしまっているのがあるかもしれない。
まずは、XSの結果から。
・5960X@3.6GHz,2chと5960X@3.6GHz,4chがほぼおなじで、このサイズだとキャッシュが効いてほとんどメモリは関係ない模様。
・8コア使い切ったときはR7 1700@3.6GHzのほうが、5960X@3.6GHzより高速で、これはx264とかでも同じ。Ryzenの演算力の高さが表れている。さすがに5960X@4.2GHzには勝てない。
・5960XでもR7 1700でも、P2 > L4, P4 > L8などとなっていて、この場合にはSMTを切ったほうがいいらしい。これは同じコアにスレッドが入ることで、L1/L2キャッシュで競合がおき、遅くなってしまっていると思われる。
次にLサイズの結果。
・5960X@3.6GHz,2chと5960X@3.6GHz,4chでそこそこ差が出ていて、Lサイズではメモリ帯域が重要になってきている事がわかる。
・メモリが効くようになったためか、R7 1700@3.6GHzはだいぶ遅くなってしまい、同じクロックの5960X@3.6Ghz,2chと互角、あるいはやや遅いぐらいまで後退してしまった。また、5960X@3.6Ghz,4ch相手では歯が立たない感じになっている。特にスレッド数を増やした場合に顕著。
・5960Xでは相変わらずP2 > L4, P4 > L8などとなっていて、やはりこの場合にはSMTを切ったほうがいいらしい。
・R7 1700では、XSサイズのときと異なり、P2 < L4, P4 < L8となっていて、面白い。7700Kも同様。原因はよくわからないが、どうせキャッシュミスするのだから、キャッシュの競合は大きな問題にならず、逆にSMTによってメモリアクセスのレイテンシが遮蔽できたのかもしれない。
というわけで、演算中心のときはやはりRyzenは速いが、メモリアクセスが重要な場面では遅くなるのかもしれない、ということがわかった。メモリをDual channelに揃えた5960X@3.6Ghz,2chと比較しても、XSサイズでは優勢なのに対し、Lサイズでは互角あるいは劣勢となってしまっている。
SMTについては効果のあるときとないときがはっきり出た。やはり演算対象によって効果がだいぶ変わってくるようだ。
まあ、x264エンコードなら前の記事のように、Ryzenは優秀だし、SMTも有効な方がいいに決まっている。ただ、姫野ベンチのメモリアクセスパターンが複雑なのもあるだろうけど、メモリアクセスが中心の計算になってくると不得意なものもあるよ、ということがわかった。
スポンサーサイト
