AMDの次世代CPUについて語ろう 第31世代

＿＿＿_
＼.＿　 | 荒らし・煽り・厨房は放置が一番。
／|＿|　| 釣られずにスルーしましょう。
|＿／＼! sage進行でマターリいきましょう。

■前スレ
AMDの次世代CPUについて語ろう 第30世代
http://pc11.2ch.net/test/read.cgi/jisaku/1252750795/

自作板AMD系スレッド過去ログ保存サイト様
http://amd.jisakuita.net/

■関連スレ
Intelの次世代CPUについて語ろう 41
http://pc11.2ch.net/test/read.cgi/jisaku/1255132918/

CPUアーキテクチャについて語れ 16
http://pc11.2ch.net/test/read.cgi/jisaku/1253517890/

■過去スレ一覧
29 ttp://pc11.2ch.net/test/read.cgi/jisaku/1247396388/
28 ttp://pc11.2ch.net/test/read.cgi/jisaku/1240713914/
27 ttp://pc11.2ch.net/test/read.cgi/jisaku/1236773340/
26 ttp://pc11.2ch.net/test/read.cgi/jisaku/1231688064/
25 ttp://pc11.2ch.net/test/read.cgi/jisaku/1228783643/
24 ttp://pc11.2ch.net/test/read.cgi/jisaku/1226628399/
23 ttp://pc11.2ch.net/test/read.cgi/jisaku/1219751351/
22 ttp://pc11.2ch.net/test/read.cgi/jisaku/1214276833/
21 ttp://pc11.2ch.net/test/read.cgi/jisaku/1209908499/
20 ttp://pc11.2ch.net/test/read.cgi/jisaku/1203947286/
19 ttp://pc11.2ch.net/test/read.cgi/jisaku/1199338832/
18 ttp://pc11.2ch.net/test/read.cgi/jisaku/1197562571/
17 ttp://pc11.2ch.net/test/read.cgi/jisaku/1195270082/
16 ttp://pc11.2ch.net/test/read.cgi/jisaku/1192923006/
15 ttp://pc11.2ch.net/test/read.cgi/jisaku/1190954072/
14 ttp://pc11.2ch.net/test/read.cgi/jisaku/1189440665/
13 ttp://pc11.2ch.net/test/read.cgi/jisaku/1187934610/
12 ttp://pc11.2ch.net/test/read.cgi/jisaku/1183558273/
11 ttp://pc11.2ch.net/test/read.cgi/jisaku/1181563841/
10 ttp://pc11.2ch.net/test/read.cgi/jisaku/1177368830/
09 ttp://pc11.2ch.net/test/read.cgi/jisaku/1172183431/
08 ttp://pc9.2ch.net/test/read.cgi/jisaku/1167003467/
07 ttp://pc7.2ch.net/test/read.cgi/jisaku/1161618220/
06 ttp://pc7.2ch.net/test/read.cgi/jisaku/1157327883/
05 ttp://pc7.2ch.net/test/read.cgi/jisaku/1150393478/
04 ttp://pc7.2ch.net/test/read.cgi/jisaku/1145187468/
03 ttp://pc7.2ch.net/test/read.cgi/jisaku/1138983969/
02 ttp://pc7.2ch.net/test/read.cgi/jisaku/1133374045/
01 ttp://pc7.2ch.net/test/read.cgi/jisaku/1124542812/

初めて立ててみた
不具合あったら、訂正など頼む

>>1
乙！

AM3規格は果たしていつまで続くのか

>>1
お疲れ〜

AM3r2なんて名前にするならなんらかの互換性があるよな
なかったらIntelに変える

AM3r2はたぶん800番台以降のチップセットか、
あるいはそれに対応して製造されたM/Bだけかと。
たぶん今ある板では対応できない気がする。

AM2/AM2+板は確実に対応しないだろうね。
DDR2なんてサポートしていないだろうから。

わざわざAM3の名前を冠するする以上、何らかの互換性はあるだろう

AM3対応はあるんじゃないか、名前的に
発売までAM3r2のままとも限らないだろうけど

来年出る6コアの"Thuban"に対応できる板辺りから、
「AM3r2対応」になる予感。

>>11
悪寒て・・・w
確実な情報kbn

>>12
"次世代CPUスレ"で確実な情報なんて…無いだろ。
でも過去のAM2/AM2+の移行や対応を考慮して考えれば、
なんとなくそーじゃないかってのは予想できるのでは？

確実な情報が欲しかったら、来年末か再来年頭の
"Bulldozer"正式発表まで待っていればいいよ。
その頃にこのスレにいらっしゃい。

わざわざ未来に行かなくてもドレスデン辺りに行けばよくね？

http://pc11.2ch.net/test/read.cgi/pc/1258305535/

>>14
ドレスデン辺りに行って何がわかるの？
「田舎町だなぁ」とかそういうこと？

理研富士通共同開発CPUとどっちが上？

>>17
おそらく性能的には大差ない
費用対効果は比べるだけ無駄

ビーナスは浮動小数点演算の鬼だぞ
同期機構の追加も大きい

ttp://pc.watch.impress.co.jp/docs/column/kaigai/20091126_331235.html

2011年に登場するAMDの8コアデスクトップCPU「Zambezi」
http://pc.watch.impress.co.jp/docs/column/kaigai/20091126_331235.html

整数演算はCPUで、浮動少数はGPUがやりますよ、とのこと

浮動小数点の点を略すなよ　気持ち悪い

BulldozerベースのAPUがいつになるかわからない時点でそんなこと言われても。
仮に出せたとしても、AVX以上にAPUへのソフトウェア対応は遅れる。

Fetch&Decode共有の謎にも切り込んで欲しい。
ここはRock他CMTアーキティクチャとの明確な差異なんだから。

質問なんだけど
ブルドーザーのスカラ部分の設計って
K9あたりからの使いまわしなの？

理にはかなってるんじゃ？
現状〜近い将来のワークロード：FPUは1%程度の使用　　Bulldozer内蔵の128bitx2（共有ユニット）で、
将来、スループット重視のワークロードが増える：FPUは数十%にアップ　GPU内蔵のFPUを使う

で、ALU＆レジスタ群は完全独立で、シングル・スループットの性能をも重視　

＞スループット重視のワークロード
処理能力重視の利用状況
意味不明

そもそも整数はフラグ立て
小数点は座標計算等の用途で
アプリというか分野によって割合が変わってくるのに
「FPが余ってるから積極的に使おう」とか今から急に発奮するって何なの？

>>26のほうが意味が分からん･･･

ところでデコーダを2スレッドで共有することで複雑性って回避できるのかな？
今でもボトルネックになってるデコーダを2コアで共有するってことは、何かあるんだろうけど

RedirectRecoveryCacheでFetchとDecodeをすっ飛ばせるって話だから
デコーダはボトルネックじゃなくなるらしい
むしろデコーダなんて2コアにひとつあれば十分だと

こういうのを読んでも専門じゃないから、詳しいことは分りません。
でも、何か楽しいね。なんでだろ

>>28
Nehalemのループ処理みたいな仕組み？
それだけでいきなり4命令同時発行できるようになるんだろうか

でもこうしてみるとBulldozerはCMT、パワーゲーティング+ターボモード、AVX+αの拡張命令、32nm・High-K+MGと盛りだくさんだね
K10でさんざ言われたvictim cacheはどうするのかね？

>>28
どんなキャッシュか知らないが、よっぽど画期的な仕組みでない限り、
そう上手くいくとは思えない。

なんかBulldozerの話出るらしいね

http://www.isscc.org/isscc/2010/ISSCCAP2010.pdf

An x86-64 Core Implemented in 32nm SOI CMOS
4:15 PM
R. Jotwani1, S. Sundaram1, S. Kosonocky2, A. Schaefer1, V. Andrade1, G. Constant1, A. Novak1,
S. Naffziger2
1AMD, Austin, TX 2AMD, Fort Collins, CO
The 32nm implementation of an AMD x86-64 core occupying 9.69mm2 and containing more than 35
million transistors (excluding L2 cache), operates at frequencies >3GHz. The core incorporates
numerous design and power improvements to enable an operating range of 2.5 to 25W and a zero-power
gated state that make the core well-suited to a broad range of mobile and desktop products.

>>28
これか
http://www.freepatentsonline.com/20080195844.pdf

【8年前】
Pentium 4はTrace CacheでFetchとDecodeをすっ飛ばせるって話だから
デコーダはボトルネックじゃなくなるらしい
むしろデコーダなんて3issueパイプラインでもひとつあれば十分だと

そーいやIntelに出戻ったネトバのチーフアーキテクトの忘れ形見なんだよな
やけに納得してしまった

鬱陶しいな

>32
それはLlanoだという話もあるが。

10.8 A 32nm Fully Integrated Reconfigurable Switched-Capacitor DC-DC Converter
Delivering 0.55W/mm2 at 77% Efficiency
12:00 PM
H-P. Le1, M. Seeman1, S. R. Sanders1, V. Sathe2, S. Naffziger2, E. Alon1
1University of California, Berkeley, CA
2AMD, Fort Collins, CO
A fully integrated switched-capacitor DC-DC converter with 32-phase interleaving is
implemented in 0.374mm2 of a 32nm SOI process. The converter can be reconfigured into
three topologies to support 0.5 to 1.2V output from a 2V input supply, and achieves a
maximum efficiency of 77% at an output power density of 0.55W/mm2.


AMDもちゃんと研究してたんだな
オンチップでDC-DCコンバータが出来れば電源ドメインも細かく分離出来て
コア毎の電圧可変もしやすくなるのだが
とは言えこの出力じゃまだまだ先は長いな

>>34
Sandyちゃんでも復活の予定。

>>32-34

,,・´∀｀・,,）っ-○○○
　　↓　　↓　　↓　　↓
,,・｀∀´・,,）っ-糞屎糞

>>32
＞ make the core well-suited to a broad range of mobile and desktop products.

Bulldozerでこの書き方はないような気が。

Bulldozerは再来年のISSCC向けのネタじゃね

隣のドバイがぐらついて(ようやく表面化した、という感もあるが)、
これにアブダビが支援に乗り出すとなると、AMDとGFは財政的に孤立するかも。

コメント欄で西さんが昔話を書いてる
ttp://agora-web.jp/archives/807723.html

http://pc.watch.impress.co.jp/docs/column/kaigai/20091127_331818.html

AMDは２０１０年をしのぎきれるのであろうか……

散々の既出ネタを今頃のように出されてもなぁ。

CoreMA→Nehalem MAに
P4系→CoreMA　並みのインパクトがあればAMDはしのげない思うが
i3〜i7にそこまでのインパクトはないっしょ。というかIntelは
AMDのペースを見て、これでも平気だなと手を抜いてるような印象を受ける

>>43
Athlon作ったのは旧DECではなく旧NEXGENが中心だったとな

この板の定説と食い違ってるな

プロジェクトリーダーを中心と見るか
実際に図面を書いたエンジニアを中心と見るか
って話に思えるが

ALUとAGUをペアにしてLoad/StoreをAGUの背後にぶら下げて共有するとか
INT/FP分離構成とかはAlphaの設計思想が現れてるなんて顔文字パクリの人が言ってた

Intelのクアッドが数量べースで10%
多コアの需要はわりと無いんだな。
まあ、サーバですらCPUよりネットワークやI/Oがボトルネックなら
クアッドにする意味ないもんな。

前スレではBulldozerのコアの実効ユニットは(ALU+AGU)*4派だったんだけど、今は(ALU+AGU)*2な気がしてきた
�@「50%のコスト増で80%のスループット向上」ってことは、(少なくともマルチスレッド時は)スレッドあたりの性能は90%
�Aシングルスレッド性能はターボで上げられる

その西さんって人の話は信用できるのか？
ちらっと読んだが、ただ自分を大きく見せる為に
自分の関わっていたNEXGENに肩入れした話を
してるように見える。

そっかあ
若い人は西さん知らないよねえ

ビルゲイツと喧嘩せずにMSXが成功していたら
歴史が変わっていたんだろうな

そっかあ
MSX世代のじいさんは1ch.tvとか牛丼事件とか知らないよねえ

対抗するようなネタなのかｗ

>>53-54 = じいさん
>>55 = おっさん
>>52 = 若者

って構図？

>>53-54 = 53〜54歳
>>55 = 55歳
>>52 = 52歳

>>51

今まで出てきた情報では2*(ALU+AGU)の線は消えた
各整数演算ユニットごとに4命令/サイクルを目指すことが明言されてる
ではそれがどのような構成なのか？という話に移っているが
これについては意見がまだバラバラで方向性は定まらず

4 * (ALU+AGU)じゃないの？
LSUは2基なんだからAGUも2つあれば十分という考え方もできる。

たとえばPhenomで追加されたABM（popcnt/lzcntなど）をどうするか？だが、
popcnt rax, [rcx]ってな具合にメモリを引数にとれる。
最低限AGUはぶら下げる（あるいは2パスで実行する）必要がある。
そうやっちゃうと、ABMをレジスタ間オペレーションで実行し、他の2命令でロードが要求される
ケースではストールするわけで。

Phenomの段階ではABMを実行出来るパイプは1つだけ。
これはあまり利用頻度の高い命令ではないし、実装コストが大きいので複数のALUで
実行出来るようにするのは現実的ではない。
というか、ビットを数える回路よりただの加算器にすぎないAGUの方が回路が単純だろう。

って考えると、AGUは4つのパイプ全部にぶら下げた方がかえってリソース食わなさそう。

アブダビと直接関係ないが貼っておく

ドバイ向け債権、邦銀は1000億円規模
http://markets.nikkei.co.jp/kokunai/hotnews.aspx?id=AS2C27024%2027112009

シングルスレッドでもPhenomより性能上がるのか。

>>62
それはあがるだろ。

クロックが上がらない、という悪寒。
まだモノが無いにしても、どのレンジを狙っている、という言及もないよね。

>>62
問題は「どの程度」上がるかだ

ブルちゃんは2011って言ってるからなぁ。もうちょっと早く
出てくれるとうれしいんだけど。

