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

このエントリーをはてなブックマークに追加
1Socket774
____
\._  | 荒らし・煽り・厨房は放置が一番。
/|_| | 釣られずにスルーしましょう。
|_/\! sage進行でマターリいきましょう。

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

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

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

CPUアーキテクチャについて語れ 16
http://pc11.2ch.net/test/read.cgi/jisaku/1253517890/
2Socket774:2010/05/05(水) 00:07:47 ID:rNgpoI9C
■過去スレ一覧
34 ttp://pc11.2ch.net/test/read.cgi/jisaku/1267796312/
33 ttp://pc11.2ch.net/test/read.cgi/jisaku/1265866982/
32 ttp://pc11.2ch.net/test/read.cgi/jisaku/1263352294/
31 ttp://pc11.2ch.net/test/read.cgi/jisaku/1258895864/
30 ttp://pc11.2ch.net/test/read.cgi/jisaku/1252750795/
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/
3Socket774:2010/05/05(水) 00:17:21 ID:O20gV4dy
だんご三兄弟また来るのかな?
4Socket774:2010/05/05(水) 00:25:13 ID:9QfspK2Q
次スレ

AMDの次世代CPUについて語ろう 第36世代
http://pc11.2ch.net/test/read.cgi/jisaku/1272985698/
5Socket774:2010/05/05(水) 00:34:32 ID:TYNKoQkv
>>1乙です

そして、重複申し訳ございません。
6Socket774:2010/05/05(水) 01:33:15 ID:9aArPiEG
ttp://techreport.com/discussions.x/18851
ATi Stream SDK 2.1

いよいよLlanoが近づいてきたなという感じがする
7Socket774:2010/05/05(水) 02:36:17 ID:S5/FH/7b
AMDじゃなくてATi Streamなんだな。
8Socket774:2010/05/05(水) 07:20:39 ID:JwzgsS0r
でも今のNVってシェアとってるっつーよりお笑いをとってるかんじ
団子は無理にGPGPUをほめなくていいのに
9Socket774:2010/05/05(水) 07:34:00 ID:/d5RUX8H
消去法でCUDAしかのこらない
10,,・´∀`・,,)っ-○○○:2010/05/05(水) 08:04:19 ID:E/cWbyEH
褒めてねえ
GPGPUなんてのは過渡期の技術であって最終的に残るのは並列化プログラミング言語・フレームワークだ。

IntelもAMDも過程は違えど最終的に目指してるのはグラフィック処理にも汎用コンピューティングにも使える
ワイドなベクタエンジンをCPUに完全統合することだぜ。

しかし今はハード面もソフト面も期が熟してない。
まして利益率の高い上位CPU/チップセットがディスクリートGPUに依存しており、PCIe 3.0への
対応も進めている現状で、IGPが市場シェアの大半を握ってしまうシナリオはIntelすら望んでないだろ。

x86に関してIntelが主導権を持っている以上、LarrabeeのSIMD命令が最終的に各社共通の
プログラミングインターフェイスになる可能性は高いとは思ってるから、
持たざる者であるNVIDIAの悪足掻き自体はわりと無意味かなと。
11Socket774:2010/05/05(水) 08:17:24 ID:JwzgsS0r
>>6
団子の言ったそばから・・・
実は団子はATi Streamの開発者なんじゃ
12,,・´∀`・,,)っ-○○○:2010/05/05(水) 08:18:32 ID:E/cWbyEH
wwww
13,,・´∀`・,,)っ-○○○:2010/05/05(水) 08:30:50 ID:E/cWbyEH
AVX関連のソフト技術は当分ちょっとした飯の種なんで
正直うちのお客さんにはGPGPU云々は言い出さないで欲しいかな
現段階では。
14,,・´∀`・,,)っ-○○○:2010/05/05(水) 08:42:04 ID:E/cWbyEH
あ、別にそんな理由でディスってるわけじゃない
15Socket774:2010/05/05(水) 09:07:37 ID:LixKsWgE
そういうのは精神科の医者とだけやり取りしててくれ
16Socket774:2010/05/05(水) 09:14:30 ID:beLmiP1P
結局は私情か

壁か空気を相手にしてくれ
17Socket774:2010/05/05(水) 09:38:07 ID:LixKsWgE
医者が何とか治療しないと
それまでずっとPC関係のコミュや大阪周辺の小さい男の子が被害を受ける
とくにショタには大問題ってかカンペキ犯罪だし
18Socket774:2010/05/05(水) 09:48:19 ID:z+5KLq/t
>>10
> 褒めてねえ
> GPGPUなんてのは過渡期の技術であって最終的に残るのは並列化プログラミング言語・フレームワークだ。
GPGPUはGPUというハードウェアで並列処理も行おうっていう合言葉みたいなもんだろ
言語やフレームワークと同じ次元で話しても意味が無いと思うが

> IntelもAMDも過程は違えど最終的に目指してるのはグラフィック処理にも汎用コンピューティングにも使える
> ワイドなベクタエンジンをCPUに完全統合することだぜ。
その過程で各社が選んだのが、
IntelはCPUのコア毎に付属するSIMDエンジンの拡張→SSEやAVX、
Nvidiaは外部ユニットとしての大型GPUの拡張→Tesla
AMDはCPUコアとは独立したGPUコアの拡張とオンダイ化だろ→FireStreamやFusion
それぞれ一長一短あるから一概にどれが優秀とは言えない

> しかし今はハード面もソフト面も期が熟してない。
> まして利益率の高い上位CPU/チップセットがディスクリートGPUに依存しており、PCIe 3.0への
> 対応も進めている現状で、IGPが市場シェアの大半を握ってしまうシナリオはIntelすら望んでないだろ。
IGPという概念が出来て以降ずっとIGPがシェアの大半を握っているだろ、ディスクリートなんか全体の数割程度でしか無い

> x86に関してIntelが主導権を持っている以上、LarrabeeのSIMD命令が最終的に各社共通の
> プログラミングインターフェイスになる可能性は高いとは思ってるから、
> 持たざる者であるNVIDIAの悪足掻き自体はわりと無意味かなと。
X86は殆ど関係ないと思うが
独自言語CUDAとTeslaはHPC市場で人気だろ?
Nvidiaも優れたハードを開発し続ければ存続できるよ
19,,・´∀`・,,)っ-○○○:2010/05/05(水) 09:59:46 ID:E/cWbyEH
> X86は殆ど関係ないと思うが

将来の統合プロセッサでx86のSIMD命令を直接実行することをマニフェストとして掲げたのはAMDだぜ。

それでSwiftでSSE5そのものを実行できると勘違いした奴が沸いたのが一昨年くらいの話。
20Socket774:2010/05/05(水) 10:09:45 ID:LixKsWgE
ショタホモ家の花壇ではコードネームSwiftはSSE5が実行出来ないことになってたの?
何で?
21Socket774:2010/05/05(水) 10:19:07 ID:LixKsWgE
「SSE5そのものを」って書いてあるもんだから
ソース見ずにうまく皮肉ったつもりだったけど
ググったらSSE5自体がSwift含むK10をスルーでBullから搭載じゃねーか
22,,・´∀`・,,)っ-○○○:2010/05/05(水) 10:20:24 ID:E/cWbyEH
と、また池沼の人が自爆しました
23Socket774:2010/05/05(水) 10:27:34 ID:z+5KLq/t
>>19
1年前の話なんか誰も覚えてねーよ
技術革新や市場動向、開発の進捗で方針転換なんて日常茶飯事の業界でマニフェストに意味なんかない
それ言ったらIntelだってよくやるだろ、1年前ってLarrabeeで大嘘こいてた時期じゃね?
お前もさんざん調子のいいこと言ってたよな、そのLarrabeeは今どうなってる、何処にも売ってないだろ?
24Socket774:2010/05/05(水) 10:27:41 ID:JwzgsS0r
google先生でもぜんぜん出てこねぇぞおい
25Socket774:2010/05/05(水) 10:32:19 ID:LixKsWgE
ていうか

AMD
x86コアを小さい頭とし
非x86コアを操るのが最終目標

Intel
x86デコーダてんこ盛りにした水ぶくれコア数種類で
ヘテロを形成するのが最終目標

NVIDIA
今のところx86無関係

てことで> X86は殆ど関係ないと思うが は別に間違って無いんじゃね?
26,,・´∀`・,,)っ-○○○:2010/05/05(水) 10:36:03 ID:E/cWbyEH
>>24
先生に嫌われてるんじゃないの?

http://journal.mycom.co.jp/articles/2007/09/15/barcelona/004.html

SSEはよりワイドなベクトルに対応できるように命令セットを拡張する必要があるし
GPUはよりデータレベル並列度を下げなければならない。
そういった段階を踏んで可能になると言う話で、RadeonとK10を同じダイに載せてすぐに
SSE命令をGPUで発行出来るという話ではない。
27Socket774:2010/05/05(水) 10:40:33 ID:JwzgsS0r
ちがう、SwiftでSSE5を実行云々の書き込み
28Socket774:2010/05/05(水) 10:43:59 ID:LixKsWgE
RadeonとK10を同じダイに載せてすぐにコプロとして操れるようにしたとしても
非x86なGPUは一生SSEなど発行しないのが現実世界
29Socket774:2010/05/05(水) 10:48:58 ID:LixKsWgE
つーかあれだな
>21-22のリロード連打では
相手の「ミスった」発言のみに反応してるだけで
内容全く理解してないんだな

>27
明確な記事は無いけど
その件の発言はそれなりにあった
30Socket774:2010/05/05(水) 10:51:35 ID:IWfp1DKb
GPUにX86やSSE使わせるぐらいならCPUのSIMDを強化するだろうからな
31,,・´∀`・,,)っ-○○○:2010/05/05(水) 10:54:15 ID:E/cWbyEH
> それ言ったらIntelだってよくやるだろ、1年前ってLarrabeeで大嘘こいてた時期じゃね?
> お前もさんざん調子のいいこと言ってたよな、そのLarrabeeは今どうなってる、何処にも売ってないだろ?

何熱くなってるのよ?

Larrabeeは最初から統合プロセッサが前提でディスクリートは競合の牽制のためだってのは最初から明らかだったよ。
牽制する必要自体が無くなってしまったら出す理由がないだろう。

言ってるだろハードは本質じゃなくて問題はソフトだと。
去年の今頃AMDがAVXサポートを表明したことで、Larrabeeの命令セットも含め、将来にわたって
Intelとの命令セット互換を維持する可能性が高くなった。
x86からGPUにアクセスできる命令セットが必要なのはAMDも同じでIntelに歩調あわせたほうがいいからな。

戦わずに勝つのが最良の兵法だぜ?
個人的興味からすれば残念ではあるけどな。
32Socket774:2010/05/05(水) 10:57:54 ID:JwzgsS0r
まーたやばくなったときの団子饒舌ショーが始まったよ
33Socket774:2010/05/05(水) 10:58:46 ID:z+5KLq/t
AMDの場合GPUコアとCPUコアが独立しているからx86に拘る必要もないんだよな
ぶっちゃけARMやPower、Sparcコアと同居させることもできる
AMDがARMやPowerのライセンスを受けるか、他社がGPUコアのライセンスを受けるかすればだけど
多分AMDのFusion構想のかなり先の展開がそれ、X86でのFusionはその足がかりだと思う
その一例がSnapdragon。
まあコアは売却したからライセンスじゃないけど、あんな風にGPUコアのライセンスを事業として立ち上げれば面白そうだ。
ハードとしての成功例はあるわけだし、他にも使いたいところが出てくるんじゃないかな。

逆にIntelはx86と一蓮托生、なんせCPUコアと密接に融合しているから他のコアへの転用はほぼ不可能
34Socket774:2010/05/05(水) 11:08:11 ID:x7V1olJQ
饒舌ってかただの躁病にしか見えないんだが
35Socket774:2010/05/05(水) 11:09:36 ID:z+5KLq/t
>>31
> Larrabeeは最初から統合プロセッサが前提でディスクリートは競合の牽制のためだってのは最初から明らかだったよ。
> 牽制する必要自体が無くなってしまったら出す理由がないだろう。
ものは言いようだなw
ソフト環境がグダグダだったって話だが、DX10ですらまともに動かなかったらしいぞ

> 言ってるだろハードは本質じゃなくて問題はソフトだと。
> 去年の今頃AMDがAVXサポートを表明したことで、Larrabeeの命令セットも含め、将来にわたって
> Intelとの命令セット互換を維持する可能性が高くなった。
> x86からGPUにアクセスできる命令セットが必要なのはAMDも同じでIntelに歩調あわせたほうがいいからな。
まあ、シェア的に似たような拡張競争しても負けは濃厚だからね互換路線は仕方ないさ
ただ、Bullでの実装を見ると、互換路線は性能それなりレベルで片手間って感じだな

> 戦わずに勝つのが最良の兵法だぜ?
> 個人的興味からすれば残念ではあるけどな。
AMDがIntel互換(SSE/AVX)とGPGPUどちらに重きをおいてるかは火を見るより明らかだろ?
要はまだ戦ってもいないということだ。
来年のLlano vs Sandyがその初戦とも言えるし、それまで妄想で楽しめばいいんだよ。
36Socket774:2010/05/05(水) 11:12:37 ID:qbU2GhGw
団子非表示にしてるのにご丁寧に片っ端から引用している馬鹿がいるな。
37,,・´∀`・,,)っ-○○○:2010/05/05(水) 11:17:33 ID:E/cWbyEH
>>30
曰く、CPUのSIMDを強化しても一部の科学技術計算やゲームにしか使えない罠。
でもGPUと演算リソースを共有してやれば、グラフィックを使う多くのプログラムで演算リソースを
有効に使える機会が増える。Fusionの発想はそっから来てる。

フロントエンドをx86側とGPU側で別々にしてバックエンド(演算ユニット)のみ共有というモデルをとってもいい。
無理にLarrabeeのようにGPU自体を「SIMDがおばけなx86」で構成する必要はないだろう。

しかし演算ユニットはx86の内部オペレーションを効率よく実行出来るように作り替える必要がある。
どのみち似たようなところにいきつくだろ。
38,,・´∀`・,,)っ-○○○:2010/05/05(水) 11:29:06 ID:E/cWbyEH
> 来年のLlano vs Sandyがその初戦とも言えるし、それまで妄想で楽しめばいいんだよ。

何度も口を酸っぱくして言ってることだが相手がアーキの改良くわえてるのに、
4コアでWestmere 2コアにすら勝てないアーキをそのまま使ってる時点でLlanoは最初から負けてるだろ。
GPUなんてディスクリートGPUでなんとでもなる。CPU性能の不足は拡張カードで補えない。
クソでも売り込むようなマーケティングセンスがあるなら別だが特に売り込める要素なし。


そもそもなんでローエンド〜ミッドレンジのSandy BridgeのダイにGMA(笑)に毛が生えたGPUコア載るかわかってるの?
コンシューマ用途でAVXを有効に使えるプログラムが出るまでは、Vertex Shader代替として使うのが
一番リソースの無駄がないからだよ。
単純計算でVSの性能がArrandaleの2〜4倍になるわけだからそれなりに使えるのでは?
俺個人はあまり気に入らんが。

Llanoと勝負するためじゃない。勝手に仮想敵にするな。
39Socket774:2010/05/05(水) 11:40:31 ID:JwzgsS0r
Llanoと登場時期がかぶるから、どうしても比較されると思うぞ
CPUは優秀、GPUは出来損ない vs CPUは値段なり、GPUが優秀 みたいにな
40Socket774:2010/05/05(水) 11:42:16 ID:Qz6kJLr5
>>36
団子も一部のヤツから見たら真新しいオモチャみたいだし。
壊れたテープと同一だって事を…おっと。コレもコテ名だな。
41Socket774:2010/05/05(水) 11:43:38 ID:iIxGmmst
比較されるだろうけど、Llanoの方がGPU性能が高くても数が出るかというと疑問が。
42,,・´∀`・,,)っ-○○○:2010/05/05(水) 11:53:52 ID:E/cWbyEH
Westmere→Sandy Bridgeの改良点

1.AVXに対応する256ビットSIMDエンジン搭載
2.Loadユニットの倍増
3.Macro OPs Fusionの対象命令拡大
4.ROB/RSのエントリ増加
5.Loop Stream Detectorで再利用できるμOPs数の拡大


>>39
G45と780G程度には比較されるかもね、全くAMDに追い風になってないけどwww

ところで、たとえばDDR3 1066MHzの2GB 1枚刺しでも十分な帯域確保できるの?
NECや富士通の廉価モデルでメモリ2枚刺しって殆ど無いよ?
43Socket774:2010/05/05(水) 12:06:53 ID:JwzgsS0r
G45と780G程度以上に開きがあるぞ
そこでIntelはGMAを1個増量してGMA双発で負けてないアピールをする
完璧なシナリオだろ
44,,・´∀`・,,)っ-○○○:2010/05/05(水) 12:07:07 ID:E/cWbyEH
嘘をいってしまった。申し訳ない。

NECの2010夏モデル
http://121ware.com/psp/PA121/LEARN/ENTP/h/?tab=LRN_Z_TOP
LaVie
 L : Core i5/i3
 S : Core i5/i3
 M : Core 2 Duo / Celeron
 Light : Atom
VALUESTAR
 N : Core i5/i3, Celeron (モバイル版CPU)
 W : Core i5/i3
 L : Core i7 8xx

AMD全く入ってない。



富士通は言わずもがな。
45,,・´∀`・,,)っ-○○○:2010/05/05(水) 12:12:14 ID:E/cWbyEH
>>43
だからアホだな。勝つ必要ねーじゃん。
メモリの価格の差額でディスクリート刺せるしww



NEC/富士通がIntelオンリーになったことで日本の家電屋は完全にAMDを見放した構図になったわけだけどどう思った?
46Socket774:2010/05/05(水) 12:15:24 ID:JwzgsS0r
>ディスクリート刺せるしww
だめだ、コストアップだぞそれ
47Socket774:2010/05/05(水) 12:20:42 ID:IWfp1DKb
Llanoの主戦場はノートかスリム筐体のデスクトップあたりだよね
48,,・´∀`・,,)っ-○○○:2010/05/05(水) 12:23:54 ID:E/cWbyEH
1600MHzモジュールを2枚刺しなんてしたらコストアップ、ケチったら
圧倒的な・・・・帯域不足
タイルレンダベースでメモリ帯域を余り食わないGPUを開発しておくべきだったね(泣



あ、仕様確認したけどLaVieはいずれもIntel HDG/GMAだった
49Socket774:2010/05/05(水) 12:27:29 ID:bXh4A9Sv
>>46
ララビの残骸つかって、今だとsellが圧倒的に使われてるPC間を繋ぐボードとか
ララビには夢があったよ。登場時期が10年ほど早い気はする。
50Socket774:2010/05/05(水) 12:50:34 ID:NOKjeCUH
夢があったというか夢しかなかったという話もある
51Socket774:2010/05/05(水) 12:55:37 ID:pkYK10Yy
Llanoなんて今の魅力が無いノート向けラインナップに選択肢ができるだけでもありがたい
デスクトップ向けでもコスト的に有利だからある程度売れるだろうし
52,,・´∀`・,,)っ-○○○:2010/05/05(水) 12:55:58 ID:E/cWbyEH
AMDの社員さん、NEC/Fujitsuのロゴ消す作業忘れてるよ

http://www.amd.com/jp-ja/Processors/ComputingSolutions/0,,30_288_3091_3100,00.html
http://www.amd.com/jp-ja/Processors/ComputingSolutions/0,,30_288_3091_3098,00.html

この会社には夢すらないな。
53,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 12:59:29 ID:E/cWbyEH
今日くらいはこれでも付けておくか
54Socket774:2010/05/05(水) 13:02:00 ID:yX22aBwX
55,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 13:07:35 ID:E/cWbyEH
>>51
AcerやDOSPARAのノートPCが選択肢に上がる人自体、日本の消費者には少ないと思う。
AMDに関心がない人はわざわざ買わないだろ。

CPUが刷新されないAMDに魅力がないからNECも富士通も見限ったんだと思うよ。
56Socket774:2010/05/05(水) 13:14:15 ID:JwzgsS0r
むしろ刷新されてないコアが世界的ヒットという
57Socket774:2010/05/05(水) 13:19:54 ID:JwzgsS0r
2010年になってもCeleronやPentiumDCがまだまだ主力
Core2がでてから4年くらい経ってる
58Socket774:2010/05/05(水) 13:36:30 ID:pkYK10Yy
NECや富士通は知らない間にAMD搭載パソコンを出さない宣言をしていたのか・・・
59,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 13:50:05 ID:E/cWbyEH
数年前、某家電量販店のノートPC売り場の実演販売

Intelだと大体こう
「CPUはIntelのデュアルコア!Core 2 Duoを搭載しております!」

これがAMD機だと
「一流メーカーNECのノートパソコンです!三流メーカーじゃ決してありません!一流メーカーのNECです!」


これ脚色抜きの実話。認知度の違いというものだな。



つか、既に地雷要素だらけじゃないか

http://pc.watch.impress.co.jp/docs/column/kaigai/20100215_348705.html
>  また、Intelはパワーゲーティングのために、CPUコアのステイトを保持する特別なSRAMをCPUに実装、
> パワーオフからの復帰を高速化した。しかし、AMDの実装では、CPUコアのステイトは、CPU外部の
> DRAMに待避される。そのため、原理的にIntelのパワーゲーティングより、オンオフのレイテンシが長い。
> 実際の機器では、パワーオフからの復帰に時間がかかることになり、どの程度実用性があるのかは、
> まだわからない。

体感速度(笑)がた落ちだな。
60Socket774:2010/05/05(水) 13:51:38 ID:Qz6kJLr5
>>58
妄想に付き合うのもどうかとw
61Socket774:2010/05/05(水) 14:01:30 ID:IWfp1DKb
NECも富士通も年間生産量2〜300万台だから、AMDを採用してラインを増やしてもコストが上がるだけだ
よほどのことが無い限り採用しないだろう
62Socket774:2010/05/05(水) 14:03:49 ID:DDSvzsQe
1. GMAで十分だと思ってるひと→Intel+内蔵GPU
2. GMAが屑だと思ってるひと→Intel+ディスクリートGPU
3. GMAは屑だがディスクリートのコストアップは嫌、CPUの性能はそこそこでいい → Llano

1が大部分のユーザでそれに2が続き、3は一番ニッチ。
マーケティングでひっくり返せる可能性は0ではないけれど、
AMDの歴史にマーケティングで成功した過去はない。
63,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 14:11:00 ID:E/cWbyEH
【質問】
来年ってなんかPCゲーでキラータイトルあったっけ?
Intelのインテグレートで性能不足するような。

ファミ通で「サンシャイン牧場」の記事が組まれるような時代ですからね。
いまどきのカジュアルゲーマー層が求めるのは「mixiアプリがストレス無く動くPC」だと思うぞ。
FlashゲーのパフォーマンスはほとんどCPUのシングルスレッド性能依存。
一方GPUはGMAでも十分。
CPU性能が下がっても満足出来るユーザーは居ないはず。

国を跨ぐと違うかもしれんが。
64Socket774:2010/05/05(水) 14:16:50 ID:IWfp1DKb
ゲームの事は知らんがmixiってモバイル向けゲーム?
65Socket774:2010/05/05(水) 14:18:24 ID:JwzgsS0r
MMORPGならLlanoで十分
66Socket774:2010/05/05(水) 14:22:39 ID:iIxGmmst
IntelのGMAのシェアが性能の割に高いのって、
単にGPUの性能なんてどうでもよい事務端末用に
Intelセットが大量に採用されているからじゃないの?
67Socket774:2010/05/05(水) 14:29:13 ID:IWfp1DKb
>>66
そうだよ

PC利用者のうち単体GPUを使う人は1/3程度
68Socket774:2010/05/05(水) 14:33:17 ID:svgl1KbX
メーカーPCだとほとんどGMAじゃないか。自作やっている人間からすればゴミだけど
69,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 14:38:18 ID:E/cWbyEH
もちろんPCの需要の7割はGPU性能の需要のほとんどない法人向けだよ。
だがしかし、ホームユースも高いGPU性能がいらない時代になりつつある。
http://it.nikkei.co.jp/digital/column/gamescramble.aspx?n=MMITew000027112009&cp=1

少なくとも日本には既に家電屋がゲーマー向けPCを作って売れるような土壌はなくなったな。
70Socket774:2010/05/05(水) 14:40:08 ID:Qz6kJLr5
>>62も「GMAで十分だと思っている」からGMAではなくて、

1.買ったPCがGMAだっただけ。

が正解だろうな。中身を知っていれば「2」か「3」にしかならない。
71Socket774:2010/05/05(水) 14:43:30 ID:NOKjeCUH
GMA指名買いする奴は流石にいないだろうからなあ
72Socket774:2010/05/05(水) 14:44:16 ID:DDSvzsQe
>>70
まあそれでもいいんだが、いずれにせよ「GMAが糞だからAMDのCPUを買おう」とはならない。
普通にRadeonなりGeForceなり搭載したPCを買う方を選ぶ。
3に呼び込むには強力なマーケティングが必要なのよ。
73,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 14:44:32 ID:E/cWbyEH
AMD指名買いする猛者キボン
74Socket774:2010/05/05(水) 14:50:07 ID:ozYmtez/
だんごwww
wwwファミ通読者www
75Socket774:2010/05/05(水) 14:50:21 ID:JwzgsS0r
>>62は自作er視点だな
76Socket774:2010/05/05(水) 14:50:34 ID:Qz6kJLr5
>>72
「それでいい」のではなくて、「それでしかない」わけだが。

あと、

>「GMAが糞だからAMDのCPUを買おう」とはならない。
>普通にRadeonなりGeForceなり搭載したPCを買う方を選ぶ。

コレも嘘。一般人は与えられた物を買うだけで、
GPUなんて気にしない。オレ達"自作オタ"や、
特定メーカー信者の妄想とは思考回路が違う。
「価格」と「宣伝文句」が美味しそうであればそれを買うだけ。
中身なんて気にしない。例え屑性能だったとしても、
そこに「購買意欲に見合った宣伝文句」があれば買うだけ。

ただ、AMDがメーカーサイドへのマーケティングが弱いのは同意。
だけど今後はチップセットも自社(GF)生産になれば、
セット販売での様々な割引やら特典は付けやすくなるので、
OEM向けのマーケティング的にもやりやすくなってくるんじゃない?
GPU+チップセットで生産予測や納品予測が立てやすくなるし。
77Socket774:2010/05/05(水) 14:58:12 ID:DDSvzsQe
> 一般人は与えられた物を買うだけで、GPUなんて気にしない。
この層は1だよね。Llanoには行かない。Intelブランドはでかい。
78Socket774:2010/05/05(水) 15:00:53 ID:IWfp1DKb
日本の場合もともとPCのオンラインゲームより携帯ゲームの方が市場規模が大きい
※前世紀の市場規模については知らん

日本じゃ大手メーカーが3Dゲーム向けPCを出す余地は最初から無かった
79,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 15:05:08 ID:E/cWbyEH
>>74
その号だけちょっとした話題になってたから読んだんだよね。
ぶっちゃけ、血しぶきつゆだく上等の洋ゲーが家電屋のPCの売上げ牽引した時代って日本に存在しないんじゃないの?



Sandy BridgeのIGPでちょっとたよりなくてLlanoで満足出来るネトゲってMHFあたり?
あれ既に終わってる気がするが。
80Socket774:2010/05/05(水) 15:07:12 ID:JwzgsS0r
ブランド戦略がいかに大事かを今NVIDIAがあらわしてるもんな・・・
81Socket774:2010/05/05(水) 15:17:33 ID:Qz6kJLr5
>>77
「Intelであるか」さえも見ていないことが多いぞ。
PCの製造メーカーは気にする場合も多いけど。
82Socket774:2010/05/05(水) 15:27:02 ID:z+5KLq/t
>>42
1以外は多分たいしたことないよ、ベストパターンでもクロックあたりせいぜい数%の向上だろう

それと、廉価向けの2コアやOntarioの存在忘れているよ?
ハイエンド向けが4コア、廉価版や省電力向けは2コアやOntario
ちなみに2コア版には20W以下のラインナップもあるらしい

ラインナップはこんなもんだろう
ネットブック:10W以下のOntario
10万円以下のCULV対応:2コアLlano
10万円以上やゲームノート:4コアLlano

全部Win7の最新DX11対応
ラインナップとしてすっきりしていてスキが欠片も無い完璧な構成だな
しかも外部バス的には全部DDR3+PCie+ディスプレイ出力で統一されて、
違いは速度とPin数くらいの開発のしやすさ

所詮NvidiaのIonやGeforceに頼らざるをえないIntelのi3/i5やSandyなんか正直相手にもならんだろうな
83Socket774:2010/05/05(水) 15:32:14 ID:z+5KLq/t
しかし団子のIntel圧力マーケティングマンセーが激しいな

>>61
数は少ないけどNECだってAMD採用しているよ、安売り用だけど
ラインナップが少ないのは知名度やサポートの質、リベートなんかの差だろうね
逆に言うと、そのへんが改善すればラインナップは増えるということだ
84,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 15:37:07 ID:E/cWbyEH
「VAIOのパソコンください」にAMDを認知させるのは難しい


> 数は少ないけどNECだってAMD採用しているよ、安売り用だけど

そのなけなしの採用数すら今期新モデルは「ゼロ」なんですが。
85Socket774:2010/05/05(水) 15:38:51 ID:qbU2GhGw
日本で、GMAでは満足に動かない(単品ビデオカート要求するレベル)
のPCゲームが流行らないのは、携帯よりはゲーム専用機の存在が大きいだろ。
加えて、ことゲームに関する限り、海外のセンスは日本と乖離してるから
洋ゲー輸入したって一部マニア以外は触ろうともしないし。
86Socket774:2010/05/05(水) 15:40:44 ID:28sYAU0R
相変わらず妄想が激しいな
87Socket774:2010/05/05(水) 15:44:31 ID:z+5KLq/t
シェア論議とか笑える
売る側がIntel:8、AMD:2の割合で売ってるから、購入者のシェアも8:2ってなだけ
中身なんかほとんどの奴は気にしない、せいぜい値段とモニタのサイズくらいだ

企業向けなんか殆どチップの安売り合戦だな
機能や性能なんか関係ない、いかに安く仕入れられるかってだけ
当然赤字で製造量が少ないAMDが大量に利益なしで納入出来る訳もない
省電力やバッテリー時間はそれなりにあればいい程度でメインの理由でも無い
88Socket774:2010/05/05(水) 15:44:46 ID:Qz6kJLr5
>>86
団子の妄想が激しいのは毎度のこと。
89Socket774:2010/05/05(水) 15:48:51 ID:z+5KLq/t
>>77
> この層は1だよね。Llanoには行かない。Intelブランドはでかい。
確かにAMDより遥かにでかい
でもそれを遥かに超えるほどNECや富士通、ソニーのブランドの方が重要

優先度
1.メーカーのブランド
2.値段
3.ディスプレイのサイズ
4.付属ソフトや機能

Intelかどうかはせいぜい5番目くらい、割合からすると数%でしかないだろう
90,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 15:53:43 ID:E/cWbyEH
海外もそろそろ潮時だけどね。有名ゲームスタジオいくつも倒産してるから。
開発費は高騰するのにパイは少なくなるんじゃやれんよ。
日本で流行ってるmixiアプリ自体、そもそも北米のFacebookの2番煎じだったりする。

DX11対応がどうのこうのいってる時点で既に少数派の思考ルーチン。
iAppのほうがよっぽど将来性がある。1年と経たない間にPSPのシェアをかっさらった。
91Socket774:2010/05/05(水) 15:55:07 ID:IWfp1DKb
生産量の劇的な増加が無ければどうにもならんね

例えるとオール電化住宅みたいなもの
湯を沸かすのも調理をするのもガスの方が安いのだが、電気とガスの2系統が有ると基本料金も2系統分発生する
それなら電気一本に絞って基本料金を一本に絞った方が、トータルでは安く済む
92Socket774:2010/05/05(水) 15:55:44 ID:JwzgsS0r
世界的な不況も考慮するとね、開発費の安いゲームにながれるのは自然だろうね
93Socket774:2010/05/05(水) 15:59:36 ID:JwzgsS0r
ちゅうかmixiアプリ自体はAVXもDX11も必要ないな、むちゃくちゃやね団子
94,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:00:21 ID:E/cWbyEH
> でもそれを遥かに超えるほどNECや富士通、ソニーのブランドの方が重要

結局>>59なわけだなwww
ちなみにその店員、「AMD Sempron」の名前は一切出さなかったwww
95Socket774:2010/05/05(水) 16:00:39 ID:IWfp1DKb
PCゲームの市場規模自体は日本でも海外でも増え続けてるけどね
この間のの不況時はさすがにペースは鈍ったがそれでも成長した

ゲームの質的な変化については知らん
96Socket774:2010/05/05(水) 16:03:39 ID:e+HKBFpz
MW2とかGMAで出来るの?
97,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:03:47 ID:E/cWbyEH
>>93
必要ないね。シングルスレッド性能重視だからね。
キャラがわらわら沸くようなアプリは軽く死ぬ。
どっちかというとTurbo Boostでクロックがどれだけ上がるかが重要かもね
もちろんどっかのBu(略のようにIPC下げるなんてのは自滅行為。
98,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:05:11 ID:E/cWbyEH
>>95
SNSと連携した基本無料のブラウザゲーの台頭が要因。
99Socket774:2010/05/05(水) 16:05:23 ID:bXh4A9Sv
>>84
俺、そのAMD入りVAIO足元においてるんだけどなにか?
正直、普通にPC買う奴はCPUがどっちでもwindows動けばいいんだよ
100Socket774:2010/05/05(水) 16:07:02 ID:JwzgsS0r
mixiのアプリなんてめちゃくちゃ軽いだろ
Atomでもできるっつーの
101,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:13:41 ID:E/cWbyEH
>>100
軽いのしかやってないだろ。

うちのやってるのはホームを表示しただけで片コアのCPU使用率が100%にはりつく。
一応30万人くらい登録してるアプリ。
102Socket774:2010/05/05(水) 16:19:06 ID:FjWBv4Mp
>>99
馬鹿には一般人がCPUがどこのかなんて関係ないのが理解できないんだよw
103,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:19:14 ID:E/cWbyEH
サンシャイン牧場の畜産広場も動物増えるとある程度ヤバイね。少なくともAtomじゃやれん。
104Socket774:2010/05/05(水) 16:19:24 ID:JwzgsS0r
どんなゲームだよ100%にはりつくブラウザゲーってのは
そもそも快適に遊べるのかよ
105,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:21:20 ID:E/cWbyEH
>>102
AMDはやたらと嫌う人がいるよ企業ユーザーは


てかAMD採用してた時代のVAIOって・・・骨董品だな
106Socket774:2010/05/05(水) 16:21:22 ID:1wLVbhBR
>>101
さすがにそれはないわ
IE6とか使ってるんじゃねえの?
107Socket774:2010/05/05(水) 16:22:34 ID:ozYmtez/
オブジェクト増えるとatomじゃきついね
ってかうんこフラッシュじゃないの?w
108Socket774:2010/05/05(水) 16:22:43 ID:IWfp1DKb
FlashのGPU支援ってどうなってんのかな

ブラウザゲームとかはやらないから判らん
109Socket774:2010/05/05(水) 16:25:55 ID:ozYmtez/
フラッシュのGPU支援って
動画だけじゃないの
110,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:27:07 ID:E/cWbyEH
>>106
俺の場合ホームに動くオブジェクト大量配置してるかもねwww
もはやCPU負荷テストwww

>>107
描画対象のオブジェクト減らせばそんなに重くはならんよ

>>108
あれはh.264の再生支援だから既存のActionScriptをどうこうできるものじゃない。
111Socket774:2010/05/05(水) 16:35:25 ID:28sYAU0R
112Socket774:2010/05/05(水) 16:39:41 ID:bXh4A9Sv
>>105
テヘが何歳かは知らないが、俺がPCいじり始めた頃なんてPC98以外は駄作だと思ってたし
中身はintel+ATIでAMDなんてただの互換CPUだと思ってたからな。

知識がそのあたりでとまってる人がまだいらっしゃるんだろう
113,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:41:07 ID:E/cWbyEH
インタプリタ部分のCPU負荷の方が大きいからGPU性能では差が出ない

せめて別窓で表示してるFlashくらいスレッドを分けて欲しいんだが。
114,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 16:46:37 ID:E/cWbyEH
「AMDはやめてください」って言った担当者は20代後半だぞ
まあその上司がその年寄りなんだろうけどな
115Socket774:2010/05/05(水) 16:53:28 ID:LixKsWgE
>>110
妄想羅列の準備に講座見ることすらしないショタカブリ
116Socket774:2010/05/05(水) 16:55:36 ID:IWfp1DKb
日本はIntel好き多そうだな

日本は世界で最も多くItanium買ってるだろう
117Socket774:2010/05/05(水) 17:21:03 ID:/d5RUX8H
>AMDなんてただの互換CPUだと思ってたからな。

ちがうのか
118Socket774:2010/05/05(水) 17:40:32 ID:DDSvzsQe
シェアで劣り、ブランドで劣り、性能すら劣る互換品の末期は無惨なものだ。
119Socket774:2010/05/05(水) 17:46:23 ID:Qz6kJLr5
>>117
「何に対して互換か」による。AMDが
「Intelの互換CPU」を製造していたのは昔だけ。

>>118
色々な人のツッコミに何一つ言えなくて、
結局それが最後の一言か。格好いいな。
120Socket774:2010/05/05(水) 17:47:49 ID:JwzgsS0r
AMD採用を増やすには国内の企業が中国に買収されないとな無理ぽ
121Socket774:2010/05/05(水) 17:49:32 ID:NOKjeCUH
Windows互換CPUというのがしっくり来る
122Socket774:2010/05/05(水) 17:49:55 ID:/d5RUX8H
x86の時点でIntel互換だろうに
123Socket774:2010/05/05(水) 17:52:56 ID:gTmTBy2C
>>122
「x86互換CPU」と「Intel互換CPU」とでは、
話が全然違うんだが…理解しているか?
124Socket774:2010/05/05(水) 17:54:02 ID:NOKjeCUH
>>122
それだとIntelもAMD64互換だからAMD互換CPUと言えてしまう
125Socket774:2010/05/05(水) 17:54:11 ID:/d5RUX8H
どうちがう?
126Socket774:2010/05/05(水) 17:54:48 ID:ozYmtez/
どうせ内部RISC86だし
127Socket774:2010/05/05(水) 17:56:11 ID:svgl1KbX
64bitはAMD互換だけどな
128Socket774:2010/05/05(水) 17:57:45 ID:/d5RUX8H
あ、SSSE3,SSE4未対応だから非互換か
129Socket774:2010/05/05(水) 17:58:37 ID:gTmTBy2C
>>128
お前の頭が残念だって事は理解できた。
儲思考も大概にしておいた方がいい。
130Socket774:2010/05/05(水) 17:59:12 ID:/d5RUX8H
だから、どう違うんだ
131Socket774:2010/05/05(水) 17:59:28 ID:gTmTBy2C
それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。
132Socket774:2010/05/05(水) 17:59:58 ID:/d5RUX8H
それが?
133Socket774:2010/05/05(水) 18:00:37 ID:gTmTBy2C
>>130
その程度を理解してからこのスレに来てください。
荒し目的だったら相手にした私を笑って、
釣り宣言をしたあとに消えてください。
134Socket774:2010/05/05(水) 18:02:09 ID:/d5RUX8H
Intel互換じゃないってんなら
x86使うなよ
135,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 18:04:38 ID:E/cWbyEH
>>131
Atom・・・
136Socket774:2010/05/05(水) 18:04:56 ID:gTmTBy2C
>>134
マジで「Intel互換」と「x86互換」を同一視…って、
いまだにそんな残念知識人がいまだに自作板にいたんだ…。
コレはヤバイ。マジでヤバイ。面白すぎてヤバイ。
137Socket774:2010/05/05(水) 18:05:39 ID:IWfp1DKb
楽しい楽しいカオスが訪れるのはこれからだぞ

AMDの生産能力はメインストリーム以上に限ってもこの2年で3倍になる
これとは別にBobcatもある

GFはAMD以外の製品も製造しなきゃいけないからその能力の全てをCPUに割くことは出来ないが
キャパシティー的には2012年にちょうどIntelに匹敵する事になる
※Bobcatがバルクでの場合の話
つまりとんでもない供給過剰状態

これは楽しみ
138Socket774:2010/05/05(水) 18:05:52 ID:/d5RUX8H
じゃIntelパクリでいいよ
139Socket774:2010/05/05(水) 18:10:31 ID:ozYmtez/
>>137
bobcatってGFじゃないだ?
140Socket774:2010/05/05(水) 18:11:25 ID:DDSvzsQe
>>119
どれも突っ込みというよりはお花畑の妄想だろう。AMDスレだから書くのは一向に
構わないがそれに対するコメントは特にない。
141Socket774:2010/05/05(水) 18:14:12 ID:IWfp1DKb
>>139
どこでどんなプロセスで作られるのか知らない

GFでメインストリームCPUと同じ工場で作るようなら
BullやLlanoととウェハの取り合いになるから生産量はIntelには及ばない
142Socket774:2010/05/05(水) 18:14:33 ID:/d5RUX8H
>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。

で?
143Socket774:2010/05/05(水) 18:20:32 ID:gTmTBy2C
>>138
AMDは「x86互換CPU製造メーカー」。これは揺るがない。
Intelに「x86命令セット」を使用するのに金払っているし、
ちなみにIntel優位ながら「クロスライセンス」を結んでもいる。
だからAMDが開発した"x86-64"なんて命令セットが、
Intelにも採用されたりする。ちなみに無料…だったはず。

だけど貴方の妄想を否定するようで悪いけど、
残念ながら「Intel CPU互換製造メーカー」ではない。
それはIntelやAMDのCPUはx86命令セットを処理することはできるが、
そのCPU同士は内部的にもバス的にも互換性は全く存在しないから。

もし、「Intelのパクリ」だったり「Intel互換CPU」だったりした場合には、
IntelがAMDを訴えたら勝てる。
というか。AMDが「独占禁止法に抵触する!」って裁判を起こしたときにでも、
AMDに対して「知的ライセンスの侵害」で訴えれば、話は終わった。

こんな感じ。「Intel互換」と「x86互換」を混同するのは恥ずかしい。
144Socket774:2010/05/05(水) 18:24:33 ID:/d5RUX8H
ま、きみらはパッケージなんて持ってないだろうから

ttp://www.agenda.co.jp/news/2009/08/atn2010-20090825.html
Pentium?以上[Pentium?III以上を推奨]
※最低でも、使用するOSの以下の最低クロックが必要です。
[WindowsVista] 1000MHz 以上の32ビットIntel互換CPU
[WindowsXP] 300MHz 以上のIntel互換CPU
[Windows2000] 133MHz 以上のIntel互換CPU

ttp://www.justsystems.com/jp/news/2010f/news/j01201.html
Pentium(R) 1GHz以上のIntel互換CPU
(Windows XPの場合は733MHz以上)

製品CD起動時は1GHz以上を推奨します。

ttp://www.tsuzuki.co.jp/jigyo/sup_ser/ppointer.html
Intel互換CPU 2.0GHz 相当以上
Intel互換CPU 1.0GHz 相当以上
145Socket774:2010/05/05(水) 18:25:34 ID:FjWBv4Mp
>>143
アホは相手にするなよ

「Intel互換」と「x86互換」を同一視

今時こんな事言ってるのが涙を誘うよなw
146Socket774:2010/05/05(水) 18:27:40 ID:JwzgsS0r
この流れ、VIA抜きには語れないな!
147Socket774:2010/05/05(水) 18:32:46 ID:/d5RUX8H
君らが勘違いしてるのはSocket7以前のバスレベルの互換や
セカンドソース時代のことじゃないの


>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。

で?
148Socket774:2010/05/05(水) 18:35:31 ID:gTmTBy2C
ついでにいえば、IntelとAMDの契約の中に、
「AMDは自社工場でx86互換CPUを作っていいよ」ってのがあったらしく、
それが去年だか一昨年だかに一時話題になった、
「GFは自社工場じゃないだろ! x86ライセンスを停止してやる!」
ってIntel側の訴えに繋がったわけですが…。

そのお話の結末は同時期に争われていた「独占禁止法裁判」の結末。
「IntelはAMDに和解金を支払い」のおまけのようにも見えたけど、
超重要事項。「x86ライセンスの継続」っていうおまけまでついて勝訴。

ていうか。「和解金が少ない」って話は確かにあったけど、
「x86ライセンス継続」がついたんだから、少ないどころの話じゃねーっすw

>>144
間違えた書き方をされたパッケージではなくて、
Windowsパッケージのシステム要件でも眺めてろw
149Socket774:2010/05/05(水) 18:36:35 ID:ozYmtez/
アイタニウムどうなってしまうん?
150Socket774:2010/05/05(水) 18:39:07 ID:JwzgsS0r
Itaniumは夢とともにNehalem-EXに引き継がれたよ
151Socket774:2010/05/05(水) 18:45:52 ID:/d5RUX8H
intel互換cpu

>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。

で?
152Socket774:2010/05/05(水) 18:48:10 ID:/d5RUX8H
※2 Intel互換CPUは動作対象ですが、AMD社の一部の旧型CPUについてはSilverlight動作対象外となります。
153Socket774:2010/05/05(水) 18:54:40 ID:LixKsWgE
Intel社と互換性のあるCPUならほらこの通り
証拠書類改竄や連続敗訴を皆様お気軽に実行出来ます!

でもお高いんでしょう?

それが何と(ry
154Socket774:2010/05/05(水) 19:47:36 ID:DDSvzsQe
>>148
この問題は、時系列順に考えれば別の見方が出来るかと。

もともとインテルとAMDの間には独禁法違反の係争があった。
Intelにしてみれば最悪ケースでは企業分割もありうる不安定要因だ。

AMDの業績悪化が深刻化したとき、AMDはアラブ資本の出資を受け入れ、
赤字で投資がままならなかった製造部門に梃入れすることにした。
収支を合わせるためにファウンドリ事業への参入も決めた。
別にAMDは分社化する必要はなかったにも関わらず(たとえばサムスンは会社の
一部門としてファウンドリ事業も行っている)、製造部門をGFとして分社化した。

ここで、AMDにもx86の製造ライセンスが失効するという不安定要因が生じた。

そしてIntelとAMDは、(いくらかの現金とともに)お互いの不安定要因をバーターする
ことに合意した。AMDはx86の製造を行う権利を引き続き保持するのと引き換えに、
Intelを独禁法違反で攻撃する権利を失った。

ライセンス問題の解決を受けて、AMDは製造部門の分社化をさらに押し進め、
決算からGFを分離し、黒字転換を果たした。
AMDの赤字を引き継ぐ形になったGFは非公開企業だから、決算の数字は(赤字だろうという以外)
外部からはわからない。

和解によるx86製造ライセンスの取得は勝利ではなく、
GF分社化以外で黒字転換できない状況に陥った大失策を、
独禁法違反という(弱者の強力な)武器と引き換えにイーブンに戻したに過ぎない、
というのが自分の見方。
155Socket774:2010/05/05(水) 19:57:49 ID:IWfp1DKb
>>154
独占禁止法といっても不正競争防止法と反トラスト法は内容が全然違う
Intelが訴えられたのは反トラスト法じゃなくて不正競争防止法

企業分割は関係ないんじゃないか
156Socket774:2010/05/05(水) 19:58:47 ID:JwzgsS0r
そして和解後、AMDは黒字となったのであった。
157Socket774:2010/05/05(水) 20:05:46 ID:IWfp1DKb
もうちょっと補足しとくと

独占禁止法は大まかに分けて
@違法な行為により競争相手に不利益を与える不正な競争を防止するもの
A過度な独占を防止するためのもの
の2種類

Intelが訴えられたのは@の方の不正行為による正当な競争の妨害であって
市場の独占を訴えられた物ではない
158Socket774:2010/05/05(水) 20:11:31 ID:/d5RUX8H
和解金で黒字とか
159Socket774:2010/05/05(水) 20:19:57 ID:pkYK10Yy
やっと気付いた
160Socket774:2010/05/05(水) 20:25:27 ID:vBnr257z
和解金玉に見えた。
161Socket774:2010/05/05(水) 20:30:40 ID:/d5RUX8H
飛ばしで黒字とか
162Socket774:2010/05/05(水) 20:49:52 ID:JwzgsS0r
そしてNVIDIAは赤字幅を順調に拡大したのであった。
163Socket774:2010/05/05(水) 20:58:55 ID:JwzgsS0r
別に赤字でも良いんだよ(拡大しちゃうのはまずいが)
お金がちゃんと血液のようにさらっさらに流れていればかまわんのよ

ただ、さらさらに流れない事態に陥ることだってあるんだよ、たとえ黒字でもね
そういうときは本格的にやばい、黒字倒産っていうしゃれにならん事態が起きちゃう
164Socket774:2010/05/05(水) 21:29:25 ID:FjWBv4Mp
黒字倒産は悲惨だよな
まあ、キャッシュを持っていればいいんだけどなかなか難しいよな
165Socket774:2010/05/05(水) 21:41:25 ID:/d5RUX8H
海兵隊が抑止力と思っていなかった
166Socket774:2010/05/05(水) 21:57:46 ID:vZy3rzOY
>>165
ルーピー馬鹿山乙w
167Socket774:2010/05/05(水) 22:02:16 ID:zLBqvsRn
口蹄疫がこんなに恐ろしい伝染病だとは思ってなかった
防疫や災害対策の予算が必要になるとは思ってなかった
168Socket774:2010/05/05(水) 22:08:38 ID:nz5IGJsG
陰厨が何も言えなくなって、またも見当違いの方向に走りだしたな。
169Socket774:2010/05/05(水) 22:16:14 ID:zLBqvsRn
【宮崎】 豚でまた口蹄疫疑い 殺処分対象、3万頭に迫る★5
http://tsushima.2ch.net/test/read.cgi/newsplus/1273033812/
170Socket774:2010/05/05(水) 23:04:35 ID:V2dka2sT
たしかx86_64ではIntelがAMD互換に成り下がったのでは?
171,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 23:17:37 ID:E/cWbyEH
そう思った奴が、「IntelがSSE5を採用しないのはAMDに対するいやがらせだ!」と見当違いのことを言っていた
172Socket774:2010/05/05(水) 23:27:53 ID:krQQ1dqf
ところでテヘと団子は同一人物?  以前トリップ同じだったけど…。
173Socket774:2010/05/05(水) 23:28:14 ID:QeIT88cN
まぁAMDのスレで毎回intelの話持ち出して来る奴もここのスレタイ的にどうかとは思うがな
174,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 23:31:01 ID:E/cWbyEH
>>172
あいつが勝手に真似した
#CR-Z
175Socket774:2010/05/05(水) 23:41:55 ID:BbBhqZXD
>>174
なるほど…。

テヘって捏造ベンチだけではなく他人の名を語って自演するまでに落ちぶれたのか…w
176Socket774:2010/05/05(水) 23:45:07 ID:z+5KLq/t
淫厨がまたファビョってるのか?
次世代スレでIntelの訴訟地獄の負け戦なんかの話してもつまらんだろ
どっちが何の互換とかもうどうでもいいだろ?
AMDもIntelも今後ずっとX86CPUを開発・販売していくことには変わらないんだからな
トムとジェーリーみたいに仲良く喧嘩してればいいんだよ

まあ、悪徳巨大結社Intel相手に長年赤字続きで苦戦していてもうだめかという土壇場で、
ATI買収、アブダビの支援、工場分離、和解とX86継続、大幅な黒字化という奇跡の復活を遂げたAMDは素直にすごいと思うよ
しかも来年は新プロセスを使った新CPUと新GPUで大反撃も行うし
大ピンチから奇跡の復活、そして大反撃とか何処の少年漫画だよw
このストーリーを小説にしたら確実にご都合主義の烙印押されて2chじゃ非難の嵐だろうね
普通はこのまま大逆転してハッピーエンドだけど、まあ無理だろうな
177,,・´∀`・,,)っ/<()◎巛巛< :2010/05/05(水) 23:55:26 ID:E/cWbyEH
ARMなんかみてみれば解るが互換メーカーの拡張を本家が逆採用することは別に珍しいことじゃない
そもそもx64自体IA-32命令セットの上位互換でAMDオリジナルの部分なんてほぼ皆無

GFの分離の際のいざこざでも、IntelのライセンスがなければAMDは「AMD64」を作ることも
ままならないという支配関係は改めて確認できたろ?
178Socket774:2010/05/06(木) 00:01:34 ID:PGQUHzf4
GW終了
179,,・´∀`・,,)っ/<()◎巛巛< :2010/05/06(木) 00:08:58 ID:usoqWTp7
木金も有給申請しとけよ
180Socket774:2010/05/06(木) 02:51:31 ID:9cmnU1KB
反撃するのに一番重要な、ハイパフォーマンスCPUというピースを欠いているのだが。
181Socket774:2010/05/06(木) 03:27:34 ID:xcZoJdOi
ライセンスというか、プログラムコード・CPU構造(MMUの操作などね。 内部構造は含まない)に対する
著作権の問題だろ。
182Socket774:2010/05/06(木) 06:56:31 ID:rhcG7rSc
>>180
> 反撃するのに一番重要な、ハイパフォーマンスCPUというピースを欠いているのだが。
Bulldozer 8コア/16コアがハイパフォーマンスじゃないのか、IntelはSandy16コアでも用意しているのか?
183Socket774:2010/05/06(木) 07:16:17 ID:jO5sKhyn
>Bulldozer 8コア/16コア
それはローパフォーマンス多コア

sandy 8coreで十分
184Socket774:2010/05/06(木) 07:36:53 ID:B0l5lPLP
12/16はサーバー
6/8はコンシューマ
185Socket774:2010/05/06(木) 07:46:12 ID:TFrRJ87S
整数・小数点
スカラ・ベクタ
区別出来る知能はもとより
何度笑われても知識すら付かないショタカブリ(生活保護の55歳(くらいだっけ?))
186Socket774:2010/05/06(木) 08:42:26 ID:MpTmikb7
sandyがだめとなったからにはBULLに期待するしかない。
187Socket774:2010/05/06(木) 08:57:20 ID:FrYVeFcn
>>182
AMD流の数え方では実行ユニットの前工程が
コア数の1/2だからな。

鯖やHPC用途みたいな
常時ピーク付近でブン回す分野だと
どうやっても100%負ける。
188Socket774:2010/05/06(木) 09:43:45 ID:575aFS45
これからはパワーより
消費電力だからな

今の10倍高速であるより
今の1/10電気食わないように出来るか

そして携帯に取ってかわれるかが
生き残りのカギだな
189Socket774:2010/05/06(木) 16:45:15 ID:LCnRwfjd
なんかトリのセンスまで雑音に似てるw
190Socket774:2010/05/06(木) 17:46:18 ID:jO5sKhyn
>そして携帯に取ってかわれるかが
>生き残りのカギだな

こういうのかね?

ttp://pc.watch.impress.co.jp/docs/news/20100506_365603.html
>Intel、スマートフォン向けSoC「Atom Z6xx」
191Socket774:2010/05/06(木) 21:16:15 ID:v/SuVfWH
>>187
果たしてそう期待通りに負けてくれるか…そこが問題だな。
192Socket774:2010/05/06(木) 21:20:48 ID:u+C7SfI9
テヘ権田は相変わらず精神分裂しっぱなしwww
193Socket774:2010/05/06(木) 21:22:45 ID:rhcG7rSc
x86は携帯向けに進出はできないよ
ARMの省電力にAtomじゃ何をどう頑張っても追いつけないからね
194Socket774:2010/05/06(木) 21:29:09 ID:rynlTPn8
ARMって6502シンカなんだよな?
195Socket774:2010/05/07(金) 00:06:16 ID:e7Ego3iW
196Socket774:2010/05/07(金) 01:16:45 ID:uIHruRZF
>>187
普通のアプリと違って、そういう特殊用途だと
ソフトを書き直す手間も許されるからなぁ。
一般向けならブルの割り切り方で正解なんだよ。
197Socket774:2010/05/07(金) 01:34:43 ID:m6Bu+v4l
ソフト側から見たらモジュールやコア数なんかどうでもよくて、スレッド数が幾つなのかが重要。
OSから見ればi7は8スレッド、Gulftownは12スレッドで認識されスケジューリングされるからね。

殆どの場合、IntelのHTTのようにスレッド間で性能差が大きいものよりも、
Bulldozerのようにスレッド間の性能に差がないほうが扱い易い。
198Socket774:2010/05/07(金) 01:58:53 ID:Q1/Cm66b
>>196-197
清清しいな
199Socket774:2010/05/07(金) 02:31:36 ID:ryUHGWyB
BULL最強という事ですね。
200,,・´∀`・,,)っ-○○○:2010/05/07(金) 02:38:41 ID:ls/Tt+fy
サーバは兎も角、クライアント・ホームユーザー向けで4スレッド以上使うソフトなんてそうそうねーけどな。
OSのサービスに割り当てるCPU時間なんて限られてるんだから
同時発行スレッド数はクライアントのコンテクストが頻繁に切り替わらない程度にあれば十分
201Socket774:2010/05/07(金) 02:44:39 ID:+cW/01Gv
団子を逆に読めば権田だとか洒落てるつもりなのかなこの馬鹿
202Socket774:2010/05/07(金) 02:49:53 ID:+cW/01Gv
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/264
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/272
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/281
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/310
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/379
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/387

AMDの次世代CPUについて語ろう 第34世代
http://pc11.2ch.net/test/read.cgi/jisaku/1267796312/
 864 名前:,,・´∀`・,,)っ-○○○@ ◆OhjIkO1O8o [sage] 投稿日:2010/04/02(金) 04:26:06 ID:VnW/HhAl
  脱糞って言われるの気にしてたんだな
  コンプレックス刺激しちゃったんだな


テヘ雑音団子やっちまったな
203Socket774:2010/05/07(金) 02:51:02 ID:+cW/01Gv
146 名前:Socket774[sage] 投稿日:2007/09/23(日) 02:16:45 ID:uqQtZWII
雑音あいかわらずいい味出してんなー。

148 名前:●テヘ権田●[sage] 投稿日:2007/09/23(日) 02:41:12 ID:/aojbA/5
>>146
> 雑音あいかわらずいい味出してんなー。
まぁな、バカは直ぐに低俗へと逃げて騒ぐから相手にしたくねぇんだけどまぁ偶には良いだろw


【自爆霊】雑音犬畜生Part44【統失】
http://mamono.2ch.net/test/read.cgi/tubo/1270998379/

テヘ権田こと雑音のプログラム知識に脱帽
http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html
204Socket774:2010/05/07(金) 02:52:42 ID:Q1/Cm66b
単にCMTに振るだけじゃなくて、
たとえばプロセッサレベルでCilkのspawn/syncを高速に実行できるような命令を積んだら面白いと思うが、
そういう革新性が無いのがつまらないですなあ。
205,,・´∀`・,,)っ-○○○:2010/05/07(金) 03:56:29 ID:ls/Tt+fy
ついでに言えばもし常に均一にスレッドが沸いてくる理想状態ならPower-Gate & Turbo-Boostなんて死に機能だろ。
ヘビーなスレッドの数が少ない時に、如何に高速に処理できるかが重要だろ。

一部のコアのクロックを引き上げるのは有効だが、それ+αが必要だな。

・2基のスカラ整数演算ユニット(Sandy Bridgeは3基)
・2基のFP/SIMDユニット(Sandy Bridgeは3基)
・容量16KB, 帯域32B/clkのL1データキャッシュ(Sandy Bridgeは32KB, 48B/clk)

少スレッド時のスループットで優位を保つには圧倒的にクロックが上がらないと厳しいと思うけどな。
4スレッド以下の場合に有利な要素がない。
i7はおいといても、K10よりシングルスレッド性能高いかどうかも疑問。


5年だか10年だか先のトレンドを先読みするのはご立派だが今を犠牲にして全てを失ったら世話ない。
206Socket774:2010/05/07(金) 04:00:08 ID:+cW/01Gv
さすが2chに張り付きニート暦7年で自称年収8500万
スーパー生活保護受給プログラマーのいうことは違うな
207Socket774:2010/05/07(金) 04:05:30 ID:NPIkiQIe
ついでに言えば焼き串使えなくなったから3人同時主演は難しいのだろ
権田さん出てらっしゃーい!
208Socket774:2010/05/07(金) 04:21:50 ID:a5BiYGbu
クライアントで重要なのはシングルパフォーマンス
ベンチでも回さない限り
209Socket774:2010/05/07(金) 04:33:17 ID:Uoz09j3x
なんかそのシングルタスクのパフォーマンスもそれほど重要じゃない気が最近してきた
210Socket774:2010/05/07(金) 04:51:41 ID:MzZG+Tkm
 重要じゃないというか、飽和してるよね。
211,,・´∀`・,,)っ-○○○:2010/05/07(金) 05:42:24 ID:ls/Tt+fy
ストレージがあまりに遅いからだろ。

というか、コンシューマ向けとしてはソフト自体がネタ切れ気味だな。
キーボードがあってマウスがあって箱があって画面があって・・・の範疇でできることを
やり尽くした感はある。ゲームも含め。
212Socket774:2010/05/07(金) 05:45:25 ID:uIYAJENY
知能指数-200のショタカブリ消えろ
213Socket774:2010/05/07(金) 06:25:43 ID:twyqZ/F0
>>197
まともに働けもしないような水増しスレッドで高性能とか、
市場操作やらかす様な邪な企業野製品らしいよな。
214Socket774:2010/05/07(金) 06:34:26 ID:a5BiYGbu
Atom 128coreでも積めばいいのに
215Socket774:2010/05/07(金) 06:39:10 ID:Uoz09j3x
なんでそこまで極端に話し振るかなあ
まともに話すことも出来ないじゃないか
216Socket774:2010/05/07(金) 06:54:15 ID:MzZG+Tkm
 Bullの方向性が妥当であるという結論に達したくないからでしょ。
217Socket774:2010/05/07(金) 07:01:52 ID:8DqPmxTp
>>214
でも2コアくらいしか使われないとかw
218Socket774:2010/05/07(金) 07:03:37 ID:uIYAJENY
>>214が極端・・・?
>215は新参か?
ショタカブリ(雑音というかこのスレの粘着コテ群)なんか
極端ならまだしも常に滅茶苦茶だぞ
219,,・´∀`・,,)っ-○○○:2010/05/07(金) 07:07:08 ID:ls/Tt+fy
まあ、しっかし、相変わらず読む価値のないレスばっかりだな。

まあ2スレッドで4命令同時実行には変わりないんだし
今の所Bulldozerの水増し8コアはSandy Bridgeの4コア(擬似8コア)と良くてどっこいの性能だぜ。
それでなくとも6コア12スレッドには勝てんだろう。

AMDの示したスペック予想だと、Interagos 16コアですら理論性能値はINT/FP共にMagny-Coursの1.3倍程度。
市場投入を見るまでもなく既に終了しとる。



別にコンシューマ用途でもいいが、ゲーム(笑)なんかCPUコア数の需要自体が飽和してるぞw
たとえばCrysisで一体何スレッド動いてるんだ?
まあPCのゲーム市場は開発者も顧客も低コストなブラウザゲームに流れて
D3DやOpenGL使ったリッチな3Dゲームの市場縮小なのは既定路線だしのう。
DX11だGPGPUだマルチコアだと騒ぎ立てたところでソフト屋がろくに見向きもしないんじゃどうしようもない。

相変わらず動画エンコード当たりが頼みなんじゃね?
こっち方面はネットブックやスマートフォンが流行っても外で持ち出して再生するとかの需要は増えそうだし。
220Socket774:2010/05/07(金) 07:20:12 ID:a5BiYGbu
DX11にしても、ほとんど見た目が変わらんのだし
コストに対する効果が対数関数的だわね
ハード的にもソフト的にも
221Socket774:2010/05/07(金) 07:26:08 ID:twyqZ/F0
水増ししてるのは、腐れの Intel だよ。

AMDのは正味。
222Socket774:2010/05/07(金) 07:32:41 ID:uIYAJENY
ちょっと表現を間違えたかな
>214は極端というより的外れないつもの馬鹿
ショタカブリ(ID:ls/Tt+fy)は滅茶苦茶というより
・どれだけ笑われても性能算出に演算器数で掛け算するのをやめない
・どれだけ笑われても今のGPUにSIMDユニットとx86デコーダが付いてると信じて疑わない
・どれだけ笑われても「たまにPentium4にはL1Dが無い」
・どれだけ笑われても隆盛(たかもり)くん目当てでこのスレに粘着
というようにホモ全開と妄想全開とバグ全開コピペを意外に器用に織り交ぜる
ネットを通しても臭ってくるほど気持ち悪いイカ臭いゴキブリだ
223,,・´∀`・,,)っ-○○○:2010/05/07(金) 07:57:05 ID:ls/Tt+fy
1コアあたり3命令とか4命令とか同時発行できるコアが本当に8ないし16あるなら兎も角
2つの整数クラスタで最大4命令のデコーダ共有を共有してるのを2コアと言ってるだけだろ。
コア数の水増しと言われても仕方ない。

あとは、2つのスレッドで共有してる4命令/clkの並列演算リソースを、
負荷に応じて3:1とか4:0とかにも動的に割り当てられる(Sandy Bridge)か
あるいはクラスタ毎の演算リソース数で頭打ち(BullDOZEr)か、どっちがマシかと言う話だな
224,,・´∀`・,,)っ-○○○:2010/05/07(金) 07:57:46 ID:ls/Tt+fy
○2つの整数クラスタで最大4命令のデコーダを共有してるのを2コアと言ってるだけだろ。
225Socket774:2010/05/07(金) 08:19:09 ID:+cW/01Gv
まぁ雑音よ、そのコテは別人キャラの設定なのか?
226Socket774:2010/05/07(金) 08:24:56 ID:GQAkhWPY
>>223
Sandy Bridgeの演算リソースはポート6つで、最大6命令/clkだろう。ALUは3つだ
C++で書かれた鯖用プログラムだと、演算リソースじゃなくてL1D$のレイテンシ・帯域に制限されそうな気がする
だから「コア」ごとにL1D$を持つBulldozerは整数系ベンチで意外と善戦するかもしれん
227Socket774:2010/05/07(金) 08:26:57 ID:48MGxmxC
>>220
>DX11にしても、ほとんど見た目が変わらんのだし
確かにそれはあるw
ゲームやってる時にその違いに気付くのは無理だな

投入コストに見合わないと判断されたらどんな規格も廃れる
228Socket774:2010/05/07(金) 08:34:39 ID:4cSWreFt
DX11は開発者目線で策定されたくさいしね(作りやすさ重視という意味で)。表現の向上はテッセレーションくらいかな
229,,・´∀`・,,)っ-○○○:2010/05/07(金) 08:50:52 ID:ls/Tt+fy
>>226
正確に言うと内部帯域は1クロック当たり4 Fused-μOPsね
FusionできないμOPsの組み合わせもあるので必ずしも6ポートに同時発行出来るわけではない。

ロード・ストアの「帯域」って言っちゃうとSSE前提になってしまうが発行回数のほうが重要では?
ちなみに某が言うに、一般的なコードで平均するとロードオペレーションの発行頻度は
コードシーケンス全体の1/5、ストアは更にその1/4程度。
Loadユニット1本でも賄えてたんだし、2本になったことでLoad操作がある程度集中しても対応できるようになるのでは?

1つのスケジューラで2つのスレッドのスケジュールをやるのはそれなりに有効だよ。
2つの命令ストリーム間の依存関係は常に存在しないし、レイテンシのかかる命令を互いに
インターリーブすることで充填率を高めることができる。

Bulldozerはクラスタが分かれてる分、それぞれのIntegerスケジューラはそれぞれで別々に、
同一命令ストリーム間で処理を並列化出来る部分を抽出し、並べ替えなければならない。
本当に脅威になるのは更にSMT(1モジュールで4スレッド同時実行)をやり出した時だと思う。
230Socket774:2010/05/07(金) 08:54:49 ID:uIYAJENY
DirectXが隆盛したら悶死する奴と「DX11の未来について」を語っても意味ない
それよりも隆盛(たかもり)くん大好きな気持ち悪いショタカブリの極限的な知能の低さによる公害のほうが遥かに問題
231,,・´∀`・,,)っ-○○○:2010/05/07(金) 09:31:23 ID:ls/Tt+fy
>>228
携帯ゲームでモーションセンサやマルチタッチパネル、裸眼3D液晶(DS次世代機)が使えるのに比べると
何が変わったのか、消費者視点で解りづらいわな。

世界的に見てもPCゲームの市場で成長してるのはMac・Firefoxでも動いて低コストなブラウザゲーや
低スペックでも動くMMOくらいで、ディスクリートが必要なクラスは世界的にも衰退してる。
だからこその非ゲーム用途のニーズ開拓(GPGPU)したり、1人に複数枚買わせたりしてるわけで。

GPGPUって丁度DSPでモデム機能も実装してみました、みたいなモンでしょ?
最早見かけることも無くなったサウンドカードと同じ道を着実に歩んでる。
232Socket774:2010/05/07(金) 09:31:53 ID:GQAkhWPY
>>229
たしかに整数演算ワークロードでL1D$のロード・ストア「帯域」はクリティカルでなかったかも

>ロード・ストアの「帯域」って言っちゃうとSSE前提になってしまうが発行回数のほうが重要では?
SSEをガシガシ使うプログラムでは、命令発行帯域よりL2〜L3〜メインメモリ帯域に制限されることが多い
SSE系ベンチではHT無効化Sandy Bridgeと半コア無効化Bulldozerの戦いになると思うが、
この分野ではキャッシュ容量・帯域の技術に秀でるIntelにAMDは勝てないだろうな
233Socket774:2010/05/07(金) 09:44:23 ID:WKDvDDrv
>>231
全世界のPCゲーム市場規模の推移ってどんな感じなん?
234Socket774:2010/05/07(金) 09:47:26 ID:Kdea8r+j
Bulldozerは1コアあたり1個の128bitのSIMDが有るよね
モジュール中の1コアを止める事に意味があるのか
235Socket774:2010/05/07(金) 09:52:20 ID:MNQe4Nt9
PCゲームは衰退してると言うけど売上的にはどうなの?
コンシューマ機の売上割合が増えてるのは確かだろうけどさ
Modern Warfare 2は発売初週の売上はPC版で過去最高だったらしいが(その後は知らん)
236Socket774:2010/05/07(金) 09:56:00 ID:Kdea8r+j
2009年までの段階では、ディスクリートGPU市場が衰退しているってデータは無いだろう

ライトなPCゲームはPCゲームのパイを広げることに役立っているが
ヘビーなゲームの市場を食うものではない
と言うよりも、ライトなPCゲームが奪っている市場というのはTVや据置型の家庭用ゲーム機などであって
PCゲームの市場を広げる事に役に立っている
237Socket774:2010/05/07(金) 10:02:39 ID:4cSWreFt
オンボの性能があがってくるのはPCゲームとしては大歓迎
238Socket774:2010/05/07(金) 10:25:10 ID:kgX+hZJm
Llanoと790GXくらべるとどの程度ゲームのスコア差がでそうなんかな?
239Socket774:2010/05/07(金) 10:45:05 ID:iDXwwqg2
今んところの情報だと、Llanoのほうが断然上の性能
240,,・´∀`・,,)っ-○○○:2010/05/07(金) 10:45:24 ID:ls/Tt+fy
>>233
国別のは知らん。

PCのパッケージゲーム市場はCrytekがコンシューマに逃げる発言したあたりで既に終わりの始まりだった。
んで、今はPCゲーム屋の逃げ口だったコンシューマゲーム市場自体すら深刻な不況。

てか俺がいうより新さんのほうが説得力あるだろ
http://www.itmedia.co.jp/news/articles/1002/17/news087.html
241,,・´∀`・,,)っ-○○○:2010/05/07(金) 10:51:55 ID:ls/Tt+fy
>>236
ヘビーなゲームにライト層もついてきてくれたからソフトメーカーは金がうまく循環してたわけだが?
今現時点で「DX11のゲームさえくれば」と言ってる状況自体が、既に終わってる。
242Socket774:2010/05/07(金) 11:17:16 ID:4cSWreFt
ライトゲームに流れざるを得なくなったのは2007年以降の不況・不況の嵐なんだよな
大手はまだこてっこての3D作っても、有名タイトルでなんとかやっていけるが
その他、大多数の中小メーカーはやりたくてもやれないってかんじで、なんとか生き残ろうと必死
243,,・´∀`・,,)っ-○○○:2010/05/07(金) 11:25:52 ID:ls/Tt+fy
表現できるグラフィックが精細になればなるほどコストは跳ね上がるじゃん。
テクスチャの解像度ももちろんだけど、シェーダプログラマの人件費がばかにならん。
コンシューマ機でいうならPS2時代には平均開発費は5億円程度かかってたものがPS3/Xboxでは30億円程度かかるそうな。
んでもってユーザーが5〜6倍に増えるならまだしもパイ減ってるじゃん。

他に目を向ければカジュアルなゲームプラットフォームのほうが流行ってる。
いくらハイエンドゲームマニアが望んでも、ソフトメーカーがやれんよ。
244Socket774:2010/05/07(金) 11:26:18 ID:+cW/01Gv
まぁ雑音よ、そのコテは別人キャラの設定なのか?
245Socket774:2010/05/07(金) 11:28:07 ID:oAS5RsK/
受け売りで話をする奴って言うことが似るよw

一致率の高さはそれとは別だが
246,,・´∀`・,,)っ-○○○:2010/05/07(金) 12:01:24 ID:ls/Tt+fy
誰と誰が同一か云々じゃなくて内容に突っ込めよ


だんごやさんの真贋は行動によって示される
247Socket774:2010/05/07(金) 12:01:52 ID:4cSWreFt
開発費ってだいたこれくらいでしょ
 PS3:3.9億円
 360:1.9億円
 Wii:1.3億円
248Socket774:2010/05/07(金) 12:14:48 ID:oAS5RsK/
真贋に価値が無いから安心しておくれとしか
249,,・´∀`・,,)っ-○○○:2010/05/07(金) 12:18:15 ID:ls/Tt+fy
既製ソフトのエンジン使い回しで抑えこめばそんなもんかもね。
問題はイニシャルコスト。

つかそれはそうとDX11使った汎用ゲームエンジンって誰が開発するの?
DX10すらDX9と殆ど差がなかった気がするんだが。
(故意にXP/DX9環境でオプションを制限しただけのソフトならいくつかあったけど)

次期UnrealEngineはTimの発言からすると次のコンシューマゲームが出る頃まで音沙汰無い気がする
250Socket774:2010/05/07(金) 12:32:28 ID:uIYAJENY
気持ち悪いホモゴキブリってのは
誰にも読まれない妄想長文書きまくって誰にも叩かれないとそれだけで増長して暴れまくるから
環境保全の為にもなるべくこのゴキブリ未満な知能の気持ち悪いショタホモを馬鹿にするべきなんだろうけど
やっぱり人生の無駄使いだからな〜
何とかならんもんか・・・
251,,・´∀`・,,)っ-○○○:2010/05/07(金) 12:37:47 ID:ls/Tt+fy
>僕は頭が悪いので何も反論できません

迄読んだ
252Socket774:2010/05/07(金) 12:38:25 ID:Kdea8r+j
今コンピューターゲーム市場でパイが減りそうなのは家庭用ゲーム機だな
携帯ゲーム機はまだ伸びてるが、据置型ゲーム機はここ数年市場規模は横ばいのまま

据え置き型ゲーム機が全盛だった頃は『TVの前』のポジション争奪戦だった
でも今は30歳代以下はTVではなくPCの前ですごす(30代以下と40代以上で傾向が決定的に異なる)
つまり、今は『PCの前』のポジションの争奪戦であり、据置型ゲーム機の将来性はかなり厳しい

※プラットフォームの規模が成長しない市場でゲームを売るには
 消費者に「ゲーム+ゲーム機」を両方買わせる程の魅力のあるゲームを作らなければ
 特に家庭用ゲーム機は1機種で1市場と考えた場合はPCゲーム市場よりはるかに小さい

携帯型ゲーム機も状況的には似てるが、こっちは携帯電話の機能を取り込めれば可能性は無くは無い
253,,・´∀`・,,)っ-○○○:2010/05/07(金) 12:58:37 ID:ls/Tt+fy
パッケージソフトビジネス不毛の市場の中でサーバ集中型のサービスで成功をおさめた
韓国のゲーム会社なんかは逞しいと思うね。

iPhoneのあれは絶対的なハード普及台数がまだまだ少ないからそれほど脅威になってないが
更にアマチュアの参入障壁が更に低いAndroidが本格的に立ち上がれば任天堂も安泰じゃない
254Socket774:2010/05/07(金) 13:01:02 ID:F8ghjMf1
そもそも日本にゃ
そんなスキルの有るアマチュアなんていないだろ

あったら、大手が離さないだろうし
今の時期に独立するバカはいない
255,,・´∀`・,,)っ-○○○:2010/05/07(金) 13:11:16 ID:ls/Tt+fy
日本のアマチュアFlash職人と契約して海外アーティストのプロモーションビデオを作った有名音楽製作会社があってだな・・・。

ゲームも対戦なら高度なAIなんて必要ないからちょっとプログラム囓った学生でも簡単に作れちゃうのが入れ食いの理由
ただマリオやポケモンより流行る作品が出てくるかというと、無理な気がする
256Socket774:2010/05/07(金) 13:35:37 ID:uIYAJENY
>>254
日本のプログラマへの待遇酷いらしいけどな
だから才能も集まらない
IQ50未満が偽プログラマで
それ以上ならなれる?ってイメージ
他の仕事しながら趣味でやってる奴のほうがスキル高そう
257Socket774:2010/05/07(金) 13:51:30 ID:Vqo2czPr
ID:uIYAJENY
これはひどい
258Socket774:2010/05/07(金) 13:55:54 ID:Kwus9dLl
誰にも読まれない妄想長文の例
http://pc11.2ch.net/test/read.cgi/jisaku/1272985619/250
259Socket774:2010/05/07(金) 14:00:26 ID:j7r2atdW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
260Socket774:2010/05/07(金) 15:26:34 ID:fiyvkBct
canvas3dやo3dとかブラウザ上で手軽に3d扱えるAPIが登場し始めてるから
カジュアルなブラウザゲーでも3dが今後の主流になるのは間違いないよ
おそらくHTML5と一緒に普及するはず

とはいってもFF14やFPSみたいなハイエンド志向のものじゃなく
マリオやみんゴルのようなデフォルメされたものだろうけど

しかしインスコ不要でブラウザ上で手軽に遊べるようになれば
ユーザー増やすチャンスと捉えて積極的にコンテンツが投入されるはず

それどころかwebsiteでも無意味に3d使うとこが出てくる
今のflash貼りまくりのサイトのようにねw

Llanoは今のwebの状況から見るとGPUが過剰な性能に見えるかもしれないが
今後を考えるとこのレベルは最低限になるかもしれない
261Socket774:2010/05/07(金) 15:30:04 ID:gWqWSiUy
>>235
とりあえずEAがPCゲー製作部門だけピンポイントでリストラするぐらい
儲かってない。
262Socket774:2010/05/07(金) 18:14:33 ID:0b8hpFl6
すっかり団子が住人として定着してんな
263Socket774:2010/05/07(金) 19:09:50 ID:dad934wm
>>220
「見た目」だけに限っていえばDX10で進歩はほとんど止まってる。
264Socket774:2010/05/07(金) 19:20:49 ID:rdG4xgL0
>>262
そりゃ久々にAMDが性能でIntelに勝っちゃったもんだからネガキャンに必死なんだろうよw
265Socket774:2010/05/07(金) 19:23:40 ID:0ALZRl53
DX10.1以降は下位互換性があるので
11の画像が大して進化していないからといって10にわざわざ留まる必要はほとんどない
GeForceの方は一気に変わってしまったので分からないが
Radeonの5シリーズに関しては大してトランジスタ数も増えてないようだしな
266,,・´∀`・,,)っ-○○○:2010/05/07(金) 19:26:04 ID:ls/Tt+fy
>>264
AtomよりPhenom X6のほうが速いだろうけどそれがどうした?
267265:2010/05/07(金) 19:28:26 ID:0ALZRl53
自分で書いていて言い分が明らかにおかしいのに気がついた
酔っぱらってるんで寝るわ
268Socket774:2010/05/07(金) 19:29:02 ID:a5BiYGbu
269Socket774:2010/05/07(金) 21:27:43 ID:vlfiz3iJ
DirectX10やらへ進まないのはMSの責任だろ。
大人しくXPでも対応させてしまえばよかったんだよ。
270Socket774:2010/05/07(金) 21:36:14 ID:a5BiYGbu
対応させても見栄えは大して変わらんの
271Socket774:2010/05/07(金) 22:25:27 ID:plS/Au/7
MS的にはDirectX10が使われようが使われまいがWindowsが売れればそれでいいからな。
普及が進まない事で対応グラフィックカードが無意味になろうが知ったことではないだろう。
272Socket774:2010/05/07(金) 22:43:05 ID:QBgHWHV+
ところで前のエイプリルフールねたでBulldozerのフェイク画像があったけど
その中の4KBのトレースキャッシュってμops換算だとどれ位の容量?
273Socket774:2010/05/07(金) 23:04:05 ID:m6Bu+v4l
仕方ないな団子やボンクラ淫虫は
今がどうとかじゃなく、5年後10年後あるいは更にその先の世界のゲームが、
DX9ベースの今と何も変わらんしょぼいグラフィックとゲーム性のままだと思っているのかね

プロセッサの性能や解像度、通信帯域なんか増えることはあっても現状維持なんてことはないのにな
10年後なんかはどれもコレも今の倍以上、モノによっては10倍くらいに進化しているだろうに
そういった時代を見越して段階的にハードもソフトも進歩している最中だろ今は

団子が好きなブラウザゲーやIpadとかだって、
将来的にはDX11レベルのAPI使ってGPUによるアクセラレーションも出来る高度なものが出てくるだろう

今後どんな技術革新やブームがあるかも分からないのに、旧世代の規格に縛られたままでいいとか思考停止にもほどがある
274Socket774:2010/05/07(金) 23:07:19 ID:2jjELhtX
>>229
二世代目以降に投機マルチスレッディングをやりそうって話が出ていますね
初代Bulldozerのピーク処理能力はSandyBridgeと張り合うのは難しいですかね?
275Socket774:2010/05/07(金) 23:32:29 ID:m6Bu+v4l
Bulldozerの色んな解説記事読んで思ったんだけど、
今後のAMDのCPU開発の方向性が性能向上より省電力性の向上をかなり意識しているように見える。
パイプラインの3way→2wayへの削減やAVXユニットの2コアでの共有は、
普通に考えたら性能でIntelの次世代以降のCPUに対してあまりにも劣勢すぎるからね。
団子が指摘するように性能比較で勝てる要素は殆どないと言ってもいい。

性能で勝つ気が無いなら、狙いは低コスト(製造・販売)か省電力かになる。
コアをシンプルかつ小型化して、省電力機構もふんだんに盛り込み、
モバイル並の省電力化を果たそうとしているのがBulldozerでありBobcatなんだろう。

例えるなら、
K10=PenD、Nehalem=X2、Bull=Core2の逆再現を目論んでいる気がする。
276Socket774:2010/05/07(金) 23:38:34 ID:Ka7sP+fh
>>269
責任って何だよ 責任って
別に普及させる義務なんて無いぞ
277Socket774:2010/05/07(金) 23:46:35 ID:4cSWreFt
RADEONは小型化してハイエンドはミドル×2で対抗
CPUでもそれと同じことをしようとしてるな
278Socket774:2010/05/07(金) 23:48:50 ID:KDZiWyGt
本当に省電力だといいがねえ
279Socket774:2010/05/07(金) 23:55:20 ID:4cSWreFt
いろいろ夢をつっこんじゃった某GPUのように欲張らなければそれなりにできるんじゃない
280Socket774:2010/05/08(土) 00:10:21 ID:9JSCSfB9
K10コア2個でSandyコア1個の大きさ
つまりシリコンの大きさあたりのSIMDユニットの能力は似たような物

同じシリコンの枠で
 Bull :スカラコア2個でSIMDユニット1個を動かす
 Sandy:はスカラコア1個をHTTで2スレッドにしSIMDユニットを動かす
って話
281Socket774:2010/05/08(土) 00:43:28 ID:Xn+nZieX
>>256
>他の仕事しながら趣味でやってる奴のほうがスキル高そう

ここで話を出来るレベルの奴で、それはないだろう。
俺も趣味でやっているが。
282Socket774:2010/05/08(土) 00:43:45 ID:+dz4CnHe
>>249
> 既製ソフトのエンジン使い回しで抑えこめばそんなもんかもね。
> 問題はイニシャルコスト。
>
> つかそれはそうとDX11使った汎用ゲームエンジンって誰が開発するの?
> DX10すらDX9と殆ど差がなかった気がするんだが。
> (故意にXP/DX9環境でオプションを制限しただけのソフトならいくつかあったけど)
>
> 次期UnrealEngineはTimの発言からすると次のコンシューマゲームが出る頃まで音沙汰無い気がする

公表されてるのはコレくらいだな
Frostbite 2 FPS
Unigine
Vision Engine MMORPG
CryEngine 3 FPS
EGO (game engine) Racing
X-Ray v1.6 (game engine) FPS
4A Engine FPS
Esenthel Engine MMORPG, RPG, FPS
Neutron 3D Engine

ちなみにカプコンのMTFW2も一応対応しているらしい
DX10対応エンジンをDX11対応にするのはたいして難しくも無いらしいし、いろんな所が検証していると思うよ
283Socket774:2010/05/08(土) 04:40:07 ID:AnzWx8qV
>>275
エネルギー効率がよければ、高クロックの余地があるって事です。
インテルのHTT導入は、パイプラインがあまり使われていない事の証拠
284Socket774:2010/05/08(土) 04:43:04 ID:rhnrLFvL
↑典型的な素人コメント
285Socket774:2010/05/08(土) 04:44:55 ID:AnzWx8qV
違うのですか?
286Socket774:2010/05/08(土) 05:04:46 ID:MpGU5UQu
このスレの玄人は荒らしコテの存在に自棄気味になってネタに走る
マジレスしてる奴は素人
287,,・´∀`・,,)っ-○○○:2010/05/08(土) 05:22:01 ID:gX+S8d8a
> エネルギー効率がよければ、高クロックの余地があるって事です。

理屈の上では同一アーキテクチャでの消費電力はクロックの3乗に比例して大きくなるから
(リーク電流分は別)上がっても多寡がしれてる。
Cellのメインコア(PPE)なんか3.2GHzと高クロックだが一つ一つの命令が高レイテンシで、
実質1.6GHzのAtomとどっこいの性能しか発揮できなかった。

レイテンシを短くするにはより高速なトランジスタでロジックを構成する必要があり、
消費電力も上がるし、クロックも上がらない。
増大したレイテンシを(広義の)SMTで埋める手も有効だが、AMDはそういう設計になってない。


> インテルのHTT導入は、パイプラインがあまり使われていない事の証拠

一部のプログラムに限れば正しいが、サーバプログラムですらせいぜい2〜3割の性能向上に留まっている。
逆に言うと律速点に対して80%程度の充填率は達成できているということ。
288Socket774:2010/05/08(土) 05:24:13 ID:ys9Mq868
>>286
成る程な
289,,・´∀`・,,)っ-○○○:2010/05/08(土) 05:31:17 ID:gX+S8d8a
曰くx86最大の熱源がデコーダだろ
IntelはComplex Decoderは1基に留めてるがBulldozerは1モジュールあたり4基
正直、BulldozerがSandy Bridgeより省電力とか高クロックとかにしやすい理由が思い浮かばないね
290Socket774:2010/05/08(土) 05:48:46 ID:sYNVLsFS
>K10コア2個でSandyコア1個の大きさ
>つまりシリコンの大きさあたりのSIMDユニットの能力は似たような物

つまりllanoとsandy bridgeのGPU部分は同規模なので能力は似たような物

>今がどうとかじゃなく、5年後10年後あるいは更にその先の世界のゲームが、
>DX9ベースの今と何も変わらんしょぼいグラフィックとゲーム性のままだと思っているのかね

五年前と今でどんだけ変わったんだよ
291Socket774:2010/05/08(土) 05:52:36 ID:sYNVLsFS
>団子が好きなブラウザゲーやIpadとかだって、
>将来的にはDX11レベルのAPI使ってGPUによるアクセラレーションも出来る高度なものが出てくるだろう
>今後どんな技術革新やブームがあるかも分からないのに、旧世代の規格に縛られたままでいいとか思考停止にもほどがある

その労力に対しての効果が低いってお話なんだが
292,,・´∀`・,,)っ-○○○:2010/05/08(土) 06:07:48 ID:gX+S8d8a
コンシューマゲーム機が16ビットから32ビットになったときは2Dから3Dへの変化があったが
アセンブラで組んでたプログラムがC/C++で書けるようになったことである程度コストを相殺できた。

今はコストをかければかけた分だけリターンがある時代じゃないからな。

たとえば、携帯電話へのSFCタイトルのベタ移植よりDX11のほうが低コストで済むなら
喜んで飛びつくだろうよ。
どこの会社もその手の移植ものは人件費の安い中国の開発会社に投げてるよ。

もうそのレベルまで技術単価落とさないとやってけない。
シェーダプログラマ1人月収100万とかで雇ってる余裕なんてない。
293Socket774:2010/05/08(土) 06:17:09 ID:sYNVLsFS
例えば
4-5kmの道のりを20km/h程度で巡航するなら
1.5万円のママチャリでも
30万円のエントリーレベルロードバイクでも
150万円のハイエンドロードバイクでも変わらない
体力的にも小学生レベルでかまわない

50-100kmの道のりを30-40km/h程度で巡航するなら
1.5万円のママチャリは論外だが
30万円のエントリーレベルロードバイクでも
150万円のハイエンドロードバイクでも変わらない
体力は高校生の運動部レベルが必要

150-250kmの道のりを40-50km/h程度で巡航するなら
30万円のエントリーレベルロードバイクと
150万円のハイエンドロードバイクで違いが出る
体力はよくトレーニングを積んだ大学生レベルが必要
294Socket774:2010/05/08(土) 06:25:36 ID:Xn+nZieX
>>293
ちょっとマジレスするが、

> 50-100kmの道のりを30-40km/h程度で巡航するなら
> 体力は高校生の運動部レベルが必要
この程度のレベルでは無理。集団走行が前提。

> 150-250kmの道のりを40-50km/h程度で巡航するなら
> 体力はよくトレーニングを積んだ大学生レベルが必要
集団走行を前提なら150kmなら可能だろうが、
250kmは大学生レベルでは無理。
プロでも厳しい。

よってたとえになっていない。
295,,・´∀`・,,)っ-○○○:2010/05/08(土) 06:31:08 ID:gX+S8d8a
Half Life 2出てからから5年半くらい?















やっぱり停滞してるなPCゲーは。
296Socket774:2010/05/08(土) 06:33:05 ID:sYNVLsFS
可能です
297Socket774:2010/05/08(土) 06:34:48 ID:H//5wQqf
>正直、BulldozerがSandy Bridgeより省電力とか高クロックとかにしやすい理由が思い浮かばないね

おまえのアタマの中で浮かぶかどうかなんぞゴミよりどうでもいい。
現実に何が出てくるかだけが重要。

糞高い使い捨てソケットママンの害悪企業は人類の敵
298Socket774:2010/05/08(土) 06:36:14 ID:Xn+nZieX
下り坂ならね。
299,,・´∀`・,,)っ-○○○:2010/05/08(土) 06:38:09 ID:gX+S8d8a
AMDのCPUシェアもそろそろ下げ止まるかな?



http://journal.mycom.co.jp/articles/2010/04/27/x6preview/menu.html
大原さん、なんでi7と比較しないの?
300Socket774:2010/05/08(土) 06:56:03 ID:57RiFZ7W
プログラムのステップ数が多くなれば多くなるほど、反比例的に開発費がかかり
反比例的にバグが多くなり、反比例的に時間とメンテ代がかかる。
結局開発費なんて毎回相場が決まっているから、反比例的にかかる開発費を抑える=
ステップ数を抑える=品質がよくないものが出来る

最近の3Dレベルが革新的に上がらないのはそのため。

それに、ゲームで一番重要な要素は「熱中できる要素があるかどうか」がKeyであり
その要素は3Dの品質とゲームの内容/種類どちらに比重があるかと言うと後者。

よって開発者がどこにポイントを置いて開発するかというと、3Dの品質ではなくて
ゲームの内容->ゲームの核となるシステムの定義づけの方に金かけるだろう。
301Socket774:2010/05/08(土) 07:05:15 ID:ErmCSFDd
「DX11なんて不要」
↑NVがすばやくAMDより対応してたらそんなセリフ吐かない
302Socket774:2010/05/08(土) 07:05:30 ID:sYNVLsFS
> 50-100kmの道のりを30-40km/h程度で巡航するなら
> 体力は高校生の運動部レベルが必要

ちなみにこれは、平日の朝飯前に
よく訓練されていないおっさんの俺が
10万そこそこのクロモリロードでやってます
303Socket774:2010/05/08(土) 07:16:45 ID:sYNVLsFS
>>299

>またTurbo CORE Technologyの効果はもう少しきちんと検証したほうがいいだろう。
>加えて、非AMDプラットフォームとも比較をしてみたいところだ。
>というわけで、このあたりはこのあとのフルバージョンで御紹介の予定なので、楽しみにしていてほしい。

ま、こういうのあるけど
ttp://www.computerbase.de/artikel/prozessoren/2010/test_amd_phenom_ii_x6_1055t_1090t_be/
304Socket774:2010/05/08(土) 07:18:46 ID:sYNVLsFS
だいたい870-860程度
305Socket774:2010/05/08(土) 07:20:49 ID:6bB+mmNz
雑音テヘごんだんごの一人劇場がはじまるよ!
306Socket774:2010/05/08(土) 07:25:16 ID:Xn+nZieX
>>302
日本で50km-100kmを巡航出来る場所がどこにある?
北海道?
307Socket774:2010/05/08(土) 07:32:44 ID:MpGU5UQu
>>306
おまえはなにをいっているんだ

そもそも陸上交通に巡航を使うのはおかしいけど
50km-100kmの周回なんて自宅の庭レベルでだって可能だろ
308Socket774:2010/05/08(土) 07:32:54 ID:6bB+mmNz
この馬鹿夫は環状コースを走る発想はないのかね・・・・
309Socket774:2010/05/08(土) 07:41:57 ID:ys9Mq868
ひとつ聞いていいか?
その辺の話がどうAMDの次世代CPUに戻れるんだ?
310Socket774:2010/05/08(土) 07:47:38 ID:MpGU5UQu
関連用語使ってるだけの単なる妄想連レスとそう違いは無いんだし
戻って来れなくても別にどうでもいいじゃないか
311Socket774:2010/05/08(土) 07:51:41 ID:Xn+nZieX
>>307
何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
ローラー台とかいうんじゃないだろうな。

結局たとえになっていないということ。
312Socket774:2010/05/08(土) 07:53:31 ID:H//5wQqf
概念論に現実論ぶつけるなよ。
煮干しでも喰っとけ。
313Socket774:2010/05/08(土) 07:56:57 ID:6bB+mmNz
>何を言っているかって、自転車で高校生の運動部レベルが、
>50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。

おまえ本当にチャリ乗ったことある??
314Socket774:2010/05/08(土) 07:57:36 ID:Xn+nZieX
概念論とやらにもなってないだろ。
315Socket774:2010/05/08(土) 08:01:54 ID:6bB+mmNz
俺は厨三の時に260Kmを8時間で走ってたぞw
しかもランドナー車で。pまけに帰宅部でなw
100Km以内なら余裕で35Km/hは維持できるだろ
316Socket774:2010/05/08(土) 08:03:32 ID:Xn+nZieX
>>313
ちょっとの時間巡航するというだけなら出来るよ。
でも50km-100kmを巡航するっていうのがまず無理な話。
巡航という意味をわかっているのか?効率よく走ることだぞ。
出来るというならやってみろ。
出来るならアマチュアのロードレースで上位入賞出来るわ。
317Socket774:2010/05/08(土) 08:04:27 ID:6bB+mmNz
巡航の新解釈だな
318Socket774:2010/05/08(土) 08:09:34 ID:Xn+nZieX
巡航速度(じゅんこうそくど)とは、航空機や船舶などが燃料の消費効率が最も良い状態で移動する速度。
通常時の移動に用いられる、経済速度。
ロードレーサーなどで長距離走行をするライダーの間で、
基本とする走行速度として表現するが、
「いかに少ないエネルギーでより遠くに移動するか」の概念が無視されており、誤用である。
319Socket774:2010/05/08(土) 08:09:56 ID:6bB+mmNz
> 50km-100kmを巡航するっていうのがまず無理な話。
荒川ロードの一本道だけですら80kmあるのに(´・ω・`)
320Socket774:2010/05/08(土) 08:16:01 ID:MpGU5UQu
何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
でも北海道でなら出来る。


北海道が有頂天だな
321Socket774:2010/05/08(土) 08:16:33 ID:ys9Mq868
俺てっきりこのスレは団子が知識をひけらかしたいだけのオナニースレだとばっかり思ってたけど、こいういう流れになる事も有るんだな。
322Socket774:2010/05/08(土) 08:28:35 ID:6bB+mmNz
>>320
> 自転車で高校生の運動部レベルが、
> 50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ
だから、コースは荒川沿いを始点終点で余裕で80kmあるだろ、
体力的には中学生レベルでも余裕で出来るぞそんなもん。
ソースは中学時代の帰宅部のチャリマニアの俺。

ちなみに俺も大学行くまで道産子だったが。
田舎にカンパの50周年モデル置きっぱなしなんだよな
今売ったらいくらくらいになるんだろ?
323Socket774:2010/05/08(土) 08:33:06 ID:MpGU5UQu
何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
しかし青函トンネルはガリバートンネル(ドラえもん秘密道具)なので
それを通り抜けて北海道に着いた高校生なら余裕


おれは北海道属性の高校性だから一目置かれる存在
324,,・´∀`・,,)っ-○○○:2010/05/08(土) 08:33:31 ID:gX+S8d8a
大腿の肉割れを自慢するスレはここですか?
325Socket774:2010/05/08(土) 08:35:42 ID:MpGU5UQu
326Socket774:2010/05/08(土) 08:39:31 ID:6bB+mmNz
さて串焼きいってくるか
327Socket774:2010/05/08(土) 08:41:33 ID:GO0pXIB1
パイプライン内部にたくさんの命令を抱え込んで複雑に加工してスループットを上げるIntel
単純で貧弱なパイプラインを多数並べて、これだけ流し込んどけば詰まることないだろというAMD
現在の整数系ベンチマークではほぼ全てのシーンでAMDはIntelに負けている
唯一AMDが勝てるのは予測の効きにくい分岐の密度が極端に高いベンチマーク
各所のキューに命令をバッファするIntelの設計では、どうしても予測ミスペナルティが大きい
人工的にレジスタ読み出しストールを発生させるとIntelは遅いけど現実のプログラムでは起こらない
328Socket774:2010/05/08(土) 08:43:26 ID:Xn+nZieX
だからなのはおまえ。
巡航するっていうのは効率の良い状態で移動する速度。
つまり人間にたとえると心拍数で60%程度だ。
試しに心拍計付けて走ってみな。

つまりだ、インテルはフルパワーで頑張ってぶっ飛ばすけど、
AMDは巡航することに重みを置いているということだ。
329,,・´∀`・,,)っ-○○○:2010/05/08(土) 09:15:17 ID:gX+S8d8a
フルパワーで頑張らないことに重みを置いた結果が「CoolSpeed Technology」ですか?
330Socket774:2010/05/08(土) 09:47:56 ID:DOaQ6830
まだそんな妄想を言ってるのか
331Socket774:2010/05/08(土) 10:24:00 ID:MpGU5UQu
それでも北海道なら・・・北海道ならきっと何とかしてくれる
332Socket774:2010/05/08(土) 10:35:05 ID:9JSCSfB9
トラックの後ろに張り付けば一般人でも時速100kmで楽々走れるぞ
ギヤ比をいじった自転車と安全装置が必要なので実用性は無いが・・・
NHKが試してがってん系の番組で実験してたよ・・・
333Socket774:2010/05/08(土) 10:50:21 ID:9JSCSfB9
Bulldpzerのコア1個のサイズ&性能がK10程度だとすると

Bullのサイズ:Sandyのサイズ=1:2 → 消費電力の関係は1:1.4〜1:2とか?(根拠は無し)
Bullの性能:Sandyの性能=1:1.15

HKMGの開発にそれなりに成功すれば、SOIとの併用もあって消費電力関係の性能は
同クラスになりそうだからワットパフォーマンスは良いだろうね
でもその一方で、Bullのクロックを15%増して性能で追いつこうとすると
消費電力の増加率が2乗なら1.3倍、3乗なら1.5倍になって微妙なところかな?
334Socket774:2010/05/08(土) 11:04:30 ID:Xn+nZieX
ダンプの後ろに張り付いて150回転位させて80km/h弱を出したことはあるが、
ダンプが止まったら死ぬなと思ったよ。若かりし思い出・・・・。迷惑だな。

そもそもブルドーザーってネーミング自体が速くないから、
コアを増やして押していくっていうのがAMDなんだろう。
早さではインテルに勝てないよ。
335Socket774:2010/05/08(土) 11:09:03 ID:MpGU5UQu
整数スカラ並列度は頭打ち
ベクタではGPUにボコボコの現状ではキャッシュ性能だけ(じゃなく分岐処理等もだが)が頼り
そのキャッシュがBullでは大変化
元々キャッシュが貧弱なままでIntelと張り合って来たAMDだけど
ここでそのキャッシュに手を入れてどうなるかって状況だ
336Socket774:2010/05/08(土) 11:12:54 ID:ErmCSFDd
おいつけそうかなーと思った矢先にまた離される
なら、マシンの改造(HD2xxx→HD3xxx→HD4xxx→HD5xxx)か
ショートカット(8800GT→9800GT→GT240)すればいい
337Socket774:2010/05/08(土) 13:14:59 ID:6MFlfoam
規制解除されてから雑音さん絶好調ですな
338Socket774:2010/05/08(土) 13:26:45 ID:BW7Gtizm
1の知識から10の願望を膨らませ100罵る
せめてその1の知識を自分の狭量さを曝け出すため以外に使えないものかね
339Socket774:2010/05/08(土) 13:29:40 ID:hRqzA1Gi
>>333
性能差が本当に1:1.15程度だったらよかったのにね
340,,・´∀`・,,)っ-○○○:2010/05/08(土) 14:20:59 ID:gX+S8d8a
メモリ帯域依存度の高くないSPECintですらNehalem(HT ON)が対Barcelonaでダブルスコアだからなあ
341Socket774:2010/05/08(土) 14:24:06 ID:6bB+mmNz
と自分に言い聞かせたいんだな。可哀想に
342,,・´∀`・,,)っ-○○○:2010/05/08(土) 14:56:27 ID:gX+S8d8a
敢えてトリプルチャネルじゃないNehalemのスコアとってきた

4コア DDR3 2ch
Fujitsu CELSIUS W280, Intel Core i7-860
Base 113
Peak 121
http://www.spec.org/cpu2006/results/res2010q1/cpu2006-20100212-09640.html

2ソケット × 4コア DDR3 2ch
Dell Inc. PowerEdge R805 (AMD Opteron 2387, 2.80 GHz)
Base 114
Peak 137
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090427-07230.html



※4コアと8コアの比較です
343,,・´∀`・,,)っ-○○○:2010/05/08(土) 14:58:50 ID:gX+S8d8a
i7のほうのURL訂正


4コア DDR3 2ch
Fujitsu CELSIUS W280, Intel Core i7-860
Base 113
Peak 121
http://www.spec.org/cpu2006/results/res2010q1/cpu2006-20100212-09634.html
344Socket774:2010/05/08(土) 15:00:21 ID:ElZX1kNh
Nehalem のスコアは?
345Socket774:2010/05/08(土) 15:01:34 ID:ElZX1kNh
団子ってNehalemとLynnfieldの区別も付かないレベル?
346,,・´∀`・,,)っ-○○○:2010/05/08(土) 15:13:27 ID:gX+S8d8a
347Socket774:2010/05/08(土) 15:14:57 ID:+dz4CnHe
>>333
> Bulldpzerのコア1個のサイズ&性能がK10程度だとすると
コアあたり3way→2wayで色々削ったのに同サイズとかねーよ
348Socket774:2010/05/08(土) 15:17:00 ID:+dz4CnHe
NehalemのスコアってHTT有効にした似非8コアだろ
349,,・´∀`・,,)っ-○○○:2010/05/08(土) 15:20:21 ID:gX+S8d8a
整数ユニットなんてそもそもたいした面積食ってない
http://www.chip-architect.com/news/K8L_floorplan.jpg


そもそも元ネタのSandy BridgeとLlanoのコアサイズ比較、前者はL2のぶんを含むが後者は含まない時点で既におかしい。
350Socket774:2010/05/08(土) 15:21:43 ID:9JSCSfB9
コアに占める整数演算器の大きさなんて微々たる物だろう
351Socket774:2010/05/08(土) 15:23:53 ID:6bB+mmNz
大きいのがいいなら屁ルミでも使っとけって感じだな
352Socket774:2010/05/08(土) 15:24:06 ID:9JSCSfB9
353,,・´∀`・,,)っ-○○○:2010/05/08(土) 15:24:19 ID:gX+S8d8a
>>348
その似非8コアに真性4コア×2ソケットがどっこいなんだぜ?
Bulldozerはさしずめ仮性8コアか。確実にK10の8コアよりはIPC落ちると思うんだが。
354Socket774:2010/05/08(土) 15:28:31 ID:JEJY0erC
なんでIPCに必死なんだこいつは?
355,,・´∀`・,,)っ-○○○:2010/05/08(土) 15:30:34 ID:gX+S8d8a
じゃあクロック数で勝負するのか




Pentium 4だな
356Socket774:2010/05/08(土) 15:32:53 ID:EFJ763LA
POWER6で
357Socket774:2010/05/08(土) 15:32:59 ID:JEJY0erC
なんか言われたら勝ってる部分を並べるのは良いが何の話をしてるんだ

キリガイAMDerと同じじゃん
358Socket774:2010/05/08(土) 15:35:28 ID:9JSCSfB9
BullのIPC設定の方針は私みたいな素人には予測しようが無いな
せめてコアサイズの予測とかが出れば考えようも有るが
359Socket774:2010/05/08(土) 15:56:49 ID:+dz4CnHe
>>353
・シングル性能
Nehalem>K10
・マルチの効率
実コア>HTT
で総合的に互角ってだけ
何がおかしいのか理解できない、団子は馬鹿なの?
360Socket774:2010/05/08(土) 16:09:31 ID:6bB+mmNz
馬鹿だよ
361Socket774:2010/05/08(土) 16:20:02 ID:ErmCSFDd
>>342
Turbo Boostって働くのか?
362Socket774:2010/05/08(土) 16:38:50 ID:knXGA7+S
8コアのBULLが2,3万円で買えれば、うれしいではないか。
363Socket774:2010/05/08(土) 16:51:40 ID:JZZ71bgH
>>287
>消費電力はクロックの3乗に比例
3乗は酷すぎ.比例でしょ.

>>342
>2ソケット × 4コア DDR3 2ch
>Dell Inc. PowerEdge R805 (AMD Opteron 2387, 2.80 GHz)
×DDR3
○DDR2-800
364Socket774:2010/05/08(土) 16:52:53 ID:+dz4CnHe
たぶん買えるよ
X6が1〜3万、X8が2万〜5万だろうね
価格戦略的にはIntelのClarkdaleとLynnfieldみたいな感じになると思う
Sandybridge6コア次第で10万円の価格帯でも出るかもしれない
365Socket774:2010/05/08(土) 16:55:26 ID:9JSCSfB9
あとは強烈なターボが欲しいね
8コアもあればターボ発動条件を満たす機会は十分に多くなりそう
366,,・´∀`・,,)っ-○○○:2010/05/08(土) 17:12:20 ID:gX+S8d8a
>>361
全部のコア駆使したときのスループット計ってるのに
一部のコアしか使われてないときにクロックを引き上げる技術が効いてるかどうかというのは
野暮な質問だと思うが。

シングルタスクだとこうだね

Fujitsu CELSIUS W280, Intel Core i7-860
http://www.spec.org/cpu2006/results/res2010q1/cpu2006-20100212-09640.html
Base 32.3
Peak 35.7

Supermicro H8DA3-2 , AMD Opteron 2386 SE
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090416-07093.html
Base 17.9
Peak 21.6


既にTurbo-Boost発動時のクロック数以上の差が付いてると思うんだが
367,,・´∀`・,,)っ-○○○:2010/05/08(土) 17:14:31 ID:gX+S8d8a
>>359
> で総合的に互角ってだけ

言ってみれば「飛車角落ち」で拮抗してるのを「互角」っていうのか。随分ゆとり思考だな。
i7 9xxじゃなくてデュアルチャネルの8xxとの比較にしたのはおいらの真心

> 何がおかしいのか理解できない、団子は馬鹿なの?

別におかしかないよ。
Bulldozerで1ソケットあたりの「コア」数を倍増させてもまだ競合CPUに及ばない理屈を解りやすく説明できるだろ?
K10でダブルスコア負けだったのがBulldozer世代では1〜2割負けくらいになる程度



>>363
ごめん、DDR3対応したのIstanbulからなのね。
じゃあHT無効4コア vs 6コアの1ソケット対決はどう?

Fujitsu CELSIUS W280, Intel Core i5-750 2.66GHz
http://www.spec.org/cpu2006/results/res2010q1/cpu2006-20100212-09630.html
Base 92.4
Peak 99.2

Hewlett-Packard Company Proliant DL165 G6 (2.6 GHz AMD Opteron 2435)
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090525-07505.html
Base 82.0
Peak 104
368Socket774:2010/05/08(土) 17:24:48 ID:M97o+wUb
compilerの性能差を語るスレはここですか?
369Socket774:2010/05/08(土) 17:36:01 ID:mA06LDf1
エンコ坊的には、2モジュールの高クロックモデルに期待。
370Socket774:2010/05/08(土) 17:39:06 ID:LWd257Uz
スレの流れを無視して壊れた録音テープみたいに自分の都合の良いデータだけ繰り返し並べ、都合が悪ければスルー

最近の団子の行動パターンってまんまテヘの行動パターンと同じじゃねーかw

やはり団子=テヘか…
371Socket774:2010/05/08(土) 17:40:42 ID:ErmCSFDd
Stream TRAID on 64 bit linux - maximaum threads
http://it.anandtech.com/show/2978/amd-s-12-core-magny-cours-opteron-6174-vs-intel-s-6-core-xeon/5

Dual Opteron 6174 2.2・・・49372
Dual Xeon X5670 2.93・・・35868

言ってみれば「飛車角落ち」で拮抗してるのを「互角」っていうのか。随分ゆとり思考だな。
372Socket774:2010/05/08(土) 17:42:24 ID:CKUTmMjj
でもテヘ本人は他人を演じきっていると本気で思い込んでいるから困る…w
373Socket774:2010/05/08(土) 17:45:50 ID:+dz4CnHe
恐怖政治による最適化を語るスレですよここは

しかし団子が必死すぎて笑える
1個や2個インテルが有利なベンチマーク見せられても、だからどうしたって話なんだが

現実に1090Tは売れまくっているし、i7じゃなくX6選んでいる奴も少なからず存在する
そもそも、875K出してくるほどIntelもK10の多コアを脅威に感じているよ
374Socket774:2010/05/08(土) 17:49:53 ID:+dz4CnHe
ほとんどのマルチスレッド対応のベンチマークでi7とX6は数%の差で競っている
1割以上の差があるのは極限られた場合のみの状況で何を叫んでも見苦しいだけだね
375,,・´∀`・,,)っ-○○○:2010/05/08(土) 17:50:47 ID:gX+S8d8a
>>368
へー、コンパイラに差があるの?

Dell Inc. PowerEdge 1950
http://www.spec.org/cpu2006/results/res2006q4/cpu2006-20060918-00109.html 
Result 16.3 / Baseline 15.8

Hewlett-Packard Company ProLiant BL465c (3.0GHz AMD Opteron 2222)
http://www.spec.org/cpu2006/results/res2007q3/cpu2006-20070831-01930.html
Result 15.5 / Baseline 14.5


>>370
都合が悪い事実を出されると人格攻撃だとか同一人物認定ってのも芸がないですよ
376Socket774:2010/05/08(土) 17:55:32 ID:kaBg8ij/
377Socket774:2010/05/08(土) 18:02:10 ID:ErmCSFDd
>>376
UMCといい、片っ端から買いまくるつもりなのかね
378,,・´∀`・,,)っ-○○○:2010/05/08(土) 18:14:46 ID:gX+S8d8a
>>371
Stream TRIADはHPC向けのメモリ帯域ベンチマークだね。
まあ、3chと4chじゃその程度の差は出るだろうね。

でもBulldozerが重視(笑)してるらしい整数演算性能にその手のベンチはほとんど意味がないよ。

ついでにいうと実際のHPC用途ですらそれほど優位な差ではないかもしれないね。
メモリローカリティを意識してプログラムをチューニングするのが当たり前だからね。
ただでさえMP(4ソケット以上)による密結合クラスタよりもDPの粗結合クラスタのほうが広く使われてるくらいだし。
379Socket774:2010/05/08(土) 18:24:47 ID:MpGU5UQu
最新レスでいきなり”粗結合:”キタ
ググったらもっさりスレ36だったんだが
ふざけて妄想埋め荒らししてるだけなら死んでくれ
380Socket774:2010/05/08(土) 18:28:18 ID:ErmCSFDd
Blender 2.5 Alpha 2 Windows
Dual Opteron 6174 2.2・・・31.5
Dual Xeon X5670 2.93・・・26.4

Blender 2.5 Alpha 2 Linux
Dual Opteron 6174 2.2・・・18
Dual Xeon X5670 2.93・・・31

*Lower is better

ところで、団子さんはhttp://boo.2ch.net/についてなにか思うところはありませんか
381Socket774:2010/05/08(土) 18:40:31 ID:+dz4CnHe
Bulldozerの否定はIntelが研究分野で最も力を入れてるSCCの否定にもつながるから止めとけ
AMDが重視していこうとしてるのは単なる整数演算性能じゃなく、コスト当たりや電力当たりでのマルチスレッド性能だよ
ベンチマークでの優劣なんかもうたいして重要視してないってこった
382Socket774:2010/05/08(土) 18:44:12 ID:knXGA7+S
>>381大正解。
383Socket774:2010/05/08(土) 18:45:47 ID:JZZ71bgH
>>378
8chでもダメな子
http://www.anandtech.com/show/3648/xeon-7500-dell-r810/7

HPCでMPではなくDPが使われているのはコストの問題が1番だと思う.
384Socket774:2010/05/08(土) 18:45:56 ID:+dz4CnHe
とはいえベンチマークで明らかに劣るようなアーキテクチャにはしてないけどな
実効性能や扱い易さを重視していて、ろくに使われもしないHTTやTB任せのNehalem系よりは人気出そうだ。
385Socket774:2010/05/08(土) 19:00:44 ID:3MtMcD/b
>>381
それは既に立ち枯れAMDという事なの?
もう復活の見込みは無いの?
速くて安くて安心のAMDは何処へ・・・
386Socket774:2010/05/08(土) 19:29:12 ID:QIJ3RdEK
要らない子

ついでに言うなら
AMDは価格戦略でしか対抗できず
CPUでもGPUでも

Radeonに制限がないから中華製のtengaもRadeonつかってFireProは無視
自分の首絞める行為をやるしかない
今後の製品でも
387Socket774:2010/05/08(土) 19:32:02 ID:L/HUVhl5
>>353
? 何が言いたいかさっぱりだぞ…?
388Socket774:2010/05/08(土) 19:32:15 ID:MpGU5UQu
シングルスレッドでのK10→Bullのユニット数変化は
デコーダ+1
ALU-1
SIMD±0
あとはキャッシュが大変化
AMDの弁・口調によればALUが2つになっても
性能の下落はせいぜい2,3%てとこか
分岐・クロック・キャッシュ(ヒット率)、等の未知の項目からすれば何でもない
389Socket774:2010/05/08(土) 19:32:47 ID:L/HUVhl5
見事なまでに安価ミスったw
>>353ってなんだよ。>>385だよw
390Socket774:2010/05/08(土) 19:47:20 ID:9JSCSfB9
相手の収入源を断つってのも戦略の一つだろうね
391Socket774:2010/05/08(土) 19:57:11 ID:ErmCSFDd
GPU分野は価格戦略っつーか勝手にNVが自爆しちゃって逆に値上した経緯が・・・
最近ではどこかの県立大学の教授がGTX285だかGTX280だかを使ったスパコン作ってたがそれについて何かコメントはないでしょうか・・・
392Socket774:2010/05/08(土) 19:59:31 ID:3MtMcD/b
>>386
ビデオカードは元々大勝しているとこを買っただけだから、そこは安心している
けれど、問題はチップセットとCPU・・・
こっちを頑張ってほしい
393Socket774:2010/05/08(土) 20:02:41 ID:L/HUVhl5
>>392
買収した当時のATIって別に大勝利じゃないよな? むしろ…。
394Socket774:2010/05/08(土) 20:06:36 ID:9JSCSfB9
あれってCUDAを介さないで直接動かすのかな

