だんご三兄弟また来るのかな?
AMDじゃなくてATi Streamなんだな。
でも今のNVってシェアとってるっつーよりお笑いをとってるかんじ
団子は無理にGPGPUをほめなくていいのに
消去法でCUDAしかのこらない
褒めてねえ
GPGPUなんてのは過渡期の技術であって最終的に残るのは並列化プログラミング言語・フレームワークだ。
IntelもAMDも過程は違えど最終的に目指してるのはグラフィック処理にも汎用コンピューティングにも使える
ワイドなベクタエンジンをCPUに完全統合することだぜ。
しかし今はハード面もソフト面も期が熟してない。
まして利益率の高い上位CPU/チップセットがディスクリートGPUに依存しており、PCIe 3.0への
対応も進めている現状で、IGPが市場シェアの大半を握ってしまうシナリオはIntelすら望んでないだろ。
x86に関してIntelが主導権を持っている以上、LarrabeeのSIMD命令が最終的に各社共通の
プログラミングインターフェイスになる可能性は高いとは思ってるから、
持たざる者であるNVIDIAの悪足掻き自体はわりと無意味かなと。
>>6 団子の言ったそばから・・・
実は団子はATi Streamの開発者なんじゃ
wwww
AVX関連のソフト技術は当分ちょっとした飯の種なんで
正直うちのお客さんにはGPGPU云々は言い出さないで欲しいかな
現段階では。
あ、別にそんな理由でディスってるわけじゃない
そういうのは精神科の医者とだけやり取りしててくれ
結局は私情か
壁か空気を相手にしてくれ
医者が何とか治療しないと
それまでずっとPC関係のコミュや大阪周辺の小さい男の子が被害を受ける
とくにショタには大問題ってかカンペキ犯罪だし
>>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も優れたハードを開発し続ければ存続できるよ
> X86は殆ど関係ないと思うが
将来の統合プロセッサでx86のSIMD命令を直接実行することをマニフェストとして掲げたのはAMDだぜ。
それでSwiftでSSE5そのものを実行できると勘違いした奴が沸いたのが一昨年くらいの話。
ショタホモ家の花壇ではコードネームSwiftはSSE5が実行出来ないことになってたの?
何で?
「SSE5そのものを」って書いてあるもんだから
ソース見ずにうまく皮肉ったつもりだったけど
ググったらSSE5自体がSwift含むK10をスルーでBullから搭載じゃねーか
と、また池沼の人が自爆しました
>>19 1年前の話なんか誰も覚えてねーよ
技術革新や市場動向、開発の進捗で方針転換なんて日常茶飯事の業界でマニフェストに意味なんかない
それ言ったらIntelだってよくやるだろ、1年前ってLarrabeeで大嘘こいてた時期じゃね?
お前もさんざん調子のいいこと言ってたよな、そのLarrabeeは今どうなってる、何処にも売ってないだろ?
google先生でもぜんぜん出てこねぇぞおい
ていうか
AMD
x86コアを小さい頭とし
非x86コアを操るのが最終目標
Intel
x86デコーダてんこ盛りにした水ぶくれコア数種類で
ヘテロを形成するのが最終目標
NVIDIA
今のところx86無関係
てことで> X86は殆ど関係ないと思うが は別に間違って無いんじゃね?
ちがう、SwiftでSSE5を実行云々の書き込み
RadeonとK10を同じダイに載せてすぐにコプロとして操れるようにしたとしても
非x86なGPUは一生SSEなど発行しないのが現実世界
つーかあれだな
>21-22のリロード連打では
相手の「ミスった」発言のみに反応してるだけで
内容全く理解してないんだな
>27
明確な記事は無いけど
その件の発言はそれなりにあった
GPUにX86やSSE使わせるぐらいならCPUのSIMDを強化するだろうからな
> それ言ったらIntelだってよくやるだろ、1年前ってLarrabeeで大嘘こいてた時期じゃね?
> お前もさんざん調子のいいこと言ってたよな、そのLarrabeeは今どうなってる、何処にも売ってないだろ?
何熱くなってるのよ?
Larrabeeは最初から統合プロセッサが前提でディスクリートは競合の牽制のためだってのは最初から明らかだったよ。
牽制する必要自体が無くなってしまったら出す理由がないだろう。
言ってるだろハードは本質じゃなくて問題はソフトだと。
去年の今頃AMDがAVXサポートを表明したことで、Larrabeeの命令セットも含め、将来にわたって
Intelとの命令セット互換を維持する可能性が高くなった。
x86からGPUにアクセスできる命令セットが必要なのはAMDも同じでIntelに歩調あわせたほうがいいからな。
戦わずに勝つのが最良の兵法だぜ?
個人的興味からすれば残念ではあるけどな。
まーたやばくなったときの団子饒舌ショーが始まったよ
AMDの場合GPUコアとCPUコアが独立しているからx86に拘る必要もないんだよな
ぶっちゃけARMやPower、Sparcコアと同居させることもできる
AMDがARMやPowerのライセンスを受けるか、他社がGPUコアのライセンスを受けるかすればだけど
多分AMDのFusion構想のかなり先の展開がそれ、X86でのFusionはその足がかりだと思う
その一例がSnapdragon。
まあコアは売却したからライセンスじゃないけど、あんな風にGPUコアのライセンスを事業として立ち上げれば面白そうだ。
ハードとしての成功例はあるわけだし、他にも使いたいところが出てくるんじゃないかな。
逆にIntelはx86と一蓮托生、なんせCPUコアと密接に融合しているから他のコアへの転用はほぼ不可能
饒舌ってかただの躁病にしか見えないんだが
>>31 > Larrabeeは最初から統合プロセッサが前提でディスクリートは競合の牽制のためだってのは最初から明らかだったよ。
> 牽制する必要自体が無くなってしまったら出す理由がないだろう。
ものは言いようだなw
ソフト環境がグダグダだったって話だが、DX10ですらまともに動かなかったらしいぞ
> 言ってるだろハードは本質じゃなくて問題はソフトだと。
> 去年の今頃AMDがAVXサポートを表明したことで、Larrabeeの命令セットも含め、将来にわたって
> Intelとの命令セット互換を維持する可能性が高くなった。
> x86からGPUにアクセスできる命令セットが必要なのはAMDも同じでIntelに歩調あわせたほうがいいからな。
まあ、シェア的に似たような拡張競争しても負けは濃厚だからね互換路線は仕方ないさ
ただ、Bullでの実装を見ると、互換路線は性能それなりレベルで片手間って感じだな
> 戦わずに勝つのが最良の兵法だぜ?
> 個人的興味からすれば残念ではあるけどな。
AMDがIntel互換(SSE/AVX)とGPGPUどちらに重きをおいてるかは火を見るより明らかだろ?
要はまだ戦ってもいないということだ。
来年のLlano vs Sandyがその初戦とも言えるし、それまで妄想で楽しめばいいんだよ。
団子非表示にしてるのにご丁寧に片っ端から引用している馬鹿がいるな。
>>30 曰く、CPUのSIMDを強化しても一部の科学技術計算やゲームにしか使えない罠。
でもGPUと演算リソースを共有してやれば、グラフィックを使う多くのプログラムで演算リソースを
有効に使える機会が増える。Fusionの発想はそっから来てる。
フロントエンドをx86側とGPU側で別々にしてバックエンド(演算ユニット)のみ共有というモデルをとってもいい。
無理にLarrabeeのようにGPU自体を「SIMDがおばけなx86」で構成する必要はないだろう。
しかし演算ユニットはx86の内部オペレーションを効率よく実行出来るように作り替える必要がある。
どのみち似たようなところにいきつくだろ。
> 来年のLlano vs Sandyがその初戦とも言えるし、それまで妄想で楽しめばいいんだよ。
何度も口を酸っぱくして言ってることだが相手がアーキの改良くわえてるのに、
4コアでWestmere 2コアにすら勝てないアーキをそのまま使ってる時点でLlanoは最初から負けてるだろ。
GPUなんてディスクリートGPUでなんとでもなる。CPU性能の不足は拡張カードで補えない。
クソでも売り込むようなマーケティングセンスがあるなら別だが特に売り込める要素なし。
そもそもなんでローエンド〜ミッドレンジのSandy BridgeのダイにGMA(笑)に毛が生えたGPUコア載るかわかってるの?
コンシューマ用途でAVXを有効に使えるプログラムが出るまでは、Vertex Shader代替として使うのが
一番リソースの無駄がないからだよ。
単純計算でVSの性能がArrandaleの2〜4倍になるわけだからそれなりに使えるのでは?
俺個人はあまり気に入らんが。
Llanoと勝負するためじゃない。勝手に仮想敵にするな。
Llanoと登場時期がかぶるから、どうしても比較されると思うぞ
CPUは優秀、GPUは出来損ない vs CPUは値段なり、GPUが優秀 みたいにな
>>36 団子も一部のヤツから見たら真新しいオモチャみたいだし。
壊れたテープと同一だって事を…おっと。コレもコテ名だな。
比較されるだろうけど、Llanoの方がGPU性能が高くても数が出るかというと疑問が。
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枚刺しって殆ど無いよ?
G45と780G程度以上に開きがあるぞ
そこでIntelはGMAを1個増量してGMA双発で負けてないアピールをする
完璧なシナリオだろ
>>43 だからアホだな。勝つ必要ねーじゃん。
メモリの価格の差額でディスクリート刺せるしww
NEC/富士通がIntelオンリーになったことで日本の家電屋は完全にAMDを見放した構図になったわけだけどどう思った?
>ディスクリート刺せるしww
だめだ、コストアップだぞそれ
Llanoの主戦場はノートかスリム筐体のデスクトップあたりだよね
1600MHzモジュールを2枚刺しなんてしたらコストアップ、ケチったら
圧倒的な・・・・帯域不足
タイルレンダベースでメモリ帯域を余り食わないGPUを開発しておくべきだったね(泣
あ、仕様確認したけどLaVieはいずれもIntel HDG/GMAだった
>>46 ララビの残骸つかって、今だとsellが圧倒的に使われてるPC間を繋ぐボードとか
ララビには夢があったよ。登場時期が10年ほど早い気はする。
夢があったというか夢しかなかったという話もある
Llanoなんて今の魅力が無いノート向けラインナップに選択肢ができるだけでもありがたい
デスクトップ向けでもコスト的に有利だからある程度売れるだろうし
今日くらいはこれでも付けておくか
>>51 AcerやDOSPARAのノートPCが選択肢に上がる人自体、日本の消費者には少ないと思う。
AMDに関心がない人はわざわざ買わないだろ。
CPUが刷新されないAMDに魅力がないからNECも富士通も見限ったんだと思うよ。
むしろ刷新されてないコアが世界的ヒットという
2010年になってもCeleronやPentiumDCがまだまだ主力
Core2がでてから4年くらい経ってる
NECや富士通は知らない間にAMD搭載パソコンを出さない宣言をしていたのか・・・
数年前、某家電量販店のノート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のパワーゲーティングより、オンオフのレイテンシが長い。
> 実際の機器では、パワーオフからの復帰に時間がかかることになり、どの程度実用性があるのかは、
> まだわからない。
体感速度(笑)がた落ちだな。
NECも富士通も年間生産量2〜300万台だから、AMDを採用してラインを増やしてもコストが上がるだけだ
よほどのことが無い限り採用しないだろう
1. GMAで十分だと思ってるひと→Intel+内蔵GPU
2. GMAが屑だと思ってるひと→Intel+ディスクリートGPU
3. GMAは屑だがディスクリートのコストアップは嫌、CPUの性能はそこそこでいい → Llano
1が大部分のユーザでそれに2が続き、3は一番ニッチ。
マーケティングでひっくり返せる可能性は0ではないけれど、
AMDの歴史にマーケティングで成功した過去はない。
【質問】
来年ってなんかPCゲーでキラータイトルあったっけ?
Intelのインテグレートで性能不足するような。
ファミ通で「サンシャイン牧場」の記事が組まれるような時代ですからね。
いまどきのカジュアルゲーマー層が求めるのは「mixiアプリがストレス無く動くPC」だと思うぞ。
FlashゲーのパフォーマンスはほとんどCPUのシングルスレッド性能依存。
一方GPUはGMAでも十分。
CPU性能が下がっても満足出来るユーザーは居ないはず。
国を跨ぐと違うかもしれんが。
ゲームの事は知らんがmixiってモバイル向けゲーム?
MMORPGならLlanoで十分
IntelのGMAのシェアが性能の割に高いのって、
単にGPUの性能なんてどうでもよい事務端末用に
Intelセットが大量に採用されているからじゃないの?
>>66 そうだよ
PC利用者のうち単体GPUを使う人は1/3程度
メーカーPCだとほとんどGMAじゃないか。自作やっている人間からすればゴミだけど
>>62も「GMAで十分だと思っている」からGMAではなくて、
1.買ったPCがGMAだっただけ。
が正解だろうな。中身を知っていれば「2」か「3」にしかならない。
GMA指名買いする奴は流石にいないだろうからなあ
>>70 まあそれでもいいんだが、いずれにせよ「GMAが糞だからAMDのCPUを買おう」とはならない。
普通にRadeonなりGeForceなり搭載したPCを買う方を選ぶ。
3に呼び込むには強力なマーケティングが必要なのよ。
AMD指名買いする猛者キボン
だんごwww
wwwファミ通読者www
>>72 「それでいい」のではなくて、「それでしかない」わけだが。
あと、
>「GMAが糞だからAMDのCPUを買おう」とはならない。
>普通にRadeonなりGeForceなり搭載したPCを買う方を選ぶ。
コレも嘘。一般人は与えられた物を買うだけで、
GPUなんて気にしない。オレ達"自作オタ"や、
特定メーカー信者の妄想とは思考回路が違う。
「価格」と「宣伝文句」が美味しそうであればそれを買うだけ。
中身なんて気にしない。例え屑性能だったとしても、
そこに「購買意欲に見合った宣伝文句」があれば買うだけ。
ただ、AMDがメーカーサイドへのマーケティングが弱いのは同意。
だけど今後はチップセットも自社(GF)生産になれば、
セット販売での様々な割引やら特典は付けやすくなるので、
OEM向けのマーケティング的にもやりやすくなってくるんじゃない?
GPU+チップセットで生産予測や納品予測が立てやすくなるし。
> 一般人は与えられた物を買うだけで、GPUなんて気にしない。
この層は1だよね。Llanoには行かない。Intelブランドはでかい。
日本の場合もともとPCのオンラインゲームより携帯ゲームの方が市場規模が大きい
※前世紀の市場規模については知らん
日本じゃ大手メーカーが3Dゲーム向けPCを出す余地は最初から無かった
>>74 その号だけちょっとした話題になってたから読んだんだよね。
ぶっちゃけ、血しぶきつゆだく上等の洋ゲーが家電屋のPCの売上げ牽引した時代って日本に存在しないんじゃないの?
Sandy BridgeのIGPでちょっとたよりなくてLlanoで満足出来るネトゲってMHFあたり?
あれ既に終わってる気がするが。
ブランド戦略がいかに大事かを今NVIDIAがあらわしてるもんな・・・
>>77 「Intelであるか」さえも見ていないことが多いぞ。
PCの製造メーカーは気にする場合も多いけど。
>>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なんか正直相手にもならんだろうな
しかし団子のIntel圧力マーケティングマンセーが激しいな
>>61 数は少ないけどNECだってAMD採用しているよ、安売り用だけど
ラインナップが少ないのは知名度やサポートの質、リベートなんかの差だろうね
逆に言うと、そのへんが改善すればラインナップは増えるということだ
「VAIOのパソコンください」にAMDを認知させるのは難しい
> 数は少ないけどNECだってAMD採用しているよ、安売り用だけど
そのなけなしの採用数すら今期新モデルは「ゼロ」なんですが。
日本で、GMAでは満足に動かない(単品ビデオカート要求するレベル)
のPCゲームが流行らないのは、携帯よりはゲーム専用機の存在が大きいだろ。
加えて、ことゲームに関する限り、海外のセンスは日本と乖離してるから
洋ゲー輸入したって一部マニア以外は触ろうともしないし。
相変わらず妄想が激しいな
シェア論議とか笑える
売る側がIntel:8、AMD:2の割合で売ってるから、購入者のシェアも8:2ってなだけ
中身なんかほとんどの奴は気にしない、せいぜい値段とモニタのサイズくらいだ
企業向けなんか殆どチップの安売り合戦だな
機能や性能なんか関係ない、いかに安く仕入れられるかってだけ
当然赤字で製造量が少ないAMDが大量に利益なしで納入出来る訳もない
省電力やバッテリー時間はそれなりにあればいい程度でメインの理由でも無い
>>77 > この層は1だよね。Llanoには行かない。Intelブランドはでかい。
確かにAMDより遥かにでかい
でもそれを遥かに超えるほどNECや富士通、ソニーのブランドの方が重要
優先度
1.メーカーのブランド
2.値段
3.ディスプレイのサイズ
4.付属ソフトや機能
Intelかどうかはせいぜい5番目くらい、割合からすると数%でしかないだろう
海外もそろそろ潮時だけどね。有名ゲームスタジオいくつも倒産してるから。
開発費は高騰するのにパイは少なくなるんじゃやれんよ。
日本で流行ってるmixiアプリ自体、そもそも北米のFacebookの2番煎じだったりする。
DX11対応がどうのこうのいってる時点で既に少数派の思考ルーチン。
iAppのほうがよっぽど将来性がある。1年と経たない間にPSPのシェアをかっさらった。
生産量の劇的な増加が無ければどうにもならんね
例えるとオール電化住宅みたいなもの
湯を沸かすのも調理をするのもガスの方が安いのだが、電気とガスの2系統が有ると基本料金も2系統分発生する
それなら電気一本に絞って基本料金を一本に絞った方が、トータルでは安く済む
世界的な不況も考慮するとね、開発費の安いゲームにながれるのは自然だろうね
ちゅうかmixiアプリ自体はAVXもDX11も必要ないな、むちゃくちゃやね団子
> でもそれを遥かに超えるほどNECや富士通、ソニーのブランドの方が重要
結局
>>59なわけだなwww
ちなみにその店員、「AMD Sempron」の名前は一切出さなかったwww
PCゲームの市場規模自体は日本でも海外でも増え続けてるけどね
この間のの不況時はさすがにペースは鈍ったがそれでも成長した
ゲームの質的な変化については知らん
MW2とかGMAで出来るの?
>>93 必要ないね。シングルスレッド性能重視だからね。
キャラがわらわら沸くようなアプリは軽く死ぬ。
どっちかというとTurbo Boostでクロックがどれだけ上がるかが重要かもね
もちろんどっかのBu(略のようにIPC下げるなんてのは自滅行為。
>>95 SNSと連携した基本無料のブラウザゲーの台頭が要因。
>>84 俺、そのAMD入りVAIO足元においてるんだけどなにか?
正直、普通にPC買う奴はCPUがどっちでもwindows動けばいいんだよ
mixiのアプリなんてめちゃくちゃ軽いだろ
Atomでもできるっつーの
>>100 軽いのしかやってないだろ。
うちのやってるのはホームを表示しただけで片コアのCPU使用率が100%にはりつく。
一応30万人くらい登録してるアプリ。
>>99 馬鹿には一般人がCPUがどこのかなんて関係ないのが理解できないんだよw
サンシャイン牧場の畜産広場も動物増えるとある程度ヤバイね。少なくともAtomじゃやれん。
どんなゲームだよ100%にはりつくブラウザゲーってのは
そもそも快適に遊べるのかよ
>>102 AMDはやたらと嫌う人がいるよ企業ユーザーは
てかAMD採用してた時代のVAIOって・・・骨董品だな
>>101 さすがにそれはないわ
IE6とか使ってるんじゃねえの?
オブジェクト増えるとatomじゃきついね
ってかうんこフラッシュじゃないの?w
FlashのGPU支援ってどうなってんのかな
ブラウザゲームとかはやらないから判らん
フラッシュのGPU支援って
動画だけじゃないの
>>106 俺の場合ホームに動くオブジェクト大量配置してるかもねwww
もはやCPU負荷テストwww
>>107 描画対象のオブジェクト減らせばそんなに重くはならんよ
>>108 あれはh.264の再生支援だから既存のActionScriptをどうこうできるものじゃない。
>>105 テヘが何歳かは知らないが、俺がPCいじり始めた頃なんてPC98以外は駄作だと思ってたし
中身はintel+ATIでAMDなんてただの互換CPUだと思ってたからな。
知識がそのあたりでとまってる人がまだいらっしゃるんだろう
インタプリタ部分のCPU負荷の方が大きいからGPU性能では差が出ない
せめて別窓で表示してるFlashくらいスレッドを分けて欲しいんだが。
「AMDはやめてください」って言った担当者は20代後半だぞ
まあその上司がその年寄りなんだろうけどな
>>110 妄想羅列の準備に講座見ることすらしないショタカブリ
日本はIntel好き多そうだな
日本は世界で最も多くItanium買ってるだろう
>AMDなんてただの互換CPUだと思ってたからな。
ちがうのか
シェアで劣り、ブランドで劣り、性能すら劣る互換品の末期は無惨なものだ。
>>117 「何に対して互換か」による。AMDが
「Intelの互換CPU」を製造していたのは昔だけ。
>>118 色々な人のツッコミに何一つ言えなくて、
結局それが最後の一言か。格好いいな。
AMD採用を増やすには国内の企業が中国に買収されないとな無理ぽ
Windows互換CPUというのがしっくり来る
x86の時点でIntel互換だろうに
>>122 「x86互換CPU」と「Intel互換CPU」とでは、
話が全然違うんだが…理解しているか?
>>122 それだとIntelもAMD64互換だからAMD互換CPUと言えてしまう
どうちがう?
どうせ内部RISC86だし
64bitはAMD互換だけどな
あ、SSSE3,SSE4未対応だから非互換か
>>128 お前の頭が残念だって事は理解できた。
儲思考も大概にしておいた方がいい。
だから、どう違うんだ
それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。
それが?
>>130 その程度を理解してからこのスレに来てください。
荒し目的だったら相手にした私を笑って、
釣り宣言をしたあとに消えてください。
Intel互換じゃないってんなら
x86使うなよ
>>134 マジで「Intel互換」と「x86互換」を同一視…って、
いまだにそんな残念知識人がいまだに自作板にいたんだ…。
コレはヤバイ。マジでヤバイ。面白すぎてヤバイ。
楽しい楽しいカオスが訪れるのはこれからだぞ
AMDの生産能力はメインストリーム以上に限ってもこの2年で3倍になる
これとは別にBobcatもある
GFはAMD以外の製品も製造しなきゃいけないからその能力の全てをCPUに割くことは出来ないが
キャパシティー的には2012年にちょうどIntelに匹敵する事になる
※Bobcatがバルクでの場合の話
つまりとんでもない供給過剰状態
これは楽しみ
じゃIntelパクリでいいよ
>>119 どれも突っ込みというよりはお花畑の妄想だろう。AMDスレだから書くのは一向に
構わないがそれに対するコメントは特にない。
>>139 どこでどんなプロセスで作られるのか知らない
GFでメインストリームCPUと同じ工場で作るようなら
BullやLlanoととウェハの取り合いになるから生産量はIntelには及ばない
>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。
で?
>>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互換」を混同するのは恥ずかしい。
>>143 アホは相手にするなよ
「Intel互換」と「x86互換」を同一視
今時こんな事言ってるのが涙を誘うよなw
この流れ、VIA抜きには語れないな!
君らが勘違いしてるのはSocket7以前のバスレベルの互換や
セカンドソース時代のことじゃないの
>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。
で?
ついでにいえば、IntelとAMDの契約の中に、
「AMDは自社工場でx86互換CPUを作っていいよ」ってのがあったらしく、
それが去年だか一昨年だかに一時話題になった、
「GFは自社工場じゃないだろ! x86ライセンスを停止してやる!」
ってIntel側の訴えに繋がったわけですが…。
そのお話の結末は同時期に争われていた「独占禁止法裁判」の結末。
「IntelはAMDに和解金を支払い」のおまけのようにも見えたけど、
超重要事項。「x86ライセンスの継続」っていうおまけまでついて勝訴。
ていうか。「和解金が少ない」って話は確かにあったけど、
「x86ライセンス継続」がついたんだから、少ないどころの話じゃねーっすw
>>144 間違えた書き方をされたパッケージではなくて、
Windowsパッケージのシステム要件でも眺めてろw
アイタニウムどうなってしまうん?
Itaniumは夢とともにNehalem-EXに引き継がれたよ
intel互換cpu
>それにIntelもx86命令セットをネイティブで処理するCPUなんて、いま持ってないだろ。
で?
※2 Intel互換CPUは動作対象ですが、AMD社の一部の旧型CPUについてはSilverlight動作対象外となります。
Intel社と互換性のあるCPUならほらこの通り
証拠書類改竄や連続敗訴を皆様お気軽に実行出来ます!
でもお高いんでしょう?
それが何と(ry
>>148 この問題は、時系列順に考えれば別の見方が出来るかと。
もともとインテルとAMDの間には独禁法違反の係争があった。
Intelにしてみれば最悪ケースでは企業分割もありうる不安定要因だ。
AMDの業績悪化が深刻化したとき、AMDはアラブ資本の出資を受け入れ、
赤字で投資がままならなかった製造部門に梃入れすることにした。
収支を合わせるためにファウンドリ事業への参入も決めた。
別にAMDは分社化する必要はなかったにも関わらず(たとえばサムスンは会社の
一部門としてファウンドリ事業も行っている)、製造部門をGFとして分社化した。
ここで、AMDにもx86の製造ライセンスが失効するという不安定要因が生じた。
そしてIntelとAMDは、(いくらかの現金とともに)お互いの不安定要因をバーターする
ことに合意した。AMDはx86の製造を行う権利を引き続き保持するのと引き換えに、
Intelを独禁法違反で攻撃する権利を失った。
ライセンス問題の解決を受けて、AMDは製造部門の分社化をさらに押し進め、
決算からGFを分離し、黒字転換を果たした。
AMDの赤字を引き継ぐ形になったGFは非公開企業だから、決算の数字は(赤字だろうという以外)
外部からはわからない。
和解によるx86製造ライセンスの取得は勝利ではなく、
GF分社化以外で黒字転換できない状況に陥った大失策を、
独禁法違反という(弱者の強力な)武器と引き換えにイーブンに戻したに過ぎない、
というのが自分の見方。
>>154 独占禁止法といっても不正競争防止法と反トラスト法は内容が全然違う
Intelが訴えられたのは反トラスト法じゃなくて不正競争防止法
企業分割は関係ないんじゃないか
そして和解後、AMDは黒字となったのであった。
もうちょっと補足しとくと
独占禁止法は大まかに分けて
@違法な行為により競争相手に不利益を与える不正な競争を防止するもの
A過度な独占を防止するためのもの
の2種類
Intelが訴えられたのは@の方の不正行為による正当な競争の妨害であって
市場の独占を訴えられた物ではない
和解金で黒字とか
やっと気付いた
和解金玉に見えた。
飛ばしで黒字とか
そしてNVIDIAは赤字幅を順調に拡大したのであった。
別に赤字でも良いんだよ(拡大しちゃうのはまずいが)
お金がちゃんと血液のようにさらっさらに流れていればかまわんのよ
ただ、さらさらに流れない事態に陥ることだってあるんだよ、たとえ黒字でもね
そういうときは本格的にやばい、黒字倒産っていうしゃれにならん事態が起きちゃう
黒字倒産は悲惨だよな
まあ、キャッシュを持っていればいいんだけどなかなか難しいよな
海兵隊が抑止力と思っていなかった
口蹄疫がこんなに恐ろしい伝染病だとは思ってなかった
防疫や災害対策の予算が必要になるとは思ってなかった
陰厨が何も言えなくなって、またも見当違いの方向に走りだしたな。
たしかx86_64ではIntelがAMD互換に成り下がったのでは?
そう思った奴が、「IntelがSSE5を採用しないのはAMDに対するいやがらせだ!」と見当違いのことを言っていた
ところでテヘと団子は同一人物? 以前トリップ同じだったけど…。
まぁAMDのスレで毎回intelの話持ち出して来る奴もここのスレタイ的にどうかとは思うがな
>>174 なるほど…。
テヘって捏造ベンチだけではなく他人の名を語って自演するまでに落ちぶれたのか…w
淫厨がまたファビョってるのか?
次世代スレでIntelの訴訟地獄の負け戦なんかの話してもつまらんだろ
どっちが何の互換とかもうどうでもいいだろ?
AMDもIntelも今後ずっとX86CPUを開発・販売していくことには変わらないんだからな
トムとジェーリーみたいに仲良く喧嘩してればいいんだよ
まあ、悪徳巨大結社Intel相手に長年赤字続きで苦戦していてもうだめかという土壇場で、
ATI買収、アブダビの支援、工場分離、和解とX86継続、大幅な黒字化という奇跡の復活を遂げたAMDは素直にすごいと思うよ
しかも来年は新プロセスを使った新CPUと新GPUで大反撃も行うし
大ピンチから奇跡の復活、そして大反撃とか何処の少年漫画だよw
このストーリーを小説にしたら確実にご都合主義の烙印押されて2chじゃ非難の嵐だろうね
普通はこのまま大逆転してハッピーエンドだけど、まあ無理だろうな
ARMなんかみてみれば解るが互換メーカーの拡張を本家が逆採用することは別に珍しいことじゃない
そもそもx64自体IA-32命令セットの上位互換でAMDオリジナルの部分なんてほぼ皆無
GFの分離の際のいざこざでも、IntelのライセンスがなければAMDは「AMD64」を作ることも
ままならないという支配関係は改めて確認できたろ?
GW終了
木金も有給申請しとけよ
反撃するのに一番重要な、ハイパフォーマンスCPUというピースを欠いているのだが。
ライセンスというか、プログラムコード・CPU構造(MMUの操作などね。 内部構造は含まない)に対する
著作権の問題だろ。
>>180 > 反撃するのに一番重要な、ハイパフォーマンスCPUというピースを欠いているのだが。
Bulldozer 8コア/16コアがハイパフォーマンスじゃないのか、IntelはSandy16コアでも用意しているのか?
>Bulldozer 8コア/16コア
それはローパフォーマンス多コア
sandy 8coreで十分
12/16はサーバー
6/8はコンシューマ
整数・小数点
スカラ・ベクタ
区別出来る知能はもとより
何度笑われても知識すら付かないショタカブリ(生活保護の55歳(くらいだっけ?))
186 :
Socket774:2010/05/06(木) 08:42:26 ID:MpTmikb7
sandyがだめとなったからにはBULLに期待するしかない。
>>182 AMD流の数え方では実行ユニットの前工程が
コア数の1/2だからな。
鯖やHPC用途みたいな
常時ピーク付近でブン回す分野だと
どうやっても100%負ける。
これからはパワーより
消費電力だからな
今の10倍高速であるより
今の1/10電気食わないように出来るか
そして携帯に取ってかわれるかが
生き残りのカギだな
なんかトリのセンスまで雑音に似てるw
>>187 果たしてそう期待通りに負けてくれるか…そこが問題だな。
テヘ権田は相変わらず精神分裂しっぱなしwww
x86は携帯向けに進出はできないよ
ARMの省電力にAtomじゃ何をどう頑張っても追いつけないからね
ARMって6502シンカなんだよな?
>>187 普通のアプリと違って、そういう特殊用途だと
ソフトを書き直す手間も許されるからなぁ。
一般向けならブルの割り切り方で正解なんだよ。
ソフト側から見たらモジュールやコア数なんかどうでもよくて、スレッド数が幾つなのかが重要。
OSから見ればi7は8スレッド、Gulftownは12スレッドで認識されスケジューリングされるからね。
殆どの場合、IntelのHTTのようにスレッド間で性能差が大きいものよりも、
Bulldozerのようにスレッド間の性能に差がないほうが扱い易い。
199 :
Socket774:2010/05/07(金) 02:31:36 ID:ryUHGWyB
BULL最強という事ですね。
サーバは兎も角、クライアント・ホームユーザー向けで4スレッド以上使うソフトなんてそうそうねーけどな。
OSのサービスに割り当てるCPU時間なんて限られてるんだから
同時発行スレッド数はクライアントのコンテクストが頻繁に切り替わらない程度にあれば十分
団子を逆に読めば権田だとか洒落てるつもりなのかなこの馬鹿
単にCMTに振るだけじゃなくて、
たとえばプロセッサレベルでCilkのspawn/syncを高速に実行できるような命令を積んだら面白いと思うが、
そういう革新性が無いのがつまらないですなあ。
ついでに言えばもし常に均一にスレッドが沸いてくる理想状態なら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年だか先のトレンドを先読みするのはご立派だが今を犠牲にして全てを失ったら世話ない。
さすが2chに張り付きニート暦7年で自称年収8500万
スーパー生活保護受給プログラマーのいうことは違うな
ついでに言えば焼き串使えなくなったから3人同時主演は難しいのだろ
権田さん出てらっしゃーい!
クライアントで重要なのはシングルパフォーマンス
ベンチでも回さない限り
なんかそのシングルタスクのパフォーマンスもそれほど重要じゃない気が最近してきた
重要じゃないというか、飽和してるよね。
ストレージがあまりに遅いからだろ。
というか、コンシューマ向けとしてはソフト自体がネタ切れ気味だな。
キーボードがあってマウスがあって箱があって画面があって・・・の範疇でできることを
やり尽くした感はある。ゲームも含め。
知能指数-200のショタカブリ消えろ
>>197 まともに働けもしないような水増しスレッドで高性能とか、
市場操作やらかす様な邪な企業野製品らしいよな。
Atom 128coreでも積めばいいのに
なんでそこまで極端に話し振るかなあ
まともに話すことも出来ないじゃないか
Bullの方向性が妥当であるという結論に達したくないからでしょ。
>>214が極端・・・?
>215は新参か?
ショタカブリ(雑音というかこのスレの粘着コテ群)なんか
極端ならまだしも常に滅茶苦茶だぞ
まあ、しっかし、相変わらず読む価値のないレスばっかりだな。
まあ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だマルチコアだと騒ぎ立てたところでソフト屋がろくに見向きもしないんじゃどうしようもない。
相変わらず動画エンコード当たりが頼みなんじゃね?
こっち方面はネットブックやスマートフォンが流行っても外で持ち出して再生するとかの需要は増えそうだし。
DX11にしても、ほとんど見た目が変わらんのだし
コストに対する効果が対数関数的だわね
ハード的にもソフト的にも
水増ししてるのは、腐れの Intel だよ。
AMDのは正味。
ちょっと表現を間違えたかな
>214は極端というより的外れないつもの馬鹿
ショタカブリ(ID:ls/Tt+fy)は滅茶苦茶というより
・どれだけ笑われても性能算出に演算器数で掛け算するのをやめない
・どれだけ笑われても今のGPUにSIMDユニットとx86デコーダが付いてると信じて疑わない
・どれだけ笑われても「たまにPentium4にはL1Dが無い」
・どれだけ笑われても隆盛(たかもり)くん目当てでこのスレに粘着
というようにホモ全開と妄想全開とバグ全開コピペを意外に器用に織り交ぜる
ネットを通しても臭ってくるほど気持ち悪いイカ臭いゴキブリだ
1コアあたり3命令とか4命令とか同時発行できるコアが本当に8ないし16あるなら兎も角
2つの整数クラスタで最大4命令のデコーダ共有を共有してるのを2コアと言ってるだけだろ。
コア数の水増しと言われても仕方ない。
あとは、2つのスレッドで共有してる4命令/clkの並列演算リソースを、
負荷に応じて3:1とか4:0とかにも動的に割り当てられる(Sandy Bridge)か
あるいはクラスタ毎の演算リソース数で頭打ち(BullDOZEr)か、どっちがマシかと言う話だな
○2つの整数クラスタで最大4命令のデコーダを共有してるのを2コアと言ってるだけだろ。
まぁ雑音よ、そのコテは別人キャラの設定なのか?
>>223 Sandy Bridgeの演算リソースはポート6つで、最大6命令/clkだろう。ALUは3つだ
C++で書かれた鯖用プログラムだと、演算リソースじゃなくてL1D$のレイテンシ・帯域に制限されそうな気がする
だから「コア」ごとにL1D$を持つBulldozerは整数系ベンチで意外と善戦するかもしれん
>>220 >DX11にしても、ほとんど見た目が変わらんのだし
確かにそれはあるw
ゲームやってる時にその違いに気付くのは無理だな
投入コストに見合わないと判断されたらどんな規格も廃れる
DX11は開発者目線で策定されたくさいしね(作りやすさ重視という意味で)。表現の向上はテッセレーションくらいかな
>>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スレッド同時実行)をやり出した時だと思う。
DirectXが隆盛したら悶死する奴と「DX11の未来について」を語っても意味ない
それよりも隆盛(たかもり)くん大好きな気持ち悪いショタカブリの極限的な知能の低さによる公害のほうが遥かに問題
>>228 携帯ゲームでモーションセンサやマルチタッチパネル、裸眼3D液晶(DS次世代機)が使えるのに比べると
何が変わったのか、消費者視点で解りづらいわな。
世界的に見てもPCゲームの市場で成長してるのはMac・Firefoxでも動いて低コストなブラウザゲーや
低スペックでも動くMMOくらいで、ディスクリートが必要なクラスは世界的にも衰退してる。
だからこその非ゲーム用途のニーズ開拓(GPGPU)したり、1人に複数枚買わせたりしてるわけで。
GPGPUって丁度DSPでモデム機能も実装してみました、みたいなモンでしょ?
最早見かけることも無くなったサウンドカードと同じ道を着実に歩んでる。
>>229 たしかに整数演算ワークロードでL1D$のロード・ストア「帯域」はクリティカルでなかったかも
>ロード・ストアの「帯域」って言っちゃうとSSE前提になってしまうが発行回数のほうが重要では?
SSEをガシガシ使うプログラムでは、命令発行帯域よりL2〜L3〜メインメモリ帯域に制限されることが多い
SSE系ベンチではHT無効化Sandy Bridgeと半コア無効化Bulldozerの戦いになると思うが、
この分野ではキャッシュ容量・帯域の技術に秀でるIntelにAMDは勝てないだろうな
>>231 全世界のPCゲーム市場規模の推移ってどんな感じなん?
Bulldozerは1コアあたり1個の128bitのSIMDが有るよね
モジュール中の1コアを止める事に意味があるのか
PCゲームは衰退してると言うけど売上的にはどうなの?
コンシューマ機の売上割合が増えてるのは確かだろうけどさ
Modern Warfare 2は発売初週の売上はPC版で過去最高だったらしいが(その後は知らん)
2009年までの段階では、ディスクリートGPU市場が衰退しているってデータは無いだろう
ライトなPCゲームはPCゲームのパイを広げることに役立っているが
ヘビーなゲームの市場を食うものではない
と言うよりも、ライトなPCゲームが奪っている市場というのはTVや据置型の家庭用ゲーム機などであって
PCゲームの市場を広げる事に役に立っている
オンボの性能があがってくるのはPCゲームとしては大歓迎
Llanoと790GXくらべるとどの程度ゲームのスコア差がでそうなんかな?
今んところの情報だと、Llanoのほうが断然上の性能
>>236 ヘビーなゲームにライト層もついてきてくれたからソフトメーカーは金がうまく循環してたわけだが?
今現時点で「DX11のゲームさえくれば」と言ってる状況自体が、既に終わってる。
ライトゲームに流れざるを得なくなったのは2007年以降の不況・不況の嵐なんだよな
大手はまだこてっこての3D作っても、有名タイトルでなんとかやっていけるが
その他、大多数の中小メーカーはやりたくてもやれないってかんじで、なんとか生き残ろうと必死
表現できるグラフィックが精細になればなるほどコストは跳ね上がるじゃん。
テクスチャの解像度ももちろんだけど、シェーダプログラマの人件費がばかにならん。
コンシューマ機でいうならPS2時代には平均開発費は5億円程度かかってたものがPS3/Xboxでは30億円程度かかるそうな。
んでもってユーザーが5〜6倍に増えるならまだしもパイ減ってるじゃん。
他に目を向ければカジュアルなゲームプラットフォームのほうが流行ってる。
いくらハイエンドゲームマニアが望んでも、ソフトメーカーがやれんよ。
まぁ雑音よ、そのコテは別人キャラの設定なのか?
受け売りで話をする奴って言うことが似るよw
一致率の高さはそれとは別だが
誰と誰が同一か云々じゃなくて内容に突っ込めよ
だんごやさんの真贋は行動によって示される
開発費ってだいたこれくらいでしょ
PS3:3.9億円
360:1.9億円
Wii:1.3億円
真贋に価値が無いから安心しておくれとしか
既製ソフトのエンジン使い回しで抑えこめばそんなもんかもね。
問題はイニシャルコスト。
つかそれはそうとDX11使った汎用ゲームエンジンって誰が開発するの?
DX10すらDX9と殆ど差がなかった気がするんだが。
(故意にXP/DX9環境でオプションを制限しただけのソフトならいくつかあったけど)
次期UnrealEngineはTimの発言からすると次のコンシューマゲームが出る頃まで音沙汰無い気がする
気持ち悪いホモゴキブリってのは
誰にも読まれない妄想長文書きまくって誰にも叩かれないとそれだけで増長して暴れまくるから
環境保全の為にもなるべくこのゴキブリ未満な知能の気持ち悪いショタホモを馬鹿にするべきなんだろうけど
やっぱり人生の無駄使いだからな〜
何とかならんもんか・・・
>僕は頭が悪いので何も反論できません
迄読んだ
今コンピューターゲーム市場でパイが減りそうなのは家庭用ゲーム機だな
携帯ゲーム機はまだ伸びてるが、据置型ゲーム機はここ数年市場規模は横ばいのまま
据え置き型ゲーム機が全盛だった頃は『TVの前』のポジション争奪戦だった
でも今は30歳代以下はTVではなくPCの前ですごす(30代以下と40代以上で傾向が決定的に異なる)
つまり、今は『PCの前』のポジションの争奪戦であり、据置型ゲーム機の将来性はかなり厳しい
※プラットフォームの規模が成長しない市場でゲームを売るには
消費者に「ゲーム+ゲーム機」を両方買わせる程の魅力のあるゲームを作らなければ
特に家庭用ゲーム機は1機種で1市場と考えた場合はPCゲーム市場よりはるかに小さい
携帯型ゲーム機も状況的には似てるが、こっちは携帯電話の機能を取り込めれば可能性は無くは無い
パッケージソフトビジネス不毛の市場の中でサーバ集中型のサービスで成功をおさめた
韓国のゲーム会社なんかは逞しいと思うね。
iPhoneのあれは絶対的なハード普及台数がまだまだ少ないからそれほど脅威になってないが
更にアマチュアの参入障壁が更に低いAndroidが本格的に立ち上がれば任天堂も安泰じゃない
そもそも日本にゃ
そんなスキルの有るアマチュアなんていないだろ
あったら、大手が離さないだろうし
今の時期に独立するバカはいない
日本のアマチュアFlash職人と契約して海外アーティストのプロモーションビデオを作った有名音楽製作会社があってだな・・・。
ゲームも対戦なら高度なAIなんて必要ないからちょっとプログラム囓った学生でも簡単に作れちゃうのが入れ食いの理由
ただマリオやポケモンより流行る作品が出てくるかというと、無理な気がする
>>254 日本のプログラマへの待遇酷いらしいけどな
だから才能も集まらない
IQ50未満が偽プログラマで
それ以上ならなれる?ってイメージ
他の仕事しながら趣味でやってる奴のほうがスキル高そう
ID:uIYAJENY
これはひどい
259 :
Socket774:2010/05/07(金) 14:00:26 ID:j7r2atdW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
canvas3dやo3dとかブラウザ上で手軽に3d扱えるAPIが登場し始めてるから
カジュアルなブラウザゲーでも3dが今後の主流になるのは間違いないよ
おそらくHTML5と一緒に普及するはず
とはいってもFF14やFPSみたいなハイエンド志向のものじゃなく
マリオやみんゴルのようなデフォルメされたものだろうけど
しかしインスコ不要でブラウザ上で手軽に遊べるようになれば
ユーザー増やすチャンスと捉えて積極的にコンテンツが投入されるはず
それどころかwebsiteでも無意味に3d使うとこが出てくる
今のflash貼りまくりのサイトのようにねw
Llanoは今のwebの状況から見るとGPUが過剰な性能に見えるかもしれないが
今後を考えるとこのレベルは最低限になるかもしれない
>>235 とりあえずEAがPCゲー製作部門だけピンポイントでリストラするぐらい
儲かってない。
すっかり団子が住人として定着してんな
>>220 「見た目」だけに限っていえばDX10で進歩はほとんど止まってる。
>>262 そりゃ久々にAMDが性能でIntelに勝っちゃったもんだからネガキャンに必死なんだろうよw
DX10.1以降は下位互換性があるので
11の画像が大して進化していないからといって10にわざわざ留まる必要はほとんどない
GeForceの方は一気に変わってしまったので分からないが
Radeonの5シリーズに関しては大してトランジスタ数も増えてないようだしな
>>264 AtomよりPhenom X6のほうが速いだろうけどそれがどうした?
267 :
265:2010/05/07(金) 19:28:26 ID:0ALZRl53
自分で書いていて言い分が明らかにおかしいのに気がついた
酔っぱらってるんで寝るわ
DirectX10やらへ進まないのはMSの責任だろ。
大人しくXPでも対応させてしまえばよかったんだよ。
対応させても見栄えは大して変わらんの
MS的にはDirectX10が使われようが使われまいがWindowsが売れればそれでいいからな。
普及が進まない事で対応グラフィックカードが無意味になろうが知ったことではないだろう。
ところで前のエイプリルフールねたでBulldozerのフェイク画像があったけど
その中の4KBのトレースキャッシュってμops換算だとどれ位の容量?
仕方ないな団子やボンクラ淫虫は
今がどうとかじゃなく、5年後10年後あるいは更にその先の世界のゲームが、
DX9ベースの今と何も変わらんしょぼいグラフィックとゲーム性のままだと思っているのかね
プロセッサの性能や解像度、通信帯域なんか増えることはあっても現状維持なんてことはないのにな
10年後なんかはどれもコレも今の倍以上、モノによっては10倍くらいに進化しているだろうに
そういった時代を見越して段階的にハードもソフトも進歩している最中だろ今は
団子が好きなブラウザゲーやIpadとかだって、
将来的にはDX11レベルのAPI使ってGPUによるアクセラレーションも出来る高度なものが出てくるだろう
今後どんな技術革新やブームがあるかも分からないのに、旧世代の規格に縛られたままでいいとか思考停止にもほどがある
>>229 二世代目以降に投機マルチスレッディングをやりそうって話が出ていますね
初代Bulldozerのピーク処理能力はSandyBridgeと張り合うのは難しいですかね?
Bulldozerの色んな解説記事読んで思ったんだけど、
今後のAMDのCPU開発の方向性が性能向上より省電力性の向上をかなり意識しているように見える。
パイプラインの3way→2wayへの削減やAVXユニットの2コアでの共有は、
普通に考えたら性能でIntelの次世代以降のCPUに対してあまりにも劣勢すぎるからね。
団子が指摘するように性能比較で勝てる要素は殆どないと言ってもいい。
性能で勝つ気が無いなら、狙いは低コスト(製造・販売)か省電力かになる。
コアをシンプルかつ小型化して、省電力機構もふんだんに盛り込み、
モバイル並の省電力化を果たそうとしているのがBulldozerでありBobcatなんだろう。
例えるなら、
K10=PenD、Nehalem=X2、Bull=Core2の逆再現を目論んでいる気がする。
>>269 責任って何だよ 責任って
別に普及させる義務なんて無いぞ
RADEONは小型化してハイエンドはミドル×2で対抗
CPUでもそれと同じことをしようとしてるな
本当に省電力だといいがねえ
いろいろ夢をつっこんじゃった某GPUのように欲張らなければそれなりにできるんじゃない
K10コア2個でSandyコア1個の大きさ
つまりシリコンの大きさあたりのSIMDユニットの能力は似たような物
同じシリコンの枠で
Bull :スカラコア2個でSIMDユニット1個を動かす
Sandy:はスカラコア1個をHTTで2スレッドにしSIMDユニットを動かす
って話
>>256 >他の仕事しながら趣味でやってる奴のほうがスキル高そう
ここで話を出来るレベルの奴で、それはないだろう。
俺も趣味でやっているが。
>>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対応にするのはたいして難しくも無いらしいし、いろんな所が検証していると思うよ
>>275 エネルギー効率がよければ、高クロックの余地があるって事です。
インテルのHTT導入は、パイプラインがあまり使われていない事の証拠
↑典型的な素人コメント
違うのですか?
このスレの玄人は荒らしコテの存在に自棄気味になってネタに走る
マジレスしてる奴は素人
> エネルギー効率がよければ、高クロックの余地があるって事です。
理屈の上では同一アーキテクチャでの消費電力はクロックの3乗に比例して大きくなるから
(リーク電流分は別)上がっても多寡がしれてる。
Cellのメインコア(PPE)なんか3.2GHzと高クロックだが一つ一つの命令が高レイテンシで、
実質1.6GHzのAtomとどっこいの性能しか発揮できなかった。
レイテンシを短くするにはより高速なトランジスタでロジックを構成する必要があり、
消費電力も上がるし、クロックも上がらない。
増大したレイテンシを(広義の)SMTで埋める手も有効だが、AMDはそういう設計になってない。
> インテルのHTT導入は、パイプラインがあまり使われていない事の証拠
一部のプログラムに限れば正しいが、サーバプログラムですらせいぜい2〜3割の性能向上に留まっている。
逆に言うと律速点に対して80%程度の充填率は達成できているということ。
曰くx86最大の熱源がデコーダだろ
IntelはComplex Decoderは1基に留めてるがBulldozerは1モジュールあたり4基
正直、BulldozerがSandy Bridgeより省電力とか高クロックとかにしやすい理由が思い浮かばないね
>K10コア2個でSandyコア1個の大きさ
>つまりシリコンの大きさあたりのSIMDユニットの能力は似たような物
つまりllanoとsandy bridgeのGPU部分は同規模なので能力は似たような物
>今がどうとかじゃなく、5年後10年後あるいは更にその先の世界のゲームが、
>DX9ベースの今と何も変わらんしょぼいグラフィックとゲーム性のままだと思っているのかね
五年前と今でどんだけ変わったんだよ
>団子が好きなブラウザゲーやIpadとかだって、
>将来的にはDX11レベルのAPI使ってGPUによるアクセラレーションも出来る高度なものが出てくるだろう
>今後どんな技術革新やブームがあるかも分からないのに、旧世代の規格に縛られたままでいいとか思考停止にもほどがある
その労力に対しての効果が低いってお話なんだが
コンシューマゲーム機が16ビットから32ビットになったときは2Dから3Dへの変化があったが
アセンブラで組んでたプログラムがC/C++で書けるようになったことである程度コストを相殺できた。
今はコストをかければかけた分だけリターンがある時代じゃないからな。
たとえば、携帯電話へのSFCタイトルのベタ移植よりDX11のほうが低コストで済むなら
喜んで飛びつくだろうよ。
どこの会社もその手の移植ものは人件費の安い中国の開発会社に投げてるよ。
もうそのレベルまで技術単価落とさないとやってけない。
シェーダプログラマ1人月収100万とかで雇ってる余裕なんてない。
例えば
4-5kmの道のりを20km/h程度で巡航するなら
1.5万円のママチャリでも
30万円のエントリーレベルロードバイクでも
150万円のハイエンドロードバイクでも変わらない
体力的にも小学生レベルでかまわない
50-100kmの道のりを30-40km/h程度で巡航するなら
1.5万円のママチャリは論外だが
30万円のエントリーレベルロードバイクでも
150万円のハイエンドロードバイクでも変わらない
体力は高校生の運動部レベルが必要
150-250kmの道のりを40-50km/h程度で巡航するなら
30万円のエントリーレベルロードバイクと
150万円のハイエンドロードバイクで違いが出る
体力はよくトレーニングを積んだ大学生レベルが必要
>>293 ちょっとマジレスするが、
> 50-100kmの道のりを30-40km/h程度で巡航するなら
> 体力は高校生の運動部レベルが必要
この程度のレベルでは無理。集団走行が前提。
> 150-250kmの道のりを40-50km/h程度で巡航するなら
> 体力はよくトレーニングを積んだ大学生レベルが必要
集団走行を前提なら150kmなら可能だろうが、
250kmは大学生レベルでは無理。
プロでも厳しい。
よってたとえになっていない。
Half Life 2出てからから5年半くらい?
やっぱり停滞してるなPCゲーは。
可能です
>正直、BulldozerがSandy Bridgeより省電力とか高クロックとかにしやすい理由が思い浮かばないね
おまえのアタマの中で浮かぶかどうかなんぞゴミよりどうでもいい。
現実に何が出てくるかだけが重要。
糞高い使い捨てソケットママンの害悪企業は人類の敵
下り坂ならね。
プログラムのステップ数が多くなれば多くなるほど、反比例的に開発費がかかり
反比例的にバグが多くなり、反比例的に時間とメンテ代がかかる。
結局開発費なんて毎回相場が決まっているから、反比例的にかかる開発費を抑える=
ステップ数を抑える=品質がよくないものが出来る
最近の3Dレベルが革新的に上がらないのはそのため。
それに、ゲームで一番重要な要素は「熱中できる要素があるかどうか」がKeyであり
その要素は3Dの品質とゲームの内容/種類どちらに比重があるかと言うと後者。
よって開発者がどこにポイントを置いて開発するかというと、3Dの品質ではなくて
ゲームの内容->ゲームの核となるシステムの定義づけの方に金かけるだろう。
「DX11なんて不要」
↑NVがすばやくAMDより対応してたらそんなセリフ吐かない
> 50-100kmの道のりを30-40km/h程度で巡航するなら
> 体力は高校生の運動部レベルが必要
ちなみにこれは、平日の朝飯前に
よく訓練されていないおっさんの俺が
10万そこそこのクロモリロードでやってます
だいたい870-860程度
雑音テヘごんだんごの一人劇場がはじまるよ!
>>302 日本で50km-100kmを巡航出来る場所がどこにある?
北海道?
>>306 おまえはなにをいっているんだ
そもそも陸上交通に巡航を使うのはおかしいけど
50km-100kmの周回なんて自宅の庭レベルでだって可能だろ
この馬鹿夫は環状コースを走る発想はないのかね・・・・
ひとつ聞いていいか?
その辺の話がどうAMDの次世代CPUに戻れるんだ?
関連用語使ってるだけの単なる妄想連レスとそう違いは無いんだし
戻って来れなくても別にどうでもいいじゃないか
>>307 何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
ローラー台とかいうんじゃないだろうな。
結局たとえになっていないということ。
概念論に現実論ぶつけるなよ。
煮干しでも喰っとけ。
>何を言っているかって、自転車で高校生の運動部レベルが、
>50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
おまえ本当にチャリ乗ったことある??
概念論とやらにもなってないだろ。
俺は厨三の時に260Kmを8時間で走ってたぞw
しかもランドナー車で。pまけに帰宅部でなw
100Km以内なら余裕で35Km/hは維持できるだろ
>>313 ちょっとの時間巡航するというだけなら出来るよ。
でも50km-100kmを巡航するっていうのがまず無理な話。
巡航という意味をわかっているのか?効率よく走ることだぞ。
出来るというならやってみろ。
出来るならアマチュアのロードレースで上位入賞出来るわ。
巡航の新解釈だな
巡航速度(じゅんこうそくど)とは、航空機や船舶などが燃料の消費効率が最も良い状態で移動する速度。
通常時の移動に用いられる、経済速度。
ロードレーサーなどで長距離走行をするライダーの間で、
基本とする走行速度として表現するが、
「いかに少ないエネルギーでより遠くに移動するか」の概念が無視されており、誤用である。
> 50km-100kmを巡航するっていうのがまず無理な話。
荒川ロードの一本道だけですら80kmあるのに(´・ω・`)
何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
でも北海道でなら出来る。
北海道が有頂天だな
俺てっきりこのスレは団子が知識をひけらかしたいだけのオナニースレだとばっかり思ってたけど、こいういう流れになる事も有るんだな。
>>320 > 自転車で高校生の運動部レベルが、
> 50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ
だから、コースは荒川沿いを始点終点で余裕で80kmあるだろ、
体力的には中学生レベルでも余裕で出来るぞそんなもん。
ソースは中学時代の帰宅部のチャリマニアの俺。
ちなみに俺も大学行くまで道産子だったが。
田舎にカンパの50周年モデル置きっぱなしなんだよな
今売ったらいくらくらいになるんだろ?
何を言っているかって、自転車で高校生の運動部レベルが、
50-100kmを30-40km/h程度で巡航するなんて環状コースでも無理な話なんだよ。
しかし青函トンネルはガリバートンネル(ドラえもん秘密道具)なので
それを通り抜けて北海道に着いた高校生なら余裕
おれは北海道属性の高校性だから一目置かれる存在
大腿の肉割れを自慢するスレはここですか?
さて串焼きいってくるか
パイプライン内部にたくさんの命令を抱え込んで複雑に加工してスループットを上げるIntel
単純で貧弱なパイプラインを多数並べて、これだけ流し込んどけば詰まることないだろというAMD
現在の整数系ベンチマークではほぼ全てのシーンでAMDはIntelに負けている
唯一AMDが勝てるのは予測の効きにくい分岐の密度が極端に高いベンチマーク
各所のキューに命令をバッファするIntelの設計では、どうしても予測ミスペナルティが大きい
人工的にレジスタ読み出しストールを発生させるとIntelは遅いけど現実のプログラムでは起こらない
だからなのはおまえ。
巡航するっていうのは効率の良い状態で移動する速度。
つまり人間にたとえると心拍数で60%程度だ。
試しに心拍計付けて走ってみな。
つまりだ、インテルはフルパワーで頑張ってぶっ飛ばすけど、
AMDは巡航することに重みを置いているということだ。
フルパワーで頑張らないことに重みを置いた結果が「CoolSpeed Technology」ですか?
まだそんな妄想を言ってるのか
それでも北海道なら・・・北海道ならきっと何とかしてくれる
トラックの後ろに張り付けば一般人でも時速100kmで楽々走れるぞ
ギヤ比をいじった自転車と安全装置が必要なので実用性は無いが・・・
NHKが試してがってん系の番組で実験してたよ・・・
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倍になって微妙なところかな?
ダンプの後ろに張り付いて150回転位させて80km/h弱を出したことはあるが、
ダンプが止まったら死ぬなと思ったよ。若かりし思い出・・・・。迷惑だな。
そもそもブルドーザーってネーミング自体が速くないから、
コアを増やして押していくっていうのがAMDなんだろう。
早さではインテルに勝てないよ。
整数スカラ並列度は頭打ち
ベクタではGPUにボコボコの現状ではキャッシュ性能だけ(じゃなく分岐処理等もだが)が頼り
そのキャッシュがBullでは大変化
元々キャッシュが貧弱なままでIntelと張り合って来たAMDだけど
ここでそのキャッシュに手を入れてどうなるかって状況だ
おいつけそうかなーと思った矢先にまた離される
なら、マシンの改造(HD2xxx→HD3xxx→HD4xxx→HD5xxx)か
ショートカット(8800GT→9800GT→GT240)すればいい
規制解除されてから雑音さん絶好調ですな
1の知識から10の願望を膨らませ100罵る
せめてその1の知識を自分の狭量さを曝け出すため以外に使えないものかね
>>333 性能差が本当に1:1.15程度だったらよかったのにね
メモリ帯域依存度の高くないSPECintですらNehalem(HT ON)が対Barcelonaでダブルスコアだからなあ
と自分に言い聞かせたいんだな。可哀想に
Nehalem のスコアは?
団子ってNehalemとLynnfieldの区別も付かないレベル?
>>333 > Bulldpzerのコア1個のサイズ&性能がK10程度だとすると
コアあたり3way→2wayで色々削ったのに同サイズとかねーよ
NehalemのスコアってHTT有効にした似非8コアだろ
コアに占める整数演算器の大きさなんて微々たる物だろう
大きいのがいいなら屁ルミでも使っとけって感じだな
>>348 その似非8コアに真性4コア×2ソケットがどっこいなんだぜ?
Bulldozerはさしずめ仮性8コアか。確実にK10の8コアよりはIPC落ちると思うんだが。
なんでIPCに必死なんだこいつは?
じゃあクロック数で勝負するのか
Pentium 4だな
POWER6で
なんか言われたら勝ってる部分を並べるのは良いが何の話をしてるんだ
キリガイAMDerと同じじゃん
BullのIPC設定の方針は私みたいな素人には予測しようが無いな
せめてコアサイズの予測とかが出れば考えようも有るが
>>353 ・シングル性能
Nehalem>K10
・マルチの効率
実コア>HTT
で総合的に互角ってだけ
何がおかしいのか理解できない、団子は馬鹿なの?
馬鹿だよ
362 :
Socket774:2010/05/08(土) 16:38:50 ID:knXGA7+S
8コアのBULLが2,3万円で買えれば、うれしいではないか。
363 :
Socket774: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
たぶん買えるよ
X6が1〜3万、X8が2万〜5万だろうね
価格戦略的にはIntelのClarkdaleとLynnfieldみたいな感じになると思う
Sandybridge6コア次第で10万円の価格帯でも出るかもしれない
あとは強烈なターボが欲しいね
8コアもあればターボ発動条件を満たす機会は十分に多くなりそう
compilerの性能差を語るスレはここですか?
エンコ坊的には、2モジュールの高クロックモデルに期待。
スレの流れを無視して壊れた録音テープみたいに自分の都合の良いデータだけ繰り返し並べ、都合が悪ければスルー
最近の団子の行動パターンってまんまテヘの行動パターンと同じじゃねーかw
やはり団子=テヘか…
でもテヘ本人は他人を演じきっていると本気で思い込んでいるから困る…w
恐怖政治による最適化を語るスレですよここは
しかし団子が必死すぎて笑える
1個や2個インテルが有利なベンチマーク見せられても、だからどうしたって話なんだが
現実に1090Tは売れまくっているし、i7じゃなくX6選んでいる奴も少なからず存在する
そもそも、875K出してくるほどIntelもK10の多コアを脅威に感じているよ
ほとんどのマルチスレッド対応のベンチマークでi7とX6は数%の差で競っている
1割以上の差があるのは極限られた場合のみの状況で何を叫んでも見苦しいだけだね
>>376 UMCといい、片っ端から買いまくるつもりなのかね
>>371 Stream TRIADはHPC向けのメモリ帯域ベンチマークだね。
まあ、3chと4chじゃその程度の差は出るだろうね。
でもBulldozerが重視(笑)してるらしい整数演算性能にその手のベンチはほとんど意味がないよ。
ついでにいうと実際のHPC用途ですらそれほど優位な差ではないかもしれないね。
メモリローカリティを意識してプログラムをチューニングするのが当たり前だからね。
ただでさえMP(4ソケット以上)による密結合クラスタよりもDPの粗結合クラスタのほうが広く使われてるくらいだし。
最新レスでいきなり”粗結合:”キタ
ググったらもっさりスレ36だったんだが
ふざけて妄想埋め荒らししてるだけなら死んでくれ
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/についてなにか思うところはありませんか?
Bulldozerの否定はIntelが研究分野で最も力を入れてるSCCの否定にもつながるから止めとけ
AMDが重視していこうとしてるのは単なる整数演算性能じゃなく、コスト当たりや電力当たりでのマルチスレッド性能だよ
ベンチマークでの優劣なんかもうたいして重要視してないってこった
382 :
Socket774:2010/05/08(土) 18:44:12 ID:knXGA7+S
383 :
Socket774:2010/05/08(土) 18:45:47 ID:JZZ71bgH
とはいえベンチマークで明らかに劣るようなアーキテクチャにはしてないけどな
実効性能や扱い易さを重視していて、ろくに使われもしないHTTやTB任せのNehalem系よりは人気出そうだ。
>>381 それは既に立ち枯れAMDという事なの?
もう復活の見込みは無いの?
速くて安くて安心のAMDは何処へ・・・
要らない子
ついでに言うなら
AMDは価格戦略でしか対抗できず
CPUでもGPUでも
Radeonに制限がないから中華製のtengaもRadeonつかってFireProは無視
自分の首絞める行為をやるしかない
今後の製品でも
シングルスレッドでのK10→Bullのユニット数変化は
デコーダ+1
ALU-1
SIMD±0
あとはキャッシュが大変化
AMDの弁・口調によればALUが2つになっても
性能の下落はせいぜい2,3%てとこか
分岐・クロック・キャッシュ(ヒット率)、等の未知の項目からすれば何でもない
相手の収入源を断つってのも戦略の一つだろうね
GPU分野は価格戦略っつーか勝手にNVが自爆しちゃって逆に値上した経緯が・・・
最近ではどこかの県立大学の教授がGTX285だかGTX280だかを使ったスパコン作ってたがそれについて何かコメントはないでしょうか・・・
>>386 ビデオカードは元々大勝しているとこを買っただけだから、そこは安心している
けれど、問題はチップセットとCPU・・・
こっちを頑張ってほしい
>>392 買収した当時のATIって別に大勝利じゃないよな? むしろ…。
あれってCUDAを介さないで直接動かすのかな
彼らの研究目的は『汎用GPUによって安価に高性能なスパコンを作る』ことにある
スパコンを作る研究であり、得た処理能力を彼ら自身が何かに使う訳じゃない
TeslaやFirestreamでは研究する意味が無い
×『汎用GPUによって安価に高性能なスパコンを作る』
○『一般大衆向けの製品であるGPUによって安価に高性能なスパコンを作る』
3 ALUのk8と2 ALUのnanoで差がないから
ブルも差がないだろう
あ、でもnanoのALU2は分岐命令と単純命令だけだから1.5 ALUってとこか
>>391 値上がりって、TSMCのせいで数が作れない、部材(メモリとか)の高騰のせいだぞ
nano-eでは更に2-3割りパフォーマンスが上がる
録音ってコテに直せよテヘごんだんごさん
焼き殺されたのか?団子
SandyBridgeと同時期のリリースといわれていたBulldozerなのだが
まだサンプルの噂とか入ってこないな
まだ登場まで1年くらいあるからのんびり待とうぜ
そういえば、256itAVXは2コア共有だけど、SSEやFPUはコアと同数の搭載で性能も向上しているっぽいかな
k10のSSE/FPUユニットって、K8の80Bitユニットに後付で64Bit付け足したものだから、
構造的にムダや性能の足かせがありそうだったけど、
Bulldozerでは最初から128Bitユニットとして新設計されているから、性能が少しは良くなっていそうだ。
K10.5はSSEに限らずいろんな部分がK7からの度重なる拡張でムダだらけで足かせだらけな気もするから、
ゼロベースで新規開発しているBulldozerコアは、かなり効率がいいデザインがされてると思う。
>>393 NVIDIAを買えばよかったのに・・・とか言われてたよな。
結果的によかったけど。
>>405 >k10のSSE/FPUユニットって、K8の80Bitユニットに後付で64Bit付け足したもの
マジなの?
>>381 > Bulldozerの否定はIntelが研究分野で最も力を入れてるSCCの否定にもつながる
つながらねーよヴァ-カ
整数クラスタがスレッド毎に分かれてるだけでフロントエンドの数も同時実行スレッド数も
Sandy Bridgeと変わらない、製品レベルの代物がIntelのメニーコア研究とどう繋がる?
それともAMDは実験段階のものを製品化するのか?大した主張だな。
>>383 何故同じページを引用する?
同じページになぜレイテンシの表があるのか英語くらい読めるだろ
なぜXeon X7560のスループットが低いのかちゃんと説明されている。
英語読めないわけじゃないだろ
なんだか自分の仮説にすごい自信を持ってるんだな団子って
すごいなぁ
結論はテヘ権田はインテルマンセー以外は受け付けませんってことだろ?
団子じゃなくてテヘ権田の別人格だろ、
いちいち俺らが馬鹿に付き合って区別して呼ぶ必要ねーだろ
そそ、そもそもBulldozerがトランジスタ効率を追求した構造という主張(思い込み)に賛同してない。
なぜ整数クラスタ2つとFP/SIMDクラスタの3クラスタで別々にスケジューリングことでトランジスタ効率あたりの電力効率が
どう向上するのか全然わからん。
というか、Complex Decoder×4の時点で既に水膨れだろう
結局この馬鹿は屁理屈さんざんこねくりまわして
言ってることはインテル最高しか言ってないんだよな
>>407 マジだよ
K7/K8は 80BitFPUが64BitSIMDの代わりもしていて、
SSEは128Bitだから前半と後半の2回に分けて計算していた。
GF100の単精度と倍精度の実装と同じようなもの。
しかしそれじゃ、Core2以降に対抗できないから、K10ではFPUの隣に64Bitユニットを追加して、
128Bitを一回で計算できるようにした。
つまらん人格攻撃しか言うこと無いのかね
いやだねえAMDが否定されると自分が否定されてるように思えちゃう可哀想な人は
ちなみに
>>416は大体正しい
K10の上位64ビットのSIMDユニットを新たに追加する実装はAMDが特許も申請してた
つーか、積和ユニットもだが、SSSE3, SSE4, AVXも追加するんだからFP/SIMDクラスタは相当な規模にはなりそうだぜ
>>414 > そそ、そもそもBulldozerがトランジスタ効率を追求した構造という主張(思い込み)に賛同してない。
3wayは無駄が多いから2wayに減らしてるし、それに伴い色々軽量化してると思うよ
今よりは効率向上していると見て間違いない
> なぜ整数クラスタ2つとFP/SIMDクラスタの3クラスタで別々にスケジューリングことでトランジスタ効率あたりの電力効率が
> どう向上するのか全然わからん。
>
> というか、Complex Decoder×4の時点で既に水膨れだろう
消費電力が大きいデコーダーが、コアあたりX3だったのがX2に減るから消費電力は減ると思うんだが。
なんか枝葉末節にこだわりすぎて大局を見れてないんだな団子って
>>419 > 消費電力が大きいデコーダーが、コアあたりX3だったのがX2に減るから消費電力は減ると思うんだが。
?????
同じスレッド数で消費電力が減る理屈であってもK10の4コアよりBulldozerの8コアの方が省電力、という主張じゃないよねそれは
さて、2スレッドで4命令/clkなのはわかったが片方のスレッドが休んだときに1スレッドで最大何命令専有できるのかねデコーダは
そもそも可変長命令のデコーダで3命令/clkが4命令/clkに増えるのはリソース1.33倍とかの次元じゃないぞ
なんで連投するのこの子、纏めるとか言う発想無いの?
それは1コアあたりに何命令まで発行するように設定されているかが判らないと推測しようが無いんじゃない
電力についてはコア増えた分クロックも落とせば何とでもなる
電力効率も大事だがそこだけだと性能が伸ばせない
これはintelもAMDも同じだけど、そのバランスのとり方に差が出て面白い
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があるの?
>>420 > 同じスレッド数で消費電力が減る理屈
それを言っているだけなんだが
>K10の4コアよりBulldozerの8コアの方が省電力、という主張じゃないよねそれは
もちろんそんな主張した覚えはさらさらないな、何処を読んだらそう勘違い出来るのか教えて欲しいくらいだ
まあ、Bobcatの8コアならK10 4コアより省電力っぽいけどね。
個人的予想は K10 4コアとBulldozer 6コア(3モジュール)が同程度というところだな。
>>421 > そもそも可変長命令のデコーダで3命令/clkが4命令/clkに増えるのはリソース1.33倍とかの次元じゃないぞ
それってつまり、2コア(モジュール)換算だと 6命令から4命令に減るのはリソース0.66倍とかの次元じゃないってことになるよね
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の発展は、そうした方向へ向かってゆくのかも知れない。
x86の命令セットがボトルネックだって話は昔からあって、
RISC勢とかItaniumとか作ったわけだが、皆x86に敗北した。
パフォーマンスでも電力効率でも。
隆盛(たかもり)くんLOVEなショタホモの目的は
その子供とあらあらしく結合することでした
それが露呈した直後に押入れ充電でやる気満々
日付が変わった直後に2時間だけ家宅(このスレ)捜索で荒らし回り
隆盛(たかもり)くんが居ないと判って退散したようです
でも痴呆だからまた結合しようと来るだろうな
>>425 Vector PathとDirect Pathは排他だから同時に動くことはないよ。
>>427 > それってつまり、2コア(モジュール)換算だと 6命令から4命令に減るのはリソース0.66倍とかの次元じゃないってことになるよね
お前は何を言ってるんだ(AAry
1つの命令ストリームから6命令同時に取り出してデコードする必要はないので6命令という数字に意味はない。
問題は、1命令ストリームから4命令/clkを取り出してデコードできるかということ。
もしそうならリソースは指数グラフとはいわないまでも単純に1.33倍よりは確実に増えるし、
3命令×2コアよりリソースが減るとも言い切れない。
その理屈が解らないなら何も言うことはないよ。
何度も言うけど、固定長命令じゃないのよ
>>429 コンパイラの吐かないプリフィックスの処理がどうこうなんて手動でアセンブる変態を除けば全く関係のない問題だ
後藤は頓珍漢だな
既に60レスもつけてる奴も大概だがな
ああそうか
>380に串止められたせいで日付変わるまで出て来れなかったわけか
んで出て来た途端に>420
>コアあたりX3だったのがX2
↓
>K10の4コアよりBulldozerの8コア
↓
「K10の4*3よりBullの8*2のほうが少ないという結論とは直結しないよね」
相変わらず脳味噌腐ってますな
12より16のほうが多いのは当たり前
このスレには気持ち悪いホモのゴキブリと結合したがってる少年など居ない
さあ早くヘドロの中に帰るんだ
死んでくれるならそのほうが嬉しいけど
まだ串とかいってるのか
妄想きわまれり
訂正
人間なら脳味噌は普通に在るけど
こいつは普通に無いかもしれない
無いものは腐っても居ないもんな
日付が変わるまで名無しで頑張ってたもんな
bulldozerのデコーダッテ
>>429で複雑になりすぎて効率が悪いからintel,centaurがやらないって言ってる
4x complex decoderなのかね?
nehalemでさえ1 comp,3x simpleなのだろ?
たとえば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ステージで完結させる必要がないのでかえってやりやすい面もある。
たとえば まで読んだ
>>439 実際問題μCode ROM参照が必要なデコード処理だとどのみちμOPsが増大するので4並列でやる意味ってあんまりないんだよね。
初代PPro〜Pen3でネックだったメモリロード+論理算術演算の命令はSimple Decoderでも1サイクルで処理できるようになってる
普通に考えればVectorPath 1→4は不可解だよね。
AVXをDirectPathで処理する余裕がないので仕方なくDirectPathを増やしたという説
K7でSSEが極端に遅かった問題の二の轍を踏まないためにはそのくらいは必要なのかもね。
256ビット命令なら少なくとも2μOPsに分解する必要があるからね
×AVXをDirectPathで処理する余裕がないので仕方なくDirectPathを増やしたという説
○AVXをDirectPathで処理する余裕がないので仕方なくVectorPathを増やしたという説
だんごもずいぶんメッキが剥がれてきたな、地が見えまくってる
キャラ設定が破綻しかかってるし、これはもう限界だな
糞長い長文垂れ流してるが結局インテル最高しか言ってないんだよなこいつ
デコーダはかなり謎だな
ttp://www.life-lab.com/amd-lab/amd686.html ではショート・ロング・ベクタの3種あるとしている
P6はショートが3つでK7はロングが3つ、ネトバもロングだけだそうで
Bullが「全部出来るデコーダ4つ」ってのも過去ログで一度だけ出た噂を
ショタホモウンコカブリが火病って連呼してるだけなんじゃないか?
まだ詳しいソース出てなさそう
シングルスレッドで完全4デコード
マルチで0〜4(普段は2)柔軟に出来たらそりゃ凄いけどな
Xネトバもロングだけ
Oネトバもショートが無い
か
団子…完全にキャラがテヘに戻っているなw
一生懸命長文書いても「Intel最高!」とだけ書いてもまるで同じ扱いしか受けないなんて可哀想
結局のところ、団子ってテヘなの?
やってることは同じだなw
ごめん、K10の時点でVector Pathも3mops/clkか
いや、おまいらが不愉快なのはわかってるよ
反論できることなんて何も無いから人格攻撃を逃げ道にしてるのも
反論できることなんて何も無いから人格攻撃を逃げ道にしてるのも
都合の悪いことにも答えてから言ってみろよw
アホすぎるなこいつはw
>都合の悪いことにも答えてから言ってみろよw
こっちの台詞だ
何にせよintelマンセーを叫びたいだけならスレチだな。
得意の串が使えないのはつらいな団子
こいつはいつも「intelマンセー」より「自分マンセー」だし
今この瞬間は何より「隆盛(たかもり)くんケツマンコー」だぞ
ああきもい
「マンセー」って言ってるようにしか聞こえない人と会話は成立しないな
去年の12月頃はまだBulldozer擁護にまわってたが情報が公開されるにつれ流石に擁護できなくなった。
>>381がSCCを引き合いに出してるがAMD版SCCってのはある意味正解なのかも(製品化できるレベルでないという意味で)
いい隔離スレだこと
そそ、アホが火病ってるのを見るのが好きだ
理屈に感情論で返したらその時点で既に負けですよ
Bulldozerって、モジュール内の2個のコアのうち、片方のコアだけクロックを変えたり止めたり出来るのかね
取り合えず現状として団子は存在自体がこのスレに対してスレ違いと言う事は分かった。
理屈で返してるじゃん何か問題でも?
団子は存在自体がこのスレに対してスレ違い
日本語が理解できない馬鹿だから張り付いてる
馬鹿は救いがないよなw
俺の指摘に対して未だに技術的反論が出来ない君はこのスレに必要ないよ
4*3<8*2つまり12<16が算数の世界で確定事項だということをいい加減解れ
昨日はなぜかVIAを持ち上げてたし、むちゃくちゃだぞ団子
いや
理解しなくていい
明らかに不可能なことを言うつもりは無い
でもせめて 覚 え ろ
現実はこうだけどね
消費電力:Barcelona 4コア≒Nehalem 4コア
スループット:Barcelona 8コア≒Nehalem 4コア
>>467 せっかくの知識なんだからもう少し役に立ててみない?煽り以外でさ
無駄に刺々しく客観性にかけるような物言いを直せば相手も黙るだろうに
内容にも十分な説得力があれば、という前提はあるけどさ
>>473 見ての通り、ここは団子にとって知識をひけらかしたいマスターベーションの場になっているから、そう言った制限を
掛ける事は多分無理だと思う
バグ満載コピペという撒き餌で隆盛(たかもり)くんをおびき寄せてウホろうというハッテンバだな
ここには居ないんだから釣れるわけ無いんだが
死体撃ちやめろよ団子
権田(団子)の言動を見ていると現時点ではAMD>Intelだということか…。
ここ最近の権田のファビョり具合はプレスコがアス64にフルボッコにされていた時代の権田を思い出すわ。
そうだねOpteronにXeonが惨敗だね
>>474
>>473 人間性の問題だから無理だよw
わざわざ嬉々として煽りに来る時点で終わってるだろw
> このページは円周率4万桁を並列アルゴリズムbbp法で計算した時のランキングです。
4万桁なんてAtomでも1秒かからない処理を遅いアルゴリズムで解くんですねわかります
いいからAMDの次世代CPUに付いて語れや
本末転倒な寝言
>>474 > Compiler: Sun Studio 12 Update 1 (internal build 39.0)
リンク先には
Compiler: Intel C++ and Fortran Compiler 11.0 for Linux Build 20080930
と書いてあるが?
484 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2010/05/09(日) 11:38:25 ID:sNWFFdis (24回)
> このページは円周率4万桁を並列アルゴリズムbbp法で計算した時のランキングです。
4万桁なんてAtomでも1秒かからない処理を遅いアルゴリズムで解くんですねわかります
superπだって糞遅いソフトだよな、あんなゴミ計算でCPUの性能語ってる奴らって馬鹿なんだよなw
>>484 また自分の都合に良い部分だけ切り出してファビョてますね…。それともこのベンチの趣旨が本気で解らないとか?
まぁ今更
>>483のペンチをあえて持ち出したのは団子の行為を真似させてもらっただけだけどねw
つまり自分にとって都合のよい結果だけを厳選してカキコする行為をね。
要するに
>>483の否定は自分自身の行動を否定しているという事だよ。わかる?
>>433 > 3命令×2コアよりリソースが減るとも言い切れない。
> その理屈が解らないなら何も言うことはないよ。
要は4命令/clkと3命令/clk*2のどっちが効率いいかって話だよね
で、Bulldozerの場合、(2命令*2)/clkで動かすことも想定してそうだ
それだけの話しで何でこんな騒いでるんだ団子は
>>492 前提条件が「AMDを貶めること」だから。
理屈に感情論で返したらその時点で既に負けですよ
彼が頭が悪いのは客観的事実ですので
どう考えてもテヘ=団子でしょw 行動パターン、言動がまるっきり同じ。
仮に同一人物ではないとしてもテヘの劣化コピーに変わりないしw
でもテヘ的にはだんごは鉄壁のインテリキャラなんだぜ?
【ここまでのまとめ】
CPUの温度センサーで強制クロックダウンする機構をMagny-Coursの「省電力技術」に応用したAMDは凄い
>>498 そんな設定だったんだ。完全にキャラ設定を崩しちゃった感じだな。
キャラ立ては難しい
>>494 ちょいと反論というか気になった点
> それに耐えうる高速駆動の加算回路が必要になる。1.33倍のリソース増大とは言えないってのはそういうこと。
3命令→4命令で増大するのは分かる
問題は3命令*2から4命令*1で増大するかどうかだな
3命令のリソースを1としたとき、4命令で1.33、3命令*2で2なら余裕でリソース削減の効果はあるだろ。
>
> いっぽうIntel伝統のプリデコード方式は生の命令ストリームを投機的に並列スキャンして
> 命令長の確定時点で頭出し失敗したものを破棄する。
> 命令フェッチ帯域分のスキャナが必要になるので一見AMDより高コストに見えるが、頭出し処理を
> 1ステージで完結させる必要がないのでかえってやりやすい面もある。
>>499 それは安全性確保の上で必要な機能だろ?
どちらかというと遅すぎた実装だね
サーバーやHPC向けで対応してないCPUなんかないだろ(知らんけど)
はいはい、要するに読んでないのね。
次の4命令までに4つの命令の長さを加算しないといけないのがどれだけ重大かもわからないのね。
3命令なら2回分で済んだので2倍速程度の加算機があれば十分だったが4命令だと3倍速が必要になる。
実際にはプリデコードビットから命令長情報を展開するのすらゼロコストではない。
それともBulldozerはプリデコードキャッシュ辞めるんだっけ?
投機的な命令頭出しをやる場合はパイプライン段数は増えるが1ステージの負担は多少軽くなるかもね。
>>503 フェイルセーフのためではなくなぜか「省電力技術」なのが味噌です
Bulldozerアーキテクチャの肝は、3命令*2から4命令(2命令*2)*1に変更したことによる効率向上は間違いない
デコーダーが小さくなれば、以降のパイプラインや内部バスも規模が小さくなり
単純に考えるとスレッド辺のコストが約0.7倍、あるいは効率が1.33倍になる
>>504 3命令や4命令なんてたまにしかない程度の頻度だろ?
大部分は2命令って話をよく聞くから、4命令時で多少効率が悪いとかはどうでもいいよ
Bullで重要なのは(2命令*2)/clkの方だと思うが違うのかな?
やっぱり馬鹿だな
ピークに合わせて回路設計は行われるんだよ
うん、507はアホ過ぎるw
Opスレに6176SE買った人いるからフルロードでクロックが下がるか試してもらえばいい
正しくクーラーが稼動していればダウンクロックするとは思えんが
>>505 リードミスか説明ミスかは知らんが実質フェイルセーフ機能だろ
そこまで騒ぐほどのもんでもないよ
適切な冷却していて高負荷でクロックダウンとか企画段階で不採用機能だろ
そもそもIBMやHP、Cray辺りがそんなクソ機能許すはずはないな
>>440に当てはめると3命令の場合たとえば
【最初のサイクル】
v1 = IP + inst1
v2 = inst2 + inst3
【次のサイクル】
IP = v1 + v2
で2サイクル。
これを1クロックで済ますには少なくとも2倍速で動かさないといけない。
もし4命令/clkになると3サイクル必要なので、更に高速化が必要。
更に命令ポインタ加算ユニットの高速化が必要になる。
命令の頭出しという単純な前処理ですらここまで圧倒的な高コストが強いられるのに、
単純にデコーダの総和だけでしかものを考えられないのって本当に馬鹿としかいいようがない。
これでまだ解らなければ小学校からやり直すべきだよ。
>>510 俺もそう思う。
ひょっとしてAMDはヒートシンクレスを目指しているのか?
>>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パスで処理するしかなくて性能出せないけどね。
フルロードで簡単にクロックが下がるのなら
ベンチの途中で不自然なパフォーマンスダウンをしたりとか、
クロックが落ちたという報告があってもいいと思うけどな。
SIMDユニットは共有なんだからデコーダは完全には独立させられないだろう
だから4命令発行のデコーダと表現されているだけで
デコーダのコア1/コア2への命令発行の振り分けは1:3、2:2、3:1程度で
片方のコアに対し4個の命令を同時発行は想定していないんじゃないの
ならなんでデコーダが共有なの?
お前の詭弁通りなら2命令/clkのデコーダを1コアずつで十分じゃないか
>>516 ようやくまともな意見が出た。
まあ、バックエンドの細さ考えればその程度で十分だと思うよ。
>>512 > で2サイクル。
> これを1クロックで済ますには少なくとも2倍速で動かさないといけない。
> もし4命令/clkになると3サイクル必要なので、更に高速化が必要。
> 更に命令ポインタ加算ユニットの高速化が必要になる。
>
> 命令の頭出しという単純な前処理ですらここまで圧倒的な高コストが強いられるのに、
> 単純にデコーダの総和だけでしかものを考えられないのって本当に馬鹿としかいいようがない。
俺の考えじゃ頻度の少ない3や4命令は2パスとかで十分
お前は頻度が少ない4命令も1パスで処理する
話が噛み合ってないのは、効率重視とピーク重視の違いってことなんだな
そりゃ、前提が違えば噛みあうはずも無い
Jcc+CMPのMacro Fusionが2スレッド同時に
できればピークは6命令/cycleになるのか?
>>517 > ならなんでデコーダが共有なの?
> お前の詭弁通りなら2命令/clkのデコーダを1コアずつで十分じゃないか
共有の方が効率よさそうだし、極稀に出てくる3命令や4命令を1clkでデコードするためだろ?
それくらい分かれよ
>SIMDユニットは共有なんだからデコーダは完全には独立させられないだろう
これは関係ないな。
デコーダが別でも演算ユニットは共有できるし実際にそういう製品は存在する。
>>515 そんな事例聞いたこと無いな。毎度の嘘だろ。
>>518 >
>>516 > ようやくまともな意見が出た。
>
> まあ、バックエンドの細さ考えればその程度で十分だと思うよ。
バックエンドの細さ無視してピーク性能で騒いでたお前が言うなww
> 俺の考えじゃ頻度の少ない3や4命令は2パスとかで十分
アホだなやっぱり
2パスかかったら結局2命令/clkだろうが
>>523 そもそもピーク時にクロック降下するなんて誰も説明してない。
でもAMDも言ってるとおり「省電力技術」なんです
キモホモはベクタデコーダ2*2(噂)に嫉妬火病するより
まず12<16を覚えるほうが先だろ
これからすぐ死ぬんなら何も努力しなくていいが
>>525 お前がアホだろ
pipelineでの処理がだよ
デコーダーとpipelineがごっちゃでコメントした俺も悪いけどな
4命令時の動作
デコーダー:1clk
Pipeline:2パス
2命令時
デコーダー:1clkで2スレッド分
Pipeline:1パス
>>526 最早そんなとこしか煽れないのかお前はw
だからどうしたのって話だな
結局は大手サーバーメーカーや顧客がマニクール採用しているから実質問題無い機能ってことだろ
デコードの件は複雑だしあまり知らないんだけど
AMDK7系はプリデコードで命令に区切り付けたものをL1Iに入れてるんじゃなかったっけ?
次にデコーダでMacro何やらに変えて
スケジューラでμに分解という3段階のデコード
食糞ホモはIntelのデコードの件をバグコピペしてる気もする
プリデコーダに複雑さを移すだけで、問題はあんまり解決されないんじゃないの?
530の考え方だと。
キャッシュだぞ?L1Iって
>>528 あーやっぱり解ってないな
まあいいや
どう
>>440のモデルに基づいてどうやってパイプライン処理するのか説明願おう
整合性が無さ過ぎる
>>533 いや、だからさ、4命令時の処理なんかどうでもいいんだよ
速かろうが遅かろうが総合的な処理性能に与えるインパクトはたいしたことが無いからな
お前がなんで4命令処理に拘るのが分らん
>>518 でもお前自身が言ってるだろ?
Pipelineが貧弱だから1:3、2:2、3:1程度で十分だって。
ここまで偉そうに俺様間違いない絶対だ理論ぶちかませるんならインテルでもAMDでも入社しててめーでCPU作れよって話だよな。
何が面白いって
>>440で既に
> ところが可変長だと命令の末尾が確定できなければ次の命令の頭出しはできない
に釘さしてるのに「2パス」で処理するとか言ってることだよねwww
しかも
> 4命令時の動作
> デコーダー:1clk
> Pipeline:2パス
>
> 2命令時
> デコーダー:1clkで2スレッド分
> Pipeline:1パス
スレッドの利用状況によって【パイプライン段数】が変わるとか
どんなアーキテクチャだよっていう
そのステージ数が動的に変わる機構だけで軽くリソース増加しちゃいそう
>440をちゃんと読んでみるとすげーな
以前ウンコは「プリデコードでほぼデコード完了」などと言ってたのに
今度は「デコーダがプリデコーダまでする必要がある」って
プリデコード+デコードを2回連続でしなきゃならない理由は「たまにPentium4にはL1Dが無い」からですか?
X「デコーダがプリデコーダまでする必要がある」
O「デコーダがプリデコードまでする必要がある」
もしくは「デコーダがプリデコーダまで兼任する必要がある」
>>536 妄想だけなら誰にでもできるレベル。
あと理論だけでは実践は無理。
> いや、だからさ、4命令時の処理なんかどうでもいいんだよ
どうでもよくないよw
どこの陣営もクロックサイクル単位でスレッドの命令ストリームを切り替えてフェッチする機構を採用してるよ。
AMDは違うの?
そもそも同じサイクルに2つの命令ストリームを同時にフェッチすること前提で語ってるけど
そんな機構自体コスト高いよ。
常識的に考えて同じ命令列から3命令ないし4命令を同時にピックする必要がある。
2つの命令列が「同時処理」されるのはアウトオブオーダ実行によるもので
デコード後の話。
>>537 俺って素人だからうまく説明出来てないんだな、そこはあやまるよ
2パスって言ってたのは、2回に分けてPipelineに流すってこと。
ABCDって命令があったら、ABを流した後にCDを流すってね
何も難しいこと言ってないしリソースだって食わないと思うが違うのかね
>>535でも言ったけど3命令や4命令時の動作なんか遅くても効率悪くてもどうでもいいんだ
Bullのデコーダーやpipeの構造からして2命令処理以外は遅くても仕方ないよねって感じだし
「2つの命令列(何これパイプライン?)」はスーパースカラによるもの
アウトオブオーダは1つの命令列での処理順序が逆(データロード完了順)になるもの
とはいえこれは現実世界の話
ウンコとショタが食料な世界のことは知りません
あとついでに
>538
△プリデコード+デコードを2回連続で
Oプリデコード+デコードを2回ずつ交互に
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に近いらしい事を言ってる。
是非とも団子の見解を教えてくれ
結論から言うと実は同じサイクルに2つの命令列を同時にピックする機構を設ける方がコストあがる。
固定長命令ならフェッチユニットを2重化して、スレッドAから12バイト、スレッドBから4バイトを
フェッチすれば3:1の割合で取り出すことができる。
しかし、そもそもx86は同じバイト数に何命令入ってるか解析するまで解らない。
同じ32バイトをフェッチしても1バイト命令が32個入ってる場合もあるし、
長い命令が3命令しか入ってない場合もありうる。
したがって、同じサイクルでAから2命令、Bから2命令みたいな割合で綺麗に取り出せるようなエスパーCPUは作りようがない。
できるのは奇数サイクルでAから32バイト、偶数サイクルでBから32バイトみたいな取り出し方だけ。
あとは命令の処理状況に応じてサイクルの割り当てが変わるだけ。
3行でまとめると
そもそも2命令:2命令とか3命令:1命令なんていうパーティショニングは不可能なんだ。
できるのはサイクル単位でスレッドAに4命令か、スレッドBに4命令か、だけ。
同じサイクルに別々のスレッドの命令が混在するはデコーダより後のステージで、どこのCPUのSMTでも同じ
ID:Yr7mfo0lのレスちゃんと読んでないのにアレだけど
一応言っとくと「ベクタデコーダ使うような長い命令の連続度(4命令がどうのこうの)並列デコード」と
「実行パイプライン・スーパースカラの並列度(ALU3つもイラネとかいうの)」は別物だぞ
全く内容かぶらない
それと食糞ID:sNWFFdisホモの発言は本当にムチャクチャ
むちゃくちゃの理由:「俺が気に入らないから」
というわけで、
>>420の問いかけの答えは、「基本的に常に片方のスレッドに4命令」でしたとさ
実装次第ではハシタが出た場合にだけ同じサイクルに2つのスレッドの命令がデコードされる可能性もあるけどね。
Bull8コア=4モジュール
4モジュールには4*4で16デコーダ
4*3<4*4で結局変わりませんが
いいからとっとと覚えろよ12<16を
546は正しいでしょ。
ていうか「えっそこから!?」ってのが正直なところだ。
ピーク4命令切り出せるデコーダは、2命令切り出すデコーダの
二倍の電力・トランジスタ数では到底収まらない。
それを2スレッドで共有すれば平均2命令しか切り出せないにも関わらず、だ。
Bulldozerのデコーダ共有は何かの妄想・誤解の産物だと思うが
デコーダだけ倍速駆動でもするつもりなのかねえ。
4命令発行のデコーダをA/Bのスレッドが交互に占有するぐらいなら
2命令発行のデコーダを2個用意して、それぞれをAとBのスレッドに割り当てた方がずっと良いんで無いの
>>551 なぜかパーティショニングできる前提で話してるからどういう論を展開してくれるか面白がってたのに
何かつまらん結論が出た。
>>545 げえ・・・
「K7系(という括りでいいの?)はプリデコード済みの命令がL1Iに入ってる」
てことを未だに記憶できないのか
チラシの裏に100回書くなりなんなりしてとっとと全部覚えろよ
>>552 その分デコーダ部分が肥大化する。
あと片方が詰まって片方が空いているときに無駄になる。
>>552 片方のスレッドがアイドルしてるケース(あるいはPOWER7のように休眠させるモードがある)ならば
4命令占有できて嬉しいかもしれない。でもデコーダから下は
1コアあたり平均2命令発行前提のリソース配分のようだから、やはり無意味だ。
>>555 4命令同時発行デコーダ×1は、
2命令同時発行デコーダ×2より、はるかに大きくなる。
>>556 コアAには2命令発行のデコーダーA
コアBには2命令発行のデコーダーB
モジュールとしては2命令発行デコーダ×2=4って意味ね
「4並列デコードを交互にスレッド割り当て」と
「基本2*2で状況に応じて割合を変える」のどちらが複雑で規模がデカくなるかは判らない
しかし今までベクタデコーダ1つ(1/3)だったのに
いきなり4つ(4/4)は増え過ぎだ
そこまで長命令が続くのか
でも2*2 (2/2)ならまだ判る
ていうかComplex Decoder*4がまだ噂の域なわけだけど
どっちにしてもプリデコード済みの件が解らない奴には
「Intelに無い(Cotre2のループ専用キャッシュのみ)技術に嫉妬乙」という言葉掛ける以外無いわな
2命令ならalu,aguは各1個で十分では?
片側で2〜3命令、FPUが2命令分(ただしレジスタ間movapsのリダクション可能なので実質それ以上)ってところか
1スレッドだけで4命令の帯域使っても十分お釣りが来る
>>546 突っ込ませてもらうと
>>516の
コア1/コア2への命令発行の振り分けは1:3、2:2、3:1程度で
片方のコアに対し4個の命令を同時発行は想定していないんじゃないの
ってコメにお前は
>>518で
バックエンドの細さ考えればその程度で十分だと思うよ。
って振り分けにも同意してたよな
これは勘違いか嘘ついたってことで
>>546の不可能ってのがお前の意見というか業界の常識ってことでいいんだな?
デコーダーの構造次第な気もするけどね
スレッド辺り2命令、2:2で振り分けることを前提にデコーダー作って、
3命令や4命令入っていた場合は、スレッドのデコードをし直すとかすればいいんじゃないかね
3命令や4命令が頻出する場合は低性能になるけど、それはよくあることなのかな
既存のアプリケーションや分野であったら教えてくれ
>>556 > 4命令同時発行デコーダ×1は、
> 2命令同時発行デコーダ×2より、はるかに大きくなる。
そこが間違い
本来の議論は2スレッド処理において、
K10の3命令*2と、Bullの4命令*1のどちらが大きいかだ
団子もお前ももう少し流れ読め
ごめんね お母ちゃんタケシが何言いたいのかわからなくてごめんね
>これは勘違いか嘘ついたってことで
俺は相手の知識を確かめるために勘違いをわざと見逃すことがある。
知らないなら噛みついても意味ないだろ。
ちなみに
3命令/clkのフロントエンドと1命令/clk、という非対称なフロントエンドがあって
クロックサイクル毎に通すスレットを入れ替えることができる、
とかなら割と出来る気がするよ。
ちなみにいうとCoolSpeed(笑)についてもわざと混乱させる言い回しをしている。
これがなぜ省電力技術なのかは割と単純な理由で俺はドンピシャな答えは知ってて敢えて言ってない。
何でいきなり雑音の真似?
>>564 そんなどうでもいいことへのレスはホントどうでもいいんだ
嘘ついてごめんなさいの一言で済む話
>3命令/clkのフロントエンドと1命令/clk、という非対称なフロントエンドがあって
そんな何処にも存在しないモノの話なんかどうでもいいよ
>CoolSpeed(笑)についてもわざと混乱させる言い回しをしている。
混乱どころか誰も気にもしてないことをお前が馬鹿騒ぎしてるだけ。
文句いうならそれを了承して採用した大手サーバーメーカーに言えよ。
で、
K10の3命令*2と、Bullの4命令*1のどちらが大きいか、
スレッド辺りの3命令や4命令の頻度や、それらが頻発するようなソフトや分野
スレッド辺り2命令決め打ちで、2スレッド同時デコード出来るかどうか
について屁理屈はないのか?
俺は相手の知識を確かめるために勘違いをわざと見逃すことがある。
ここは笑うとこかw
むしろパイプラインの構成要素ってデコーダだけじゃないんで
Decoderだけに拘っても意味がないと思うんだけどね。
乱暴な言い方をすればテーブル参照して対応するOpcodeに置き換えるだけの処理なんで
その個数だけを問題にされても全然本質じゃない。としか。
デコードそのものよりも1命令ストリームからデコーダの数分の命令を切り出す処理のほうがよっぽどコスト高い。
俺が今言ってるPickステージの実装コストなんてデコーダよりもよっぽど重要だよ。
あと、一般的なアウトオブオーダコアでDecoderのすぐ後くらいのステージにあるRenamerの話をすると、
その規模はパイプラインの並列度の2乗に比例して大きくなるね。
3^2 * 2 と 4^2 だと前者の方が僅かに大きいくらいか。
これの場合BulldozerはXOPに3ソースオペランド命令なんかも追加されてるので
K10の2コアよりBulldozerの1モジュールの実装コストが上がる要因はある。
> 混乱どころか誰も気にもしてないことをお前が馬鹿騒ぎしてるだけ。
実装の目的が全く解ってないから気にしないようにしてるだけだろwww
素直になれよww
クーラーが故障したときにP-Stateを強制的に下げるのを省電力技術とは言わないし
そもそもそんなことを目的としてない
今更だけど、AMDのサイトに書いてある英語も読めない奴らだらけなのか?
実はお前ら俺よりもAMD嫌いなんじゃないのか?
>>567 最強で人間として最低の言い訳でしかないな。
「後出しジャンケン無敵説」
で、そのジャンケンの俺より先に出したのは誰だよ
あまりにお馬鹿な珍説しか出てこないから自分でミスリードして自分でネタばらししたわけだが
L1I内で既にプリデコード済み
ダイサイズ等の無駄を気にしなければばりばりデコーダの数を増やせる恐ろしいAMD
でもIntelでもトレースキャッシュでそれより凄いのやってたんだよな
パイプラインはキャッシュから始まるからデコード関係全てを飛ばせる
でもPen4はデコーダが1つ(笑い)なので
その最初のトレースキャッシュに命令が溜まるのが遅く
普段から遅いのに初動が更に遅くなってしまう
というのが「もっさり」なのではなかろうか
逆にAMDはプリデコードを素早く済ませられるのでキビキビ
なんてことはないだろうか
串ウンコはそろそろ何か覚えたか?12<16は確定事項だからな忘れんなよ?
言い訳はもうたくさんw
恥の上塗りに気付よアホw
>>545-546の説明を俺より先に出したのは一体誰だよww
俺のミスリードに騙された無知野郎が必死だなwww
> 4命令時の動作
> デコーダー:1clk
> Pipeline:2パス
>
> 2命令時
> デコーダー:1clkで2スレッド分
> Pipeline:1パス
笑いすぎて飯がうまいなwwwwwwww
L1へのヒットに期待して、プリデコーダ部分はピーク4命令に対応できるだけの
供給能力はなくてもいってこと?
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の説明にも割と納得できる。
妄想乙>>オレ
>>577 俺にっぽいけど
誰に質問してんだか判らん
>>578 申し訳ないが、デコーダのスループットはモジュール全体で4命令/clkって公式発表が既に出てるんだわ
好調じゃん団子。これなら串を駆使しなくていいな!
>>580 パイプラインの連続した部分というのは
情報(命令)をすぐ次のリソースに流していかなければならないから連続している
でもキャッシュがあれば貯められる
パイプライン内でのリソース単位での能力の過不足はそのままパイプライン全体の能力に繋がるけど
キャッシュとかデコーダ共有等はそのデコボコをならす役目になっている
プリデコーダもデコーダの能力と吊り合っているのが望ましいけど
上記のようにあまり細かく調節しなくていいし
分岐予測ミスでパイプラインストールしてもプリデコーダ部分には関係無い、はず
過不足はそのままパイプライン全体の能力に繋がる
↓
過剰は無駄に終わるし不足は全体の能力を下げる
>>583 パイプライン間でのデコボコをならす役目というのは結構的を射てると思う
Intelはデコーダ後にあるLSDやRATや深いROBなどのバッファがデコーダ時のデコボコを吸収してくれるのに対して、
AMDの設計では、極浅いパックバッファと、レーン別でエントリ数が少ないROB・RSしかなくて、とても吸収できない
だから、デコードの平均帯域を確保すればいいIntelと、最低帯域を確保しないといけないAMD、というのが、
デコーダの設計の違いに現れてるんだと思う
>>570 高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
温度上昇で故障や異常停止することを危惧しているだけだし
まともな冷却をして高負荷時でも温度を低く押さえていればクロックダウンはしないってことだし
省電力って説明は意味不明だけど、まあどうでもいいよホント
>>568 > デコードそのものよりも1命令ストリームからデコーダの数分の命令を切り出す処理のほうがよっぽどコスト高い。
> 俺が今言ってるPickステージの実装コストなんてデコーダよりもよっぽど重要だよ。
デコーダー数に影響するから、そこを削るためにデコーダーを共有にしてるんだろ
>>575 素人にとっては、専門用語とかで細かく説明されるより、後藤の
「x86 命令換算で2命令程度しか並列実行できないケースが少なくない。
uOPに砕いて実行する場合でも同じで、3〜4 x86命令の並列実行帯域は、
あくまでもピークであり、平均はそれよりかなり少ないというのが常識だという。」
というような、多いか少ないか、どの程度かっていうおおまかな説明で十分なんだよ。
>>576 そこを今更突っ込まれてもな…
普段どんだけ不味いんだお前の飯って
> 高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
> 温度上昇で故障や異常停止することを危惧しているだけだし
要するに未だにわかってないってことですね。
何で省電力技術なのか俺は納得してるよ(省電力化を助ける技術といったほうがいいかな)
何かもうぼろぼろね
>>585 馴染みの無さそうな用語を更に略語で書かれてもちょっと(LSDは判るが)
ただ、アウトオブオーダは命令貯めておかないと出来ないし
スレッド間のデコード振り分けも2コアの命令の貯まりを見てするわけだもんな
>すぐ次のリソースに流していかなければならない
は厳密に言うとどうだろう
貯めてる部分で本当はパイプライン分けるべき?
WestmereよりMagny Coursのが「若干」省電力なのにまだ団子は噛み付いているようす
>>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・については出来たらいいなー程度の希望だから、出来ない理屈を力説したりバカにしなくていいよ
>>588 > 高温度でクロック下げるなんて機能、フェイルセーフ以外の何者でも無いだろって話じゃね?
> > 温度上昇で故障や異常停止することを危惧しているだけだし
>
> 要するに未だにわかってないってことですね。
>
> 何で省電力技術なのか俺は納得してるよ(省電力化を助ける技術といったほうがいいかな)
しつこいねお前もw
省電力でもフェイルセーフでもどっちでもいいんだよ、俺らは
マニクールなんか買うことも使うことも無いだろうからね
いろんなベンダーが納得して採用しているならそれでいいじゃんて話
常にアッチッチでcoolなspeedが効きまくり?
>>592 実行ユニット数に関係すんのは「最後のデコード」をする「スケジューラ」で
「デコーダ」自体は関係無さそうに思うけどな
俺も全然詳しくないけどウンコの発言はまずバグってるから
K7系デコーダはロング(中規模?)が3つでベクタ(大規模?)が1つ(らしい)
BullはCompが4つならロングもベクタも4つずつ
数の上では1コアで比べて丁度倍
間違えた
1コアと1モジュで比べて
>>590 すまん、RATはレジスタ・エイリアス・テーブル、ROBはリオーダ・バッファ、RSはリザベーション・ステーション
Intelは複雑なRAT機構を使って積極的に効果的なレジスタ・リネームしてるのに対して、
AMDのレジスタ・リネーミングは単純なRISC風リネーム機構の移植でROBのエントリ数も少ない
汎用レジスタが8個しかないx86ではIntelのやり方が正解なんだと思う
AMDはK7→K8でパックバッファを設けて空いてるパイプラインを充填しやすくしたんだけど、
Bulldozerでは空いてるパイプラインがなければ、別のスレッド(コア)に流せるようにして、
さらに充填率を高める設計にしてると思う
> Bulldozerでは空いてるパイプラインがなければ、別のスレッド(コア)に流せるようにして、
それは現実的なコストでは無理
>>599 「別のコアに流せるようにして」は誤解を招く表現だった
「別のスレッドのデコードをして」のつもりで書いた
Bulldozerの実行ユニットは、コア間でバイパス機構がないらしいから必ずスレッドは別になる
そういう理念で設計したならバックエンドも統合してSMTにした方が合理的なんだが
>>601 Andy Glewの弁では一つの小容量L1D$を2スレッドが取り合うことによる性能低下が大きいらしい
まぁ、IntelもSMT時にはROBを分けて使ってるから、バックエンドもある程度分かれているわけだが
IntelがROBを猛烈に強化しているのは、x86-64で汎用レジスタが増えた上にSMT時にはROBが半分になって
レジスタ・リード・ストールが発生する可能性が高まるからだと俺は思ってる
たぶん、Sandy BridgeでもROBエントリ数は増やしてくるぜ
>>591 > WestmereよりMagny Coursのが「若干」省電力なのに
Atomのほうが「圧倒的に」省電力ですよ。
何を売りにしたいの?
「シングルスレッド性能で妥協しない」ために
ベクタ共有デコーダ共有で使えるリソース増やしてるけど
基本的にはベクタ犠牲でマルチスレッドでの整数スカラ性能重視だもんねえ
スケジューラの肥大が実行ユニットの2乗に比例するんなら
ALU2*2で省スペース簡略化も理に適う
「それにALUなんざ2つで充分」と言うからには
キャッシュ系能力でIntelに劣るとしても
バッファ充実等で実行パイプ充填に力を入れると思うけどね
>602
>601は「暇になったら他スレッドデコードもやる程度」な件を言ってんでしょ
>>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倍の空間をサポートしないといけなくなる。
○Renamer
>>604 暇になったらも何も、デコーダを2スレッドで共有してる時点でリソースの競合になることに変わりはない
>>602 > Andy Glewの弁では一つの小容量L1D$を2スレッドが取り合うことによる性能低下が大きいらしい
> まぁ、IntelもSMT時にはROBを分けて使ってるから、バックエンドもある程度分かれているわけだが
まあその小容量L1DってのはNetBurstの8KB〜16KBのことであって
間違っても32KB共有より16KB×2のほうが性能が高いと言ってるわけじゃないけどな
nanoはcomplex decoder x3なんだね
>>607 「デコーダ暇」な状況では競合にはならない
スケジューラ辺りで実行命令貯め過ぎたら
それ以上デコードしても際限無く抱え込めないだろうし
涅槃のLSDループ専用トレースキャッシュも
デコーダを休ませて消費電力下げるためのものでもあるはずだし
とにかく暇な状況は出来る
暇なら競合にならない
余裕出来ることがまず無いのはキャッシュくらいか
>>610 いやだから、共有してる時点で暇だろうがそうじゃなかろうが
2スレッド分の命令ストリームをデコードしなきゃならんのだが
>>609 それでシングルコアなのに大飯喰らいなんだな
Nano L2100 1.8GHz
1MB L2
TDP 25W
65nmプロセス
Core 2 Duo L7700 1.80 GHz
4MB L2
TDP 17W
65nmプロセス
NanoってSOIもHKMGも使ってないんじゃないの
>>605 > これはRenamerの話でDecoderの話ではない。
> IntelプロセッサではRenamerはDecoderのすぐ後のステージだ。
> RenamarはDecoderではない。
> 何度も釘を刺してるのに↓こんな勘違いを平然とやってのける。
俺は別にプロでも専門家でも無い一自作erだから用語の意味なんかよく勘違いもするよ
Renamerのコストが減る事はわかった
で、デコーダーはどうなの?って話だ
増える、減る、少し、かなり、分からないとかの分かりやすい言葉で説明してくれ
ああ、後から嘘ついたとか、デコーダーの話じゃないってのは勘弁な
> 本当に馬鹿だな
質問に答えないであさっての話をするお前も馬鹿だけどな
> あ、ついでに言うとSSSE3, SSE4, AVXのデコードロジックをハードワイヤードで積めば
> K10に比べると1デコーダ当たりの規模は格段にでかくなるのは明らかだけどな。
> OpcodeマップだけでもSSE3までの約2倍の空間をサポートしないといけなくなる。
Bulldozerがハードワイヤードって話なんか聞いた事ないけど
>>609 Bulldozerはスレッド辺りComplex DecoderはX2かな
まあ、65nm時点ではCore 2もHKMGは使ってないけどな
> Bulldozerがハードワイヤードって話なんか聞いた事ないけど
あーこれは駄目だ話にならねえ
未だに「スレッド当たり」とか言ってる時点でウケるwwww
>>545-546当たりの解説が全然頭に入ってないのね
自分で撒いた種に
>>616 こらこら、人をののしるレスはやめたほうがいいぞ
ここは自作板なんだから、俺みたいにCPUの内部構造に疎い連中が集まるところだ
>>611 さっきから>601とどう繋がってるのか判らんのだけど
とりあえず、バッファとやらに命令の貯蓄があるうちは
急いでそのスレッドのデコードをする必要は無い
そういう余裕が多いほうを置いといて少ないほうのスレッドで働く
これはデコード能力を取り合ってはいない
スレッドにはCPU全然使わないものもあって
そういう状況がまさに>「暇になったら他スレッドデコードもやる程度」
競合になる瞬間が全く無いわけではないけど・・・
てか元々そういう話が発端じゃなかったっけか?
ハードワイヤードロジック化されたデコーダってのはデコードにマイクロコードを用いないってことだよ
すなわちSimple Decoder(AMDでいうDirectPath)のこと。
>>620の補足
要するに>601は
「競合がちょっとしか起きない状況ならSMTのほうが無駄が無い」
と言ってるのかと思ったんだが
雑音テヘ団子はそんなにインテルが大好きならインテル次世代スレに行けよ
>>621 ああ、すまんすまん、SIMDのデコーダーのことね。
256bitで新命令だから肥大化して邪魔ってことで2コア共有だし、端から勝負になるとは思ってない
SSSE3や4も含めて互換性確保のために採用するだけだろうから期待もしてないしどうでもいいよ。
Bulldozerの構造をまとめると
デコーダーは4命令対応一個を共有
スケジューラーやpipelineとかは2命令実行
(付随するいろんな機能もK10世代からは削られてるだろう)
AVXは2コア共有
SSEはSSSE3/4に対応
整数周りは結構小さくなってそうで、
SIMD周りがどの程度肥大化してるかってところだな
将来AVXが普及しまくったら、共有じゃなくコア単位で持つようになるとは思うけど、
とりあえず普及するか分からない現状で共有って路線は正解だと思う
>>625 > (付随するいろんな機能もK10世代からは削られてるだろう)
突っ込まれる前に訂正しとこう
機能自体の削減じゃなく、機能の性能や規模のことです
いつまでテヘ団子にマジレス続けるの?もうやめろよw
整数演算機を使わずにSIMDユニットだけを動かし続ける処理って殆ど無いんじゃないの
整数演算器が共有されていないなら、SIMDユニットを共有したところで大して性能落ちないんじゃない
ついでに言うとスレミスってね?
おはようアフォ共
> ああ、すまんすまん、SIMDのデコーダーのことね。
> 256bitで新命令だから肥大化して邪魔ってことで2コア共有だし、端から勝負になるとは思ってない
SIMDだろうが整数だろうがデコーダは同じだが。
バックエンドのハードウェアだけじゃなくてデコードロジックの負担も考慮しなければならない。
速いか遅いかは別にしてSSSE3/SSE4やAVXを実行出来るキャパがあれば、デコーダは命令を
デコードできないといけないし、そのロジックを積んでる分だけデコーダは肥大化するんだよ。
スレッド毎に分かれてるか共有してるかはデコーダを通した後の話。
単純にSandy Bridgeと比較してもXOP等のサポート分だけデコーダは巨大になる。
> SSSE3や4も含めて互換性確保のために採用するだけだろうから期待もしてないしどうでもいいよ。
期待どころかものすごい地雷だな。段階的に追加した物じゃなくてウン百命令を一気に追加するわけだから
潜在的な不具合は計り知れない。
おまいがどうでも良くてもAMDにとっては重大な問題だな。
>>628 パイプ複数本やアウトオブオーダのバッファ(?)はデータロード待ち中の命令を増やすためにある
それらを共有すればどちらも競合することになるってのが理屈
>SIMDユニットだけを動かし続ける処理
ってのは無くてもSIMDユニットを高頻度で動かす(しそうな)マルチメディア系処理で
SIMDユニットの総数が大きく減るのは性能の大きな低下になるんではないか
まあこの辺はちゃんとしたソースでも無いとな
ひとりでよくもまぁダラダラと自問自答と言うか自己批判ができるな。
試しに○串報告してみるか
串なんて刺してないんだ。残念でしたww
節穴したら大阪のsonetだったりocnだったりしそうだけどなw
>>628 > 整数演算機を使わずにSIMDユニットだけを動かし続ける処理って殆ど無いんじゃないの
勿論ないよ。
アドレスを計算しなきゃいけないからイテレーション毎に汎用レジスタの値の加算・減算程度には
整数演算は必要になるね。
> 整数演算器が共有されていないなら、SIMDユニットを共有したところで大して性能落ちないんじゃない
2基しかないSIMDユニットでリソース競合がおきても、整数ユニットでは何も解決できないんだわ。
>Core 2 Duo L7700 1.80 GHz
>4MB L2
>TDP 17W
>65nmプロセス
なにこの超選別品
>>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)
>>637 「GeForeceはSIMDユニットだらけでスカラなんて無いがx86ならSSEを途中でスカラに分解出来る」
なんて思えるのはウンコ100%バーベキューのお前だけ
>628は単に「どんな処理でも整数演算率がベクタ演算比率を下回ることは無い」みたいなこと言ってるだけだろ
> 「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みてみ?
>>637 競合したときは諦めるしかないけど、SIMDユニットの使用頻度が低い頻度も小さいんじゃなないのってことね
単純に考えると、SIMDユニット使用頻度が1/nならSIMDユニット競合の頻度は(1/n^2)×n=1/n
あと、ユニットに流し込むタイミングはあるていど調整できるんじゃないのかな
>>641 だからデータ並列=タスク並列なお前だけの説だと言っている
「たまにPentium 4にはL1Dが無い」って信じてるのもお前だけ
>>641 俺は団子の言ってることは間違ってないと思うし、非常に適切なコード例を出してきたと思う
だがこのコードで命令数を数えてみると、整数ユニット側に行く命令が1割越えてる気がするぞ
CPUなんかにバグなんてあるわけないだろ
プログラムが仕込まれているわけでもあるまいし
シングルなのに大飯喰らいだな
celeron 420 tdp:35w
>>632 > 期待どころかものすごい地雷だな。段階的に追加した物じゃなくてウン百命令を一気に追加するわけだから
> 潜在的な不具合は計り知れない。
> おまいがどうでも良くてもAMDにとっては重大な問題だな。
何を今更なことを言ってるんだ
SSE/2/3拡張の度に数十〜100近い追加をしてきているし、AVXにしても数年かけて対応しているから、
大きな不具合が出るほど拙い実装なんかしないだろ。
そもそもBulldozerはサーバーやHPC向けに開発していて、ベンダーの新機能に対するチェックも厳しいだろうし、
致命的な不具合を抱えたまま市場に投入するくらいなら発表を延期する方を選ぶだろ。
PhenomのTLBエラッタ騒ぎから学んでその辺は慎重に対応すると思うぞ。
>>644 ベクトル命令数が整数命令数が超えるかどうかの議論で、
1割を下回るという意見に、1割は超えるなんて言っても結局超えていないわけだからあまり意味は無いのでは。
HPCは狙ってんのかなあ
Bull単体での構成では大して重要じゃないとして捨てられてる気がする
そこらへんはAPUでカバーするべき分野だと思うし
GPUにも計算させるゆうてはるもんな
すでにあの大国がやっちゃったけど
今までの半導体のパターンでいえば、Bulldozerは死産じゃないかなあ、と思っている。
AMD自身も第三者も誰もモジュール構成のメリットを明快に説明できていない、というのが根拠。
黙っててもIntelがAVXアプリを作らせるだろうし、それが動かないのは何かと宜しく無いだろう
優先度は別にして、将来的にはAVXもGPGPUもOpenGLもDirectXも、何でも対応するのがAMDのスタンス
モジュール単位で構成するのはもうどうこういういうレベルの話じゃないと思うんだが
SandyにしてもLlanoにしてもモジュール構造だしな
Bulldozerでモジュール内の単位が変わったということに関してなら
150%のダイサイズで190%の性能ということで明快だと思うが
>>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割も向上すれば何処も文句言わないし採用も増えると思うがね。
>>652 > 150%のダイサイズで190%の性能ということで明快だと思うが
そういえばそんなことも言ってたね
シュリンクでダイサイズが6割程度になる事も考慮すると、
ダイサイズは現状より多少小さくなって、性能は約倍ってことになるね。
(150%*0.6倍=0.9倍で少し縮小、190%は倍と言っていいだろう)
単純に考えると、45nm 4コア 250mm2→32nm 8コア 230mm2(0.9倍)になるな
アンコア部がどうなるか未知数だけど、Denebと面積比は同じ位だろうってことで計算
>>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の構造自体が変わる。
フリーライドはいつものAMDの戦略なんだから
本格的に普及するまでは嗚呼ついてますね、程度でもいいんじゃないの?
性能で残念なことは否めないけどさ
信者脳的には新命令初期において、最適化カッコ悪い!的な煽りの方便ともなる
>>652 >150%のダイサイズで190%の性能ということで明快だと思うが
それを達成するために、なぜ2コアを1モジュールにするアプローチをとったのかが
明確でない。
・デコーダ共有で並列実行部分のランダム性が性能に悪い影響を与えるのを緩和
・SSEユニット減らしつつも共有化でシングルスレッド時の並列度維持
この辺は何度繰り返して話題にすればいいんだ?
>>657 根本的に考え方が違う
2コアを1モジュールに押し込んだのではなく
1モジュールで2スレッド実行可能にしたのがBulldozerだ
考え方的にはハイパースレッディングの延長線上にある
定義はそれぞれ色々あるだろうけども
HTT
考えなしに並列化しまくって案の定余ったリソースを有効利用するための機能
Bull
1コアに更に整数実行パイプ部分のみを1セット追加して
マルチスレッド時の整数スカラ性能を最優先
対抗ではあるけど線は別だと思う
>>660 リソースを一部共有して複数スレッドを走らせる技術として延長線上という表現を使いました
完全に定義付けの差っすね
>>658 >・デコーダ共有で並列実行部分のランダム性が性能に悪い影響を与えるのを緩和
そこは共有して嬉しいところじゃない、という話題も何度も繰り返されているよね。
FPUは使用頻度にムラがあるから共有する意味があるが、
デコーダは(大容量トレースキャッシュでも積まない限りは)常にビジーで、
かつn倍のスループットを得るのにn^2倍のトランジスタを消費してしまう。
整数パイプラインをコア間で共有して効率を上げるならばその前段も共有する
のは至極道理だが、パイプラインは分離だという。わけがわからない。
まあ、俺がわからないのはいいんだ。
AMD Fanboy以外でここのロジックを明快に説明できる人間が未だに誰もいないのを
問題にしている。見たことあるなら教えて欲しい。
ベクターユニット共有によるロスを最小化するため、かなぁ?
ある構造でデコーダの能力と演算ユニットの能力が吊り合っているとして
そこでデコーダを10倍にしてなおかつデコーダが常に動いているとすると
デコーダは既にデコードした命令を何度も何度も繰り返しデコードしてることになる
そんな馬鹿なことはた例えIntelでも99%やらない
というか後藤も「キューが貯まってないほうの実行パイプ(スケジューラ?)にデコードを振り分ける」と言っているし
>という話題も何度も繰り返されている
なんて大阪秋葉原の押入れくらいでしか見たことが無い
>>663 ダイサイズを縮小したい
SIMDユニットは利用頻度が低いから減らしたい
2つのコアで共有させよう
ついでに他の共有できる部分も共有させよう
つう事で非常に分り易いと思うんだが
SIMDの使用頻度が低くて
ダイを小さくしたいなら
Fusionなんて辞めれば良いのに
Fusion前提だからこそ既存FPUの役割を減らしていく方向
>Fusion前提だからこそ既存FPUの役割を減らしていく方向
(笑)
AMDの狙いは、互換性維持のためSSEやAVXには対応するけど性能競争する気はない、
メインは整数クラスタ(モジュール化)とシェーダークラスタ(MIMD?)の組合せで業界の覇権を狙う、だろ
そんな独自規格
だれが使うの
GPUすら忘れたホモ
>>673 AVXは独自規格とはいえIntelが大プッシュするから結構使われるよ
互換性のない
shader clusterとやらの方だよ
AVX載ってないとキツイと言われるようになるのは何年後ぐらいだろうか……
何か前にもあったな
広告担当の誰かがてきとうに作って
OpteronとIstanbulが同列に扱われたりなどしてるそれを見てホモが真剣に語ってる図というのが
今回はK10@6コアとK10@6コア*2でintとfroatの割合が違ってるが
「Opteron&Istanbul」は無くなってるな
>>676 > 互換性のない
> shader clusterとやらの方だよ
互換性無いwww
何との何の互換性が無いんだよwww
だれが、どうやって使うんだ
そんなマイナー独自規格を
Intelとの互換もなしに
ところでOpenCLってベンチ以外で
何に使われてるんだ?
ヘテロジニアスは規定路線です。
IntelとAMDはいまさらやめられませ〜ん。
VIAとNVはどうなるんでしょうか、知りたくもありませんが。
>>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
ここだけ実性能比なのかな?
>>681 お前の頭の悪さにはびっくりだww
シェーダーがバイナリやらソースを直接実行するわけじゃない
APIにはドライバで対応するから、ベンダーはCPUの中身なんか気にしないで
DXやOGL、OCL、C++とか好きな言語で開発すればいいんだよ。
最適化したけりゃすればいいだけで、その時はAMDが手厚くサポートしてくれる
>>685 >その時はAMDが手厚くサポートしてくれる
はたして・・・
AMDが手厚くサポートしてくれるってどんだけお花畑なんだよ
OpenCLは各デバイスごとのバイナリを実行する仕様だし、
中身CPU以上に違うGPUの違いを無視してコード書いても性能なんかでないだろう。
何の言語使うにしろ、ターゲットとするGPUごとに最適化することは必須じゃないの?
GPUごとに最適化なんて面倒くさいことしているうちは普及なんかしないと思う
.NETあたりが鍵になるんじゃないかな
>>670 Andy Glewもdresdenboyも、デコーダ共有の得失については特に深くは言及してないんじゃないか。
デコーダ共有に、FPU共有のしやすさとかのメリットはあるにしても、
3命令同時発行というx86のベストプラクティスを捨てるほどの価値はあるのか、
あるいは、平均2命令でいいなら、4命令同時発行×1より2命令同時発行×2の方がシンプルで省トランジスタ・省電力なんじゃないか。
三命令発行がトランジスタ効率的にベストじゃないと判断しただけだと思うが
トランジスタ効率にフォーカスするなら2命令発行×2の独立デコーダがベストだろう。
4命令発行は難しい処理(=電力とトランジスタを喰う)で、
かつ平均すると2命令に落ちるという、誰が得するのかわからないアプローチだ。
ピークがどちらかのコアに偏るなら意味があるが、デコーダはそういう性質は薄いし、
後段(スケジューラ)でキューイングするということは、偏りはならされて平均化されるということだ。
そっちの方が効率が良いというシミュレート結果が出たんだろ
物が出てから判断するしかねえだろうがそこらへんは
3命令デコーダx2だとL1Iも2倍いるんじゃないの?
あるいはマルチポート化とか
デコーダ話のループストリームに加えて
Core2の4命令にまで妄想持ち込む奴まで出て来るとはな
>685
API経由のくそ遅いものを
だれが好き好んで使うんだ
ところでAMDのSSE4aは
何で使われているのか
LlanoとOntarioのサンプルが出荷されてるらしいけど
OntarioのCPU部分はBulldozerの1/2モジュールなの?
ふと思ったのだがWindows2000ProだとBulldozerのFPUは一つしか使えないのだろうか。
……どうでもいいな。
>>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倍だから、
利用タイミングさえ重複しなければコア当たりの性能を引き上げることはできる。
ちなみに
> Deneb(10) vs Istanbul(17)
> は最高クロック同士だとありえない結果だし
2008年最高性能のOpteronは 2386 SE(Barcelona 2.8GHz×4)
2009年は Istanbul 2.9GHz×6
ということで整数は概ねクロック×コア数なみ。
×2009年は Istanbul 2.9GHz×6
○2009年は2439 SE 2.8GHz×6(Istanbul)
アウトオブオーダ=スーパースカラ(>541)なせいで
以前Opteron(ブランド)とIstanbul(コード)の名が一緒に並んでたような
いい加減な広告に人生を賭けるショタホモ55歳(推定)
アウトオブオーダといえば
アーキテクチャスレのMADオタコピペで「FPスケジューラはアウトオブオーダではない」とあったけどほんとかね?
それなら共有化すれば単なるインオーダからSMTが付いたAtomみたいになるからいいんだが
それはBullのFPだけのことなのか
「モジュールはクラスタで皆ひっくり返して呼んでてうんちゃらかんちゃら」とよく解らないことを言ってる奴の発言だから放っといたほうがいいのか
どうなんだろ
■後藤弘茂の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も出る前とあって、時期が早すぎ封印されていると推定される。
だからどうしたとしか言いようがない
それならまだLarrabeeについて言及している部分の方が面白いと思うが
次々世代のHaswellを封印するIntelと
次世代のBulldozerの音沙汰がないAMD
少なくとも、当初言われていたOrochiの今年後半の生産開始はないな。
>>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で回るとしたらそれはそれでクロック当たりのスループットは低いですよ
ってことになるわけで、それ以上の要素は無いと思うけどな。
IntelでもオレゴンチームはぱっとしないからHaswellもどうなることやら。
まだオレゴンがどうとか言ってる奴いるんだw
ぱっとしないチームが作ったNehalemに無残にも市場を奪われたOpteronって何なの?
本当に団子はintelを愛しているんだな。
Haswellにもオレゴンが加わるのかよ...
ノートPCでも雑音の法則発動かよ
オレゴンチームは市場を奪ったんじゃない!雑音の知能を奪ったんだ!
反論のつもりでズレた事を言うから楽しい
そんなのでHaswellへの不安が消えるかいな
サンタクララチームって今後もItanium保守チームであり続けるんだろうか
Nehalem-EXはサンタクララが作ったけど、Westmere-EXはバンガロールらしいし、
RAS機能強化するときに出張ってくるくらいなのだろうか。
>>718 アンタが不安なだけにしか見えんが。
失敗時のリスクヘッジのためのTick-Tockモデルなわけで、
* Bridgeの続投ではなくマイクロアーキテクチャの刷新というロードマップに変更がないだけで
十分といっていいんじゃないの?
FMA命令の追加で更に1コアあたりのFPの理論スループットをSandy Bridgeの更に2倍にすることが
できると言われているが、その計画に変更がないだけでも御の字。
むしろ2008年時点で先の方まで情報を出しちゃったから、それ以上の期待もしようがない。
むしろAMDの心配してやれよ
対Haswellって意味ではBulldozerの次世代(22nm? 25nm?)のほうが不安要素多くないか?
各FMAを256ビット化すれば性能的にもHaswellに追従可能だが、
あるいはGPUのシェーダクラスタとの共用化をすすめてくるかね?
x86ベクタの強化でGPUの1/100から2/100に!!!
723 :
Socket774:2010/05/13(木) 18:40:07 ID:Ojsonk68
第二世代Fusionは2015年らしい
LinpackあたりならSandy Bridge 6コアで実効140GFLOPS(倍精度)程度は出せるよ
> x86ベクタの強化でGPUの1/100から2/100に!!!
へえ70TFLOPSも出せるんだGPUは
>>724 |ω・)コソーリ計算を修正w 140GFLOPS / (2/100) = 7TFLOPS
いいや、実用性のない方のGPUは0.2掛けくらいが妥当だからこれでおk
radeonはいつでも公称値勝負
NVIDIAのサイトで確認すると,確かにシェーダクロックは1.15GHzになっており,
倍精度浮動小数点演算のピーク性能は515GFlopsになっています。
Intelの8コアのX7560は72.5GFlopsで130Wですから,
まだ,ピークFlops/Wでは4倍程度のアドバンテージがあるのですが,
今年末に出るとみられているSandy BridgeではサイクルあたりのFlopsを
倍増すると考えられるのでかなり差が縮まり厳しいところです
掛け算も出来ないっつーか
12<16は覚えたのかホモ
>>729 CPUがGPUの1/100とか2/100ってのはどこから来たんだ?
>>730 CPUは最適化一切無し1スレッド
GPU(CUDA)は何ヶ月も出してカリカリにチューン
大学から出てくるレポートなんてそんなんばっかしだよ
それすらRadeonなんて無縁だけどな
1+1は2じゃない 200だ! 10倍だぞ10倍!
ん?某GPUは倍精度(理論値)は単精度(理論値)の0.2掛けじゃなかったのか?
なんでテヘは他人に成りすましてまでファビョっているの?
大好きなIntelが性能でAMDにたまたま負けたのがそんなに悔しいのw
くやしいおおお
くやしいおおおおおおぉぉぉぉ
わかったからさっさとクソして寝ろ
>>731 GPUのコア(と呼ぶベンダーもいる、CPUの演算器に相当)とCPUのコアの数を比較して
100倍速いとか書いてる糞記事が出てきたんだが
>>733 tp://beye2.com/item_7464.html
もうとっくに訂正されてる
これは言い間違いってやつだろうし
書いて間違うのとレベルが違うっていうか
やっぱり12<16すらまだ解らないホモは知能0なんだよな
>>736 なんでテヘの話題にダンゴが喰い付くんだw
>>737 貧乏研究室は科研費おりなくてNVIDIAから寄付金もらわないとやってけない、と思ったら涙が出てくるよ。
計算機科学の公証性を歪めるクソ研なんざ消えて良し。レンホーの鉄槌希望。
>>739 少なからず同一認定する頭の悪い子が複数いるからだよ
ホモ呼ばわりされてしもた
>>742 ホモは雑音の事
12<16の件は>420関連を読めば判る
「いくら肉体労働者だからってプロレスラー(人間)と雑音(知能の無い何か)を一緒にするなよ」
って言いたかっただけ
>>713 > ぱっとしないチームが作ったNehalemに無残にも市場を奪われたOpteronって何なの?
Intel最強のイスラエルの傑作であるCore2にメモコンやL3を足したのがNehalemだからな、
余程のボンクラじゃない限り優秀なコアになるのは確定していたよ。
まあいずれにしても
Broadcast+乗算+加算+αが1サイクルに同時発行出来る前提で設計されたFLOPS数と
常に全部の命令スロットを積和算に割り振らないと発揮できない常識的にあり得ない利用シーンでのFLOPS数を単純比較しても
全く意味がないんだけどな
今日の団子は生きがいいな。何か良い事でもあったのか。
>>744 元はPentium Proだろ
それはともかく
その優秀なイスラエルチームが4年ぶりのメジャーアップデートとして放つSandy BridgeのFPUを
更にFMAに替えた物がHaswellだよ。
余程のボンクラじゃない限り優秀なコアになるのは確定じゃないの?
GPUにやらせたほうがクソ速いときはGPUに
CPUにやらせry
てのがヘテロの行き着く先
データ並列度が高い処理のスループットが高いだけで速いわけじゃない
車に喩えるなら
スポーツカーのトランク小さいトランクよりも4トントラックの方が多くの荷物を運べるけど
そもそも荷物はこぶのだけが車の役割じゃないっていう感じね
25.75倍て
flops差以上の差、いやこえられない壁だな・・・
PPU(58gflops)=9600GT(208gflops)とか
x4 955(102.4gflops) > HD4870(1200gflops)とか
あてにならんちや
>にもかかわらずAVX LNIと自滅の道を歩んでいるIntel
だったらAVX対応なんてしないでSSE5でよかったのに(棒)
いや、エンドユーザー側からすればまったく実用性がないしw
たとえばAESみたいなブロック暗号ならECBならクラック(笑)と同じ原理でブロック数分だけ並列化可能だけど
一般的にはCBCやCFBで使うことが多いから並列化できない。
>>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の継続以外ないだろ?
平文のある16バイトと別の16バイトの平文のビットパターンが同じ場合、暗号文も同じ箇所が同じビットパターンになるのがECB。
それこそクラック(笑)に弱くなるので誰も使わない。
> 一度大失敗して引っ込めたプランの焼き直し、
> しかも原因がハードではなくソフト環境の出来の悪さが酷かったなのによくそんな自信あり気に話せるな。
??????
Larrabeeのことなら全くの見当違いだぞ
メインコアはSandy Bridgeの拡張でベクタ長は256ビットに留め
GPUコアすらLarrabeeベース出はなくGMAの焼き直しと言われてるくらいだ。
>>734 0,2倍だけど540Gあるよ、しかも190W(HD5870)。
72.5G/130WのX7560の約5倍になる。
効率半分になっても2倍以上の性能差だな。
コスト差も考えるとすごいことになるぞ。
> なにせAVX失敗したら終わりだもんね。代替プランはSSEの継続以外ないだろ?
MSが全面支持、AMDがSSE5をキャンセルしてAVXに追従の時点で
代替がどうとか馬鹿もたいがいに
>>757 中国のスパコンのあれ、4870X2だけども
その半分すら動いてない計算になるぞ。
760 :
♪:2010/05/13(木) 21:40:25 ID:HW4mbN3y
>>757 馬鹿だな。
専用設計で2倍とか負けたも同然。10〜100倍が目安。
RISCなんて汎用でx86の数倍早い時期が10年前後もつづいたがそれでも負けたんだぞ。
ここでスパコン持ち出すかw
まさかHaswellがLarrabeeベースになると思ってるのかwww
後藤ですら何ヶ月も前に訂正してるのにww
しかもRockwellのGPUコアにすらLarrabee載らないなんて噂まで3月には浮上してるんだが
万能ツールとよばれるものが
万能だった例が無い
by 飯倉清
764 :
♪:2010/05/13(木) 21:48:54 ID:HW4mbN3y
GPGPU = 専用→器用貧乏
汎用 = システム、整数系アプリ向け
いわゆる「汎用機」が全然汎用じゃなかったりとかね
766 :
♪:2010/05/13(木) 21:49:52 ID:HW4mbN3y
汎用プロセッサの汎用とは
システム、整数系アプリ向け
ということである。
そういえば「FPスケジューラは全てインオーダなのか?」の話が終わってなかったんだけど
アウトオブオーダ=スーパースカラで隆盛(たかもり)くんの貞操狙ってる気持ち悪いショタホモのせいで
そんな雰囲気じゃ全くなくなってるな
12<16を覚えるまで押入れから出て来るなよ
768 :
♪:2010/05/13(木) 21:54:06 ID:HW4mbN3y
Bulldozerはモジュールなどとよばずにふつうに8コアとしてうっていればね。
Intelの8コアと比較してスループットにすぐれるとかいえたかもしれないのに。
>>762 後藤から仕入れた情報を然も自分の方が早かったように言う図
>>761 スパコンほどハードに最適化してくれる用途はないぞ
>>745 単精度については効率悪いの承知でVLIWにしているから仕方ない
倍精度に関しちゃSFU除いた4個を使っているから単精度ほど効率は悪くならないけどね
まあ、計算の種類に応じてSSE/AVXとシェーダーを使い分ければいいだけだな
>>747 その凄いというSandybridgeはwestmereと比べてどの程度性能が上がってるの?
シングルスレッド性能、クロックの上限が何割向上とかね。
そういえばLNI凄いらしいけど、AMDも対応しそうな気がするな、互換性維持のためにね。
AVXにも対応したから、LNIは非対応はないと思う。
更に規模が大きくなるから共有のままだろうけどね。
AMDがLNI対応したら団子はどうするのかな?泣くの?
LNI凄い 数の機能増やして
凄い 肥大化
Haswell=Nehalem改良コア+オンボロGPU+Larrabeeの512BitSIMDじゃなかったっけ?
コアやGPUとか現状と大して変わらんから全く無視していたよ
GPUがテープアウトしてから店頭で買うことができるまでの期間ってCPUのときよりも短いんだっけ?
Southern Islandsは今年中にはみられるのかな
>AVXにも対応したシェーダーを作るか
半端に使い物にならない汎用性で肥大化ですね
少なくともGMAベースの低性能IGP+AVXによるソフトウェアVertex Shaderで性能補完という基本路線は
数世代にわたって継続する予定だから安心しろ。
LNI・・・IntelがAMDにライセンスしてるかどうかも不明だな。
あれはLarrabee専用のOSとセットのモノだから命令セットだけあっても無意味
いずれにせよAVXのフル256ビット化すらされてない段階で512ビットなんてのはない
DirectX+GPUにすぐ潰されそうなAVX&LNIなんてどうでもいいよ
知能0が気持ち悪いショタホモ自殺させて
Bullのパイプライン予想とかでも語りたいね
見事なララビ教徒だ
Rockwellですら統合されないのだとすると2015年か
>DirectX+GPU
DXCSはPSの第二passでしかない
>少なくともGMAベースの低性能IGP+AVXによるソフトウェアVertex Shaderで性能補完という基本路線は
VS以外もやってきそうな気もしないでもない
LNIはAVXみたいなプリフィックス長固定の命令セットになるが
AVXのエンコードスキームと似て非なるモノで
現時点ではAVX2とかAVX3とかの拡張計画の延長線にない
別物
Itanium互換プロセッサをAMDが作らないのと同じレベルで
Intel専用命令セットになる可能性あるよ
GeForceとRADEONに最適化はわかるがGMAに最適化は誰もやりたがらなさそうだ
4gamerの記者も最後までよく頑張ったな
それで追いつかれてりゃ
世話ねぇっす
算数が出来ない奴(ID)と国語が出来ない奴の2本立て
誰か何とかしろ
>>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の流用ってだけだろうけど。
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だけ構成変なんですが
変でも性能出れば「天才!」って評価になるんだけど
性能どころかモノすら出て来ないララビ
早く押入れから顔を見せるんだ
>>786 未だに勘違いしてるようだけど
Larrabeeが普及するかどうかと、IntelがAMDにライセンスするかどうかは
まったくもって別問題なので切り離して考えて下さいwww
後藤は勘違いしてるがAVXとLNIは(HPC用途は別として)全く対象とするアプリケーションが違う。
WindowsやLinuxで動くコードでSSEや3DNow!を動かすのと同じレベルで考えても困るよ。
AVXだとかは今まで通りCPUの命令としてダイレクトにコーディングできるけど
Larrabeeのコードはホスト独立なIntel謹製の専用OSで動くんですよ。
OSのライセンスまでIntelから購入するの?
馬鹿なの?
AMDがItaniumを作らないのは
そもそもItaniumはAMDにライセンスしてないからなんですよ。
AMDがx86互換プロセッサを作れるのはIntelがライセンスしているからだってこと忘れないでくれ
実装に関わる基本特許をIntelが押さえてるからAMDはIntelと契約を結ばないと
製造することができない。
Larrabeeもx86基本特許とは別に、内部構成に関わる重要な部分の特許をもっていて
それを回避してLarrabee互換プロセッサを作るのは基本的に無理。
もちろん勝手に互換プロセッサ作ったりしたらAMDは100%敗訴です。
>ゲフォは8スカラユニットで1グループ
SIMDです(笑)
AMD以外はSIMDです
AMDがAVX入れたのは保険
そもそもx86なんて過去との互換性抜きにしたらゴミ同然なんですよ。
x86世に出た頃から笑われていたこと忘れないでくれ
まだ噂レベルだけどBullにCompデコーダ*4入れてるからもう充分
ベクタプロセッサにまでx86対応するなんて馬鹿馬鹿しくてできない。
Larrabeeもおそらく
押入れを回避して世に出すのは基本的に無理。
もちろん勝手に証拠書類改竄なんてしたら100%敗訴です。
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基
×内積ユニット
○積和ユニット
特許w
誰が大手ユーザーか考えたら意味が無いわ
>>793 まぁ。x86はそろそ別のセットへの移行を考えるべきだよなぁ…。
>>796 それ。i5だかi3とのオンボード比較もなかった?
>>798 無理に移行を進めてもIA64のドッペルゲンガーが増えるだけ
x86にというかC系言語におまけでくっ付いて来るDirectXのように
非x86のGPUがx86にくっ付いていればそれでいい
うん
画質も違いすぎるね
>>801 これレンダリング解像度からしてちがうな
意図的にぼかしてるのか?
右の方は画質落としてももっさもさしとるのう
そういう意味じゃねーw
AMDerが意図的にインテルのほうに細工してるだろこれw
え、右は設定落としてももっさりしてますベンチに騙されないでっていう動画じゃないの
youtubeの動画拾って
くっ付けただけ
セッティング等はいずれも不明
よほど暇なやつだな、こんなの作るの
ゲームしたけりゃGPUつけろってことを再認識させられる動画でしたまる
>>801 編厨ってこんなのでお互いだましあいして妄想がふくらんでるから
ありえない信者みたいなのが繁殖してるんだろうな。
マジレスすると左と右とでは画面キャプチャ〜動画エンコードに用いたソフトがちがうね。
右はモスキートノイズがつねにでているし、解像度もぼけている。動きの激しい部分ではブロックノイズ
が盛大にでてるね。色も変化している。
たとえばGPUでは差のでないフォントも含めてもやもやいたり。
こういうのにだまされる人はもう少し自分の認識に慎重になったほうがいいよ。
よかったじゃねーか、これでGMAに希望や幻想を抱くやつは居なくなった
まさに中二情弱がかもにされるネタだな。
GFショボ過ぎてつかえない
以上
>>788 > AVXだとかは今まで通りCPUの命令としてダイレクトにコーディングできるけど
> Larrabeeのコードはホスト独立なIntel謹製の専用OSで動くんですよ。
> OSのライセンスまでIntelから購入するの?
つまりWindowsやLinux、Unixじゃ動かないってことか?
そんなもん普及以前の問題だろ?誰が使うんだ?
GF自身のラインが既にキャパいっぱいか、
TSMCに頼んだ方が安くつくor高性能なものが作れる、ってことかね。
自前でいいものを安く作れる余裕があるなら、余所には頼まないよな。
>つまりWindowsやLinux、Unixじゃ動かないってことか?
>そんなもん普及以前の問題だろ?誰が使うんだ?
driver上のOSってこと
>ほとんどのGPUでは、ネイティブ命令セットへのコンパイルを初め、大半のソフトウェア処理をホストCPU側で行なう。
>それに対して、Larrabeeでは、Larrabee自体の上でマイクロOSが走っており、
>従来GPUならホストCPU上のドライバで行なっていたような処理を、Larrabee上で行なう。
AMDにとっては使ったことの無いGFの40nmより、
ラデで使い慣れたTSMCの40nmの方が開発しやすかったってだけだろう。
そもそも統合GPUがラデだからっ経験とノウハウがそのまま生かせるからリスクがかなり低い。
>>817 要はドライバーっていうかトランスメタのCMSみたいなもんか
ダメじゃん、ドライバ関連の失敗フラグ何度立てれば気が済むんだIntelは…
そもそもHaswellやRockwell登場予定の2014年辺りはWin8やDX12が登場していそうだが、
Intelがまともに対応出来るとは思えん。
多分やっとDX11ゲームが普及している頃だろうけど、Dx11対応ドライバ作れるのかね
OpenCLやOpenGLもだけど。
馬鹿だな
お前は
足し算掛け算まるで駄目
バグありコピペをやらせたら
世界一!世界二!世界三!
ざ・つ・おん
>>817, 819
ドライバに載る?違うな
メモリ空間の独立した自己完結したマシンが存在すると考えればいい。
いわゆる「ドライバ」はホスト-Larrabeeデバイス間を仲介するための最低限の機能のみで実装される。
データのやりとりは今研究されてるShared Virtual Memoryが使えるかもね。
まあ、古典的なMessage Passingが現時点では妥当だろうけどね。
メリットがわからんか?
ホスト独立のOSで動くアプリケーションってことは、ホストがLinuxでもMacでも同じ
コードが動くという当たり前の理屈だよ。
> つまりWindowsやLinux、Unixじゃ動かないってことか?
> そんなもん普及以前の問題だろ?誰が使うんだ?
違う、Intelにとって普及以前に【AMDに使わせる必要】がないだけだ
ホストOS側のコードはLarrabeeデバイスと通信するための最低限のコードを書くだけでいい。
ホストのAPI/ABIに左右されないという意味で圧倒的に楽な開発モデルだよ。
>>813 GFの40nmの生産ラインは多分まだ本格稼動して無いし(年内に稼動)、ラインも低消費電力向けのラインだよ
CPUやGPU用で使われるラインとは別
このラインは外部から受注したものの製造に充てられる
最強じゃんLarrabee
なんでそれが頓挫したんだ!世の中間違ってる
汎用性と消費電力は反比例だからな
馬鹿乙
だんご、だんご、だんご、だんご
だんご、大家族〜♪
屁ルミは汎用性をあげてるけどめちゃくちゃ電気食いでしょ
ドライバで仮想化するんなら
元のハードウェアがx86である必要が全くないと思うんだが
> ドライバで仮想化するんなら
逆だ、「ドライバ」という概念そのものが仮想化される。
ドライバ相当の処理の大半はデバイス上のMicroOS上で自分自身で処理される。
ホストはコマンドとデータを送るだけ。
> 元のハードウェアがx86である必要が全くないと思うんだが
それは、非x86のハードウェアで
# ./configure
# make
# make install
の3コマンドでPOSIXアプリのコードがビルド&動作できてはじめていうものだ。
最適化は後回しにしてもすぐに「動かす」ことに出来る即効性こそLarrabeeの強みだ。
Fermiの汎用性なんて所詮GT200に毛が生えたようなもんだし、Cell SPEの域にも達してない
5年後の話をしても仕方ない
押入れの話に比べれば未来の話くらい何でもない
組込でIntelが全部面倒見るならフルスペックのx86である必要は全く無いわな
まあLarrabeeはどうでもいいんだが……
5年後じゃなくて50年後なんだけどな
>>835 > 組込でIntelが全部面倒見るならフルスペックのx86である必要は全く無いわな
全部を面倒見る訳じゃないからP54Cベース+最低限の拡張なんだけどね。
・既にOSレベルのコード資産がある
・ハードウェアのIPライセンスを購入してくる必要がない
・ハード技術・ソフト技術ともにこなれている
まあ、これがIntelじゃなくてIBMならPPCベースになってたかもしれないね。
もちろんモダンな汎用x86としてフルスペックである必要はない。
高速に動く必要がない命令は動くけどマイクロコードデコードとか、SunのようにMicroOSがトラップして
処理するとかでも互換性は確保できる。
Larrabeeアプリケーションを動かす上で必須でないロジックは縮小・あるいは省いていい。
それでなくともたかだか非対称2-issueのパイプラインだからデコードロジックも大幅に簡略化できそうだね。
>>836 パラダイムシフトが50年起きなければな。
性能がどうとかドライバの成熟がどうとかってのはあくまで方便であって、必要なら出すだろうし
必要に迫られなければ永久に出さずに終わると思うよ。
Larrabeeは10年戦うんだよ
それにしても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個買ってくるのに自転車ならより速く往復できるかもしれないが、
大型トラックだとかえって時間がかかるかもしれないのと同じレベル。
魔法はどこにもないんだよ。
Larrabeeだって例外ではない。
その「用途が限定された大型トラック」が、
今までは(個数が出ないために)最新の半導体技術で作れず、
汎用のCPUには太刀打ちできなかったのに対し、
GPUの需要に便乗してCPUと同じ土俵で作れるようになった、
というところがミソなんでそ。
>言うことがまるで変わらない。
アウトオブオーダ≠スーパースカラ とか
フェッチ≠プリフェッチ とか
常にPentium4にはL1Dがある とか
確かにもう言うことが決まりきっている
>>839 > その意味Haswellの256ビットFMA×2とか
スレ違いの話題だが、これは確定事項なのか?
Intelなら非対称で256bit FMA + 256bit FP-Add
あたりにしてくるような気がするんだが
数は出てもごく一部の科学技術演算以外、ソフト屋の需要を喚起できてないのも味噌ね。
COBOLの職業プログラマ人口は世界300万人といわれてるが、CUDA人口はたったの約6万(NVIDIA調べ)だ。
SDKを試しにダウンロードしてみただけの人も含めた累計だろうから実質人口は推して知るべし。
AVX使えばDirt2を120FPSでプレイ可能!!
※グラフィックスカードを挿した場合
>>843 その類の(コテの)レスは間違い探しとかウォーリーを探せみたいなもので
情報を得るためのもんではない
×コテのレスは間違い探し
○コテのレスは見る価値無いのでコテをNG登録
>>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の実装がされるときには命令フェッチ帯域の拡張は確実に入るということ。
>>841 東工大の論文見てると
大型トラックの荷台に荷物(データ)を隙間無くキッチリ積める作業も
馬鹿にならないボトルネックで用途の限定のされ方が半端ないけどな。
CPUと同じ土俵ってのはどうだかな。
とりあえず、Intel版クルーソーがLarrabeeって理解でいいのかな
あっちは非x86コアでX86を動かすってコンセプトだったけど、
こっちはx86コアで非X86を動かすということになるのかな。
具体的に何を想定しているのかは不明だけど、DirectXやopenCL辺りをWinやLinuxを介さないで、
ホストOS上で実行しちゃおうってことか?
ホストOSによりLNIがユーザーからは直接見えないってことになるみたいだから、
確かにAMDがサポートする必要はないな。
そういえばホストOSは何をエミュレーションしているんだ?
x86なら、元がx86だからホストOSなんていらないし、LNIは隠れているから、x86とLNI以外なんだろうけど。
>>829 Fermiの場合は物理設計ミスだね
ぶっつけ本番で量産を始めてTMSCの問題に見事に引っかかってしまった
ATiは47**で一段階はさんでから5***の設計をしたからTMSCの罠を回避できた
nVidiaは後出しじゃんけんなんだからATiを見て設計しなおしを決めれば良かったのに
TMSCが悪いけどその対応で明暗が出たな
>>852 Nvidiaも一応GT21xで予習したんだけど、AMDみたいに難題のクリアに挑戦しなかったから失敗しただけ。
挑戦したけど出来なかったんだったっけ?
まあ、何が問題でどうすれば解決できるかはAMDが教えてくれたから今度は大丈夫だろう。
>>841 最近の3DゲームはHD解像度(1920x1200)でAAやAFとかの処理も加わって、膨大な量の計算が必要だろ。
例えるなら、大量の作業員が働く現場で、毎朝アンパン1万個配達してもらう必要がある状况で、
自転車で10〜20個ずつ持ってくるよりも、ダンプで1万個まとめて持ってきた方が早いし簡単だろうってことじゃないかな。
今後はは自転車の籠が大きくなって今までの倍以上持ってこれるようになるけど、
現場の規模も大きく(3D表示、マルチ画面)なってきていて、ダンプカーの搭載量や速度も良くなってきてるから、
相対的な差は依然として大きいままってところかと。
Larraeeのキャンセルについて
ttp://www.4gamer.net/games/049/G004963/20091212001/ 初代Larrabeeは,その消費電力や発熱量の多さに対して処理性能が十分とは言えず,
「演算処理性能でも一世代前のハイエンドグラフィックス製品に及ばない状態だった」
つまり 45nm Larrabee < 55nm GT200b や RV790
最大の問題は,グラフィックスカードとして市場投入するには,DirectXのサポートなど,
ソフトウェア環境の問題が山積していた点にあるとのこと。
とあるゲームデベロッパ関係者によれば,Larrabeeは,
DirectX 10への最適化すら,十分とはいえない状態だったようだ。
ホストOSの問題なのか、ドライバの問題なのか、あるいは両方の問題なのか。
リャノとサンデーはどっちが強いのよ
CPU・・・SandyBridge>>Llano
GPU・・・Llano>>SandyBridge
別途GPUを積むならSandy優位、積まないならLlano優位
CPUはキャッシュだらけだからIntel有利
GPUにはキャッシュ無いからIntelズタボロ
Larrabeeにもキャッシュあるけど構想自体がウンコ過ぎて挽回出来ない
アホ
>AAやAFとかの処理も加わって、膨大な量の計算が必要だろ。
単なる固定機能処理だろ
>ダンプカー
>自転車
ダンプカーは良いだろうが、自転車は不適当だな
なんせクロックは3-4倍あるわけだから
スポーツカーってところだろ200-300のパンとやらをつめる
>>859 問題は小回りの利きやすさだから別に走行時の速度は論じてない。
1/25.75スピードのCPUがスポーツカー
ちゃうちゃう、
>>853の単に大量輸送のお話に対して言ってるわけ
もっとも、最寄のコンビニにアンパン買いにいく例えにたいし
大量輸送を無理矢理持ち出してるは、どうなんだってお話
アンパン1個の話に喩えるならダンプカーが停めてある駐車場のほうがコンビニよりずっと遠い的なイメージかも
この独り言いつも気持ち悪過ぎ
ダンプカーやスポーツカーや自転車でパンを運ぶ例えは
どうやってもしっくりこないことが確定
CPU・・・自動車
GPU・・・新幹線
小回りのきくCPU
直線最速GPU
適材適所ということでここはひとつ
CPU部分がSandyでGPU部分がLlanoなCPUがほしいです
物量と機動力に訴えたLarrabeeは死んだ!何故か!
早産だっただけ
本番は2015年でしょ
その間は布教の期間
早産って今更DirectX(等の非x86)潰すの無理だろ
遅れれば遅れるほど腐敗が進む
>>868 LlanoはSSEも積んでるぞ
適材適所で使い分けろってことだ
べつにAVX(SSE)をGPUのShaderとして使ったほうが良いんじゃないですかね
それで性能が出せるんならな
オンボードとしては十分すぎるでしょ
絵描きはGPUに任せときゃーいいの
CPUがひましているなら、AVXをShaderとして使ってもいいだろうけど、
Intelと違って統合GPUの性能がそれなりにあるから、
性能が上がるかどうか微妙な気が。
Intelの場合はGPUドライバの出来が不安
発想を転換して、CPUにGPUの仕事をさせよう。
無理だった。
SSEを代わりに使うんじゃなく追加で使えばよくね?
480sp+SSEで性能3割増しとか
性能のアンバランスさと距離の違いをどうやって制御するのかは考えない
まあ、Carkdaleの場合でさえSSE代替は785Gを超えるかどうかの性能だから、
Llanoの場合に代替しても性能落ちるし、追加で使っても1割も伸びないだろうけどな。
>880
sandybridgeはそうなるだろ
GMA統合してるのにか
ワットパフォーマンスが悪化するだけだ
Llano待ちの奴はGPUやGPGPUにも期待してるが、
Sandy待ちの奴はGPUに期待はしてない、逆に邪魔者扱い
だれもGPGPUには期待していない
期待している人は多い
CUDAの為にゲフォ買ってる奴も多いからな
ただ、来年すぐに一般的なソフトで普及するとか無茶は言わないだけ
動画編集やウィルススキャン、科学技術計算など身近なところからスパコンレベルまで適用範囲はかなり広い
あくまで並列処理での範囲が広いだけで、シングル処理だらけの個人向けに限ればかなり限られてくるがな
streamが出たの何時だっけ
今無いものが、はたして・ね
今ないから今後もないとか頭悪すぎるだろ
数の大小が解らない奴の片割れだぞ
残念ながら今後も無いだろ
今でも使ってる人は使ってる
使う人は使うというだけの話
「全ての人が使うようになる」とか「使う人は皆無」と言った極論は無意味だ
何に使ってるの
スパコン
AVXもDX11もOpenCLもGLもLNIもどれも一般人には恩恵ないけど
>>888 AMD・nVidia・intelまったく関係ないが、GPGPUでウイルススキャンってCPU使用率減らす以外でなんかメリットあるのかな。
並列処理で高速化するかというとディスクアクセスがボトルネックになって早くならない気もする。
恩恵はある、気づいてないだけ
まあ、オフィスソフトやブラウザしか使わない場合は無いと言えるけどな
逆にクリエイティブな仕事をする人にはかなり恩恵ある
粗悪エンコードとか
>>899 サーバ用なんじゃないの
あるいは高速SSD前提か
>>899 はげどう。ストレージがネックになると思う。
>>900 今のオフィス向けPCは地味に高負荷だぜ?
セキュリティ向けのソフトが裏で複数動きまくってる。
>>890 で、AVIVOを呼び出すだけのソフト以外で何か実用レベルの物が出た?
まあ、それ以外のソフトも時間が経てば出てくるって言いたいんだけど、
煽り抜きで、それ作ってビジネスになると思う?なるとして何年後?
ま、市場が無いから人材が育たないのか、人材が育たないから市場が無いのか。
いずれにしても必要なら何らかの金銭的支援を行うべきだよ。
NVIDIAは大学に支援することで市場を替えようとしてるね。
シリコンバレーの名だたる大学発のベンチャーが革新をもたらしてきた。
他社の後追いしてればお零れに預かれるという発想がA社を駄目にしたと思う。
トリップ検索ソフトを自力で作ったフリをしてるだけの人は流石に言うことが違うな
そもそも金銭的に苦しくなった原因はどーれだ
1,Intelの他社排除的な商習慣
2,ヘクター・ルイズ
3,ダーク・マイヤー
K8以降まともな製品開発して来なかったからじゃないですかね
昨今はATIのGPUにだいぶ助けられてるようですが
NVIDIAはGPUとしての本分を捨ててでもGeForceの汎用化を進めてる。
超がつく巨大企業でもないかぎり、それだけのリスクを負わないとイノベーションは起こせない。
少なくとも保守的なアーキテクチャに留めて安全策をとるのは市場構造が変えようという姿勢ではないね。
てっぺんがあからさまな安全策をとって、どこのソフトウェアベンチャーがリスクをおかしてくれるのか。
主体性がないとしかいいようがない。
>>906 訴訟対象になってたIntelの商習慣が云々のときは単価10万オーバーのCPUをデスクトップ市場に投入して
絶好調だったじゃないですか。
本当に帳簿が赤くなったのは実力で押され出してからでしょう。
イノベーション()笑
市場構造の改革()笑
いくらなんでも踊らされすぎてる
誰が踊ってるって?
俺にいわせればNVIDIAの対応すら生温い
ソフトが出てくるのは「GPGPU=儲かる」の公式がソフト業界に浸透されたときだ
動くソフトを選ぶようなアーキテクチャ作ってる時点で自ら市場を狭めているわけだ。
まあ、本当にソフト屋に優しい何でも動くような汎用性をもったプロセッサ作ったところで
それこそ水膨れFLOPS数ぬきでx86やARMとガチ勝負しないといけなくなるだけだと思うけど。
Intelの商習慣が問題になったのはK7あたりの古い時代からの話でしょ
「訴訟を起こしたのは、K8が出て実力付いてきた今こそ
ゴネ得と言われずに済むから」
みたいな事をAMDの人が当時言ってた気がする
>>907 GPU以外全部ダメの間違いじゃないか?
CPU部門はSocket939時代以降どれもこれもパッっとしないんだよね
焼き直しの置き直しなんてしているからこんな事になる・・・
アホ過ぎる
自分で指摘した罠がララビにもあるのに
そもそもIntelにとってはGPGPUを邪魔できればいいので
Larrabeeの投入自体は本質ではないと思われ
同じx86ベースならXeonのほうが圧倒的に儲かるからな。
Intelの商習慣が問題になったのはK6からじゃなかったっけ
起訴で他社に嫌がらせ、リベートで他社排除
それらがあって今があるんだろ
>>907 まともじゃないX6にまともなi7が価格競争を強いられてるんだぜ
MIMD寄りになれば驚異そのものだからな
NIやFermi3のときもまた足を引っ張るわけか
あらら、イノベーションは何処へやら
次のMSのゲーム機に採用される奴が勝つ。 Windowsでは。
>>919 本音を言うとそもそもGPGPUがソフト市場で成功するとは全く思っていないのよ。
いってしまえばNVIDIAのやってることは無駄な足掻きにすぎん。
ちなみにIntelはLarrabeeを投入する理由をGPGPUを牽制するためと初っぱなから公言してるからな。
潰すべきGPGPUソフト市場が存在してない段階で投入する意味はないわな。
もう32コアCellの計画も存在しないし、トップ500に占めるXeonのシェアはどんどん上がっていく。
>>908 > NVIDIAはGPUとしての本分を捨ててでもGeForceの汎用化を進めてる。
> 超がつく巨大企業でもないかぎり、それだけのリスクを負わないとイノベーションは起こせない。
>
> 少なくとも保守的なアーキテクチャに留めて安全策をとるのは市場構造が変えようという姿勢ではないね。
> てっぺんがあからさまな安全策をとって、どこのソフトウェアベンチャーがリスクをおかしてくれるのか。
> 主体性がないとしかいいようがない。
どんなに汎用化を進めてもGeforceは所詮は外付けのアクセラレーターでしか無い
CPU自体にそれなりの能力があれば必要性はかなり減る
誰もが高性能なGPGPUを高い金出して買うわけじゃない、そんなのは極少数
廉価CPUにそれなりのGPGPUがついてきたら殆どの人はそれで満足数だろうな
来年は出始めだからシェアはたいしたことないけど、再来年以降はほぼすべての新規ノートPCはFusion CPUになる。
デスクトップだって流用されるからそれなりの数になる。
AMD CPUのシェアが20%のままでも、全世界で数千万台の規模になり、GPUも含めると1億台に近くなる。
その全てでDX11、OpenCLに対応出来るわけだから、イノベーションを起こすには十分だろ。
なんだか暗にAMDの路線を肯定してるがな
今日は絶不調だな
Larrabeeが統合されないという可能性もあるわけか
日本国内PCメーカーの夏モデル見ただけでもIntel一色だけどな
AMDって信用無いんだなと思ったわ。
ゲーム機と携帯の区別まで失ったか
かなり不調っぽいね
スマートフォン=ゲームプラットフォームだよ
iPhoneのソフト市場は既にPSPを越えてる
数はともかく、金額ベースでは
苦し過ぎなんじゃね。すでに
勢いが無くなって、みんな
ソーシャルゲームに移ってるみたいだし。
>>922 > 廉価CPUにそれなりのGPGPUがついてきたら殆どの人はそれで満足数だろうな
Ionですね。
>>928 iPhone向けゲームビジネスは非常に苦しいっす……
また画期的過ぎる解釈だ
やっぱ好調なのね
過当競争で厳しいのと、過疎かつ高コストで厳しいのとどっちがマシか
・・・どっちもクソだな
ゲームユーザーが去ったら買い替え周期ってどうなるんかな?
たぶん次世代もゲーム専門機としてやっていこうと考えてるのは任天堂くらいしかないと思うよ
ただ据え置き機のXboxは「安いパソコン」化だけはしないと思うけどね
PS3が自社開発のブラウザやBDプレイヤーを搭載しても
360はIEを載せなかった
競合他社と競争するために自社製品の市場を自ら切り崩すような本末転倒なことはやらないのはMSもIntelも同じ。
>>926 結局ダンゴのCPU選びは性能、コスパ等ではなく、「みんなが使っているから」という理由か…。
思うよwですか
開発ヤメタって話を聞いてきたのかと思ったがな
なんだか詳しそうなんだし裏を取ってきてよ
>>935 安いだけならAtomで十分なんだ。ごめん。
メーカーの視点でいうとこうかな
Core i3/i5/i7・・・メインストリームからパフォーマンスレンジまで同じソケットでカバー
グラフィック性能が必要ならディスクリートカードを刺せばいい
Celeron・・・前世代のCore 2ベースの筐体設計がそのまま使い回せる
低価格路線に転じたAMDが採用されるかどうかは、Intel IGP以上ディスクリート未満の
統合GPU性能のために別途筐体設計をする価値があるかどうかにかかっていると思うよ。
そもそも(ネットブックを除いた)ノートPCの消費者はGPU性能を殆ど必要としてないビジネスユーザーが
かなりの部分占めてるんだし、GPUが強力になれば売れるなんて発想はファンボーイ1人が願っても
ベンダーはそうは思わないのが現実。
780G/790Gでシェア奪還出来てないことを、CPUアーキ変わらないまま
CPUくっついてから本気出すとか言っても何も変わらん。
ゲームしたい人が日本メーカーのPCを買うのか?
なら日本メーカーはIntelを選ぶわな
団子のゲーム業界やGPUに関するコメントを意訳すると「intelの軍門に降らない業界など潰れてしまえ」って言ってるだけだしな。
例えばGPUに関しては「GPGPUなんてCPUの仕事を奪うようなことは止めてGPUとしての仕事だけしてればいい」と言いつつ
「だけど、GPUとしての仕事は今後CPUがやるから、GPUはお役ご免になってくれ」だからね。
この二つを重ねれば、「俺(CPU)はお前(GPU)の仕事を奪うけど、お前(GPU)は俺(CPU)の仕事を奪うなよ」と言ってるだけ。
Intelがゲーム業界に溶け込めなかったから機嫌が悪いんじゃね?
日本でAMDが採用されないのは供給量に問題があるからじゃないの
過去のIntelの汚いやり方も関係してるけど
まあ、セレロン大国の日本じゃCPUなんかは一般人には関係ないかw
IGPを全面に打ち出したいならSandy Bridgeのセカンドソース契約して
GMAの代わりにRadeon載っけた製品でも作ったらいいんじゃないの
CPUはビックリマンチョコじゃないんだから「おまけ」目当ての消費者を当て込むのは間違い
それが出来るならやってますがな
Intelが自殺志願者に見えるなんてやっぱ不調か
何をどう批判してバカにしても結局Fusionを肯定するしかなくなるからな
>>928 スマートフォンで多数を占めるSnapdragonのGPUコアはXBox360互換でRadeon互換
ライセンスは譲渡しているけどね
アーキテクチャに共通点が多いから、移植やらクロス展開がとてもしやすい
結局ATIアーキテクチャがゲーム市場の多数派であることは変わらないんだよ
>>930 IonはCore2と一蓮托生で今後先細りで来年死ぬ
Ion2は低性能外付けでしか無いからやっぱり来年死ぬ
団子はAMDプラットフォーム採用のノートPCのモデル数が50から100に倍増したのを知らないのか
ノートベンダーの90%がDX11 GPUに興味があるのを知らないのか
>>943 じゃあ逆にRadeonのIPをライセンスしてマージンを取るんだ!
・・・どっちも無いな
しかしAtomあたりに関してはTSMCに委託してるし、Ionとかの統合化とか含めあり得ん話じゃない
TSMCに委託ってIOチップじゃん
>>946 >
>>943 > じゃあ逆にRadeonのIPをライセンスしてマージンを取るんだ!
> ・・・どっちも無いな
自社ハードですらろくにドライバも作れないIntelにVLIWでめんどくさいRadeonは到底扱えないよ
IntelはおとなしくRadeonと組合せてりゃいいんだよ
> しかしAtomあたりに関してはTSMCに委託してるし、Ionとかの統合化とか含めあり得ん話じゃない
TSMCのAtomは委託して1年間顧客がつかなくて頓挫したのを知らないのか?
> VLIWでめんどくさい
GPGPUとして成功しないと思ってる最大の理由を俺より先に言ってくれて感謝する
>>934 でも任天堂が一番ゲーム専用機から遠いよな、ある意味。
WiiFitは健康器具だとか言ってる人ですか
ぶっちゃけ、ある意味あれは究極のやり込みゲーだよ
WiiFitの耐荷重オーバーしちゃっている人なんだろうね
なんだか可哀そう
Fusionってのが少ししたらでるから、安いマザボとCPUにしといてあとで取っ替えろ
っていわれたんだがあってるの?
>>945 これってIntelの製造が追いついてないからじゃないの?
>>950 最大の理由はマーケティングが弱いことだろ
VLIWは扱いが難しいだけで大した理由にはならないよ
マーケティングが強いとX2よりPenDが売れるし、リネームやメモリバス削減詐欺でも売れるんだからな
>>955 間違いだよ
今のマザーにはどうやったって載らない
>>956 アランが追いついてないだけ
Core2機増やせばいいだけでAMDとは関係ない
VLIWは使い物にならないだけで
AMDも切捨て路線ジャン
MIMID、MIMD騒いでるが
まじめにMIMDならその複雑さはlarrabeeなんかの比じゃない
WiiFitは欲しいけどマンションだから無理やねん。
>>960 明らかに日本語になってない何かの言葉をクシし
算数の出来ないウンコといつもコンビを組んでるIDだということを猛烈にアピール
Larrabeeで団子のトリを解析するのが夢です。
Intelは複数の工場をローテーションさせ、常時4工場以上稼動させている
対してAMDは1工場
マーケティングも何も、今の生産能力じゃ何をやっても無意味
GFの新工場と買収攻勢に期待
CPUの戦場で勝敗を決めるのは製造の方であってアーキテクチャーなんておまけ
>>957 Pentium Dは既に動くソフトが存在してたろ。何が言いたいんだね?
Radeonは十分なシェアは確立してるがGPGPUとしてのソフトはほぼ皆無。
一般消費者にとってはVLIWプログラミングするために買ってる訳じゃないからGPGPUとして日の目をみるかどうかどうかは全くの別問題。
ひとつの事実として、NVIDIAは、VLIWを辞めた。
理由は明快。VLIWは汎用的なコードのプログラミングに向かないからだ。
>>964 Core 2, Xeon(Woodcrest)の登場以降、製造キャパが余りまくって赤字になったのに
売れない製品を大量に作ってもゴ○になるだけでしょう?
ほんとに妄想とバグしかないな
VLIWが汎用的なコードのプログラミングに向かないってのは事実なんだろうけど、
汎用性に振りすぎた初代Larrabeeは電力効率とか(他にも理由はあるだろうが)で市場に出なかったし、
今は業界全体で汎用性と効率を両立したプロセッサのアーキテクチャとプログラミングモデルを模索してる段階なんじゃない?
製造原価そのものは安いので値下げするという手がある。
値下げして売れるならな。
>>964 現時点でドレスデンのFab1とチャータード合併により得たFabが、Fab2〜7。
NYの建設中のFabがFab8扱いになります。見事な嘘をありがとう。
ちなみに、Fab1はFab36及びFab38と呼ばれていたモノなので、
実質的に2工場分の生産キャパを持っているといっても過言ではないでしょ。
フル生産でx86市場でシェア50%を狙えると豪語していたFabだし。
まぁ。そのFab36/38がAMDの経営を圧迫していたんだけどな!
圧迫させるために稼動させる世界というのが「押入れ」
ATIがずっとVLIWを続けるって前提なのが面白い
スレッドは無数にあるけど1スレッド内では依存性が強い
という状況では
NVのアーキではスレッドを次々と作って演算器を余さず使えるのに対し
VLIWでは複数スレッドを1命令に収めることは出来ないだろうから
1ユニットだけ動いてて他の4ユニットは暇を持て余してるという状況になり効率が悪い
しかしベクタでなくても1スレッド内でとにかく並列度が高い状況が続くのなら
VLIWは非常に効率が良い
3D描画でラデがゲフォをボコっている通り(ゲフォFXは何故か失敗したようだけど)
GPGPUではNVのやり方が正しいのならVLIW続けるのは無いだろうけど
だったら16ベクタユニットが1つと2つのスカラユニットしかないララビなんかもっと酷いんじゃないか?
>>970 その中でCPU製造用なのはFab1だけ
でもってFab1はAMD時代に建物こそ2工場分建設されたが、拡張された2工場目は建物だけで中身は無し
※現在はラインが作られ、年内に稼動
バルク用や200_ウェハ用の工場ならいくつか有るが、現行のCPUは作れない
アホ乙
>>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ではそういう割り振りが可能)
NVアーキと同じ様に
スカスカSIMDもといSIMMユニットのメモリロード待ちに別スレッドを作り
別の命令でSIMMを埋めることが出来る世界が押入れ
流石は隆盛(たかもり)くん目当てでデータ並列=タスク並列なショタホモである
正確に言うとLarrabeeは4Wayのハードウェアマルチスレッド×16Wayのソフトウェアマルチスレッド(笑)で64 thread/coreかな
普通のCPUのように1つのプログラムフローの中で並列演算リソースを全て使うようなプログラミングスタイルを行う自由度は与えられていないので
GeForceのSIMTはむしろSIMDの劣化版と見ることもできる。
plNa4WAz←ニート発狂wwwww
雑音風味が効いてるな
三交代制って言ってたよな
脳内乙
自分で持ってきたソースも全く読めずに
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セットなど)。
> SIMDでは,ベクトル演算器の得意とするベクトル様式に,データ側を調整する必要がある。
> 例えばSSEだと4要素ベクトル演算器で処理系が実装されているため,すべての演算器が活用されて,
> 最高のパフォーマンスが得られるのは,演算対象となるデータが4要素ベクトルのときに限られる
> (※あるいは2要素ベクトル×2セットなど)。
GeForceは4要素じゃなくて32要素ベクトルになるだけだけどな。
データの再パッキング(たとえばx, y, z, wを砕いてxだけ32個、yだけ32個・・・)を抽象化してるだけにすぎない。
LarrabeeにはGather/Scatterを1発でできる命令が標準で備わっているのでGeForceと同じことができる。
夜中だろうと平日日中だろうと休み無く2chで働く人乙
団子しっかりしろ。地が出てるぞ。
>>981 雑音が3人いて三交代24時間態勢なのかと思った。
雑音が単一人物でも、読む価値無しなコテ(NG済)が2名ぐらいいるから計3名か。
過去のウンコが持って来たソースvs今のウンコの妄想
勝つのはどっちだ
CUDAのいうwarp=従来CPUやLarrabeeでいうthread
CUDAのいうthread=Larrabeeでいうstrand
まあ、言葉遊びだな。
> SPがメモリアクセスを発注していて,その結果が返ってくるまでストールしていたりするのを検知すると,
> IUは次の命令を受注し,SPを活用すべく別のスレッド発生させる」という仕組みが採用されているのだ。
> この仕組みにより,SMは常に複数の実行スレッドを請け負い,休みなく“働く”ことになる。
このスレッド切替機構もwarp単位の話で、原理的には広義のSMT(IntelでいうHT)と同じ。
完全に命令ストリームの独立した「スレッド」を同じ房にぶら下がったSPで別々に処理できることを意味しない。
俺の言うことが矛盾してるように見えるのは要するに本質がわかってないということだ。
団子、いつのまにかすっかりいつものテヘに戻っているなw
「4亀ソースにあるように
ゲフォはSMTスーパースカラに似た処理が出来る
ララビも同様にSIMM内でスーパースカラが出来る」
以上、24時間営業から突然夜間営業のみになった押入れからの念仏中継でした
>>989 > 俺は人物の区別もできない馬鹿です
まで読んだ
AMDもSIMDっちゃSIMDなんよ
16way中に更に5wayの演算器とか非常にめんどいけど
>plNa4WAz
もう良いよ顔真っ赤だぞwww
よく頑張ったからAMDのスレの警備なんてしなくていいから自宅の警備に戻れwww
スレッド粒度は
larrabee 16
cuda 32
stream 320
ゲルシンガーの夢は団子の中でまだまだ生き続けている
丁度良いところに、ぽっ、と出てきただけだろうけど、
IntelはセカンドプランとしてPowerVR使い続けるという手があるだろうな。
あれもドライバでOpenCL対応とかやるんでしょ?
GPUの根幹をPowerVRで作って
固定機能多目、最低限のEUをGPUブロックにのせ
必要ならばCPUの演算器を使うってのはいいと思う
1000
1001 :
1001: