やっと少し時間ができたので、Haswell-Eで少し実験。
今回は
前やったみたいに、x264がスレッドをどのくらい有効に使ってくれるか試す。
ほかの5960X (Haswell-E)関連の記事
5960Xでx264エンコードi7 5960X オーバークロック(OC)なんか買ってしまった
設定と環境
x264はマルチスレッド効率が高いほうだけど、8C/16Tはどうなのかな、という実験。
| OS | Win8.1 x64 | Win8.1 x64 |
| CPU | i7 5960X | i7 4770K |
| コア数 | 8C/16T | 4C/8T |
| 動作周波数 (Core) | 4.4GHz | 3.9GHz |
| 動作周波数 (UnCore) | 4.2GHz | 3.9GHz |
| キャッシュ容量 | L3=20MB | L3=8MB |
| メモリ | DDR4-2400, 4ch | DDR3-2400, 2ch |
| メモリ容量 | 32GB (8GBx4) | 16GB (4GBx4) |
| メモリタイミング | 16-16-16-39-2 | 11-12-12-32-2 |
ソースH.264/AVC、1920x1080p、23.976fps、約1分30秒、2155frames
精霊使いの剣舞 OPをエンコードしたもの
共通x264 r2479 x64 (Komisar氏)
Avisynth
LSMASHSource r717 (POP氏)
x264設定x264 --threads <スレッド数> --preset <プリセット>
測定いつもどおり一発勝負
結果 (高速化率)
各プリセットのthread=1の時に対する各スレッド数での速度比をグラフにした。
スレッド数が1の時と比べ、8コア/16スレッドな5960Xでは最大9.8倍、4コア/8スレッドの4770Kでも最大4.4倍も高速化していて、やはりx264のマルチスレッド効率は高いようだ。そして5960Xのマルチスレッド性能の高さ、ハイパースレッディングの有用性もわかると思う。
また、予想通り(?)「重い」プリセットのほうがスレッド効率が高い。逆に「軽い」プリセットはスレッド数を増やしてもさほど高速化しない。
4770Kの場合、スレッド数を増やしていっても速度はすぐに頭打ちになってしまう。x264のスレッド数は自動の場合はコア数×1.5だけど、そのぐらい(12スレッド)でだいたい最高速度になっているんじゃないかと思う。
一方、5960Xの場合、自動なら24スレッドになる。けど、このグラフを見る限り24スレッドではまだまだ頭打ちとはいえなさそうだ。グラフを見る限り、スレッドを増やしすぎたからといって速度が落ちていく兆候は見えないので、速度だけ考えるなら48ぐらいにしてしまってもいいのかもしれない。ただ
threadによって画質がいつも同じとは限らないと思うので、そこはちょっと気になることころ…。
ちなみに、この実験、プリセット5通り、スレッド数48通り、マシン2台ということで、計480回のエンコードになる。さすがにログをいちいち見て手動で入力したくなかったので、適当にプログラムを書いてcsvで出力、excelでグラフ化…というそれはそれで面倒なことになっている。
まあ、エクセルにさえ放り込めればあとは関数使っていくらでもいじってグラフにできるので、そこは楽なのだけど。
そのエクセルファイルは
こちら。
ほかの5960X (Haswell-E)関連の記事
5960Xでx264エンコードi7 5960X オーバークロック(OC)なんか買ってしまった