彼らの研究目的は『汎用GPUによって安価に高性能なスパコンを作る』ことにある
スパコンを作る研究であり、得た処理能力を彼ら自身が何かに使う訳じゃない

TeslaやFirestreamでは研究する意味が無い
395Socket774:2010/05/08(土) 20:08:50 ID:9JSCSfB9
×『汎用GPUによって安価に高性能なスパコンを作る』
○『一般大衆向けの製品であるGPUによって安価に高性能なスパコンを作る』
396Socket774:2010/05/08(土) 20:23:52 ID:awUi9idF
3 ALUのk8と2 ALUのnanoで差がないから
ブルも差がないだろう

あ、でもnanoのALU2は分岐命令と単純命令だけだから1.5 ALUってとこか
397Socket774:2010/05/08(土) 20:33:47 ID:MpGU5UQu
nanoって・・・
ttp://hamanasu.sakura.ne.jp/~yami/qandc/cpuspec.html
ここだと散々な扱いなんだが・・・
整数スカラだけなら差が無いのか?

まあどうせALU2・3(&デコーダ3・4+1&SSE64・128等々)を比べるんならヨナとコンロだろ
398Socket774:2010/05/08(土) 20:39:42 ID:kaBg8ij/
>>397
そのサイトがあまりにもゴミなだけです
399Socket774:2010/05/08(土) 20:49:40 ID:bnTx52mg
>>391
値上がりって、TSMCのせいで数が作れない、部材(メモリとか)の高騰のせいだぞ
400Socket774:2010/05/08(土) 20:56:41 ID:ErmCSFDd
http://www.extremetech.com/image_popup/0,,iid=255433&aID=249505&sID=27867,00.asp
こんなの、カークが浮かばれないです
401Socket774:2010/05/08(土) 21:00:54 ID:awUi9idF
nano-eでは更に2-3割りパフォーマンスが上がる
402Socket774:2010/05/08(土) 22:31:08 ID:6bB+mmNz
録音ってコテに直せよテヘごんだんごさん
403Socket774:2010/05/08(土) 22:40:27 ID:ErmCSFDd
焼き殺されたのか?団子
404Socket774:2010/05/08(土) 23:21:12 ID:0Mtqk9Oi
SandyBridgeと同時期のリリースといわれていたBulldozerなのだが
まだサンプルの噂とか入ってこないな
405Socket774:2010/05/08(土) 23:59:50 ID:+dz4CnHe
まだ登場まで1年くらいあるからのんびり待とうぜ

そういえば、256itAVXは2コア共有だけど、SSEやFPUはコアと同数の搭載で性能も向上しているっぽいかな
k10のSSE/FPUユニットって、K8の80Bitユニットに後付で64Bit付け足したものだから、
構造的にムダや性能の足かせがありそうだったけど、
Bulldozerでは最初から128Bitユニットとして新設計されているから、性能が少しは良くなっていそうだ。

K10.5はSSEに限らずいろんな部分がK7からの度重なる拡張でムダだらけで足かせだらけな気もするから、
ゼロベースで新規開発しているBulldozerコアは、かなり効率がいいデザインがされてると思う。
406Socket774:2010/05/09(日) 00:11:52 ID:PscwQLrB
>>393
NVIDIAを買えばよかったのに・・・とか言われてたよな。
結果的によかったけど。
407Socket774:2010/05/09(日) 00:18:14 ID:TykbZ5RQ
>>405
>k10のSSE/FPUユニットって、K8の80Bitユニットに後付で64Bit付け足したもの

マジなの?
408,,・´∀`・,,)っ-○○○:2010/05/09(日) 00:25:21 ID:sNWFFdis
>>381
> Bulldozerの否定はIntelが研究分野で最も力を入れてるSCCの否定にもつながる

つながらねーよヴァ-カ
整数クラスタがスレッド毎に分かれてるだけでフロントエンドの数も同時実行スレッド数も
Sandy Bridgeと変わらない、製品レベルの代物がIntelのメニーコア研究とどう繋がる?
それともAMDは実験段階のものを製品化するのか?大した主張だな。
409,,・´∀`・,,)っ-○○○:2010/05/09(日) 00:39:45 ID:sNWFFdis
>>383
何故同じページを引用する?

同じページになぜレイテンシの表があるのか英語くらい読めるだろ
なぜXeon X7560のスループットが低いのかちゃんと説明されている。
英語読めないわけじゃないだろ
410,,・´∀`・,,)っ-○○○:2010/05/09(日) 00:51:12 ID:sNWFFdis
>>380
> ところで、団子さんはhttp://boo.2ch.net/についてなにか思うところはありませんか

この通り、何もないよ。
当てが外れたなヴァーカ

>>379
loose couplingのほうの訳だから「疎結合」って表記が正しいのか。
ご指摘感謝いたします。
411Socket774:2010/05/09(日) 01:05:05 ID:F/OnfXRk
なんだか自分の仮説にすごい自信を持ってるんだな団子って
すごいなぁ
412Socket774:2010/05/09(日) 01:12:30 ID:OpoHju9O
結論はテヘ権田はインテルマンセー以外は受け付けませんってことだろ?
413Socket774:2010/05/09(日) 01:13:29 ID:OpoHju9O
団子じゃなくてテヘ権田の別人格だろ、
いちいち俺らが馬鹿に付き合って区別して呼ぶ必要ねーだろ
414,,・´∀`・,,)っ-○○○:2010/05/09(日) 01:16:16 ID:sNWFFdis
そそ、そもそもBulldozerがトランジスタ効率を追求した構造という主張(思い込み)に賛同してない。

なぜ整数クラスタ2つとFP/SIMDクラスタの3クラスタで別々にスケジューリングことでトランジスタ効率あたりの電力効率が
どう向上するのか全然わからん。

というか、Complex Decoder×4の時点で既に水膨れだろう
415Socket774:2010/05/09(日) 01:32:35 ID:OpoHju9O
結局この馬鹿は屁理屈さんざんこねくりまわして
言ってることはインテル最高しか言ってないんだよな
416Socket774:2010/05/09(日) 01:34:41 ID:Yr7mfo0l
>>407
マジだよ
K7/K8は 80BitFPUが64BitSIMDの代わりもしていて、
SSEは128Bitだから前半と後半の2回に分けて計算していた。

GF100の単精度と倍精度の実装と同じようなもの。

しかしそれじゃ、Core2以降に対抗できないから、K10ではFPUの隣に64Bitユニットを追加して、
128Bitを一回で計算できるようにした。
417,,・´∀`・,,)っ-○○○:2010/05/09(日) 01:36:20 ID:sNWFFdis
つまらん人格攻撃しか言うこと無いのかね

いやだねえAMDが否定されると自分が否定されてるように思えちゃう可哀想な人は
418,,・´∀`・,,)っ-○○○:2010/05/09(日) 01:45:17 ID:sNWFFdis
ちなみに>>416は大体正しい
K10の上位64ビットのSIMDユニットを新たに追加する実装はAMDが特許も申請してた


つーか、積和ユニットもだが、SSSE3, SSE4, AVXも追加するんだからFP/SIMDクラスタは相当な規模にはなりそうだぜ
419Socket774:2010/05/09(日) 01:45:24 ID:Yr7mfo0l
>>414
> そそ、そもそもBulldozerがトランジスタ効率を追求した構造という主張(思い込み)に賛同してない。
3wayは無駄が多いから2wayに減らしてるし、それに伴い色々軽量化してると思うよ
今よりは効率向上していると見て間違いない

> なぜ整数クラスタ2つとFP/SIMDクラスタの3クラスタで別々にスケジューリングことでトランジスタ効率あたりの電力効率が
> どう向上するのか全然わからん。
>
> というか、Complex Decoder×4の時点で既に水膨れだろう
消費電力が大きいデコーダーが、コアあたりX3だったのがX2に減るから消費電力は減ると思うんだが。

なんか枝葉末節にこだわりすぎて大局を見れてないんだな団子って
420,,・´∀`・,,)っ-○○○:2010/05/09(日) 01:58:34 ID:sNWFFdis
>>419
> 消費電力が大きいデコーダーが、コアあたりX3だったのがX2に減るから消費電力は減ると思うんだが。

?????
同じスレッド数で消費電力が減る理屈であってもK10の4コアよりBulldozerの8コアの方が省電力、という主張じゃないよねそれは
さて、2スレッドで4命令/clkなのはわかったが片方のスレッドが休んだときに1スレッドで最大何命令専有できるのかねデコーダは
421,,・´∀`・,,)っ-○○○:2010/05/09(日) 02:00:55 ID:sNWFFdis
そもそも可変長命令のデコーダで3命令/clkが4命令/clkに増えるのはリソース1.33倍とかの次元じゃないぞ
422Socket774:2010/05/09(日) 02:10:20 ID:OpoHju9O
なんで連投するのこの子、纏めるとか言う発想無いの?
423Socket774:2010/05/09(日) 02:11:25 ID:w5eAFKdA
それは1コアあたりに何命令まで発行するように設定されているかが判らないと推測しようが無いんじゃない
424Socket774:2010/05/09(日) 02:23:08 ID:4Mx13oPd
電力についてはコア増えた分クロックも落とせば何とでもなる
電力効率も大事だがそこだけだと性能が伸ばせない
これはintelもAMDも同じだけど、そのバランスのとり方に差が出て面白い
425Socket774:2010/05/09(日) 02:37:23 ID:xs1JExK7
K7系は3基のDirect Path(IntelのSimple Decoderに相当)と
1基のVector Path(複雑な命令専用のDecoder)の計4基の
Decoderがあった

Direct PathとVector Path、1基ずつで1基のComplex Decoderに相当するから

Bulldozerには
4基のDirect Pathと4基のVector Pathの計8基のDecoderがあるの?
426Socket774:2010/05/09(日) 03:03:59 ID:Yr7mfo0l
>>420
> 同じスレッド数で消費電力が減る理屈
それを言っているだけなんだが

>K10の4コアよりBulldozerの8コアの方が省電力、という主張じゃないよねそれは
もちろんそんな主張した覚えはさらさらないな、何処を読んだらそう勘違い出来るのか教えて欲しいくらいだ
まあ、Bobcatの8コアならK10 4コアより省電力っぽいけどね。
個人的予想は K10 4コアとBulldozer 6コア(3モジュール)が同程度というところだな。
427Socket774:2010/05/09(日) 03:07:28 ID:Yr7mfo0l
>>421
> そもそも可変長命令のデコーダで3命令/clkが4命令/clkに増えるのはリソース1.33倍とかの次元じゃないぞ
それってつまり、2コア(モジュール)換算だと 6命令から4命令に減るのはリソース0.66倍とかの次元じゃないってことになるよね
428Socket774:2010/05/09(日) 03:48:37 ID:IeOHMhL5
>>409
371とは別のページですよ.
それとメモリスループットが低いのはメモリキャパシティを増やしたためで
レイテンシとの関わりは書いてないと思うのですが.

ところでみなさんはBulldozerがどのくらいのクロックで出ると思っています?
6コアK10より8コアBulldozerの方がデコーダにしろALUにしろ少なくなるから,
Phenom II X6 1090Tより,つまり3.2GHzよりは高クロックになると自分は思っていますが.
Frond endとExecutionで消費電力の半分以上になるようですので.
http://citavia.blog.de/2009/10/28/more-on-power-management-7262005/
429Socket774:2010/05/09(日) 05:07:37 ID:KbFdCUgy
ttp://pc.watch.impress.co.jp/docs/2008/0428/kaigai438.htm
こうして見ると、Nehalemでは、フロントエンドにボトルネックがそのまま残されているようだが、
それは、設計の最初から織り込み済みなのかもしれない。
x86 CPUの現実としては、3〜4命令同時デコードは、限られたケースでしか現実的ではないと割り切っているという指摘もあるからだ。
CPUアーキテクトとしてIBM時代から有名なGlenn Henry(グレン・ヘンリー)氏(President and Founder, Centaur Technology)は次のように語る。

「(x86 CPU設計者の)誰もが同意しているのは、3から4命令の同時デコードにはいくつかの制約があるということだ。
常に3から4命令の同時デコードができるとは、皆、考えていない。
そして、通常は、おかしなプリフィックス(Funny Prefixes)が、ついてない場合のみを想定している。
Intelも、おかしなプリフィックスがない“ノーマル命令(Normal Instruction)”を、3から4命令ずつデコードすることを前提としているはずだ。
これは、我々の『Isaiah』(VIA Technologies/Centaur Technologyの次期CPUアーキテクチャ)の場合でも同じだ。
それ(ノーマル命令)以外のケースに(3〜4命令の同時デコードを)拡張しようとすると、デコーダが極端に複雑になってしまうだろう」

Henry氏が指摘するのは、先端x86 CPUの3〜4命令という命令デコード帯域は、イレギュラなプリフィックスがついていない命令を想定しており、
それ以外のケースでは命令デコード帯域が落ちることは織り込み済みということだ。
3〜4命令のデコードは、あくまでもピーク帯域で、平均値は落ちると考えていると推定される。
だとしたら、上流のフェッチ&プリデコードにボトルネックがあっても問題ではなくなる。

Nehalemの説明の通りだとすると、電力効率を考えた場合、無理に命令プリデコード&デコードを拡張することは得策ではないことになる。
そうすると、当然、今後の解決策として想定されるのは、「命令フェッチからデコードまでをできるだけスキップすること」になる。
将来のIntelのPC向けCPUの発展は、そうした方向へ向かってゆくのかも知れない。
430Socket774:2010/05/09(日) 05:52:59 ID:6Pde+Evh
x86の命令セットがボトルネックだって話は昔からあって、
RISC勢とかItaniumとか作ったわけだが、皆x86に敗北した。
パフォーマンスでも電力効率でも。
431Socket774:2010/05/09(日) 06:14:22 ID:01tAcw2H
隆盛(たかもり)くんLOVEなショタホモの目的は
その子供とあらあらしく結合することでした

それが露呈した直後に押入れ充電でやる気満々
日付が変わった直後に2時間だけ家宅(このスレ)捜索で荒らし回り
隆盛(たかもり)くんが居ないと判って退散したようです

でも痴呆だからまた結合しようと来るだろうな
432Socket774:2010/05/09(日) 06:25:24 ID:QE7Pds54
>>428
4GHzで出ると素敵。
433,,・´∀`・,,)っ-○○○:2010/05/09(日) 06:45:48 ID:sNWFFdis
>>425
Vector PathとDirect Pathは排他だから同時に動くことはないよ。



>>427
> それってつまり、2コア(モジュール)換算だと 6命令から4命令に減るのはリソース0.66倍とかの次元じゃないってことになるよね

お前は何を言ってるんだ(AAry
1つの命令ストリームから6命令同時に取り出してデコードする必要はないので6命令という数字に意味はない。
問題は、1命令ストリームから4命令/clkを取り出してデコードできるかということ。

もしそうならリソースは指数グラフとはいわないまでも単純に1.33倍よりは確実に増えるし、
3命令×2コアよりリソースが減るとも言い切れない。
その理屈が解らないなら何も言うことはないよ。

何度も言うけど、固定長命令じゃないのよ


>>429
コンパイラの吐かないプリフィックスの処理がどうこうなんて手動でアセンブる変態を除けば全く関係のない問題だ
後藤は頓珍漢だな
434Socket774:2010/05/09(日) 07:00:21 ID:OpoHju9O
既に60レスもつけてる奴も大概だがな
435Socket774:2010/05/09(日) 07:07:09 ID:01tAcw2H
ああそうか
>380に串止められたせいで日付変わるまで出て来れなかったわけか

んで出て来た途端に>420
>コアあたりX3だったのがX2

>K10の4コアよりBulldozerの8コア

「K10の4*3よりBullの8*2のほうが少ないという結論とは直結しないよね」

相変わらず脳味噌腐ってますな
12より16のほうが多いのは当たり前

このスレには気持ち悪いホモのゴキブリと結合したがってる少年など居ない
さあ早くヘドロの中に帰るんだ
死んでくれるならそのほうが嬉しいけど
436,,・´∀`・,,)っ-○○○:2010/05/09(日) 07:10:00 ID:sNWFFdis
まだ串とかいってるのか
妄想きわまれり
437Socket774:2010/05/09(日) 07:10:52 ID:01tAcw2H
訂正
人間なら脳味噌は普通に在るけど
こいつは普通に無いかもしれない
無いものは腐っても居ないもんな
438Socket774:2010/05/09(日) 07:15:56 ID:bD5bYP2w
日付が変わるまで名無しで頑張ってたもんな
439Socket774:2010/05/09(日) 07:37:39 ID:W3wbkZZe
bulldozerのデコーダッテ>>429で複雑になりすぎて効率が悪いからintel,centaurがやらないって言ってる
4x complex decoderなのかね?

nehalemでさえ1 comp,3x simpleなのだろ?
440,,・´∀`・,,)っ-○○○:2010/05/09(日) 08:07:53 ID:sNWFFdis
たとえば4バイト固定長の命令セットなら、4並列デコードはそんなに大きな問題じゃないんだよ。

  デコーダ1:IP
  デコーダ2:IP+4
  デコーダ3:IP+8
  デコーダ4:IP+12
  次のサイクル:IP←IP+16

ところが可変長だと命令の末尾が確定できなければ次の命令の頭出しはできない
AMDのアーキテクチャはL1Iにフェッチする時点で命令長検出を事前にやってしまうことで
デコーダの負担を多少減らしてはいるが、やっぱり固定長と同等とはいかない。

事前に命令長情報がある場合は、命令の頭出しはこんな感じになる

  デコーダ1:IP
  デコーダ2: IP + inst1.length
  デコーダ3: IP + inst1.length + inst2.length
  次のサイクル:IP ← IP + inst1.length + inst2.length + inst3.length

んで、これが4命令同時デコードになるとこうなる

  デコーダ1:IP
  デコーダ2: IP + inst1.length
  デコーダ3: IP + inst1.length + inst2.length
  デコーダ4: IP + inst1.length + inst2.length + inst3.length
  次のサイクル:IP + inst1.length + inst2.length + inst3.length + inst4.length

これを文字通り1サイクルで完結させないといけない。
それに耐えうる高速駆動の加算回路が必要になる。1.33倍のリソース増大とは言えないってのはそういうこと。
生のポインタをプリデコードタグにいれておけばいい?それはそれでキャッシュやフロントエンドが大変なことになる。

いっぽうIntel伝統のプリデコード方式は生の命令ストリームを投機的に並列スキャンして
命令長の確定時点で頭出し失敗したものを破棄する。
命令フェッチ帯域分のスキャナが必要になるので一見AMDより高コストに見えるが、頭出し処理を
1ステージで完結させる必要がないのでかえってやりやすい面もある。
441Socket774:2010/05/09(日) 08:14:39 ID:ZUNJOSb6
たとえば まで読んだ
442,,・´∀`・,,)っ-○○○:2010/05/09(日) 08:34:24 ID:sNWFFdis
>>439
実際問題μCode ROM参照が必要なデコード処理だとどのみちμOPsが増大するので4並列でやる意味ってあんまりないんだよね。
初代PPro〜Pen3でネックだったメモリロード+論理算術演算の命令はSimple Decoderでも1サイクルで処理できるようになってる


普通に考えればVectorPath 1→4は不可解だよね。
AVXをDirectPathで処理する余裕がないので仕方なくDirectPathを増やしたという説
K7でSSEが極端に遅かった問題の二の轍を踏まないためにはそのくらいは必要なのかもね。
256ビット命令なら少なくとも2μOPsに分解する必要があるからね
443,,・´∀`・,,)っ-○○○:2010/05/09(日) 08:35:33 ID:sNWFFdis
×AVXをDirectPathで処理する余裕がないので仕方なくDirectPathを増やしたという説
○AVXをDirectPathで処理する余裕がないので仕方なくVectorPathを増やしたという説
444Socket774:2010/05/09(日) 08:36:51 ID:cJm7fWt2
だんごもずいぶんメッキが剥がれてきたな、地が見えまくってる
キャラ設定が破綻しかかってるし、これはもう限界だな
445Socket774:2010/05/09(日) 08:36:52 ID:OpoHju9O
糞長い長文垂れ流してるが結局インテル最高しか言ってないんだよなこいつ
446Socket774:2010/05/09(日) 08:44:25 ID:01tAcw2H
デコーダはかなり謎だな
ttp://www.life-lab.com/amd-lab/amd686.html
ではショート・ロング・ベクタの3種あるとしている
P6はショートが3つでK7はロングが3つ、ネトバもロングだけだそうで

Bullが「全部出来るデコーダ4つ」ってのも過去ログで一度だけ出た噂を
ショタホモウンコカブリが火病って連呼してるだけなんじゃないか?
まだ詳しいソース出てなさそう

シングルスレッドで完全4デコード
マルチで0〜4(普段は2)柔軟に出来たらそりゃ凄いけどな
447Socket774:2010/05/09(日) 08:46:59 ID:QoPLw0jh
448Socket774:2010/05/09(日) 08:47:20 ID:01tAcw2H
Xネトバもロングだけ
Oネトバもショートが無い
449Socket774:2010/05/09(日) 08:48:53 ID:NbOywkg4
団子…完全にキャラがテヘに戻っているなw
450Socket774:2010/05/09(日) 08:52:03 ID:F/OnfXRk
一生懸命長文書いても「Intel最高!」とだけ書いてもまるで同じ扱いしか受けないなんて可哀想
451Socket774:2010/05/09(日) 08:53:08 ID:ZUNJOSb6
結局のところ、団子ってテヘなの?
452Socket774:2010/05/09(日) 08:54:37 ID:xOdSleUQ
やってることは同じだなw
453,,・´∀`・,,)っ-○○○:2010/05/09(日) 08:55:14 ID:sNWFFdis
ごめん、K10の時点でVector Pathも3mops/clkか


いや、おまいらが不愉快なのはわかってるよ
反論できることなんて何も無いから人格攻撃を逃げ道にしてるのも
454Socket774:2010/05/09(日) 08:58:59 ID:xOdSleUQ
反論できることなんて何も無いから人格攻撃を逃げ道にしてるのも

都合の悪いことにも答えてから言ってみろよw
アホすぎるなこいつはw
455,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:01:58 ID:sNWFFdis
>都合の悪いことにも答えてから言ってみろよw

こっちの台詞だ
456Socket774:2010/05/09(日) 09:03:35 ID:ZUNJOSb6
何にせよintelマンセーを叫びたいだけならスレチだな。
457Socket774:2010/05/09(日) 09:07:48 ID:bD5bYP2w
得意の串が使えないのはつらいな団子
458Socket774:2010/05/09(日) 09:08:56 ID:01tAcw2H
こいつはいつも「intelマンセー」より「自分マンセー」だし
今この瞬間は何より「隆盛(たかもり)くんケツマンコー」だぞ
ああきもい
459,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:09:41 ID:sNWFFdis
「マンセー」って言ってるようにしか聞こえない人と会話は成立しないな

去年の12月頃はまだBulldozer擁護にまわってたが情報が公開されるにつれ流石に擁護できなくなった。
>>381がSCCを引き合いに出してるがAMD版SCCってのはある意味正解なのかも(製品化できるレベルでないという意味で)
460Socket774:2010/05/09(日) 09:18:42 ID:11yf3rYo
いい隔離スレだこと
461,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:20:46 ID:sNWFFdis
そそ、アホが火病ってるのを見るのが好きだ
理屈に感情論で返したらその時点で既に負けですよ
462Socket774:2010/05/09(日) 09:25:05 ID:w5eAFKdA
Bulldozerって、モジュール内の2個のコアのうち、片方のコアだけクロックを変えたり止めたり出来るのかね
463Socket774:2010/05/09(日) 09:26:58 ID:bD5bYP2w
>>408ですでに団子さんの負けですやん
464Socket774:2010/05/09(日) 09:34:21 ID:ZUNJOSb6
取り合えず現状として団子は存在自体がこのスレに対してスレ違いと言う事は分かった。
465,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:34:23 ID:sNWFFdis
理屈で返してるじゃん何か問題でも?
466Socket774:2010/05/09(日) 09:38:05 ID:xOdSleUQ
団子は存在自体がこのスレに対してスレ違い

日本語が理解できない馬鹿だから張り付いてる
馬鹿は救いがないよなw
467,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:39:29 ID:sNWFFdis
俺の指摘に対して未だに技術的反論が出来ない君はこのスレに必要ないよ
468Socket774:2010/05/09(日) 09:39:39 ID:01tAcw2H
4*3<8*2つまり12<16が算数の世界で確定事項だということをいい加減解れ
469Socket774:2010/05/09(日) 09:43:01 ID:bD5bYP2w
昨日はなぜかVIAを持ち上げてたし、むちゃくちゃだぞ団子
470Socket774:2010/05/09(日) 09:43:07 ID:01tAcw2H
いや
理解しなくていい
明らかに不可能なことを言うつもりは無い
でもせめて  覚  え  ろ
471,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:43:53 ID:sNWFFdis
現実はこうだけどね
消費電力:Barcelona 4コア≒Nehalem 4コア
スループット:Barcelona 8コア≒Nehalem 4コア
472,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:44:42 ID:sNWFFdis
>>469
いつどこでVIAを持ち上げた?
473Socket774:2010/05/09(日) 09:44:44 ID:F/OnfXRk
>>467
せっかくの知識なんだからもう少し役に立ててみない?煽り以外でさ
無駄に刺々しく客観性にかけるような物言いを直せば相手も黙るだろうに
内容にも十分な説得力があれば、という前提はあるけどさ
474,,・´∀`・,,)っ-○○○:2010/05/09(日) 09:52:46 ID:sNWFFdis
Intelコンパイラだから速いんだと言ってた人にエサあげる。
Xeonは純正コンパイラ入ってないとこんな悲惨な結果www

Sun Microsystems
Sun Blade X6275 (Intel Xeon X5570 2.93GHz)
Compiler: Sun Studio 12 Update 1 (internal build 39.0)
SPECintR_rate2006 = 253
SPECint_rate_base2006 = 238
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090414-07079.html

Sun Microsystems
Sun Blade X6440 (AMD Opteron 8389 2.9GHz)
Compiler: PGI Server Complete Version 8.0 x86 Open64 4.2.2 Compiler Suite (from AMD) ←AMD純正
SPECintR_rate2006 = 292
SPECint_rate_base2006 = 226
http://www.spec.org/cpu2006/results/res2009q3/cpu2006-20090914-08593.html
475Socket774:2010/05/09(日) 10:02:23 ID:ZUNJOSb6
>>473
見ての通り、ここは団子にとって知識をひけらかしたいマスターベーションの場になっているから、そう言った制限を
掛ける事は多分無理だと思う
476Socket774:2010/05/09(日) 10:14:24 ID:01tAcw2H
バグ満載コピペという撒き餌で隆盛(たかもり)くんをおびき寄せてウホろうというハッテンバだな
ここには居ないんだから釣れるわけ無いんだが
477Socket774:2010/05/09(日) 10:20:55 ID:FvaKuw+6
死体撃ちやめろよ団子
478Socket774:2010/05/09(日) 10:52:51 ID:vbuYv/b0
権田(団子)の言動を見ていると現時点ではAMD>Intelだということか…。

ここ最近の権田のファビョり具合はプレスコがアス64にフルボッコにされていた時代の権田を思い出すわ。
479,,・´∀`・,,)っ-○○○:2010/05/09(日) 10:53:51 ID:sNWFFdis
そうだねOpteronにXeonが惨敗だね>>474
480Socket774:2010/05/09(日) 10:54:13 ID:xOdSleUQ
>>473
人間性の問題だから無理だよw
わざわざ嬉々として煽りに来る時点で終わってるだろw
481Socket774:2010/05/09(日) 10:57:07 ID:bD5bYP2w
http://www.stickam.jp/
団子の大好きなDX11の解説中
482Socket774:2010/05/09(日) 11:22:06 ID:pG1a4J5P
>>478
行動がシンプルだから分かりやすい
483Socket774:2010/05/09(日) 11:23:38 ID:l6fCSp2G
>>479
そうだね確かに惨敗だねw
http://h2np.net/pi/pi_thread.html
484,,・´∀`・,,)っ-○○○:2010/05/09(日) 11:38:25 ID:sNWFFdis
> このページは円周率4万桁を並列アルゴリズムbbp法で計算した時のランキングです。

4万桁なんてAtomでも1秒かからない処理を遅いアルゴリズムで解くんですねわかります
485Socket774:2010/05/09(日) 11:46:27 ID:ZUNJOSb6
いいからAMDの次世代CPUに付いて語れや
486Socket774:2010/05/09(日) 11:49:27 ID:oJi8aMfW
ttp://xs.to/image-6568_4BE6210E.jpg
ttp://xs.to/image-A04C_4BE6210E.jpg

396 :Socket774 [↓] :2010/05/08(土) 20:23:52 ID:awUi9idF
3 ALUのk8と2 ALUのnanoで差がないから
ブルも差がないだろう

あ、でもnanoのALU2は分岐命令と単純命令だけだから1.5 ALUってとこか


401 :Socket774 [↓] :2010/05/08(土) 21:00:54 ID:awUi9idF
nano-eでは更に2-3割りパフォーマンスが上がる
487Socket774:2010/05/09(日) 11:50:34 ID:MuIc33S6
本末転倒な寝言
488Socket774:2010/05/09(日) 11:52:57 ID:cMUbIq3U
>>474
> Compiler: Sun Studio 12 Update 1 (internal build 39.0)

リンク先には
Compiler: Intel C++ and Fortran Compiler 11.0 for Linux Build 20080930
と書いてあるが?
489Socket774:2010/05/09(日) 11:58:02 ID:OpoHju9O
484 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2010/05/09(日) 11:38:25 ID:sNWFFdis (24回)
 > このページは円周率4万桁を並列アルゴリズムbbp法で計算した時のランキングです。
 4万桁なんてAtomでも1秒かからない処理を遅いアルゴリズムで解くんですねわかります

superπだって糞遅いソフトだよな、あんなゴミ計算でCPUの性能語ってる奴らって馬鹿なんだよなw
490Socket774:2010/05/09(日) 11:58:04 ID:l6fCSp2G
>>484
また自分の都合に良い部分だけ切り出してファビョてますね…。それともこのベンチの趣旨が本気で解らないとか?

まぁ今更>>483のペンチをあえて持ち出したのは団子の行為を真似させてもらっただけだけどねw
つまり自分にとって都合のよい結果だけを厳選してカキコする行為をね。

要するに>>483の否定は自分自身の行動を否定しているという事だよ。わかる?
491Socket774:2010/05/09(日) 12:01:56 ID:bD5bYP2w
http://www.4gamer.net/games/107/G010710/20100317030/

>ゲームプログラムをIntel HD Graphicsに最適化してほしい

  \\_
:三ニ=:::::::ヽ
:ヽ.ニ=::て.>廴_
三.ヽ= (⌒ヽ;:;:;,.二)
ニ=-ヽ:ヽ、,∠.^^ぅ  ダメだ。その願いは神龍の力を超えている。
〃,べ= ̄ニ二 ̄
/;:ィリ ノノ ,.へヽ
;:ヘ/ ̄ ̄ ̄Vヽヽ
ソ        ├┤|
492Socket774:2010/05/09(日) 12:06:23 ID:Yr7mfo0l
>>433
> 3命令×2コアよりリソースが減るとも言い切れない。
> その理屈が解らないなら何も言うことはないよ。
要は4命令/clkと3命令/clk*2のどっちが効率いいかって話だよね
で、Bulldozerの場合、(2命令*2)/clkで動かすことも想定してそうだ

それだけの話しで何でこんな騒いでるんだ団子は
493Socket774:2010/05/09(日) 12:14:32 ID:VFBA5r+Q
>>492
前提条件が「AMDを貶めること」だから。
494,,・´∀`・,,)っ-○○○:2010/05/09(日) 12:27:22 ID:sNWFFdis
>>490
もちろん意義ならないな。
アルゴリズムに有用性があれば性能評価としては非常に参考になるがクソ役にも立たん
HPCの世界では性能でハードウェアを選ぶようにソフトウェア・ライブラリも選ぶのだよ。
つかGMPの300万桁の方も見たけど動作クロック報告がないのでどうとも言い難い

こんないい加減なベンチを権威あるSPECと同レベルで語ること自体が烏滸がましいね。

参考までに俺はSuperPIの性能で優劣つけたことは一度もないぞ
お前が同一人物だと勘違いしてるクソテヘのことなら知らん


>>488
釣られたついでにこれも見てね
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090413-07022.html

あと、何故か16コアでの結果があるから。同じOpteronの16コアと見比べて見ようね
http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090413-07024.html

つうかそもそもDPで4ソケットなんてIntelがサポートしてない筈なんだが
Sunがどんな構成とったのか気になる

そもそもSunとIntelでコンパイラ性能にそんなに大差はないよ
http://blogs.sun.com/keiichio/entry/sunstudio12u1_osol_speccpu2006


>>492
> で、Bulldozerの場合、(2命令*2)/clkで動かすことも想定してそうだ
当 た り 前 だ
2命令×2ならそもそもフロントエンドを共用にする意味がないだろ。
共用するメリットを生かす、たとえば1スレッドで4命令/clkもできるような構成をとるなら
ハードはそういう風に設計にしないといけない。

その上で>>440を読み直してくれ。実装コストが一気に上がるのがわかる。
本気で頭が悪い子だね君は。
495Socket774:2010/05/09(日) 12:33:27 ID:bD5bYP2w
理屈に感情論で返したらその時点で既に負けですよ
496,,・´∀`・,,)っ-○○○:2010/05/09(日) 12:34:49 ID:sNWFFdis
彼が頭が悪いのは客観的事実ですので
497Socket774:2010/05/09(日) 12:36:40 ID:LVGcUQqi
どう考えてもテヘ=団子でしょw 行動パターン、言動がまるっきり同じ。

仮に同一人物ではないとしてもテヘの劣化コピーに変わりないしw
498Socket774:2010/05/09(日) 12:38:20 ID:cJm7fWt2
でもテヘ的にはだんごは鉄壁のインテリキャラなんだぜ?
499,,・´∀`・,,)っ-○○○:2010/05/09(日) 12:38:55 ID:sNWFFdis
【ここまでのまとめ】
CPUの温度センサーで強制クロックダウンする機構をMagny-Coursの「省電力技術」に応用したAMDは凄い
500Socket774:2010/05/09(日) 12:39:40 ID:VFBA5r+Q
>>498
そんな設定だったんだ。完全にキャラ設定を崩しちゃった感じだな。
501Socket774:2010/05/09(日) 12:52:11 ID:pG1a4J5P
キャラ立ては難しい
502Socket774:2010/05/09(日) 12:56:56 ID:Yr7mfo0l
>>494
ちょいと反論というか気になった点

> それに耐えうる高速駆動の加算回路が必要になる。1.33倍のリソース増大とは言えないってのはそういうこと。
3命令→4命令で増大するのは分かる
問題は3命令*2から4命令*1で増大するかどうかだな
3命令のリソースを1としたとき、4命令で1.33、3命令*2で2なら余裕でリソース削減の効果はあるだろ。

>
> いっぽうIntel伝統のプリデコード方式は生の命令ストリームを投機的に並列スキャンして
> 命令長の確定時点で頭出し失敗したものを破棄する。
> 命令フェッチ帯域分のスキャナが必要になるので一見AMDより高コストに見えるが、頭出し処理を
> 1ステージで完結させる必要がないのでかえってやりやすい面もある。
503Socket774:2010/05/09(日) 12:59:53 ID:Yr7mfo0l
>>499
それは安全性確保の上で必要な機能だろ?
どちらかというと遅すぎた実装だね
サーバーやHPC向けで対応してないCPUなんかないだろ(知らんけど)
504,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:07:32 ID:sNWFFdis
はいはい、要するに読んでないのね。

次の4命令までに4つの命令の長さを加算しないといけないのがどれだけ重大かもわからないのね。
3命令なら2回分で済んだので2倍速程度の加算機があれば十分だったが4命令だと3倍速が必要になる。
実際にはプリデコードビットから命令長情報を展開するのすらゼロコストではない。

それともBulldozerはプリデコードキャッシュ辞めるんだっけ?
投機的な命令頭出しをやる場合はパイプライン段数は増えるが1ステージの負担は多少軽くなるかもね。
505,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:08:40 ID:sNWFFdis
>>503
フェイルセーフのためではなくなぜか「省電力技術」なのが味噌です
506Socket774:2010/05/09(日) 13:09:24 ID:Yr7mfo0l
Bulldozerアーキテクチャの肝は、3命令*2から4命令(2命令*2)*1に変更したことによる効率向上は間違いない
デコーダーが小さくなれば、以降のパイプラインや内部バスも規模が小さくなり
単純に考えるとスレッド辺のコストが約0.7倍、あるいは効率が1.33倍になる
507Socket774:2010/05/09(日) 13:12:35 ID:Yr7mfo0l
>>504
3命令や4命令なんてたまにしかない程度の頻度だろ?
大部分は2命令って話をよく聞くから、4命令時で多少効率が悪いとかはどうでもいいよ

Bullで重要なのは(2命令*2)/clkの方だと思うが違うのかな?
508,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:14:12 ID:sNWFFdis
やっぱり馬鹿だな
ピークに合わせて回路設計は行われるんだよ
509Socket774:2010/05/09(日) 13:15:37 ID:XFfvmGjJ
うん、507はアホ過ぎるw
510Socket774:2010/05/09(日) 13:17:06 ID:1gpmYjsI
Opスレに6176SE買った人いるからフルロードでクロックが下がるか試してもらえばいい

正しくクーラーが稼動していればダウンクロックするとは思えんが
511Socket774:2010/05/09(日) 13:17:28 ID:Yr7mfo0l
>>505
リードミスか説明ミスかは知らんが実質フェイルセーフ機能だろ
そこまで騒ぐほどのもんでもないよ
適切な冷却していて高負荷でクロックダウンとか企画段階で不採用機能だろ
そもそもIBMやHP、Cray辺りがそんなクソ機能許すはずはないな
512,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:24:37 ID:sNWFFdis
>>440に当てはめると3命令の場合たとえば

【最初のサイクル】
v1 = IP + inst1
v2 = inst2 + inst3

【次のサイクル】
IP = v1 + v2

で2サイクル。
これを1クロックで済ますには少なくとも2倍速で動かさないといけない。
もし4命令/clkになると3サイクル必要なので、更に高速化が必要。
更に命令ポインタ加算ユニットの高速化が必要になる。

命令の頭出しという単純な前処理ですらここまで圧倒的な高コストが強いられるのに、
単純にデコーダの総和だけでしかものを考えられないのって本当に馬鹿としかいいようがない。

これでまだ解らなければ小学校からやり直すべきだよ。
513Socket774:2010/05/09(日) 13:27:47 ID:1jiAwlXq
>>510
俺もそう思う。
ひょっとしてAMDはヒートシンクレスを目指しているのか?
514Socket774:2010/05/09(日) 13:29:48 ID:Yr7mfo0l
>>508
お前が馬鹿だろ?
ピーク重視なら従来の3命令*2か共有で6命令、あるいは強化して4命令*2とかにすればいいだけ
2pipeの2コアで共有の4命令/clkデコードなんて、どう見ても実性能の2命令*2を重視している

