自動フィールドシフト 高速化 (まとめ)
この前高速化版+10を公開したのだけど、自動フィールドシフト高速化で実際どのくらい速くなっているのか…という話。
環境
Win7 SP1 x64
Core i7 4770K (4C/8T @ 4.0GHz)
DDR3-2133 2ch 16GB (9-11-10-28-2)
Aviutl 1.00 (スレッド数:8)
m2v.aui 0.7.8
MPEG2, 1440x1080i, 10240frames
自動フィールドシフト設定
デフォルトに「映画/アニメ」プリセットを適用したもの
スレッド数:8
この設定で、ベンチマークプラグインで出力しつつ、所要時間を測定。要するに自動フィールドシフトの単体ベンチマークのようなもの。
いつもどおり一発勝負。
今回、上に書いたように自動フィールドシフトの単体の速度を測るだけでなく、所要時間を自動フィールドシフトの処理ごとに測定した。
1. 初期化
init
2. フレームの取得 (デコード、色変換、YUY2アップサンプリング)
get_ycp_cache
3. フレーム走査 (並列化部分)
scan_frame
4. 解析・フィルタリング・判定
count_motion
analyze_frame
analyze_map_filter
5. フィールドシフト・フレーム合成
blend
大雑把に言えば、この5つの部分に分けられる。
まずこれまで公開した高速化版の比較。
オリジナル(MMX)、高速化版+6、高速化版+8、高速化版+10で比較。
+8と+10のAVX版は共通(同じコード)。
1フレームにかかった平均処理時間をグラフにした。

更新ごとに速くして行きましたよ~という図。
こうして見ると、薄いグレーの部分(scan_frame)や黄色の部分の高速化が目立つけど、それ以外も少しずつ高速化している。
自動フィールドシフトで並列化されている部分は薄いグレーの部分だけで、そこが最も高速化しているので、自動フィールドシフト単体としての並列化率は更新するたびに下がり続けている。
それでも実際に高速化版を使用するとCPU使用率が上がる事が多い。実際には自動フィールドシフト単体の使用なんてせずに例えばx264エンコをしたりする。なので、自動フィールドシフトの高速化によってx264により多くのフレームが渡されことになり、x264側のマルチスレッドが効くようになることで、エンコ中のCPU使用率が向上している(そして速くなる)のだと思う。
次に、高速化版 +10で、各高速化の段階ごとに比較。

AVX2も「劇的」からは程遠いけど、確実に効果はある。
というわけで、だいたいこんなもんだし、もっといえばHaswellでこんだけ、という話。Ivy/Sandyだと似たような傾向だけど、XeonW3680(Westmere)ではこんなに高速化していなかったので、CPU・環境によって結構違うのかもしれない(原因不明)。
高速化を通じて、色々勉強になったし、大量のメモリアクセスは遅いということは身に染みた。
自動フィールドシフトという素晴らしいプラグインを開発・公開してくださったaji様、ありがとうございます。
また、公開初期の頃、いろいろバグがあって申し訳ありませんでした。ご指摘いただいた方々、あるいは高速化したよ、という報告をくださった方々、ありがとうございます。
環境
Win7 SP1 x64
Core i7 4770K (4C/8T @ 4.0GHz)
DDR3-2133 2ch 16GB (9-11-10-28-2)
Aviutl 1.00 (スレッド数:8)
m2v.aui 0.7.8
MPEG2, 1440x1080i, 10240frames
自動フィールドシフト設定
デフォルトに「映画/アニメ」プリセットを適用したもの
スレッド数:8
この設定で、ベンチマークプラグインで出力しつつ、所要時間を測定。要するに自動フィールドシフトの単体ベンチマークのようなもの。
いつもどおり一発勝負。
今回、上に書いたように自動フィールドシフトの単体の速度を測るだけでなく、所要時間を自動フィールドシフトの処理ごとに測定した。
1. 初期化
init
2. フレームの取得 (デコード、色変換、YUY2アップサンプリング)
get_ycp_cache
3. フレーム走査 (並列化部分)
scan_frame
4. 解析・フィルタリング・判定
count_motion
analyze_frame
analyze_map_filter
5. フィールドシフト・フレーム合成
blend
大雑把に言えば、この5つの部分に分けられる。
まずこれまで公開した高速化版の比較。
オリジナル(MMX)、高速化版+6、高速化版+8、高速化版+10で比較。
+8と+10のAVX版は共通(同じコード)。
1フレームにかかった平均処理時間をグラフにした。

更新ごとに速くして行きましたよ~という図。
こうして見ると、薄いグレーの部分(scan_frame)や黄色の部分の高速化が目立つけど、それ以外も少しずつ高速化している。
自動フィールドシフトで並列化されている部分は薄いグレーの部分だけで、そこが最も高速化しているので、自動フィールドシフト単体としての並列化率は更新するたびに下がり続けている。
それでも実際に高速化版を使用するとCPU使用率が上がる事が多い。実際には自動フィールドシフト単体の使用なんてせずに例えばx264エンコをしたりする。なので、自動フィールドシフトの高速化によってx264により多くのフレームが渡されことになり、x264側のマルチスレッドが効くようになることで、エンコ中のCPU使用率が向上している(そして速くなる)のだと思う。
次に、高速化版 +10で、各高速化の段階ごとに比較。

AVX2も「劇的」からは程遠いけど、確実に効果はある。
というわけで、だいたいこんなもんだし、もっといえばHaswellでこんだけ、という話。Ivy/Sandyだと似たような傾向だけど、XeonW3680(Westmere)ではこんなに高速化していなかったので、CPU・環境によって結構違うのかもしれない(原因不明)。
高速化を通じて、色々勉強になったし、大量のメモリアクセスは遅いということは身に染みた。
自動フィールドシフトという素晴らしいプラグインを開発・公開してくださったaji様、ありがとうございます。
また、公開初期の頃、いろいろバグがあって申し訳ありませんでした。ご指摘いただいた方々、あるいは高速化したよ、という報告をくださった方々、ありがとうございます。
スポンサーサイト