自動フィールドシフト 高速化版+10

Haswell向け高速化。

とはいえ、今までに比べればそんなに高速化しないのが残念。+6 → +8に比べるとたいしたことないと思う。拡張命令よりメモリアクセスパターンの改善のほうが効果があることを実感。

・AVX2により少し高速化。

・スレッド分割を見直し、わずかに高速化。より均等に分割されるように。

Haswell向け高速化。いつもどおり、AVX2が使用可能な環境なら自動的に使用される。(Haswell + Win7 SP1以降)

部分的には3割以上高速化しているところもあるけど、afs全体の高速化の度合いとしては多くても1割ぐらいかも。メモリアクセスが大半なところも多いので、そういった所では全く速度が伸びない…。



とりあえず、以下AVX2高速化に関するメモ書き。まあ、当たり前のことばっかりなんだろうけど。

・ちゃんと関数の終わりに_mm256_zerouppper(vzeroupper)を書く。
・ちゃんと/arch:AVXを指定してコンパイルする。

このへんを忘れると速度が出ず、ハマる。SSE-AVX遷移ペナルティーはそれなりに大きいみたい。気をつけていたつもりだったが、_mm256_zerouppperはやっぱり忘れやすい。

・メモリアクセスがメインのところをAVX2化してもほとんど効果出ない。

まあ当たり前といえば当たり前だけど…。

HaswellでメモリアクセスどころかL3キャッシュすらほとんど高速化されていないのもHaswellが性能上がらない原因のひとつじゃないかなあと思う。NehalemやSandyは前世代と比べてメモリアクセスが大幅に強化されたことが性能の飛躍的な向上を支えていたのかもしれない。

そこでeDRAMなんでしょうけど…。

・128bitの壁。vperm系が遅いらしい。

shuffle/pack/unpack、さらにshift/alignrが使いにくいです…。shuffle系はともかく、128bit×2でない256bitのshift/alignrは欲しかった…。

128bitの壁を越えるにはvperm~を使えばいいんだけど、これがまた遅いらしい。コメントにも頂いたように、意外とvextracti128とかvinserti128を使ったほうがいいようだ。

・Haswellちゃんはshuffle/pack/unpack/blendが苦手?

なるべく連投しないように…ってそんなこと言われても…。YC48を扱うとどうしてもshuffleまみれになるような気が。このへんはよくわからないし、あきらめ。



このあたりに注意すれば、あとはわりと簡単にAVX2コードを作成でき、そこそこ速度が出る。特にまとまった計算があるところだと、結構高速化できて面白い。



ダウンロード>>



スポンサーサイト

コメントの投稿

非公開コメント

No title

AVX2はイントリンシックだと旨味が半減します。アセンブラでゴリゴリ書くとうまいです。
このへんはSSE2あたりとあまり変わらないですね。

No title

やはりアセンブラゴリゴリですか。

たしかにコンパイラの出すコードはたまに私から見ても非効率的なことをやってますからね…。

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: afs

うーん、すみません。15回に1回ぐらいというのがまた厄介ですね…。

・ソースの解像度
・出力解像度
・afsの設定
・Aviutlの[ファイル]>[環境設定]>[システムの設定]の最大画像サイズの設定

あたりも教えていただけますでしょうか。

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: No title

情報有り難うございました。

頂いた設定を再現し、20本以上エンコードしましたが、特に問題は発生せず、原因が特定できていない状態です。たまに発生する、といった問題は難しいです…。

今後、コードの見直しなどしてみます。

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: afs

あまり関係ないとは思うのですが、Aviutlの[環境設定] > [システムの設定]のキャッシュフレーム数はどのくらいでしょうか。

多め(15以上とか)に設定しているのでしたら、LargeAddressAwareを有効にしたほうが良いかと思いますが…そこも教えていただけますでしょうか。

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

afs, 再現した…のですが…

LargeAddressAware、x64ということですし、やはりチェックを入れてみていただけないでしょうか。

実は、思わぬ状態で偶然再現しました。
http://sdrv.ms/14ZjraW
※この後、Aeroが切れてウィンドウがぐちゃぐちゃになって「メモリが不足しています」というOSのメッセージが出ました。

以下のように、メモリを使用しまくったところ、編集プロジェクト(aup)を読み込む際に発生しました。

Aviutl (編集中)
Aviutl + x264 10bit
QSVEncC
TMSR4 (カット詳細分析)
Firefox(タブたくさん)
Chrome(ニコ動たくさん)
Thuderbird
RAM Disk 4GB
などなど

再現したからといって、同じことが原因とは限りませんが、メモリ不足が一因となっている可能性はあるのだと思います。

そこで、LargeAddressAwareにチェックを入れ、Aviutlが扱えるメモリ空間を広げてみていただけないでしょうか。x64 OSなら特にデメリットはないはずです。

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: No title

無事安定したようでよかったです。

やはり64bit OSならLargeAddressAwareをつけたほうが良いようですね。
プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: まじぽか太郎様

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (ミラー使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR