というかもはや最適化はインラインアセンブリではなく、
「如何にコンパイラが最適化しやすいCコードを書くか」ということに尽きる気がします。
というわけで21500ぐらいまで来ました。
何はともあれ、自分の環境(DevilsCannyon=Haswell)4.5GHzで普段使っているフィルタをかけて25~26fps出るようになったため、24フレームのアニメをフィルタをかけてリアルタイム再生できます。
参考にいつものフィルタは↓(TFMは事前処理(1pass目)なので2pass目では実質バイパス)
TFM(mode=1,order=-1,PP=1,slow=2,input=TFMout,batch=true)
TDecimate(mode=1,tfmIn=TFMout,input=TDout,batch=true)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ(STR=1.0)
2016/03/26
2016/03/21
7日間の残り
フロイド-スタインバーグ・ディザリング
ネックはdfttestのdither処理難ではないかというところで。
単純に最新のVCでコンパイルするだけで2割速くなりました。
が、そこからがなかなか短くならない・・・
コードの最適化もしているのですが、1000フレームのアニメをエンコードするのに
VC2015 communicateのプロファイラでモジュールのサンプル時間(1ms/sample)を測定したところ
dfttest 1.9:30123
dfttest VC14 /Ox /Arch:SSE2:25118
dfttest VC14 /Ox /Arch:SSE2 Optimized Code:22230
ほどかかっているようです。
ちなみにほかにも
fftw:39781
DGDecode:7348
FluxSmooth:3348
unsharpHW:3113
SplineResize:2457
となっています。
fftwは並列化されているためボトルネックにはならないのですが、やはりdfttestの関数自体の20s超が気になります・・・。
ディザリングをしなければこれが劇的に減るのですが、ね。
もうちょっとコードを弄ってみましょう。
というか、コンパイラで早くなったのはどうも浮動小数点の精度の所為な気がします。
というのも演算結果が変わるので・・・。
まぁ、SNは90dB以上=0.002%程度の差、1digit程度の差しかないため、実質問題はないかと。
/fp:preciseを指定しているのですが、謎です。
ネックはdfttestのdither処理難ではないかというところで。
単純に最新のVCでコンパイルするだけで2割速くなりました。
が、そこからがなかなか短くならない・・・
コードの最適化もしているのですが、1000フレームのアニメをエンコードするのに
VC2015 communicateのプロファイラでモジュールのサンプル時間(1ms/sample)を測定したところ
dfttest 1.9:30123
dfttest VC14 /Ox /Arch:SSE2:25118
dfttest VC14 /Ox /Arch:SSE2 Optimized Code:22230
ほどかかっているようです。
ちなみにほかにも
fftw:39781
DGDecode:7348
FluxSmooth:3348
unsharpHW:3113
SplineResize:2457
となっています。
fftwは並列化されているためボトルネックにはならないのですが、やはりdfttestの関数自体の20s超が気になります・・・。
ディザリングをしなければこれが劇的に減るのですが、ね。
もうちょっとコードを弄ってみましょう。
というか、コンパイラで早くなったのはどうも浮動小数点の精度の所為な気がします。
というのも演算結果が変わるので・・・。
まぁ、SNは90dB以上=0.002%程度の差、1digit程度の差しかないため、実質問題はないかと。
/fp:preciseを指定しているのですが、謎です。
2016/03/09
どこへ行こうというのかね?
MASM refference
x86/x64 SIMD命令一覧表 (SSE~AVX2)
・・・なんでこんなことを調べているのでしょうか・・・
visual studio expressを2015にしたんですよ。
んで、よくよく調べるとMASMってちゃんとVCに入ってるんですね。
というわけで今までMASM6.15でアセンブルしていたのを最新版でアセンブルしようと・・・したらできなかったという話です。
masm6では問題なくアセンブルできていたのに、その後継の14でできなくなるとは之如何に。
エラー A2022 instruction operands must be the same size
と言われるという・・・
如何せん僕はwindowsのソフトをほとんど弄ったことがありません。
見たことがある(わかるわけではない)のも386のアセンブラぐらいというロートルなので、そもそもオペコードの意味が分からない・・・
とかいろいろグーグル先生に尋ねた結果、アドレスの書き方が良くない?らしいということが判明。
まぁ、あまり原因はわかっていないのですが。
_DATA SEGMENT PARA PUBLIC USE32 'DATA'とか書いてあるのが多少気になりますが、そもそも意味が分からない・・・
という話とは多分関係ないのですが、ひとまず、DGIndexをAVX2を有効にしてコンパイルすると
同一ソースで150MB/s→170MB/s@Haswell4.5GHzぐらいになりました。fpsは調べてませんが。
大体1割早くなった感じでしょうか。
AVX2>AVX=SSE2ぐらいで。
TIVTCも早くなったりするだろうか。
というわけで試してみたけど変わりませんでした。
そして別にコンパイラ最適かじゃなくて、Tdecimateの差分算出を並列処理させれば早くなるんじゃね?とか思って
ベクター化と並列化のメッセージ
を眺めている今日この頃。
深みにはまるだけな気がして仕方がない・・・
x86/x64 SIMD命令一覧表 (SSE~AVX2)
・・・なんでこんなことを調べているのでしょうか・・・
visual studio expressを2015にしたんですよ。
んで、よくよく調べるとMASMってちゃんとVCに入ってるんですね。
というわけで今までMASM6.15でアセンブルしていたのを最新版でアセンブルしようと・・・したらできなかったという話です。
masm6では問題なくアセンブルできていたのに、その後継の14でできなくなるとは之如何に。
table1 sword 16384, 21407, 16384, 8867というようなコードをアセンブルすると
movdqa xmm0,[table1]
エラー A2022 instruction operands must be the same size
と言われるという・・・
如何せん僕はwindowsのソフトをほとんど弄ったことがありません。
見たことがある(わかるわけではない)のも386のアセンブラぐらいというロートルなので、そもそもオペコードの意味が分からない・・・
とかいろいろグーグル先生に尋ねた結果、アドレスの書き方が良くない?らしいということが判明。
movdqa xmm0,xmmword ptr[table1]というようにしたら治りました。
まぁ、あまり原因はわかっていないのですが。
_DATA SEGMENT PARA PUBLIC USE32 'DATA'とか書いてあるのが多少気になりますが、そもそも意味が分からない・・・
という話とは多分関係ないのですが、ひとまず、DGIndexをAVX2を有効にしてコンパイルすると
同一ソースで150MB/s→170MB/s@Haswell4.5GHzぐらいになりました。fpsは調べてませんが。
大体1割早くなった感じでしょうか。
AVX2>AVX=SSE2ぐらいで。
TIVTCも早くなったりするだろうか。
というわけで試してみたけど変わりませんでした。
そして別にコンパイラ最適かじゃなくて、Tdecimateの差分算出を並列処理させれば早くなるんじゃね?とか思って
ベクター化と並列化のメッセージ
を眺めている今日この頃。
深みにはまるだけな気がして仕方がない・・・
2016/03/06
登録:
投稿 (Atom)