アカウント名:
パスワード:
リンク先を読む限りでは…「8コア分の負荷を掛けたら8コア全体に負荷が掛かるのか」と言う点が争点になりそうですね。2コアのはずなのに1コア分しか負荷が掛からない、と言う訴えなので。
ただ、そこらへんはアプリやOSのスケジューラーの作りこみ次第なのでAMDが作り込んだアプリで8コアに均等に負荷が掛かってしまえば誇大広告ではないと言う結論に達してしまいそうですが…。
AMD Bulldozer の実装は、「CPUが100%頑張ってるときでも、浮動小数点ユニットの稼働率はあんまり高くない」ので、「じゃあ、複数のCPUコアが浮動小数点ユニットを共有すれば、ハードウェア削減できる」ってアイデアですよね。
だから、「浮動小数点ユニットの稼働率が高くない」プログラムを動かす分には、ちゃんと8コアっぽく動いてくれますが、「浮動小数点ユニットを酷使する」ようなプログラムだと4コアっぽくなってしまいます。
で、問題は「SSEも浮動小数点ユニットを使って処理する」という点。性能評価に使われるような、動画エンコードなどといったCPU
FPUだけならまだしも、ボトルネックになりやすいL1命令キャッシュとデコーダも共有してます。これが無ければ、詐欺なんて言われないと思うのですが。
デコーダーは共有するかわりに強化されてます。それまでのK8が3命令同時デコード、整数演算パイプ3本だったのに対し、Bulldozerは4命令同時デコードで、整数演算パイプが各モジュール2本の合計4本
というわけで、整数演算のALU数が減ってるのもあって、デコーダーはそうそうボトルネックにならないはずです。
結局のところ、整数演算主体な普通のアプリでは、「1スレッドでのクロックあたりのピーク処理性能は2/3に減る」代わりに、「同時実行可能なスレッド数は2倍に増える」ので、「トータルで1.3倍に高速化できる」って目論見だった(しかも、実際のアプリだと、「3本のALUをそうそう酷使でてないので、1スレッドの実効性能は2/3も落ちない」から、もうちょっと高速化が期待できる)のに、マーケティングの悪さもあってか、「トータルで2倍の高速化」を期待して「期待より遅い!」と文句が出てた感じですかね。
「サーバーに使うと強い」ような性格のCPUなのに、コンシューマーでの「ゲームや動画エンコードなどの、Bulldozerの苦手なアプリ」で評価されちゃったのが不幸ってことで。
重要な点を忘れているか、無視している?整数演算主体な、かつマルチスレッド効率が非常に高い希有なアプリでは、トータルで1.3倍になります。しかし、整数演算主体な、かつマルチスレッド効率低い普通のアプリでは、トータルで1倍以下になります。普通の人が4スレッド以上を常に占有できるようなアプリが、動画エンコードぐらいしか無い。なのにその動画エンコードで使うSSE/AVXが弱いってのが悲しいところ。
サーバで使うと強いといったって、8スレッドフルに回せる用途だとコストの安さを電力効率の悪さが消してしまう。この用途でも、普通はIntelのCPUを選ぶというのはシェアの差が証明しているでしょう。電力効率さえもう少し良ければ、Webサーバ用途での可能性はあったと思うのですけどね。
Bulldozerの性能が低いとか電力効率が悪いとかいうのは、「Bulldozerは8コアという主張は詐欺か?」「デコーダーがボトルネックになるからデコーダー共有なら詐欺だ」という、このスレッドの流れとは無関係です。
でまあ、「整数演算主体な、かつマルチスレッド効率低い普通のアプリ」に対して、Bulldozer は高クロック化で対応する、という方針でしたね。電力効率については、設計思想としてはかなり高くなるはずでした。最初の発表段階では、それを売りにしてたぐらいで。
結局のところ、設計思想としては悪くなかったのですが、実装が追いついてなかったのと、ユーザーニーズを見誤ったのが失敗点なんですかね。。
私はプロセスの選択と製造技術の点でIntelに負けたのが失敗だったのだと思います。Intelのプロセスで作れば、勝負になる性能を出せたでしょう。こと高性能CPU向けに関しては、世界中のCPUメーカーが製造技術で負けてるから、Intelの一人勝ちなわけですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
負荷が問題? (スコア:1)
リンク先を読む限りでは…
「8コア分の負荷を掛けたら8コア全体に負荷が掛かるのか」
と言う点が争点になりそうですね。
2コアのはずなのに1コア分しか負荷が掛からない、と言う訴えなので。
ただ、そこらへんはアプリやOSのスケジューラーの作りこみ次第なので
AMDが作り込んだアプリで8コアに均等に負荷が掛かってしまえば
誇大広告ではないと言う結論に達してしまいそうですが…。
Re: (スコア:5, 参考になる)
AMD Bulldozer の実装は、
「CPUが100%頑張ってるときでも、浮動小数点ユニットの稼働率はあんまり高くない」ので、
「じゃあ、複数のCPUコアが浮動小数点ユニットを共有すれば、ハードウェア削減できる」ってアイデアですよね。
だから、「浮動小数点ユニットの稼働率が高くない」プログラムを動かす分には、ちゃんと8コアっぽく動いてくれますが、
「浮動小数点ユニットを酷使する」ようなプログラムだと4コアっぽくなってしまいます。
で、問題は「SSEも浮動小数点ユニットを使って処理する」という点。
性能評価に使われるような、動画エンコードなどといったCPU
Re:負荷が問題? (スコア:0)
FPUだけならまだしも、ボトルネックになりやすいL1命令キャッシュとデコーダも共有してます。
これが無ければ、詐欺なんて言われないと思うのですが。
Re:負荷が問題? (スコア:2)
デコーダーは共有するかわりに強化されてます。
それまでのK8が3命令同時デコード、整数演算パイプ3本だったのに対し、
Bulldozerは4命令同時デコードで、整数演算パイプが各モジュール2本の合計4本
というわけで、整数演算のALU数が減ってるのもあって、
デコーダーはそうそうボトルネックにならないはずです。
結局のところ、整数演算主体な普通のアプリでは、
「1スレッドでのクロックあたりのピーク処理性能は2/3に減る」代わりに、
「同時実行可能なスレッド数は2倍に増える」ので、「トータルで1.3倍に高速化できる」
って目論見だった(しかも、実際のアプリだと、「3本のALUをそうそう酷使でてないので、1スレッドの実効性能は2/3も落ちない」から、もうちょっと高速化が期待できる)のに、
マーケティングの悪さもあってか、「トータルで2倍の高速化」を期待して「期待より遅い!」と文句が出てた感じですかね。
「サーバーに使うと強い」ような性格のCPUなのに、コンシューマーでの「ゲームや動画エンコードなどの、Bulldozerの苦手なアプリ」で評価されちゃったのが不幸ってことで。
Re: (スコア:0)
重要な点を忘れているか、無視している?
整数演算主体な、かつマルチスレッド効率が非常に高い希有なアプリでは、トータルで1.3倍になります。
しかし、整数演算主体な、かつマルチスレッド効率低い普通のアプリでは、トータルで1倍以下になります。
普通の人が4スレッド以上を常に占有できるようなアプリが、動画エンコードぐらいしか無い。
なのにその動画エンコードで使うSSE/AVXが弱いってのが悲しいところ。
サーバで使うと強いといったって、8スレッドフルに回せる用途だとコストの安さを電力効率の悪さが消してしまう。この用途でも、普通はIntelのCPUを選ぶというのはシェアの差が証明しているでしょう。
電力効率さえもう少し良ければ、Webサーバ用途での可能性はあったと思うのですけどね。
Re:負荷が問題? (スコア:2)
Bulldozerの性能が低いとか電力効率が悪いとかいうのは、
「Bulldozerは8コアという主張は詐欺か?」「デコーダーがボトルネックになるからデコーダー共有なら詐欺だ」という、このスレッドの流れとは無関係です。
でまあ、「整数演算主体な、かつマルチスレッド効率低い普通のアプリ」に対して、Bulldozer は高クロック化で対応する、という方針でしたね。
電力効率については、設計思想としてはかなり高くなるはずでした。最初の発表段階では、それを売りにしてたぐらいで。
結局のところ、設計思想としては悪くなかったのですが、実装が追いついてなかったのと、ユーザーニーズを見誤ったのが失敗点なんですかね。。
Re: (スコア:0)
私はプロセスの選択と製造技術の点でIntelに負けたのが失敗だったのだと思います。
Intelのプロセスで作れば、勝負になる性能を出せたでしょう。
こと高性能CPU向けに関しては、世界中のCPUメーカーが製造技術で負けてるから、Intelの一人勝ちなわけですが。
Re: (スコア:0)