FX8350を買って以来、ずーっと解けなかった謎がようやく解明と言って良いところまで来ましたので、いまさらですがレポートします。マヤの怪しい予言が当たる前に(笑)この問題だけは解いておきたかったのですが、ギリギリ間に合いました。しつこい中身ですが、お付き合いください。自己満足度１２０％の記事です。
以前書きました記事、"侵略すること火の如く 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の遅さはどうなのか？ まさかこの２つだけ不利になるようにTVMW5の設定を統一しなかったんじゃないか？ と言う疑いさえ浮かべたくなりますが、さすがにそれはないだろう、と思い直しました。何か設定を変更しているのは間違いないでしょうが、FX8350やFX8150だけ遅くなってA10-5800Kはそれほど遅くならない、そんな設定があるのでしょうか？
FX8350とA10-5800KのCPUアーキテクチャはほとんど同じ、違いはクロックが少々と、コンピュート・ユニット(CU)の数がFX8350が2倍なこと、３次キャッシュはFX側だけあること。そのうち一番影響が大きいのはCUの数で間違いないでしょう。じゃぁスレッドの数をBIOSで制限したとか？ それは露骨過ぎますし、「8コアのパワーを一番使える作業」として動画エンコードを取り上げたことに嘘をつくことになります。でも、TVMW5はAviUtlと違って有効スレッドの数を変更できないし・・・。と、思っていたら、妙な項目を見つけました。TVMW5の"オプション"→"環境設定"→"マルチスレッドの設定"より、"フィルタリングをマルチスレッドで実行する"という項目です。もしやもしや。
フィルタリングと言うとノイズ除去やシャープ化が真っ先に頭に浮かびますが、圧縮ファイルをデコードするのも一種のフィルタリングです。簡単高速エンコードをうたうMediaEspressoが高速でエンコードが終了するのは、このデコードをハードウェア処理、すなわちGPUにゆだねられるのが大きいからです。TVMW5はデコードにGPUを使っていないため、CPUのパワーで行うしかありません。マルチスレッドが使えなければ大きく性能を落としてしまうAMDの現アーキテクチャ。このチェックを外してフィルタリングをシングルスレッドにしてしまえば？ やってみましょう。あとは上の90秒エンコードと同じ条件にそろえます。ちなみに、同じ設定にあるキャッシュは、この程度の長さの動画だと最大１秒くらいしか効果が現れなかったのでチェック入れっぱなしにしておきました。さて、結果は
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スレッドが有効に使われていない可能性が濃厚です。もちろんその点はまーったく触れられてませんけどね。
まぁある意味すっきりしました。仮定の域は出てませんけどね。
他の用途はともかく、MPEG2→H.264エンコードなら自信を持ってお勧めできます。
以前書きました記事、"侵略すること火の如く 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の遅さはどうなのか？ まさかこの２つだけ不利になるようにTVMW5の設定を統一しなかったんじゃないか？ と言う疑いさえ浮かべたくなりますが、さすがにそれはないだろう、と思い直しました。何か設定を変更しているのは間違いないでしょうが、FX8350やFX8150だけ遅くなってA10-5800Kはそれほど遅くならない、そんな設定があるのでしょうか？
FX8350とA10-5800KのCPUアーキテクチャはほとんど同じ、違いはクロックが少々と、コンピュート・ユニット(CU)の数がFX8350が2倍なこと、３次キャッシュはFX側だけあること。そのうち一番影響が大きいのはCUの数で間違いないでしょう。じゃぁスレッドの数をBIOSで制限したとか？ それは露骨過ぎますし、「8コアのパワーを一番使える作業」として動画エンコードを取り上げたことに嘘をつくことになります。でも、TVMW5はAviUtlと違って有効スレッドの数を変更できないし・・・。と、思っていたら、妙な項目を見つけました。TVMW5の"オプション"→"環境設定"→"マルチスレッドの設定"より、"フィルタリングをマルチスレッドで実行する"という項目です。もしやもしや。
フィルタリングと言うとノイズ除去やシャープ化が真っ先に頭に浮かびますが、圧縮ファイルをデコードするのも一種のフィルタリングです。簡単高速エンコードをうたうMediaEspressoが高速でエンコードが終了するのは、このデコードをハードウェア処理、すなわちGPUにゆだねられるのが大きいからです。TVMW5はデコードにGPUを使っていないため、CPUのパワーで行うしかありません。マルチスレッドが使えなければ大きく性能を落としてしまうAMDの現アーキテクチャ。このチェックを外してフィルタリングをシングルスレッドにしてしまえば？ やってみましょう。あとは上の90秒エンコードと同じ条件にそろえます。ちなみに、同じ設定にあるキャッシュは、この程度の長さの動画だと最大１秒くらいしか効果が現れなかったのでチェック入れっぱなしにしておきました。さて、結果は
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エンコードなら自信を持ってお勧めできます。
アクセス
トータル
ランキング
ただ、このへんはペガシスに問い合わせれば教えてくれるんじゃないかなぁ、とは思います。
もちろん、実際のところは各レビュワーにしかわからないところで、cpu負荷状態も添付してくれると多少は判断材料になって良いのでしょうが…。
たぶん、負荷の軽いデコードと重いエンコードの割り当てのバランスで、エンコード待ちをどう扱うかの違いなのでは。
でも、FXのイメージアップに取り組むべきはAMD自身なのですから、AMDが「こういう設定で使ってね」と具体的に提示しないとまずいのではないかと思います。
AMDの広報は、今のところそういう方面で十分に機能しているようには見えません。
TrinityのVCEにしても、ほかならぬAMDが積極的に売り込まないと、埋もれてしまっても仕方ないでしょうし。
エンコード時のマルチスレッドまで全部切ってみると、負担が大きいのは3コア分くらいになりますね。ただ、並列処理はしていなくともそれぞれの処理を別スレッドで行っている可能性はあります。
まぁ記事内に書きましたとおり、もっとも大きいのはx264のフィルタとの最適化を無効化されることですからね、あまりこだわってもしょうがないです。
>kazuさん
普通は思いつかないです、というより物理的にマルチなCPUを使っているのですからまず外さないです。ちゃんと設定すれば、うまく振り分けてくれ、ほぼ常時8スレッド使いっぱなしで速く終わらせてくれますから。
わたしは、ぜひ同じ設定でCore i7 3770Kの出力結果も掲載して欲しかったですね。3570Kとほとんど変わらないのなら設定間違えている証拠になりますから。
>2012-12-21 23:20:04さん
さすがに意図的にやったとは思いたくないです。
一応AMDもイベントなどで指標はだしているんですが、CPUメーカーが直接やると「自社製品が有利になるようなソフトのみ使っているんだろ」とかんぐられてしまいますから。「使ってくれればウチのよさも分かる」ってことでブロガー向けイベントが積極的に行われているんでしょう。ただ、参加者の大半はもともとAMDの良さが分かっている人ばかりでしょうけど。
VCEに関してはおっしゃるとおりです。せめてavivoのときのように無料の純正ソフトを用意して欲しいものです。AMD自身もまだVCEの機能を全部引き出すことができないのかも知れません。
検証ありがとうございます。私もTVMW5ユーザーで1055Tを使っています。これを見るまでFXシリーズにまったく興味がなく、Haswel待ちだったのですが考えが変わりました。今にもFX-8350をポチりそうな勢いです。
それにしてもasciiの記事は何か意図を感じますね。
asciiの記事を見たエンコユーザーはFXをごみだと考えてしまいます。
商業サイトのFXの評価がひどすぎますからね。あれでは売れません。真実ならともかく必ずしもそうとは思えなかった～それまで使っていたFX8120の手ごたえから、あそこまで能力が低いとは思えなかったので、自分で検証してみました。
1055TからFX8350ならエンコードは間違いなく大幅にアップします。TDPが気になる場合は、性能が2600K並に落ちますが、FX8300も有力な選択肢になるかと思います。
asciiのライター、同じデータを別の文章でウィークリーアスキーにも書いてますからね。マイナビと合わせて確かにゴミにしか見えなくなってしまいます。わたしの検証内容と同じことをやった証拠はないので、意図的かただのトンチキかは謎です。
1055Tで1時間41分かかっていたエンコードが67分で終了。単位時間当たりの消費電力増と処理時間短縮を考えるとトータルでは消費電力が下がることになりそうです。
ありがとうございました。
買いましたか。満足していただけたようで、うれしいです。
PhenomIIx6の半分以下の処理時間で終わるとは、やはり速いですね。Core i7もいいですけど、CPUの値段の高さやマザーボードも買って交換しなければならないなどお金と手間がかかりますからね。AMD環境を持っているのなら、FX-8350やその系統が一番ですよ。
尚、価格.comではIntelのIvy-Bridgeについて、「Sandy-Bridgeから買い換える必要がある程には体感速度が上がっていない」と言う意見がありましたが、この事からしても、たとえベンチマークではIvy-BridgeのほうがSandy-Bridgeより性能が上がっているとしても、X86環境では既に高速化が限界のために変化がない、とも言えるのではないでしょうか。それは大方のところHuswellでも同様でしょう。その意味では、いくらIntelがＣＰＵ性能を高めても、意味がなくなる時代が近づいてきた、とも言えるかも知れません。筆者はOpen CL対応アプリで高速化したいため、主力機をＡＰＵに換えると思いますが。ちなみにロシアのオーバークロッカーによれば、Ivy-BridgeとHuswellではそこまで差が出なかったそうです（当然ながらSandy-BridgeとHuswellでも差がない？）。