録画人間の末路 -

人は記録をしながらじゃないと生きていけない

FX8350のエンコード性能を低く見せるやり方

2012-12-20 23:18:23 | 意味なしレビュー
FX8350を買って以来、ずーっと解けなかった謎がようやく解明と言って良いところまで来ましたので、いまさらですがレポートします。マヤの怪しい予言が当たる前に(笑)この問題だけは解いておきたかったのですが、ギリギリ間に合いました。しつこい中身ですが、お付き合いください。自己満足度120%の記事です。

以前書きました記事、"侵略すること火の如く FX-8350の真の実力を探る"は、商用サイトで低評価しか得られないFX8350に対し「一世代前のCore i7よりはずっと高性能」と評価したことで、結構反響を呼んだように思います。
ただ、それなら商用サイトの低評価はなぜ発生したのか? あまり当てにならない定番ベンチマークソフトやチップセットの足回りがイマイチなためにヘビーゲームのfpsが悪いのは分かります。が、動画のエンコードまで遅い評価というのが、わたしには信じられませんでした。あんなに遅いわけがないんです。前回でも取り上げたこのascii.jpの記事。

VisheraことAMD「FX-8350」は低予算自作に革命を起こすか?

この記事では"AVHCD"という謎のフォーマットをデコード素材として使っていますので、同じものは用意できませんが、名前が似ているからいいだろうとAVCHDのm2tsフォーマット、67秒のものを用意して同じ条件、メモリ速度も1600に落として1passの時間を測定しました。

 91秒

リンク先の結果より28秒も早く終わってしまいます。もちろん、同じフォーマットで同じ長さでも、動画の動きなどでエンコード時間は大きく異なりますので、ascii.jpの用意したAVHCDの動画がずっと重いものだ、という可能性は十分あります。ですが、他のCPUの比較結果がわたしには非常に気になったわけです。Core i5 3570Kではありません。A10-5800Kのほうです。記事ではA10-5800Kでの結果は142秒。FX8350の119秒と近すぎるんです。経験上、FX8350とA10-5800Kのエンコード性能差はもっとあるはずです。なのでこっちで用意したAVCHD動画をA10-5800KにTVMW5を入れて測定したら

 157秒

順当な差はつきましたが、リンク先のものより遅くなってしまいました。むしろわたしの用意した動画の方が重いんじゃない?という気がしてきます。じゃぁFX8350やFX8150の遅さはどうなのか? まさかこの2つだけ不利になるようにTVMW5の設定を統一しなかったんじゃないか? と言う疑いさえ浮かべたくなりますが、さすがにそれはないだろう、と思い直しました。何か設定を変更しているのは間違いないでしょうが、FX8350やFX8150だけ遅くなってA10-5800Kはそれほど遅くならない、そんな設定があるのでしょうか? 
FX8350とA10-5800KのCPUアーキテクチャはほとんど同じ、違いはクロックが少々と、コンピュート・ユニット(CU)の数がFX8350が2倍なこと、3次キャッシュはFX側だけあること。そのうち一番影響が大きいのはCUの数で間違いないでしょう。じゃぁスレッドの数をBIOSで制限したとか? それは露骨過ぎますし、「8コアのパワーを一番使える作業」として動画エンコードを取り上げたことに嘘をつくことになります。でも、TVMW5はAviUtlと違って有効スレッドの数を変更できないし・・・。と、思っていたら、妙な項目を見つけました。TVMW5の"オプション"→"環境設定"→"マルチスレッドの設定"より、"フィルタリングをマルチスレッドで実行する"という項目です。もしやもしや。

フィルタリングと言うとノイズ除去やシャープ化が真っ先に頭に浮かびますが、圧縮ファイルをデコードするのも一種のフィルタリングです。簡単高速エンコードをうたうMediaEspressoが高速でエンコードが終了するのは、このデコードをハードウェア処理、すなわちGPUにゆだねられるのが大きいからです。TVMW5はデコードにGPUを使っていないため、CPUのパワーで行うしかありません。マルチスレッドが使えなければ大きく性能を落としてしまうAMDの現アーキテクチャ。このチェックを外してフィルタリングをシングルスレッドにしてしまえば? やってみましょう。あとは上の90秒エンコードと同じ条件にそろえます。ちなみに、同じ設定にあるキャッシュは、この程度の長さの動画だと最大1秒くらいしか効果が現れなかったのでチェック入れっぱなしにしておきました。さて、結果は

 123秒

大きくスコアを落としています。しかも、ascii.jpのデータにかなり近い結果が出てしまいました。一方、A10-5800Kではというと

 163秒