命令の頻度でいうと
2命令:8〜9割
3命令:1割程度
4命令:数%
って気もするから恐らく全体の1割程度の3や4命令のピーク時の性能は切り捨てたとも言えそうだね。
どの道命令Pipelineが2本しか無いから、4命令なんて2パスで処理するしかなくて性能出せないけどね。
515Socket774:2010/05/09(日) 13:32:16 ID:PscwQLrB
フルロードで簡単にクロックが下がるのなら
ベンチの途中で不自然なパフォーマンスダウンをしたりとか、
クロックが落ちたという報告があってもいいと思うけどな。
516Socket774:2010/05/09(日) 13:33:33 ID:w5eAFKdA
SIMDユニットは共有なんだからデコーダは完全には独立させられないだろう
だから4命令発行のデコーダと表現されているだけで
デコーダのコア1/コア2への命令発行の振り分けは1:3、2:2、3:1程度で
片方のコアに対し4個の命令を同時発行は想定していないんじゃないの
517,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:34:57 ID:sNWFFdis
ならなんでデコーダが共有なの?
お前の詭弁通りなら2命令/clkのデコーダを1コアずつで十分じゃないか
518,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:36:34 ID:sNWFFdis
>>516
ようやくまともな意見が出た。

まあ、バックエンドの細さ考えればその程度で十分だと思うよ。
519Socket774:2010/05/09(日) 13:37:16 ID:Yr7mfo0l
>>512

> で2サイクル。
> これを1クロックで済ますには少なくとも2倍速で動かさないといけない。
> もし4命令/clkになると3サイクル必要なので、更に高速化が必要。
> 更に命令ポインタ加算ユニットの高速化が必要になる。
>
> 命令の頭出しという単純な前処理ですらここまで圧倒的な高コストが強いられるのに、
> 単純にデコーダの総和だけでしかものを考えられないのって本当に馬鹿としかいいようがない。

俺の考えじゃ頻度の少ない3や4命令は2パスとかで十分
お前は頻度が少ない4命令も1パスで処理する
話が噛み合ってないのは、効率重視とピーク重視の違いってことなんだな
そりゃ、前提が違えば噛みあうはずも無い
520Socket774:2010/05/09(日) 13:39:35 ID:xs1JExK7
Jcc+CMPのMacro Fusionが2スレッド同時に
できればピークは6命令/cycleになるのか?
521Socket774:2010/05/09(日) 13:40:06 ID:Yr7mfo0l
>>517
> ならなんでデコーダが共有なの?
> お前の詭弁通りなら2命令/clkのデコーダを1コアずつで十分じゃないか
共有の方が効率よさそうだし、極稀に出てくる3命令や4命令を1clkでデコードするためだろ?
それくらい分かれよ
522,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:40:42 ID:sNWFFdis
>SIMDユニットは共有なんだからデコーダは完全には独立させられないだろう

これは関係ないな。
デコーダが別でも演算ユニットは共有できるし実際にそういう製品は存在する。
523Socket774:2010/05/09(日) 13:41:06 ID:/ju9rie7
>>515
そんな事例聞いたこと無いな。毎度の嘘だろ。
524Socket774:2010/05/09(日) 13:41:19 ID:Yr7mfo0l
>>518
> >>516
> ようやくまともな意見が出た。
>
> まあ、バックエンドの細さ考えればその程度で十分だと思うよ。
バックエンドの細さ無視してピーク性能で騒いでたお前が言うなww
525,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:41:58 ID:sNWFFdis
> 俺の考えじゃ頻度の少ない3や4命令は2パスとかで十分

アホだなやっぱり

2パスかかったら結局2命令/clkだろうが
526,,・´∀`・,,)っ-○○○:2010/05/09(日) 13:48:29 ID:sNWFFdis
>>523
そもそもピーク時にクロック降下するなんて誰も説明してない。
でもAMDも言ってるとおり「省電力技術」なんです
527Socket774:2010/05/09(日) 13:57:44 ID:01tAcw2H
キモホモはベクタデコーダ2*2(噂)に嫉妬火病するより
まず12<16を覚えるほうが先だろ
これからすぐ死ぬんなら何も努力しなくていいが
528Socket774:2010/05/09(日) 14:05:51 ID:Yr7mfo0l
>>525
お前がアホだろ
pipelineでの処理がだよ
デコーダーとpipelineがごっちゃでコメントした俺も悪いけどな

4命令時の動作
デコーダー:1clk
Pipeline:2パス

2命令時
デコーダー:1clkで2スレッド分
Pipeline:1パス
529Socket774:2010/05/09(日) 14:09:05 ID:Yr7mfo0l
>>526
最早そんなとこしか煽れないのかお前はw
だからどうしたのって話だな
結局は大手サーバーメーカーや顧客がマニクール採用しているから実質問題無い機能ってことだろ
530Socket774:2010/05/09(日) 14:13:13 ID:01tAcw2H
デコードの件は複雑だしあまり知らないんだけど
AMDK7系はプリデコードで命令に区切り付けたものをL1Iに入れてるんじゃなかったっけ?
次にデコーダでMacro何やらに変えて
スケジューラでμに分解という3段階のデコード

食糞ホモはIntelのデコードの件をバグコピペしてる気もする
531Socket774:2010/05/09(日) 14:20:09 ID:xS4vqfAa
プリデコーダに複雑さを移すだけで、問題はあんまり解決されないんじゃないの?
530の考え方だと。
532Socket774:2010/05/09(日) 14:25:30 ID:01tAcw2H
キャッシュだぞ?L1Iって
533,,・´∀`・,,)っ-○○○:2010/05/09(日) 15:10:59 ID:sNWFFdis
>>528
あーやっぱり解ってないな

まあいいや
どう>>440のモデルに基づいてどうやってパイプライン処理するのか説明願おう
534Socket774:2010/05/09(日) 15:36:02 ID:MuIc33S6
整合性が無さ過ぎる
535Socket774:2010/05/09(日) 15:41:37 ID:Yr7mfo0l
>>533
いや、だからさ、4命令時の処理なんかどうでもいいんだよ
速かろうが遅かろうが総合的な処理性能に与えるインパクトはたいしたことが無いからな
お前がなんで4命令処理に拘るのが分らん

>>518
でもお前自身が言ってるだろ?
Pipelineが貧弱だから1:3、2:2、3:1程度で十分だって。
536Socket774:2010/05/09(日) 15:47:36 ID:OpoHju9O
ここまで偉そうに俺様間違いない絶対だ理論ぶちかませるんならインテルでもAMDでも入社しててめーでCPU作れよって話だよな。
537,,・´∀`・,,)っ-○○○:2010/05/09(日) 15:49:29 ID:sNWFFdis
何が面白いって>>440で既に

> ところが可変長だと命令の末尾が確定できなければ次の命令の頭出しはできない

に釘さしてるのに「2パス」で処理するとか言ってることだよねwww
しかも

> 4命令時の動作
> デコーダー:1clk
> Pipeline:2パス
>
> 2命令時
> デコーダー:1clkで2スレッド分
> Pipeline:1パス

スレッドの利用状況によって【パイプライン段数】が変わるとか
どんなアーキテクチャだよっていう
そのステージ数が動的に変わる機構だけで軽くリソース増加しちゃいそう
538Socket774:2010/05/09(日) 15:59:33 ID:01tAcw2H
>440をちゃんと読んでみるとすげーな
以前ウンコは「プリデコードでほぼデコード完了」などと言ってたのに
今度は「デコーダがプリデコーダまでする必要がある」って

プリデコード+デコードを2回連続でしなきゃならない理由は「たまにPentium4にはL1Dが無い」からですか?
539Socket774:2010/05/09(日) 16:03:58 ID:01tAcw2H
X「デコーダがプリデコーダまでする必要がある」
O「デコーダがプリデコードまでする必要がある」
もしくは「デコーダがプリデコーダまで兼任する必要がある」
540Socket774:2010/05/09(日) 16:03:59 ID:kJfVmt97
>>536
妄想だけなら誰にでもできるレベル。
あと理論だけでは実践は無理。
541,,・´∀`・,,)っ-○○○:2010/05/09(日) 16:05:03 ID:sNWFFdis
> いや、だからさ、4命令時の処理なんかどうでもいいんだよ

どうでもよくないよw

どこの陣営もクロックサイクル単位でスレッドの命令ストリームを切り替えてフェッチする機構を採用してるよ。
AMDは違うの?

そもそも同じサイクルに2つの命令ストリームを同時にフェッチすること前提で語ってるけど
そんな機構自体コスト高いよ。
常識的に考えて同じ命令列から3命令ないし4命令を同時にピックする必要がある。


2つの命令列が「同時処理」されるのはアウトオブオーダ実行によるもので
デコード後の話。
542Socket774:2010/05/09(日) 16:14:03 ID:Yr7mfo0l
>>537
俺って素人だからうまく説明出来てないんだな、そこはあやまるよ

2パスって言ってたのは、2回に分けてPipelineに流すってこと。
ABCDって命令があったら、ABを流した後にCDを流すってね
何も難しいこと言ってないしリソースだって食わないと思うが違うのかね

>>535でも言ったけど3命令や4命令時の動作なんか遅くても効率悪くてもどうでもいいんだ
Bullのデコーダーやpipeの構造からして2命令処理以外は遅くても仕方ないよねって感じだし
543Socket774:2010/05/09(日) 16:15:16 ID:01tAcw2H
「2つの命令列(何これパイプライン?)」はスーパースカラによるもの
アウトオブオーダは1つの命令列での処理順序が逆(データロード完了順)になるもの

とはいえこれは現実世界の話
ウンコとショタが食料な世界のことは知りません

あとついでに
>538
△プリデコード+デコードを2回連続で
Oプリデコード+デコードを2回ずつ交互に
544Socket774:2010/05/09(日) 16:23:45 ID:Yr7mfo0l
3命令や4命令の発生頻度はどんなもんなのかね
個人的には>>514 みたいに全体の1割程度って予想してるんだが
ググッてもあまり無いというような抽象的な説明しか見かけない

後藤氏のコラムでも
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20100205_346902.html

現在のPC向けCPUの3〜4 x86命令デコード&実行のパイプラインは、
実際にはオーバーキルなケースがある。
メモリに制約がある現状では、命令間の依存性のために、
x86 命令換算で2命令程度しか並列実行できないケースが少なくない。
uOPに砕いて実行する場合でも同じで、3〜4 x86命令の並列実行帯域は、
あくまでもピークであり、平均はそれよりかなり少ないというのが常識だという。

ってことで平均は2に近いらしい事を言ってる。

是非とも団子の見解を教えてくれ
545,,・´∀`・,,)っ-○○○:2010/05/09(日) 16:26:43 ID:sNWFFdis
結論から言うと実は同じサイクルに2つの命令列を同時にピックする機構を設ける方がコストあがる。
固定長命令ならフェッチユニットを2重化して、スレッドAから12バイト、スレッドBから4バイトを
フェッチすれば3:1の割合で取り出すことができる。

しかし、そもそもx86は同じバイト数に何命令入ってるか解析するまで解らない。
同じ32バイトをフェッチしても1バイト命令が32個入ってる場合もあるし、
長い命令が3命令しか入ってない場合もありうる。
したがって、同じサイクルでAから2命令、Bから2命令みたいな割合で綺麗に取り出せるようなエスパーCPUは作りようがない。

できるのは奇数サイクルでAから32バイト、偶数サイクルでBから32バイトみたいな取り出し方だけ。
あとは命令の処理状況に応じてサイクルの割り当てが変わるだけ。
546,,・´∀`・,,)っ-○○○:2010/05/09(日) 16:32:10 ID:sNWFFdis
3行でまとめると

そもそも2命令:2命令とか3命令:1命令なんていうパーティショニングは不可能なんだ。
できるのはサイクル単位でスレッドAに4命令か、スレッドBに4命令か、だけ。
同じサイクルに別々のスレッドの命令が混在するはデコーダより後のステージで、どこのCPUのSMTでも同じ
547Socket774:2010/05/09(日) 16:36:53 ID:01tAcw2H
ID:Yr7mfo0lのレスちゃんと読んでないのにアレだけど
一応言っとくと「ベクタデコーダ使うような長い命令の連続度(4命令がどうのこうの)並列デコード」と
「実行パイプライン・スーパースカラの並列度(ALU3つもイラネとかいうの)」は別物だぞ
全く内容かぶらない

それと食糞ID:sNWFFdisホモの発言は本当にムチャクチャ
548,,・´∀`・,,)っ-○○○:2010/05/09(日) 16:44:25 ID:sNWFFdis
むちゃくちゃの理由:「俺が気に入らないから」
549,,・´∀`・,,)っ-○○○:2010/05/09(日) 16:51:28 ID:sNWFFdis
というわけで、>>420の問いかけの答えは、「基本的に常に片方のスレッドに4命令」でしたとさ
実装次第ではハシタが出た場合にだけ同じサイクルに2つのスレッドの命令がデコードされる可能性もあるけどね。
550Socket774:2010/05/09(日) 16:56:32 ID:01tAcw2H
Bull8コア=4モジュール
4モジュールには4*4で16デコーダ
4*3<4*4で結局変わりませんが


いいからとっとと覚えろよ12<16を
551Socket774:2010/05/09(日) 17:02:05 ID:FvaKuw+6
546は正しいでしょ。
ていうか「えっそこから!?」ってのが正直なところだ。

ピーク4命令切り出せるデコーダは、2命令切り出すデコーダの
二倍の電力・トランジスタ数では到底収まらない。
それを2スレッドで共有すれば平均2命令しか切り出せないにも関わらず、だ。
Bulldozerのデコーダ共有は何かの妄想・誤解の産物だと思うが
デコーダだけ倍速駆動でもするつもりなのかねえ。
552Socket774:2010/05/09(日) 17:05:09 ID:qI6oRAXc
4命令発行のデコーダをA/Bのスレッドが交互に占有するぐらいなら
2命令発行のデコーダを2個用意して、それぞれをAとBのスレッドに割り当てた方がずっと良いんで無いの
553,,・´∀`・,,)っ-○○○:2010/05/09(日) 17:05:53 ID:sNWFFdis
>>551
なぜかパーティショニングできる前提で話してるからどういう論を展開してくれるか面白がってたのに
何かつまらん結論が出た。
554Socket774:2010/05/09(日) 17:08:42 ID:01tAcw2H
>>545
げえ・・・
「K7系(という括りでいいの?)はプリデコード済みの命令がL1Iに入ってる」
てことを未だに記憶できないのか
チラシの裏に100回書くなりなんなりしてとっとと全部覚えろよ
555Socket774:2010/05/09(日) 17:10:27 ID:kJfVmt97
>>552
その分デコーダ部分が肥大化する。
あと片方が詰まって片方が空いているときに無駄になる。
556Socket774:2010/05/09(日) 17:13:01 ID:FvaKuw+6
>>552
片方のスレッドがアイドルしてるケース(あるいはPOWER7のように休眠させるモードがある)ならば
4命令占有できて嬉しいかもしれない。でもデコーダから下は
1コアあたり平均2命令発行前提のリソース配分のようだから、やはり無意味だ。

>>555
4命令同時発行デコーダ×1は、
2命令同時発行デコーダ×2より、はるかに大きくなる。
557Socket774:2010/05/09(日) 17:21:18 ID:qI6oRAXc
>>556
コアAには2命令発行のデコーダーA
コアBには2命令発行のデコーダーB
モジュールとしては2命令発行デコーダ×2=4って意味ね
558Socket774:2010/05/09(日) 17:26:24 ID:01tAcw2H
「4並列デコードを交互にスレッド割り当て」と
「基本2*2で状況に応じて割合を変える」のどちらが複雑で規模がデカくなるかは判らない
しかし今までベクタデコーダ1つ(1/3)だったのに
いきなり4つ(4/4)は増え過ぎだ
そこまで長命令が続くのか
でも2*2 (2/2)ならまだ判る
ていうかComplex Decoder*4がまだ噂の域なわけだけど

どっちにしてもプリデコード済みの件が解らない奴には
「Intelに無い(Cotre2のループ専用キャッシュのみ)技術に嫉妬乙」という言葉掛ける以外無いわな
559Socket774:2010/05/09(日) 17:28:21 ID:7COft7iL
2命令ならalu,aguは各1個で十分では?
560,,・´∀`・,,)っ-○○○:2010/05/09(日) 17:32:37 ID:sNWFFdis
片側で2〜3命令、FPUが2命令分(ただしレジスタ間movapsのリダクション可能なので実質それ以上)ってところか
1スレッドだけで4命令の帯域使っても十分お釣りが来る
561Socket774:2010/05/09(日) 17:36:04 ID:Yr7mfo0l
>>546
突っ込ませてもらうと

>>516
コア1/コア2への命令発行の振り分けは1:3、2:2、3:1程度で
片方のコアに対し4個の命令を同時発行は想定していないんじゃないの
ってコメにお前は
>>518
バックエンドの細さ考えればその程度で十分だと思うよ。
って振り分けにも同意してたよな
これは勘違いか嘘ついたってことで
>>546の不可能ってのがお前の意見というか業界の常識ってことでいいんだな?

デコーダーの構造次第な気もするけどね
スレッド辺り2命令、2:2で振り分けることを前提にデコーダー作って、
3命令や4命令入っていた場合は、スレッドのデコードをし直すとかすればいいんじゃないかね

3命令や4命令が頻出する場合は低性能になるけど、それはよくあることなのかな
既存のアプリケーションや分野であったら教えてくれ
562Socket774:2010/05/09(日) 17:42:10 ID:Yr7mfo0l
>>556
> 4命令同時発行デコーダ×1は、
> 2命令同時発行デコーダ×2より、はるかに大きくなる。
そこが間違い
本来の議論は2スレッド処理において、
K10の3命令*2と、Bullの4命令*1のどちらが大きいかだ
団子もお前ももう少し流れ読め
563Socket774:2010/05/09(日) 17:47:44 ID:FvaKuw+6
ごめんね お母ちゃんタケシが何言いたいのかわからなくてごめんね
564,,・´∀`・,,)っ-○○○:2010/05/09(日) 17:49:53 ID:sNWFFdis
>これは勘違いか嘘ついたってことで

俺は相手の知識を確かめるために勘違いをわざと見逃すことがある。
知らないなら噛みついても意味ないだろ。

ちなみに
3命令/clkのフロントエンドと1命令/clk、という非対称なフロントエンドがあって
クロックサイクル毎に通すスレットを入れ替えることができる、
とかなら割と出来る気がするよ。



ちなみにいうとCoolSpeed(笑)についてもわざと混乱させる言い回しをしている。
これがなぜ省電力技術なのかは割と単純な理由で俺はドンピシャな答えは知ってて敢えて言ってない。
565Socket774:2010/05/09(日) 17:58:56 ID:01tAcw2H
何でいきなり雑音の真似?
566Socket774:2010/05/09(日) 18:10:39 ID:Yr7mfo0l
>>564
そんなどうでもいいことへのレスはホントどうでもいいんだ
嘘ついてごめんなさいの一言で済む話

>3命令/clkのフロントエンドと1命令/clk、という非対称なフロントエンドがあって
そんな何処にも存在しないモノの話なんかどうでもいいよ

>CoolSpeed(笑)についてもわざと混乱させる言い回しをしている。
混乱どころか誰も気にもしてないことをお前が馬鹿騒ぎしてるだけ。
文句いうならそれを了承して採用した大手サーバーメーカーに言えよ。

で、
K10の3命令*2と、Bullの4命令*1のどちらが大きいか、
スレッド辺りの3命令や4命令の頻度や、それらが頻発するようなソフトや分野
スレッド辺り2命令決め打ちで、2スレッド同時デコード出来るかどうか

について屁理屈はないのか?
567Socket774:2010/05/09(日) 18:12:10 ID:xOdSleUQ
俺は相手の知識を確かめるために勘違いをわざと見逃すことがある。

ここは笑うとこかw
568,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:19:07 ID:sNWFFdis
むしろパイプラインの構成要素ってデコーダだけじゃないんで
Decoderだけに拘っても意味がないと思うんだけどね。
乱暴な言い方をすればテーブル参照して対応するOpcodeに置き換えるだけの処理なんで
その個数だけを問題にされても全然本質じゃない。としか。

デコードそのものよりも1命令ストリームからデコーダの数分の命令を切り出す処理のほうがよっぽどコスト高い。
俺が今言ってるPickステージの実装コストなんてデコーダよりもよっぽど重要だよ。

あと、一般的なアウトオブオーダコアでDecoderのすぐ後くらいのステージにあるRenamerの話をすると、
その規模はパイプラインの並列度の2乗に比例して大きくなるね。
3^2 * 2 と 4^2 だと前者の方が僅かに大きいくらいか。
これの場合BulldozerはXOPに3ソースオペランド命令なんかも追加されてるので
K10の2コアよりBulldozerの1モジュールの実装コストが上がる要因はある。
569,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:21:11 ID:sNWFFdis
> 混乱どころか誰も気にもしてないことをお前が馬鹿騒ぎしてるだけ。

実装の目的が全く解ってないから気にしないようにしてるだけだろwww
素直になれよww
570,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:26:10 ID:sNWFFdis
クーラーが故障したときにP-Stateを強制的に下げるのを省電力技術とは言わないし
そもそもそんなことを目的としてない

今更だけど、AMDのサイトに書いてある英語も読めない奴らだらけなのか?
実はお前ら俺よりもAMD嫌いなんじゃないのか?
571Socket774:2010/05/09(日) 18:28:36 ID:BYuH90kJ
>>567
最強で人間として最低の言い訳でしかないな。
「後出しジャンケン無敵説」
572,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:32:22 ID:sNWFFdis
で、そのジャンケンの俺より先に出したのは誰だよ

あまりにお馬鹿な珍説しか出てこないから自分でミスリードして自分でネタばらししたわけだが
573Socket774:2010/05/09(日) 18:36:52 ID:01tAcw2H
L1I内で既にプリデコード済み
ダイサイズ等の無駄を気にしなければばりばりデコーダの数を増やせる恐ろしいAMD
でもIntelでもトレースキャッシュでそれより凄いのやってたんだよな
パイプラインはキャッシュから始まるからデコード関係全てを飛ばせる

でもPen4はデコーダが1つ(笑い)なので
その最初のトレースキャッシュに命令が溜まるのが遅く
普段から遅いのに初動が更に遅くなってしまう
というのが「もっさり」なのではなかろうか

逆にAMDはプリデコードを素早く済ませられるのでキビキビ
なんてことはないだろうか


串ウンコはそろそろ何か覚えたか?12<16は確定事項だからな忘れんなよ?
574Socket774:2010/05/09(日) 18:39:10 ID:xOdSleUQ
言い訳はもうたくさんw
恥の上塗りに気付よアホw
575,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:40:46 ID:sNWFFdis
>>545-546の説明を俺より先に出したのは一体誰だよww

俺のミスリードに騙された無知野郎が必死だなwww
576,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:44:09 ID:sNWFFdis
> 4命令時の動作
> デコーダー:1clk
> Pipeline:2パス
>
> 2命令時
> デコーダー:1clkで2スレッド分
> Pipeline:1パス

笑いすぎて飯がうまいなwwwwwwww
577Socket774:2010/05/09(日) 18:51:44 ID:xS4vqfAa
L1へのヒットに期待して、プリデコーダ部分はピーク4命令に対応できるだけの
供給能力はなくてもいってこと?
578Socket774:2010/05/09(日) 18:54:15 ID:1cld7LE8
Decoderで盛り上がっているのでおいらも素人予想してみる

あえて2 threadでdecoderを共有する構造なことを考えると、
複雑なdecoder+簡易なdecoderの組み合わせになっているのではないか。
たとえば3命令/cycle decoder+2命令/cycle decoderの組み合わせの場合。

1 threadの場合は常に3命令/cycleの方が使われてK10同等の性能。
2 threadの場合は交互に使えば2.5命令*2/cycle相当。
Cache missなどで片方が止まれば、生きているthreadの方を3命令/cycleで切り出しできるので、
実質的に3命令/cycle*2台に近い性能が期待できるかも。

Tr数に関しては、2命令/cycleのdecoderならかなり小さいはずだから、
3命令+2命令構成でも3命令decoder 1つと比べて1.5倍程度で済むんじゃないかな

こんな構成なら1.5倍の面積で1.8倍の性能というAMDの説明にも割と納得できる。

妄想乙>>オレ
579Socket774:2010/05/09(日) 18:55:22 ID:01tAcw2H
>>577
俺にっぽいけど
誰に質問してんだか判らん
580Socket774:2010/05/09(日) 18:57:29 ID:xS4vqfAa
>>579
安価ぬけてわるかった。
>>573についての質問。
581,,・´∀`・,,)っ-○○○:2010/05/09(日) 18:59:13 ID:sNWFFdis
>>578
申し訳ないが、デコーダのスループットはモジュール全体で4命令/clkって公式発表が既に出てるんだわ
582Socket774:2010/05/09(日) 19:11:37 ID:bD5bYP2w
好調じゃん団子。これなら串を駆使しなくていいな!
583Socket774:2010/05/09(日) 19:12:02 ID:01tAcw2H
>>580
パイプラインの連続した部分というのは
情報(命令)をすぐ次のリソースに流していかなければならないから連続している
でもキャッシュがあれば貯められる
パイプライン内でのリソース単位での能力の過不足はそのままパイプライン全体の能力に繋がるけど
キャッシュとかデコーダ共有等はそのデコボコをならす役目になっている

プリデコーダもデコーダの能力と吊り合っているのが望ましいけど
上記のようにあまり細かく調節しなくていいし
分岐予測ミスでパイプラインストールしてもプリデコーダ部分には関係無い、はず
584Socket774:2010/05/09(日) 19:22:39 ID:01tAcw2H
過不足はそのままパイプライン全体の能力に繋がる

過剰は無駄に終わるし不足は全体の能力を下げる
585Socket774:2010/05/09(日) 19:29:57 ID:7kTS+I0L
>>583
パイプライン間でのデコボコをならす役目というのは結構的を射てると思う
Intelはデコーダ後にあるLSDやRATや深いROBなどのバッファがデコーダ時のデコボコを吸収してくれるのに対して、
AMDの設計では、極浅いパックバッファと、レーン別でエントリ数が少ないROB・RSしかなくて、とても吸収できない
だから、デコードの平均帯域を確保すればいいIntelと、最低帯域を確保しないといけないAMD、というのが、
デコーダの設計の違いに現れてるんだと思う
586Socket774:2010/05/09(日) 19:30:53 ID:Yr7mfo0l
>>570
高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
温度上昇で故障や異常停止することを危惧しているだけだし
まともな冷却をして高負荷時でも温度を低く押さえていればクロックダウンはしないってことだし
省電力って説明は意味不明だけど、まあどうでもいいよホント
587Socket774:2010/05/09(日) 19:45:16 ID:Yr7mfo0l
>>568
> デコードそのものよりも1命令ストリームからデコーダの数分の命令を切り出す処理のほうがよっぽどコスト高い。
> 俺が今言ってるPickステージの実装コストなんてデコーダよりもよっぽど重要だよ。
デコーダー数に影響するから、そこを削るためにデコーダーを共有にしてるんだろ

>>575
素人にとっては、専門用語とかで細かく説明されるより、後藤の
「x86 命令換算で2命令程度しか並列実行できないケースが少なくない。
uOPに砕いて実行する場合でも同じで、3〜4 x86命令の並列実行帯域は、
あくまでもピークであり、平均はそれよりかなり少ないというのが常識だという。」
というような、多いか少ないか、どの程度かっていうおおまかな説明で十分なんだよ。

>>576
そこを今更突っ込まれてもな…
普段どんだけ不味いんだお前の飯って
588,,・´∀`・,,)っ-○○○:2010/05/09(日) 19:53:03 ID:sNWFFdis
> 高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
> 温度上昇で故障や異常停止することを危惧しているだけだし

要するに未だにわかってないってことですね。

何で省電力技術なのか俺は納得してるよ(省電力化を助ける技術といったほうがいいかな)
589Socket774:2010/05/09(日) 19:57:52 ID:ZUNJOSb6
何かもうぼろぼろね
590Socket774:2010/05/09(日) 19:58:44 ID:01tAcw2H
>>585
馴染みの無さそうな用語を更に略語で書かれてもちょっと(LSDは判るが)


ただ、アウトオブオーダは命令貯めておかないと出来ないし
スレッド間のデコード振り分けも2コアの命令の貯まりを見てするわけだもんな
>すぐ次のリソースに流していかなければならない
は厳密に言うとどうだろう
貯めてる部分で本当はパイプライン分けるべき?
591Socket774:2010/05/09(日) 20:00:02 ID:bD5bYP2w
WestmereよりMagny Coursのが「若干」省電力なのにまだ団子は噛み付いているようす
592Socket774:2010/05/09(日) 20:04:09 ID:Yr7mfo0l
>>568
> 3^2 * 2 と 4^2 だと前者の方が僅かに大きいくらいか。
> これの場合BulldozerはXOPに3ソースオペランド命令なんかも追加されてるので
> K10の2コアよりBulldozerの1モジュールの実装コストが上がる要因はある。
こういう話を聞きたかったんだよ
僅かがどの程度か知らんが、規模を小さく出来るってことだよな
XOPを追加しても超えるかもしれないってことで、K10のままXOPに対応するよりはマシってことだよな

ついに団子がBulldozerのデコーダーがK10より規模が小さくなるって認めたよ

後は下記2つだが、どんな説明してくれるのかな
1・スレッド辺りの3命令や4命令の頻度や、それらが頻発するようなソフトや分野
2・スレッド辺り2命令決め打ちで、2スレッド同時デコード出来るかどうか

2・については出来たらいいなー程度の希望だから、出来ない理屈を力説したりバカにしなくていいよ
593Socket774:2010/05/09(日) 20:08:55 ID:Yr7mfo0l
>>588
> 高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
> > 温度上昇で故障や異常停止することを危惧しているだけだし
>
> 要するに未だにわかってないってことですね。
>
> 何で省電力技術なのか俺は納得してるよ(省電力化を助ける技術といったほうがいいかな)
しつこいねお前もw
省電力でもフェイルセーフでもどっちでもいいんだよ、俺らは
マニクールなんか買うことも使うことも無いだろうからね
いろんなベンダーが納得して採用しているならそれでいいじゃんて話
594Socket774:2010/05/09(日) 20:13:17 ID:NEdQaE04
常にアッチッチでcoolなspeedが効きまくり?
595Socket774:2010/05/09(日) 20:13:47 ID:01tAcw2H
>>592
実行ユニット数に関係すんのは「最後のデコード」をする「スケジューラ」で
「デコーダ」自体は関係無さそうに思うけどな
俺も全然詳しくないけどウンコの発言はまずバグってるから

K7系デコーダはロング(中規模?)が3つでベクタ(大規模?)が1つ(らしい)
BullはCompが4つならロングもベクタも4つずつ
数の上では1コアで比べて丁度倍
596Socket774:2010/05/09(日) 20:14:27 ID:01tAcw2H
間違えた
1コアと1モジュで比べて
597Socket774:2010/05/09(日) 20:22:34 ID:01tAcw2H
3連レスはホモっぽくて嫌だけど
とりあえずスケジューラの中身が解るような図を貼る
ttp://pc.watch.impress.co.jp/img/pcw/docs/336/298/html/03.jpg.html
598Socket774:2010/05/09(日) 20:48:31 ID:7kTS+I0L
>>590
すまん、RATはレジスタ・エイリアス・テーブル、ROBはリオーダ・バッファ、RSはリザベーション・ステーション
Intelは複雑なRAT機構を使って積極的に効果的なレジスタ・リネームしてるのに対して、
AMDのレジスタ・リネーミングは単純なRISC風リネーム機構の移植でROBのエントリ数も少ない
汎用レジスタが8個しかないx86ではIntelのやり方が正解なんだと思う
AMDはK7→K8でパックバッファを設けて空いてるパイプラインを充填しやすくしたんだけど、
Bulldozerでは空いてるパイプラインがなければ、別のスレッド(コア)に流せるようにして、
さらに充填率を高める設計にしてると思う
599Socket774:2010/05/09(日) 20:51:45 ID:FvaKuw+6
> Bulldozerでは空いてるパイプラインがなければ、別のスレッド(コア)に流せるようにして、

それは現実的なコストでは無理
600Socket774:2010/05/09(日) 20:55:33 ID:7kTS+I0L
>>599
「別のコアに流せるようにして」は誤解を招く表現だった
「別のスレッドのデコードをして」のつもりで書いた
Bulldozerの実行ユニットは、コア間でバイパス機構がないらしいから必ずスレッドは別になる
601Socket774:2010/05/09(日) 21:01:15 ID:XFfvmGjJ
そういう理念で設計したならバックエンドも統合してSMTにした方が合理的なんだが
602Socket774:2010/05/09(日) 21:13:22 ID:7kTS+I0L
>>601
Andy Glewの弁では一つの小容量L1D$を2スレッドが取り合うことによる性能低下が大きいらしい
まぁ、IntelもSMT時にはROBを分けて使ってるから、バックエンドもある程度分かれているわけだが

IntelがROBを猛烈に強化しているのは、x86-64で汎用レジスタが増えた上にSMT時にはROBが半分になって
レジスタ・リード・ストールが発生する可能性が高まるからだと俺は思ってる
たぶん、Sandy BridgeでもROBエントリ数は増やしてくるぜ
603,,・´∀`・,,)っ-○○○:2010/05/09(日) 21:15:05 ID:sNWFFdis
>>591
> WestmereよりMagny Coursのが「若干」省電力なのに

Atomのほうが「圧倒的に」省電力ですよ。
何を売りにしたいの?
604Socket774:2010/05/09(日) 21:21:53 ID:01tAcw2H
「シングルスレッド性能で妥協しない」ために
ベクタ共有デコーダ共有で使えるリソース増やしてるけど
基本的にはベクタ犠牲でマルチスレッドでの整数スカラ性能重視だもんねえ
スケジューラの肥大が実行ユニットの2乗に比例するんなら
ALU2*2で省スペース簡略化も理に適う

「それにALUなんざ2つで充分」と言うからには
キャッシュ系能力でIntelに劣るとしても
バッファ充実等で実行パイプ充填に力を入れると思うけどね

>602
>601は「暇になったら他スレッドデコードもやる程度」な件を言ってんでしょ
605,,・´∀`・,,)っ-○○○:2010/05/09(日) 21:32:09 ID:sNWFFdis
>>592
> > これの場合BulldozerはXOPに3ソースオペランド命令なんかも追加されてるので
> > K10の2コアよりBulldozerの1モジュールの実装コストが上がる要因はある。
> こういう話を聞きたかったんだよ
> 僅かがどの程度か知らんが、規模を小さく出来るってことだよな
> XOPを追加しても超えるかもしれないってことで、K10のままXOPに対応するよりはマシってことだよな

これはRenamerの話でDecoderの話ではない。
IntelプロセッサではRenamerはDecoderのすぐ後のステージだ。
RenamarはDecoderではない。
何度も釘を刺してるのに↓こんな勘違いを平然とやってのける。

> ついに団子がBulldozerのデコーダーがK10より規模が小さくなるって認めたよ

本当に馬鹿だな

あ、ついでに言うとSSSE3, SSE4, AVXのデコードロジックをハードワイヤードで積めば
K10に比べると1デコーダ当たりの規模は格段にでかくなるのは明らかだけどな。
OpcodeマップだけでもSSE3までの約2倍の空間をサポートしないといけなくなる。
606,,・´∀`・,,)っ-○○○:2010/05/09(日) 21:32:57 ID:sNWFFdis
○Renamer
607Socket774:2010/05/09(日) 21:34:40 ID:XFfvmGjJ
>>604
暇になったらも何も、デコーダを2スレッドで共有してる時点でリソースの競合になることに変わりはない
608,,・´∀`・,,)っ-○○○:2010/05/09(日) 21:41:07 ID:sNWFFdis
>>602
> Andy Glewの弁では一つの小容量L1D$を2スレッドが取り合うことによる性能低下が大きいらしい
> まぁ、IntelもSMT時にはROBを分けて使ってるから、バックエンドもある程度分かれているわけだが

まあその小容量L1DってのはNetBurstの8KB〜16KBのことであって
間違っても32KB共有より16KB×2のほうが性能が高いと言ってるわけじゃないけどな
609Socket774:2010/05/09(日) 21:43:00 ID:ul08xTiW
nanoはcomplex decoder x3なんだね
610Socket774:2010/05/09(日) 21:51:10 ID:01tAcw2H
>>607
「デコーダ暇」な状況では競合にはならない

スケジューラ辺りで実行命令貯め過ぎたら
それ以上デコードしても際限無く抱え込めないだろうし
涅槃のLSDループ専用トレースキャッシュも
デコーダを休ませて消費電力下げるためのものでもあるはずだし
とにかく暇な状況は出来る
暇なら競合にならない
余裕出来ることがまず無いのはキャッシュくらいか
611Socket774:2010/05/09(日) 21:56:18 ID:XFfvmGjJ
>>610
いやだから、共有してる時点で暇だろうがそうじゃなかろうが
2スレッド分の命令ストリームをデコードしなきゃならんのだが
612,,・´∀`・,,)っ-○○○:2010/05/09(日) 21:58:06 ID:sNWFFdis
>>609
それでシングルコアなのに大飯喰らいなんだな

Nano L2100 1.8GHz
1MB L2
TDP 25W
65nmプロセス

Core 2 Duo L7700 1.80 GHz
4MB L2
TDP 17W
65nmプロセス
613Socket774:2010/05/09(日) 22:02:30 ID:qI6oRAXc
NanoってSOIもHKMGも使ってないんじゃないの
614Socket774:2010/05/09(日) 22:07:01 ID:Yr7mfo0l
>>605

> これはRenamerの話でDecoderの話ではない。
> IntelプロセッサではRenamerはDecoderのすぐ後のステージだ。
> RenamarはDecoderではない。
> 何度も釘を刺してるのに↓こんな勘違いを平然とやってのける。
俺は別にプロでも専門家でも無い一自作erだから用語の意味なんかよく勘違いもするよ
Renamerのコストが減る事はわかった
で、デコーダーはどうなの?って話だ
増える、減る、少し、かなり、分からないとかの分かりやすい言葉で説明してくれ
ああ、後から嘘ついたとか、デコーダーの話じゃないってのは勘弁な

> 本当に馬鹿だな
質問に答えないであさっての話をするお前も馬鹿だけどな

> あ、ついでに言うとSSSE3, SSE4, AVXのデコードロジックをハードワイヤードで積めば
> K10に比べると1デコーダ当たりの規模は格段にでかくなるのは明らかだけどな。
> OpcodeマップだけでもSSE3までの約2倍の空間をサポートしないといけなくなる。
Bulldozerがハードワイヤードって話なんか聞いた事ないけど

>>609
Bulldozerはスレッド辺りComplex DecoderはX2かな
615,,・´∀`・,,)っ-○○○:2010/05/09(日) 22:09:20 ID:sNWFFdis
まあ、65nm時点ではCore 2もHKMGは使ってないけどな
616,,・´∀`・,,)っ-○○○:2010/05/09(日) 22:11:39 ID:sNWFFdis
> Bulldozerがハードワイヤードって話なんか聞いた事ないけど