CPUもGPUも遅れまくりなんだよな
物理的限界か('A`)

>>66
AVX無しで…とは思うけど省いたら、
またほぼ再設計で出直しレベルだったのかもねぇ。

>>67
「物理的限界」の意味がさっぱりわからない。
そしてCPUは遅れているが、GPUはそこそこ順調だろ。

GPGPUという単語を聞いてベクタ演算を全てGPUでやる世界が待ち切れない
みたいな奴が居るな
物理的限界か('A`)

>>59
mjd?
ソースを…ソースを下さい

>>70
チャック・ムーアさんがこの前の発表で質問に答えてたよ
module内のeach INT Unitが〜という言い方だった（と思う）

発表のスライドには含まれてないけどAMDの投資家向けページで
各セッション（音声のみ）は公開されてるからそこで確認できるはず

ただこういうのは全貌を明かしてないので曖昧な表現が多いから
もしかしたら言葉の解釈次第で実際と異なるケースあるかもしれん

いずれにせよBDの下にLlanoとBobcatがあるので
そいつらよりもIPCが上回らないと用意する意味が無いからね

団子の人は4セット説か・・・確かにダイ全体の面積に
占める割合は小さいから増やしても問題ないのかも

むしろフェッチとデコーダをどうすんだろうか
食わせるためのエサを十分供給できるのかなぁ
どうやってボトルネックを回避し得るのだろう

μOPsをバッファリングして、反復処理で再デコードさせずにμOPsを再利用する仕組みではないかな。
NehalemのLoop Stream Detectorを用いた方式とほぼ類似の技術。

もちろんループ以外では役に立たないので4命令/clkのデコード帯域を
2コアで共有することになるが、それでもベストケースでは2スレッド合計8命令/clkで
処理することができる、と。

小さいループでだけ有効な極小の命令トレースキャッシュ技術。
かなりピーキーな設計だと思う。

ただ、どんだけ並列度を上げても、目的のデータを拾ってくるまでパイプラインが止まる宿命からは逃れられない。
だからこそ片方のコアがデータハザードで止まっても、もう片方のコアには4命令の帯域を
フルに共有できる仕組みが生きてくる。
極小のループ内であわよくば8命令同時発行ってのは、それに特化したベンチ以外では
役に立たなさそうだが、基本性能を底上げしてれば不満も出にくいでしょ。
2スレッドで8命令を狙うにはピーキーだが、4命令を狙うには性能の最低ラインは抑えてるという、そんな印象。

このあたりの特許が関係あるかも
ttp://www.faqs.org/patents/inv/210956

各特許のInventorを辿ると、ほかにも色々面白いのが沢山でてくる

>>73
無理して共有で4命令デコードするより
3命令×2スレッド載せた方がパフォーマンスもスループットも有利な気がするのだが。

非常に単純に模式化すれば、
デコーダを共有すれば、従来コア2個分のトランジスタを費やしたリッチなデコーダを構成出来るから
1スレッドで占有時のパフォーマンスは良くなる。でも収穫逓減の法則で、
2倍のトランジスタを費やしても、デコーダ性能は2倍にはならない。
つまり2スレッド並行実行時の1スレッドあたりのスループットは、悪くなる。

デコーダ層が単独スレッドのパフォーマンスにフォーカスするのは、
Bulldozer全体がトランジスタ性能比の改善を指向しているのと整合しないように思える。
ここにはまだ明かされていない重要な秘密(実は実質的に共有でない、というようなことも含めて)
があるはず。

>>75>>76
デュアルコアでもSMTでもない理由考えたら自明
団子が書いてるようにストールさせないで済むし
同時に走るスレッドで演算ユニットの取り合いにもならない
フレキシブルにパイプラインを稼動させられる

>>77
片方ストール時のみ4命令発行出来ても通常2命令/スレッドでは嬉しくないし
スループット向上をμOPsのトレースキャッシュに頼るのは
(P4の失敗を考えると)納得しにくい。

デコーダがFPUのような特性を持つ(通常使われてないとかレイテンシが大きいとか)なら
共有するのもわかるが、そうではないし、実際過去にも
共有したアーキテクチャはない。自明というにはわからないことが多い。

キャッシュミスして実効ユニットがストールしてるときって、デコーダは動いたままで生成したμOpsをレジスタに格納してると思ってた

>>74
これか
PROCESSING PIPELINE HAVING STAGE-SPECIFIC THREAD SELECTION AND METHOD THEREOF
ttp://www.freepatentsonline.com/y2009/0172362.html
今までとはかなり違うなー

この図だと各integerユニット内部は
ALU1 AGU1 LSU1 ThreadReirement1に見えるのだけど、実際はどーなんだろな

ありゃ？ということは2x(ALU+AGU)もあり得るのか
パワレポの後藤さん連載コラム読む限りでは
こっちの説みたいだけど今ある情報の解釈次第で
がらっと変わるからどっちなのか判断難しいね

>>80
これはあくまで実装例

「こういう実装もできる」って形でこんなことも書いてる
�@シングルスレッド中の(依存関係がない)2命令をデコーダから両方のコアに渡して高速化する
�Aシングルスレッドを片方のコアで実行中、あらかじめロード命令をもう片方のコアで実行しておいて
　結果を事前にプリフェッチまたはキャッシュに入れておく(Rockのスカウトスレッド的？)
�B分岐が確定する前にとりあえず両方の場合の命令をデコード・実行 → 分岐が確定した時点で正しいほうを選択する
�Cシングルスレッド中の単一の命令を両方のコアでそれぞれ実行し、2つの結果を付き合わせることで信頼性を向上させる
�Dパイプラインの各段階(フェッチ・デコード・ディスパッチ・実行)の前のスレッドセレクターで、
　パイプラインの状態・スレッドの性質・命令の種類などから判断して実行する命令を動的に判断する
�E各デコーダが複雑な命令と単純な命令の2つを同時に並列にデコードできて、その2つの命令は単独のスレッドからでも別々のスレッドからでもいい
�F(L2キャッシュを通さなくても)同モジュールの２コアの実行ユニット間で直接データの受け渡しができる

企業秘密を守るためにわざと特許の部分とは関係ないところは実際の実装とかけ離れたモデルアーキテクチャを
使うのは常套手段ではないかな

Intelの場合、Larrabeeの特許論文ではモデルのアーキテクチャがなぜかアウトオブオーダ型のCPUコアになってた。

ブルドーザーはシングルスレッドの整数演算をハードウェアで分散処理するのか。

英語読むのにかかった数時間が団子に5分で否定されたぜ！

Andy GlewはBulldozerに関していろいろ語ってるけど
（曰く、「俺の子供みたいなもんだから嬉しいぜ！」）
その中で元々クラスター型のアーキテクチャには
>>82みたいな投機的マルチスレッディングの
アイディアも含まれていたので、それ関係じゃないかな。
もっともBulldozerに入ってるかどうかは微妙だけど。

BulldozerのIntegerパイプラインが4(ALU+AGU)ってのは
デコーダが最大4命令（確定）だから遊ぶユニット出てくるんじゃ？
ただ2(ALU+AGU)だと実行効率は上がるけどピーク下がるし
その辺どうやって実装するのかちょっと思いつかないな。

ちょいと聞きたいんだが、
今回の和解で互いの特許関係をかなり自由に使えるようになったみたいだが、
つまりAMD CPUやチップセットをIntel 向けにも出したり
逆にIntel CPUをAMD向けに出すこともできるということかな。
それともQPIやDMI関係は使えないとか？

>>87
包括契約みたいな記述だから、できるんでね？　ただし、5年間とかの期間限定でね。　

X86の特許関係っていつ切れるんだろう？

>>87
x86のライセンスに関しては和解した。
それとバスライセンスは全く別の話。

仮にバスライセンスで和解しても
HyperTransportは捨て難いだろう。
コアのアーキティクチャと密接な繋がりもあるし
いまさらソケット互換路線には戻れないのではないか。

ノースがCPUに統合されていく中、互換性があっても
そんなに魅力的とは思えん。

お互いがバスに使っている特許は欲しいかもしれないけど、
互換性には興味ないんじゃないの？

ソケット互換に出来るならその方がAMDにとっては断然売りやすいでしょ。
苦労してPCベンダにマザーボードから何から自社用に設計調達してもらわなくてよくなる。
無理だけど。

ちょくちょく変わるソケットへのパテント料とかなんとかいちいち払うの?
過去Intelの方から切った (そして他のベンダーのコストがあがった) わけだよ?

x86ライセンスの特許と、お互いが全く別の特許で固めらている
「バスライセンスで和解」なんて事はあり得ない。
"CPUバスライセンス"の話が一緒くたに語る奴の気がしれない。

AMDが使用している"HyperTransport"も
HT仕様自体は標準化団体により決められているが、
OpteronやPhenomがささるCPUソケット周辺の実装に関する特許は、
他社に自由に提供しているわけではない。
だから他社はHTで接続できる機器は製造できるが、
AMDソケットにささるCPUを造れるわけではない。

仮にIntelのプラットフォームのコピーなんか作ったら
AMDオリジナルを信仰してたAMDerが発狂死するんじゃね？

ﾃﾍ権田の特徴（極一部）
・話題にもなってないわけのわからない前提をどこかから持って来る
・宗教がどうとか言い出す
・コテを付けたり外したり換えたりする

>>86
3.5*(ALU+AGU)みたいなのは出来ないのか？
あるいはALUとAGUを融合させて4つを随時切り替えるとか

遊ぶくらいが丁度いいんじゃね？
スカスカになるときって本当に断続的にスカスカになるからそれこそアグレッシブな電力カットがやりやすい。

>>96
お前みたいな阿呆を産み出したのはIntelの罪だな。

同じことやってもつまらんだろう。

GPUにおけるNVIDIAとATIみたいにアーキテクチャが根本から異なるのがしのぎを削るように
異種格闘技戦が楽しい

HyperTransportってフリーライセンスじゃなかったっけ？

>>99
それPentium4もどきじゃね？
SMTや投機MTでパイプ埋めるとかｗ
トレースキャッシュもどきもありそうだし

いずれにせよ消費電力の抑制が
難しくなるからスカスカにするような
構成はまずやらないと思うが・・・

>>101
このﾃﾍ権田は前スレで
i7でのon offでではなくCore2とi7での比較でHTの効果を語っておりました

>>102
そうだよ。

ttp://www.drccomputer.com/drc/modules.html

こんなのがあった。最近の情勢は知らない。

そーいやﾃﾍって今何してんの？

>>107
最悪板だかにあるヲチスレに逝ってこいよ。

>>102
>>95 が書いてる様にCPUには使えないんだよな。

最新じゃなくて１世代前のHTくらい開放してもいいと思うんだけどね。

VIAを取り込めばチップセットが少しは安く出来るだろうし、nVidiaがVIAを
買収するのを少しは妨害出来るかもしれんし。

"HTにCPUを接続する事」がダメなのではなくて、
現状のAMDソケット互換CPUがダメなだけかと。

独自実装でソケット周り全てを作るならば文句は言えない。

NanoもC7もメモコン移設という大改造が必要になるからVIAにとってちっとも旨みが無い
AMDもローエンド食われてちっとも旨みが無い
誰が得するこんなもん

ビデオカードとかSATAとか繋がらんの？＞HT

>>112
何を言っているかさっぱりわからんが…。
HTXにささるSATAチップ&カードとか。
HTXにささるVGAチップ&カードとか作れば可能じゃね？

一般に売られている板にHTXスロットがあるの観たこと無いけどね。

http://support.amd.com/us/Processor_TechDocs/43479.pdf

Intel AVXから外されたvpermil2ps/vpermil2pdがXOPの仕様に追加

http://forums.amd.com/devblog/blogpost.cfm?catid=208&threadid=112934
> We intend to support all of it, with the possible exception of CVT16,
> which might not appear in the initial AVX-compatible products

CVT16は初期のAVX互換製品にはないかも、と書かれてたけど
仕様書から消えたみたいだね

>>76 >>78
Phenom の L1 のレイテンシって3クロックだっけ。実際暇なんでないの。
だからa、b各コアのL1に1クロックずらしてフェッチかけりゃ1デコーダでも
足りるでしょって話かと思ったけど。

I-Cacheも2つって明言されてたっけ？
そういう噂をどこかで見た気もするけど

それは初耳
D-Cacheが2つなのは意味があるだろうけど

L1を共有する２コアで１モジュールじゃなかったっけ？
D-Cacheは独立なのか。

http://aceshardware.freeforums.org/post12356.html#p12356
これだった

まさかとは思うがCVT16のAPI仕様もIntelと合わせるために延期したのだろうか？
http://www.issp.u-tokyo.ac.jp/super/manual/system-b/Intel_Cdoc110/main_cls/intref_cls/common/intref_halffloat_overview.htm

いや、これに対応する命令はなくて複合関数なんですけどね。

そういえばIEDMの季節だった
どんな成果が出てくるかな

http://pc.watch.impress.co.jp/docs/news/20091211_335263.html

これでAMDは何個CPUのせれるようになんの？

そういえば、APUの定義って何なんだろう？
APUにアクセスするのに専用命令が用意されてる様ではないみたいだし
FPUを完全エミュレートするのはハード的に敷居が高そうだから
良くてSSEを部分的に実行するだけか、最低GPGPU時に低レイテンシでアクセス出来るだけってオチっだたりして・・・

http://www.atmarkit.co.jp/fsys/zunouhoudan/114zunou/amd_apu.html

マルチコアもコアの数で稼ぐのはそろそろ限界に達してきているし、また、
PCにかかる負荷の方もストリーミング・ビデオの受信とか、扱うべきものが
昔とは大分変わってきているのだから、この際、CPUも変わっていかねば
ならない、それでCPU＋GPUだ、という主張に見える。その上、よく見ると
その製品ラインには、CPUでもGPUでもなくAPUと書いてあるのだ。

いかにもアナリスト向けだな。「何か新しいものだ」というときに名前を変えて
みるのは、よくやる手だが、効果がある。CPU＋GPUというような表現だと、
単に両者を合体しただけ、みたいに捉えられがちだが、別な名前にすれば
違う概念と捉える人が増えるし、その方が効果が際立つ。

7文字が3文字になるだろ

>>124
定義も何も異種混合コア。「ヘテロジニアス・マルチコア」のAMD名称。
それ以上でも以下でもない。

>>124
X64やFPUやSSE(AVX)をGPUコアで処理させるのは当分無理。
当面はDirectX11を処理できるCPUをAPUと呼ぶだろうね。

一番乗りかと思われたLarrabeeがあのザマだからな
金はあるんだからとりあえず出せばいいのに

いくらIntelでもこのご時世に体を張ったギャグはやれんだろう

Fermiで撤退するベンダー続出だろうな

誤爆った

整数パフォーマンスを犠牲にする? AMDの「Bulldozer」
http://pc.watch.impress.co.jp/docs/column/kaigai/20091216_335956.html

>　これらは、実は全て根は同じ疑問で、相互に結びついている。
> そして、後段については、すでに冒頭で書いたように、Bulldozerの整数命令スケジューラは
> 整数ユニットに4個のuOPを発行することがわかっている。
> そして、整数コアの実行パイプラインは、uOPを4並列実行できる構成だ。
> AMDによると、整数演算パイプが2つ、ロード/ストアパイプが2つの合計4パイプだという。

シングルスレッド性能落ちるじゃん

>>133
AMDから「整数演算パイプが2つ、ロード/ストアパイプが2つの合計4パイプ」
という情報を得たから書いた記事なんだろうけど、ちょっと怪しいなぁ

ttp://pc.watch.impress.co.jp/docs/column/kaigai/20091126_331235.htm の
Moore氏が「シングルスレッドパフォーマンスで妥協しない」
Chekib Akrout氏が「プロセッサの中で最も使われている部分は整数演算ユニットである」
といっていたというのに対してかなり矛盾する気がする

整数パイプの回路の規模や消費電力なんて山ほどつんでいるL3に比べれば小さいものだろうに
そこをケチってシングルスレッド性能を落とすのかな？

さらに1クロックごとに対象を入れ替えて
2スレッドの命令を交互に同時に4つずつデコードすると説明しているけど
計4命令/クロックをデコードしたいなら単純に2命令デコーダを2つ積むほうが
デコーダを作るも楽になるんじゃ

この情報が正しければ、Bulldozerの1モジュールとBobcatの2コアは
ダイサイズもパフォーマンスも大差なさそうだけど
わざわざ2種類も開発する必要性があったのかね

そして、クロックあたりのシングルスレッドパフォーマンスはLlanoが一番高くなるってどんなオチ

今回は眉唾で読もう

実は超クロックで登場するのかもしれん

Pentium4の再来か。

デコーダを共有する合理性がないんだよ、今のところ。
だからどんな説も腑に落ちない。

ベンチ特化CPUの登場である

いつも手堅いAMDがあえてバランス崩したチューンするのか
クロック上がらんとやっぱ厳しいねぇ

普通にK6のdualで良かったんでない？

fpuを積みたくないのか？

コアを小さくしてたくさん積めるようにしたいんだろ。
多分K7かK8の性能位に落ちると思う。

シングル性能も考慮したK7(性能的に)のメニーコア路線とも言えそう。
シングルスレッドのベンチは捨てたHPC専用なんだろう。

K6だって

実は倍速ALUだったりしてね

あれ？そんなCPUが昔あったような…

K6-3のクロックあたりの整数演算性能はPen3やK7を超えてTunderbirdに匹敵するんだが。

ちなみにK7はL2外付けのSlotA版のことで、ThunderbirdはL2内蔵したSocketA版のこと。

やむおえないだろうが、
あんまりコアがあっても活かしきれないぜ
シングルスレッド性能を犠牲にするなら尚更

デコーダや周辺拡張もされるだろうから、
そのまま性能の低下に繋がらないだろうけど、
同クロックで同条件だと1〜2割程度は低下するのだろうか？

>>80の特許使ってるならシングルスレッドの性能も落ちない
ひとつのスレッドを分解して2つの整数コアに投げるから
1モジュールあたりの整数性能は4/3倍

ハイハイ

>>150
まだ全然情報が出ていない段階だからその可能性もあるのか。
>>80ならば、>>135が引用した2人の話とも適合する。

>>146
クロック上げられないのに比較しても意味ないような

>>146-147
純粋なコアの議論でL2の有無の違うCPUを比較するのはどうかと
きっちり、K6-2＜K7/K75、K6-III＜Thunderbirdだしね

K6系のボトルネックは2Wayデコーダだったけど
K7系のボトルネックはレジスタ数になることが多かった

K7系には整数レジスタが8本しかないので
スタックポインタで確実に-1本、3命令分のデスティネーションで-3本されて
残りの4本でループカウンタ、オブジェクトのポインタ、3命令分のソースレジスタ
フレームポインタ、thisポインタなどをこなさないといけないので
常時3Wayを処理するのはかなり厳しく、3Way整数パイプは潜在能力を発揮できなかった

ゆえにx86-64のレジスタ倍増はK7系の拡張であるK8系には理にかなった拡張であり
ご存知の通り、同じアプリでも64ビット版だとK8系はかなり性能を伸ばす

また、K7系やP6系のFPUがK6系などに比べて強力といわれていたのはFPU自体の性能に加えて
レジスタ数の頚城から解放されて、3Wayデコーダの実力が発揮されたという側面もあった

よって、K6-IIIがP5用の2Wayコードがあふれていた当時は高性能だったからといって
SSE等の非整数処理コードがそれなりに普及し、これからx86-64の時代という今
K6並のコアで充分といえるかは別の問題になると思うよ
（K6系はP5系やP6系に比べて整数演算に関してはかなり優秀なコアだったけど）

>>152
Bulldozerの1モジュール（2コア）とGrayhoundやNehalemの1コアの比較すればでしょ？

45nmで6コアのThubanやGulftownが出るのに
32mで4BulldozerモジュールのZambeziまでしか予定がないって…

32mってドンだけでっかいシリコン作るつもりよ orz

かつてない歩留まりを提供できそうだな

>>154
FPやSSEの性能は低性能だから話題にしてないよ

>（K6系はP5系やP6系に比べて整数演算に関してはかなり優秀なコアだったけど）
それを言いたかっただけだし、あなたも理解していてなにより。

参考程度にかつての整数ベンチ(CPUMark99)
ttp://www.watch.impress.co.jp/pc/docs/article/991215/cpumark.htm
K6-3 450MHz > Athlon 550MHz > Pen3 550E(河童)

NexGen
AMD独自の技術ってどれだけあるのかね

K8は整数実行パイプとロード/ストアパイプがペアで1つの
整数スケジューラーに繋がってて、これが3セット。
Bulldozerでは1つの整数スケジューラーに
実行パイプとロード/ストアパイプが4本直に繋がってるみたいだから
スケジューラーの効率自体は上だと思うんだけど・・・

まっ省略されてるだけかもしれないけどね。

サイクルごとに2スレッドに交互に4命令発行するぐらいなら、
毎サイクル毎スレッド2命令発行するよな、普通。
後藤は自分で自分につっこむべき。

>>161の知恵遅れがやばい

つうか
AMDはGPUもCPUも質より量って方針で、非常に詰まらん
シングル落ちるなら興味なくなったわ
ま、5GHz以上で回るってんならまた別だが
あ、16,32コアとか言い張るんだろうけど

ベンチのスコア稼ぎがんばってね

整数1個減らしただけで「シングル激減ベンチ特化」が湧き出す不思議

Core2のベンチ向上はSSE強化でi7はキャッシュ強化のためで
整数演算器増やしたからじゃないってこと解ってんのかな

デコーダを統合するメリットないでしょ。命令キャッシュを共通に出来るから
二つのコアが同じコードを(SIMD的に)実行するなら意味があるが、そういう
ケースは一般的じゃない。
4命令を発行できるファットなデコーダより、2命令発行のシンプルなデコーダ*2
の方がトランジスタも電力も安価。

>>163
必死なところ悪いけど、AMDはIntelほどベンチの恩恵を受けないよ。

だからゲームは固定機能の量で決まるんだっつーの

ネタ切れだからしょうがない

下がっても、上がらない

>>168
陰厨も必死なんだろ。煽りも低調。知識も枯渇って感じ。

ネタ切れで先祖がえりのamd

2Way ALUだとしても整数リザベーションステーションを集中型にシフトするのだとしたら
それなりに実効IPCは確保できるかも

分散型RSの欠点は、RSの1レーンが空いても、別のレーンに投入されて溜まったμOPを処理出来ないと言うこと。

IntelでいうMacroOPs-Fusionは採用されるんだろうか
FMACユニットがあるなら乗算と加算をFusionとかできないかな

それが出来るなら新命令いらんて

>>152
レジスタファイルとキャッシュがコア毎に分かれてても1スレッドを分散処理できるもんなの？

>>175
そのときは真ん中に置いて共有するんじゃないの。
(Bulldozerでそれをやってる、という話ではなく)

スカラレジスタとSIMDレジスタ間のデータ転送がますます遅くなっていくように見える

最初は「2つスレッドでピークは分散するから、2コアでリソース共有したら、
いい感じにスループットとパフォーマンス両立できるんじゃね?」から
始まったんだろう。

やっぱ無理じゃん、ということで、FPUとデコーダの共有が落とし所で今に至る。
共有デコーダは未だに正体よくわからんが。

CMTに振るなら、あとは内部のバス、メモリ回りをどうするかだよな。

2コアで同じ命令を発行できるようにして冗長化してポストItaniumを狙う、とか？

この人たちまだいるの？
http://japan.internet.com/webtech/20060331/12.html
http://japan.zdnet.com/news/hardware/story/0,2000056184,20099773,00.htm

IA32との戦いの末やっと手に入れた安息の地を奪い取るつもりかー！

>>180
このスレをNaffzigerで検索だ！


Bulldozerはロードストアユニット等の足回り強化で実効性能を上げるつもり？

米FTC、独占的地位を利用し競争を阻害したとしてIntelを提訴
http://pc.watch.impress.co.jp/docs/news/20091217_336397.html
こんな時間に新着記事北


あと一応>>133の続き記事貼っとく

AMDのBulldozerの命令発行の仕組み
http://pc.watch.impress.co.jp/docs/column/kaigai/20091217_336298.html

FPの構成については
FMAC×2 + FMISC + FSTORE
あるいは
FMAC×2 + FMISC(FSTORE兼用)×2
だと思うけどね

いちおう2回の積和算に対してVPERMIL2PSを1命令発行できればSGEMMでもピークに近い
性能を発揮できる。理屈上はね。

amdと和解した後でFTCが出てくるとは
Nが裏で糸引いてるのはミエミエじゃないか

>Intelがコンパイラに細工をすることでAMD CPUの性能を引き下げたこと
まだこれ主張してるの?
フリーランチ気分が抜けてないなぁ

あぁごめん、AMDが主張してるわけじゃなかったんだね
この前和解したばっかりなのに何言ってんだと思ってしまった

フリーランチの話はCPUメーカ関係ない話だからお門違い。

知障コテが無意味に再臨しております

和解金払って心象良くしても結局提訴されるのな

和解金云々は小売りに圧力かけてIntelCPUだけ買わせて独占とかって件じゃないの？

>>163
Larrabeeの悪口はもうやめた方がいい

>>171
PentiumでLarrabee作っていたIntelの信者が言うと滑稽だな

団子が貶せば貶すほど良いものに見えてくる不思議

これがリバースハイパースレッディングの正体かな

2コア=1モジュール、と考えるとデコーダ共有が謎だったが、
1コア+α=1モジュール、と考えればいいような気もしてきた。

■後藤弘茂のWeekly海外ニュース■
AMDが次期アーキテクチャ「Bulldozer」と「Bobcat」の概要を明らかに
http://pc.watch.impress.co.jp/docs/column/kaigai/20091112_328392.html

AMDの次世代CPU「Bulldozer」のクラスタベースマルチスレッディング
http://pc.watch.impress.co.jp/docs/column/kaigai/20091120_330076.html

整数パフォーマンスを犠牲にする? AMDの「Bulldozer」
http://pc.watch.impress.co.jp/docs/column/kaigai/20091216_335956.html

AMDのBulldozerの命令発行の仕組み
http://pc.watch.impress.co.jp/docs/column/kaigai/20091217_336298.html

メインのCPUとサブのLarrabeeを
同列に考えてる奴がいるなｗ
AMDのブルはサブなのかｗ

>>185
AMD和解前からFTCは出てきていたよ。
むしろIntelはFTCとの本格抗争が怖いから、
先にAMD和解して心証を良くしようとしただけ。

それをどう受け取るかはFTC次第。

メインになる物をサブって

酷過ぎて発表延期して以来サブだよ

Larrabeeはサンプルチップ作った挙句の発売中止だから
単なる開発難航で延期のBulldozerとは格が違う

ｷﾘｯ

Bobcatは全くの新設計か
K7ベースでシュリンクしても1Wは無理だろうしなぁ

ブルの半分

FTCはAMD関係なく出てくるだろう。　昔分割された米の電話会社と
比べてもIntelの支配力は遜色ないかうわ回っているように見える。
電話会社と違って対外国の有力な企業だから
分割されないだけなんじゃなかろうか

ブルの整数ユニットはSIMD整数扱えるんだよね？

分割しなくても、手持ちのGPUがDX10対応のGMAだけだから今後苦しくなっていくよ。

そうやって現実を見ないからAMDはダメになった

>>208
今がGMAだけだとしても、将来はどうかわからんからなぁ。
まぁ統合されるGPUが来年でもGMA発展系みたいだから、
数年単位ではミドルからローの統合GPUでは上だろうね。
ただ、省電力性能などを上げない限りは押しが弱いので、
その部分がどれだけ改良されているかだな。

シングルスレッドを同モジュール内の2コアの両方で実行しようとしたときに障害になるのって、
要するにキャッシュコヒーレンシだよね？

だったら
�@スケジューラを賢くしてなるべく他方のコアの演算結果を参照しないようにする
　＋キャッシュ制御を賢くして、さらにL1・共有L2をInclusiveにする
�A2コアのレジスタ間を繋ぐクロスバーとかを作る
のどっちかで解決できるような気がするんだけど、どうよ？

素人考えだし、両方とも技術的に簡単じゃないってのは分かってるけど

> �@スケジューラを賢くしてなるべく他方のコアの演算結果を参照しないようにする
> 　＋キャッシュ制御を賢くして、さらにL1・共有L2をInclusiveにする
> �A2コアのレジスタ間を繋ぐクロスバーとかを作る

そんなコストかけて1スレッドの性能上げたいならissue数を上げてSMTにしたほうがいいだろ

>>209
Intelの現実こそ見るべきだな

米FTC、独占的地位を利用し競争を阻害したとしてIntelを提訴
http://pc.watch.impress.co.jp/docs/news/20091217_336397.html

最早悪の組織

>>211-212
めんどくさいことはわからんが、シングルスレッド性能上げるだけなら、
ターボブーストもどきでクロックを上げればいいんじゃないか？

つーかK8とK10でクロック当たり１割しか性能違わないじゃん
変なチューンよりK8に戻したほうが

クロックドメインも整数とFPで独立だったらﾜﾛｽ
Pentium 4はALUが倍速でFPUが半速だったんだよな

同じコアのレジスタファイルへの読み書きすらレイテンシが大きいんで演算結果をバイパス
（古い言い方だとアキュムレータ）するのが常套手段なのに、
よそのコアの演算結果を取ってくるなんざいくらレイテンシが大きくなるやら。
てなことで>>211は現実問題無理。

つーわけで>>214のほうが現実解。というか、本当にGPUでFP命令発行することを想定してるなら
クロックドメインの独立は当然なんだが。


つーか、どっちかというとベストケースで2コア分のSIMD演算ユニットを占有できるのが
シングルスレッド性能の要なんじゃないの？
FPは対Sandy Bridgeでは微妙だが、SIMD整数の性能のほうはXOP独自命令を使うことで
Bulldozerにもそこそこ優位性は得られるかもしれない、と思ったり。
（IntelはSIMD整数は256ビット化されないのでNehalemに毛がはえた程度）

気持ち悪いからさっさと死んでくれ

integer unit間にはレジスタやTLB等をコピー・転送する同期インターフェイスがある
他のinterger unitのキャッシュも参照して同期を取る
ってな感じで、integer unit間はかなり密接につながってる

>>215
K8からK10に戻すことと、"Bulldozer"となんか関係あるの？
K8からK10に戻して何をどーするの？

パフォーマンスコアは1%の改良を積み上げるしかない時代だと思うがな。

むしろK10が妙に遅いのが不思議だよな。ブロック図や構造を見るとかなり贅沢で
速そうなんだけど。実際はCore2とさして変わらない。というかcore2の速さが不思議なのか。

やっぱ、バカ正直に作りすぎなんじゃないのかね？全ての命令をまんべんなく
速くする、っていう思想なんだよなAMDのCPUって。

それよりコンパイラがよく使う命令順序パターンに最適化したパス回路を組んで、
ある組み合わせで命令が並んでいた場合に高速に処理できる、みたいな
仕組みを入れたほうが、効果的なんじゃﾈｰﾉ

特に最内周ループだとコンペアして条件分岐とか殆ど入ってくるし。

そこで>28でしょ

>>196
どういう事？

>>219
デコーダ共有により、その同期ユニットを使って純粋なシングルスレッドではなく
似非シングルスレッドができるって事かな。
ピークパフォーマンスは参照+時間差命令発行によるペナルティを考慮すると
純粋なシングルスレッドには劣るんだろうな、多分。

こんな事するなら、パイプライン据え置きのコアをたくさん積んで
デコーダーを共有構成にした方が良かったんじゃないのかな

それとも一定量のジョブを定量的に送り、各コアをアイドルにさせず常時に近いビジー状態にもっていけるからなのかな
ピークになる時はそうそう無いとの記事インタビューだから、絶対値となるピークパワーを捨て平均値の底上げを狙った一物なんだろうか
それでも、Bulldozerからみた前世代になる筈のK10よりはシングルスレッドは上げてくるんだろうけど

http://www.brightsideofnews.com/news/2009/12/17/why-the-ftc-lawsuit-against-intel-has-substance.aspx

Intel then designed its compiler and libraries in or about 2003 to
generate software that runs slower on non-Intel x86 CPUs, such as
[AMD] Opteron. This decrease in the efficiency of Opteron and other
non-Intel x86 CPUs harmed competition in the relevant CPU markets.

This imposes a severe performance handicap for all non-Intel CPUs.
This would not be an issue if Intel's compilers were rarely used,
but Intel's compilers very often produce the fastest binaries, particularly
on Intel parts, so many performance sensitive applications use them."

Worse, a number of benchmarks exhibit performance boosts
if the CPUID vendor name string is changed to "GenuineIntel"

>>222
演算ユニットか潤沢な分スケジューラ・リザベーションユニットが貧弱で逆に
決まったパターンでしか速くならない。
逆にIntelはスケジューラが強力（集中管理型）でその分ユニットを巧みにケチっている。

どこかとどこかのGPUと設計思想が似てるな。

,,・´∀｀・,,）っ-○○○さんへ

あなたのHPはどこですか？

これじゃね？
http://www.google.co.jp/search?hl=ja&q=%E3%81%A0%E3%82%93%E3%81%94%E3%82%84%E3%81%95%E3%82%93%E3%81%AE%E8%A6%9A%E6%9B%B8%E3%81%8D
http://www.google.co.jp/search?hl=ja&q=Second+Garage

>>226
微妙に嘘混じりの適当なことぶっこいているな。さすが。

>>225
つーか。意訳書いとけよ。訳して読むの面倒…。

よーはするに、Intel様ではないと性能が出ないコンパイラの話か。
ソフトの提供は昔からAMDが弱い部分として指摘されていた部分だな。
Intelのやったことは確かに酷い部分も含まれるが、
自社製コンパイラを他社製CPU使用時まで最適化させるのは、
開発費やその他諸々を考えると、致し方ない部分もあると思うんだが…。
そもそも他社製CPU時の完全動作検証を誰がやるんだ？

>>229
お前はアドレス生成ユニットが3つもあるのは何故だと思うね？


LSUの個数（2基）より多くしないといけないほどスケジューラが貧弱だからだよ。

>>230
ttp://www.4gamer.net/games/017/G001762/20091217005/
> コンパイラを秘密裏に再設計し，AMD製プロセッサでパフォーマンスが
> 出ないよう仕向けたうえで，その事実を隠したまま「競合よりもIntel製プ
> ロセッサのほうが高速」と消費者に説明した

自社に有利なバイナリを吐かせるだけなら問題なかったんじゃないかな。

ほへ〜
Second Garageの人だったのね
ちょっと納得

↓だんごさんへ↓
HPとか結構楽しんで読んでるんで
がんばってください

K8はデコードの段階でも依存関係の解消はしてるから
スケジューラだけ見て貧弱ってのもどうかと思う

スケジューリングなんて簡単に乱れるよ。相手がキャッシュである以上。

逆に聞きたいんだけどintelが自社製コンパイラでAMD製CPUに最適化する義務(というか保証?)って
どこが担保してんの?
AMDが金払ってるのならいざ知らず、そうでないのならどんな結果出されても文句言えないと思うのだが
相手が巨大企業だと問題になるのかね…

無論intelのそういう小細工が精神的に汚いという点に於いては異論はない
でも汚いけどビジネスとしては正当化できると思う

AMDがうちのコンパイラではintelもAMD良い成績なのにintelのコンパイラは性能低いんじゃないですか？
って皮肉を言えばいいのにね。

それはカッコイイ

>>236
独占企業には何かと手かせ足かせが付くから仕方ない。
それも含めてビジネスだからな。
Intelが弱小なら相手が不利になることもある程度は容認される。

詳細知らないから詳しい人いたら聞きたいが

　そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
Intelはこれをやっちゃったんじゃないの？

　そこを最適化してもIntelCPUじゃ変化なし、AMD CPUだと速くなる
これをやる義務はIntelにはないと思うがなー

AMDのCPUを調べて、パフォーマンスが出ないようにわざわざ書き換えた
そうして得られた不正な性能評価を消費者への自社製品の宣伝に利用した

この辺がコンパイラ関連の問題点
誰も「AMDに最適化しないのはけしからん」などとは言っていない

何にしても言いがかりだろ
AMDに高速コード吐いてやる義理も義務もねー

>そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
それをintelがやってはいけない理由が疑問という話なんだよ
AMD製CPUでもコンパイルが通るのは罠だと感じる

わざわざ遅くなるように書き換えたらまずいだろｗ

自動車会社がライバルの自動車を改造して性能を落として
「わが社のクルマと乗り比べてください」って言ってるようなもんだ

要は、詐欺

インテルのコンパイラはSSEの使用促進が目的で
当初AMDのCPUではコンパイル不可だったんだよ。
当然出来たバイナリは走るが。
AMDでコンパイル可なオプションが付いたのは10.0からだったかな。
インテル太っ腹じゃんと思って、おいらも有難く使わせていただいた。

>>243
> そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
> それをintelがやってはいけない理由が疑問という話なんだよ
> AMD製CPUでもコンパイルが通るのは罠だと感じる

意図的に悪意を持ってやるのがダメだと言っている。
基本は自分の得になることは問題なし、相手の損になることは問題ありがルール。

AMDのCPUの特徴の理解は難しくないし、最適化の目安も難しくはないだろう。
パイプラインやデコーダやキャッシュとかの大まかな構造は公開されてるしね。
つまり意図しない限りは滅多に苦手なコードを生成することはないだろうということ。

どうやらSSE2を使うか使わないかでもめてるみたいだし
互換SSE上の動作は我々の保証によるものではないので除外した(ｷﾘｯ
とでもintelが発言してしまえばそれで終わってしまうじゃない

故意にウェイトを入れる的な、意図的な悪意のあるコードを入れてるわけではないようだ
実際にダメとなればAMD製CPUでの動作は出来ないようにするでやはり収束

結論
自己資本コンパイラが必要

除外するならするでそれをきちっと言わないとな

　プリンタの互換カートリッジ封じってアメリカではダメなんだっけ？

>>248
（本当かどうかは知らんが）遅いとは言えAMDでも使えるコードを吐いてくれるとも言えるからな。
やはりAMDが両陣営の最適コードを吐けるコンパイラを作ってintelのコンパイラ開発技術のダメさを皮肉るのが一番いいと思うよ。

まあ仮にAMDがコンパイラを作って
わざとIntel製CPUで性能がでないようにして
比較広告したら、全然無問題だからな。
消費者が見抜けるかの問題。
iccなんて誰が見ても自社製品拡販のためのコンパイラなのにね。
他社のコンパイラメーカーに圧力かけて性能ださせないようにした
とかだったら問題だが。

>>247
「最適化」コンパイラだからな。
IntelがIntelチューンするのは当然。
逆に他社の互換命令まで面倒見なきゃいけない義務も義理も無い。

もうAMDの手を離れてんだからどうでもいいことじゃないか

> コンパイラを秘密裏に再設計し，AMD製プロセッサでパフォーマンスが
> 出ないよう仕向けたうえで，その事実を隠したまま「競合よりもIntel製プ
> ロセッサのほうが高速」と消費者に説明した

>>252
わざわざ遅くなるようにチューンして、宣伝に使ったら不味いでしょ。

iccで計測したと書いてあれば何の問題もない。
書いて無くてもあまり問題はない。よくある比較広告だよ。

>>252
今回の問題は「わざと遅くしていた」点が問題。
最適化は好きにしてくれてかまわない。

>>252
ついでに言うと「他社の互換命令」まで面倒観る義務もないが、
SSE2は「他社の互換命令」ではない。

アルゴリズムがインテルに最適化されていて、インテルのCPUだと速いってんなら問題ない。
AMDのCPUを検出したらわざと遅くする仕掛けを入れるなら、
そのコンパイラは独禁法にかかるかも。

WINDOWSがFIREFOXを検出して、わざと遅くするような事したら大変な事になるよ。

シェアNo.1のIntelチップ向けに最適化されたコードを効率よく実行出来ないなら
互換チップメーカーなんか辞めてしまえ。
自分の会社のチップ向けに独自バイナリを作ってくれるところと商売をすればよい。

効率よく実効出来ない＝AMDのCPUを検知するとわざと遅くするよう細工する

>>258
つまり最初からintel CPUでの動作だけを保証して他社では動きませんとしてれば問題はなかったと。
たしかに他社製では遅くなるという警告なしで遅くなるようにしてたら問題にもなるわな。

>>259
だーかーらー…AMDがソフトウェアに力入れていないのも悪いし、
Intel製のコンパイラだから"Intel製CPU用に特化している"のは問題はないわけ。
Intel製CPUと他社製CPUで、最適化されたコードと他社CPUコードを吐くのも問題ない。

だけど「わざと遅くするコードを吐き出すのは問題だろ？」って話をしているんだよ。

x86コンパイラなんて、VC++とgccとiccの3強でしょ
Windows用の商用バイナリを作るのに限ればVC++とiccの2強
（VC++が圧倒的なのはともかく）

x86 CPUの2強の片方とコンパイラの2強の片方が同じ会社で
かつ「1つの会社であることが消費者にとってマイナス」ならそれを問題とし
分社すべきではないか検討するパターンがアメリカじゃない

icc部門が分社化して、AMD最適化オプションとか
AMDとIntelブレンドコードオプションとかついているのを出してくれたほうが
消費者的にうれしいわけだしょ

Bolandの転落を見る限り、コンパイラで食っていける可能性は低いけどさ

llvm頑張れェ…

ここにいる連中はAMDの陳述書すら読んでないバカ揃いなのかよ

INTEL以外のCPUを検知すると意図的に遅いコードを吐くってのがコンパイラ問題だっての

Intelの遣り方は「まずCPUを検出すると遅いコードを吐く」
「そこからIntelCPUだけ最適化させる」なんでしょ
そんなんだから会社もハードもソフトもバグだらけなんだよｗ

>>265
AMDは遅いコードと言ってるが実態は自動ベクトル化を等の最適化を行わないだけ

>>267
AMDだけではなくて、FTCもその点は言及しているけどな。

>>255
>iccで計測したと書いてあれば何の問題もない。
俺もそれで終わりなネタだと思うけどね。

Intelが作ってるコンパイラを
Intelが秘密裏に（？）再設計して
AMD製プロセッサでパフォーマンスが出ないよう仕向けたところで
それはIntelの勝手。
文句があるならACC(AMD C++ Compiler)作れって話。

>>268
っで？

AMDのCPUに最適化してくれないことがケシカランなのか？
AMDのCPUIDか何かを検知してWait命令のようなものを追加してるのか？
本質はどっち？

普通に非ｉｎｔｅｌｃｐｕだとわざと遅くなるコード吐いてるのが問題の本質でしょ

そのことを明記していればそれでも問題なかったかも

そのわざと遅くなるコードと言うのが、単に最適化されていなくて遅いのか余分な命令を追加しているのか？
どっちと言う話し。

遅くなるようなコードと言うのは後者であり、前者の場合は遅いと言うよりは速くならないと言ったほうが良いと思う。

>>269
インテルが弱小企業ならそれでもおｋ

そろそろ印象と憶測ではなく実際のコードを見て話すべき頃かと。
本家スラッシュドットあたりで検証されていないかい?

>>276
その辺不透明なままでここまで盛り上がる不思議

両方持ってる奴がプログラム書くなり見つけるなりして比較すればええ

>>267
だから陳述書を読もうな
お前みたいなワナビーが「実態」とかヘソ茶で噴飯な妄想は良いから

>>273
コンパイル自体はどこのCPUでも普通にやる。
CPUIDでIntel製じゃないのが分かると
SSE使ったコードを吐かない、という事っぽい。

「遅くしてる」というより「速くしない」と言う方が正解。

>>280
どっちを基準に取るかでその表現はどっちにでもなる。
インテル側はSSEを使わないことは「早くしない」だろうし、
AMD側から見れば意図的にSSEを使わないようにして「遅くしてる」となる。
が
> コンパイラを秘密裏に再設計し
再設計とあることから、今まではしっかりSSE使ってたものを、使わなくしてる
わけだから、「遅くしてる」と言うのが妥当だな。

SSE使う方が遅いCPUだってありうるわな
自社製以外は眼中に無かったで終了

>>281
なるわけないだろ。

intelCPUではないという理由だけで存在する機能を使わせないコードを吐くのは
明らかにインチキ。
だったらintelもSSEを使わないコードで勝負するべき。

>283
言ってることがわけわかんねーんで日本語で頼む

ニトロ入れる機能があるんだからどっちともニトロ入れて比べるか、
もしくはどっちともニトロ抜きで競走しろ

>>256
>今回の問題は「わざと遅くしていた」点が問題。
わざと遅くしてないぞ。PC Watchの記事の書き方が糞。
Intel純正かどうかを判別して純正以外では最適化をしなかっただけ。
純正品でもアーキテクチャは異なるし、他社の最適化なんてやってやる義理もないだろ。
記事書いてる奴のレベルそのものが低い。

そもそもSSEはなくても同じ計算が実行できる拡張機能なわけで、
他社製のCPUが同じ命令セットをサポートしているかどうかは完全にIntel純正コンパイラのサポート対象外。
サポートしていない互換品までむしろ面倒見ている方がむしろおかしい。

SSEはライセンスはIntelがAMDにライセンス供与しているから、
ライセンス料金が発生していたら、Intelのやり方は、
「金だけ奪い取って仕事をしなかった」事でもあるよな。

どこのやくざ企業だよ。

AMDのCPUでSSEの自動最適化を行う場合は、
AMDのCPUであることを確認し、
さらにSSEをサポートしている世代であることを確認し、
さらにその世代がどんなSSEユニットの構成仕様なのかに合わせた最適化をしなければならない。
従ってコンパイラがAMDのCPUについて既知じゃなきゃいけない。

ICCが勝手にSSEに最適化するっても、対象のCPUがIntel以外であれば何がベストなのかICCにはわかりようがない。
AMDがIntelに対して全ての情報を提供しているわけでもないのにIntelがAMDのCPUの内部を
詳細に知っていてベストな最適化ができるはずもない。もちろん競合だからしてやるだけ損。
そしてIntelからすればユーザが安全に自動最適化の効果を享受できるようにするなら、
Intel純正以外では最適化コードを実行できないことにするのがあたりまえの対策の一つ。

という単純な問題をうまく
コンピュータに無知な層を相手に騙して
利用しているのがAMDの法務サイドの戦略だと思うね。
Intelからすれば他社に合わせて純正コンパイラの拡張命令をサポートなんて土台無理な話なんだが。

それを隠してが問題なんじゃね？

この話題って昔この噂が流れたときに散々やっただろ
ループしすぎ

ソフトウエアをかいたりハードでも製品開発したことあるやつなら
サードパーティの製品をサポートするということがどれだけ馬鹿で無謀な取り組みかは
理解できるはずだが。他社製品というのはサポートしようがないんだよ。
自社でもサポートの範囲は企画の段階で厳密に決めてメンテナンスしていくわけで。
まったく話がばかげている。

>ライセンス料金が発生していたら、Intelのやり方は、
>「金だけ奪い取って仕事をしなかった」事でもあるよな。

ワケ分からん。
仮にSSEにライセンス料があったとしてもそれは使用料であって
自社製コンパイラでAMDのCPUをサポート対象にするかは関係ないわけだが。

つかAMDもコンパイラ作ればいいじゃん　
自社CPUだけガリガリに最適化するやつ
全くめんどくせえ。

>>293
その場合は、動作保証対象外と明記すればいい。
そんなもので、性能比べてるから問題になってるんでしょ？

>>295
あのさ動作保証外なんて表記にはほとんど意味ないんだが。
わかってないやつがうける。

例えばAMD製のCPUで殆ど最適化コードの動作検証もしていないのに
たまたまバグやエラッタでICCでコンパイルしたSSEのコードをAMD製CPUでユーザが
動作保証外なのに勝手に実行したら、現実問題としてクレームになって
無駄なコストが発生するんだよ。
Intelは趣味で最適化コンパイラつくってるわけじゃないし、
AMD製CPUに対しては余計な不具合をださないことが先決なの。
というか企業の製品ってのはそういう考えの集合。

具体的に性能を比べていたっていうソースはあるのかねぇ…。
どうせある程度CPU事情を知っている側からするとお笑いレベルの言いがかりなんだろうけど。

Intel「AMDのほうが速くなってしまうエラッタが見付かったので潰して再設計しました」

Intel以外のCPUを見つけると…
1,拡張命令を使わせない2,意図的に処理速度を下げる

1は言い訳できるけど、ここで問題になってる2はいかんでしょ〜
思いのほかはやかったから細工したのか？

どっちも言い訳できねーよ。
比較にならんじゃないか。

でも、今回のは独禁法絡みでの主張だから、intelとAMDが互角の状態なら問題ない行為が、
問題になるってことなんじゃないの？
この主張が法廷で認められるかはわからないが。

ともかく決着がついてから判断したほうがいいね
素人がどうこう言っても仕方ない

そんなことより早くブルドーザー出してくれないかなー
32nmプロセスのＣＰＵで1年遅れるのはやはり痛い

いつまで経っても「コンパイラが最適化しないだけ！」と強弁するワナビーが減らないようなので
AMDの訴状から引用しておくが

>（「CPUID」と呼ばれるコンピュータのマイクロプロセッサーの特定する機能を利用して，
>プログラムが起動された時にコード・パスが決定される。）
>その設計上，コード・パスが公平に作成されていないのである。プログラムが「Genuine Intel」の
>マイクロプロセッサーを検知した場合，プログラムは完全に最適化されたコード・パスを実行し，
>最高効率で稼動する。しかし，プログラムが「AuthenticAMD」のマイクロプロセッサーを検知した
>場合は，プログラムは別のコード・パスを実行し，プログラムのパフォーマンスを下げるか
>クラッシュを引き起こす。

これのどこが最適化してないだけなんだ？

MSですら他社のブラウザに配慮して平等に選択するようにしているのに、Intelときたら…。
何をやってもIntelはイチャモンつけられるくらいの独占企業だからな、
いい加減おとなしく従ってろボケと言いたい。

それと淫厨はいい加減ウザイからvsスレに篭ってろハゲ。

絶妙な文章で吹いたw
まさに自分の書いたことが内容は損ねずに、
全くそれが悪いものであるようにかかれているな。

>>303はよくよめばその通りの動作だよ。
CPUIDという機能をもちいて動作が保証できないCPUでは最適化コードをとばす必要があるんだ。
それをパフォーマンスの低下させるとか、クラッシュさせるとか表現は
ユーザサイドの主観から見た超解釈によるものだからな。

Intelだと使う、AMDだと使わないって場合でも相対的に性能に差はでるね

>>302
45nmでは15ヶ月くらいだったんだからこれでもまだマシ

>>306
いいかげんにしろこのキチガイ

まあここの馬鹿なアム厨達には理解できないだろうけど、
もう一度かいてあげよう。

IntelはAMDのCPUは知らないから、AMD向け最適化コードなんてものはそもそも生成しようとおもっても
できないんだよ。だから仕様がわかっていてどう最適化すればよいかもわかるIntel純正のCPU以外では、
殆どのx86で問題なく動く最適化のほとんど入っていないないコードを実行するか、
警告をはっするなりして抜けるしかないの。
>プログラムは完全に最適化されたコード・パスを実行し，
>最高効率で稼動する。しかし，プログラムが「AuthenticAMD」のマイクロプロセッサーを検知した
>場合は，プログラムは別のコード・パスを実行し，プログラムのパフォーマンスを下げるか
>クラッシュを引き起こす。
この文はIntelコンパイラが悪者であるかのようなトーンでかかれているけど、
内容だけをつみとればなるほどあたりまえのことだよ。

まあ5年、10年あとにわかってくれればいいや。
今までもそうやってAMDのスレの内容は改善してきたわけだし。

ここってVSスレですか？

>>309
AMDが両陣営対応の最適コードを吐くコンパイラを開発すれば万事解決するしイニシアチブが取れると思わない？

つーかさ、AMDがCPUIDでGenuinIntel返すようにすればいいだけじゃね

AMDの次世代CPUについて語ろう

コンピュータをわかってない人たちをうまく騙す、
大嘘は書いてないっていう、
いかにもな面白い文章だな。

>>310はID:E6GeZaRpは真性キチガイのインテル信者かよ

まあキチガイに分かるかどうか定かではないが>>303を言い換えてやろう

あくまでも問題なのは「INTELじゃないとわざわざ遅くなったり不安定になるプログラムを吐くコンパイラ」であって
「INTELに最適化されたコードを吐くコンパイラ」ではない

キチガイワナビーの脳内では等価なのかもしれないが、世間一般では等価ではない
理解できるか？

真性キチガイに言っても無駄かもしれないが連投すんな
書きたいことは一回で書け

その他社製品が動かなくてもインテル的には当たり前な状態で
製品比較してうちの方が優秀なのだ、って比較になってないし
なんかちょっとおかしくね？って話なんじゃないのかね。

>>313
必要ないな。
AMDがAMDに最適コードを吐くコンパイラを開発すれば事足りるだろ。

インテル最適コードvsAMD最適コードで比べれば性能は一目瞭然だ。

>>298
むしろ普通にコンパイルしただけだとAMD CPUの方が早かったので、
腹いせに"プログラムのパフォーマンスを下げるかクラッシュを引き起こす"ような
プログラムをはき出すことによって、ようやくいまの性能差を引き出せたのかもしれない。

よくわからないがAMDが自社の製品に対する最適化コンパイラを出してないのか？

各アーキで有効なコードをコンパイル時に複数生成しておく。
そして、実行時にCPUIDで判別してそのCPUに最適なコードへジャンプするようにする。
当たり前のことが書いてあるだけ。
つーか、一気にアム厨がわいて出てきたな。

INTELコンパイラを使うと「元のソースには存在しない」CPUIDチェックルーチンと
非INTEL環境だと遅く不安定になるコードが含まれるプログラムが生成されます

これがガチキチインテル信者(>>322=ID:E6GeZaRp)のフィルターを通すと「最適化してないだけ」となります

おそらく日付が変わっても、壊れたオルゴールのように同じことを叫び続けることでしょう

>>322
つ スレタイ

このスレの最古参級であるが
未だにこんなコテコテのアム厨達が生き残っているとは予想してなかったな。
大分レベルがあがって現実的になってきたとおもってたのに…。
>>324 Intelのスレもそうであるが、このスレも別にマンセーするスレではないんだが。

どこでも馬鹿にされる可哀想なﾃﾍ権田

>>323
>これがガチキチインテル信者(>>322=ID:E6GeZaRp)のフィルターを通すと「最適化してないだけ」となります
君のような無知・無能のお馬鹿くんが、最適化していないだけなのを誤解するようにわざとかかれてるんだが。

ID:E6GeZaRpはテヘゴンだと白状したので通常の措置を実施しました

327 名前： あぼ〜ん [あぼ〜ん] 投稿日： あぼ〜ん
あぼ〜ん

ああ厨スレから
馬鹿が大量流入しているのか。
なるほどどおりでいきなり馬鹿度があがったきがしたぞ。
馬鹿がうつるからこっちくんなw

ﾃﾍはもっさりスレに帰りなさい

>>321
どうせどこも使わないから、MSやPGIに実機と情報渡して最適化させてるだけだと思う。

SSEが有効なCPUならSSEを使うようにすれば良かったのに、
CPUの名前だけで分けたのがまずいんじゃないの？

CPUにSSEが有効なbitが立っているかだけ確認してSSE使用の有無を決めるのでは無くて、
CPUの製造元で判断するのがおかしいと言う。

以前どこかでCPUの製造元をIntelに変えたら性能が上がった(SSE等の命令が使われるようになった)と言うのを見たことがあるから、
CPUの製造元を見てからSSE等の判断をしていたのだろう。

まあほんとに「最適化してない」程度なら世界中の公取が動いたりしないわけでｗ

インテルに最適化したコードでいいから普通に使わせろ
意図的に使わせないようにしといて性能比較とかふざけんな

ってことでしょ

CPUIDで判断してんなら拡張命令とか関係なくね
最適化がどうとかちゃんちゃらおかしくね

自分にチューンが悪いんじゃなくて相手にデチューンが悪い
という話を曲解してまでインテル擁護するのはどうかと。

>>314
それ、やったらまずくね？ｗ

自分は、どちらかというと
iccが出力するコードは、普遍的なCPU性能を測るのには適しませんよ。
特殊な条件下での出来事を、普遍的なことのように錯誤させたらダメですからね。
ということが論点なんだろうと思ってたけど、よく分からなくなってきた。

その相手にデチューンという話が個人で割れてる印象
もちろんAMDやintelの間でも
intel曰く互換CPUの互換命令にまで最適化する必要はない
AMD曰くSSE2使ったコード吐けよおらぁぁぁぁぁ

要らないwaitやら故意にクラッシュを引き起こすコードなんてすぐにでも
ソースとして引用できそうなものだけど上がらないね
これをAMDが証拠としてきちんと提出すべき

なんで和解した現在、AMDが証拠を広布せにゃならんのかね

アホだろ貴様

抽出 ID:E6GeZaRp (18回)

あぁそうか、FTCが提訴という前提を忘れてた
悪意のあるコードが上がると良いね

http://yro.slashdot.org/comments.pl?sid=155593&cid=13042922

金を取ってる商品の割には頭の悪いコードだが、
サポート対象外のチップ向けにgenericに書いていると言われればそれまで。
誰も悪意は証明できまいよ。

いやさすがにwaitやらは悪意があるだろう…
クラッシュを引き起こすと主張するに値するコードにも興味がある

waitとかクラッシュ云々は妄想じゃないの?
ソースきぼんぬ。

>>331
intel謹製コンパイラが問題だという以上、つかわなくったって出すべきだと思うんだけどな。

iccって今時 rep movsdなんてコードを吐くのか。
プリフィックスつきループ命令使うよりコンペアブランチの
ほうが早いはずなんだがな。

SSEあるかどうかもわからん他社のCPUに
SSEコード実行させるほうがおかしいだろw
故意に最適化してないってのは最適化コード動作させられる
保証がないからだろ。

>>345
iccはキャッシュサイズなどを重視して最適化するから
目先の所要クロックとかで判断しちゃいかんよ。

rep プリフィックスつきループ命令ははキャッシュサイズに
関係ありませんから。

いってみれば旧世代のCISC命令で、デコードと実行に時間
がかかる。x86アセンブラで書くならほとんど使わないよ。

Pentium III向けにも同じコードを吐くようだから
特に他社を意識したわけじゃなさそうだな。Pentium 4向けには最適化したようだが。

>>348
ぶっちゃけ今時前後のコードをみていかないと何が最適かはわからん。
iccの全力よりも常に早いコードを書けるというやつが実際に
証明しながら論じるなら説得力があるが、いままでに
2ちゃんねるでそんなやつは見たことがないからな。

結局のところ、
別の会社のコンパイラに他社のCPUで性能がでないように
圧力をかけた、とかでないかぎりあくまでも自社のコンパイラで
どう作ろうが自由なんだよな。
論点は比較の方だと思う。
会社で開発とかやってりゃ、他社を助けるようなものは排除する
って考えは当たり前にやることだし。

>>345
シンプルな命令の組み合わせの方が速かったのは初代 pentium のみ
pentium pro 以降は素直に便利な命令を使ったほうが速くなるよ
レジスタの消費を抑えやすい点でも有利だし

>>348
rep 系の命令は専用の回路があったりするから速いこと多いよ
一度デコードしてしまえばループが終わるまでデコーダに負担かけずに
実行し続けられるから

連投してインテル擁護してるところを見るにID:clYNpsbwはテヘだな

テヘじゃないよ。
信者の脳内ではインテル擁護すればみんなテヘなの?

>>351
　だったらそもそもAMDだと動かないか、動くにしても警告でも出す
ようにすれば筋が通るんじゃない？

いやテヘだろ
1回で書けないまとまりのない脳構造だし

>だったらそもそもAMDだと動かないか、動くにしても警告でも出す
>ようにすれば筋が通るんじゃない？
それもいいが、
それはそれで故意に動かさないようにしたとかいわれるの必至だろw
これでもいれわてんのに。

AMDが最適コンパイラ出せばいいのにね。

2言目にはテヘとかいう妄想馬鹿はいい加減AMDスレから消えてくれないか?
脳内テヘと一人で闘ってろよ。書き込みすんな、クズが。

>>357
　これでも、というかどう考えても今の状態の方が悪質でしょ。

pen4は特性上repを好んで多用する
phenomでは、ブロックサイズがpage-size〜half of L1ならrep使え、ってことになってるな

>>332

> CPUにSSEが有効なbitが立っているかだけ確認してSSE使用の有無を決めるのでは無くて、
> CPUの製造元で判断するのがおかしいと言う。

そもそもCPUID命令は仕様上、製造元固有の実装という事になっている。
CPUIDの機能ビットでSSEの有無を判断する場合は、
その前に必ずCPUIDが返すベンダーストリングが
"GenuineIntel"であることを確認する必要がある。
ベンダーを識別せずにCPUIDの機能ビットを利用する事は仕様違反。

クラッシュ云々は上の方で出てた訴状の内容の主張ですね
waitに関しては妄想かも
スレッド間の同期のためのものだとしたら笑い話だけど

ネット探索してたらAMD製CPUでもgccでコンパイルした物より
iccでコンパイルした物の方が早かったなんて例も報告されてるみたい
intelと同等に最適化しないと今後も同じ流れが繰り返されるんじゃないかな
少なくともこのスレでは

まずベンダーを識別してもいいが、それはあくまでベンダー名の識別であって
機能の実装をそこで判断するのは仕様に則った判別方法なの？
もしそれがOKだとしたらSSEのビットなんて最初からいらないでしょｗ

和解したから
良いじゃないどちらでも
AMDもインテルも納得してんだろ

GMPで円周率を計算すればよろしい

つーかチップセットで閉め出されたNVIDIAが腹いせになんか要らん事言ったんじゃねー過？

訴訟のことはもういいやと思うわけだが
BobcatがどうやってTDP抑えるのか気になるなあ

>>367
仕返しにチップセット不要にされるな

BobcatコアとRV830改あたりを使ったFusionが楽しみだ
Atomはマーケティングの都合で性能を上げられないみたいだし

>>369
仕返し以前にその予定じゃん

IntelプラットフォームのマザボからPCIEｘ16が消えたら笑えるんだが

そんな高リスクな真似は無いんじゃ?
熱密度的な観点からGPUを内蔵する世代でも
ディスクリートは止められないと思う
その際に上手く協調できるかが課題
その点AMDはリスク低そう&強調するテクニックkの開発スピード上がりそう

QPI直結Larrabee vs HT直結Radeonの対決になるとか

ディスクリート廃止っつーか
「うちにはﾗﾗﾋﾞがあるんだもん！」とか言ってそれしか着けられなくなる可能性も無くは無いｗ

かぶった

確か過去にはAMDでも適切な拡張命令に即して実行可能なコードを吐くように設計されてたはず
いつからかそれがなくなったからたたかれてたはず

>>358
ホントその一行で終わる話。

pgiが出してただろACML最適化を謳ってたものの
だれも使わなかったんだろ
シェアが小さいから

>>373
拡張スロットは実質GPU専用になりつつあるし
スロット削ってGPU専用ソケットつけても良いような気がしないでもない

SSEやSSE2はAMD64(互換のIntel 64)の基本命令なんだから、存在の有無なんて…という理由は苦しいと思うが?
ICCが出たのはいつで、AMD64が出たのはいつよ。

ttp://ja.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
＞実行に必要なライブラリやリンカなどは付属していないため、他のコンパイラの環境に寄生した形で実行される。
何だただのマルウェアか

>>362
x86命令自体が製造元でほぼ固有の実装になっているが…。

>>377
そうもいかないんだよ。コンパイラが二つあってもソフトウェアベンダー側が、
IntelコンパイラとAMDコンパイラ双方で動作確認しなければならない。
手間が二重にかかりるという最大の欠点がある。

「ソース書いた。コンパイラで書き出した。ではそのまま出荷！」

こうはならないんだよ。ベンダー側の手間暇も考えると独自コンパイラを提供しても、
シェア率の低いメーカー側のコンパイラはやはり使われないか、
やっぱりIntelコンパイラだけしか使われないという状況が生まれてしまう。
そのためにはAMDがシェアを上げなければならないが、Intelはそれを邪魔している。
様々な意味で今回の「Intelの悪意」は影響しているんだよ。

つか。CPU固有で最適化される鯖向け市場でのOpteronの頑張り様を観れば、
一般向けであそこまで差がつくのはありえないってーの。

> つか。CPU固有で最適化される鯖向け市場でのOpteronの頑張り様を観れば、
> 一般向けであそこまで差がつくのはありえないってーの。

このへんが信者は現実が見えてないと言われる所以。
一般消費者は(一番売れてるメーカーの製品で用が足りるなら)
わざわざ安かろう悪かろうなマイナーメーカーは選ばない。

ICCはIntelの製品だしどう作ろうがIntelの自由だろ。
AMDの製品で動かしたときの動作に文句だれる信者は
頭がおかしいw

こんなくだらない電波論が独禁で仕方なく取り扱われるあたり、
実際Intelは独占企業のわりにMSなどとくらべてあまり悪いことはやってない馬鹿正直なメーカー
だったんだろうな。

Pentium4、D時代に細工、妨害なんてしなけりゃあ提訴なんてされずに済んだものを

>>382
OpteronってQ3で10%切ってPC向けよりシェア低いけど、頑張っているの？

>>387
シェアしか見てないの?

５．米FTCがIntelを提訴
http://www.geocities.jp/andosprocinfo/wadai09/20091219.htm

>>388
シェア下がっているのに頑張っているというのは、スパコンでTOP500で上位占めてるから？

SSE最適化のためだけの寄生ソフトからAMDを邪魔するためだけのマルウェアへと進化しました

ICCは実際あまりつかわれていないないから、AMDに不利なコードをいくら吐くようにつくっても
AMDの邪魔は宣伝効果以外では殆ど無理。

言い逃れは無理と見てトーンダウンするテヘであった

ICCはあくまでもIntel CPUの世代や機能の有無にあわせて最適化コードを生成するだけ。
AMDがIntelに自社CPUの情報を提供してICCで最適化コードを実行するような契約を取り交わしてるわけじゃないのに、
AMD向けの最適化コードを生成するのなんて論理的に無理なの。
リバースエンジニアリングしてライバルCPUを引き立てるなんてするわけもないだろ。
今まではIntel CPU向けに最適化したコードがたまたまAMDのCPUでも速いってだけで、
AMDのCPUはAMDが自由に設計しているのだから、Intelにとってはそんなのコントロールの範疇外。
その辺の事情を、プログラム書いたこともない馬鹿が理解できないで世界中でさわいでいるだけ。
Atomの話題と比較してもそうだがAMD周辺からはなぜか昔から電波論がでやすい。
世界中にアホな信者が散在している証拠。これは改善されるべきw

テヘ認定厨きたな。
テヘ認定厨は存在そのものが荒らし。
ここは君のような低レベルがくるスレではないぞ。

SPEC CPU2000の時代ではAMDが登録する結果でさえicc使っていたからiccによる嫌がらせは
アーキテクチャを超えて比較しようとする専門家に対してちょっとだけ有効だったりする

＞AMDが登録する結果でさえicc使っていた

ほかに使えるコンパイラがなかったの

>>383
ﾜﾛﾀｗ　現実観てねぇｗ
一般消費者はCPUなんてみてねぇよｗ
システム構成が理解できるならば、
安物Celeron機+糞オンボードVGAマシーンが売れる理由がねぇｗ

いやむしろ一般消費者はCPUはおろか
速さにそんな執着ないだろ。
廉価版CPU+オンボードVGA
で不都合がある奴の方が今時珍しい。
つか上位はコストパフォーマンス悪いから。

>>390
シェアだけで全てが見えてるの?

AMDがコンパイラ出せって言うのも一理あるけれど、
AMDのプロセッサが自分で最適化させやすいというのもあるんだけれど。

しっかし、なんで「AMDのプロセッサを含めて最適化」論が出てるの?
前の書き込み見てないの?

>>383
>わざわざ安かろう悪かろうなマイナーメーカーは選ばない。

思ったがその「安かろう悪かろう」のメーカーに負けそうだから、
コンパイラに細工して、負けないようにしているIntel様ってことでOk？

>>399
シェアだけとは思ってないが、他の部分でOpteron頑張っているというなら教えてくれよ。
俺はスパコンTOP500で上位占めているくらいしかぱっと思い浮かばないが。

Opteronがクライアント用プロセッサなら話がわかるんだけれど、サーバー用プロセッサを用いる必要がある他の分野っていくつあるの?

>コンパイラに細工して、負けないようにしているIntel様ってことでOk？
FTAやAMD fanboyの認識はそれであってると思うよ?
当のAMDは今どう思ってるかは知らない
事実がどうなのかも知らない

http://h2np.net/pi/pi_thread.html

別にどっちだろうが速度はでるんだよ

まだ同じことガタガタいってんのか

>>341
これは流石に・・・
つーか、__intel_fast_memcpyのコードのスループットはガチ

>>352
ストリング命令は流石に今時使わないでしょ。

とりあえずAMDとINtelのシェア差は性能じゃなくIntelの悪質な嫌がらせによる差ということだね。

ICCってそんなに速くないよ。SIMD周りだけは速いケースが多いけど。

ホラ吹き団子登場か。

Bulldozerに関してはAMD独自命令使わないと半分程度しか性能発揮できないような設計になってるから
そういう意味で言いがかりは通用しない

BulldozerはSSE5をやめてAVXにした。
つまりICCの批判をした一方で、AMDはIntelのインフラにまたしても便乗しようとしているわけで
やってることが矛盾しているだろ。
それとも好き勝手SSE5でっちあげてり、AVXに急遽変更してみたり勝手にやってるのに
ICCが最適化に対応しなかったらまた信者さん達は批判するのだろうか。
AMDはAMDのアーキテクチャを勝手に決めることができるし、
Intelは自社のコンパイラの仕様を勝手に決めることができる。当たり前のことだ。
BulldozerのクラスタードアーキテクチャはIntel CPUの設計からかけはなれているから
さすがに自社開発でコンパイラを用意するか、協力者をつのらないかぎりはまともに性能でないからな。
IntelはICCでAMD CPUではAVXコードを実行させないこともできる。もともとSSE5かAVXかって気まぐれで
勝手に決められているものだからな。

読む価値無し

＞IntelはICCでAMD CPUではAVXコードを実行させないこともできる。

ん？CPUIDで判別して？

ブルはAVXのスループット半分なんだから素直にAVX駆使した方が性能下がったりして

CPUIDで判別してだな。
そもそもAMDがAVXを上位下位ふくめてどこまでサポートしてくるのか
実際ものがでるまで正確なところはわからないので、
最適化コードを実行させなのがIntelとしては一番楽で安全な対応なの。

それだと米FTCの餌になりかねんな

ID:clYNpsbw はiccがAMD CPUに対応すると何か困るわけ？

>412
「俺はおふくろを押し倒して男になった」まで読んだ。

論点ずれてね？
もしAMDが最適化コンパイラ出してても、インテルのデモでは
インテルはiccをAMDのCPUに使ってただろうし。

CPUのベンチと称しながら、最適化されたvsされてない、
という本来比較すべきじゃない対象を
比較したのが問題なんだろ。

>>415
確かにIntelコンパイラの吐くコードだとAVX使うとかえって性能落ちそうな箇所があるよ。

俺の予想だとvbroadcasts{s,d} は鬼門
Intelの場合ロードユニットに128ビットまでのブロードキャスト機能が組み込まれてるので
128ビットだけならシャッフルユニットを使わずにブロードキャストできる。
256ビットのロードはvinsertf128相当のμOPでおｋ。

[A]
↓Load (with Broadcast)
[A A A A]
↓Permute 256
[A A A A A A A A]

このへんは謹製シミュレータで確認した。　


しかしBulldozerはバックエンドは旧Bulldozerとほとんど変わってない（内部128ビットのまんま）
バックエンドがAVXに最適化されてないとすると
スカラ値をロードしてシャッフルユニットで各要素にコピー、
さらにそれをYMM上位にコピーで、合計3マイクロオペレーション。

A
↓Load scalar
[A * * *]
↓Permute 128
[A A A A]
↓Move (to YMM upper)
[A A A A][A A A A]

というわけで256ビット単位で処理すると単純に128ビットの2倍＋αのスループットサイクルを要する。

>>404
"FTA"や"AMD fanboy"ってなに？

FTAはFTCのミスじゃね？
fanboyは厨や信者に相当する英語での表現。

Pentium Mすら認識しなかったのにぶち切れて、スタートアップルーチンとか完全に自分で書いてたが
他のコンパイラの質がよくなったのでICC自体使わなくなった

抽出 ID:clYNpsbw (17回)

　ｉ関係者乙

気持ち悪い低脳の包茎が暴れています

Pen-Mが出た頃のICCって、プロセッサ・ファミリ識別子が6のプロセッサは
SSE2に対応していないと決めつけ、
Pen-MをSSE2非対応CPUとして認識してたな。

>>427
IDがAmD

>>400
理想を言えばAMD謹製コンパイラの早期投入だろうが
単に速度比較するなら素の状態のgccあたりでやればいいだけ。

アレなんか良くも悪くも教科書通りの最適化するから
機種依存を排した比較にはもってこいだろ。

つ AMD x86 Open64 Compiler Suite

>>379
それなんてAGP？

現実的には圧倒的シェアのビジュアルスタジオプロフェッショナル
でコンパイルされたバイナリがほとんどだから影響は限定的だな。
ただ、インテル自らプロモーションする場合はICCでの比較になる
はずなんで、そういう意味では問題になる。

低省電力モデルはどうなってるの？

>>432
それこそAMD XOP非対応だぞ、と。

AVX対応は、直ぐあとにLNIが控えてるからどこも本腰では対応しないと思うから気にする無駄だろう。

問題は、ほとんどの既存ソフトでSandybridgeが4コア/8スレッドで、来年出る6コア/12スレッドのGulftownに性能で勝てないことだろ。
Bulldozerの真の敵は、実はGulftownじゃないだろうか。

FTCはAMDよりnVIDIAに対する嫌がらせを追求したんだと思う。
とはいえ、FTC側は今までトンデモナイ金額を請求させることで
仕事の評価が成されるとお偉いさんは考えてる節がある。

だからAMDのネタを持ってきたんだよ。
おそらく、負けたら史上最高額の金額を請求されると思う。
歴史が繰り返されるならね。

SandyBridgeの4コア版はメインストリーム用でハイエンド用じゃないんだから、
ハイエンド用のGulftownに勝てなくても問題はないんじゃないの？
ハイエンド用の8コア版が別にあるんだし。

Bulldozerの真の敵は内にある。
まずは十分な性能でスケジュール通りに出すことですよ。

前例を鑑みると順調に遅れるはずだな

ぶっちゃけ「既に遅れている」んですけどね。
そもそもは今年に45nmで開始する予定だったアーキティクチャ。

とりあえず2011年前半に生産開始する「予定」だけどな。

半期ぐらいズレるのはAMDのデフォ。

未来予見力に定評のあるムーアさんのかんがえたbulldozerに頼るしか…！

あんまり早く出るとK10の影が薄くなる

早く出すぎてもプラットフォームが混乱するだけどな。
IntelなんかCore2とi7/i5が併存していてカオスだぜ。

Bulldozerの2011年延期はある意味正解だと思う。
おかげでデスクトップはおろかノートにも展開できた。
K8が一部残るけど、K10の機能削減版と思えば気にもならない。

逆にIntelのCore2は噂じゃ2011年以降も現役らしい。
まるでどっかのG92みたいだ。

32nmに完全に移行できないとLGA775を排除できないからね。
45nmでの廉価版Nehalemの開発失敗でプラットフォーム移行計画がぐだぐだになったからな。

>>443-444
いや。もう。さっさと出してK10なんて跡形もなくしてくれ。
ヤツは頑張った。それこそ生き馬の目を抜くCPU業界で、
10年も戦い抜いたヤツに、まだ頑張れとか。鬼か？

読み物
ttp://ascii.jp/elem/000/000/484/484074/

>>446
それはメニーコアで期待されて頑張っているクラシックペンチアムさんに失礼だろ。
あっちはこれから老体に鞭打ってIntelの将来を背負うんだぜ。

ATI Stream対応C++言語コンパイラ登場(CUDAも)
ttp://pc.watch.impress.co.jp/docs/news/20091221_338330.html

＞対象のC言語の記述はforループによる繰り返し制御構造
forはループ終了の判定が分岐だからトリッキーでGPUは苦手だ、とかどっかで読んだけど
何だよ結局のところ単純なforならむしろ大得意ってことじゃん

バカ正直にCのソースと相似の構造をGPUの命令で作ったら遅いんじゃないのか
GPUの機種を検出してそれにあわせて自動アンロールとかするとみた

GPUのコンパイラでfor文をコンパイルすると、ループの規模が
小さい場合は分岐判定せずに全部アンローリングする力業。

ループの規模が大きい場合でも一定量をアンローリングして、
そのブロックの繰り返し。極力分岐を減らしパフォーマンス低下
を防ぐようなコードを吐くようになっている。

FTC絡みかどうかしらないけどIntelは待ってくれてる、AMDは気合入れとけよー
http://www.brightsideofnews.com/news/2009/12/21/intel-tick-tock-slows-down-sandy-bridge-slips-into-2011.aspx

>>453
待つ必要ないからとっとと出せばいいだけ。
AMDに配慮とかありえないから心配するな、単にSandy自体かチップセットの開発が遅れているだけだね。

まあ、インテルのチップセットは最近バグ多かったから、時間かけてるんじゃないの？

Intelもヘテロにむかうの？x86のメニーコア路線じゃなかったっけ

>>455
Intel・・・メインコア 　Nehalem(x86)→SandyBridge(x86)→Haswell(x86)→???(x86)
　　　　　サブコア　 　　　　GMA(GPU)―――――――？――――――→Larrabee(x86)
AMD・・・メインコア　K10(x86)――→Bulldozer/Bobcat(x86)
　　　　　サブコア　　　　　　　　　　　　 Evergreen(GPU)――？―→Hekatoncheir(GPGPU)

両社とも大小演算コアを混在させる点ではヘテロジニアスマルチコアだが、
Intelはサブコアもx86という意味で命令セット的にはホモジニアスマルチコア(メニーコア)とも言える。

(IntelプランではサブコアもAtomに近い既存x86アプリ実行能力を持つので、
バックグラウンドサービスしか動いていないような低負荷時にそれらをサブコアに逃がして
全メインコア電源断といった動作が「理論上は」可能。)

>>453
たまに脳みそ沸いて、Intelを過小評価発言するやつがいるけど、
Intelに待つ理由なんて、「自己利益優先」以外に何一つなんだけど…。
分割やFTCが本気で怖かったら、SSDやらメモリ、GPUやらに手を染めない。
それにも手を出していくのがIntelの怖さであり、Intelの実力。

そもそもで対AMDでは資産規模10倍以上でいまだに勝負を決められないのだから、
手をゆるめる必要性が全くない。

ふと思ったんだけどさ、AMDの次世代はドザモジュールがチップ当り3か4乗るって予想が大半だけど、
これってちょっとおかしくないか？

と言うのも、AMDの主張ではドザモジュールは従来コアの1.5倍のリソース（で1,8倍のスループット）って
話だが、プロセスは1世代進化する予定だからドザコアは現行コアの7割から8割くらいの面積で
実装できることになる。とするとチップ面積を現行から下げるのでもない限り、現在載ってるコア数と
同等以上の数のモジュールを載せられると思うんだが。

それに、ドザモジュール1個は単純なコア2個の2割減のスループットなわけで、メディアの予想通り今の
コア数の半分の数しか載せないとするとトータルのスループットは2割減になる。とすると、前世代より
パフォーマンスで劣るチップを出すことになるわけで、セールス上も考えにくいと思うんだが。

だから、俺は実際はチップあたりのドザモジュールの数は現行のコア数と同じかそれより多めに載せてくる
んじゃないかと思うんだが、どうよ？

>>457
FTCが注視するのは一つのカテゴリーを独占、排他してるかどうかだ
どんなに多数のカテゴリーに手を出していてもそれぞれの分野で
シェアがぼちぼちなら文句は言ってこない

>>458
4コア2モジュールで面積が現行から2割減なら3モジュールだとオーバーするね。
ブルドーザコアはサイズの削減考えてるんじゃないかなぁ。
最終的にはコア数はモジュール単位のMCMで全部解決するような方向性で。
モジュールたくさん積んでくるならそれが歓迎だけどさ。

>>460
4コア品はリソースが半端になるから難しいが、ハイエンドの6コア品のチップ面積なら
8コア載せれそうな感じがするんだよな。まあ、チップ面積を下げて安値競争をしかける
気なのかも知れないけどさ。だが、現行でもi7にしてやられてる事を考えると、そこから
さらにパフォーマンスダウンできるとも思えないんだよな。

>>460
＞4コア2モジュールで面積が現行から2割減なら3モジュールだとオーバーするね。

考えなおしてみたが、やっぱり4コア（モジュール）品でもコア数と同じだけ載せれなくないか？

今の現行コアの単位面積を1とすると4コア品では1x4で4の単位面積だよな。
で、もし現行プロセスでドザモジュールを作るとするとリソース数1.5倍だから、
1モジュール当り1.5単位面積が必要になる。そうすると、4モジュール載せた
現行プロセスでの4ドザモジュールチップは6単位面積必要になる。で、それを
次世代プロセスでシュリンクすると半分の3単位面積となるわけだから、、現行の
4コア品のチップ面積（4単位面積）に収まる。

実際にはきっちり半分にシュリンクできるとは限らないし、1.5倍のリソースですむとも
分からないけど、なんかいけそうな気がするんだよな。

バス幅の確保もある事だし、あまり小さくも出来ない筈では?

クロスバーとかのバスの割合が大きいから、この辺にメスを入れてくると思う。

調べところ32nm Llanoの1コアのサイズ=10mm2(コア+L1)だった。
コアを3wayから2wayの新設計で7mm2になる。(モジュール構造の非効率な部分も改善して理論値近くになりそう)
1モジュールが2コアだから15mm2。
(細かいことは抜きにして、思いっきり適当な概算)

ちなみにSandyは約20mm2。

Sandy 1コア> Bull 1モジュール(2コア)で、悪くても同サイズになりそうだ。

AMDはクラスタードアーキテクチャを採用したら1.5倍のリソースで1.8倍のスループットとは
言っているけど、従来のコアの1.5倍なんて言ってないよ。
コアやモジュールのサイズを推測する手がかりないから、
推測に推測を重ねても無駄だと思うけど。

どっかに提出とかするんじゃないんだから好きにやらせてやれよ

Buldozerのモジュールは「2 issue × 2コア」と「4 issue(SMT) × 1コア」の中間なんだろうけど、どっちに近いのかね。
「2 issue × 2コア」側だったらシングルスレッドを2コアで分担して実行、なんてできるはずもないけど
「4 issue(SMT) × 1コア」側だったら（実装しだいで）できなくないよね？

ターボでシングルスレッド性能上げるってのもIntelの見てると、
（ベースの周波数が低くない限り）そこまで大きな向上幅ではなさそうだし・・・

L1とL2のサイズまだ発表されてなかったな

いまより増えることはあっても減ることはないだろう。
とくにL1は拡張されると思うが。

>>469
もしコアあたりのL1キャッシュの量が増えると考えてるなら
ぜひとも理由を聞かせて欲しいな

>>467
中間でもなんでも無くキッパリ"2 issue × 2コア"です。

L1の構成は性能にシビアに響くから普通は容量増やしたりはしない。
AMDはK7から、IntelのCore MAはPentium MからL1はずっと同じ構成だろ。

NehalemはL1データキャッシュのランダムアクセスレイテンシを犠牲（3→4）にして
データのバッファリングを強化してるがそれが一部のゲームなどでの性能低下の要因になってる。
痛みの伴わない変革などない。

流石は知的障害者

intelのLSD相当のL0.5キャッシュとかいわれるやつは容量あがるの？

最近、キチガイのヒトのターゲットは団子さんに移ったんですね(笑)

IDチェックに便利だよこのスレ

Bulldozerがパフォーマンスよりスループットに振ったCMT寄りのチップで
HPCやクラウドにはいいけどハイエンドデスクトップには向かないのは
もはや確定している、ように思えるが
まだ逆転の要素はあるのかい?

2つの整数クラスタを投機実行に使うとか？

FPクラスタに限れば4issueに増えてるわけだからそっち方面はそれなりに。

256bit FADDと256ビット FMULの構成だと128bitのそれに対してスループットは2倍だが
積和ユニットは乗算と加算を結合できるケースでしか使えない。
たとえばN-Bodyみたいな問題だと、コア（モジュール）当たりの性能は1.3倍くらいIntelの実装の方が速い。

「性能上がるからから普通は容量増やしたりはしない。」とかそういうのは要らないんでさっさと死んで

性能上がるなんて言ってないのに読解力もないやつが死ねば？

>>471
AVXなど命令セットが大きくなると、それだけメモリを食うからだろうけど、
"K10"の時点でL1は128KBあるから、十分だとは思うが。

キャッシュメモリというのは、容量を大きくすると、アクセス速度が遅くなるのれす。

自作板なんだからまずそこから書いてあげないとダメ。

>>483
一般論としてL1キャッシュは最も実行コアに近いメモリだから容量を犠牲にしてでも
最短サイクルでアクセス出来る必要がある。

AMD K7以降のデータキャッシュは64KBの2Wayセットアソシエイティブだが
Intelの32KB 8Wayセットアソシエイティブより容量は多いが
下位アドレスが同一のアドレスを同時に2つまでしか保持できないということであり、それだけ
データスラッシングのリスクも大きい。

RDPMCとか使ってL1ミスヒット率をカウントしてみればわかるけど
OpteronのLINPACKの実効性能（理論値比）がNehalemより1割くらい低い理由も実はこの辺にある。
(行列積問題は定ストライドアクセスしまくる)

>>482
そこ合算していいのか。AVXなら命令長縮むからL1命令が問題ないのは確実。
つってもL1データが足りないとなってもじゃあ大きくできるかと言うと難しい。

> 64KBの2Wayセットアソシエイティブ
それは辛いっすねAMD・・・

某ゲーム機のMIPSのキャッシュがやはり2wayで、
「今時ないわー」と思っていたが、普通にあるんだね。

>>481
「容量増やすと性能下がる」のほうだったか
すまんかった
でもどっちにしてもきもいだけなんで死んでください

容量と速度は反比例するとかいうのはよく言われるけど
容量上げたほうが損とは限らないし上記自体もそうとは限らない
マージン削ればデメリットなく性能上げられる、その一例がOCだし
L2はバリバリ容量増やしてる（た）のがIntel

L1容量変えないのはコアの構成のためだと思われ
今日日のCPUはL2はコアの隣にあるけどL1は中に入っているので
容量増やせば設計が変わってしまう
これでバグでも大量新規作成されたら明らかにデメリットが上回る
まあバグなどお構いなしのIntelは今度ループ専用トレースキャッシュの容量大幅増するみたいだけど

EGPBFIOnみたいなのにかろうじて支えられているのが
今のAMDなわけです。
この状況は何とかしないとまずいだろう、と。なんともならないけど。

AMDは俺が育てた(ｷﾘｯ

容量増えればキャッシュにヒットしているかどうかを調べるのに時間がかかるようになる。
時間がかからないように設計するとダイ面積が増える。
容量増えればキャッシュミスが減るって利点もあるので、どうバランスとるかは、
結局アーキテクトの設計方針次第。

CPUについてなら大正解
GPUについてなら的外れ

L1キャッシュをスレッド毎に持つってのがAMDの回答だろう。
理屈上はレイテンシも維持したまま容量も帯域もスレッド数分だけスケールする。

1スレッドの性能は全く上がらないけど。
ただ性能低下を起こすケースすらあるIntelのHT（SMT）よりはスループット的対決には有利。

HTに毛の生えた程度のスループット向上だったら、L1データキャッシュを
独立に持つ意味も薄いような。
デコーダ共有だとそんな感じになりそうなんだけど。

富士通のSPARC64やSunのRockがやってるような、
コア間のスレッド同期を支援する命令やハードウェアの追加はしないのかね。
うまくすれば少ないトランジスタで大きな効果が見込めると思うのだが。

Intelのは4命令とは同時デコードできる組み合わせに制約がつきまくるからね。事実上3命令＋α。
Bulldozerは同じ4命令同時デコードでも命令帯域は32byte/clkでより実効スループットに振っている。
命令デコードに関しては最大で1.3倍程度の性能差ができる。

それで8コアでSandy Bridgeの4コア版には整数では勝てるかもしれないがCoreシリーズ上位やXeonの
6〜8コアに勝てるかというと、微妙。

頭悪いレス撒き散らすもっさりスレの連中は巣に帰れよ。
スレごとこの板から消えて欲しいぐらいだ。

別にスレが消えなくても
知的障害者独り死ぬだけで関連コテ全て消えてすっきりするんだが

>>490
＞ダイ面積
マージンって文字通り余白として形になってるんだなあ
やはり発熱の関係かね？

ID:EGPBFIOn

ならさっさと死ねよ池沼

池沼スレの奴が池沼死ねとか見事なブーメランだな

煽りにそのまま返しちゃうところが団子まだ若いよなあ
素直に羨ましいと思う30代後半のクリスマス

ジョウゴ理論でデコーダ帯域を広く取ってるはずのIntelが
3命令+αで足りてるなら、Bulldozerの4命令2スレッド振り分けも
それほど性能低下にはならないのかもねえ。
早く実物が見てみたい。

もっさりスレの裸の王様

まあ整数と浮動小数点の、市場の大きい側に併せてチューニングしていった方がＡＭＤとしては良いだろう
PCでのシェアが取れなければ全て無意味だが

PCではシェア取れないと思う

スパコンはアレだし、やっぱ組み込み？

組み込み部門売り払っちまったじゃないか旧ATIが持ってたのに

AMDなんて、その場しのぎしかできねーもん

その場しのぎでスパコンTOP500の上位占領か。
本気だしたらどーなるんだろな。
しかもその場しのぎのメーカーに負けるIntel様。
もしかしたらIntelって本当に糞メーカー何じゃね？
少なくともその場しのぎのAMDより技術力無しかｗ

amdはよそからパクッテきてるだけだもん

考えてみると幹部が全員外様ってすごいなｗ

技術力が無いのはLarrabeeみてたらわかるでしょ

失敗する独自技術よりはましだな。
クラスター構造のBulldozerとかwktkしすぎてどうしようかと思うくらい面白いCPUなんだが。
K10と構造が違いすぎて性能の予想すら出来ん。

逆にGMA内蔵したNehalemのSandyはちっとも面白くない。
今との違いが殆ど無いしね。

ちょ、I派が食いつくようなレスだな

まあBulldozerもクセはあるが叩き甲斐はある石だと思う。

>>509
会社と反りが合わなくなったアーキテクトが復讐するために転職してるようにも見えるw

独自技術が無いと言うけど余所の技術を自社文化にうまく融合させる術は大したもんだと思う
普通は買収してもシナジー効果が得られなかったり日の目を見ることができなかったりすることもあるし

技術の融合が目的の買収でない場合もあるよ。
OracleなんかオープンソースのDB支援企業買いまくってる。

Intelが似たような並列化フレームワーク作ってるベンチャー買いまくってるのも
ぶっちゃけ（ｒｙ

2011年までAMDは一切明るい状態にならないのがなぁ
1年は完全に空白ってのが悲しい

あまり悲観するなよ
この前の和解でキャッシュを手に入れた事だし
開発にも力入れられるんじゃないの?

ｲﾝﾃﾙは今年は新製品らしい製品を投入してなかったよな
そんな空白期間あってもｲﾝﾃﾙには関係無いっぽいが

ハァ？

「キャッシュ増えると性能下がる」
　　　　　　　　 　 ＿＿＿
　　　　　　　／　＿＿＿＿ヽ
　　　　　　　|　 | /, −､, -､ｌ
　　　　　　　| _|　-|○　|　○||　　　　　人　　人　　　人
　　 , ―-､　(6　 ＿ｰ っ-´､}　　　　　（＿）　（＿）　（＿）
ーー|　-⊂)　＼ ヽ_ ￣￣ﾉﾉーーー（＿＿）（＿＿）（＿＿）ーー
　 　 |￣￣|／ （_ ∪￣ / ､　＼
サン・レウン・コー[Sun Leon Kou]
(195?〜2010 押入れ)

AMDがよそからパクって来てるって言っても、その元となる製品の開発者がAMDにいるわけだが?
Dirk Meiyer だってそうだし。K8なんてバリバリAlpha(ry

というかQPIは自分たちで開発できなかったからDEC出身者を雇った(買った)Intelも同類になるよ?

>>518
> 開発にも力入れられるんじゃないの?
開発は問題ない
Bulldozerも次世代RADEONも和解金無しでも順調に開発中だからね
今までの弱点だったマーケティングやソフトサポートに力入れるんじゃないかな

借金が大量にあって、返済期限が近づいてきてるから、そっちにもある程度回さないといけないんじゃないの？

その通り

Bulldozerは既に2年延期した実績があって今の状況なんだが、開発順調と評していいものかどうか。
SunのRockほど革新的ではないから、Rockのように頓挫はしないだろうけど、
「きっとシングルスレッド性能は落ちない、むしろ上がる」というような無根拠な期待が
薄れたら、再びAMDのCPU戦略は窮するのではないか。

AVXへの対応に時間を掛ける必要があったのなら遅延自体は仕方ないと思うけど

俺は素人だからよくわかんないんだけど、
86命令を一度に一つづつ順繰りに出すソフト＝シングルスレッド
という解釈でいいのかな？

１＋１を10回計算するプログラムを組んだら、
二つの整数演算器はフルで使われるの？

>>526
シングルスレッドは「落ちない」は別に無根拠でもないでしょ。
整数演算パイプが減ったのが、性能に直結する事って滅多にないのでは？

それにいまのPhenomと比べてNehalem系やCore系は
整数演算パイプは半分程度だけど、
Phenomに比べて性能が半分ってわけでもないし。
"Bulldozer"は長らく続いた"K8"を引き継いだコアではなくて、
新設計コアなので"Phenomから減ったから性能も下がる"って
発言も当てにならない。根拠がない発言だろ。

はいはい

えーと、否定しちゃっていいのかな

> それにいまのPhenomと比べてNehalem系やCore系は
> 整数演算パイプは半分程度だけど、

とんでもない。両方とも整数ALUは3基ですよ。
Core MAの場合スケジューラが集中管理型だからAGUをALUをペアにして持つ必要がないだけで

> 新設計コアなので"Phenomから減ったから性能も下がる"って
Pentium Mなみのスケジューラを持つことで実効性能はそこそこ維持するかもしれないが
ピークは落ちるだろうな、ALU 2基なら。

「フェッチ＝プリフェッチ」
　　　　　　　　 　 ＿＿＿
　　　　　　　／　＿＿＿＿ヽ
　　　　　　　|　 | /, −､, -､ｌ
　　　　　　　| _|　-|○　|　○||　　　　　人　　人　　　人
　　 , ―-､　(6　 ＿ｰ っ-´､}　　　　　（＿）　（＿）　（＿）
ーー|　-⊂)　＼ ヽ_ ￣￣ﾉﾉーーー（＿＿）（＿＿）（＿＿）ーー
　 　 |￣￣|／ （_ ∪￣ / ､　＼
サン・レウン・コー[Sun Leon Kou]
(195?〜2010 押入れ)

http://hissi.org/read.php/jisaku/20091225/MkVzOWNld1E.html

いつもの基地外か

　　　　　　　　 　 ＿＿＿　　　　＜いいぞ　ベイべー！
　　　　　　　／　＿＿＿＿ヽ　　　プロセス＝CPU＝FSB　を信じない奴は基地外だ！！
　　　　　　　|　 | /, −､, -､ｌ　　　　キャッシュ増量で性能低下　を信じない奴はよく訓練された基地外だ！！
　　　　　　　| _|　-|○　|　○||　　　　　人　　人　　　人
　　 , ―-､　(6　 ＿ｰ っ-´､}　　　　　（＿）　（＿）　（＿）
ーー|　-⊂)　＼ ヽ_ ￣￣ﾉﾉーーー（＿＿）（＿＿）（＿＿）ーー
　 　 |￣￣|／ （_ ∪￣ / ､　＼　　ホント Core2のL2大増量は地獄だぜ！ フゥハハハーハァー
サン・レウン・コー[Sun Leon Kou]
(195?〜2010 押入れ)

aa連張り知能障害とか今時ここまで型にはまったバカもいるもんなのか

Bulldozerの実物が出て阿鼻叫喚になるのはどっちの信者か。
今から楽しみだ。

K10の再来(悪い意味で)な希ガス。
PC用途だと、シングルスレッド性能がダウンしそうだし

現状が常に3命令供給できてるわけじゃない点とターボの実装でとんとんになるかもしれない。
あとL2がモジュール内で共有なのがどう響いてくるか。

IPCが大幅に下がりはしないだろうから、クロック次第だろうね。
ただ、ターボはintelだとコア単位でクロック変動出来るけど、
Bulldozerだとどうなんだろう？
モジュール単位の可能性がたかそうだから、AMDの方がターボでクロック上げにくそうだけど。

ただでさえ熱いデコーダが
二スレッド分供給するせいで沸騰するような。
デコーダ層のステージ分割を増やせば、今度は分岐のペナルティ増大。
1スレッドがIdleのときは4命令/スレッドになるけど、
今度は整数演算器がボトルネック。
デコーダ共有は誰得なんだろうね?

普通のPC用途だと、アクティブなスレッド数がモジュール数以下に収まることが大半だろうから
（OSの支援が必要だけど）1スレッドが1モジュールにマッピングされる感じになるんじゃない？

その場合、>>80の1スレッドから2整数ユニットを使える話がなくとも
4Wayデコーダ→2ALU＋2Load/Storeになるから
3Wayデコーダ→3ALU/Load/StoreのK10に対して
（常に劣るということにはならないで）
アプリによって勝ったり負けたりといった感じになる気がする

ま、当然>>80のようななんらかの新技術がないとK10と同じく
Nehalemには相変わらず苦戦することになっちゃうわけだけど

K10までのDecoderは<VectorPath or DirectPath>x3で最大3macroOp/cycle

BulldozerのDecoderは<MicrocodePath and FastPath>x4で
(tag付き)uOpに変換、RegisterRenameも同Decoderが行う(final decode)
1thread目は<MicrocodePath or FastPath>x4で4uOp/cycle
2thread目は<1thread目で使われてないPath>x4で最大4uOp/cycle
2thread合計だと最大8uOp/cycleってことらしい

今後のPCで求められるの性能って何だろう
パフォーマンス？
ワットパフォーマンス？

Bulldozerは性格上モジュールの中で更にブロックごとに電力管理が出来そうな気がする

性能はperformanceだけど

>>541
禿銅

x86の場合デコーダの負荷＆発熱がネックになってる筈なのに、それを共用する
事でフル活動させたら凄い事になりそうだよなあ。

勿論、AMDの開発陣もそれを分かって対策はしてるつもりなんだろうが、果たして
それがちゃんと成功するかどうか。

1モジュール（2コア）に2スレッドが割り当てられている時はデコーダと演算器は等速
1モジュールに1スレッドしか割り当てられない時はデコーダ：演算器は1：2の速度比で動くとか

ホットスポットであるデコーダの速度を上げなくて良いので、演算器はかなり高速に駆動できるとか・・・

今さらだけど1ブルドーザーユニット＝（現在の）１コアって数え方になるの？

1モジュール＝1ｺｱ以上2ｺｱ以下

1コア=K10とすると、
1モジュール=0.8コア以上1.6コア以下、では。

「1スレッドで1コア」って基準なら
1モジュが1コアになるのか2コアになるのかの判断は噂の真偽次第だな
1スレッドを分解出来るだとかループ専用トレースキャッシュ積むからそのためにデコーダ共有するだとか・・・

>540
turbo boostが出るまでは
まさか電力制御が性能まで制御する事になるとは思ってもみなかったからなぁ
2コア1モジュールはクロックの制御どうなってるんだろう
一律だとかなり分が悪そう

>>544
ワットパフォーマンスが良い（かつそこそこコンパクト）ならCore 2 Quadみたいに2つ並べて
パフォーマンス設計にするとかの応用が利くと思う

何コアまでが有効なのかが鍵だね
I/Oネックだと大差なくなっちゃうしね

>>543
あれ？
命令供給十分じゃね？

・Bulldozerのデコーダは1サイクルで4命令発行（後藤の推測）
・サーバー重視とは言ってもPC分野でも売れなきゃ鯖専用となって数が出ない→高価になって結局鯖でも売れない
　これでは勝負にならないので、恐らくPCでも性能確保のめどが立っているはず

以上より
�@1モジュールあたり2個のスレッドが走るとき（2コアとも使用）
　1サイクルで4命令発行に対し、2コア×2パイプライン＝4パイプラインでちょうど1：1
�A1モジュールあたり1個のスレッドが走るとき（1コアのみ使用）
　1サイクルで4命令発行に対し、1コア×2パイプライン×倍速駆動≒4パイプラインでちょうど1：1

これでPCに必要なシングルスレッド性能と、鯖に必要なマルチスレッド性能を両立できる
どうだろ？

前提になる「PCに必要なシングルスレッド性能」って何だろ？
マルチコア・マルチスレッドを前提に作られているCPUで、
シングルスレッド性能は「いまより下がらない程度」な扱いの予感。

最小構成でも2モジュールは乗るんだろうから
�Aの場合でも2スレッドまで切り替えや割り込みのオーバーヘッド無しに走らせられる
今後も多くのソフトは2スレッドまでしか使わないだろうから、この辺りがバランスがいいと思う

ちなみに、ただの憶測なのでネタ程度に思ってください・・・
ただ単に、他に4命令発行のデコーダーを2コア（4パイプライン）で共有する理由を思いつかなかっただけです

同じコード群を実行してるスレッドで命令キャッシュ共有したかったからでしょ？

１、シングルスレッドの整数演算
２、マルチスレッドの整数演算
３、シングルスレッドの浮動小数点演算
４、マルチスレッドの浮動小数点演算

シングルスレッドの整数演算は現状維持で十分という判断だったんじゃないかな？
その代わり2〜4は期待出来ますと。

> ４、マルチスレッドの浮動小数点演算
ここはSandy Bridgeとの比較になるから期待できるかどうかは・・・

>>558
そういうケースは少ないと思われ。
またそういうケースであっても、実行ループがL1命令キャッシュに収まるなら
キャッシュがスレッド毎に独立でもデメリットはない。

L1命令キャッシュは原則リードオンリーだし

命令キャッシュに書き戻すケースなんてあるのか？

自己書き換えとか
とはいえこれやるとキャッシュいったんInvalidateして読み直しだからものすごいクロック数のペナルティになる。

常識的に考えてない。というか。ない。

>>560
AVX 256bit以外はそんなに変わらんと思うが。

いやそこが一番大きいだろう

レガシー命令じゃ半分かそれ以下しか使えないのはIntel, AMDとも同じ

>>567
だからAVX 256bit以外は大した差はないんだろ？
それに大半の人はレガシーのSSE2か3対応のソフト位しか使わんだろう。
AVX対応ソフトもどれ程出てくるかは疑問が残るし。

HPCでは必須要素だからおりてくるのもはやいでしょ。
今回はフリーも含めてコンパイラが早期に対応を完了してるし。

MMXのときなんてアセンブラでニーモニックも用意されてなくて
emit文直打ちでやってた人すらいたもんだ。

だからDX11以外は大した差はないんだろ？
それに大半の人はレガシーのDX9か8対応のソフト位しか使わんだろう。
DX11対応ソフトもどれ程出てくるかは疑問が残るし。

>>570
残念だがWindows7はデスクトップ描画がDirectX10.1ベースで、
標準搭載のDiretXは11なんだよ。
過去のゲームは仕方ないが、後方互換性もあるから、
今後出てくるゲームはDX11対応が多くなるだろうね。

まあ、MMOや一般ソフトの対応は時間かかると思うけど、
Win7移行が進めば自然に増えてくるだろうね。

>>569
Teslaの急激な普及や天河1号のラデオン搭載をみると、
SSEに毛が生えた程度のAVXが必須で普及するとは思えんが。

DX9に毛が生えた程度のDX11が必須で普及するとは思えんが。

過去にもSSEで痛い目にあってるからなぁAMDは

問題なのは命令セットやAPIじやなく
AMDのハードの実装が実用レベルじゃないこと

>572
AVXがSSEに毛が生えた程度ってのはだいぶ違うだろ
デコーダが命令長判定しやすくなったとか色々と変わっとるがな

おまえらそんなにSSEパワーを使うようなソフト使ってんの？

SSEは今までは後ろに付く数字が増えていったけど
これからは小文字のダブリューが増えてくようになる

SSEは石屋が石を売りたいがために作るただのセールストークネタのひとつ

DX11は石屋が石を売りたいがために作るただのセールストークネタのひとつ

SSEよりDXの方が遙かに重要な印象。

11作ってDirectX売ろう！ｗ

DirectX10/11ベースでゲームを作れるほど
Windows Vista/7のシェアが増える頃には、
PCゲームベンダは残らず廃業するかコンソールに鞍替えしてるかと。

Vistaて重い重い言われてるやん
あれな、世のPCにはGMAが5割だっけ?
そんなので動かすから情弱がVista遅い遅い言うんだよ



でもVistaがくそには変わり無いけどなー

みんなDX10/11ベースで開発できるXBOX360に移るだろうね

移る、って
どっちでも使えるようにするためにXNAがあるんでしょ

vistaと7って何が違うの？

明らかにSP2とSP3ぐらいの差があるのに何をいっとるんだ君は

>>572
しかしッ！
貴公が崇拝するDirectXもッ！
CPUで動くコード部分にはしっかり拡張命令が使われてるのだッ！

>>587
タスクバーがドック機能が付いてMacOS Xっぽくなった

ソレハトテモジュウヨウナチガイデスネ

Microsoft XNA
http://ja.wikipedia.org/wiki/Microsoft_XNA

一方PS3は･･･

> SSEに毛が生えた程度のAVXが

そりゃAMDのBulldozerの実装に関してははそうでしょうよ。もとが128ビットSSE5だし。
AMD基準で動いてるわけではない。

ひょっとしてLlanoはK10ベース（SSE3までしか対応してない）だからAVXディスってるの？

「キャッシュ増加は性能低下」が周りに受け入れられなくて
奇妙な煽りしか出来なくなった障害者

Llanoをやたらと敵視しすぎだよ

家庭用ゲーム機が強い日本でも、家庭用ゲーム機向けソフトとPC向けソフトの市場規模は1：4〜1：5
PC向けソフトにオンラインゲームの市場規模を加えると1：3

ちなみに、その日本では家庭用ゲーム機向けソフトの市場規模は縮小し続け10年前の半分しかない
PC向けソフトが家庭用ゲーム機向けソフトに喰われるという発想はどこから出るんだろ

ちなみに、今業界ではWiiが超失速しており遠からずWiiショックが来ると言われている

>>596
比率の順序おかしくないか

家庭用に携帯ゲーム機は含まないとかの落ちがあるんだろう

おっと間違った
× 家庭用ゲーム機向けソフトとPC向けソフトの市場規模は1：4〜1：5
○ PC向けソフトと家庭用ゲーム機向けソフトの市場規模は1：4〜1：5

モバゲー、mixiアプリ、iphoneアプリとかもある

mixiアプリはやばいねアレは。
ついついアイテム課金しそうになった。

麻雀しかやってねぇ
つかランキングみたがバケモノ揃いだろ…

そういやfalcom,koeiってPCやめたのか？

オプーナやさんはまだやってね？
まだ一応競馬ソフトだしてね？
ファルコムはわかんね。いまイース７がPSPだけども
イース５でスーファミ独占だったと思ったら6はPCだったし

個人的には2Dで良いんでネット対応のソーサリアン出してほしいわ
3Dのやつは既にあるけどメンドクサイ

watch_akiba
"兄貴"こと日本AMDの土居憲太郎氏より、
26日で同社を退職したとの連絡を頂きました。
新天地での活躍を祈っております。
約1時間前 Seesmicで

あー、「Ikinaが心配」ってそういうオチか

Bulldozerがさらに遅れるのか性能に難があるのか
Intelに対抗出来る自作PC向けのチップが出て来そうにないから
看板広報に逃げられた?
これから昇り調子なら普通辞めないよなあ。

性能に難があるとは言いきれんよ。

本当に汎用ALUが2基に減ったらスレッドあたりの整数演算性能は減るのか？
むしろAGUが独立になったわけで、バレルシフタつきの加算器なんで、
実は簡単な整数算術演算なら空きがあれば発行出来るんじゃないかと思ってるんだが。
もちろんLEA命令はそのまま実行出来るだろうし。

むしろLEA命令を使えば rax = rcx + rdx をオペランド破壊なしで実行出来る。
どういうパフォーマンス戦略があるのかは未だにわからん。

FP性能に関しては、流石に天井は見えてるが。

看板後方の件はMSの人を彷彿とさせるな
企業ってシステムとして人の査定が苦手なのかね、派閥とかあるし

x86CPU全体から見るとK7以降のLEAは特殊だから
BulldozerのLEAがどんな実装になるか興味があるな

K7からk8初期まで L:2 T:0.5
ttp://www.freeweb.hu/instlatx64/AuthenticAMD0000F4A_K8_Clawhammer_InstLatX86.txt

k8中期以降は lea r, [r+r]のみALUで実行するようになったのか
L:1 T:0.33になっている
ttp://www.freeweb.hu/instlatx64/AuthenticAMD0020FB1_K8_Manchester_InstLatX86.txt

他のCPUはlea r, [r+r*n+dsip]までをレイテンシ1でこなすが
1サイクルに1命令のみ実行可能であることが多いようだ
ttp://www.freeweb.hu/instlatx64/

>>608
妄想乙

Intelとの対立の構図でさんざん煽ってきたのに
後任への引継ぎもなく辞めた理由を邪推するなという方が無理。

兄貴ってCEOか何か？

日本法人の広報

2011年にはFusion世代に移行するAMDのモバイルCPU
http://ascii.jp/elem/000/000/484/484976/

Llanoについて、ダイ写真のGPU部が狭く見えて、巷で噂されてる480SPに疑問があるから、
トランジスタ数でちょっと大雑把に考察してみる

Llanoのサイズ=Propusのサイズ(160mm2)らしいから、
プロセス世代差でトランジスタ数は倍になり、3億x2の6億になる。

CPU部分について
4コアでL2=1Mだから、トランジスタ数は2コアL2=1MのRegorの倍になる。
2.34億x2=4.8億になる。

GPU部は6億-4.8億=1.2億になる。
ざっと見たところ、シェーダー+固定機能だけを考えれば良さそう。

とりあえず比較としてHD4350/4550のトランジスタ数を調べたら約2.4億だった。
RADEON系は約半分が演算器だから、約1.2億になってドンピシャの数になる。

クラスタが6個あるから、80/6=13SP 余り2SP？
SPはサイズが小さいからもう少し多いと思うけど、
流石にクラスタ辺り80SPはなさそう。
20SP*6=120SPか、せいぜい40SP*6=240SPだと思う。

前提から間違ってるのでなんとも

総トランジスター数は10億程度って情報があるのに、なぜ勝手に6億なんて計算するんだろう。
そもそもCPUのIstanbulは45nmで346mm2のダイサイズでトランジスタ数は9億。
GPUのHD 4870は55nmで300mm2のダイサイズでトランジスタ数は9億5600万。
AMDのCPUとGPUでは、GPUの方ががトランジスタ数辺りに必要なダイサイズが小さいんだから、
CPUのダイサイズとトランジスタ数を元にGPU部分に使われているトランジスタ数を推測する意味なんてない。

K10タイプのExclusieveCacheでL2 1MB x 4コアはちょっと疑問だねぇ。

初代PhenomではExclusiveCacheと各コア独立クロックが災いして、
「低速稼働/halt中の他コア」へのCache probeがパフォーマンス悪化要因として顕在化した。
PhenomIIではその対策として、「halt時にL1/L2を自動的にフラッシュ」する機能を追加。
L1/L2からL3(orメモリ)への書き出しトラフィックが発生するものの、
それでもprobe問題が減ってパフォーマンスは格段に良くなった。

さてL2が1MBになるとどーなるか
2コアではさほど問題にならなかったProbe問題が4コアで顕在化したように
L2増量でHalt毎のCacheFlushトラフィックが問題となる恐れがあるｷｶﾞｽ

2011年にK10クアッドというのが何度見ても正気とは思えないんだが……

>>619
10億の記述見逃してた…
全体の1/4程度の面積で約半分のトランジスタ使うのか。
どんだけ高密度なんだ。

>>617
プギャー

HD5750級とか…
AMD、Intel共にどんだけの価格帯のCPUたちを滅ぼすつもりなんだ…

　まあでも、1年以上後の話だからね。

Llano搭載ITXマザー出たら自作やめようかな。
CPUとGPUを選ぶのが馬鹿らしくなってきた。

>>621
低価格向けなんだから別に問題ないだろ。
結局GMAを統合するしかない某社に比べたら、
低価格帯での性能面での優位性は揺るがないんじゃない？
「どこまで省電力に出来るか」に疑問が残るけど。
総合的な省電力面で差を縮められない場合は、
現状と同じでさほど採用が増えることは無いかも。

低価格はGMAで十分ですが
アホ乙

低価格帯ノートでIGP含めて総合的に見るとAMDに分はあるが結局ネームバリューに負ける…
Llanoで巻き返しの可能性を示しBobcatで殲滅戦を計る…そしてFusionの可能性を模索する

Bobcatで消耗戦

低電力版で性能勝負してもな
Bullと開発リソースかぶってオマケで作れるならともかく

そもそも低価格帯のマシン買う層に
性能面での優位性とやらがセールスポイントにならんだろ

むしろ低価格だからこそ
その部分を気にする人たちが一定数いると思うけどな

低価格でも高性能であってほしいと思うよ
そう願って、思い込んでAtom搭載ﾈｯﾄﾌﾞｯｸを買った人達をがっかりさせないように
AMDには血便がでるほど頑張ってほしいな

軽いゲーム(ほぼCPU依存)ならノートでグラフィックチップが
ATI積んだ2003年モデルにintel積んだ2007年モデルが負けるという事実。

だが遅いAMDをわざわざ選ぶ理由はなかった

Ontarioは40nmだから価格競争力があるかどうかやや疑問。いきなりデュアルコアだし…

>>636
"Bobcat"はATOM対抗でしょ？
40nmなのはGPU側にあわせたんだろうけど、
価格より省電力性能の方が疑問でならない。

>>632
その手の発想するのは自作する連中だけ。
DELLやらHPの"とにかく動けばいい"大口法人向けマシンに
ゲーム性能なんざ関係ないし。

K7〜10って整数は整数の、小数点は小数点のスケジューラに命令渡してるよな
でもBullは整数のスケジューラも小数点のスケジューラに渡せる
ように見える図があったりする
これってFPUで整数の溢れた分を処理しようってことなんかね

数から言えば整数なんて浮動小数点のうちの1つなわけだし
int専門には敵わなくてもおこぼれを処理する程度なら充分役に立つだろうけど

お騒がせしました。一応報道通り退社致しました。
皆さんの温かいサポートのお陰で今の私があり、
感謝の気持ちでいっぱいです。本当に有難うございます。
今後は土居憲太郎としてつぶやいていきますので、
それでもよろしければ今後もフォローして頂けると。
約3時間前 Twittelatorで

まだ次が決まっていないので、
とりあえず決まったら就職祝いとしてCi7買うかなw
約3時間前 Twittelatorで

>>638
イッパンジン向けの雑誌や、BPNetの記事を見ればわかるけど、
一般人ほど安いPCの性能を気にしてるぞ。
とくに某雑誌では、「Atom,Celeron743」が買ってはいけない地雷CPUあつかいになってるｗ

つか電気屋でパソコン買ってる一般人は
そのPC雑誌すら読まないから。

エヌイーシーかフジツーかソニーのやつ下さい、で終わりな連中に
AMDのオンボはIntelより性能良いなんて永遠に関係のない話。

>>642
VAIOくださいで終わるという落ち。

>>642
eMachinesやGatewayなんてゴミもあるけどな

友人はhpのathlon買ってた

OntarioのGPU性能ってどんくらいだろうね

どうせメモリがネックになることは目に見えてるから790GX程度の
性能が出れば御の字じゃない？まあもうちょっと出るとは思うけど。

>>639
変わらんよ。
FP演算やるにもロード・ストアやそのためのアドレス算出には整数側パイプラインの助けを借りないといけない。

>>628
なわきゃねー

バカ騙してるだけ

>>641
なぜCeleron743はダメなの？

ａｔｏｍはわかるけど

>>648
馬鹿ってのは未だにPCでゲームやる馬鹿のことか

Atom買った人に追い打ちかけるようなこと言うんじゃねーよ

>>649
・SU2300との価格差小
・N280との性能差＜SU2300との性能差
・VT非対応(XP Modeが「動けばいい」レベルでも必要なら選択不可)
・SpeedStep非対応(TDP10Wライン中実質最高発熱)
こんなところかな

正直0.1GHzの違いよりコア数の違いの方が大きいわな

…で、AMD積んだノートって見たことあるか？

>>642
ぶっちゃげスペック（中身）なんかどうでもいいからなぁ
昨日ヤマダに行って店員に
「テカテカの液晶のくれ」と言ってたヲヤジ見たから
尚更そう思うｗ

英語キーボード派なので海外モデルを探すのでそれなりには・・・

AMD搭載ノートなら近所に一機あったなー
何気にtigrisプラットホームだった気がする
ていうか一機だけって・・・ｗ
店にいた客はどうやらAtomに興味津々でしたね

最近のVAIOのキータッチは馬鹿にしてるのかと思います
まだASUSとかのノートの方がしっかり打てる

何も考えずにThinkPadでいいんじゃないの

>>653
普通に売っているぞ。

>>658
ThinkPadもいまでは「ブランドで売れるマシーン」だな。
単なる中国製品なのに。

ThinkPadの質ってそんなに落ちた？

とりあえず会社で使っているThinkPadマシンは
発狂しそうなぐらい遅い。
CoreDuoでメール書くとかに不自由なんてとてもするとは思えないし、
一体どうやったらここまで重くなれるんだろう。

自作マシンの軽快さに慣れないとわからない感覚なんだろな

>>659
中古で買ったX61使ってるが決め手は
・B5モバイルのくせに通常版C2D搭載
・リッチノートよりキーボードが打ちやすい（これは好みだな）
・リッチノートより安い。（それでもCULV並の値段はした）
・見た目がかっこよかった。
の4点だった。
家の外でも中でもそれなりの性能と駆動時間を確保できるから一応使い易いが、さすがにデスクトップでやるような作業をやらすと重い。そのあたりはどうしようもない。

性能的には悪くない。ただマニア向け。

企業モデルにある指紋認証ログインは楽だと思った。

>>661
それむしろソフト側の問題じゃない？
ThinkPadは基本いじりたい放題だから極限まで軽くしてる。

>>664
友人がそのモデル持ってる。
あれは確かに便利だが個人ユースではほぼ意味がない。


…CeleronSU+IONなCULVならスゴそうだ。バッテリーが問題になるが。

>>665
プリインストールの邪魔くさいやつ消しまくってるんだけど、
どうにもこうにも重くてかなわん。
同世代のモデルを支給されている同僚は全員文句言ってた。
でもまぁ、もうちょっと余計なもの削れないか年明けにやってみる。
これだけは言えるが、Lenovoマシンだけは絶対に買わん。

1モジュールに整数演算器が2群4基
もしも2群を個別制御が出来ないなら4基を同時に動かす事になり、通常使用時のワットパフォーマンスは話にならない
よって個別に制御が可能なはず
この場合はFPUも個別に制御可能

また4命令同時発行可能なデコーダーは、整数演算器1群2基に命令を渡すだけの場合は命令発行頻度は1/2でいい

つまり電力消費の大きい部分やホットスポットがざっくりと分離された超シンプルコア
並列度が低い場合はワットパフォーマンスが高く、超高クロック駆動も可能かも

＞また4命令同時発行可能なデコーダーは、整数演算器1群2基に命令を渡すだけの場合は命令発行頻度は1/2でいい

それは今までと何が違うの？
命令リタイヤメントが滞ってれば結局デコーダ稼働率は落ちるよ。

ロード＋整数演算で構成されてたμOPが別々になるということはその分だけ内部命令が簡素化されるということであり
TDPの上限までの範囲で高クロック化しやすくはなるかもね。
そもそもデコーダと整数演算ユニットのクロックドメインは一致してるのかしら？

来年は知障フリーなスレでありますように

もっさりスレのぬしの遠吠え

知的障害者がまたまた突然「集合がどうのこうの」と意味不明な発言をしています


きもすぎ

【レス抽出】
対象スレ：AMDの次世代CPUについて語ろう 第31世代
キーワード：集合


296 名前：Socket774[sage] 投稿日：2009/12/19(土) 21:43:27 ID:E6GeZaRp
>>295
あのさ動作保証外なんて表記にはほとんど意味ないんだが。
わかってないやつがうける。

例えばAMD製のCPUで殆ど最適化コードの動作検証もしていないのに
たまたまバグやエラッタでICCでコンパイルしたSSEのコードをAMD製CPUでユーザが
動作保証外なのに勝手に実行したら、現実問題としてクレームになって
無駄なコストが発生するんだよ。
Intelは趣味で最適化コンパイラつくってるわけじゃないし、
AMD製CPUに対しては余計な不具合をださないことが先決なの。
というか企業の製品ってのはそういう考えの集合。

672 名前：Socket774[sage] 投稿日：2009/12/31(木) 23:16:37 ID:cwxAdFci
知的障害者がまたまた突然「集合がどうのこうの」と意味不明な発言をしています

また負け犬来てるのか

烏合の衆AMD

AMD使いって自分の理解できないレベルの話になると
意味不明とか言い出すよね
CPUでもGPUでも

L2、デコーダが共有、ALUが2基なのは、Intel相手にしんぐるスレッド性能で
多少劣っても、コア数を増やしまくる作戦ってことでFA？
Core i3にAthlon�U X3/X4をぶつけるみたいだし。

遠吠えでググれば判るように
イヌ科の遠吠えは仲間と連絡を取るというか
Googleの1ヒット目ページによれば＞、「集合するぞー」という仲間に対する合図　らしい

並の馬鹿の発言ならば「負け犬の遠吠え」（押入れ遁走する時の鳴き声はキャンキャンであって遠吠えはおかしい）という誤訳（誤造？）を
さらに誤って縮めたものだという可能性も少なくないが
知的障害者のことだからそんな一般的な推測は役に立たない

なにしろ>472では
＞L1の構成は性能にシビアに響くから普通は容量増やしたりはしない。
「キャッシュ増やすと性能が○○だからやらない」
性能の件だから上がるか下がるか変らないかの３択で
普通に考えて「キャッシュ増やすと性能上がるけどIntelは異常だからそうしない」と訳したら大間違い
何と「キャッシュ増やすと性能下がる」のほうだったという驚愕の事実があったばかりだからなあ・・・
Core2もっさり2スレ目から半永久的に電波を撒き散らしている有名知的障害者を正直甘く見ていた

L1って容量よりレイテンシや連想度のの方が重要だからな
容量増やして連想度落とすより、今のままの方が良いという判断だろ

実質ライバル不在だし
変に手を入れる必要もない

nanoですら16wayだっけか
プリフェッチ腐ってるけど

3000シリーズは修正されて20-30%パフォーマンス上がってるけどね

>>677
AthlonII X3/X4にCore i3しか「ぶつけられない」の間違えだろ。

>>679
たぶんこの人は「latency」が何のことだか、キャッシュサイズとどんな
相関があるのか理解していない。

そんな人たちにAMDは支えられています。

あ、この人って679じゃないよ。

団子もそろそろスルーカを身に付けるべき

intelは低価格な4コアをLGA1156では出せないからね。
LGA775はLGA1156でまかなえない部分だけに推しとどめたいだろうから、
Core2Quad8000より安いのは出したくないだろうし。

何で>679まで知的障害者に憎まれてるんだｗ
現実世界では当たり前のこと言ってるから（ただし「普通に言われてること」をさも事実のように書いてはいるけど）
「キャッシュ増量で性能低下」な価値観と相反するのかな？やはり


トレードオフでのデメリットは演算性能に出るとは限らず
キャｓｓｙ増やせば普通に面積食うし
>490によれば演算性能面で容量増のメリットだけを得ることも出来そうだ

しかし容量増やせば上記の面積に加えて熱のデメリットもあるし
コアと一体化してるL１を増やすことはアーキというか設計図も大きく変ってくる
PenMから容量変らないとすれば多くのプログラムがそのIntelL1に合わせてるかもしれないし
ハードのバランスとソフトの慣習の2つが関わってるんではないかな

> 何と「キャッシュ増やすと性能下がる」のほうだったという驚愕の事実があったばかりだからなあ・・・
驚愕してるのはD6lvz/8Zだけだよ。

俺最初からスルーしてるけどな

sandy延期？

元ソースこれだろ
http://www.brightsideofnews.com/news/2009/12/21/intel-tick-tock-slows-down-sandy-bridge-slips-into-2011.aspx

IntelのスライドにSandy Bridgeが書かれてないから、という下らない憶測

もともとイスラエルチームのモバイル向けだから、モバイル向けクアッドコアを優先供給という考え方も出来る。
2010年に出たとして少量生産なのは目に見えてると思うが

>>688
スルーっつっても糞を3つ「貫く」とかいうんではなく
この場合は「どれだけ馬鹿にされてもコピペ連投などで荒らさす押入れでジッと耐えること」みたいな意味だぞ

こんな記事でてたのね

SIGGRAPH ASIA 2009 - 非プラットフォーム依存パラレルの本命、「OpenCL」最新事情
http://journal.mycom.co.jp/articles/2009/12/25/siggraph02/index.html

非の位置がおかしいと思うのです
プラットフォーム【非】依存だろ、と

いや別に通じるけど

なにものにも縛られない
それが善司流

まあ"not platform dependent"って言わなくも無いけど

OpenCL最新事情
http://www.z-z-z.jp/BLOG/log/eid500.html

＞　既に、Deferred ShadingのライティングプロセスをDirectComputeで実装する試みは
＞DICEがFrostbite2エンジンで行っていますし、既に発売中の「Colin McRae: DiRT 2」は、
＞Ambient Occlusionの処理をDirectComputeで実装しています。

>>695
自由人すぎる

>>696 少なくとも native なら言わないだろｗ

現行のL2相当を排除してL3を高速小容量にしたものを2コアで共有するのがブルL2なのかね。
全体としてはCore2のL2を小さくしてその下に全コア共有のL3を持ってきたようなのをイメージしてるんだけど。
これだと現方式でL1、L2入れ替えがネックになって伸び悩んでる処理に強くなるかも。

>>700
んなややこしい言い方せんでも

下位の共有キャッシュが包括なのか排他なのか切り替えできるのかってことだろ？

＞これだと現方式でL1、L2入れ替えがネックになって伸び悩んでる処理に強くなるかも。

排他だけがネックじゃないからなんとも。
たとえばある2次元配列かなんかに0x10000単位のストライドで連続アクセスすると、2Wayセットアソシエイティブでしかない
K7〜K10のL1キャッシュ構造ではスラッシングが起きる。

排他やめたら「排他がネックになってる処理」に強くなるかな？
↓
ネックは排他だけではない！！！

普通の事ジャン

「排他がネックになってる処理」のネックが排他のせいなだけかどうか
ならともかく
AMDキャッシュL1のネック語られてもな

もうコアごとにメモコン載せちゃえよ

>>706
あほ？

>>706
俺も同じこと考えたことある

>>707
ダメなのか?

アニキ逃げる

>>706
そのメモコン経由のメモリアクセスが遅い（レイテンシがとても長い）から
L1/L2/L3キャッシュを緩衝材代わりに使ってるんだよ

だから、そのメモコンごとにL1/L2を搭載しても＜以下略＞

GPUの世界はシュリンクが進みすぎてメモリバスを引き出すのに
苦労してるみたいだな。今後はメモリインタフェースも高速シリアル
になっていくんだろうか。

>>706
つMagny-Cours
．．．いえ、なんでもありません

>>712
「コアごと」はたぶん本当の「コアごと」の意味だと思われる。
いまのPhenom X4ならばメモコンは4つ搭載。
Magny-Coursの12コア版ならば、メモコンは12個。
8コア版ならば8個という意味だと思われる。

どこのCellですか

>>711
XDR2にしてもまだまだ帯域足りないしなぁ
結局キャッシュに頼る事になるんじゃないの
なるべくオンダイで済む処理で高画質追求してさ
あといきなりリアルタイムレイトレのジャンプアップが難しいのはわかるけど
タイルベースレンダリングとかあの辺もやるべきなんじゃないかとか

AMDの場合はPC用はメモコン2個、MBのメモリスロットは2〜4（6）じゃないかな？

メモコンを複数積んだところで、メモコン⇔メモリー間のMB上の配線が無理でしょ

結局S3,NVIDIA,Intel路線に行くしかないんだよ
帯域足りないって言ってるのに、更に多画面に走るなんてアホダロ
どんだけ粗悪画で我慢させたいわけ？

S3は帯域足りてるのか

帯域って何の帯域だよ

nVIDIAは帯域以前の問題なわけだが。

エアGPUじゃ画面出せないしなー

S3以下略路線てのはキャッシュをうまく使うようにするって事か
確かにChromeは異常なようで、S3スレをちょっとのぞいてみたら面白いことやってた
なんかの開発者らしい人が、やはりChromeの異常（な速）さに気づいた書き込みがあり
それに興味を持った他ユーザーの要望に応え、サンプルプログラムを投稿
（任意サイズ、任意数のshaderを次々実行し切り替えるというもの）
これがchromeで異常に速い
高負荷でも速いが、起動直後のバッチ数100の場合は他のGPUの8倍は速い
（これはNVIDIA、AMD向け最適化後の話）

これがキャッシュの効果か、構造の違いによるものなのか、その両方なのか、それは知らないが
かなりのインパクトだった

Chromがいくら凄かろうがローエンドのチップしか絶対に出ないから。

ローエンドしか無い事よりろくに出荷する気が無い事の方を問題視すべきだろう

S3製品はロードマップ通りに出ているならミドルレンジでは十二分に戦えるだけの性能はあるはずなんだよな。
半年どころか一年遅延も当たり前ではローエンドでしか戦えないのは仕方がない。

ま、CPU屋が係った最初のGPUだからな
根本から違うんだろ

http://www.youtube.com/watch?v=S8cUp-8Fyr0
Shader Performance RadeonHD3450 vs GeForce8500GT vs Chrome540GTX

単純にShaderの作り込みの違いだろ

またそれか
芸が無いんだよお前は

AMDのことかｗ

>>727
なにこれ？

>>729
わからんがたぶん荒らしの如くURLコピペを繰り返す、
能無し野郎のことを言っているんじゃないか？

べつにネタがないから古臭い過去の遺物の増量しか出来ない会社のことじゃないよ

確かに古くはP6アーキまでほじくり返すのもなｗ
ATOMやらララ様とか酷いもんじゃｗ

増量にGPGPU性能が劣るNV

ha?

NV謹製のベンチでAMDに負けるNV

またanandのあれか
本当に芸がない

3倍のスペック差で2倍程度の差
はいはいがんばって増量しようねCPUもGPUも
そういやブルドーザーってクライアント市場狙ってないのかな
それとも6GHzとかで動くのかな

>>736
6GHzで動いたら他を圧倒しすぎだろｗ

なんで？

固定機能増量予定の屁ルミ、まだまだ増量路線のNV

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683
> AMD is also careful to mention that the integer throughput of one of these integer cores is
>greater than that of the Phenom II's integer units.

1integer coreあたりでもPhenom�Uより上

あてになんねーｗ

"Bulldozer"は純粋な新コアだから情報だけでは性能が推し量れないのが難点。
ただクロック辺りの性能がいまのコアより低いコアを出す理由も利点もない。
もし現状より低ければ、それこそコア開発失敗。K11頓挫だろう。
現状で頓挫していないのは、>>740の情報はある程度正しいと観るのが妥当。

ただ、それが「何処まで上か」を推測するのが「次世代CPUスレ」の楽しみ。
儲脳全開で否定するしか出来ない奴らは、vsスレにでも逝ってください。

IPCって以前はキャッシュ性能が重要と言われてた気がするが
Bullの構成が明かされてからは途端に「整数演算器の数」が優勢になったよな

「叩きたい場所を叩きたい奴」がいるからね。
そういう奴はまともな知識も持ってないので、
お話にならない。色々な意味で。

ピークIPC　→　演算器の数による
実効IPC　→　キャッシュによる

みたいな感じでしょ
もちろん他の要素はあるけど

何で1コアの中にロードストアや演算器が複数あるのかっていうと
1スレッドの中にも並列化出来るものがあって
基本的には演算の前にデータを読み出せるようにするのが目的らしいけど
1スレッド中でも本当はさらにスレッドを分けられるような書き方をしたコードもあって
この辺あまり詳しいわけじゃないけど演算器が複数あるのはそれを並列化するためだと思う

今後どんどんプログラム面でマルチスレッド化が進み（演算器に分配するんではなくコアに振り分ける）
今でも３並列な状況は珍しいとすら言われてるらしいんで
3つ目の整数の蛇足化は相当なものになるんじゃないかと思われる

おまえら、どうせもうすこし待てばわかることだし、今解ったからと言って、なんの実質的利益にもならんことなのに、
そんなに気になるのかBulldozerの性能が。

phenom2とCore2ってIPCって同等ですかね？
Core2の方が高いのかな。

>>747
気になる。AMD次世代CPUだしな！

>>748
Core2の方が良かったはず。

>>746
プログラムのMT化したからといって、ILPが減るわけではない。両者は完全に独立。

Bulldozerは、デコーダ共有で1スレッドあたりの命令発行数が減るので
それにあわせて整数演算器の数も最適化した。
これはトランジスタあたりのコア数を増やす一方で、スループットに大きな
ダメージを与えることはないが、だからといってシングルスレッドのパフォー
マンス劣化が皆無で済む、なんて旨い話はない。

そのような見方は>>740の"Phenom IIより速い"という話とは矛盾するが、
共有デコーダ、および整数演算パイプに隠された秘密が明かされない限りは、
半導体メーカーにはよくあるブラフ、リップサービスの類だと判断する他はない。

AMDは今年もPhenom2だけで戦うのか
それともGulftown対抗の6コアを安く売るのかな

>>640
　　-------------------
　　とりあえず決まったら就職祝いとしてCi7買うかなw
　　-------------------
アム厨をさんざん煽った当人はこんなモノ…と(笑)

しかしユーザーから見て、彼はデマ・嘘・無能に溢れていたHector Ruiz時代を象徴する
ような人物でしたらから、『新生AMD』を印象付けるためにも早めに切るべきでしたね。

一介の広報担当であった彼自身には何の責任も無い訳ですが。

>>740はどう解釈すべきなんですかね(「新生AMD」的に考えて)

雑音を無視して話を進めると
と言っても別に詳しいわけじゃないから大部分推測だけど
演算器での並列作業では同じコアの同じキャッシュでデータを共有出来る
しかしそこからスレッドを分けてコアを違えるとなるとデータの受け渡しがあった場合面倒なことになる
共有キャッシュがあるといってもX86ではL2からだし遅延は大きい
いくら依存性が無い（順番無視して演算出来る）処理でもデータの関係性が深いとスレッドを分けると遅くなるかもしれない
その辺はどうなるんだろうか

ただゲームは作りのややこしさから以前はシングルスレッド一点張りだったのを
プログラマが頑張ってマルチスレッド化してる最中だし
コアレベル(?)の並列化は進んでいくと思われる

コアや周辺拡張をPhenomとイコールで考えているから間違えなんじゃね？
P6からの拡張とされるCore系でもかなりの拡張と性能向上が観られた。
さらには"K8"アーキティクチャは既に限界に達している事から、
"K8"コアをそのまま使う可能性は低いと思われる。
ただ、「どんな拡張がなされているか？」となると、まさに、

>共有デコーダ、および整数演算パイプに隠された秘密が明かされない限りは、

うちらは妄想して、遊んでいるしかない。その為のスレだし。
よって>>740の見解は、まぁ。額面のまま受け取っていいんじゃね？
そもそも性能を低く見積もる必要性なんて全くないし。

コンパイラがもう少し賢くなれば整数性能はもっと上がるんじゃ
ないかと思うよ。x64モードで増えたレジスタを活用するとか、
コードの前後関係をもっと詳しく分析してロードストアタイミング
を最適化するとかね。

x86とはいえ内部RISCマシンだから、デコード後を見据えた
アセンブリを吐くようにできたら多少は早くなると思う。

Clarkdaleに対抗する新製品あるの？
いつまでPhenom 2 X4のまま？

>>758
Clarkdale対抗はAthlonIIX3で十分なんだが。
PhenomIIX4はi5/i7対抗。

まあ、Clarkdaleで自作する奴の大半が別途GPUを買うし、せいぜいHD5770でも買ってAMDの利益に貢献してくれるだろう。
それと、メーカー製には、価格の高さからほとんど採用されなさそう。
総じて、i3やi5はAMDにとって大した脅威ではない。

>>759
既にAMDが先行してるってことね
これで安心して2 X4 945買える
5670も楽しみ

あとはサーバー用にatomの対抗馬が欲しい

AthlonII、価格の安さでメーカー製にいっぱい採用されるといいね

確かに売れたらいいのだけど、
Intelは大量出荷先には、超安価で卸しそうだからなぁ。

結局最後に物を言うのはコストだからな

>>753
それギャグだろ

本当に買うかどうかは分からん

>>764
本人が冗談ですとフォロー入れてるのにね
まぁ揚げ足取りしか能の無い奴は相手する必要ない

>759(笑)

i5 670は売れるだろうなぁ

3.46GHz-3.73GHzとクロック高いからな一般用途じゃ一番快適なんじゃないか

ｸﾗｰｸはグラフィックス性能が3倍増なんだよ(上の空

はいはい

いつもの3倍の回転をくわえるのか

両手でやるのといつもの2倍ジャンプするのも忘れるなよ。

貧乏なので、おととしの年末の一番安いときに買ったDDR2を活用できるAMDが好きです。

AGUでも整数演算できるんでないの？
とは言っても加減算くらいになりそうだけど

>>773
DDR2はそろそろDDR3と価格容量比逆転する頃合いかな。
って考えるとAtomは微妙になってきた。

VIAもDDR3に対応してきたしね

777

620が7000円を切ったら本気だす

>>778
AMD Athlon総合 (AM2&AM3) その101
http://pc11.2ch.net/test/read.cgi/jisaku/1262272738/

でも店頭価格はDDR2が多少値下がりしているのよね

CPU、メモリ、HDDはギャンブルだって店員スレで言ってた

仕入れる側だとそうだろうな

買う側だと
必要なときに必要なブツがある程度の価格で手に入ればいい
となるかな？

bulldozerはSandy bridgeに勝てるかなあ？

Sandy BridgeはCrayスパコンに採用内定

※Crayと名が付きゃ崇め奉るという業界ルール

bulldozerはSandy bridgeに勝てるかなあ？

MACオタはNehalemがCray(TOP500で1位)に採用されると言っていた

>>787
でなきゃわからんが、AVXが絡むベンチでは負ける。

>>787
勝ってもらわないと困る。

でもベンチがちょっとの差で負けたからって使えないってもんでもないけど。

Sandy BridgeってGPUなしバージョンも在るのけ？

鯖用はGPUなしらしく、その流用のハイエンド向けプラットフォームもGPUなし。
メインストリーム用は既出のLGA1155のGPU統合版だけになるんじゃないかな。

LlanoでSandy Bridgeと競争できるのかな。
現状のAtlon�U、Phenom�U+780Gですらシェアが減少して
競争力があまりないところをみると、Llano vs sandy bridgeでも
大して変わらなさそう。それどころか、Intel側のGPUがそこそこの
性能になったら、唯一のアドバンテージもあまり評価されない気が・・・・。

>>792
GPUの替わりにQPIとか載せてくんのかね
まぁ、GPU側もなんかやってきそうだけど

シェア減ってるのはAtomのせいだぞ

>>794
http://www.toranoana.jp/mailorder/article/04/0010/20/38/040010203841_popup2.html
SandyBridgeのハイエンドはこんな感じになるらしい。
コア数や増えるレーン数からすると、GPUなくなってもダイサイズがかなりでかそう。

>>796
コレなんてエロ同人誌？

>>796
Bulldozerが勝つのは相当難しそうだ

Bulldozerは出る前から敗北が決定してるようなもんじゃないか

http://www.expertspc.com/report.php?report_no=37&page_no=1
こっちだｗ
>>797
元ネタはうみねこのなく頃にしかわかｒん。
別板に貼ってあったURLだから。

擬似16コア vs 12コア vs 4コア

Sandra 2009 SP3 Benchmark Result on WinXP-Pro SP3
======================================================
CPU 　　　XEON E5540　　　OPTERON 2435 　　　C2Q Q6600
Core　　　2x 4core+HTT　　2x 6core 　　　　　1x 4core
TDP 　　　2x 80W　　　　　2x 75W 　　　　　　1x 105W
Clock 　　2x 2.53GHz　　　2x 2.60GHz 　　　　1x 2.40GHz
Memory　　6xDDR3-1066R　　4xDDR2-800R　　　　4xDDR2-800
M/B 　　　Super X8DT3 　　Tyan S2927E　　　　Dell 755
ChipSet 　Intel 5520　　　NVIDIA NFP36k　　　Intel Q35
------------------------------------------------------
Int. 　　　132GIPS　　　　　106GIPS　　　　　37GIPS
F.P. 　　　119GFLOPS　　　　102GFLOPS　　　　29GFLOPS
1'Cashe　　419GB/s　　　　　485GB/s　　　　　201GB/s
2'Cache　　258GB/s　　　　　307GB/s 　　　　　33GB/s
3'Cache 　　91GB/s 　　　　　81GB/s 　　　　　(Non)
Memory　　13.9GB/s 　　　　20.0GB/s　　　　　4.7GB/s
FP*Mem　　１６５４ 　　　　２０４０　　　　　１７４
------------------------------------------------------
MM-Int 　　239MPix/s　　　　284MPix/s　　　　80MPix/s
MM-FP 　　192MPix/s　　　　134MPix/s　　　　50MPix/s
MM-Dbl 　　100MPix/s 　　　　73MPix/s　　　　25MPix/s
Cording　　761MB/s 　　　　1000MB/s　　　　　364MB/s
------------------------------------------------------
FileSystem NTSC by LSI_MegaRAID-SAS_RAID5 (4xSATA)
・R.Read　　66MB/s 　　　　　62MB/s 　　　　　----
・R.Write 　32MB/s 　　　　　60MB/s 　　　　　----
・S.Read 　123MB/s　　　　　340MB/s 　　　　　----
・S.Write 　48MB/s　　　　　270MB/s 　　　　　----
======================================================

そのベンチはあちこちに張られているが、Xeonのメモリが不可解に遅いのが気になる

>>796
サンディがデカ過ぎだということがよく解った

Sandy大きすぎるから無理なように思えるけど
結局なんとかなりそうな気がしてきた。

PC市場はLlanoとOntario投入でAMDの勝利だな。
如何にCPUの性能が高くても、ゲームも動画支援もろくに出来ないGPU搭載のSAndybridgeじゃ、
DX11対応で、ゲームもそれなりに出来てGPGPUにも対応出来るHD5570クラスのGPUを内蔵するAMDのAPUには到底敵わんよ。
Office用途じゃAMDとIntelに大差ないし、メディア系のソフトはGPGPU(DXCS)への対応が進んで圧倒的に差が出るからね。

Llanoはいわば、AthlonX4ori5 + HD5570
ontarioは、AtomDC + ionの強化版

だからね、売れない方がおかしい。

今後は、superpiとかのCPUベンチだけが少し速くGPGPUには対応できないIntel、
それなりにゲームが出きてGPGPU対応でエンコードとかがかなり速くWin7完全対応のAMDになるだろう。

唯一Intelが勝つための道は、DirectComputeやOpenCLなどのGPGPU普及を全力で阻止することだな。
つまり、MSやAppleに真正面から喧嘩売ることしかないね。あとadobeとか。

私は馬鹿です
まで読んだ

>>805
メーカー品にもっと採用されないと意味ないんだぜ
AMDしか買ってない俺でも思う

>805
時々こういうのが出てくるるとホッとするというか
ほのぼのとするよな
今後も適度に電波頼むよ

>>807
そのへんは、和解したしFTCやEUが強く出ているとはいえ、今まで脅されていた側が、
脅しがなくなったからといって急に態度が変わるとも思えないから、大手から徐々に採用が多くなっていくと思う。

まあ、和解直後、多数の独禁法違反訴訟、ソケット乱立、LarrabeeによるGPGPU市場進出の大幅な後退など、
Intelの足かせは意外に多く、逆にAMDはAPUとGPUの新製品投入にWin7とDX11やOpenCLの後押しも加わり、
2011年からの数年は恐らくAMDにとって過去最大の反撃のチャンスなのは確か。
(SlotAのAthlonやAthlon64X2投入時以上と思う)

はいはいワロス

で、後押しするはずのOpenCL,DCのソフトって何時出るの
10240bit（笑）で

ttp://en.hardspell.com/doc/enshowcont.asp?id=7475&pageid=6387
4coreが2coreと競ってるようじゃどうしようもないでしょ

たとえば320SPであろうが35.2gflopsのGPUに負ける程度にトテモ速いものじゃ意味ないんだよ

>>811
> で、後押しするはずのOpenCL,DCのソフトって何時出るの
> 10240bit（笑）で
>
> ttp://en.hardspell.com/doc/enshowcont.asp?id=7475&pageid=6387
> 4coreが2coreと競ってるようじゃどうしようもないでしょ

OpenCL/DCに対応しないIntelには関係ないから気にすんな。

エンコード速度比較
ttp://www.dosv.jp/other/0907/img/01/pop/078.gif

i7 965 vs HD4650 vs HD4770(これ以上のモデルは大差ない性能)

i7 965 10万円
SD解像度：49s
HD解像度：324s

HD4650 5千円
SD：38s
HD：123s

HD4770 1万円
SD：18s
HD：90s

GPGPU対応ソフトだとHD4650にすら負けるi7とか別にいらんだろ。

> 2011年からの数年は
「ビグザム量産の暁には」という奴だが、その手の目論見はあまりうまくいかない。

おまえら、数年ぶりの大提灯が読めるかもしれないと思うとwkwkしないか？

>>775
ａｔｏｍは初めっから微妙　性能低すぎ

>>793
そこそこの性能にならないから

北森にベンチ出ててＡＭＤ、ＮＶの最下位クラスに惨敗してたはず

インテルのグラフィック成功したためしないから　いつも性能が低すぎる

>>805
LlanoとOntarioが少なくとも去年末、あるいは今年年頭に
発表・発売されていれば、確かに数年安泰だったけどなぁ。
来年対決することになるコアは"Sunday Bridge"コア流用だから、
GPU性能差もある程度CPU性能で押し切られる面もあるだろ。

まぁ。"Sunday Bridge"がどの程度の性能を示すかは、
未知数なんだけどね。

お、320wayのお馬鹿ちゃんいてるｗ

>>813
画質あたりのサイズは？
CPUと比較して同等の画質を達成できなかったり、できても容量大きかったりしてエンスーはそんなもん使わないよ。
非エンスーだとたまにしかしないからCPUでやっても大した負担にはならない。
ブルドーザには期待しててもGPGPUなんぞには期待してない。

>>814
ビグザム量産してから戦うのと同じなんだぜ？

あるいは
ガンダム(CPU)だけのIntel vs
ビグザム(CPU)+エルメス(GPU)+ジオング(APU)のAMD

>>820
> >>813
> 画質あたりのサイズは？
> CPUと比較して同等の画質を達成できなかったり、できても容量大きかったりしてエンスーはそんなもん使わないよ。
同じ処理をCPUとGPGPUで比較しているんだが。
GPGPUだけは手抜き処理とかじゃないから、その質問に意味はないな。

> 非エンスーだとたまにしかしないからCPUでやっても大した負担にはならない。
> ブルドーザには期待しててもGPGPUなんぞには期待してない。
今のGPGPUには俺もたいして期待してないが、SSE対応と同程度には近い将来普及する可能性が高い。
そのきっかけがDX11対応のHD5xxxであり、GPGPU対応CPUのLlanoだと思う。
ちなみに、開発用のハードは去年の6月から配布しているから、早いところは今年の夏くらいには対応製品出してくるだろうね。

>>821
>ビグザム(CPU)+エルメス(GPU)+ジオング(APU)のAMD

最後の「ジオング(APU)」が意味わからん。
"Sunday Bridge"もAMD的表現にすればAPUなんだが。

Sunday Bridge の検索結果 約 57,500,000 件中 1 - 10 件目
Sandy Bridge の検索結果 約 8,950,000 件中 1 - 10 件目

仕方ないかな

Fusion路線がもっと早く実現してたらよかったのになぁ、もったいないなぁと思うねぇ
昨年あたりから出ていれば今頃市場を席巻してたかもしれん
しかしまさかここまでCPUの形骸化が進むとは思わなかったな
Core2が出てきた時の絶望感はいったいどこへやらと言う

>>822
良いエンコソフトがまだGPUに対応してないらしいから（エンコ部分が）
未来を待てない精子にはGPUが無価値でも仕方ない

>>822
同じ処理をするソフトが存在しないじゃないか。
>>813は時間だけで出力結果の比較がない。
5xxxでCPU品質のエンコードができるようになるなら俺も歓迎するよ。

仮にGPGPUが普及したとしてもLlanoの競争力はあくまで単純な描画能力だと思うよ。
CPU使用率が50%を超えない人が動画再生支援やらを求めて選ぶ製品。
そもそもGPGPUの処理能力を必要とする人はビデオカードを買うよ。
だからLlanoのGPGPU部分が売りになるとは到底思えない。

>>821
PhenomIIは何になる？リックドムぐらい？

GMくらいじゃね。

精子「CPU用のコードとGPU用のコードは違うじゃないか！」

AMDは粗悪劣化変換ソフトavivo video converterに丸投げしてるだけ
nvはソフト開発側がCUDAに最適化しているが、当然CPUと同じ処理ではない
>>820,822,827
はいはい、元記事

http://www.dosv.jp/other/0907/11.htm

＞同じ処理をCPUとGPGPUで比較しているんだが。
＞同じ処理をCPUとGPGPUで比較しているんだが。
＞同じ処理をCPUとGPGPUで比較しているんだが。

>>827
ノートＰＣになれば俄然輝きが増す


知ってる人は知っているって位置づけ　指名買いも増えてくると思われる

家で使うので消費電力の差は問題にならない

> 実際の結果はグラフを参照してほしいが、まず目立つのはATIのRadeon HD
> シリーズが軒並み高速な点だ。ただし、実はこれは少々ワケアリで、変換
> 後の動画がインターレースのような状態になってしまっている
それで813で記事ではなくグラフ画像に直リンクしてたのか。流石。

>>831
>その後最新のCatalyst 9.5がリリースされており、
>これを使うと変換速度は落ちるものの、
>この問題は解消されていることが確認できた

ふむふむ。

しかし、その画像もエンコ時間ものせない

新年早々バイトの10240bit君は元気なようだな

精子は死の間際に
「CPUとGPUでは処理が違う」
という幻文を見た

GPUエンコなんて両社とも糞画質なんで
どんぐりの背比べなんで

おなじ処理してるなら画質の差なんて出るわけないから

「オリジナル」が「CPUエンコ」に見える幻覚継続中か

アム厨っておもしろいね

今も残ってるのは筋金入りだからな

あいつは自称皮肉屋を気取っててなんだか中二臭いんだよね

自称「皮肉屋を気取ってて」なんだか中二臭いんだよね　？
自称「皮肉屋を気取っててなんだか中二臭いんだよね」　？
自称を気取ってて　？

　ガチでやり合ったらボロが出るから、ああやって言い逃げしている
だけでしょ。

あいつは自称｢皮肉屋｣
そんな風に気取っているあいつはなんだか中二臭くて痛々しいんだよね

ご本人から指摘があったので

>>842
ﾜﾛｯｼｭｗｗｗｗｗｗ

何言ってるか解らないうわごとを串使って並べられても遠吠え「スライムは仲間を呼んだ！」にしか見えないんだが

ttp://pc.watch.impress.co.jp/docs/2008/0829/ubiq225.htm
＞逆に言えば、エンコードエンジンはバリバリにx86プロセッサに最適化されたものであり、
＞ほかのソフトウェアのように上級言語でセオリー通りに書いたものではないため、
＞GPUに対応させるとなると、ほぼスクラッチから書き直しするのに近い作業規模になると考えられる。

質の高いエンコソフトは長年掛けて熟成されたものであり
そうすぐには作り上げられない
同様に今あるGPUエンコソフトもすぐ作られたものであるから質が良くないものしかない
「GPUだから質が悪い」とか言ってる可哀想な奴は放っとくとしても
「GPUとCPUで同じ処理をしてない」と言うにはエンコ後の現物かソフトの中身を見るかするしかない

スｗｗラｗｗｗイｗｗｗムｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

あのさ
CPUとGPUが同じ処理してるってんなら
そのGPU同士で画質の差が出るのはおかしいだろ

何だ冬だから初心者が来てるのか
エンコの質はソフト次第って言ってることから（知識があれば）判るように
CUDAに対応してないAMDのGPUはちゃんと構って貰うのは難しい
エンコでCPUと勝負って言ったら普通に考えてｹﾞﾌｫのほうだけ

>>850
全くその通り。圧縮アルゴリズムが同じならどんなアーキテクチャでやってもほぼ同じ結果にならないといけない。
違っていいのはせいぜい内部の浮動小数点計算部の精度程度のもの。
圧縮アルゴリズムとプロセッサ向け最適化の区別がついてないのが居座ってはいるけど。

今の話題と微妙にずれた話だが、圧縮ファイルのバイナリ一致について

圧縮エンコーディングというのは、超多変数の汎関数の停留値探索を途中まで
やるみたいなもので（最後までやるのは非効率なので妥協する）、
パラレリズム（色々なレベルの）を効率よく使おうとすると
変数全体ではなくその部分集合によるローカルな最適化も利用され、
理想的なグローバル最適化と実質的価値はほぼ同等（どっちも途中までだし）でも
数値としてはわずかに異なる解が導かれるような方法が選択されることもある。

なぜそのような方法が選択されるのかというと、ハードウェアが変われば、
そのハードが最も得意とする部分集合の取り方がかわるから。

確かx264 もシングルスレッドとマルチスレッドで結果が完全には
バイナリ一致しない方法を取っているんじゃなかったかな。
CPU上のスレッド分割ですらそういうものなので、毛色の違うハードではなおさらだろう。

>853　は見た目画質が異なる場合の話じゃなくて
同等の画質なんだけどバイナリ一致じゃないよって場合の話ね

画質って言い方漠然とし過ぎなんだけど
１ピクセル単位の色情報レベルではどうなの

>>851
業界標準たるDirectComputeとOpenCLが動き出した今、Nvidia限定のCUDAはもう落ち目だよ。
ハードウェアでパフォーマンスリーダーだったらまだわかるけど、
Fermiが難航してやることなすこと裏目にでるNvidiaと、
最新API、最新プロセスに直ぐに対応し、
下位のレンジやモバイル向けにもスピーディーに展開したAMDのどちらで今後ソフト開発が進むかは語るまでもないな。

CUDA対応ソフトといっても、動かすのが9600GTやGTS250じゃ作る気も失せる。
HD5870とGTX285のどっち向けにソフト作りたいかといわれれば、将来性考えて普通はHD5870向けだろ。

CUDAが業界標準みたいな幻想って哀れ

非PCなら独自先行も生きてくるんだけどねぇ

未だ代表的なソフトが存在していないDirectComputeが業界標準とか莫迦もほどほどに。
TOP500に占めるOSシェア見てみればわかるけどHPCはLinuxの独壇場でWindowsが付けいる余地はないよ。

残りの市場にとっては、それぞれの会社の思惑で乱立する「Cの方言」の1つでしかないんだけどな。

ぶっちゃけCompute Shaderは事実上Windowsのゲームくらいでしか使い道はないが、
そのゲームに即戦力として使いたい肝心の「出来合いの物理エンジン」なんかが未だに存在してない。
NVIDIAはPhysXをいち早くCUDAに対応させ、IntelはLarrabee計画に先駆けてHavokをキープした。

多くのゲームベンダが欲しいのは出来合いのライブラリであって、「クセのあるC/C++言語の方言」なんかじゃないんだよ。
プラモデルしか作ったことない連中に材料の原油と化学染料渡してガンダム作ってくれって言っても無理があるだろ？

>>855
>853-854　で言ってる画質は元の映像と非可逆圧縮映像の”近さ”を
測る尺度でほぼ同等の数値という意味だよ　尺度にもいくつかあって
体感と傾向が異なると言われるもの、近いと言われるもの、色々だが

MPEGなんかエンコードにもデコードも実装方法によって全然別モノになる。
JPEG自体がそうだし。

あれだ、結局質が落ちるってのはDCT(離散コサイン変換)をどうサボったかってことだろ。
CPUには1コアあたり数百KB〜数MBで数百GB/sの帯域でアクセスできるL2キャッシュがある一方
雀の涙ほどのスクラッチパッドメモリしか与えられず100GB/sを越えるかどうかのメモリ帯域を取り合う
実効精度を大幅に犠牲にしてルックアップテーブルのサイズを小さくしつつ、厳密な処理も近似に落とし込まないと、
「CPUより圧倒的に速い」と言えるほどのスループットが得られるわけがない。

結局、どう足掻いても、速い、不味い、だ。

>>858
> 未だ代表的なソフトが存在していないDirectComputeが業界標準とか莫迦もほどほどに。
CUDAにだって代表的なソフトなんてないだろ。
もしかしてTMPEGencとかいうつもりか？それともフィルターが対応しただけのPhotoshop?

> TOP500に占めるOSシェア見てみればわかるけどHPCはLinuxの独壇場でWindowsが付けいる余地はないよ。
そんなことは誰だって知ってる

> 残りの市場にとっては、それぞれの会社の思惑で乱立する「Cの方言」の1つでしかないんだけどな。
>
> ぶっちゃけCompute Shaderは事実上Windowsのゲームくらいでしか使い道はないが、
> そのゲームに即戦力として使いたい肝心の「出来合いの物理エンジン」なんかが未だに存在してない。
> NVIDIAはPhysXをいち早くCUDAに対応させ、IntelはLarrabee計画に先駆けてHavokをキープした。
Physxゲームは相変わらず数が少ないし、DX11ゲームへの採用は当分ないし、
現行のコンシューマーはGPUで処理できないから結局CUDA対応はほとんど意味が無いよね。
havokは実際はAMDが開発していたけどね、Intelは放置していただけ。
LarrabeeがキャンセルしそうでIntelもやる気が無くなったからAMDはBulletに移ったんだろうな。

> 多くのゲームベンダが欲しいのは出来合いのライブラリであって、「クセのあるC/C++言語の方言」なんかじゃないんだよ。
> プラモデルしか作ったことない連中に材料の原油と化学染料渡してガンダム作ってくれって言っても無理があるだろ？
見切り発車レベルでしかないからライブラリが絶対的に不足しているのは仕方ない。
とはいえ、乱立したままじゃ疲れるだけだし、それぞれ思惑はあれどApple、Intel、Nvidia、AMDという大御所がこぞって対応を表明しているから、
今後拡充してくるのは確実だろう。
それが十分使えるレベルになるのは数年後だろうけどね。

まあMSが並列化言語として押してるのは普通のC/C++やC#なんだけどな。
2010のマルチスレッド周りのテコ入れ加減みればわかる。


> Physxゲームは相変わらず数が少ないし、DX11ゲームへの採用は当分ないし、
> 現行のコンシューマーはGPUで処理できないから結局CUDA対応はほとんど意味が無いよね。

この状況をわかってなお、ゲームでGPGPU市場が花開くというおめでたい未来予想図が描けるなら大したものだよ。
たとえばBulletがどれだけ売れたのよ？もしくは売れるのよ？PhysXやHavokより普及する見込みあるの？

知ってると思うがGPGPUのゲーム活用の急先鋒たるNVIDIA自体がゲーム市場にはある程度見切りをつけている。
（従来ゲームに割いてた技術支援関連の予算を大学や国研なんか回るのに使ってる）

物理エンジン屋の買収は競合企業の嫌がらせを狙った敵対工作の色のほうが強いと思ってるが。

前向きな話をしようか。
わかりやすいところで言うとWiiのスマブラXにもHavokは使われてるよ。
あとPhysXはナイツとかでも使ってたかな。
てなわけでコンシューマ機しかもWiiですら2大物理エンジンは使われてるんだわ。

ソフト屋を物理エンジンのAPIに慣れさせることが重要だ

PhysXがCUDAで書かれていようが、PhysXを使うのにCUDA触らせる必要なんてないんだよ。
CPUとGPUのプログラミングパラダイムの違いはエンジン屋が吸収する。
エンジンを書かないアプリ屋はC/C++だけ使ってればよろしい。

> わかりやすいところで言うとWiiのスマブラXにもHavokは使われてるよ。
> あとPhysXはナイツとかでも使ってたかな。
> てなわけでコンシューマ機しかもWiiですら2大物理エンジンは使われてるんだわ。
どっちもCPU処理だし歴史が深いから当然だね。
ただし、AMDがPhysxに対応する気がないし、havok対応は途中で止めたからGPUで処理出来ないけどね。

その代わり今はBulletに取り組んでて、ドライバでそのうち対応するでしょ。
シェアは確かに前者の2つには及ばないけどそれなりにあって環境もそれなりに整ってて、唯一のDX11GPUメーカーのAMDが対応したことで、
今後は普及してくると思うが。

> ソフト屋を物理エンジンのAPIに慣れさせることが重要だ
ゲーム屋さんはとっくに慣れていると思うが。
世の中にどれだけの物理演算ゲームやエンジンがあると思ってるんだ。

NvidiaがDX11対応GPUを今だに持ってない以上、DX11対応のゲームやエンジンやソフトはAMDのHD5xxxをベースに開発するしかない。
そして、半年たった今かけてかなりの数がソフトベンダーに配布されているだろうね。
そのAMDがBullet対応する以上それに従わざるをえない。
なんたってGPUで処理すればCPUよりも速くなるのはPhysxが証明したからね。
今はまだ整ってないから独自エンジンやhavokだけど、対応が進めばBulletゲームも増えてくるだろうな。

ついでにBulletの現状
ttp://bulletphysics.org/wordpress/

シェア10% (Physx 27%、havok 23%)
PS3/XBOX360/Wii対応のエンジンやゲームあり
実はCUDAも対応していた(今は知らん)

結構環境は整ってるみたいで、知名度の差による開発者の数の差が問題だから、後はAMDのサポート次第だな。

CPUより遅くて大失笑をかったOpenCL Havok FXをお忘れですか？

GPUでやれば速いなんてのがそもそもの間違い
nvのG80,G92,GT200世代ですら数に物言わせた力業だ
現に58gflopsのPPUと同パフォーマンスを出すためには、9600GTの312gflopsをPhysx専用に使わなきゃならん

AMDのGPUは更に不向き
重要なのはハードの構造

重要なのはハードウェアの構造とソフトウェアの構造のマッチングだろう

あるハードウェアに対してマッチする構造のソフトウェアが試みられた事が
ないのと、あるけどダメだったのとは同じじゃない

>>865
最後の1行が素人臭さを演出しているな。

>>865は10240bit君（笑）か。

ゲームで普及を諦めた？
当たり前だろ、NVだけ対応ですなんて売れますかいなｗｗｗ

amdのGPUにマッチするのは何？

ないある

>>867
ただの素人だから素人臭いのは仕方ないな

と、一番の素人が申しておりますｗ

AMDのGPUに無理やり物理やらせてあげるのに
高すぎるCPU負荷をかけてVLIWを発行したあげく
CPUより遅いなんて無駄の連鎖は要らない
CPUでやらせた方が良いに決まってる

ClarkがGPGPUに対応する
つまりこれはインテルの一時的な負けを表している
Clarkが対応したからってどうなんだっていう話があるがそれはそれとして

10240bitちゃん元気だな

CPUとGPUが連携して行う処理での一番のネックはその間の通信速度と言われてたりして
それを解消するために統合するんだろうけど
とにかく早くやってもらわないと馬鹿が有頂天で困る

一次Intel派のFUSIONがどうだと散々バカにする発言が多かったが、
MCMでも近場に置くだけでアレだけ性能上がったからなぁ。

馬鹿を有頂天にさせて、Llano登場でたたき落とす算段だろう

Llanoはどうやって売り込むんだろう。

現状のX4 630がマルチスレッドのソフトでi3以上、悪いと
G6950~i3 540くらい。
http://www.xbitlabs.com/articles/cpu/display/clarkdale-review_12.html#sect0

Llanoでは、L2$倍増、DDR3 1600対応で性能が上がるだろうけど、
sandyには遠く及ばないはず。GPU部分は圧勝だろうから、
ゲームベンチや、GPGPUベンチを全面に押し立ててくるのかねぇ・・・。

なんかキャッシュ増やすと性能下がるって聞いたけど大丈夫なの？

馬鹿なの？

>>880
CPU部分は足回りの改良とクロックの向上が性能向上の主体なんじゃないかな？
あとはGPU部分の良さでシステム全体としての性能が上なことを売りにするんじゃないかと。
2チップ構成で、APUのダイサイズもあまり大きくないから、スリムPCなんかにも売り込めるだろうし。

>>880
> Llanoはどうやって売り込むんだろう。
>
> 現状のX4 630がマルチスレッドのソフトでi3以上、悪いと
> G6950~i3 540くらい。
> http://www.xbitlabs.com/articles/cpu/display/clarkdale-review_12.html#sect0
>
> Llanoでは、L2$倍増、DDR3 1600対応で性能が上がるだろうけど、
> sandyには遠く及ばないはず。GPU部分は圧勝だろうから、
> ゲームベンチや、GPGPUベンチを全面に押し立ててくるのかねぇ・・・。

何をどうやっても売れるけどな。
逆にSandyが微妙。
世の中の殆ど全てが4スレッドの3GHzでまかなえる現実。(市場の95%以上)
ダイサイズから予想される初期の価格。
Llano=160mm2(propusと同等)=AthlonIIX4位の値段=2万円以下
Sandy4コア=220mm2位=100mm2以下のClarkdaleよりもかなり高い=3万円以上。
(一番下位やHTTナシが2万円くらい)

i7+GMAのSandyに3万円払うのと、AthlonIIX4+HD5570のLlanoに2万円払うのはどっちが得かは語るまでもないな。

ちなみにSandy2コアが約150mm2位でLlanoより少し小さいくらい。
恐らくこれがLlanoの直接のライバルになるだろう。

・CPUの性能
Sandy4コア>Llano>Sandy2コア
・GPU性能
Llano>>>Sandy4コア>2コア
・値段
Sandy4コア>Llano=Sandy2コア

>100mm2以下のClarkdaleよりもかなり高い=3万円以上。
100mm2以下なのはCPUコアだった。GPUが114mm2で合計200mm2位だね。
そう考えると、Sandy4コアの初値はClarkdaleのi5の更に上の値段で2万円以上かな。
恐らくLynnfieldとあまり変わらない価格になりそうだ。

お花畑が過ぎる

>>884
ゲーミングPCはプレミアム価格で売れるからなのか、
各社力を入れてるみたいだから、sandy2コアより
ずっと高い値段設定にできるなら勝機はあるかもね。
480SP?+高クロック+CPU,GPU間のボトルネック解消で、
RV830以上、RV840未満くらいの性能にはなりそうだし。

>>885
ダイサイズとか関係ない。ブランド保持のために、
Intelが上位コアを安値で売る事はありえない。
その時点で上位コアは現状の"Lynnfield"と価格は変わらない。
価格が下がる可能性があるのは、"Bulldozer"や"Llano"が
性能を出した場合のみ。
それでも上位の価格が下がるとは思えない。

>>881
その上でキャッシュ増量傾向にある現状が大丈夫なの？なのか
そんな法則があるこの世が大丈夫なの？なのか
そんな発言してる奴が大丈夫なの？なのか

キャッシュは増量するとレイテンシを小さいまま維持するのが難しい。
L1キャッシュには、もっともよくアクセスする命令やデータが保存されているのだから、
L1キャッシュのレイテンシが大きくなると性能への影響が大きい。
なので、L1キャッシュの容量を増やすのは難しい。
ってのをどういう風に誤解したのかわからないが、キャッシュが増えると性能が下がる、
と言ってるやつがいるだけ。
無視したらいいよ。

キャッシュをメインメモリに置き換えればわかる話なのにね。

なんだ勘違いかあ
いや、スレ汚しすまんね

L1にすっぽり収まる規模のデータならL1の速度が重要だが
L2容量差でベンチ差が凄いゲームだとかもっと規模の大きいもの
L1程度の容量なんて小さ過ぎて見えないようなものは
L1のレイテンシがちょっと増えても容量が倍になったほうが良い
L2以下のレイテンシはもっと多いから

AMDにしたら4コア版が160mm2、2コアで110mm2前後で作れる
Llanoが高値で売れた方が利益はでるだろうけど
たとえ4Ghzで動いたとしてもNehalemにすら勝てないだろうし
Llanoが前面に出過ぎてもBulldozerの影が薄くなるだけだから
あくまでまでも省エネ＋低価格路線で売り込みそう

で、Llano以上のパフォーマンスを求める人は
（当然だけど）Bulldozer＋GPU（か、チップセット内臓GPU）でって割り切りそう

個人的には5〜6万円台のノートに
2コア版のLlanoが乗ればいいな（VAIO TypeNシリーズとか）

>>894
4GHzで動けば勝てるだろ。

>>894
1プロセス進むごとに、演算性能が二倍前後になるみたい(RV730→830はあんまり
上がってないけどw)だから、480SPのLlanoは、来年登場の製品のうち、
$79以下のローエンド相当だろうな。RV810が80SPのままなところをみると、
もうローエンドGPUはストップで、Llano一本になるんじゃね。

>>893
その辺はAMDのアーキテクトが色々考えて、増やすか増やさないか決めるんじゃないの？
シミュレーションしてみたらコストに見合わない性能向上なのかもしれないし、
LlanoではCPUコア部分はいじらないで、速やかに製品を出すことを優先しているのかもしれないし。

>>887
今ある高価格高付加価値系ゲームPCの市場では別途GPUを搭載するのが当たり前なので、
少なくともその市場においては内蔵GPUの性能でもって売り込むのは難しいだろう。

AMDは低価格ゲームPCの市場を開拓しようと頑張ってはいるものの、いまいちぱっとしない・・・が、
シェアでは遙かに上を行く競合他社の新製品はそこそこの性能を出してきているので、
若干チャンスが生まれる可能性もある。

>>897
別に今後のAMDがL1容量をどうするかなんて話はしとらんのだけど

ただまあBullなどを鯖メインとしてやっていくつもりならそれに容量等は合わせてくると思う
AMDの（今のアーキの）L1はway数が少ないのをよく言われるけど
「鯖のプログラムは局所性があってキャッシュ要らないからAMDはキャッシュが少ない」
なんて書き込みを北森で見て、後半は明らかに間違いだけど
局所性があるんならway数が少ない＝データの塊が大きいのは鯖向けとして正しいんだよな

まあ実際はそんな(2wayで済むような)局所性はありませんがね。

way数が多い＝局所性が高いケースに対応するって意味かと。
サーバの場合は同時に走るプロセスも使用メモリも多いから、
あまり細かい局所性にこだわってもメリット少ないって判断じゃ
ないかな。

いや、そうではない。
極端な話、L1が連続する単一のメモリブロックだけ収容すれば済むならば、
キャッシュは1wayで事足りる。
局所性があればway数は少なくてよい、というのはそういう意味。

実際には、サーバであっても、2wayでは(4wayならば不要なはずの)余計なfill/writebackが
発生する。

way数とwayあたりのキャッシュラインサイズって相関性あったっけ？

キャッシュラインのサイズはタグ数と反比例し、タグ数とway数が
キャッシュ管理のための回路の規模を決定する。まあ要するに
way数とキャッシュラインサイズはあんまり関係ない。
というかL1のキャッシュラインサイズを64バイトから変えるのは
いろんな意味で勇気がいると思います。

Bulldozerのアーキテクトが作ってた
PowerPC系の特徴ってどんなのがある？

>>905
チャック・ムーアはPower4の設計主任だったみたいね。
英語版しかなかったけどこれでも読んでくれ。
ttp://en.wikipedia.org/wiki/POWER4

http://www-06.ibm.com/jp/support/redbooks/AIX_pSeries/SG88850900.pdf
POWER4なら、IBM純正の解説があるけど。

Llano-2Pは公式スライドには存在しないような・・・

今年出る6コアって現行AM3のマザーに乗るのかね？
bios更新ごときで行けるのか・・・？

ソケットが変わるという話はまだ出てないね。

AM3には乗りそうだが…"C3 performance Boost"で、
コアクロックは上がるが、電圧は全コア固定ってのはありそう。

Fudzilla情報では乗るらしいが・・・。

でも、一番の関心は「Bulldozerも乗るかどうか」だな。個人的には

AM3r2対応だから乗ることはできるでしょう
問題はBios対応だね
アーキテクチャが違うから今までのような非対応でも動くことはあるということが期待出きない
まあ、Bulldozerはハイエンドだから、機能制限がありそうな既存マザーで動かす人は少なく、
殆どは新規購入しそうだ。

HTの帯域増えたりすんのかな。どれくらいパフォーマンスに影響あるかもしらんけども・・・

インテルのSocketB2 CPUに内蔵されるPCI-Eと同程度には増やしてくるんじゃね。
AM3では当然制限つきになるけど。

>>912
いまのAM3板には無理なんじゃないかなぁ？

AM3に載らないんだったらAM3r2なんて名前にはしない
AM2+みたいなものだろう

なんかスバルの軽みたいな名前だな

どうにかしてるぜっ！！

>>917
7x0系の板には無理で、8x0系の板以上で可能とか？
7x0系の板も"Thuban"の"C3 performance Boost"対応できるならば、
搭載可能とか。そういう流れになると思うが。

2011年の新CPUコア「Bulldozer」「Bobcat」の姿
ttp://ascii.jp/elem/000/000/489/489200/index-2.html

2 Load/CycleはK7から可能になったはずだが

K7では1ユニットっぽいけど違うのかな。
http://journal.mycom.co.jp/photo/column/sopinion/184/images/001l.gif

> これがBulldozerの場合、Load命令とALU命令がペアになっているのは第1段
> のデコードの出力までで、第2段のデコードを経てスケジューラーに入る段
> 階でこのペアが切り離される。
これって電力消費の無駄が大きいってCore MAで否定されたやり方ではないのかな。

整数レジスタファイルはEXUと独立してひとつ
各EXUにはRegisterCopyがある
XMM/YMMレジスタファイルはFPUにひとつ
dayo

CoreMAも命令実行の前で、命令を分解して同時実行できる命令と組みあわせるから、
MacroOPを分解するのも命令実行の手前なら、電力消費の無駄は減らせるんじゃないの？

物理的にいくつのレジスタがあるのかねFPUには
YMMレジスタ確保できる程度にはあるんだろうけど

もとは45nmでのスタートを予定していて、来年前半にも量産予定で、
社の命運を握るフラッグシップなチップの割には、
情報の露出があまりにも少ないような気がします。

あと一年たったらわかる
Bulldozerが幻想だったことに

なーに、この業界では珍しくない('A`)

>>925
来年の前半に量産→市場出荷するなら
この時期にESの”現物”が公表出来るはずだが
(SandyBridgeは既に実機デモまでやってる）
何の音沙汰も無い。

という事はもうどんな進捗状況かは察しがつくというわけだ。

もまいら、もうちょっと明るい未来を夢みようぜ (´･ω･｀)

632 ：底辺投機家：2009/11/13(金) 23:04:16 ID:Ly7aps2U
有識者の方々にお尋ねしたい。

先日発表された内容の
Ａ． Bulldozerがポシャる可能性
Ｂ． Bobcatがポシャる可能性
Ｃ． Fusion/APUがポシャる可能性
を具体的数字で示していただけますか。

633 ：Socket774：2009/11/13(金) 23:07:12 ID:Rjv2vUM8
まず「ポシャル」の定義を教えてくれ

634 ：Socket774：2009/11/13(金) 23:09:17 ID:xs3ZX472
A 12�l
B 24�l
C 38�l

635 ：Socket774：2009/11/13(金) 23:09:45 ID:zCXK77Zf
Q：Bulldozerがポシャる可能性
A：0
Q：Bobcatがポシャる可能性
A：0
Q：Fusion/APUがポシャる可能性
A：0
Q：それぞれが遅れる可能性
A：低くない

636 ：Socket774：2009/11/13(金) 23:11:26 ID:8JZwV8y1
なんか妙な言い回しが板のあちこちでみる
別に困ることでもないだろうに
A,わからん
B,わからん
C,わからん
おれたちトーシローの意見をきいても意味無いと思うが

637 ：Socket774：2009/11/13(金) 23:14:35 ID:Ly7aps2U
>>633
中止、もしくはデザイン変更

638 ：Socket774：2009/11/13(金) 23:20:12 ID:EO/YjpG6
今さら中止も変更もないだろ。
仮にAMDが倒産してもIBMが引き継ぐんじゃね？

640 ：Socket774：2009/11/13(金) 23:27:51 ID:Rjv2vUM8
A. これまで紆余曲折あってアーキテクチャー公開だから、中止・デザイン変更の可能性は低いと思う。
B. ダイ写真の公開してるし、中止・デザイン変更の可能性は低いと思う。
C.中止・デゼイン変更の可能性は 上二つほど低くないと思う。

思ったほど性能が出ないとか、発売が遅れるとか、プロセスの歩留まりが向上しないとかはありがちだが。

641 ：Socket774：2009/11/13(金) 23:43:27 ID:Ly7aps2U
識者の皆様
貴重なご意見ありがとうございました<（＿）>

642 ：Socket774：2009/11/14(土) 00:02:04 ID:0mOzxaqI
識者じゃないが、あそこまで時間とリソースをかけて開発してきたのだから
ブルドーザーが市場投入されないとしたらAMDがその前に潰れた場合だけだろうな。

明るい夢が見られるような情報をAMDが提供していない。

（´；ω；`）

>>925
だからこそ「情報の露出が少ない」のかもな。
"SandyBridge"だって「デモした」ぐらいと、
AVXが搭載されるぐらいで、他に何か出たか？

価格まで出ないと「情報が少ない」

そら価格次第では粘土も大理石になるからな

ただアスキーの記事見ただけじゃK10より性能低下するって印象受けるな
クラスタ化するから効率アップするんじゃないかと期待していたが
32nmにシュリンクするから消費電力は低くなりますよってか？

もうそろそろ次スレだしブルドーザーの情報まとめようぜ

結局Bulldozerの内部構成については未だに大原さんも後藤さんも勝手な想像、
妄想の域を出てなくて、それも全面的に納得いくものではないという。
情報欲しいよ情報。

AMD 製作過程 想像で描いてみた・・・w

http://up3.viploader.net/pc/src/vlpc001773.png

RegorにDenebは混じってないよ

>>938
確かダイが違うんだよね

>>937
1Core Sempronはどういう工程で生まれるの？

>>939
別ダイはPropusもだけどあれは製品にDenebが混じってるね
ちなみにRegorを1コア殺したのがSempronになる

>>940
Regorの半コア殺しでは？
Sargasだったっけ？

そういえばCeleronとかCULVって
Core2の派生っていうか選別落ち？

えーい１６ナノはまだか？

わたし、１６ナノ。

>>925
まぁとりあえず来年出れば儲けもんぐらいに考えてた方が
精神衛生上いいと思うがｗ
AMDの予定なんてアテになったことがない

"FUD"zillaを信じてるヒトが生き残っていたりして、ここ相変わらずオモシロいですね(笑)
CESでGFが28nmの試作ウェハを披露したとのこと。
http://www.semiaccurate.com/2010/01/09/global-foundries-28nm-wafer-spotted/
　　------------------
　　The new wafers were quite irregular in appearance, so they could be CPU or
　　GPU chips, or they could be some very advanced test structures.
　　------------------
製品に近い回路が作れる状態らしいとのこと。

作れる状態らしいの
「らしい」に思いっきり期待してGF先生の次回作を気長に待ちましょう
なぁみんな

BulldozerのまとめってURLを適当に貼り付けでいいのか

いいんじゃないか？GFの情報もあると尚よし。

1月中にBulldozerのサンプル配布始めるって話だよね

後藤辺りが書いた記事を1つ載せるだけで済む程度の情報しかないよな今は

仮に致命的な遅延や計画停止した場合は、Magny-Coursをシュリンクして対応するのかな。
あるいはLlanoの拡張版とか。(4コア480SPを2つくっつけて8コア960sp4chメモリ)

ブルドーザに関しては、秘密主義が徹底しているのかもしれないな
インテルに即座に対応されるのを避けるために

クロックが伸びるかが心配です

AMDはGFの32nm SOI HKMGを使用する
Intelは32nm HKMGを使用する
単純には比較出来ないだろうけどSOIの分AMDが有利な気がする。

そもそも45nm SOI→32nm SOI HKMGで大幅にプロセスが進化するから、
単純なシュリンクだけでも大幅な性能改善(省電力、高クロック)が出来るだろう。

それにTSMCの劣悪な40nmプロセスですら、
高性能のHD5xxxを予定通りに製造できたAMDの設計やプロセスへの最適化技術を考えると、
否が応にも期待してしまう。

最近のK10、K8を見てると
SOIが必ずしも有効だとは思えないんだが

コストを高める意味で有効

SOIじゃ無かったら性能ガタ落ちだったかもしれんし、よくわからんね。
GPU統合に余計なコストがかかるのだけは間違いないが。

L3 6Mか480SPのGPUの内蔵で、どちらがコスト対効果が高いかだね

>>955
SOIは有効だっただろ？　High-k…というかIntelの方がリークを削減していたが。

「PD-SOIでは必要電圧が増えるから消費電力でも性能面でもバルクと差はない。コストが無駄に高いだけ」
とIntelは以前から言ってたけどな
バルクでPD-SOI以上の高速省電力石を作り続けてるintelはそれを実証してるわけで