落ちてははいますが、FX8350ほど極端ではありません。全くではありませんが、ascii.jpの条件に近づきました。FX8350とA10-5800Kの数値差もかなり近いものになっています。
この結果、"フィルタリングの負担が大きくなりすぎた"のは実は大した問題ではありません。A10-5800Kのデータから見ればそれはあきらかです。もっと大きいのはx264とフィルタの同時処理のバランスが崩れたためです。前回記事でもAviUtlではFX8350はあまり性能を発揮できないことを書きました。それはAviUtlでのx264では8スレッドのうち2スレッドがあまり有効活用されていないと書いたのですが、"フィルタリングをマルチスレッドで実行する"を外した場合、x264でのエンコードがAviUtlとほぼ同じCPUの負担状況を見せたのです。やはり常時利用は6スレッド分だけ、残りは動いたり休んだりでした。どうやらx264自体が8スレッド処理が苦手だったようです。TVMW5だと8スレッドすべてが有効に見えたのは、休むスレッドを有効に使うようフィルタリング処理を割り当てていたためでしょう。PEGASYSのソフトというとIntel最適化優先という印象が強いのですが、TVMW5に限って言えばx264の処理に最適化されていたようです。だからFX8350が速かったのです。A10-5800Kでの落ち込みが少ないのは、4スレッドしか処理できないのでx264の処理速度が変わらないためと思われます。

なら、Intelはどうか。仮想Core i5として、Core i7 2600Kのハイパースレッドを無効にして、TVMW5をもう一度インストールし、同じAVCHDファイルを"フィルタリングをマルチスレッドで実行する"を無効・有効にしたケースでそれぞれ調べてみました。

有効 112秒
無効 114秒

A10-5800K以上に差の少ない結果、数字上の印象はほとんど変わらない結果になってしまい、FX8350よりも高速になりました。それでもascii.jpのCore i5 3570Kと比べるとかなり遅いですが、A10-5800Kの処理時間からみて用意した動画が重いことと、世代の古いSandyBridgeではハイパースレッドなしでは新世代のIvyBridgeより遅いということはありうるでしょう、メモリも1333ですし。ちなみにハイパースレッドを有効にしたうえだと

有効 95秒
無効 111秒

と、FX8350ほどではありませんがかなり低下し、ハイパースレッドなしとの差があまりなくなります。それだけ"フィルタリングをマルチスレッドで実行する"を切るのは8スレッド処理可能CPUを空回りさせる効果があるのです。
エンコードをマルチスレッドで行う設定を切れば大嘘つきになりますが、フィルタリングだけなら「8コアでエンコードするように設定はしている」ことに間違いはなく、かつFX8350の処理能力を大幅に低く見せることができることが分かりました、しかもあくまでCore i5と同条件で。この設定変更を行っていない、と語るにはFX8350のデータが近すぎます。これをもってFX8350をCore i5 3570Kより速い、と判断することはできません。と、いうより、もうIvyBridgeを直接使わない限り、判断材料など見つかりません。でも、ascii.jpのFX8350のエンコードデータの信憑性は限りなく低くなりました。


"フィルタリングをマルチスレッドで実行する"有効無効比較データまとめ

FX8350
有効/91秒 無効/123秒

A10-5800K
有効/157秒 無効/163秒

Core i7 2600K(HTなし)
有効/112秒 無効/114秒

Core i7 2600K(HTあり)
有効/95秒 無効/111秒


ちなみにもうひとつ、マイナビニュースでもFX8350のエンコード機能を低く評価する記事があります。

【特集】
Visheraこと「AMD FX-8350」を試す - 前編/パフォーマンス徹底検証編
17 TMPGEnc Video Mastering Works 5 V5.2.4.68


ここはもっと酷いんですよね。なにせ出力ファイルの条件が全く書いてませんから。これならなんとでもできます。素材として使うことにこだわっているWMV9HDはエンコードの素材としてはAVCHD以上に重いため、簡単な処理ほど高速になるAMDアーキテクチャだとIntelに対する優位性が大幅に低減されてしまいます。ちなみにわたしがもっぱら素材として使うMPEG2は今となっては単純な部類に入るフォーマットなためにFX8350が有利になります。そのWMVを使い、エンコード先をFX8350ではトロくなることが分かりきっているDivXにでもすれば、FX8350を簡単にへっぽこCPUにすることができます。次ページのMainConcept Referenceは使ったことないのでよく分かりませんが、HDV720pではCore i5 3570KがCore i7 3770Kより速いところを見ると8スレッドが有効に使われていない可能性が濃厚です。もちろんその点はまーったく触れられてませんけどね。