あーこれは駄目だ話にならねえ
617,,・´∀`・,,)っ-○○○:2010/05/09(日) 22:13:30 ID:sNWFFdis
未だに「スレッド当たり」とか言ってる時点でウケるwwww

>>545-546当たりの解説が全然頭に入ってないのね
618Socket774:2010/05/09(日) 22:14:32 ID:MuIc33S6
自分で撒いた種に
619Socket774:2010/05/09(日) 22:15:11 ID:7kTS+I0L
>>616
こらこら、人をののしるレスはやめたほうがいいぞ
ここは自作板なんだから、俺みたいにCPUの内部構造に疎い連中が集まるところだ
620Socket774:2010/05/09(日) 22:18:00 ID:01tAcw2H
>>611
さっきから>601とどう繋がってるのか判らんのだけど
とりあえず、バッファとやらに命令の貯蓄があるうちは
急いでそのスレッドのデコードをする必要は無い
そういう余裕が多いほうを置いといて少ないほうのスレッドで働く
これはデコード能力を取り合ってはいない

スレッドにはCPU全然使わないものもあって
そういう状況がまさに>「暇になったら他スレッドデコードもやる程度」
競合になる瞬間が全く無いわけではないけど・・・
てか元々そういう話が発端じゃなかったっけか?
621,,・´∀`・,,)っ-○○○:2010/05/09(日) 22:19:01 ID:sNWFFdis
ハードワイヤードロジック化されたデコーダってのはデコードにマイクロコードを用いないってことだよ
すなわちSimple Decoder(AMDでいうDirectPath)のこと。
622Socket774:2010/05/09(日) 22:20:50 ID:01tAcw2H
>>620の補足
要するに>601は
「競合がちょっとしか起きない状況ならSMTのほうが無駄が無い」
と言ってるのかと思ったんだが
623Socket774:2010/05/09(日) 22:31:49 ID:OpoHju9O
雑音テヘ団子はそんなにインテルが大好きならインテル次世代スレに行けよ
624Socket774:2010/05/09(日) 22:37:32 ID:2Nh2peZr
コンダンゴはIntelスレでもゴミ扱いだから…。

つか団子の古巣はここ…

C2D・C2Q・i7はやっぱりもっさりだった Part70
http://pc11.2ch.net/test/read.cgi/jisaku/1262094066/l50
625Socket774:2010/05/09(日) 23:08:52 ID:Yr7mfo0l
>>621
ああ、すまんすまん、SIMDのデコーダーのことね。
256bitで新命令だから肥大化して邪魔ってことで2コア共有だし、端から勝負になるとは思ってない
SSSE3や4も含めて互換性確保のために採用するだけだろうから期待もしてないしどうでもいいよ。

Bulldozerの構造をまとめると
デコーダーは4命令対応一個を共有
スケジューラーやpipelineとかは2命令実行
(付随するいろんな機能もK10世代からは削られてるだろう)
AVXは2コア共有
SSEはSSSE3/4に対応

整数周りは結構小さくなってそうで、
SIMD周りがどの程度肥大化してるかってところだな

将来AVXが普及しまくったら、共有じゃなくコア単位で持つようになるとは思うけど、
とりあえず普及するか分からない現状で共有って路線は正解だと思う
626Socket774:2010/05/09(日) 23:12:04 ID:Yr7mfo0l
>>625
> (付随するいろんな機能もK10世代からは削られてるだろう)
突っ込まれる前に訂正しとこう
機能自体の削減じゃなく、機能の性能や規模のことです
627Socket774:2010/05/09(日) 23:13:32 ID:OpoHju9O
いつまでテヘ団子にマジレス続けるの?もうやめろよw
628Socket774:2010/05/09(日) 23:35:46 ID:qI6oRAXc
整数演算機を使わずにSIMDユニットだけを動かし続ける処理って殆ど無いんじゃないの

整数演算器が共有されていないなら、SIMDユニットを共有したところで大して性能落ちないんじゃない
629Socket774:2010/05/09(日) 23:40:01 ID:LYmpcXuY
109モデルのノートに次世代AMD CPUが採用される
http://blog.livedoor.jp/amd646464/archives/51686260.html#comments

> AMD CPU搭載ノートがこんなに注目を集めるのは初めて
630Socket774:2010/05/09(日) 23:44:08 ID:LYmpcXuY
631Socket774:2010/05/10(月) 00:03:47 ID:npF0dF2d
ついでに言うとスレミスってね?
632,,・´∀`・,,)っ-○○○:2010/05/10(月) 05:33:15 ID:u3WIg2Mq
おはようアフォ共

> ああ、すまんすまん、SIMDのデコーダーのことね。
> 256bitで新命令だから肥大化して邪魔ってことで2コア共有だし、端から勝負になるとは思ってない

SIMDだろうが整数だろうがデコーダは同じだが。
バックエンドのハードウェアだけじゃなくてデコードロジックの負担も考慮しなければならない。
速いか遅いかは別にしてSSSE3/SSE4やAVXを実行出来るキャパがあれば、デコーダは命令を
デコードできないといけないし、そのロジックを積んでる分だけデコーダは肥大化するんだよ。
スレッド毎に分かれてるか共有してるかはデコーダを通した後の話。

単純にSandy Bridgeと比較してもXOP等のサポート分だけデコーダは巨大になる。


> SSSE3や4も含めて互換性確保のために採用するだけだろうから期待もしてないしどうでもいいよ。

期待どころかものすごい地雷だな。段階的に追加した物じゃなくてウン百命令を一気に追加するわけだから
潜在的な不具合は計り知れない。
おまいがどうでも良くてもAMDにとっては重大な問題だな。
633Socket774:2010/05/10(月) 06:13:19 ID:77HvQaMM
>>628
パイプ複数本やアウトオブオーダのバッファ(?)はデータロード待ち中の命令を増やすためにある
それらを共有すればどちらも競合することになるってのが理屈

>SIMDユニットだけを動かし続ける処理
ってのは無くてもSIMDユニットを高頻度で動かす(しそうな)マルチメディア系処理で
SIMDユニットの総数が大きく減るのは性能の大きな低下になるんではないか
まあこの辺はちゃんとしたソースでも無いとな
634Socket774:2010/05/10(月) 06:33:50 ID:gCRZMNn7
ひとりでよくもまぁダラダラと自問自答と言うか自己批判ができるな。
試しに○串報告してみるか
635,,・´∀`・,,)っ-○○○:2010/05/10(月) 06:45:40 ID:u3WIg2Mq
串なんて刺してないんだ。残念でしたww
636Socket774:2010/05/10(月) 06:53:44 ID:gCRZMNn7
節穴したら大阪のsonetだったりocnだったりしそうだけどなw
>>628
> 整数演算機を使わずにSIMDユニットだけを動かし続ける処理って殆ど無いんじゃないの
勿論ないよ。
アドレスを計算しなきゃいけないからイテレーション毎に汎用レジスタの値の加算・減算程度には
整数演算は必要になるね。

> 整数演算器が共有されていないなら、SIMDユニットを共有したところで大して性能落ちないんじゃない

2基しかないSIMDユニットでリソース競合がおきても、整数ユニットでは何も解決できないんだわ。
638Socket774:2010/05/10(月) 07:03:30 ID:PZdIi6en
>Core 2 Duo L7700 1.80 GHz
>4MB L2
>TDP 17W
>65nmプロセス

なにこの超選別品
639,,・´∀`・,,)っ-○○○:2010/05/10(月) 07:33:20 ID:u3WIg2Mq
>>638
L2100をデュアルコア化したらTDPいくらくらいになるだろうな?

Core 2 Duo T7000シリーズ 〜2.4GHz TDP 35W
Nano L2100 1.8GHz TDP 25W

ていうか、Nano L2100はVID 1.2V切るからLシリーズとの比較が妥当だと思うけど(Tシリーズは1.3V)
640Socket774:2010/05/10(月) 07:58:34 ID:77HvQaMM
>>637
「GeForeceはSIMDユニットだらけでスカラなんて無いがx86ならSSEを途中でスカラに分解出来る」
なんて思えるのはウンコ100%バーベキューのお前だけ
>628は単に「どんな処理でも整数演算率がベクタ演算比率を下回ることは無い」みたいなこと言ってるだけだろ
641,,・´∀`・,,)っ-○○○:2010/05/10(月) 08:23:30 ID:u3WIg2Mq
> 「GeForeceはSIMDユニットだらけでスカラなんて無いがx86ならSSEを途中でスカラに分解出来る」

なにその珍説。初めて聞いたわ。
まあ128ビットSSEを64ビットSIMDユニット×2で処理出来る程度には分解可能だろうけどね

> 「どんな処理でも整数演算率がベクタ演算比率を下回ることは無い」

どんだけアホなんだっていう
たとえば行列積や多体演算のSIMD化されたコードの内周ループにおいてスカラ整数演算命令の出現頻度なんて正味1割もない。

http://grape.mtk.nao.ac.jp/~nitadori/phantom/
のLimited accuracy version for BH-tree code
gravity.cみてみ?
642Socket774:2010/05/10(月) 08:49:03 ID:scCCh/+C
>>637
競合したときは諦めるしかないけど、SIMDユニットの使用頻度が低い頻度も小さいんじゃなないのってことね
単純に考えると、SIMDユニット使用頻度が1/nならSIMDユニット競合の頻度は(1/n^2)×n=1/n

あと、ユニットに流し込むタイミングはあるていど調整できるんじゃないのかな
643Socket774:2010/05/10(月) 09:18:23 ID:77HvQaMM
>>641
だからデータ並列=タスク並列なお前だけの説だと言っている
「たまにPentium 4にはL1Dが無い」って信じてるのもお前だけ
644Socket774:2010/05/10(月) 14:30:10 ID:PuBzSBms
>>641
俺は団子の言ってることは間違ってないと思うし、非常に適切なコード例を出してきたと思う
だがこのコードで命令数を数えてみると、整数ユニット側に行く命令が1割越えてる気がするぞ
645Socket774:2010/05/10(月) 15:39:46 ID:7cBdrLAS
CPUなんかにバグなんてあるわけないだろ
プログラムが仕込まれているわけでもあるまいし
646Socket774:2010/05/10(月) 17:48:44 ID:r/i/hdXL
シングルなのに大飯喰らいだな
celeron 420 tdp:35w
647Socket774:2010/05/10(月) 21:13:54 ID:7Z6NziBN
>>632
> 期待どころかものすごい地雷だな。段階的に追加した物じゃなくてウン百命令を一気に追加するわけだから
> 潜在的な不具合は計り知れない。
> おまいがどうでも良くてもAMDにとっては重大な問題だな。
何を今更なことを言ってるんだ
SSE/2/3拡張の度に数十〜100近い追加をしてきているし、AVXにしても数年かけて対応しているから、
大きな不具合が出るほど拙い実装なんかしないだろ。
そもそもBulldozerはサーバーやHPC向けに開発していて、ベンダーの新機能に対するチェックも厳しいだろうし、
致命的な不具合を抱えたまま市場に投入するくらいなら発表を延期する方を選ぶだろ。
PhenomのTLBエラッタ騒ぎから学んでその辺は慎重に対応すると思うぞ。

>>644
ベクトル命令数が整数命令数が超えるかどうかの議論で、
1割を下回るという意見に、1割は超えるなんて言っても結局超えていないわけだからあまり意味は無いのでは。
648Socket774:2010/05/10(月) 21:20:05 ID:BRaZ6U+O
HPCは狙ってんのかなあ
Bull単体での構成では大して重要じゃないとして捨てられてる気がする
そこらへんはAPUでカバーするべき分野だと思うし
649Socket774:2010/05/10(月) 22:27:32 ID:PMXwf+/F
GPUにも計算させるゆうてはるもんな
すでにあの大国がやっちゃったけど
650Socket774:2010/05/11(火) 00:43:57 ID:bD/lFeRV
今までの半導体のパターンでいえば、Bulldozerは死産じゃないかなあ、と思っている。
AMD自身も第三者も誰もモジュール構成のメリットを明快に説明できていない、というのが根拠。
651Socket774:2010/05/11(火) 00:52:31 ID:LKm6f76f
黙っててもIntelがAVXアプリを作らせるだろうし、それが動かないのは何かと宜しく無いだろう
優先度は別にして、将来的にはAVXもGPGPUもOpenGLもDirectXも、何でも対応するのがAMDのスタンス
652Socket774:2010/05/11(火) 01:01:14 ID:uOeeSIgy
モジュール単位で構成するのはもうどうこういういうレベルの話じゃないと思うんだが
SandyにしてもLlanoにしてもモジュール構造だしな
Bulldozerでモジュール内の単位が変わったということに関してなら
150%のダイサイズで190%の性能ということで明快だと思うが
653Socket774:2010/05/11(火) 01:02:20 ID:LKm6f76f
>>650
何を言ってるんだお前は?
余裕でヒット商品になるよ

45nm SOIのマニクールが130Wで12コア2.3GHzだから、
32nm SOI HK/MGのBulldozer 16コアなら3GHzは行ける。

マルチスレッド性能は 2.3x12=27.6Gと、3.0*16=48Gで、7割近い性能アップになるし、
整数演算回路の縮小とかで多少割り引いても5割以上は向上することになる。

5割も向上すれば何処も文句言わないし採用も増えると思うがね。
654Socket774:2010/05/11(火) 01:19:17 ID:LKm6f76f
>>652
> 150%のダイサイズで190%の性能ということで明快だと思うが
そういえばそんなことも言ってたね
シュリンクでダイサイズが6割程度になる事も考慮すると、
ダイサイズは現状より多少小さくなって、性能は約倍ってことになるね。
(150%*0.6倍=0.9倍で少し縮小、190%は倍と言っていいだろう)

単純に考えると、45nm 4コア 250mm2→32nm 8コア 230mm2(0.9倍)になるな
アンコア部がどうなるか未知数だけど、Denebと面積比は同じ位だろうってことで計算
655,,・´∀`・,,)っ-○○○:2010/05/11(火) 03:02:39 ID:51kWPjlr
>>644
もちろんSIMDのload(movaps)なんかは整数クラスタにぶら下がってるLoad Unitで処理されるが
マヌケにもスカラ演算って言ってるのでわざと数から外したw

ちなみにこの手の問題はLoadの比率は32ビットか64ビットでも変わる(32ビットだとレジスタ数が不足)し
一部積和算を使うことでSIMD命令を削減可なので、そういう意味ではスカラクラスタに
流れるオペレーションの比率は変わる。


>>647
> SSE/2/3拡張の度に数十〜100近い追加をしてきているし、

SSE2の倍精度SIMDサポートはともかく整数は大半がMMXの2倍長版や単精度のスカラ版など
既存オペレーションの幅変更版が大半だから、ほとんどトランジスタの拡張は必要ないだろう。
ハード的には66, F2, F3のプリフィクスに特殊な意味を持たせるようにしたくらいしか大きな拡張はされてない。

> AVXにしても数年かけて対応しているから

数年かけたのはIntelだけだろwww
ちなみにIntelはSandy Bridge(開発当時はGesher)を4年がかりで作ってる。
AMDの中の人がbinutilsのMLにSSE5の削除パッチを送ったのは2009年5月くらいだな。
それまではSSE5を前提としたソフトを続々出していた。
多く見ても再設計に1年半程度か。それなんて突貫工事?

問題はVEXプリフィクスが今までのx86のフォーマットの根本から変わることだ。
すなわちデコードハードウェアを根本から再設計しないといけないし、場合によっては内部opsの構造自体が変わる。
656Socket774:2010/05/11(火) 03:32:37 ID:SYMADErY
フリーライドはいつものAMDの戦略なんだから
本格的に普及するまでは嗚呼ついてますね、程度でもいいんじゃないの?
性能で残念なことは否めないけどさ
信者脳的には新命令初期において、最適化カッコ悪い!的な煽りの方便ともなる
657Socket774:2010/05/11(火) 09:37:08 ID:bD/lFeRV
>>652
>150%のダイサイズで190%の性能ということで明快だと思うが
それを達成するために、なぜ2コアを1モジュールにするアプローチをとったのかが
明確でない。
658Socket774:2010/05/11(火) 09:46:26 ID:V2RFFcOC
・デコーダ共有で並列実行部分のランダム性が性能に悪い影響を与えるのを緩和
・SSEユニット減らしつつも共有化でシングルスレッド時の並列度維持
この辺は何度繰り返して話題にすればいいんだ?
659Socket774:2010/05/11(火) 09:48:23 ID:J99FYweS
>>657
根本的に考え方が違う
2コアを1モジュールに押し込んだのではなく
1モジュールで2スレッド実行可能にしたのがBulldozerだ
考え方的にはハイパースレッディングの延長線上にある
660Socket774:2010/05/11(火) 10:01:22 ID:V2RFFcOC
定義はそれぞれ色々あるだろうけども

HTT
考えなしに並列化しまくって案の定余ったリソースを有効利用するための機能

Bull
1コアに更に整数実行パイプ部分のみを1セット追加して
マルチスレッド時の整数スカラ性能を最優先

対抗ではあるけど線は別だと思う
661Socket774:2010/05/11(火) 10:20:23 ID:J99FYweS
>>660
リソースを一部共有して複数スレッドを走らせる技術として延長線上という表現を使いました
完全に定義付けの差っすね
662Socket774:2010/05/11(火) 10:43:41 ID:bD/lFeRV
>>658
>・デコーダ共有で並列実行部分のランダム性が性能に悪い影響を与えるのを緩和
そこは共有して嬉しいところじゃない、という話題も何度も繰り返されているよね。
FPUは使用頻度にムラがあるから共有する意味があるが、
デコーダは(大容量トレースキャッシュでも積まない限りは)常にビジーで、
かつn倍のスループットを得るのにn^2倍のトランジスタを消費してしまう。

整数パイプラインをコア間で共有して効率を上げるならばその前段も共有する
のは至極道理だが、パイプラインは分離だという。わけがわからない。
663Socket774:2010/05/11(火) 10:49:48 ID:bD/lFeRV
まあ、俺がわからないのはいいんだ。
AMD Fanboy以外でここのロジックを明快に説明できる人間が未だに誰もいないのを
問題にしている。見たことあるなら教えて欲しい。
664Socket774:2010/05/11(火) 10:55:25 ID:Cd76ER64
 ベクターユニット共有によるロスを最小化するため、かなぁ?
665Socket774:2010/05/11(火) 11:36:03 ID:V2RFFcOC
ある構造でデコーダの能力と演算ユニットの能力が吊り合っているとして
そこでデコーダを10倍にしてなおかつデコーダが常に動いているとすると
デコーダは既にデコードした命令を何度も何度も繰り返しデコードしてることになる
そんな馬鹿なことはた例えIntelでも99%やらない

というか後藤も「キューが貯まってないほうの実行パイプ(スケジューラ?)にデコードを振り分ける」と言っているし
>という話題も何度も繰り返されている
なんて大阪秋葉原の押入れくらいでしか見たことが無い
666Socket774:2010/05/11(火) 11:54:18 ID:V2RFFcOC
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20091217_336298.html
今更探して来るってのもアレだけど、これだね

別の(一昨日の)話だけど
>同サイクルにデコードされるx86命令は、同じキャッシュラインから切り出されるため、いずれも同じスレッドに属することになる
てことで2スレッド*2並列デコードとかは無いわけか
L1Iでプリデコード済みなAMDだから別にこの辺はどうでもいいんだけど
667Socket774:2010/05/11(火) 15:56:32 ID:RNx0x8xK
>>663
ダイサイズを縮小したい
SIMDユニットは利用頻度が低いから減らしたい
2つのコアで共有させよう
ついでに他の共有できる部分も共有させよう

つう事で非常に分り易いと思うんだが
668Socket774:2010/05/11(火) 18:05:42 ID:PXi0ZTyx
SIMDの使用頻度が低くて
ダイを小さくしたいなら
Fusionなんて辞めれば良いのに
669Socket774:2010/05/11(火) 18:25:03 ID:FlOjermt
Fusion前提だからこそ既存FPUの役割を減らしていく方向
670Socket774:2010/05/11(火) 18:34:41 ID:sDA3mV/O
Bulldozerの話してて、これ読んでない奴いるか?
http://pc11.2ch.net/test/read.cgi/jisaku/1253517890/587-600
671Socket774:2010/05/11(火) 19:03:10 ID:3/PXAkR7
>Fusion前提だからこそ既存FPUの役割を減らしていく方向
(笑)
672Socket774:2010/05/11(火) 20:38:24 ID:LKm6f76f
AMDの狙いは、互換性維持のためSSEやAVXには対応するけど性能競争する気はない、
メインは整数クラスタ(モジュール化)とシェーダークラスタ(MIMD?)の組合せで業界の覇権を狙う、だろ
673Socket774:2010/05/11(火) 20:45:38 ID:3/PXAkR7
そんな独自規格
だれが使うの
674Socket774:2010/05/11(火) 21:04:59 ID:V2RFFcOC
GPUすら忘れたホモ
675Socket774:2010/05/11(火) 21:30:13 ID:LKm6f76f
>>673
AVXは独自規格とはいえIntelが大プッシュするから結構使われるよ
676Socket774:2010/05/11(火) 21:32:03 ID:3/PXAkR7
互換性のない
shader clusterとやらの方だよ
677Socket774:2010/05/11(火) 21:32:43 ID:TFwvDGsv
AVX載ってないとキツイと言われるようになるのは何年後ぐらいだろうか……
678,,・´∀`・,,)っ-○○○:2010/05/11(火) 21:38:02 ID:51kWPjlr
>>670
それ前提で話してると思ってた。


あと>>653
既に性能予想があってだな

http://www.ospn.jp/osc2009-shimane/amd.pdf

グラフから読み取れる数字は大体こんなもん
Istanbul 17
Magny-Cours 26
Interagos 33

K10 1コア→K11 2コアでのスループットは1.8倍程度と仮定して逆算すると
Interagosの動作クロックはいいとこ2.5GHz前後
679Socket774:2010/05/11(火) 22:07:37 ID:V2RFFcOC
何か前にもあったな
広告担当の誰かがてきとうに作って
OpteronとIstanbulが同列に扱われたりなどしてるそれを見てホモが真剣に語ってる図というのが

今回はK10@6コアとK10@6コア*2でintとfroatの割合が違ってるが
「Opteron&Istanbul」は無くなってるな
680Socket774:2010/05/11(火) 22:21:02 ID:LKm6f76f
>>676
> 互換性のない
> shader clusterとやらの方だよ
互換性無いwww
何との何の互換性が無いんだよwww
681Socket774:2010/05/11(火) 22:30:22 ID:3/PXAkR7
だれが、どうやって使うんだ
そんなマイナー独自規格を

Intelとの互換もなしに
682Socket774:2010/05/11(火) 22:31:57 ID:3/PXAkR7
ところでOpenCLってベンチ以外で
何に使われてるんだ?
683Socket774:2010/05/11(火) 22:33:43 ID:3RRl+gGa
ヘテロジニアスは規定路線です。
IntelとAMDはいまさらやめられませ〜ん。
VIAとNVはどうなるんでしょうか、知りたくもありませんが。
684Socket774:2010/05/11(火) 23:13:19 ID:LKm6f76f
>>678
他のも数値化してコアの世代も並記してみた
2007 4C 8 (Barcelona/Agena)
2008 4C 10 (Shanghai/Deneb)
2009 6C 17 (Istanbul/Thuban)
2010 12 26 (Magni-Cours)
2011 16 33 (Interlagos)

これってクロックあたりの性能比較じゃね?
Athlon64(1C)を1とした時のね。

・クロックとコア数だけ考えた場合
Athlon64 1C 1GHz=1
Istanbul 6C 2.6GHz=16(17)
でほぼグラフ通りの差になっている。
IPC比も含めたら17どころじゃない差になりそうだけどね。

Agena(8) vs Deneb(10)
Deneb(10) vs Istanbul(17)
は最高クロック同士だとありえない結果だし
Magni-Cours(26) vs Interlagos(33)はコア数差程度
33/26=1.27、16/12=1.33

Magni-Coursだけコア数比より落ちている理由は分らん。
12/6=2、26/17=1.5
ここだけ実性能比なのかな?
685Socket774:2010/05/11(火) 23:18:29 ID:LKm6f76f
>>681
お前の頭の悪さにはびっくりだww
シェーダーがバイナリやらソースを直接実行するわけじゃない
APIにはドライバで対応するから、ベンダーはCPUの中身なんか気にしないで
DXやOGL、OCL、C++とか好きな言語で開発すればいいんだよ。
最適化したけりゃすればいいだけで、その時はAMDが手厚くサポートしてくれる
686Socket774:2010/05/11(火) 23:51:00 ID:a7Sz8lId
>>685
>その時はAMDが手厚くサポートしてくれる
はたして・・・
687Socket774:2010/05/12(水) 00:34:31 ID:bQNWMrtI
AMDが手厚くサポートしてくれるってどんだけお花畑なんだよ
688Socket774:2010/05/12(水) 00:34:53 ID:tBFvVyzU
OpenCLは各デバイスごとのバイナリを実行する仕様だし、
中身CPU以上に違うGPUの違いを無視してコード書いても性能なんかでないだろう。
何の言語使うにしろ、ターゲットとするGPUごとに最適化することは必須じゃないの?
689Socket774:2010/05/12(水) 00:49:35 ID:m2HAnMbU
GPUごとに最適化なんて面倒くさいことしているうちは普及なんかしないと思う
.NETあたりが鍵になるんじゃないかな
690Socket774:2010/05/12(水) 01:58:35 ID:6E7e2qA4
>>670
Andy Glewもdresdenboyも、デコーダ共有の得失については特に深くは言及してないんじゃないか。

デコーダ共有に、FPU共有のしやすさとかのメリットはあるにしても、
3命令同時発行というx86のベストプラクティスを捨てるほどの価値はあるのか、
あるいは、平均2命令でいいなら、4命令同時発行×1より2命令同時発行×2の方がシンプルで省トランジスタ・省電力なんじゃないか。
691Socket774:2010/05/12(水) 02:07:34 ID:m2HAnMbU
三命令発行がトランジスタ効率的にベストじゃないと判断しただけだと思うが
692Socket774:2010/05/12(水) 02:18:27 ID:6E7e2qA4
トランジスタ効率にフォーカスするなら2命令発行×2の独立デコーダがベストだろう。

4命令発行は難しい処理(=電力とトランジスタを喰う)で、
かつ平均すると2命令に落ちるという、誰が得するのかわからないアプローチだ。
ピークがどちらかのコアに偏るなら意味があるが、デコーダはそういう性質は薄いし、
後段(スケジューラ)でキューイングするということは、偏りはならされて平均化されるということだ。
693Socket774:2010/05/12(水) 02:41:52 ID:m2HAnMbU
そっちの方が効率が良いというシミュレート結果が出たんだろ
物が出てから判断するしかねえだろうがそこらへんは
694Socket774:2010/05/12(水) 03:22:00 ID:9p9WfluQ
3命令デコーダx2だとL1Iも2倍いるんじゃないの?
あるいはマルチポート化とか
695Socket774:2010/05/12(水) 05:00:32 ID:ntMxZkEV
デコーダ話のループストリームに加えて
Core2の4命令にまで妄想持ち込む奴まで出て来るとはな
696Socket774:2010/05/12(水) 07:16:21 ID:903oTJEG
>685
API経由のくそ遅いものを
だれが好き好んで使うんだ

ところでAMDのSSE4aは
何で使われているのか
697Socket774:2010/05/12(水) 08:03:32 ID:GyrVw/AV
LlanoとOntarioのサンプルが出荷されてるらしいけど
OntarioのCPU部分はBulldozerの1/2モジュールなの?
698Socket774:2010/05/12(水) 08:11:51 ID:HTjrU7FM
ふと思ったのだがWindows2000ProだとBulldozerのFPUは一つしか使えないのだろうか。
……どうでもいいな。
699Socket774:2010/05/12(水) 08:30:12 ID:ntMxZkEV
>>697
FPスケジューラの持つ2本のパイプをBullは1モジュ共有でBobは1コアが所有
ただFPUの構成って整数パイプのユニットと比べてわけ判らんから断言は出来んけど
ttp://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:AMD_A64_Opteron_arch.svg
K10はこんなことになってるし
700,,・´∀`・,,)っ-○○○:2010/05/12(水) 08:41:05 ID:8+RU6ZtX
>>684
> これってクロックあたりの性能比較じゃね?
> Athlon64(1C)を1とした時のね。

いやそれありえないからw
同じK8でクロックしか上がってない2003-2004の微妙な伸びはどう説明するんだよっていうwww
1.8GHzが2.4GHzくらいに伸びた時期だぜ?
そもそもOpteronって書いてあるんだから基準はAthlon64じゃなくてOpteron(SledgeHammer)だろ。

これ大体SPECint_rateの値と比例してるんだよな

FPのほうはコア性能よりも足回り(メモリ帯域)の性能にもよるところが大きいと思うが。
実際2009-2010は単純にメモリch増加の分だけFP性能が伸びている罠。
(相対的にIntegerはクロック落ちた分伸び悩んでいる)


InteragosのFPUは共有とはいえFMAを使うことでのスループットはK10の最大2倍だから、
利用タイミングさえ重複しなければコア当たりの性能を引き上げることはできる。
701,,・´∀`・,,)っ-○○○:2010/05/12(水) 09:10:41 ID:8+RU6ZtX
ちなみに
> Deneb(10) vs Istanbul(17)
> は最高クロック同士だとありえない結果だし

2008年最高性能のOpteronは 2386 SE(Barcelona 2.8GHz×4)
2009年は Istanbul 2.9GHz×6

ということで整数は概ねクロック×コア数なみ。
702,,・´∀`・,,)っ-○○○:2010/05/12(水) 09:15:35 ID:8+RU6ZtX
×2009年は Istanbul 2.9GHz×6
○2009年は2439 SE 2.8GHz×6(Istanbul)
703Socket774:2010/05/12(水) 09:16:23 ID:GyrVw/AV
>>670
MACオタは意地悪だな・・・
704Socket774:2010/05/12(水) 09:58:59 ID:ntMxZkEV
アウトオブオーダ=スーパースカラ(>541)なせいで
以前Opteron(ブランド)とIstanbul(コード)の名が一緒に並んでたような
いい加減な広告に人生を賭けるショタホモ55歳(推定)
705Socket774:2010/05/12(水) 12:05:58 ID:3tQ0QfRj
>>697
別物。
706Socket774:2010/05/12(水) 13:34:59 ID:ntMxZkEV
アウトオブオーダといえば
アーキテクチャスレのMADオタコピペで「FPスケジューラはアウトオブオーダではない」とあったけどほんとかね?
それなら共有化すれば単なるインオーダからSMTが付いたAtomみたいになるからいいんだが
それはBullのFPだけのことなのか
「モジュールはクラスタで皆ひっくり返して呼んでてうんちゃらかんちゃら」とよく解らないことを言ってる奴の発言だから放っといたほうがいいのか
どうなんだろ
707Socket774:2010/05/12(水) 13:41:52 ID:0ZSeiGDV
■後藤弘茂のWeekly海外ニュース■
コンピューティング市場の規模は5年で6億台とIntelが予測
http://pc.watch.impress.co.jp/docs/column/kaigai/20100512_366386.html

Intelは今回のInvestor Meetingで、2013年の「Haswell(ハスウェル)」についても、何も言及しなかった。
Haswellは、Nehalemを担当した米オレゴン州の開発センターで開発しているCPUだ。2013年に登場する予定で、すでに一部顧客に対しては説明も開始している。

 2013年の次々期マイクロアーキテクチャCPUをIntelオレゴンが開発していることは、すでに明かされている。
今年(2010年)2月に米スタンフォード大学の公開講義EE380で、IntelのアーキテクトGlenn J. Hinton氏(Intel Fellow, Intel Architecture Group, Director, IA-32 Microarchitecture Development, Intel)
が行なった講演「Key Nehalem Choices」で、オレゴンが2013年のCPUを開発していることが示唆された。
Hinton氏はオレゴン設計センターのアーキテクトのリーダーで、 Haswellも担当していると見られる。Haswellについては、Sandy Bridgeも出る前とあって、時期が早すぎ封印されていると推定される。
708Socket774:2010/05/12(水) 14:31:01 ID:m2HAnMbU
だからどうしたとしか言いようがない
それならまだLarrabeeについて言及している部分の方が面白いと思うが
709Socket774:2010/05/13(木) 01:56:33 ID:4Xozv/m2
次々世代のHaswellを封印するIntelと
次世代のBulldozerの音沙汰がないAMD
少なくとも、当初言われていたOrochiの今年後半の生産開始はないな。
710,,・´∀`・,,)っ-○○○:2010/05/13(木) 02:30:09 ID:K0i0hle1
>>700-702に補足
この時点で2009年以降の数字はあくまで予想値でしかないんだよな
Istanbul 6コアが2009年中に3.0GHz出す予定だっだと仮定すれば数字の帳尻が大体合う。

【2008-2009】
グラフ比率: 17/10 = 1.7
コア×クロック数比率:(3.0 * 6) / (2.8 * 4) ≒ 1.6 (+ HT Assist + DDR3 + etc = 1.7?)

【2009-2010】
グラフ比率: 26/17 ≒ 1.56
コア×クロック数比率:(2.3 * 12) / (3.0 * 6) ≒ 1.56

2011年のInteragosが3GHzで回るとしたらそれはそれでクロック当たりのスループットは低いですよ
ってことになるわけで、それ以上の要素は無いと思うけどな。
711Socket774:2010/05/13(木) 03:50:23 ID:6y9oOQUH
IntelでもオレゴンチームはぱっとしないからHaswellもどうなることやら。
712Socket774:2010/05/13(木) 06:51:50 ID:SGjMD0kf
まだオレゴンがどうとか言ってる奴いるんだw
713,,・´∀`・,,)っ-○○○:2010/05/13(木) 07:30:12 ID:K0i0hle1
ぱっとしないチームが作ったNehalemに無残にも市場を奪われたOpteronって何なの?
714Socket774:2010/05/13(木) 07:50:48 ID:XBQhPYWe
本当に団子はintelを愛しているんだな。
715Socket774:2010/05/13(木) 08:04:15 ID:iMzSCbF8
Haswellにもオレゴンが加わるのかよ...
716Socket774:2010/05/13(木) 08:32:38 ID:iMzSCbF8
ノートPCでも雑音の法則発動かよ
717Socket774:2010/05/13(木) 08:37:02 ID:YWi234Sc
オレゴンチームは市場を奪ったんじゃない!雑音の知能を奪ったんだ!
718Socket774:2010/05/13(木) 10:20:31 ID:EfLsbeQN
反論のつもりでズレた事を言うから楽しい

そんなのでHaswellへの不安が消えるかいな
719Socket774:2010/05/13(木) 14:41:46 ID:i5oQRX2g
サンタクララチームって今後もItanium保守チームであり続けるんだろうか
720Socket774:2010/05/13(木) 14:46:52 ID:ShsZL7dh
Nehalem-EXはサンタクララが作ったけど、Westmere-EXはバンガロールらしいし、
RAS機能強化するときに出張ってくるくらいなのだろうか。
721,,・´∀`・,,)っ-○○○:2010/05/13(木) 18:12:02 ID:K0i0hle1
>>718
アンタが不安なだけにしか見えんが。
失敗時のリスクヘッジのためのTick-Tockモデルなわけで、
* Bridgeの続投ではなくマイクロアーキテクチャの刷新というロードマップに変更がないだけで
十分といっていいんじゃないの?

FMA命令の追加で更に1コアあたりのFPの理論スループットをSandy Bridgeの更に2倍にすることが
できると言われているが、その計画に変更がないだけでも御の字。
むしろ2008年時点で先の方まで情報を出しちゃったから、それ以上の期待もしようがない。

むしろAMDの心配してやれよ
対Haswellって意味ではBulldozerの次世代(22nm? 25nm?)のほうが不安要素多くないか?
各FMAを256ビット化すれば性能的にもHaswellに追従可能だが、
あるいはGPUのシェーダクラスタとの共用化をすすめてくるかね?
722Socket774:2010/05/13(木) 18:31:12 ID:YWi234Sc
x86ベクタの強化でGPUの1/100から2/100に!!!
723Socket774:2010/05/13(木) 18:40:07 ID:Ojsonk68
第二世代Fusionは2015年らしい
724,,・´∀`・,,)っ-○○○:2010/05/13(木) 19:39:04 ID:K0i0hle1
LinpackあたりならSandy Bridge 6コアで実効140GFLOPS(倍精度)程度は出せるよ

> x86ベクタの強化でGPUの1/100から2/100に!!!

へえ70TFLOPSも出せるんだGPUは
725Socket774:2010/05/13(木) 19:54:40 ID:e7DWOcU1
>>724
|ω・)コソーリ計算を修正w 140GFLOPS / (2/100) = 7TFLOPS
726,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:00:54 ID:K0i0hle1
いいや、実用性のない方のGPUは0.2掛けくらいが妥当だからこれでおk
727Socket774:2010/05/13(木) 20:01:20 ID:XyqkTTqZ
radeonはいつでも公称値勝負
728Socket774:2010/05/13(木) 20:05:09 ID:HW4mbN3y
NVIDIAのサイトで確認すると,確かにシェーダクロックは1.15GHzになっており,
倍精度浮動小数点演算のピーク性能は515GFlopsになっています。
Intelの8コアのX7560は72.5GFlopsで130Wですから,
まだ,ピークFlops/Wでは4倍程度のアドバンテージがあるのですが,
今年末に出るとみられているSandy BridgeではサイクルあたりのFlopsを
倍増すると考えられるのでかなり差が縮まり厳しいところです
729Socket774:2010/05/13(木) 20:15:45 ID:YWi234Sc
掛け算も出来ないっつーか
12<16は覚えたのかホモ
730Socket774:2010/05/13(木) 20:22:30 ID:e7DWOcU1
>>729
CPUがGPUの1/100とか2/100ってのはどこから来たんだ?
731Socket774:2010/05/13(木) 20:23:42 ID:YWi234Sc
>>730
GPU 100倍 でググればいいだけ
732,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:30:29 ID:K0i0hle1
>>730
CPUは最適化一切無し1スレッド
GPU(CUDA)は何ヶ月も出してカリカリにチューン

大学から出てくるレポートなんてそんなんばっかしだよ

それすらRadeonなんて無縁だけどな
733Socket774:2010/05/13(木) 20:32:06 ID:nbjN3YSd
1+1は2じゃない 200だ! 10倍だぞ10倍!
734,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:34:36 ID:K0i0hle1
ん?某GPUは倍精度(理論値)は単精度(理論値)の0.2掛けじゃなかったのか?
735Socket774:2010/05/13(木) 20:36:45 ID:iahGzgA6
なんでテヘは他人に成りすましてまでファビョっているの?
大好きなIntelが性能でAMDにたまたま負けたのがそんなに悔しいのw
736,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:38:30 ID:K0i0hle1
くやしいおおお
くやしいおおおおおおぉぉぉぉ





わかったからさっさとクソして寝ろ
737Socket774:2010/05/13(木) 20:39:10 ID:1/MUqo2C
>>731
GPUのコア(と呼ぶベンダーもいる、CPUの演算器に相当)とCPUのコアの数を比較して
100倍速いとか書いてる糞記事が出てきたんだが
738Socket774:2010/05/13(木) 20:40:20 ID:YWi234Sc
>>733
tp://beye2.com/item_7464.html
もうとっくに訂正されてる
これは言い間違いってやつだろうし
書いて間違うのとレベルが違うっていうか
やっぱり12<16すらまだ解らないホモは知能0なんだよな
739Socket774:2010/05/13(木) 20:43:39 ID:61PswE2R
>>736
なんでテヘの話題にダンゴが喰い付くんだw
740,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:45:15 ID:K0i0hle1
>>737
貧乏研究室は科研費おりなくてNVIDIAから寄付金もらわないとやってけない、と思ったら涙が出てくるよ。













計算機科学の公証性を歪めるクソ研なんざ消えて良し。レンホーの鉄槌希望。
741,,・´∀`・,,)っ-○○○:2010/05/13(木) 20:46:07 ID:K0i0hle1
>>739
少なからず同一認定する頭の悪い子が複数いるからだよ
742Socket774:2010/05/13(木) 20:46:30 ID:nbjN3YSd
ホモ呼ばわりされてしもた
743Socket774:2010/05/13(木) 20:52:26 ID:YWi234Sc
>>742
ホモは雑音の事
12<16の件は>420関連を読めば判る

