Intel派がAMDの次世代CPUを語るスレ 1
バックアッププランって普通、メインの予定が崩れたから出てくるんじゃないの？
>>930の言ってることだとLarrabee統合がメインプランで、それが崩れたから、
HaswellがSandy改良＋普通のGPU統合のバックアッププランになったの方が
意味が通じるんだけど。
>>930の言ってることだとLarrabee統合がメインプランで、それが崩れたから、
HaswellがSandy改良＋普通のGPU統合のバックアッププランになったの方が
意味が通じるんだけど。
933 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 09:42:12.92 ID:o5GMnakW
コプロとしてダイ上に併設するってのとCPUコア組み込みのSIMD機能として追加するってのは
全く意味が違うんだが。支離滅裂にも程がある。
全く意味が違うんだが。支離滅裂にも程がある。
淫虫はコプロを否定してたよねｗ
ビデオカード（笑）の話はスレチですよ
＞淫虫はコプロを否定してたよねｗ
AMDのVLIWじゃコプロに成りえないじゃん遅すぎて
同規模でスレッド数20%あがるはずのcaymanがcypressにf@hで負けるのはどういうことなんだろうね
shaderは単に簡略化してTMUの数を増やしただけで終わったのがcayman
AMDのVLIWじゃコプロに成りえないじゃん遅すぎて
同規模でスレッド数20%あがるはずのcaymanがcypressにf@hで負けるのはどういうことなんだろうね
shaderは単に簡略化してTMUの数を増やしただけで終わったのがcayman
AMDのAPUも今のところCPUとGPUを1チップにしましたってだけだからな。
GPGPUの活用はユーザーが各自努力してくださいだし。
その先は、青写真もあるか怪しい状態だけど。
GPGPUの活用はユーザーが各自努力してくださいだし。
その先は、青写真もあるか怪しい状態だけど。
caymanは32nmがキャンセルされた影響で、5xxxをベースに、32nmで予定していた機能の一部
を載せたものだから、イマイチなのは仕方が無いだろう
28nmが出る前にソフトメーカーにVLIEW4に馴染んでもらうための布石といったところか
ちなみにGPGPUをコプロとして使って速度が出ないのは当然だ
PCにおけるGPGPUはGPUが使われて無いときに遊んでいるリソースを回収するためのもの
HPCにおけるGPGPUはまた別だが
を載せたものだから、イマイチなのは仕方が無いだろう
28nmが出る前にソフトメーカーにVLIEW4に馴染んでもらうための布石といったところか
ちなみにGPGPUをコプロとして使って速度が出ないのは当然だ
PCにおけるGPGPUはGPUが使われて無いときに遊んでいるリソースを回収するためのもの
HPCにおけるGPGPUはまた別だが
単にドライバの成熟度の違いだな
SP構成を弄って既存のアプリが影響受けないわけがない
今の段階でもGPGPUアプリじゃCypress比で下がってるのもあれば上がってるのもある
SP構成を弄って既存のアプリが影響受けないわけがない
今の段階でもGPGPUアプリじゃCypress比で下がってるのもあれば上がってるのもある
SSEやAVXの経験あるからRadeonのSIMD化は可能だろ
単に回路の簡略化のためVLIW>SIMDって判断してるだけ
そういえば団子って以前Larrabeeの512bit SIMDがAVXの次世代って息巻いて絶賛してたよな
いつの間にAVXの512bitや1024bitなんてものに宗旨替えしたんだ？
そもそもそれがホントならLarrabee統合に意味は全く無いだろ
単に回路の簡略化のためVLIW>SIMDって判断してるだけ
そういえば団子って以前Larrabeeの512bit SIMDがAVXの次世代って息巻いて絶賛してたよな
いつの間にAVXの512bitや1024bitなんてものに宗旨替えしたんだ？
そもそもそれがホントならLarrabee統合に意味は全く無いだろ
RadeonをSIMD化するってどういう意味？
たとえばVLIW4を128bitSIMDにするとか？
たとえばVLIW4を128bitSIMDにするとか？
サーバー向けはともかく
一般向けにsimdコプロは不要
アクセラレータがあればよい
一般向けにsimdコプロは不要
アクセラレータがあればよい
>単に回路の簡略化のためVLIW>SIMDって判断してるだけ
その分リアルタイムでコンパイルしVLIWを発行する負荷がCPUに増える
その分リアルタイムでコンパイルしVLIWを発行する負荷がCPUに増える
>>942
そんな感じ
ただし制御回路とかくっつける必要があるから回路規模というかダイサイズが倍位になる
ゲフォは倍速化使ってサイズを半分にしてるから小さい(大きいけどな)
VLIWだからデコードやスケジューリングをCPUが受け持ってるけど、
CPUとGPU、メインメモリとGPUメモリが物理的に離れていてレイテンシが大きいし、
転送速度も遅くて効率が非常に悪い
そんな感じ
ただし制御回路とかくっつける必要があるから回路規模というかダイサイズが倍位になる
ゲフォは倍速化使ってサイズを半分にしてるから小さい(大きいけどな)
VLIWだからデコードやスケジューリングをCPUが受け持ってるけど、
CPUとGPU、メインメモリとGPUメモリが物理的に離れていてレイテンシが大きいし、
転送速度も遅くて効率が非常に悪い
946 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 19:14:27.47 ID:o5GMnakW
> そういえば団子って以前Larrabeeの512bit SIMDがAVXの次世代って息巻いて絶賛してたよな
それ言ったのは後藤だっつーのｗ
> いつの間にAVXの512bitや1024bitなんてものに宗旨替えしたんだ？
もちろんIntelがAVXと別物と言った時点で
> そもそもそれがホントならLarrabee統合に意味は全く無いだろ
逆に言えば統合しなくともCPUコアのSIMD拡張計画には全く支障は無いということね。
CPUコアにSIMD機能を統合するのか単にダイ上にコアを載せるのか
お前の想定してるのはどっちだよ。話が進んでるとすれば後者のほうだ。
それ言ったのは後藤だっつーのｗ
> いつの間にAVXの512bitや1024bitなんてものに宗旨替えしたんだ？
もちろんIntelがAVXと別物と言った時点で
> そもそもそれがホントならLarrabee統合に意味は全く無いだろ
逆に言えば統合しなくともCPUコアのSIMD拡張計画には全く支障は無いということね。
CPUコアにSIMD機能を統合するのか単にダイ上にコアを載せるのか
お前の想定してるのはどっちだよ。話が進んでるとすれば後者のほうだ。
947 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 19:23:52.27 ID:o5GMnakW
IntelがSIMD拡張を率先してやるとAMDのファンボーイがそれを貶す
でもAMDはIntelについていく。
そのパターンの繰り返しいい加減飽きたよ
でもAMDはIntelについていく。
そのパターンの繰り返しいい加減飽きたよ
>>946
> > そういえば団子って以前Larrabeeの512bit SIMDがAVXの次世代って息巻いて絶賛してたよな
> それ言ったのは後藤だっつーのｗ
ほうほう
271 名前：,,・´∀｀・,,）っ[sage] 投稿日：2008/08/22(金) 03:46:06 ID:6R6YXCRn
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
Ctについては>>182あたりに書いたことがドンピシャ。
Larrabee新命令はどうやら既存命令とはOpcode食い合わないらしい
（＝512ビット版AVXそのものの先行実装の可能性大）
Larrabeeの位置づけといい、俺どれだけエスパーだよ
あまりに予想が当たりすぎててもう笑うしかねー
639 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/10/29(水) 08:00:59 ID:PL3EJ2gj [2/2]
（略）
ごめんね、実はAVXまでは既に対応出来てるんだ
Larrabeeはこれを512ビットに引き延ばすだけでいけると思うんだ
868 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/11/21(金) 01:36:03 ID:IoVgtMoH [1/2]
AVXに関しては、整数512-bit/浮動小数1024-bitまでの拡張計画打ち出してるから
まさに512-bit/1024-bitがLarrabeeのそれなんじゃないの？
（略）
> > そういえば団子って以前Larrabeeの512bit SIMDがAVXの次世代って息巻いて絶賛してたよな
> それ言ったのは後藤だっつーのｗ
ほうほう
271 名前：,,・´∀｀・,,）っ[sage] 投稿日：2008/08/22(金) 03:46:06 ID:6R6YXCRn
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
Ctについては>>182あたりに書いたことがドンピシャ。
Larrabee新命令はどうやら既存命令とはOpcode食い合わないらしい
（＝512ビット版AVXそのものの先行実装の可能性大）
Larrabeeの位置づけといい、俺どれだけエスパーだよ
あまりに予想が当たりすぎててもう笑うしかねー
639 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/10/29(水) 08:00:59 ID:PL3EJ2gj [2/2]
（略）
ごめんね、実はAVXまでは既に対応出来てるんだ
Larrabeeはこれを512ビットに引き延ばすだけでいけると思うんだ
868 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/11/21(金) 01:36:03 ID:IoVgtMoH [1/2]
AVXに関しては、整数512-bit/浮動小数1024-bitまでの拡張計画打ち出してるから
まさに512-bit/1024-bitがLarrabeeのそれなんじゃないの？
（略）
こんなんもあったわ
どう見ても息巻いて……なんでもないよ
170 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/10/15(水) 00:08:21 ID:ucUcLpmM [1/15]
>>169
継承するコード資産は高級言語でいいじゃん。最適化なんてIntelコンパイラに任せておけよ。
Cellが何が駄目って、2005年の電撃的な発表以来、未だにIBM謹製のXL C/C++が「開発版」なんだぜ。
その意味じゃIntelは使い古したアーキテクチャの拡張故に地に足がついてる。
ちなみにLarrabeeはIntelの将来のCPUで搭載される命令を先行実装してるって言う意味では
過去の資産よりは「未来への資産」を重視してる。
AVXの更に先の世代ではLarrabeeのSIMD拡張は普通のCPUに搭載されることになる。
（略）
どう見ても息巻いて……なんでもないよ
170 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2008/10/15(水) 00:08:21 ID:ucUcLpmM [1/15]
>>169
継承するコード資産は高級言語でいいじゃん。最適化なんてIntelコンパイラに任せておけよ。
Cellが何が駄目って、2005年の電撃的な発表以来、未だにIBM謹製のXL C/C++が「開発版」なんだぜ。
その意味じゃIntelは使い古したアーキテクチャの拡張故に地に足がついてる。
ちなみにLarrabeeはIntelの将来のCPUで搭載される命令を先行実装してるって言う意味では
過去の資産よりは「未来への資産」を重視してる。
AVXの更に先の世代ではLarrabeeのSIMD拡張は普通のCPUに搭載されることになる。
（略）
LNIの仕様が出る前、出た後で変わったんじゃないの？
一時期、サイトの方でLNIをVEXフォーマットで表現できないか考察してたと思うけど。
一時期、サイトの方でLNIをVEXフォーマットで表現できないか考察してたと思うけど。
951 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 21:23:35.03 ID:o5GMnakW
>>950
まあそういうことだな
64ビット専用だからVEXに押し込む必要ないからねぇ。
たとえば回収されたBCD命令のOpcodeをリードバイトに使っても収まる。
VEXじゃ32本（5ビット）のSIMDレジスタ×3オペランド＋マスク（3ビット）を表現するのは
難しい。できなくはないけど、mmmmmの予約空間が半分近く使われる。
VEXの寿命縮めてまでLarrabee独自命令を押し込む必要は無い。
AVXの命令のほとんどはRISCに倣ってに1命令1サイクルで実行できる
（今はできないものもあるが将来的にはできる）ようにデザインされてるが、
LRBniはCISC的に何サイクルもかけるものが多いし、単純な積和算にせよ1サイクルのスループットで
完結させようと思えば従来CPUのような高クロック化は難しい。
命令フォーマットの設計思想が全く違う。
まあそういうことだな
64ビット専用だからVEXに押し込む必要ないからねぇ。
たとえば回収されたBCD命令のOpcodeをリードバイトに使っても収まる。
VEXじゃ32本（5ビット）のSIMDレジスタ×3オペランド＋マスク（3ビット）を表現するのは
難しい。できなくはないけど、mmmmmの予約空間が半分近く使われる。
VEXの寿命縮めてまでLarrabee独自命令を押し込む必要は無い。
AVXの命令のほとんどはRISCに倣ってに1命令1サイクルで実行できる
（今はできないものもあるが将来的にはできる）ようにデザインされてるが、
LRBniはCISC的に何サイクルもかけるものが多いし、単純な積和算にせよ1サイクルのスループットで
完結させようと思えば従来CPUのような高クロック化は難しい。
命令フォーマットの設計思想が全く違う。
952 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 21:42:46.48 ID:o5GMnakW
参考までに、LRBniからは8/16ビット整数オペレーションが省かれてるので
これをそのまんまSSE/AVXのポストに据え置くのは難しいわな。
もしCPUコアにLRBniを組み込むとして512ビットAVXとLRBniの2系統の命令を同時に
サポートするということになるんじゃね？
それは単純にLRB側のコードをそのままCPUで動くようにするためだな。
フォーマットが複雑すぎるのでmicrocodeデコードになるだろうが、Sandy Bridgeで追加された
μOPs cacheがあるのでループする処理に関しては性能の問題は軽減されるかも。
これをそのまんまSSE/AVXのポストに据え置くのは難しいわな。
もしCPUコアにLRBniを組み込むとして512ビットAVXとLRBniの2系統の命令を同時に
サポートするということになるんじゃね？
それは単純にLRB側のコードをそのままCPUで動くようにするためだな。
フォーマットが複雑すぎるのでmicrocodeデコードになるだろうが、Sandy Bridgeで追加された
μOPs cacheがあるのでループする処理に関しては性能の問題は軽減されるかも。
>microcodeデコード
これ何？
これ何？
954 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 22:46:28.56 ID:o5GMnakW
x86の1命令と内部μOP(s)が1〜2つで対応してる場合は、ハードワイヤードロジックで実装された
Simple Decoderでの対応になる。モダンなx86が1クロック3〜4命令同時デコードできるってのは
Simple Decoderで処理できるものだけ。
複雑な命令は、Complex Decoderのmicrocode ROMテーブルから対応する複数のオペレーションを
引っ張ってきて複数サイクルかけて吐き出すような動作になる。
んでもってμOPs cacheにヒットしてればこの遅いDecoderでの処理を飛ばすことができるので
パイプラインを乱さずに処理することができる。Sandy Bridgeの速さの理由のひとつだね。
じゃあトレースキャッシュNetBurstだってもっと速くてもよかったじゃないかというと、
それもそうなんだが、処理可能なオペレーションが単純すぎて、それほど複雑でも無い普通の
命令までもμOPs数そのものが増えて結果的に遅かった。
Simple Decoderでの対応になる。モダンなx86が1クロック3〜4命令同時デコードできるってのは
Simple Decoderで処理できるものだけ。
複雑な命令は、Complex Decoderのmicrocode ROMテーブルから対応する複数のオペレーションを
引っ張ってきて複数サイクルかけて吐き出すような動作になる。
んでもってμOPs cacheにヒットしてればこの遅いDecoderでの処理を飛ばすことができるので
パイプラインを乱さずに処理することができる。Sandy Bridgeの速さの理由のひとつだね。
じゃあトレースキャッシュNetBurstだってもっと速くてもよかったじゃないかというと、
それもそうなんだが、処理可能なオペレーションが単純すぎて、それほど複雑でも無い普通の
命令までもμOPs数そのものが増えて結果的に遅かった。
それは
複数のμOPに分解される命令の話で
複雑なフォーマットの命令の話ではないよな
複数のμOPに分解される命令＝複雑なフォーマットの命令
なのか？
複数のμOPに分解される命令の話で
複雑なフォーマットの命令の話ではないよな
複数のμOPに分解される命令＝複雑なフォーマットの命令
なのか？
via cpuのx87命令の大半みたいなものかな
957 ：,,・´∀｀・,,）っ-○○○：2011/04/22(金) 23:44:41.23 ID:o5GMnakW
ロードしてBroadcastして型変換してプレディケートつき積和算みたいなのを従来CPUで
１〜２μOPｓでできるかっつーの。
でもComplexにだけ実装すればsimpleデコーダのコストは省けるよね。
Sandy BridgeでもAVXのうちvpblendvbのような4オペランド命令はComplex Decoderでしか
デコードできない。
１〜２μOPｓでできるかっつーの。
でもComplexにだけ実装すればsimpleデコーダのコストは省けるよね。
Sandy BridgeでもAVXのうちvpblendvbのような4オペランド命令はComplex Decoderでしか
デコードできない。
これについて聞きたいんだけど
>フォーマットが複雑すぎるのでmicrocodeデコードになるだろうが
μOPの話ばかりして、命令フォーマットの話はスルーか？
>フォーマットが複雑すぎるのでmicrocodeデコードになるだろうが
μOPの話ばかりして、命令フォーマットの話はスルーか？
959 ：,,・´∀｀・,,）っ-○○○：2011/04/23(土) 00:04:59.83 ID:vH/Ah5Lq
フォーマットが複雑ってのはハードワイヤードロジックで実装するとコストがかかるってことも意味する。
ハードワイヤードで処理できたとしても全部のデコーダで対応したらコストがかかるだろう？
Complex Decoderで処理される命令全てがmicrocode ROMで処理されるわけではないが
フォーマットが複雑な命令はほぼすべてComplex Decoderで処理されるのが通例。
P54CのU/VパイプってのはまさにComplex DecoderとSimple Decoderの組み合わせだ。
ハードワイヤードで処理できたとしても全部のデコーダで対応したらコストがかかるだろう？
Complex Decoderで処理される命令全てがmicrocode ROMで処理されるわけではないが
フォーマットが複雑な命令はほぼすべてComplex Decoderで処理されるのが通例。
P54CのU/VパイプってのはまさにComplex DecoderとSimple Decoderの組み合わせだ。
960 ：,,・´∀｀・,,）っ-○○○：2011/04/23(土) 01:04:36.18 ID:vH/Ah5Lq
ちなみにLarrabeeネイティブでもSIMD命令のほとんどはComplex Decoderのパスだし
Simple Decoder処理できるのはシンプルなスカラ演算とマスク演算、vstore命令くらいしかない
ってIntelが言ってるだろう。
そもそも根本的な話として、LRBniフォーマットが複雑なのは、複数のオペレーションを
1命令に詰め込めるようにしたからなわけで、Wide-issueでμOPsに分解して処理するモダンな
CPUでは大半がmicrocodeデコードになって然るべきだろう。
Simple Decoder処理できるのはシンプルなスカラ演算とマスク演算、vstore命令くらいしかない
ってIntelが言ってるだろう。
そもそも根本的な話として、LRBniフォーマットが複雑なのは、複数のオペレーションを
1命令に詰め込めるようにしたからなわけで、Wide-issueでμOPsに分解して処理するモダンな
CPUでは大半がmicrocodeデコードになって然るべきだろう。
プレス子スレにてSIMMとSIMDの勘違いをした決定的瞬間のログ（団子こと雑音が"録音"と呼ばれていた時代のログ）
http://web.archive.org/web/20080518103351/http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html
http://web.archive.org/web/20080518103351/http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html
>>961
（録音が）あまりに無様すぎて乾いた笑いが出てくるレベルだな・・・
（録音が）あまりに無様すぎて乾いた笑いが出てくるレベルだな・・・
最近だとデフォルトスタンダード、ビター文か？
せざるおえん っていうのもある
965 ：,,・´∀｀・,,）っ-○○○：2011/04/25(月) 22:37:58.60 ID:OyPMlNid
パッチもん っていうのもある
正しい日本語：雑音語
ビタ一文→ビター文
せざるを得ない→せざるおえん
laugh→lahgh
デファクトスタンダード→デフォルトスタンダード
SIMD→SIMM
脊髄反射→脊髄反応
骨折り損のくたびれ儲け→骨折り損のくたびれ損
馬脚を現す→馬鹿ってすぐ脚をだす
提灯記事→行灯記事
ビタ一文→ビター文
せざるを得ない→せざるおえん
laugh→lahgh
デファクトスタンダード→デフォルトスタンダード
SIMD→SIMM
脊髄反射→脊髄反応
骨折り損のくたびれ儲け→骨折り損のくたびれ損
馬脚を現す→馬鹿ってすぐ脚をだす
提灯記事→行灯記事
translation:
Author never thought that this thread could be so noticeable...so do doubts.
Please be neutral, this processor ain't the best from AMD or it might consists some bugs(causing low in score).
Take this test with a pinch of salt. Both CPU taken for comparison support turbo feature (Intel is slightly better than AMD in this case).
Benchmarks conducted had left turbo enabled.
For the sake of equality, all parameters are unified, CPU from AMD has turned off Turbo Core/CIE/CnQ and for Intel side, it has TB/C3,C6/EIST/CIE turned off. (edited: left out of the keyword "turned off")
Benchmark software is now updated to Cinebench R11.5
（笑）なんていってそのサイトのURLコピペするとか中国語も英語も読めないんだろうな
Author never thought that this thread could be so noticeable...so do doubts.
Please be neutral, this processor ain't the best from AMD or it might consists some bugs(causing low in score).
Take this test with a pinch of salt. Both CPU taken for comparison support turbo feature (Intel is slightly better than AMD in this case).
Benchmarks conducted had left turbo enabled.
For the sake of equality, all parameters are unified, CPU from AMD has turned off Turbo Core/CIE/CnQ and for Intel side, it has TB/C3,C6/EIST/CIE turned off. (edited: left out of the keyword "turned off")
Benchmark software is now updated to Cinebench R11.5
（笑）なんていってそのサイトのURLコピペするとか中国語も英語も読めないんだろうな
969 ：,,・´∀｀・,,）っ-○○○：2011/04/29(金) 09:37:55.57 ID:c15ZwRFu
Turboがきいてもスコア改善率はせいぜい1〜2割だろ。
いい訳にならない差だな
いい訳にならない差だな
971 ：,,・´∀｀・,,）っ-○○○：2011/04/29(金) 10:06:46.52 ID:c15ZwRFu
必死だなｗ
対sandyで概ね半分のパフォーマンスだよね
同クロックだと
同クロックだと
いっぽうSandyはLlanoに比べて80%低速（19.21/3.99）
974 ：,,・´∀｀・,,）っ-○○○：2011/04/29(金) 10:23:33.50 ID:c15ZwRFu
http://www.4gamer.net/games/128/G012877/20110215083/
以前よくIntelびびってるってことで、取り上げられていたのが
＞Intelは，Sandy Bridge-Eの4コアモデルやIvy Bridgeで，動作クロックを引き上げることにより，
＞同価格帯の「Bulldozer」（ブルドーザ，開発コードネーム）比で10〜30％高い性能を発揮できる
http://www.anandtech.com/show/4291/additional-details-on-sandy-bridgee-processors-x79-and-lga2011
SandyBridge-E 4コア版のクロックが、定格3.6GHz、TB最大3.9GHz
とクロックわかったから、4gamerの記事にあるIntelの言に合わせると、
Bulldozerの3〜5万ゾーンは、
SandyBridge-Eの定格2.8〜3.3GHz
TB時も考慮すると3〜3.6GHz
くらいの性能と、Intelは推測してるっぽいな。
以前よくIntelびびってるってことで、取り上げられていたのが
＞Intelは，Sandy Bridge-Eの4コアモデルやIvy Bridgeで，動作クロックを引き上げることにより，
＞同価格帯の「Bulldozer」（ブルドーザ，開発コードネーム）比で10〜30％高い性能を発揮できる
http://www.anandtech.com/show/4291/additional-details-on-sandy-bridgee-processors-x79-and-lga2011
SandyBridge-E 4コア版のクロックが、定格3.6GHz、TB最大3.9GHz
とクロックわかったから、4gamerの記事にあるIntelの言に合わせると、
Bulldozerの3〜5万ゾーンは、
SandyBridge-Eの定格2.8〜3.3GHz
TB時も考慮すると3〜3.6GHz
くらいの性能と、Intelは推測してるっぽいな。
hammerの頃もこんな感じで馬鹿が勝利宣言してましたよ
Intelが言ったということからすると、Intelは>>975で書いたくらいの性能だと
推測してるんじゃないの？
別に実際のBulldozerの性能がこれくらいだと言ってるわけじゃないのに。
あと、SandyBridge-EとLGA1155のSandyBridgeの性能差もわからないんだけど。
推測してるんじゃないの？
別に実際のBulldozerの性能がこれくらいだと言ってるわけじゃないのに。
あと、SandyBridge-EとLGA1155のSandyBridgeの性能差もわからないんだけど。
978 ：,,・´∀｀・,,）っ-○○○：2011/04/29(金) 12:29:03.00 ID:2Yx8Ejco
直接影響しそうなのはL3キャッシュ容量とメモリチャネル数くらい
Bulldozerが6月、Sandy Bridge-EがQ4なんだから、Sandy Bridge-Eを出すときに価格決めるってだけじゃないか？
>>979
Intelはランク付けで大体価格決まっている。
P1が300ドル前後で、P2が600ドル前後と900ドル前後、Extremeが999ドル以上って感じに。
4コアSandyBridge-EはP1なので、基本300ドル前後。
高くてもP2の600ドル前後まではいかない。
Intelはランク付けで大体価格決まっている。
P1が300ドル前後で、P2が600ドル前後と900ドル前後、Extremeが999ドル以上って感じに。
4コアSandyBridge-EはP1なので、基本300ドル前後。
高くてもP2の600ドル前後まではいかない。
Sandybridgeと比較して小さいとはいえないBulldozerのFPU
http://repositories.lib.utexas.edu/bitstream/handle/2152/3082/quinnelle60861.pdf
P.141
Table 6.3.2 Bridge fused multiplier-adder results
より
65nm AMD SOI
FPADD_DP 72,075um^2
FPMUL_DP 131,130um^2
FMA_DP 186,930 um^2
であるから
FMA_DP/(FPADD_DP + FPMUL_DP) = 0.919908
となる
Bulldozerは50%が拡張倍精度(EP)対応
Sandybridgeは25%がEP対応だから
実際の差はより小さいと推測される
http://repositories.lib.utexas.edu/bitstream/handle/2152/3082/quinnelle60861.pdf
P.141
Table 6.3.2 Bridge fused multiplier-adder results
より
65nm AMD SOI
FPADD_DP 72,075um^2
FPMUL_DP 131,130um^2
FMA_DP 186,930 um^2
であるから
FMA_DP/(FPADD_DP + FPMUL_DP) = 0.919908
となる
Bulldozerは50%が拡張倍精度(EP)対応
Sandybridgeは25%がEP対応だから
実際の差はより小さいと推測される