まぁある意味すっきりしました。仮定の域は出てませんけどね。

AMD CPU FXシリーズ FX-8350 FD8350FRHKBOX
AMD
AMD

他の用途はともかく、MPEG2→H.264エンコードなら自信を持ってお勧めできます。
『コンピューター機器』 ジャンルのランキング
コメント (11)   この記事についてブログを書く
この記事をはてなブックマークに追加
« プラズマテレビの開発終了か... | トップ | 蔵が建つ、とはよく言ったものだ »

11 コメント

コメント日が  古い順  |   新しい順
Unknown (Unknown)
2012-12-21 00:23:03
デコードはマルチスレッドで行われているようです。根拠:タスクマネージャーで見ていてオンオフで大きくスレッド数が変わらない。
ただ、このへんはペガシスに問い合わせれば教えてくれるんじゃないかなぁ、とは思います。
Unknown (kazu)
2012-12-21 01:16:53
おもしろいですね。今のエンコードマシンはphenomでH264のみなのでマルチスレッドをわざわざ外すという環境を思いつきませんでした。
もちろん、実際のところは各レビュワーにしかわからないところで、cpu負荷状態も添付してくれると多少は判断材料になって良いのでしょうが…。

たぶん、負荷の軽いデコードと重いエンコードの割り当てのバランスで、エンコード待ちをどう扱うかの違いなのでは。
Unknown (Unknown)
2012-12-21 23:20:04
設定によってパフォーマンスが変わるのなら、確かに無意識に(あるいは作為的に)不利な設定で計測されてしまうこともあるでしょうね。
でも、FXのイメージアップに取り組むべきはAMD自身なのですから、AMDが「こういう設定で使ってね」と具体的に提示しないとまずいのではないかと思います。
AMDの広報は、今のところそういう方面で十分に機能しているようには見えません。
TrinityのVCEにしても、ほかならぬAMDが積極的に売り込まないと、埋もれてしまっても仕方ないでしょうし。
Unknown (krmmk3)
2012-12-22 00:48:50
>2012-12-21 00:23:03さん
エンコード時のマルチスレッドまで全部切ってみると、負担が大きいのは3コア分くらいになりますね。ただ、並列処理はしていなくともそれぞれの処理を別スレッドで行っている可能性はあります。
まぁ記事内に書きましたとおり、もっとも大きいのはx264のフィルタとの最適化を無効化されることですからね、あまりこだわってもしょうがないです。

>kazuさん
普通は思いつかないです、というより物理的にマルチなCPUを使っているのですからまず外さないです。ちゃんと設定すれば、うまく振り分けてくれ、ほぼ常時8スレッド使いっぱなしで速く終わらせてくれますから。
わたしは、ぜひ同じ設定でCore i7 3770Kの出力結果も掲載して欲しかったですね。3570Kとほとんど変わらないのなら設定間違えている証拠になりますから。