「いくら肉体労働者だからってプロレスラー(人間)と雑音(知能の無い何か)を一緒にするなよ」
って言いたかっただけ
744Socket774:2010/05/13(木) 20:59:57 ID:XMmZgZKq
>>713
> ぱっとしないチームが作ったNehalemに無残にも市場を奪われたOpteronって何なの?
Intel最強のイスラエルの傑作であるCore2にメモコンやL3を足したのがNehalemだからな、
余程のボンクラじゃない限り優秀なコアになるのは確定していたよ。
745,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:00:32 ID:K0i0hle1
まあいずれにしても
Broadcast+乗算+加算+αが1サイクルに同時発行出来る前提で設計されたFLOPS数と
常に全部の命令スロットを積和算に割り振らないと発揮できない常識的にあり得ない利用シーンでのFLOPS数を単純比較しても
全く意味がないんだけどな
746Socket774:2010/05/13(木) 21:04:28 ID:XBQhPYWe
今日の団子は生きがいいな。何か良い事でもあったのか。
747,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:05:04 ID:K0i0hle1
>>744
元はPentium Proだろ

それはともかく
その優秀なイスラエルチームが4年ぶりのメジャーアップデートとして放つSandy BridgeのFPUを
更にFMAに替えた物がHaswellだよ。
余程のボンクラじゃない限り優秀なコアになるのは確定じゃないの?
748Socket774:2010/05/13(木) 21:13:07 ID:iMzSCbF8
GPUにやらせたほうがクソ速いときはGPUに
CPUにやらせry
てのがヘテロの行き着く先
749Socket774:2010/05/13(木) 21:16:01 ID:YWi234Sc
まともそうなサイトが100倍って言うからにはそういう処理もあるんだろうし
ttp://www.brightsideofnews.com/Data/2010_3_16/ATI-Radeon-HD-5970-king-of-iPhone-Wi-Fi-password-cracking/ElcomSoft_GPU_Performance_6.jpg
別にこれくらいでも充分だわな
つまり「Intelはx86ベクタを捨てつつあるAMDCPUに喧嘩吹っかける以外に望みが無い」ということ

SSEも専用SIMD使っといて効率悪いってんじゃあ
CPUにはもうFPU使える3DNow!だけでいいんじゃないか?
にもかかわらずAVX LNIと自滅の道を歩んでいるIntel
押入れあげるよ
750,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:18:26 ID:K0i0hle1
データ並列度が高い処理のスループットが高いだけで速いわけじゃない

車に喩えるなら
スポーツカーのトランク小さいトランクよりも4トントラックの方が多くの荷物を運べるけど
そもそも荷物はこぶのだけが車の役割じゃないっていう感じね
751Socket774:2010/05/13(木) 21:21:22 ID:iMzSCbF8
25.75倍て
flops差以上の差、いやこえられない壁だな・・・
752Socket774:2010/05/13(木) 21:22:41 ID:XyqkTTqZ
PPU(58gflops)=9600GT(208gflops)とか
x4 955(102.4gflops) > HD4870(1200gflops)とか

あてにならんちや
753Socket774:2010/05/13(木) 21:26:36 ID:XyqkTTqZ
>にもかかわらずAVX LNIと自滅の道を歩んでいるIntel

だったらAVX対応なんてしないでSSE5でよかったのに(棒)
754,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:27:04 ID:K0i0hle1
いや、エンドユーザー側からすればまったく実用性がないしw

たとえばAESみたいなブロック暗号ならECBならクラック(笑)と同じ原理でブロック数分だけ並列化可能だけど
一般的にはCBCやCFBで使うことが多いから並列化できない。
755Socket774:2010/05/13(木) 21:29:13 ID:XMmZgZKq
>>721
一度大失敗して引っ込めたプランの焼き直し、
しかも原因がハードではなくソフト環境の出来の悪さが酷かったなのによくそんな自信あり気に話せるな。

>>各FMAを256ビット化すれば性能的にもHaswellに追従可能だが、
AVXを128bit*2の構成にした時点で、互換はとるけど勝つ気は全くないのは見て取れると思うが?
>>あるいはGPUのシェーダクラスタとの共用化をすすめてくるかね?
AVXにも対応したシェーダーを作るか、AVX/LNI < GPGPUキャンペーンでもして対応ソフト増やすかのどっちかじゃね?

AMDはSIMDでIntelに追従しつつ、GPGPUという独自路線も取れるから結構美味しい位置にいるんだよな。
ALU/FPU/SSE/AVX/GPU(OpenGL/OpenCL/DX11)
Intel互換も含めて業界標準と言えるAPIの全部にCPU一個で対応出来るようになる。
しかもどれをとってもそれなりに高性能を出せるとくれば、採用したいと思うところは結構あるとおもうよ。

どちらかというとAVX頼りなIntelの方が将来はやばいと思うが。
なにせAVX失敗したら終わりだもんね。代替プランはSSEの継続以外ないだろ?
756,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:35:01 ID:K0i0hle1
平文のある16バイトと別の16バイトの平文のビットパターンが同じ場合、暗号文も同じ箇所が同じビットパターンになるのがECB。
それこそクラック(笑)に弱くなるので誰も使わない。

> 一度大失敗して引っ込めたプランの焼き直し、
> しかも原因がハードではなくソフト環境の出来の悪さが酷かったなのによくそんな自信あり気に話せるな。

??????
Larrabeeのことなら全くの見当違いだぞ

メインコアはSandy Bridgeの拡張でベクタ長は256ビットに留め
GPUコアすらLarrabeeベース出はなくGMAの焼き直しと言われてるくらいだ。
757Socket774:2010/05/13(木) 21:36:13 ID:XMmZgZKq
>>734
0,2倍だけど540Gあるよ、しかも190W(HD5870)。

72.5G/130WのX7560の約5倍になる。
効率半分になっても2倍以上の性能差だな。
コスト差も考えるとすごいことになるぞ。
758,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:36:32 ID:K0i0hle1
> なにせAVX失敗したら終わりだもんね。代替プランはSSEの継続以外ないだろ?

MSが全面支持、AMDがSSE5をキャンセルしてAVXに追従の時点で
代替がどうとか馬鹿もたいがいに
759,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:38:04 ID:K0i0hle1
>>757
中国のスパコンのあれ、4870X2だけども
その半分すら動いてない計算になるぞ。
760:2010/05/13(木) 21:40:25 ID:HW4mbN3y
>>757
馬鹿だな。
専用設計で2倍とか負けたも同然。10〜100倍が目安。
RISCなんて汎用でx86の数倍早い時期が10年前後もつづいたがそれでも負けたんだぞ。
761Socket774:2010/05/13(木) 21:41:00 ID:EfLsbeQN
ここでスパコン持ち出すかw
762,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:42:41 ID:K0i0hle1
まさかHaswellがLarrabeeベースになると思ってるのかwww
後藤ですら何ヶ月も前に訂正してるのにww

しかもRockwellのGPUコアにすらLarrabee載らないなんて噂まで3月には浮上してるんだが
763Socket774:2010/05/13(木) 21:44:44 ID:XyqkTTqZ
万能ツールとよばれるものが
万能だった例が無い

                  by 飯倉清
764:2010/05/13(木) 21:48:54 ID:HW4mbN3y
GPGPU = 専用→器用貧乏
汎用 = システム、整数系アプリ向け
765,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:49:09 ID:K0i0hle1
いわゆる「汎用機」が全然汎用じゃなかったりとかね
766:2010/05/13(木) 21:49:52 ID:HW4mbN3y
汎用プロセッサの汎用とは
システム、整数系アプリ向け
ということである。
767Socket774:2010/05/13(木) 21:50:11 ID:YWi234Sc
そういえば「FPスケジューラは全てインオーダなのか?」の話が終わってなかったんだけど
アウトオブオーダ=スーパースカラで隆盛(たかもり)くんの貞操狙ってる気持ち悪いショタホモのせいで
そんな雰囲気じゃ全くなくなってるな
12<16を覚えるまで押入れから出て来るなよ
768:2010/05/13(木) 21:54:06 ID:HW4mbN3y
Bulldozerはモジュールなどとよばずにふつうに8コアとしてうっていればね。
Intelの8コアと比較してスループットにすぐれるとかいえたかもしれないのに。
769Socket774:2010/05/13(木) 21:54:13 ID:nbjN3YSd
>>762
後藤から仕入れた情報を然も自分の方が早かったように言う図
770,,・´∀`・,,)っ-○○○:2010/05/13(木) 21:55:23 ID:K0i0hle1
>>761
スパコンほどハードに最適化してくれる用途はないぞ
771Socket774:2010/05/13(木) 21:56:31 ID:XMmZgZKq
>>745
単精度については効率悪いの承知でVLIWにしているから仕方ない
倍精度に関しちゃSFU除いた4個を使っているから単精度ほど効率は悪くならないけどね
まあ、計算の種類に応じてSSE/AVXとシェーダーを使い分ければいいだけだな

>>747
その凄いというSandybridgeはwestmereと比べてどの程度性能が上がってるの?
シングルスレッド性能、クロックの上限が何割向上とかね。

そういえばLNI凄いらしいけど、AMDも対応しそうな気がするな、互換性維持のためにね。
AVXにも対応したから、LNIは非対応はないと思う。
更に規模が大きくなるから共有のままだろうけどね。
AMDがLNI対応したら団子はどうするのかな?泣くの?
772Socket774:2010/05/13(木) 22:05:24 ID:YWi234Sc
LNI凄い 数の機能増やして
凄い 肥大化
773Socket774:2010/05/13(木) 22:05:40 ID:XMmZgZKq
Haswell=Nehalem改良コア+オンボロGPU+Larrabeeの512BitSIMDじゃなかったっけ?
コアやGPUとか現状と大して変わらんから全く無視していたよ
774Socket774:2010/05/13(木) 22:08:09 ID:iMzSCbF8
GPUがテープアウトしてから店頭で買うことができるまでの期間ってCPUのときよりも短いんだっけ?
Southern Islandsは今年中にはみられるのかな
775Socket774:2010/05/13(木) 22:11:47 ID:XyqkTTqZ
>AVXにも対応したシェーダーを作るか

半端に使い物にならない汎用性で肥大化ですね
776,,・´∀`・,,)っ-○○○:2010/05/13(木) 22:18:08 ID:K0i0hle1
少なくともGMAベースの低性能IGP+AVXによるソフトウェアVertex Shaderで性能補完という基本路線は
数世代にわたって継続する予定だから安心しろ。

LNI・・・IntelがAMDにライセンスしてるかどうかも不明だな。
あれはLarrabee専用のOSとセットのモノだから命令セットだけあっても無意味

いずれにせよAVXのフル256ビット化すらされてない段階で512ビットなんてのはない
777Socket774:2010/05/13(木) 22:20:02 ID:YWi234Sc
DirectX+GPUにすぐ潰されそうなAVX&LNIなんてどうでもいいよ
知能0が気持ち悪いショタホモ自殺させて
Bullのパイプライン予想とかでも語りたいね
778Socket774:2010/05/13(木) 22:20:59 ID:EfLsbeQN
見事なララビ教徒だ
779Socket774:2010/05/13(木) 22:25:14 ID:iMzSCbF8
Rockwellですら統合されないのだとすると2015年か
780Socket774:2010/05/13(木) 22:25:49 ID:XyqkTTqZ
>DirectX+GPU

DXCSはPSの第二passでしかない
781Socket774:2010/05/13(木) 22:28:06 ID:XyqkTTqZ
>少なくともGMAベースの低性能IGP+AVXによるソフトウェアVertex Shaderで性能補完という基本路線は

VS以外もやってきそうな気もしないでもない
782,,・´∀`・,,)っ-○○○:2010/05/13(木) 22:31:30 ID:K0i0hle1
LNIはAVXみたいなプリフィックス長固定の命令セットになるが
AVXのエンコードスキームと似て非なるモノで
現時点ではAVX2とかAVX3とかの拡張計画の延長線にない
別物



Itanium互換プロセッサをAMDが作らないのと同じレベルで
Intel専用命令セットになる可能性あるよ
783Socket774:2010/05/13(木) 22:36:29 ID:iMzSCbF8
GeForceとRADEONに最適化はわかるがGMAに最適化は誰もやりたがらなさそうだ
4gamerの記者も最後までよく頑張ったな
784Socket774:2010/05/13(木) 22:41:17 ID:XyqkTTqZ
それで追いつかれてりゃ
世話ねぇっす
785Socket774:2010/05/13(木) 22:44:26 ID:YWi234Sc
算数が出来ない奴(ID)と国語が出来ない奴の2本立て
誰か何とかしろ
786Socket774:2010/05/13(木) 23:39:46 ID:XMmZgZKq
>>782
> Itanium互換プロセッサをAMDが作らないのと同じレベルで
> Intel専用命令セットになる可能性あるよ
Itanium(IA64)は普及しないと判断したからx86-64を策定したんだが
逆に考えるとLNIが普及すると判断したら搭載してくると思うよ
SSEやAVXを搭載したのも普及を見込んだからだからね

SSEとは別物のAVXに対応したから、また別のLNIに対応しても不思議じゃないと思うが

LNIの規格自体は数年前にできてるし、AMDと平等なクロスライセンス結んだから、
既に計画が進んでてもおかしくはないな

>いずれにせよAVXのフル256ビット化すらされてない段階で512ビットなんてのはない
128bit SSEの性能を優先したんだろ、多分。
256Bit AVXユニットで128Bit SSE*2を処理するより実装が楽だったんじゃないかな。
まあ、128it SSE5の流用ってだけだろうけど。
787Socket774:2010/05/14(金) 06:25:42 ID:plZNuIz4
Larrabeeがどんなものなのか正しく判ってなかったと思うが
とりあえず45nmで48コア、2+16の演算器で600muとする
48*18で864はHD4870程度でありHD5870の半分である
HD5870は40nmで334muなのだが・・・

今日日のGPUはスカラユニット積んでいるのに対しララビのはベクタユニット
ベクタ・SIMDのほうがスペース節約出来るってのに1/3〜1/4しかないってどういうことよ?
SIMDはスーパースカラではないから同じ命令しか実行出来ない
ループや分岐に対応したとかいってもそこは変わらないだろう

ゲフォは8スカラユニットで1グループ
ラデは5VLIWスカラユニットで1グループ
ララビは16ベクタ(+2スカラ)
16と長いうえにベクタ
何だかPenD作ったIntelだけ構成変なんですが

変でも性能出れば「天才!」って評価になるんだけど
性能どころかモノすら出て来ないララビ
早く押入れから顔を見せるんだ
788,,・´∀`・,,)っ-○○○:2010/05/14(金) 06:50:20 ID:SD3ubyu3
>>786
未だに勘違いしてるようだけど
Larrabeeが普及するかどうかと、IntelがAMDにライセンスするかどうかは
まったくもって別問題なので切り離して考えて下さいwww

後藤は勘違いしてるがAVXとLNIは(HPC用途は別として)全く対象とするアプリケーションが違う。
WindowsやLinuxで動くコードでSSEや3DNow!を動かすのと同じレベルで考えても困るよ。
AVXだとかは今まで通りCPUの命令としてダイレクトにコーディングできるけど
Larrabeeのコードはホスト独立なIntel謹製の専用OSで動くんですよ。
OSのライセンスまでIntelから購入するの?
789Socket774:2010/05/14(金) 07:04:39 ID:3+gdlIZZ
馬鹿なの?
790Socket774:2010/05/14(金) 07:05:21 ID:3+gdlIZZ
>>789>>787宛ね
791,,・´∀`・,,)っ-○○○:2010/05/14(金) 07:05:21 ID:SD3ubyu3
AMDがItaniumを作らないのは
そもそもItaniumはAMDにライセンスしてないからなんですよ。

AMDがx86互換プロセッサを作れるのはIntelがライセンスしているからだってこと忘れないでくれ
実装に関わる基本特許をIntelが押さえてるからAMDはIntelと契約を結ばないと
製造することができない。

Larrabeeもx86基本特許とは別に、内部構成に関わる重要な部分の特許をもっていて
それを回避してLarrabee互換プロセッサを作るのは基本的に無理。
もちろん勝手に互換プロセッサ作ったりしたらAMDは100%敗訴です。
792Socket774:2010/05/14(金) 07:21:56 ID:3+gdlIZZ
>ゲフォは8スカラユニットで1グループ

SIMDです(笑)

AMD以外はSIMDです
793Socket774:2010/05/14(金) 07:26:53 ID:plZNuIz4
AMDがAVX入れたのは保険
そもそもx86なんて過去との互換性抜きにしたらゴミ同然なんですよ。

x86世に出た頃から笑われていたこと忘れないでくれ
まだ噂レベルだけどBullにCompデコーダ*4入れてるからもう充分
ベクタプロセッサにまでx86対応するなんて馬鹿馬鹿しくてできない。

Larrabeeもおそらく
押入れを回避して世に出すのは基本的に無理。
もちろん勝手に証拠書類改竄なんてしたら100%敗訴です。
794,,・´∀`・,,)っ-○○○:2010/05/14(金) 07:49:59 ID:SD3ubyu3
Larrabeeに関しては積和ユニットなんかよりLoad/Store Unitのほうが実装コスト大きい気がするよ
Fermiの「CUDA Core」は、512ビットSIMD内積ユニットが2個に対して512bit分のLSUは1基
LarrabeeはLoadユニット1基+Storeユニット1基なんで、単純に考えてFLOPSあたりの
L1帯域はFermiの4倍はあることになる。

型変換とかブロードキャストなんかも組み込まれてると考えると相当大きいと思うね。
まあ並列配置じゃなくて直列配置なんでどこまでがLSUでどこまでがFPUかなんて考えるのは野暮だけども。
それでなくとも256KB/coreというGPUとしては破格の大容量のL2キャッシュは
言わずもがな。

どうでもいいがスカラ(兼Vector Mask)ユニットは1コアあたり1基
795,,・´∀`・,,)っ-○○○:2010/05/14(金) 07:51:13 ID:SD3ubyu3
×内積ユニット
○積和ユニット
796Socket774:2010/05/14(金) 07:53:10 ID:NMoWUSgf
追いついた、といってもそれは数字上での話

http://www.youtube.com/watch?v=_l2e0mf3CcA
のようにうんこで有名な初代Phenomでもこの差
797Socket774:2010/05/14(金) 08:57:20 ID:uIPffaIq
特許w

誰が大手ユーザーか考えたら意味が無いわ
798Socket774:2010/05/14(金) 12:28:37 ID:VN3FcrPI
>>793
まぁ。x86はそろそ別のセットへの移行を考えるべきだよなぁ…。

>>796
それ。i5だかi3とのオンボード比較もなかった?
799Socket774:2010/05/14(金) 14:37:39 ID:4KMI+Zxx
NVIDIA、2011年第1四半期は大幅な増収増益
http://pc.watch.impress.co.jp/docs/news/20100514_367014.html
800Socket774:2010/05/14(金) 16:24:16 ID:plZNuIz4
>>798
無理に移行を進めてもIA64のドッペルゲンガーが増えるだけ
x86にというかC系言語におまけでくっ付いて来るDirectXのように
非x86のGPUがx86にくっ付いていればそれでいい
801Socket774:2010/05/14(金) 19:43:15 ID:M67dlL+f
>>798
これね
http://ux.getuploader.com/mosa/download/33/athlon2-i5.wmv

正直こんな差があるとは思ってなかったから笑っちまったわ
802Socket774:2010/05/14(金) 20:15:41 ID:3+gdlIZZ
うん
画質も違いすぎるね
803Socket774:2010/05/14(金) 20:19:29 ID:4KMI+Zxx
>>801
これレンダリング解像度からしてちがうな
意図的にぼかしてるのか?
804Socket774:2010/05/14(金) 21:14:09 ID:NMoWUSgf
右の方は画質落としてももっさもさしとるのう
805Socket774:2010/05/14(金) 21:20:10 ID:4KMI+Zxx
そういう意味じゃねーw
AMDerが意図的にインテルのほうに細工してるだろこれw
806Socket774:2010/05/14(金) 21:24:34 ID:NMoWUSgf
え、右は設定落としてももっさりしてますベンチに騙されないでっていう動画じゃないの
807Socket774:2010/05/14(金) 21:29:12 ID:3+gdlIZZ
youtubeの動画拾って
くっ付けただけ

セッティング等はいずれも不明

よほど暇なやつだな、こんなの作るの
808Socket774:2010/05/14(金) 22:06:34 ID:NMoWUSgf
ゲームしたけりゃGPUつけろってことを再認識させられる動画でしたまる
809Socket774:2010/05/14(金) 22:16:41 ID:oTQ41ggo
>>801
編厨ってこんなのでお互いだましあいして妄想がふくらんでるから
ありえない信者みたいなのが繁殖してるんだろうな。
810Socket774:2010/05/14(金) 22:29:35 ID:oTQ41ggo
マジレスすると左と右とでは画面キャプチャ〜動画エンコードに用いたソフトがちがうね。
右はモスキートノイズがつねにでているし、解像度もぼけている。動きの激しい部分ではブロックノイズ
が盛大にでてるね。色も変化している。
たとえばGPUでは差のでないフォントも含めてもやもやいたり。

こういうのにだまされる人はもう少し自分の認識に慎重になったほうがいいよ。
811Socket774:2010/05/14(金) 22:31:39 ID:NMoWUSgf
よかったじゃねーか、これでGMAに希望や幻想を抱くやつは居なくなった
812Socket774:2010/05/14(金) 22:32:40 ID:oTQ41ggo
まさに中二情弱がかもにされるネタだな。
813Socket774:2010/05/15(土) 01:43:50 ID:cMxe5ppJ
http://www.digitimes.com/news/a20100513PD208.html
> AMD said to use bulk 40nm at TSMC for Fusion chips

GFも元Charteredの40nmライン抱えてるはずなんだが、なんぞこれ。
814Socket774:2010/05/15(土) 01:48:11 ID:2lqc5mkn
GFショボ過ぎてつかえない

以上
815Socket774:2010/05/15(土) 02:09:46 ID:O1AREOqe
>>788
> AVXだとかは今まで通りCPUの命令としてダイレクトにコーディングできるけど
> Larrabeeのコードはホスト独立なIntel謹製の専用OSで動くんですよ。
> OSのライセンスまでIntelから購入するの?
つまりWindowsやLinux、Unixじゃ動かないってことか?
そんなもん普及以前の問題だろ?誰が使うんだ?
816Socket774:2010/05/15(土) 02:14:26 ID:NFxMc5aq
GF自身のラインが既にキャパいっぱいか、
TSMCに頼んだ方が安くつくor高性能なものが作れる、ってことかね。

自前でいいものを安く作れる余裕があるなら、余所には頼まないよな。
817Socket774:2010/05/15(土) 04:22:46 ID:3zWQcsbi
>つまりWindowsやLinux、Unixじゃ動かないってことか?
>そんなもん普及以前の問題だろ?誰が使うんだ?

driver上のOSってこと

>ほとんどのGPUでは、ネイティブ命令セットへのコンパイルを初め、大半のソフトウェア処理をホストCPU側で行なう。
>それに対して、Larrabeeでは、Larrabee自体の上でマイクロOSが走っており、
>従来GPUならホストCPU上のドライバで行なっていたような処理を、Larrabee上で行なう。
818Socket774:2010/05/15(土) 04:23:43 ID:O1AREOqe
AMDにとっては使ったことの無いGFの40nmより、
ラデで使い慣れたTSMCの40nmの方が開発しやすかったってだけだろう。
そもそも統合GPUがラデだからっ経験とノウハウがそのまま生かせるからリスクがかなり低い。
819Socket774:2010/05/15(土) 04:48:42 ID:O1AREOqe
>>817
要はドライバーっていうかトランスメタのCMSみたいなもんか

ダメじゃん、ドライバ関連の失敗フラグ何度立てれば気が済むんだIntelは…
そもそもHaswellやRockwell登場予定の2014年辺りはWin8やDX12が登場していそうだが、
Intelがまともに対応出来るとは思えん。
多分やっとDX11ゲームが普及している頃だろうけど、Dx11対応ドライバ作れるのかね
OpenCLやOpenGLもだけど。
820Socket774:2010/05/15(土) 04:50:20 ID:3zWQcsbi
馬鹿だな
お前は
821Socket774:2010/05/15(土) 05:11:17 ID:trvIJ/Rs
足し算掛け算まるで駄目
バグありコピペをやらせたら
世界一!世界二!世界三!
ざ・つ・おん
822,,・´∀`・,,)っ-○○○:2010/05/15(土) 07:33:09 ID:O1FPzVWB
>>817, 819
ドライバに載る?違うな
メモリ空間の独立した自己完結したマシンが存在すると考えればいい。

いわゆる「ドライバ」はホスト-Larrabeeデバイス間を仲介するための最低限の機能のみで実装される。
データのやりとりは今研究されてるShared Virtual Memoryが使えるかもね。
まあ、古典的なMessage Passingが現時点では妥当だろうけどね。

メリットがわからんか?
ホスト独立のOSで動くアプリケーションってことは、ホストがLinuxでもMacでも同じ
コードが動くという当たり前の理屈だよ。


> つまりWindowsやLinux、Unixじゃ動かないってことか?
> そんなもん普及以前の問題だろ?誰が使うんだ?

違う、Intelにとって普及以前に【AMDに使わせる必要】がないだけだ

ホストOS側のコードはLarrabeeデバイスと通信するための最低限のコードを書くだけでいい。
ホストのAPI/ABIに左右されないという意味で圧倒的に楽な開発モデルだよ。
823Socket774:2010/05/15(土) 07:37:14 ID:AuxlY6Yx
>>813
GFの40nmの生産ラインは多分まだ本格稼動して無いし(年内に稼動)、ラインも低消費電力向けのラインだよ
CPUやGPU用で使われるラインとは別

このラインは外部から受注したものの製造に充てられる
824Socket774:2010/05/15(土) 08:01:36 ID:pDOxqhsk
最強じゃんLarrabee
なんでそれが頓挫したんだ!世の中間違ってる
825Socket774:2010/05/15(土) 08:13:03 ID:AuxlY6Yx
汎用性と消費電力は反比例だからな
826Socket774:2010/05/15(土) 08:13:07 ID:9g/6nkCY
馬鹿乙
827Socket774:2010/05/15(土) 08:14:26 ID:Xb6CfH6P
だんご、だんご、だんご、だんご
だんご、大家族〜♪
828Socket774:2010/05/15(土) 08:29:59 ID:trvIJ/Rs
汎用性(x86ということ)と引き換えに性能と開発難易度(簡易性)を犠牲にする化け物Larrabee
ttp://pc.watch.impress.co.jp/docs/2009/0305/kaigai493.htm
829Socket774:2010/05/15(土) 09:27:49 ID:avGRAhMo
>>825
ゲフォが作ったFermiが良い例だ
830Socket774:2010/05/15(土) 09:34:35 ID:pDOxqhsk
屁ルミは汎用性をあげてるけどめちゃくちゃ電気食いでしょ
831Socket774:2010/05/15(土) 10:33:02 ID:I5DBHpzZ
ドライバで仮想化するんなら
元のハードウェアがx86である必要が全くないと思うんだが
832,,・´∀`・,,)っ-○○○:2010/05/15(土) 10:51:05 ID:O1FPzVWB
> ドライバで仮想化するんなら

逆だ、「ドライバ」という概念そのものが仮想化される。
ドライバ相当の処理の大半はデバイス上のMicroOS上で自分自身で処理される。
ホストはコマンドとデータを送るだけ。


> 元のハードウェアがx86である必要が全くないと思うんだが

それは、非x86のハードウェアで
# ./configure
# make
# make install
の3コマンドでPOSIXアプリのコードがビルド&動作できてはじめていうものだ。

最適化は後回しにしてもすぐに「動かす」ことに出来る即効性こそLarrabeeの強みだ。
Fermiの汎用性なんて所詮GT200に毛が生えたようなもんだし、Cell SPEの域にも達してない
833Socket774:2010/05/15(土) 11:38:32 ID:cjgS3usT
5年後の話をしても仕方ない
834Socket774:2010/05/15(土) 11:41:24 ID:trvIJ/Rs
押入れの話に比べれば未来の話くらい何でもない
835Socket774:2010/05/15(土) 11:51:34 ID:cMxe5ppJ
組込でIntelが全部面倒見るならフルスペックのx86である必要は全く無いわな
まあLarrabeeはどうでもいいんだが……
836Socket774:2010/05/15(土) 12:53:28 ID:SWvZIvRN
5年後じゃなくて50年後なんだけどな
837,,・´∀`・,,)っ-○○○:2010/05/15(土) 13:10:20 ID:O1FPzVWB
>>835
> 組込でIntelが全部面倒見るならフルスペックのx86である必要は全く無いわな

全部を面倒見る訳じゃないからP54Cベース+最低限の拡張なんだけどね。
・既にOSレベルのコード資産がある
・ハードウェアのIPライセンスを購入してくる必要がない
・ハード技術・ソフト技術ともにこなれている

まあ、これがIntelじゃなくてIBMならPPCベースになってたかもしれないね。

もちろんモダンな汎用x86としてフルスペックである必要はない。
高速に動く必要がない命令は動くけどマイクロコードデコードとか、SunのようにMicroOSがトラップして
処理するとかでも互換性は確保できる。

Larrabeeアプリケーションを動かす上で必須でないロジックは縮小・あるいは省いていい。
それでなくともたかだか非対称2-issueのパイプラインだからデコードロジックも大幅に簡略化できそうだね。


>>836
パラダイムシフトが50年起きなければな。
性能がどうとかドライバの成熟がどうとかってのはあくまで方便であって、必要なら出すだろうし
必要に迫られなければ永久に出さずに終わると思うよ。
838Socket774:2010/05/15(土) 13:14:55 ID:pDOxqhsk
Larrabeeは10年戦うんだよ
839,,・´∀`・,,)っ-○○○:2010/05/15(土) 14:06:05 ID:O1FPzVWB
それにしてもGPGPU擁護論者の論調って数年前のPS3ファンボーイと五十歩百歩だなあと思う。
言うことがまるで変わらない。





まあ、IntelもAMDも見解が共通してるのは、CPUにおけるSIMD拡張はシングルスレッドの性能を引き上げるための
「高速化」の方策の1つであるということ。1つのトランザクションを如何に高速化できるかにつきる。

たとえば3D演算でよく使われる単精度4×4行列同士の積は、64回の乗算と48回の加算が必要だが
SSEを使うと16回の乗算命令と12回の加算命令で処理できる。AVXならその半分。
更に16並列のFMAユニットがあれば1回の乗算と3回の積和算で処理出来る。
それ以上はあっても1行列に対する演算を高速化することはできない。
その意味Haswellの256ビットFMA×2とかLarrabeeの512ビットFMAは「CPU」1コアのSIMD拡張としては最上限かもね。

これがGPUだと、数万個の4x4行列を低速・超多並列の演算ユニットまとめて処理するとかのレベルになる。
もちろんそれだけ処理の依存関係のないデータが大量にあればそれでもいいが、用途は絞られるよね。
徒歩5分の場所にある裏通りのコンビニでアンパンを1個買ってくるのに自転車ならより速く往復できるかもしれないが、
大型トラックだとかえって時間がかかるかもしれないのと同じレベル。
840Socket774:2010/05/15(土) 14:13:58 ID:4FaFvu+z
魔法はどこにもないんだよ。
Larrabeeだって例外ではない。
841Socket774:2010/05/15(土) 15:24:13 ID:cMxe5ppJ
その「用途が限定された大型トラック」が、
今までは(個数が出ないために)最新の半導体技術で作れず、
汎用のCPUには太刀打ちできなかったのに対し、
GPUの需要に便乗してCPUと同じ土俵で作れるようになった、
というところがミソなんでそ。
842Socket774:2010/05/15(土) 15:32:36 ID:trvIJ/Rs
>言うことがまるで変わらない。
アウトオブオーダ≠スーパースカラ とか
フェッチ≠プリフェッチ とか
常にPentium4にはL1Dがある とか
確かにもう言うことが決まりきっている
843Socket774:2010/05/15(土) 15:43:07 ID:FGt8tYe5
>>839
> その意味Haswellの256ビットFMA×2とか
スレ違いの話題だが、これは確定事項なのか?
Intelなら非対称で256bit FMA + 256bit FP-Add
あたりにしてくるような気がするんだが
844,,・´∀`・,,)っ-○○○:2010/05/15(土) 15:47:13 ID:O1FPzVWB
数は出てもごく一部の科学技術演算以外、ソフト屋の需要を喚起できてないのも味噌ね。
COBOLの職業プログラマ人口は世界300万人といわれてるが、CUDA人口はたったの約6万(NVIDIA調べ)だ。
SDKを試しにダウンロードしてみただけの人も含めた累計だろうから実質人口は推して知るべし。
845Socket774:2010/05/15(土) 15:58:49 ID:pDOxqhsk
AVX使えばDirt2を120FPSでプレイ可能!!
※グラフィックスカードを挿した場合
846Socket774:2010/05/15(土) 15:59:09 ID:trvIJ/Rs
>>843
その類の(コテの)レスは間違い探しとかウォーリーを探せみたいなもので
情報を得るためのもんではない
847Socket774:2010/05/15(土) 16:01:34 ID:NFxMc5aq
×コテのレスは間違い探し
○コテのレスは見る価値無いのでコテをNG登録
848Socket774:2010/05/15(土) 16:07:23 ID:cMxe5ppJ
>>844
なぜ比較対象がCOBOL。
849,,・´∀`・,,)っ-○○○:2010/05/15(土) 16:26:55 ID:O1FPzVWB
>>843
それだと乗算のスループットネックで行列積なんかの性能は基本的に上がらないからFMAの意味自体ほとんどないね。
「FMAで最大4倍」って明言してるから256bit FMA×2って説は有力。

とはいえHaswellの性能についてはいろいろ疑問があるね
安定して16SP/clkのスループットを得るには、vbroadcastss + vmulps + vaddps で
命令長を合計16バイト以内に抑える必要がある。
vmulps, vaddpsは4バイトに圧縮できるからvbroadcastssは8バイトまでに抑えれば十分できる。

しかしFMAサポートで更に2倍の性能を得るにはvbroadcastss×2 + vfmadd231ps×2を同時に発行しなければいけない。
もし同じ16byte/clkの命令フェッチ帯域だと確実に足りなくて、Loop Stream Detectorに収まるように
プログラムを組まないといけない。
逆に考えれば256bit FMA×2の実装がされるときには命令フェッチ帯域の拡張は確実に入るということ。
850Socket774:2010/05/15(土) 20:06:29 ID:KmgOqvII
>>841
東工大の論文見てると
大型トラックの荷台に荷物(データ)を隙間無くキッチリ積める作業も
馬鹿にならないボトルネックで用途の限定のされ方が半端ないけどな。
CPUと同じ土俵ってのはどうだかな。
851Socket774:2010/05/15(土) 22:36:57 ID:O1AREOqe
とりあえず、Intel版クルーソーがLarrabeeって理解でいいのかな
あっちは非x86コアでX86を動かすってコンセプトだったけど、
こっちはx86コアで非X86を動かすということになるのかな。
具体的に何を想定しているのかは不明だけど、DirectXやopenCL辺りをWinやLinuxを介さないで、
ホストOS上で実行しちゃおうってことか?

ホストOSによりLNIがユーザーからは直接見えないってことになるみたいだから、
確かにAMDがサポートする必要はないな。

そういえばホストOSは何をエミュレーションしているんだ?
x86なら、元がx86だからホストOSなんていらないし、LNIは隠れているから、x86とLNI以外なんだろうけど。
852Socket774:2010/05/15(土) 22:43:00 ID:mrZEW6kN
>>829
Fermiの場合は物理設計ミスだね
ぶっつけ本番で量産を始めてTMSCの問題に見事に引っかかってしまった

ATiは47**で一段階はさんでから5***の設計をしたからTMSCの罠を回避できた
nVidiaは後出しじゃんけんなんだからATiを見て設計しなおしを決めれば良かったのに

TMSCが悪いけどその対応で明暗が出たな
853Socket774:2010/05/15(土) 23:17:40 ID:O1AREOqe
>>852
Nvidiaも一応GT21xで予習したんだけど、AMDみたいに難題のクリアに挑戦しなかったから失敗しただけ。
挑戦したけど出来なかったんだったっけ?
まあ、何が問題でどうすれば解決できるかはAMDが教えてくれたから今度は大丈夫だろう。

>>841
最近の3DゲームはHD解像度(1920x1200)でAAやAFとかの処理も加わって、膨大な量の計算が必要だろ。
例えるなら、大量の作業員が働く現場で、毎朝アンパン1万個配達してもらう必要がある状况で、
自転車で10〜20個ずつ持ってくるよりも、ダンプで1万個まとめて持ってきた方が早いし簡単だろうってことじゃないかな。
今後はは自転車の籠が大きくなって今までの倍以上持ってこれるようになるけど、
現場の規模も大きく(3D表示、マルチ画面)なってきていて、ダンプカーの搭載量や速度も良くなってきてるから、
相対的な差は依然として大きいままってところかと。
854Socket774:2010/05/15(土) 23:47:36 ID:O1AREOqe
Larraeeのキャンセルについて
ttp://www.4gamer.net/games/049/G004963/20091212001/

初代Larrabeeは,その消費電力や発熱量の多さに対して処理性能が十分とは言えず,
「演算処理性能でも一世代前のハイエンドグラフィックス製品に及ばない状態だった」
つまり 45nm Larrabee < 55nm GT200b や RV790

最大の問題は,グラフィックスカードとして市場投入するには,DirectXのサポートなど,
ソフトウェア環境の問題が山積していた点にあるとのこと。
とあるゲームデベロッパ関係者によれば,Larrabeeは,
DirectX 10への最適化すら,十分とはいえない状態だったようだ。

ホストOSの問題なのか、ドライバの問題なのか、あるいは両方の問題なのか。
855Socket774:2010/05/16(日) 02:42:29 ID:4kX6aL3O
リャノとサンデーはどっちが強いのよ
856Socket774:2010/05/16(日) 03:02:59 ID:mKrkBjIn
CPU・・・SandyBridge>>Llano
GPU・・・Llano>>SandyBridge

別途GPUを積むならSandy優位、積まないならLlano優位
857Socket774:2010/05/16(日) 05:46:52 ID:ejo1tyIs
CPUはキャッシュだらけだからIntel有利
GPUにはキャッシュ無いからIntelズタボロ
Larrabeeにもキャッシュあるけど構想自体がウンコ過ぎて挽回出来ない
858Socket774:2010/05/16(日) 07:00:14 ID:KFqnufmG
アホ
859Socket774:2010/05/16(日) 07:47:24 ID:KFqnufmG
>AAやAFとかの処理も加わって、膨大な量の計算が必要だろ。

単なる固定機能処理だろ

>ダンプカー
>自転車

ダンプカーは良いだろうが、自転車は不適当だな
なんせクロックは3-4倍あるわけだから
スポーツカーってところだろ200-300のパンとやらをつめる
860,,・´∀`・,,)っ-○○○:2010/05/16(日) 08:52:01 ID:ZpwaxppR
>>859
問題は小回りの利きやすさだから別に走行時の速度は論じてない。
861Socket774:2010/05/16(日) 08:55:50 ID:lkGDITlc
1/25.75スピードのCPUがスポーツカー
862Socket774:2010/05/16(日) 08:59:30 ID:KFqnufmG
ちゃうちゃう、>>853の単に大量輸送のお話に対して言ってるわけ

