rigayaの日記兼メモ帳

---

デフォルトでダウンロードする音声エンコーダをqaacに。
neroがいつまでダウンロードできるか怪しいため。

neroをダウンロードする機能は残ってたり…(以下略)。


qaacはAppleのエンコーダが必要となるので、iTunesとかQuickTimeの一部が必要になる。簡易インストーラは、CoreAudioToolbox.dllがない場合(※)に、iTunesインストーラをダウンロード、その中から必要なdllをqaacと同じフォルダに配置して、qaacを利用可能な状態にしている。 (iTunesのインストールをしているわけではありません! )
(2014.07.31追記) x264guiEx 2.15v2からはQuickTimeのインストーラを使用するように変更。

iTunesインストーラが必要となった時には、説明書きが表示されるので、それを読んでから「OK」をクリックし、その後iTunesのダウンロード画面が表示されるので左下に表示される「今すぐダウンロード」(青いボタン)をクリックして下さい。

そうするとウィンドウが幾つか勝手に開閉して、ダウンロードが開始され、iTunesインストーラのダウンロードが終わると自動的に他のもののインストールを続行していく。　…ダウンロードウィンドウを閉じないようにしてください、お願いします。

---

(※)
CoreAudioToolbox.dllのチェックをしているのは3箇所で、

・Apple Application Supportがインストールされているか (レジストリ)
・<Aviutl.exeのあるフォルダ>\exe_files フォルダ
・(上書きインストールなら)現在指定されているqaac.exeのフォルダ

このいずれにもなかったらiTunesのダウンロード画面を表示する。

---

qaacのダウンロード & アップデート

簡易インストーラはアップデートにも使えるわけだけど、x264やL-SMASH同様、qaacももし更新されていたらアップデートがかかるはず。

---

XPでは動かなかった…
Windows XP Mode on VMWare Playerで確認。原因はたぶんXPのIEがIE8なので、Appleのページを満足に表示できない、というかよくわからないセキュリティがうんたらかんたらでひっかかるからだと思う。あと、L-SMASHの更新用のバージョン取得もセキュリティなんちゃらでうまく動かなかった。(そもそもIE8で表示できてない…)

まあIEは9でだいぶよくなったけど、それより前はとても残念だったので仕方ないかも。

正直あまりHTML(というかWeb全般?)詳しくないので、お手上げ…

IE9以降が入るVista以降の環境ではちゃんと動くのは確かめた。まあx264guiEx自体、動作環境はVista以降にしているので、XPの方はごめんなさい、ということで…

---

---

このまえの記事の続き。

AMDのSteamrollerなどでは256bitの浮動小数点演算に対応はしていても内部的には128bit×2の演算しかできないのであれば、わざわざ256bit演算を使う必要はないのではないか、と予想したのだけどそれの検証。

浮動小数点演算部分をAVX+FMA3(256bit)で行うか、AVX+FMA3(128bit)で行うか、で比較。2つの差は図にすると下みたいな感じ。(左:256bit, 右:128bit)

---

環境
A10-7850K (2M/4T, Core 4.4GHz @ 1.41～1.47V)
DDR3-2496, 2ch, 16GB, 11-13-13-31-2
Asrock FM2A88ITX-X+

Win7 x64
Aviutl 1.00

対象: 1280x720p, 2048フレーム

以下、1フレームあたりのPMD_MT単体の処理速度(2048フレームの平均)

PMD_MTは「修正PMD」「useExp」の2つのオプションがあるので、2x2=4通りあるのだけど、ここでは修正PMDはオンとして、useExpを「オフ」でのかかった時間を測った。

結果


AVX/FAM3の256bitとAVX/FMA3の128bitを比べると、AVX/FMA3の128bitのほうが速い。予想通り、A10-7850Kでは256bit演算を使うよりも128bit×2でそのまま演算したほうが高速なようだ。

Intel CPUにようにちゃんと256bit演算が高速であれば、256bitで計算したほうが128bitを2回するより速いはずなのだが…こうしてみるとAMDのAVX(256bit)対応は、単に「256bit演算も一応できないことはない」ということであって、それ以上の意味は無いのかな、と思う。

AMDも次世代はちゃんとシングルスレッド性能やSIMD性能を上げて欲しいけど…

---