>2012-12-21 23:20:04さん
さすがに意図的にやったとは思いたくないです。
一応AMDもイベントなどで指標はだしているんですが、CPUメーカーが直接やると「自社製品が有利になるようなソフトのみ使っているんだろ」とかんぐられてしまいますから。「使ってくれればウチのよさも分かる」ってことでブロガー向けイベントが積極的に行われているんでしょう。ただ、参加者の大半はもともとAMDの良さが分かっている人ばかりでしょうけど。
VCEに関してはおっしゃるとおりです。せめてavivoのときのように無料の純正ソフトを用意して欲しいものです。AMD自身もまだVCEの機能を全部引き出すことができないのかも知れません。
Unknown (papyrus21)
2013-01-06 13:11:26
前のFX-8350の記事とあわせて読ませていただきました。
検証ありがとうございます。私もTVMW5ユーザーで1055Tを使っています。これを見るまでFXシリーズにまったく興味がなく、Haswel待ちだったのですが考えが変わりました。今にもFX-8350をポチりそうな勢いです。
それにしてもasciiの記事は何か意図を感じますね。
asciiの記事を見たエンコユーザーはFXをごみだと考えてしまいます。
Unknown (krmmk3)
2013-01-06 21:23:44
>papyrus21さん
商業サイトのFXの評価がひどすぎますからね。あれでは売れません。真実ならともかく必ずしもそうとは思えなかった~それまで使っていたFX8120の手ごたえから、あそこまで能力が低いとは思えなかったので、自分で検証してみました。
1055TからFX8350ならエンコードは間違いなく大幅にアップします。TDPが気になる場合は、性能が2600K並に落ちますが、FX8300も有力な選択肢になるかと思います。
asciiのライター、同じデータを別の文章でウィークリーアスキーにも書いてますからね。マイナビと合わせて確かにゴミにしか見えなくなってしまいます。わたしの検証内容と同じことをやった証拠はないので、意図的かただのトンチキかは謎です。
Unknown (papyrus21)
2013-01-09 19:04:57
結局我慢できずにFX-8350を購入しました。
1055Tで1時間41分かかっていたエンコードが67分で終了。単位時間当たりの消費電力増と処理時間短縮を考えるとトータルでは消費電力が下がることになりそうです。
ありがとうございました。
Unknown (krmmk3)
2013-01-09 22:14:38
>papyrus21さん
買いましたか。満足していただけたようで、うれしいです。
PhenomIIx6の半分以下の処理時間で終わるとは、やはり速いですね。Core i7もいいですけど、CPUの値段の高さやマザーボードも買って交換しなければならないなどお金と手間がかかりますからね。AMD環境を持っているのなら、FX-8350やその系統が一番ですよ。
Unknown (Unknown)
2013-03-12 19:11:10
 そもそもアスキーは、A-Series Trinityでも不正行為を行った嫌疑が間違いなくあります。何故かと言えば、AMDがA-Series APUを出す最も重要な理由として、Open CLに対応したアプリ(例えばAdobe Premere、PhotoShopなど。AMDのサイトを参照のこと)であれば、GPU支援で高速化できるという事があります:事実以前の週アスで、笠原一輝氏がIntelとも合わせてGPU支援による効果を証明。しかしわざとそれに対応していないアプリを使い、「GPU支援をしても速度が上がらない」ように見せかけたと考えられます。つまり、事実上はアスキーがIntelのステマ行為を行ったという事であり、客観性と中立性が要求される批評紙としての価値を、失ったとさえ言えるでしょう。ちなみにX86環境のソフト開発では、既にCPUだけによる高速化は限界らしく、それでGPU支援による高速化が進められています。事実ここ最近では、NVIDIAのGPUも含めて、画像関係全般でGPU支援による高速化対応が半ば常識化しているようです。
Unknown (Unknown)
2013-03-12 19:33:16
 追記ですが済みません、Premiereでした。
 尚、価格.comではIntelのIvy-Bridgeについて、「Sandy-Bridgeから買い換える必要がある程には体感速度が上がっていない」と言う意見がありましたが、この事からしても、たとえベンチマークではIvy-BridgeのほうがSandy-Bridgeより性能が上がっているとしても、X86環境では既に高速化が限界のために変化がない、とも言えるのではないでしょうか。それは大方のところHuswellでも同様でしょう。その意味では、いくらIntelがCPU性能を高めても、意味がなくなる時代が近づいてきた、とも言えるかも知れません。筆者はOpen CL対応アプリで高速化したいため、主力機をAPUに換えると思いますが。ちなみにロシアのオーバークロッカーによれば、Ivy-BridgeとHuswellではそこまで差が出なかったそうです(当然ながらSandy-BridgeとHuswellでも差がない?)。
Unknown (krmmk3)
2013-03-12 23:52:51
>2013-03-12 19:11:10さん
わたしはTrinityのブロガー勉強会に参加したのですが、その時AMDの方は大変熱心にOPEN CLについて語っていました。AMDがAPUを押す最大の理由はOPEN CLへの最適化であると。にも拘わらず、アスキーに限らず商業系情報サイトや雑誌は見事OPEN CLに一切触れることなく、「安価なゲーム用」以外の定義をせずに簡単なベンチマークテストだけで評価してましたね。
手抜き、Intelの政治力や柵などあるでしょうが、従来の基準の評価以外は行わないというのは、OPEN CLやソフトウェアのマルチスレッド化を推進するためにCPU構造をユニット化に進むAMDだけではなく、CPU周辺のSoC化を推し進めるために自前GPUの強化やより省電力を図るIntelにとっても不幸な話です。おっしゃるとおり、x86x64系の単純強化はもう意味がないところまで来ているので、両メーカーとも異なる新たな道を狙っているのですから。
それでも、AMDに言わせれば「AMD新製品はけなす、が常識化しているPC情報界の中で、Trinityは比較的良好な扱いをしてもらえた」らしいですよ。

コメントを投稿


コメント利用規約に同意の上コメント投稿を行ってください。

数字4桁を入力し、投稿ボタンを押してください。

あわせて読む

トラックバック

この記事のトラックバック  Ping-URL
ブログ作成者から承認されるまでトラックバックは反映されません。