もっとも、最寄のコンビニにアンパン買いにいく例えにたいし
大量輸送を無理矢理持ち出してるは、どうなんだってお話
863,,・´∀`・,,)っ-○○○:2010/05/16(日) 09:12:04 ID:ZpwaxppR
アンパン1個の話に喩えるならダンプカーが停めてある駐車場のほうがコンビニよりずっと遠い的なイメージかも
864Socket774:2010/05/16(日) 09:29:01 ID:ejo1tyIs
この独り言いつも気持ち悪過ぎ
865Socket774:2010/05/16(日) 09:30:26 ID:iuJQZhl3
ダンプカーやスポーツカーや自転車でパンを運ぶ例えは
どうやってもしっくりこないことが確定
866Socket774:2010/05/16(日) 09:34:35 ID:lkGDITlc
CPU・・・自動車
GPU・・・新幹線
小回りのきくCPU
直線最速GPU

適材適所ということでここはひとつ
867Socket774:2010/05/16(日) 09:38:27 ID:4kX6aL3O
CPU部分がSandyでGPU部分がLlanoなCPUがほしいです
868,,・´∀`・,,)っ-○○○:2010/05/16(日) 09:49:21 ID:ZpwaxppR
というかGPUとCPUの物理的距離が短くなろうとドライバに制御を移行する時点で大きなサイクルロスがあるからな
いくらGPGPU(笑)が物量で訴えても、制御切替の必要が無くデータ移動もゼロコストのSSEの機動力には及ばない存在。

http://pc.watch.impress.co.jp/docs/column/kaigai/20100415_361133.html
> Sandy Bridgeでは、CPUコア群とGPUコア群はL3キャッシュを共有するため、

ちなみにこれとは別にGPUは独立したL1, L2キャッシュが存在するんだけどな。
869Socket774:2010/05/16(日) 10:19:47 ID:ejo1tyIs
物量と機動力に訴えたLarrabeeは死んだ!何故か!
870Socket774:2010/05/16(日) 10:33:21 ID:iuJQZhl3
早産だっただけ
871Socket774:2010/05/16(日) 10:42:16 ID:lkGDITlc
本番は2015年でしょ
その間は布教の期間
872Socket774:2010/05/16(日) 10:53:54 ID:ejo1tyIs
早産って今更DirectX(等の非x86)潰すの無理だろ
遅れれば遅れるほど腐敗が進む
873Socket774:2010/05/16(日) 12:16:58 ID:7OslUOwh
>>868
LlanoはSSEも積んでるぞ
適材適所で使い分けろってことだ
874Socket774:2010/05/16(日) 12:42:26 ID:KFqnufmG
べつにAVX(SSE)をGPUのShaderとして使ったほうが良いんじゃないですかね
875Socket774:2010/05/16(日) 12:44:36 ID:xYWLkr+Q
それで性能が出せるんならな
876Socket774:2010/05/16(日) 12:48:46 ID:KFqnufmG
オンボードとしては十分すぎるでしょ
877Socket774:2010/05/16(日) 12:53:41 ID:lkGDITlc
絵描きはGPUに任せときゃーいいの
878Socket774:2010/05/16(日) 13:32:59 ID:gkmNEYI7
CPUがひましているなら、AVXをShaderとして使ってもいいだろうけど、
Intelと違って統合GPUの性能がそれなりにあるから、
性能が上がるかどうか微妙な気が。
879Socket774:2010/05/16(日) 14:57:29 ID:2MASbQJZ
Intelの場合はGPUドライバの出来が不安
880Socket774:2010/05/16(日) 15:03:09 ID:w+IashdN
発想を転換して、CPUにGPUの仕事をさせよう。
881Socket774:2010/05/16(日) 15:09:28 ID:1K1NSk2X
無理だった。
882Socket774:2010/05/16(日) 15:44:19 ID:7OslUOwh
SSEを代わりに使うんじゃなく追加で使えばよくね?
480sp+SSEで性能3割増しとか
性能のアンバランスさと距離の違いをどうやって制御するのかは考えない

まあ、Carkdaleの場合でさえSSE代替は785Gを超えるかどうかの性能だから、
Llanoの場合に代替しても性能落ちるし、追加で使っても1割も伸びないだろうけどな。
883Socket774:2010/05/16(日) 17:06:41 ID:KFqnufmG
>880
sandybridgeはそうなるだろ
884Socket774:2010/05/16(日) 17:28:52 ID:xYWLkr+Q
GMA統合してるのにか
885Socket774:2010/05/16(日) 17:55:01 ID:Qdl6nfsw
ワットパフォーマンスが悪化するだけだ
886Socket774:2010/05/16(日) 18:16:53 ID:7OslUOwh
Llano待ちの奴はGPUやGPGPUにも期待してるが、
Sandy待ちの奴はGPUに期待はしてない、逆に邪魔者扱い
887Socket774:2010/05/16(日) 18:20:09 ID:KFqnufmG

だれもGPGPUには期待していない
888Socket774:2010/05/16(日) 18:47:10 ID:7OslUOwh
期待している人は多い
CUDAの為にゲフォ買ってる奴も多いからな
ただ、来年すぐに一般的なソフトで普及するとか無茶は言わないだけ
動画編集やウィルススキャン、科学技術計算など身近なところからスパコンレベルまで適用範囲はかなり広い
あくまで並列処理での範囲が広いだけで、シングル処理だらけの個人向けに限ればかなり限られてくるがな
889Socket774:2010/05/16(日) 19:01:50 ID:KFqnufmG
streamが出たの何時だっけ
今無いものが、はたして・ね
890Socket774:2010/05/16(日) 19:16:14 ID:7OslUOwh
今ないから今後もないとか頭悪すぎるだろ
891Socket774:2010/05/16(日) 19:21:03 ID:ejo1tyIs
数の大小が解らない奴の片割れだぞ
892Socket774:2010/05/16(日) 19:23:18 ID:lkGDITlc
http://www.brightsideofnews.com/news/2010/5/4/amd-announces-opencl-based-stream-sdk.aspx
http://techreport.com/discussions.x/18851

いよいよFuisonのための動きがでてきた、あとはハードがでるだけ
893Socket774:2010/05/16(日) 19:25:26 ID:KFqnufmG
残念ながら今後も無いだろ
894Socket774:2010/05/16(日) 19:38:57 ID:Qdl6nfsw
今でも使ってる人は使ってる
使う人は使うというだけの話

「全ての人が使うようになる」とか「使う人は皆無」と言った極論は無意味だ
895Socket774:2010/05/16(日) 19:41:38 ID:KFqnufmG
何に使ってるの
896Socket774:2010/05/16(日) 19:47:05 ID:lkGDITlc
スパコン
897Socket774:2010/05/16(日) 19:49:28 ID:lkGDITlc
AVXもDX11もOpenCLもGLもLNIもどれも一般人には恩恵ないけど
898Socket774:2010/05/16(日) 19:51:31 ID:KFqnufmG
あーTENGAか
ttp://www.tenga-love.com/
899Socket774:2010/05/16(日) 20:00:40 ID:H4gvPdjC
>>888
AMD・nVidia・intelまったく関係ないが、GPGPUでウイルススキャンってCPU使用率減らす以外でなんかメリットあるのかな。
並列処理で高速化するかというとディスクアクセスがボトルネックになって早くならない気もする。
900Socket774:2010/05/16(日) 20:01:32 ID:7OslUOwh
恩恵はある、気づいてないだけ
まあ、オフィスソフトやブラウザしか使わない場合は無いと言えるけどな

逆にクリエイティブな仕事をする人にはかなり恩恵ある
901Socket774:2010/05/16(日) 20:10:44 ID:KFqnufmG
粗悪エンコードとか
902Socket774:2010/05/16(日) 20:18:51 ID:xYWLkr+Q
>>899
サーバ用なんじゃないの
あるいは高速SSD前提か
903Socket774:2010/05/16(日) 20:19:34 ID:qVW89+xO
>>899
はげどう。ストレージがネックになると思う。

>>900
今のオフィス向けPCは地味に高負荷だぜ?
セキュリティ向けのソフトが裏で複数動きまくってる。
904,,・´∀`・,,)っ-○○○:2010/05/16(日) 21:11:42 ID:ZpwaxppR
>>890
で、AVIVOを呼び出すだけのソフト以外で何か実用レベルの物が出た?
まあ、それ以外のソフトも時間が経てば出てくるって言いたいんだけど、
煽り抜きで、それ作ってビジネスになると思う?なるとして何年後?

ま、市場が無いから人材が育たないのか、人材が育たないから市場が無いのか。
いずれにしても必要なら何らかの金銭的支援を行うべきだよ。
NVIDIAは大学に支援することで市場を替えようとしてるね。
シリコンバレーの名だたる大学発のベンチャーが革新をもたらしてきた。

他社の後追いしてればお零れに預かれるという発想がA社を駄目にしたと思う。
905Socket774:2010/05/16(日) 21:13:15 ID:ejo1tyIs
トリップ検索ソフトを自力で作ったフリをしてるだけの人は流石に言うことが違うな
906Socket774:2010/05/16(日) 21:41:20 ID:lkGDITlc
そもそも金銭的に苦しくなった原因はどーれだ
1,Intelの他社排除的な商習慣
2,ヘクター・ルイズ
3,ダーク・マイヤー
907Socket774:2010/05/16(日) 21:46:41 ID:KFqnufmG
K8以降まともな製品開発して来なかったからじゃないですかね
昨今はATIのGPUにだいぶ助けられてるようですが
908,,・´∀`・,,)っ-○○○:2010/05/16(日) 21:52:37 ID:ZpwaxppR
NVIDIAはGPUとしての本分を捨ててでもGeForceの汎用化を進めてる。
超がつく巨大企業でもないかぎり、それだけのリスクを負わないとイノベーションは起こせない。

少なくとも保守的なアーキテクチャに留めて安全策をとるのは市場構造が変えようという姿勢ではないね。
てっぺんがあからさまな安全策をとって、どこのソフトウェアベンチャーがリスクをおかしてくれるのか。
主体性がないとしかいいようがない。
909,,・´∀`・,,)っ-○○○:2010/05/16(日) 21:56:03 ID:ZpwaxppR
>>906
訴訟対象になってたIntelの商習慣が云々のときは単価10万オーバーのCPUをデスクトップ市場に投入して
絶好調だったじゃないですか。

本当に帳簿が赤くなったのは実力で押され出してからでしょう。
910Socket774:2010/05/16(日) 21:58:00 ID:uUorkqnX
イノベーション()笑
市場構造の改革()笑

いくらなんでも踊らされすぎてる
911,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:05:24 ID:ZpwaxppR
誰が踊ってるって?
俺にいわせればNVIDIAの対応すら生温い

ソフトが出てくるのは「GPGPU=儲かる」の公式がソフト業界に浸透されたときだ
動くソフトを選ぶようなアーキテクチャ作ってる時点で自ら市場を狭めているわけだ。

まあ、本当にソフト屋に優しい何でも動くような汎用性をもったプロセッサ作ったところで
それこそ水膨れFLOPS数ぬきでx86やARMとガチ勝負しないといけなくなるだけだと思うけど。
912Socket774:2010/05/16(日) 22:06:03 ID:2MASbQJZ
Intelの商習慣が問題になったのはK7あたりの古い時代からの話でしょ

「訴訟を起こしたのは、K8が出て実力付いてきた今こそ
ゴネ得と言われずに済むから」
みたいな事をAMDの人が当時言ってた気がする
913Socket774:2010/05/16(日) 22:06:55 ID:dt4EyQBQ
>>907
GPU以外全部ダメの間違いじゃないか?
CPU部門はSocket939時代以降どれもこれもパッっとしないんだよね
焼き直しの置き直しなんてしているからこんな事になる・・・
914Socket774:2010/05/16(日) 22:11:04 ID:uUorkqnX
アホ過ぎる

自分で指摘した罠がララビにもあるのに
915,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:21:48 ID:ZpwaxppR
そもそもIntelにとってはGPGPUを邪魔できればいいので
Larrabeeの投入自体は本質ではないと思われ

同じx86ベースならXeonのほうが圧倒的に儲かるからな。
916Socket774:2010/05/16(日) 22:28:25 ID:GMe8Y3/O
Intelの商習慣が問題になったのはK6からじゃなかったっけ
起訴で他社に嫌がらせ、リベートで他社排除
それらがあって今があるんだろ
917Socket774:2010/05/16(日) 22:29:24 ID:7OslUOwh
>>907
まともじゃないX6にまともなi7が価格競争を強いられてるんだぜ
918Socket774:2010/05/16(日) 22:31:39 ID:lkGDITlc
MIMD寄りになれば驚異そのものだからな
NIやFermi3のときもまた足を引っ張るわけか
919Socket774:2010/05/16(日) 22:32:15 ID:uUorkqnX
あらら、イノベーションは何処へやら
920Socket774:2010/05/16(日) 22:35:16 ID:LpIp+EkN
次のMSのゲーム機に採用される奴が勝つ。 Windowsでは。
921,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:40:22 ID:ZpwaxppR
>>919
本音を言うとそもそもGPGPUがソフト市場で成功するとは全く思っていないのよ。
いってしまえばNVIDIAのやってることは無駄な足掻きにすぎん。

ちなみにIntelはLarrabeeを投入する理由をGPGPUを牽制するためと初っぱなから公言してるからな。
潰すべきGPGPUソフト市場が存在してない段階で投入する意味はないわな。
もう32コアCellの計画も存在しないし、トップ500に占めるXeonのシェアはどんどん上がっていく。
922Socket774:2010/05/16(日) 22:42:20 ID:7OslUOwh
>>908
> NVIDIAはGPUとしての本分を捨ててでもGeForceの汎用化を進めてる。
> 超がつく巨大企業でもないかぎり、それだけのリスクを負わないとイノベーションは起こせない。
>
> 少なくとも保守的なアーキテクチャに留めて安全策をとるのは市場構造が変えようという姿勢ではないね。
> てっぺんがあからさまな安全策をとって、どこのソフトウェアベンチャーがリスクをおかしてくれるのか。
> 主体性がないとしかいいようがない。

どんなに汎用化を進めてもGeforceは所詮は外付けのアクセラレーターでしか無い
CPU自体にそれなりの能力があれば必要性はかなり減る
誰もが高性能なGPGPUを高い金出して買うわけじゃない、そんなのは極少数
廉価CPUにそれなりのGPGPUがついてきたら殆どの人はそれで満足数だろうな

来年は出始めだからシェアはたいしたことないけど、再来年以降はほぼすべての新規ノートPCはFusion CPUになる。
デスクトップだって流用されるからそれなりの数になる。
AMD CPUのシェアが20%のままでも、全世界で数千万台の規模になり、GPUも含めると1億台に近くなる。
その全てでDX11、OpenCLに対応出来るわけだから、イノベーションを起こすには十分だろ。
923,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:42:32 ID:ZpwaxppR
>>920
Tegraのことか
924Socket774:2010/05/16(日) 22:44:00 ID:uUorkqnX
なんだか暗にAMDの路線を肯定してるがな

今日は絶不調だな
925Socket774:2010/05/16(日) 22:44:41 ID:lkGDITlc
Larrabeeが統合されないという可能性もあるわけか
926,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:45:12 ID:ZpwaxppR
日本国内PCメーカーの夏モデル見ただけでもIntel一色だけどな
AMDって信用無いんだなと思ったわ。
927Socket774:2010/05/16(日) 22:47:29 ID:uUorkqnX
ゲーム機と携帯の区別まで失ったか
かなり不調っぽいね
928,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:48:37 ID:ZpwaxppR
スマートフォン=ゲームプラットフォームだよ
iPhoneのソフト市場は既にPSPを越えてる
929Socket774:2010/05/16(日) 22:50:23 ID:AYIBxwq3
数はともかく、金額ベースでは
苦し過ぎなんじゃね。すでに
勢いが無くなって、みんな
ソーシャルゲームに移ってるみたいだし。
930Socket774:2010/05/16(日) 22:51:42 ID:1K1NSk2X
>>922
> 廉価CPUにそれなりのGPGPUがついてきたら殆どの人はそれで満足数だろうな
Ionですね。

>>928
iPhone向けゲームビジネスは非常に苦しいっす……
931Socket774:2010/05/16(日) 22:53:23 ID:uUorkqnX
また画期的過ぎる解釈だ

やっぱ好調なのね
932,,・´∀`・,,)っ-○○○:2010/05/16(日) 22:54:42 ID:ZpwaxppR
過当競争で厳しいのと、過疎かつ高コストで厳しいのとどっちがマシか
・・・どっちもクソだな
933Socket774:2010/05/16(日) 23:03:46 ID:uUorkqnX
ゲームユーザーが去ったら買い替え周期ってどうなるんかな?
934,,・´∀`・,,)っ-○○○:2010/05/16(日) 23:16:49 ID:ZpwaxppR
たぶん次世代もゲーム専門機としてやっていこうと考えてるのは任天堂くらいしかないと思うよ

ただ据え置き機のXboxは「安いパソコン」化だけはしないと思うけどね
PS3が自社開発のブラウザやBDプレイヤーを搭載しても
360はIEを載せなかった

競合他社と競争するために自社製品の市場を自ら切り崩すような本末転倒なことはやらないのはMSもIntelも同じ。
935Socket774:2010/05/16(日) 23:17:22 ID:HvjnAPpu
>>926
結局ダンゴのCPU選びは性能、コスパ等ではなく、「みんなが使っているから」という理由か…。
936Socket774:2010/05/16(日) 23:19:59 ID:uUorkqnX
思うよwですか

開発ヤメタって話を聞いてきたのかと思ったがな
なんだか詳しそうなんだし裏を取ってきてよ
937,,・´∀`・,,)っ-○○○:2010/05/16(日) 23:38:19 ID:ZpwaxppR
>>935
安いだけならAtomで十分なんだ。ごめん。


メーカーの視点でいうとこうかな
Core i3/i5/i7・・・メインストリームからパフォーマンスレンジまで同じソケットでカバー
 グラフィック性能が必要ならディスクリートカードを刺せばいい
Celeron・・・前世代のCore 2ベースの筐体設計がそのまま使い回せる

低価格路線に転じたAMDが採用されるかどうかは、Intel IGP以上ディスクリート未満の
統合GPU性能のために別途筐体設計をする価値があるかどうかにかかっていると思うよ。

そもそも(ネットブックを除いた)ノートPCの消費者はGPU性能を殆ど必要としてないビジネスユーザーが
かなりの部分占めてるんだし、GPUが強力になれば売れるなんて発想はファンボーイ1人が願っても
ベンダーはそうは思わないのが現実。
780G/790Gでシェア奪還出来てないことを、CPUアーキ変わらないまま
CPUくっついてから本気出すとか言っても何も変わらん。
938Socket774:2010/05/16(日) 23:44:09 ID:uUorkqnX
ゲームしたい人が日本メーカーのPCを買うのか?

なら日本メーカーはIntelを選ぶわな
939Socket774:2010/05/16(日) 23:44:26 ID:GejGQplU
団子のゲーム業界やGPUに関するコメントを意訳すると「intelの軍門に降らない業界など潰れてしまえ」って言ってるだけだしな。

例えばGPUに関しては「GPGPUなんてCPUの仕事を奪うようなことは止めてGPUとしての仕事だけしてればいい」と言いつつ
「だけど、GPUとしての仕事は今後CPUがやるから、GPUはお役ご免になってくれ」だからね。

この二つを重ねれば、「俺(CPU)はお前(GPU)の仕事を奪うけど、お前(GPU)は俺(CPU)の仕事を奪うなよ」と言ってるだけ。
940Socket774:2010/05/16(日) 23:46:13 ID:uUorkqnX
Intelがゲーム業界に溶け込めなかったから機嫌が悪いんじゃね?
941Socket774:2010/05/16(日) 23:51:31 ID:GMe8Y3/O
日本でAMDが採用されないのは供給量に問題があるからじゃないの
過去のIntelの汚いやり方も関係してるけど
まあ、セレロン大国の日本じゃCPUなんかは一般人には関係ないかw
942,,・´∀`・,,)っ-○○○:2010/05/16(日) 23:53:02 ID:ZpwaxppR
IGPを全面に打ち出したいならSandy Bridgeのセカンドソース契約して
GMAの代わりにRadeon載っけた製品でも作ったらいいんじゃないの
CPUはビックリマンチョコじゃないんだから「おまけ」目当ての消費者を当て込むのは間違い
943Socket774:2010/05/16(日) 23:54:36 ID:uUorkqnX
それが出来るならやってますがな

Intelが自殺志願者に見えるなんてやっぱ不調か
944Socket774:2010/05/17(月) 00:08:47 ID:Keesg2kH
何をどう批判してバカにしても結局Fusionを肯定するしかなくなるからな

>>928
スマートフォンで多数を占めるSnapdragonのGPUコアはXBox360互換でRadeon互換
ライセンスは譲渡しているけどね
アーキテクチャに共通点が多いから、移植やらクロス展開がとてもしやすい
結局ATIアーキテクチャがゲーム市場の多数派であることは変わらないんだよ

>>930
IonはCore2と一蓮托生で今後先細りで来年死ぬ
Ion2は低性能外付けでしか無いからやっぱり来年死ぬ
945Socket774:2010/05/17(月) 00:11:52 ID:Keesg2kH
団子はAMDプラットフォーム採用のノートPCのモデル数が50から100に倍増したのを知らないのか
ノートベンダーの90%がDX11 GPUに興味があるのを知らないのか
946,,・´∀`・,,)っ-○○○:2010/05/17(月) 00:13:12 ID:3wc/5yYP
>>943
じゃあ逆にRadeonのIPをライセンスしてマージンを取るんだ!
・・・どっちも無いな

しかしAtomあたりに関してはTSMCに委託してるし、Ionとかの統合化とか含めあり得ん話じゃない
947Socket774:2010/05/17(月) 00:15:53 ID:Keesg2kH
>>945
残りの10%は日本メーカー
948Socket774:2010/05/17(月) 00:16:23 ID:FILsXdwQ
TSMCに委託ってIOチップじゃん
949Socket774:2010/05/17(月) 00:19:38 ID:Keesg2kH
>>946
> >>943
> じゃあ逆にRadeonのIPをライセンスしてマージンを取るんだ!
> ・・・どっちも無いな
自社ハードですらろくにドライバも作れないIntelにVLIWでめんどくさいRadeonは到底扱えないよ
IntelはおとなしくRadeonと組合せてりゃいいんだよ

> しかしAtomあたりに関してはTSMCに委託してるし、Ionとかの統合化とか含めあり得ん話じゃない
TSMCのAtomは委託して1年間顧客がつかなくて頓挫したのを知らないのか?
950,,・´∀`・,,)っ-○○○:2010/05/17(月) 00:23:24 ID:3wc/5yYP
> VLIWでめんどくさい

GPGPUとして成功しないと思ってる最大の理由を俺より先に言ってくれて感謝する
951Socket774:2010/05/17(月) 00:26:50 ID:b326rUUL
>>934
でも任天堂が一番ゲーム専用機から遠いよな、ある意味。
952Socket774:2010/05/17(月) 00:36:25 ID:zlIuTqZl
>>951
何で?
953,,・´∀`・,,)っ-○○○:2010/05/17(月) 00:37:53 ID:3wc/5yYP
WiiFitは健康器具だとか言ってる人ですか
ぶっちゃけ、ある意味あれは究極のやり込みゲーだよ
954Socket774:2010/05/17(月) 00:53:33 ID:WKynwCVX
WiiFitの耐荷重オーバーしちゃっている人なんだろうね
なんだか可哀そう
955Socket774:2010/05/17(月) 01:36:38 ID:sxgXVv+x
Fusionってのが少ししたらでるから、安いマザボとCPUにしといてあとで取っ替えろ
っていわれたんだがあってるの?
956Socket774:2010/05/17(月) 02:05:44 ID:+HqmAlZT
>>945
これってIntelの製造が追いついてないからじゃないの?
957Socket774:2010/05/17(月) 02:28:49 ID:Keesg2kH
>>950
最大の理由はマーケティングが弱いことだろ
VLIWは扱いが難しいだけで大した理由にはならないよ
マーケティングが強いとX2よりPenDが売れるし、リネームやメモリバス削減詐欺でも売れるんだからな
958Socket774:2010/05/17(月) 02:29:48 ID:Keesg2kH
>>955
間違いだよ
今のマザーにはどうやったって載らない
959Socket774:2010/05/17(月) 02:31:10 ID:Keesg2kH
>>956
アランが追いついてないだけ
Core2機増やせばいいだけでAMDとは関係ない
960Socket774:2010/05/17(月) 07:20:00 ID:5iQNvVP1
VLIWは使い物にならないだけで
AMDも切捨て路線ジャン

MIMID、MIMD騒いでるが
まじめにMIMDならその複雑さはlarrabeeなんかの比じゃない
961Socket774:2010/05/17(月) 07:28:14 ID:b326rUUL
WiiFitは欲しいけどマンションだから無理やねん。
962Socket774:2010/05/17(月) 07:35:16 ID:plNa4WAz
>>960
明らかに日本語になってない何かの言葉をクシし
算数の出来ないウンコといつもコンビを組んでるIDだということを猛烈にアピール
963Socket774:2010/05/17(月) 07:52:23 ID:DLpiD8YC
Larrabeeで団子のトリを解析するのが夢です。
964Socket774:2010/05/17(月) 08:09:35 ID:7yZbaySn
Intelは複数の工場をローテーションさせ、常時4工場以上稼動させている
対してAMDは1工場

マーケティングも何も、今の生産能力じゃ何をやっても無意味
GFの新工場と買収攻勢に期待
CPUの戦場で勝敗を決めるのは製造の方であってアーキテクチャーなんておまけ
965,,・´∀`・,,)っ-○○○:2010/05/17(月) 08:45:05 ID:3wc/5yYP
>>957
Pentium Dは既に動くソフトが存在してたろ。何が言いたいんだね?

Radeonは十分なシェアは確立してるがGPGPUとしてのソフトはほぼ皆無。
一般消費者にとってはVLIWプログラミングするために買ってる訳じゃないからGPGPUとして日の目をみるかどうかどうかは全くの別問題。

ひとつの事実として、NVIDIAは、VLIWを辞めた。
理由は明快。VLIWは汎用的なコードのプログラミングに向かないからだ。
966,,・´∀`・,,)っ-○○○:2010/05/17(月) 08:55:22 ID:3wc/5yYP
>>964
Core 2, Xeon(Woodcrest)の登場以降、製造キャパが余りまくって赤字になったのに
売れない製品を大量に作ってもゴ○になるだけでしょう?
967Socket774:2010/05/17(月) 09:17:14 ID:plNa4WAz
ほんとに妄想とバグしかないな
968Socket774:2010/05/17(月) 09:20:12 ID:E0lGA2sk
VLIWが汎用的なコードのプログラミングに向かないってのは事実なんだろうけど、
汎用性に振りすぎた初代Larrabeeは電力効率とか(他にも理由はあるだろうが)で市場に出なかったし、
今は業界全体で汎用性と効率を両立したプロセッサのアーキテクチャとプログラミングモデルを模索してる段階なんじゃない?
969Socket774:2010/05/17(月) 09:31:38 ID:bIlQe8x7
製造原価そのものは安いので値下げするという手がある。
値下げして売れるならな。
970Socket774:2010/05/17(月) 14:53:05 ID:GGyEh0/6
>>964
現時点でドレスデンのFab1とチャータード合併により得たFabが、Fab2〜7。
NYの建設中のFabがFab8扱いになります。見事な嘘をありがとう。

ちなみに、Fab1はFab36及びFab38と呼ばれていたモノなので、
実質的に2工場分の生産キャパを持っているといっても過言ではないでしょ。
フル生産でx86市場でシェア50%を狙えると豪語していたFabだし。

まぁ。そのFab36/38がAMDの経営を圧迫していたんだけどな!
971Socket774:2010/05/17(月) 15:42:59 ID:plNa4WAz
圧迫させるために稼動させる世界というのが「押入れ」
972Socket774:2010/05/17(月) 16:21:33 ID:EX3ipWUh
ATIがずっとVLIWを続けるって前提なのが面白い
973Socket774:2010/05/17(月) 16:47:36 ID:plNa4WAz
スレッドは無数にあるけど1スレッド内では依存性が強い
という状況では
NVのアーキではスレッドを次々と作って演算器を余さず使えるのに対し
VLIWでは複数スレッドを1命令に収めることは出来ないだろうから
1ユニットだけ動いてて他の4ユニットは暇を持て余してるという状況になり効率が悪い

しかしベクタでなくても1スレッド内でとにかく並列度が高い状況が続くのなら
VLIWは非常に効率が良い
3D描画でラデがゲフォをボコっている通り(ゲフォFXは何故か失敗したようだけど)

GPGPUではNVのやり方が正しいのならVLIW続けるのは無いだろうけど
だったら16ベクタユニットが1つと2つのスカラユニットしかないララビなんかもっと酷いんじゃないか?
974Socket774:2010/05/17(月) 17:12:31 ID:7yZbaySn
>>970
その中でCPU製造用なのはFab1だけ

でもってFab1はAMD時代に建物こそ2工場分建設されたが、拡張された2工場目は建物だけで中身は無し
※現在はラインが作られ、年内に稼動

バルク用や200_ウェハ用の工場ならいくつか有るが、現行のCPUは作れない
975Socket774:2010/05/17(月) 18:08:39 ID:SGXMoGrS
アホ乙
976,,・´∀`・,,)っ-○○○:2010/05/17(月) 18:18:21 ID:3wc/5yYP
>>974
こういうことだろ?
http://www.itmedia.co.jp/news/articles/0704/10/news020.html
キャッシュフローが滞ったら何もできないってこと。




&馬鹿ニートの相手などする気は更々無いが

http://www.atmarkit.co.jp/fcoding/articles/parallel/03/para03c.html

> T10のSIMT上で動く各スレッドは独自のarchitectural stateを持っているため、各スレッドそれぞれが
> 独自のループ処理や条件分岐を行うことが可能です。ただし、命令デコーダを共有しているため、
> 各スレッドが独自の処理を行った場合並列実行にはなりません。T10の性能を引き出すためには、
> 一定数(T10では32個)のスレッドが同じ命令を実行する必要があります。


NVIDIAのいうスレッドの考え方でいいならLarrabeeは1コアあたり16スレッドを同時処理できる(笑)
「SIMT」は要するにSIMDにおける並列リソースの各要素をスレッドと呼んでるだけでのもので
メモリからの読み書き時にデータを再パックして処理しているだけ。
更に中村氏のいう「architectural state」って実は要素独立のプレディケートビットマスクでしかなかったりする。

データの再パッキングと要素単位のプレディケーションを備えたSIMDエンジンはSIMT(笑)になりうる。
SSE4でもこの辺は大幅に強化されてるので、ある意味でCore 2 Quadも16コアのSIMTアーキテクチャということになる(笑)
(実際OpenCLではそういう割り振りが可能)
977Socket774:2010/05/17(月) 18:27:21 ID:plNa4WAz
NVアーキと同じ様に
スカスカSIMDもといSIMMユニットのメモリロード待ちに別スレッドを作り
別の命令でSIMMを埋めることが出来る世界が押入れ
流石は隆盛(たかもり)くん目当てでデータ並列=タスク並列なショタホモである
978,,・´∀`・,,)っ-○○○:2010/05/17(月) 18:31:17 ID:3wc/5yYP
正確に言うとLarrabeeは4Wayのハードウェアマルチスレッド×16Wayのソフトウェアマルチスレッド(笑)で64 thread/coreかな
普通のCPUのように1つのプログラムフローの中で並列演算リソースを全て使うようなプログラミングスタイルを行う自由度は与えられていないので
GeForceのSIMTはむしろSIMDの劣化版と見ることもできる。
979,,・´∀`・,,)っ-○○○:2010/05/17(月) 18:35:09 ID:3wc/5yYP
plNa4WAz←ニート発狂wwwww
980Socket774:2010/05/17(月) 18:38:36 ID:EX3ipWUh
雑音風味が効いてるな
981Socket774:2010/05/17(月) 18:42:10 ID:DLpiD8YC
三交代制って言ってたよな
982,,・´∀`・,,)っ-○○○:2010/05/17(月) 18:43:11 ID:3wc/5yYP
脳内乙
983Socket774:2010/05/17(月) 18:46:59 ID:plNa4WAz
自分で持ってきたソースも全く読めずに
1年近く妄想漏らし続けるキモホモ

202 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2009/07/22(水) 06:59:49 ID:3rqpGJeJ
ここでも読んでおきな
http://www.4gamer.net/games/050/G005004/20080614003/
(以下略)


>「任意の要素数のベクトル演算を,SM(のIU)がデコード。
>支配下となる8基のSPから,必要な数だけを活用して実行スレッドを発生させ,
>SPが余っていたり,SPがメモリアクセスを発注していて,その結果が返ってくるまでストールしていたりするのを検知すると,
>IUは次の命令を受注し,SPを活用すべく別のスレッド発生させる」

>SIMDでは,ベクトル演算器の得意とするベクトル様式に,データ側を調整する必要がある。
>例えばSSEだと4要素ベクトル演算器で処理系が実装されているため,
>すべての演算器が活用されて,最高のパフォーマンスが得られるのは,演算対象となるデータが4要素ベクトルのときに限られる
>(※あるいは2要素ベクトル×2セットなど)。
984,,・´∀`・,,)っ-○○○:2010/05/17(月) 18:54:51 ID:3wc/5yYP
>  SIMDでは,ベクトル演算器の得意とするベクトル様式に,データ側を調整する必要がある。
> 例えばSSEだと4要素ベクトル演算器で処理系が実装されているため,すべての演算器が活用されて,
> 最高のパフォーマンスが得られるのは,演算対象となるデータが4要素ベクトルのときに限られる
> (※あるいは2要素ベクトル×2セットなど)。

GeForceは4要素じゃなくて32要素ベクトルになるだけだけどな。
データの再パッキング(たとえばx, y, z, wを砕いてxだけ32個、yだけ32個・・・)を抽象化してるだけにすぎない。
LarrabeeにはGather/Scatterを1発でできる命令が標準で備わっているのでGeForceと同じことができる。

夜中だろうと平日日中だろうと休み無く2chで働く人乙
985Socket774:2010/05/17(月) 18:55:57 ID:HU/8I3+x
団子しっかりしろ。地が出てるぞ。
986Socket774:2010/05/17(月) 19:00:57 ID:7s+/xE5J
>>981
雑音が3人いて三交代24時間態勢なのかと思った。
雑音が単一人物でも、読む価値無しなコテ(NG済)が2名ぐらいいるから計3名か。
987Socket774:2010/05/17(月) 19:00:59 ID:plNa4WAz
過去のウンコが持って来たソースvs今のウンコの妄想
勝つのはどっちだ
988,,・´∀`・,,)っ-○○○:2010/05/17(月) 19:21:45 ID:3wc/5yYP
CUDAのいうwarp=従来CPUやLarrabeeでいうthread
CUDAのいうthread=Larrabeeでいうstrand

まあ、言葉遊びだな。

> SPがメモリアクセスを発注していて,その結果が返ってくるまでストールしていたりするのを検知すると,
> IUは次の命令を受注し,SPを活用すべく別のスレッド発生させる」という仕組みが採用されているのだ。
> この仕組みにより,SMは常に複数の実行スレッドを請け負い,休みなく“働く”ことになる。

このスレッド切替機構もwarp単位の話で、原理的には広義のSMT(IntelでいうHT)と同じ。
完全に命令ストリームの独立した「スレッド」を同じ房にぶら下がったSPで別々に処理できることを意味しない。

俺の言うことが矛盾してるように見えるのは要するに本質がわかってないということだ。
989Socket774:2010/05/17(月) 19:22:32 ID:3q6TjB9e
団子、いつのまにかすっかりいつものテヘに戻っているなw
990Socket774:2010/05/17(月) 19:28:38 ID:plNa4WAz
「4亀ソースにあるように
ゲフォはSMTスーパースカラに似た処理が出来る
ララビも同様にSIMM内でスーパースカラが出来る」

以上、24時間営業から突然夜間営業のみになった押入れからの念仏中継でした
991,,・´∀`・,,)っ-○○○:2010/05/17(月) 19:30:03 ID:3wc/5yYP
>>989
> 俺は人物の区別もできない馬鹿です

まで読んだ
992,,・´∀`・,,)っ-○○○:2010/05/17(月) 19:42:49 ID:3wc/5yYP
CUDAのSIMTがSIMDそのものなのは中学レベルの英語すら読めない人以外では公然たる常識
http://forums.nvidia.com/index.php?showtopic=93655

押し入れの中ならぬゴミ溜めの部屋で布団被ってネットの向こうのAMDスレのパトロールしてる人は違うのかもしれないけどね
993Socket774:2010/05/17(月) 19:55:28 ID:plNa4WAz
>SMT(IntelでいうHT)と同じ。
何故かいきなり正しい発言が飛び出した
「複数スレッドで暇な演算器を有効利用する」と
現実世界のソースのどれもが言ってることと合ってる
ただしここだけ

ttp://pc.watch.impress.co.jp/docs/2008/0702/kaigai451.htm
CPUでいうμOPsをスレッド
CPUのスレッドをワープと言っているようだけど
このワープ(スレッド)をアウトオブオーダ(≠スーパースカラ)で動的に扱うらしい

ウンコはベクタ演算すら理解してない気がするんだがまあいつものことか
994Socket774:2010/05/17(月) 19:55:53 ID:5iQNvVP1
AMDもSIMDっちゃSIMDなんよ
16way中に更に5wayの演算器とか非常にめんどいけど
995,,・´∀`・,,)っ-○○○:2010/05/17(月) 19:57:33 ID:3wc/5yYP
>plNa4WAz
もう良いよ顔真っ赤だぞwww

よく頑張ったからAMDのスレの警備なんてしなくていいから自宅の警備に戻れwww
996Socket774:2010/05/17(月) 19:58:01 ID:5iQNvVP1
スレッド粒度は
larrabee 16
cuda 32
stream 320
997Socket774:2010/05/17(月) 20:05:13 ID:DLpiD8YC
ゲルシンガーの夢は団子の中でまだまだ生き続けている
998Socket774:2010/05/17(月) 20:08:01 ID:bIlQe8x7
丁度良いところに、ぽっ、と出てきただけだろうけど、
IntelはセカンドプランとしてPowerVR使い続けるという手があるだろうな。
あれもドライバでOpenCL対応とかやるんでしょ?
999Socket774:2010/05/17(月) 20:14:41 ID:5iQNvVP1
GPUの根幹をPowerVRで作って
固定機能多目、最低限のEUをGPUブロックにのせ
必要ならばCPUの演算器を使うってのはいいと思う
1000Socket774:2010/05/17(月) 20:15:01 ID:plNa4WAz
1000
10011001
1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。

         自作PC板@2ch http://pc11.2ch.net/jisaku/