あと、BulldozerはFMA3には非対応で、FMA4というのにしか対応していないようなので、AVX+FMA4の組み合わせも追加しておいた (確認はできないけどたぶんちゃんと動くはず)。このAVX+FMA4はFMA3/FMA4両対応となっているSteamrollerではなぜか若干遅いので(上の図にある通り)、FMA3に対応していればAVX+FMA3が優先的に動くようにしてある。

---

ダウンロード>>
ダウンロード (ミラー) >>
OneDriveの調子がいまいちの時はミラー(dropbox)からどうぞ。同じものです。

---

---

i7 4770KとA10-7850Kを同じクロックにして比較した。メモリ速度もだいたい互角。

環境1
Core i7 4770K (4C/8T, Core 4.4GHz @ 1.325V / Uncore 4.2GHz)
DDR3-2600, 2ch, 16GB, 10-12-12-31-2
Asrock Z87 Extreme4

環境2
A10-7850K (2M/4T, Core 4.4GHz @ 1.41～1.47V)
DDR3-2496, 2ch, 16GB, 11-13-13-31-2
Asrock FM2A88ITX-X+

Win7 x64
Aviutl 1.00

対象: 1280x720p, 2048フレーム

以下、1フレームあたりのPMD_MT単体の処理速度(2048フレームの平均)

PMD_MTは「修正PMD」「useExp」の2つのオプションがあるので、2x2=4通りあるのだけど、ここでは修正PMDはオンとして、useExpを「オフ」でのかかった時間を測った。

結果


useExpを「オフ」にするモードでは、重み計算 & ノイズ除去 (weight & nr)を浮動小数点演算のゴリ押しによって求めている。このため、SIMD演算の弱いBulldozer系には苦手な計算になっている。

特に、

1. 4770Kのほうが圧倒的に速い。

2. 4770KはSIMD化によって高い効果が得られるものの(x2.7倍速)、7850Kのほうはいまいち(x1.5倍速)。

3. 7850Kで、originalのgaussianH(垂直方向のガウシアンぼかし)、遅すぎ? (3.9msかかってる…)

4. 7850Kで、SSE4.1版のほうがAVX版より速い…。

ことがわかる…。

---

1と2はもう単に7850KがSIMD演算が苦手、というだけの話。同じ物理4コアとはいえ、7850KはSIMD演算器を2コアで共有しているうえに、256bit演算に対応しているものの、実際には256bitの演算器を持たず、256bit演算を実行する際には128bit演算器を2回まわしているとされている。ということは、Haswellは1コアが256bitのSIMD演算器を2個持っているのに対し、Streamrollerは2コアが128bit演算器が2個を共有している、という状態になっていて、SIMD演算に限れば圧倒的な差があることになる。これでは遅いのはもう仕方ない…

3のoriginalのgaussianHが遅いのは…なんでなのん? 謎。

4はなんでだろう、と最初は思っていたのだけど、結局7850Kが256bit演算器を持たないことが原因かもしれない。

重み計算 & ノイズ除去 (weight & nr)は整数で計算するところと浮動小数点で計算するところがある。これをAVX/FMA3を使って計算する場合、浮動小数点部分は256bitで計算可能だが、整数演算部分は128bitでしか計算できない(256bitの整数演算はAVX2が必要)。そのため、下の図のように整数部分を128bitで計算しておいて、浮動小数点演算部分になったら128bit×2を256bitに結合してから256bitで計算し、再び整数演算部に戻るときには256bitを128bit×2に分離してから計算している。IntelなCPUでは浮動小数点部を256bitで計算することで大幅に高速化できるため、結合や分離をしてでも浮動小数点部は256bitで計算したほうが速い。


↑AVXを使用し、重い浮動小数点演算部を256bit単位で計算することで浮動小数点演算回数を減らし、高速化できる

---

しかし、7850Kは256bit命令に対応しているだけで実際には256bit演算器を持たないため、256bit演算を行ったつもりでも実際には下の図のように128bitの計算が2回行われるだけで、256bit演算を行うメリットはあまりない事になってしまう。


↑256bitで計算しようとしても内部では結局128bit×2…

むしろ、結合やら分離やらに無駄に手間をかけただけに終わり、遅くなってしまっているんだろうな…と予想できる。

というわけで、そのうちこの予想を検証してなんとか7850Kでももう少し速くしてみる…(続くと思う…)

とりあえず寝る…