【CRISC】CPUアーキテクチャについて語れ【EPIC】3

【天麩羅】

お前らいい加減、無能なAMD房・Intel房に振りまわされず、
エンコ時間がどうとかPIがどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、

フリップフラップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。

さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！

前スレ
Part 1　http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/
Part 2　http://pc7.2ch.net/test/read.cgi/jisaku/1101041110/

2het

VC++の最適化がとてつもなく糞な件

; Listing generated by Microsoft (R) Optimizing Compiler Version 13.10.3077

; （中略）
PUBLIC?transpose@@YAXQAD0@Z; transpose
; Function compile flags: /Ogty
; File c:\documents and settings\fusianasan\my documents\hoge.cpp
_TEXTSEGMENT
_a$ = 8; size = 4
_b$ = 12; size = 4
?transpose@@YAXQAD0@Z PROC NEAR; transpose

; 4 : void transpose(char a[8], char b[8]) {

pushebp
movebp, esp
andesp, -8; fffffff8H

; 5 : __m64 m = *((__m64*)a);

moveax, DWORD PTR _a$[ebp]
movqmm0, MMWORD PTR [eax]

; 6 : for (int i = 8; i-- ; ) {

movecx, DWORD PTR _b$[ebp]
moveax, 8
$L948:

; 7 : b[i] = _m_pmovmskb(m);
; 8 : m = _m_paddb(m, m);

movqmm1, mm0
deceax
pmovmskb edx, mm0
paddbmm1, mm0
movBYTE PTR [eax+ecx], dl
movqmm0, mm1
jneSHORT $L948

; 9 : }
; 10 : _m_empty();

emms

; 11 : }

movesp, ebp
popebp
ret0
?transpose@@YAXQAD0@Z ENDP; transpose
_TEXTENDS
END

同じコード＠ICC 8.1

; -- Begin ?transpose@@YAXQAD0@Z
; mark_begin;
IF @Version GE 612
.MMX
MMWORD TEXTEQU <QWORD>
ENDIF
IF @Version GE 614
.XMM
XMMWORD TEXTEQU <OWORD>
ENDIF
ALIGN 4
PUBLIC ?transpose@@YAXQAD0@Z

?transpose@@YAXQAD0@ZPROC NEAR
; parameter 1: 8 + ebp
; parameter 2: 12 + ebp
$B1$1: ; Preds $B1$0
push ebp ;4.38
mov ebp, esp ;4.38
and esp, -8 ;4.38
mov edx, DWORD PTR [ebp+8] ;4.6
movq mm0, QWORD PTR [edx] ;5.23
mov eax, DWORD PTR [ebp+12] ;4.6
mov edx, 7 ;6.18

; LOE eax edx ebx esi edi mm0
$B1$2: ; Preds $B1$2 $B1$1
pmovmskb ecx, mm0 ;7.12
mov BYTE PTR [edx+eax], cl ;7.5
paddb mm0, mm0 ;8.9
add edx, -1 ;6.18
cmp edx, -1 ;6.3
jne $B1$2 ; Prob 90% ;6.3
; LOE eax edx ebx esi edi mm0
$B1$3: ; Preds $B1$2
emms ;10.3
; LOE ebx esi edi
$B1$4: ; Preds $B1$3
mov esp, ebp ;11.1
pop ebp ;11.1
ret ;11.1
ALIGN 4
; LOE
; mark_end;
?transpose@@YAXQAD0@Z ENDP
_TEXTENDS
_DATASEGMENT DWORD PUBLIC FLAT 'DATA'
_DATAENDS
; -- End ?transpose@@YAXQAD0@Z
_DATASEGMENT DWORD PUBLIC FLAT 'DATA'
_DATAENDS
END

その例ではVC++よりICCの最適化が優れている事はわかったが何が言いたいの？

斜め上を突っ走る人間のする事は理解できん。

VC++がアフォなだけかと。

>>2-6
板違い帰れ。

もっとも、このコード自体あんま良くない。
アンロールしても依存関係で並列化できるところが少ないし。
分岐ペナルティの話にしてもPentium Mならループ専用の分岐予測器があるので完全ノーミスでもおかしくない（これは良いことだけど）

この例だと_m_psllq(m, 1);で代用可能なのでいいんだが、どーやら両引数に同じ変数を入れると常に無駄なコードを吐くらしい。
_m_pxor(m, m);でレジスタクリアするとか。まぁこれは_mm_setzero_si64()を使えばいいのだが、
_m_pcmpeqb(m, m)とか、 _mm_setone_si64とかないから、どうしようもないじゃないですか。
全ビット立てたQWORD値を読み込んだほうが速いです、マジで。使えません。

まともに最適化ノウハウを教えないIntelが悪いのか、MSがタコなのかは知らないけど
ここまでコンパイラがアフォだからこそ逆に、x86ではASM直書きする価値があるんですわ。

GCCやCWのAltiVec拡張はASMで書き直す必要ないくらいまともなコード吐いてくれる。
Cレベルでソフトパイプライニングは余裕。というかレジスタ決めうちじゃない分Cのほうがやりやすい。
アルゴリズムのチューニングに注力できる。

Mac開発者これから大変だな。GCCもVC++と似たようなレベルよ。

Mac用にもIntelがコンパイラ提供するんだろ？

IntelがLinux版程度のものでも無償提供するかどうかは疑問だけどね。
また、IntelにしてみればObjective-C対応のコンパイラなんて作ってられないだろうし、
そうなるとコンパイラの使い分けが必要になったり。どちらにしろ開発者は苦労するね。

AppleがC/C++向けのフレームワークの開発再開してくれれば俺は喜んで禿について逝く。
Cocoa大嫌い。

変な粘着が住み着いてしまいましたねorz

細粒度のデータフローマシンがお好き？

>>糞固定
前のスレでも我慢してたがCPUアーテクチャを語るスレだといい加減気づけ。
というか、何を語りたいのか意味不明だから勘弁してくれ。
文章垂れ流しをしているようにしか見えないから。チラシの裏に（ｒｙ
いずれにせよ、かなりスレ違いだからさ、その辺を空気読めよ。

まぁなんだ、CPUアーキテクチャの特性を知らずしてソフトの最適化を語るほど愚かではないから
基本的に突っ込まれたら知ってる範囲で問答しようぜよ。

何ならDinamic BindingやPolymorphismなどのオブジェクト指向的機能を取り入れた
コードを処理するのに有効な間接分岐予測の実装について小一時間でも。
MacOSはPentium Mベースのアーキテクチャに移行して正解かもわからんね。
JavaとかObjective-Cでありがちなスタック処理も間接分岐も強い。
こういう切り口でいくらでも議論は成り立つと思うがな。

無論当方とて別板別スレの同窓会やりたい気はないのだが、ストーカーって怖いものだね。

IBMはもうＰＣ用よりもゲーム用等に適した作りのチップを作る事に力を入れたいから切り捨てたって事なんでしょうね、きっと…

サーバ用マルチコアの習作なんじゃないの？

> 知ってる範囲
公園の水溜りより狭く浅い知識で語られても迷惑千万だからもうくんな。

これでもR8CやSHも叩いたことあるが。あとGeForceのシェーダもな。

その程度の基礎的なことで知識があると勘違いしているのか。
いい加減そのみかん箱より狭い世界から外に出たほうがいいぞ。

>>19は博学らしいのでさぞ語ってくれるのだろうなｗｗｗ

お前の個人スレじゃないんだから、
もちっと発言を減らせ。

>>団子
VC++の最適化が気に入らないならMS news groupや開発者blogとかに書けばいい。
意外にまともに対応してくれる事もあるぞ。まぁ、あのコードの意味は突っ込まれるかも
しれんがな・・・

gccの最適化が気に入らなければ・・・中略・・・自分でやれって言われるかもしれんがな・・・

どちらにせよDinamicとか書いている英語力では(ry

ところでRISCとCISCはカバーしているがEPICは叩いた事ないのか？

>>20
さんざ語ってきてるし他の連中も語ってきてるし、
何よりお前間違い指摘されても理解できてねーし。
そのちり紙より薄いプライドに泥塗られて火病る前にちったぁ雰囲気読め、吉外。

団子が話に参加してもいいけど、団子の話するのはやめにしよう。
うざいものがよけいうざくなる。
PWRfecientとかそういうのの話はないのか。

>>22
Itaniumは実機は叩いたことは無いがいちおう無駄に命令セットの概要は知ってるお。
コンパイラも走らせたことがある。最適化見てどんな動きするかは大体予想しつつ。
あー、IPFsimなんてのもあったかな。

流石にリッチな命令セットらしく、IA64用VC++でも比較的思い通りのコードを吐くらしい。
GCCあたりもだけど、レジスタが多くて3オペランド以上（非破壊的）な演算だと
まともなコード吐くコンパイラって多いと思う。

予想なんだけど、VC++のコンパイラエンジンってもともと古典的RISC向けに組まれてるんじゃないの？

VCの吐いたコード見ると気づくんだけど
$L948:
movq　mm1, mm0
dec　eax //←なんでここでフラグ更新してるの？
pmovmskb edx, mm0
paddb mm1, mm0
mov BYTE PTR [eax+ecx], dl
movq mm0, mm1
jne SHORT $L948//条件ジャンプはここよ

条件jump命令とフラグ更新命令の間にフラグを更新しない命令（ここではMMX/SSE命令）を後に何個か連続させることで
パイプラインストールを回避するってのはRISCプロセッサの最適化の常套手段だった希ガス。
んで、RISC向けのコンパイラエンジンに少しずつx86特有の最適化手法を取り入れたのが今のVC++と。
x86のGCCもそんな感じだし。

別のコードだけどテキストセグメントが肥大化しすぎてPentium 4向けの最適化でかなり痛い目にあったことがある。
Pentium IIIやMじゃたいした問題じゃなかったけど、Pentium 4ってL1キャッシュがかなり小さい
（NorthwoodでHT有効なら4kbyteまでしか使えない）から、1関数でセグメントが数KBとか食うと
それだけでキャッシュミスの頻度が上がるのね。

上のコードはHacker's Delightに載ってるBitwise TranposeのSSE最適化版ね。
オリジナルとはまったく別の方法を使ってるけど。

はいはい PWR / efficient　PWR / efficient

コンパイラが馬鹿コード吐いて困ってます
コントロールレジスタを使わなくて済む整数キャスト用の命令付けてください

そうだな、せっかくの良スレをたかが一匹の糞で潰すのはもったいない。

そういえばAMDとIntelでマルチコアへの見方が違うけど面白いな。

RISCも何も普通にスケジューリングするとそうなる

パイプラインが導入された時点でフラグ変更命令とフラグ非変更命令の
入れ替えなんてのは普通にあったな。

OSもハードで実装した例とかってある？
めっちゃ軽そうやん？

>>28 つーわけでIntel先生の最適解
icl hoge.cpp /FA /Ox /c /G{5,6,7} で検証
・/G5　Pentium
mov eax, 7
$B1$2:
pmovmskb ecx, mm0
mov BYTE PTR [edx+eax], cl
paddb mm0, mm0
dec edx
cmp edx, -1
jne $B1$2

・/G6 Pentium III向け。
mov eax, 7
$B1$2:
pmovmskb ecx, mm0
paddb mm0, mm0
mov BYTE PTR [edx+eax], cl
dec edx
cmp edx, -1
jne $B1$2

・/G7 Pentium 4, Pentium M向け。decをadd -1に置き換えているのはNetBurstの特性配慮かと。
mov eax, 7
$B1$2:
pmovmskb ecx, mm0
mov BYTE PTR [edx+eax], cl
paddb mm0, mm0
add edx, -1
cmp edx, -1
jne $B1$2

OoOの無い第5世代アーキテクチャ（もっともSSE Pentiumなんてモノは存在しないが）向けを含め
全てjccはフラグ変更の直後になってる。
これを模範とすればVC++の最適化の挙動ってやっぱり奇妙と言わざるを得ない。
試してみればわかるがループの中身をもっと増やした場合、VC++は際限なくフラグ書き換えを前のほうに持ってくる。

VC++の想定してるアーキテクチャは
・フラグ書き換えは条件ジャンプ命令よりできるだけ前のほうに持ってきたほうがいい
・src, destが同一レジスタのオペレーションはペナルティがあるので別レジスタに値コピーしたほうがいい

なまじIDE付きのWindowsコンパイラ製品で最速だからx86に最適化されてると思われがちだが
この辺の動き見る限りではx86にチューニングされてるとは言いがたい。　

格納するアドレスがecx+eaxだからって考え方もあるか。
老婆心ながらループを for (int i = 7; i >=0; i--) {} に変えてみたらどうなるか試してみましたよ。

PUBLIC?transpose@@YAXQAD0@Z; transpose
; Function compile flags: /Ogty
_TEXTSEGMENT
_a$ = 8; size = 4
_b$ = 12; size = 4
?transpose@@YAXQAD0@Z PROC NEAR; transpose
; Line 4
pushebp
movebp, esp
andesp, -8; fffffff8H
; Line 5
moveax, DWORD PTR _a$[ebp]
movqmm0, MMWORD PTR [eax]
; Line 6
movecx, DWORD PTR _b$[ebp]
moveax, 7
$L947:
deceax←意地でもフラグ変更はここ！
; Line 7
pmovmskb edx, mm0
; Line 8
movqmm1, mm0
movBYTE PTR [eax+ecx+1], dl ←ここで+1してるあたりもう必死かと。
paddbmm1, mm0
movqmm0, mm1
jnsSHORT $L947
; Line 10
emms
; Line 11
movesp, ebp
popebp
ret0
?transpose@@YAXQAD0@Z ENDP; transpose
_TEXTENDS
END

>>30
OS専用命令やハードウェアなら実装されている。
例えばMMU等ハードウェアや管理系命令、タスク間&マルチプロセッサ通信命令等。

>>25
> Itaniumは実機は叩いたことは無いがいちおう無駄に命令セットの概要は知ってるお。

知ったかぶり表明ですね。
勇気がありますな。

SYMBOL

シムボル

>>団子
スレ違いって何度も言われているのに何でVCの話を必死になって続けてるの？

単に「MMX/SSEの最適化が出鱈目」ってことで脳内解決しとくわ。
ここには分岐予測のアルゴリズムについて語れる人が居ないということもわかった。

分岐予測の話題など出たこともないのだが

じゃあ消えろ

確かに敢えて出さなかったがVCがフラグ値をなるべくjccの実行より早く更新させたがる理由を考える上で
分岐予測の機構は外せないだろ。

decやaddの命令のレイテンシはせいぜい1か2程度なので、ここまで必死にフラグ更新とjccの
実行タイミングに間を置きたがる理由は分岐がらみの問題以外に無い。

IntelのコンパイラがやるのはあくまでIntelの石向けの最適化なので、互換CPUでの最適化まで保障しない。
たとえばAMDやVIAの石だとマイクロアーキテクチャの実装がIntelとえらく違うのかな、とか。

AMDの最適化マニュアルはろくに読んだことがないので暇なときに目を通すけど、徒労に終わるかもしれんね。

ここはコンパイラ屋さんがくる所じゃないよ

分岐予測はフェッチ時にやるんだよ馬鹿

>>42
ベクトル型にしろスカラ型にしろ、ハードの特性を生かす有効な最適化手法を知らずに
ハードについて語れることなんてほとんど無い気がするけど

>>43
その通りだよ。
現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
でもフェッチはインオーダだろ。

手段と目的が入れ替わっとるとは思わんですか？

最適化はプログラマの手助けであって、CPUの高速化ではなかった（少なくとも最初は）
CPUの目的はインストラクションの実行ではなく、データ演算のためだった（少なくとも最初は）
パソコンの目的は速さを競うためではなく、何かアプリを動かすためだった（少なくとも最初は）

> ベクトル型にしろスカラ型にしろ、ハードの特性を生かす有効な最適化手法を知らずに
> ハードについて語れることなんてほとんど無い気がするけど

明らかに遅いコードを見てアーキテクチャを語る事は無駄だな。
団子はこのスレに池。

x86命令の所要クロック計測スレPart2
http://pc8.2ch.net/test/read.cgi/tech/1136527588/

> 現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
instruction decoderがsymmetricでない場合は問題がある。

そのスレなら見てるよ。目ぼしい知識はないから書き込みはしないけどね。


> > 現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
> instruction decoderがsymmetricでない場合は問題がある。

ほらそうやって論点をずらす。問題はフラグ変更とjccの関係。

馬鹿だなぁ。
お前のオナニースレの間違いを指摘しただけ。
間違いを指摘されて開き直る馬鹿相手に議論なんて無意味だし
議論していないんだから論点なんて存在しない。

> instruction decoderがsymmetricでない場合は問題がある。

俺が話題を限定して言ってるのは明白なのにこんなわざわざ知ってる範囲のことを得意げに
語られても困るって話よ。ID違うけど何か工作中だったのかな。

「お前のスレ」か。じゃあ俺に所有権認めたのね。じゃあこのスレに書き込まないでくれる？

ついでに言うが「thread」と「response」を間違えたと言い訳するならますます墓穴ですよ
このまったく非なる語彙をうっかり間違えるようなのはコンピュータ技術について語る以前の問題なので。

「の」には所有以外の意味もある事はしらないのですか？

ここを「オナニースレ」といったことは肯定しつつ苦しい反撃しますかｗｗｗｗ

朝早いんで寝るよ。昼寝したから眠くないけど。

>>47
>問題はフラグ変更とjccの関係。
つーかそれってさ、uOpに変換後どう最適化してんの？って聞いてるのと同じだろ？
そんなにディープな内部情報をIntelもAMDも公開しないだろ。それがx86の実行効率のキモにもなるし．．
実地で計るしか無いんじゃないか？

一応，uopでググると以下が見つかった．どっちも海外ニュースだ(~~;)
K8
http://pc.watch.impress.co.jp/docs/article/20011102/kaigai01.htm

Yonah
http://pc.watch.impress.co.jp/docs/2005/0906/kaigai209.htm

どうみても団子の立てた団子のオナニースレです。
本当にありがとうございました。

スレの所有権を宣言するウンコwww

プログラム板で相手にされなかったからって、
他板の良心的スレに張り付いて荒らし続ける人って嫌いです

MACヲタよりはマシだけどな

MACヲタは間違いを認めるので団子よりマシ

何の役にもたたねーし間違い指摘されても理解できてねーし
マジで荒らし以外の何物でもないよな。せめて便所ネタでも書けりゃいいのに。

2-60を透明あぼーんで桶?

>>56
団子は鳥屋に勝った香具師だ見くびるな

MSのコンパイラの動きはバグとかじゃなくて何か確信をもってやってるように見えたんでね。

x86で「遅延分岐」が有効かどうか？
MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを
フラグ確定だけ先に持ってきても、どのフラグを使うか、どこにジャンプするかの情報はJCCのほうにあるわけだから
意味ないようにも見える。事実Intelコンパイラはこんな動きをしてない。
Intel CPU以外の何かでは役に立つ情報なのかもしれない。

かわりにIntelコンパイラがVC++より多めに吐いてるものがtestやcmpなどの比較命令だが、コレは実は（以下自制）

このへんの理屈は分岐予測の実装に絡んでくるはずなんだな。
まぁ先にも指摘があるようにこのへんは基本的にブラックボックスなので想像に頼るしかないところは多いと思う。
この話題はム板に丁度その議論やってるスレ（メロンアイス鳥つけてる人のスレじゃないよ）見つけたんで
そっちで投げてみるわ。今は反芻している。

>>55
まぁべつに長居する気はないが「お前のスレ」って言われれば「じゃあ命令される筋合い無いね」って切り返すのは
当然と思いますが、何か？

以下めんどくさいので略

-MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを
+MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを回避or軽減するためのものでは？

>>62
> MSのコンパイラの動きはバグとかじゃなくて何か確信をもってやってるように見えたんでね。
バグでも特別な処理でもなく、普通にスケジューリングするとそうなる(こともある)っつの。

> x86で「遅延分岐」が有効かどうか？(以下略)
全く意味不明

> このへんの理屈は分岐予測の実装に絡んでくるはずなんだな。
どこがどう絡むのか、想像でもいいから書いてみろや。

改めて聞くけど、>>32も、普通にスケジューリングするとそうなる範囲内？

自論は、「Intel CPUにはあくまで無意味」だが、何か別のアーキテクチャの分岐処理では有効な
スケジューリングじゃないかという話。

遅延分岐って知らない？RISCとそのコンパイラでよく使われた最適化手法だけど。
分岐先判明後に数命令、どっちに分岐しても悪い作用の無い命令を続けることっで
分岐のペナルティを回避するというやつ。

フラグ更新とjccの間の命令数命令が、ある何かのアーキテクチャでは、
パイプラインストールを隠蔽するために使われるのでは、という仮説。

まぁこれはむしろ分岐予測じゃなくて分岐確定後の処理寄りだけどね。

>>65
> 改めて聞くけど、>>32も、普通にスケジューリングするとそうなる範囲内？
そうなる範囲内

> 遅延分岐って知らない？RISCとそのコンパイラでよく使われた最適化手法だけど。
遅延分岐はハードウェアの話だ。
x86に遅延分岐が実装されたことは一度もない。

> フラグ更新とjccの間の命令数命令が、ある何かのアーキテクチャでは、 パイプラインストールを隠蔽するために使われるのでは、という仮説。
大抵のアーキテクチャでは、一般的に(条件コードを含めて)データ依存関係のある場合はそうなる。

どうでもいいがパイプラインストールを隠蔽というのはおかしな言い方だぞ。

> まぁこれはむしろ分岐予測じゃなくて分岐確定後の処理寄りだけどね。
だから分岐予測は全然関係ねーの。

＞大抵のアーキテクチャでは、一般的に(条件コードを含めて)データ依存関係のある場合はそうなる。

依存関係ね。はい。
これをやらないと、具体的にどこどこに依存関係の問題が発生するのでしょうか？

あと、ICCの最適化ではjccの直前でcmpやtest命令を発行しフラグ変更してますがこれは悪い例ですか？


>>66
分岐予測はフラグ変更を監視してるんじゃないんの？今の仮説にはたしかに直接は関係ないけど。

何をしたいんだコイツ？空気読めない馬鹿って本気でウザいな。
誰一人として支持すらしてくれないのによくやるよ…自己満足甚だしい。

>>67
> これをやらないと、具体的にどこどこに依存関係の問題が発生するのでしょうか？
一般的には、データフローグラフを幅優先でtraverseすると並列度の高いコードができる。
そうすると自動的にproducerとconsumer命令の間に無関係の命令がたくさん入りこむ。

実際はリソースの制限があるのでもっと複雑なスケジューリングをやってる。

> 分岐予測はフラグ変更を監視してるんじゃないんの？
してない。
分岐のresolveにはもちろんフラグの値が必要だが、分岐を予測する時はフラグは見ない。

MIPS、マルチスレッディング対応の32bitコアファミリを発表
ttp://pc.watch.impress.co.jp/docs/2006/0207/mips.htm

>>67
>分岐予測はフラグ変更を監視
分岐予測なのにフラグを監視してどーする。予測じゃねーじゃんw

> 分岐予測はフラグ変更を監視してるんじゃないんの？

（　ﾟдﾟ）ﾎﾟｶｰﾝ

あれ？jcc発行時の履歴だけで判定してんだっけ？
フラグ値の変化も予測に反映されてる筈だが？
まあいいや。

>>69の説明じゃ、再三逝ってる、最終のフラグ変更とjccの間の不自然な間隔の説明になってない罠。
依存関係ならたとえばpmovmskb直後のmov [mem], dxにだってある。
[eax+ecx+1]なんてやったら命令長が増える。そこまでしてやる必要のあることか？
全部その理屈で説明可能？

故意にか回答を避けられてるようだがICCについても薀蓄よろしく。
スケジューリングがまったく別物なのでそもそも無理か。
うちはいちおういろいろ並べ替えてみてパフォーマンステストは行っているが合理的に正しいという結論に達した。

いつも楽しみにこのスレを覗かせてもらっている者です
最近知ったかぶりをみんなでいじめる書き込みばかりで読むのが嫌になります
でも分岐予測はフラグ変更を監視うんぬんという発言は致命的すぎます

>>73
> フラグ値の変化も予測に反映されてる筈だが？
どっからそういうウソ知識を。。。
分岐予測は基本的には分岐命令のアドレスと分岐履歴しか使わん。

> 最終のフラグ変更とjccの間の不自然な間隔の説明になってない罠。
おまいはdec eaxが一体どこにあれば自然だというんだ。

dec eaxとjccの間にはループ本体があるだけじゃん。


iccもべつにおかしくはないだろ。こんな短いコードならどう並べたところで大差ない。
P6以上ならdec-cmp-jccでuopsフュージョンやってるかもしれん。

致命的なのは文脈上どうみても勘違いしたとしか思えない「スレ」と「レス」の間違い以上のものはないかと。
もちろん、古典的な分岐予測システムは分岐方向・アドレスの履歴テーブルを使ってるのは承知なんだけどさ、

ループ検出器の機構を頭の悪い俺に説明してくれない？

>>76
> もちろん、古典的な分岐予測システムは分岐方向・アドレスの履歴テーブルを使ってるのは承知なんだけどさ、
使ってない。

> ループ検出器の機構を頭の悪い俺に説明してくれない？
お前の脳内機構の説明もできない。

>>75
μOPｓフュージョンが命令の「再結合」だと思ってる人発見ｗｗｗｗ

> P6以上ならdec-cmp-jccでuopsフュージョンやってるかもしれん。

ホームラン級の（ｒｙ
μOPｓフュージョンてのは

従来P6ではレジスタ・メモリ間オペレーションは、メモリロードとオペレーションに分離して処理してた。
２つ以上のμOPに分解するのは複雑なアルゴリズムが必要なので、3つのデコーダのうちの
１つComplexDecorderパスでしかデコードできなかった。
（VC++では今でも/G6ではメモリ・レジスタ間オペレーションの生成をなるべく避ける）

Pentium Mでは、デコードステージで分解せず１つのμOPとして扱い、そのままスケジューリング→
実行前のステージで分離→実行→再結合してからリタイヤという機構を導入したの。
それで３割ほど内部効率があがった。
決して既存のx86命令を結合する技術じゃないよ。

μOPsフュージョン知らないならPenMの分岐予測器の実装も知るわけ無いよな。
ちなみにループ検出器ってのはPentium Mに搭載された履歴を使うのではなく、ループ回数を完全にカウントして
完全に分岐方向を当ててしまうものなんだけど、当然ながらこいつにはBTBなんて使ってない。

Pentium II/IIIあたりの時代のIA32最適化マニュアルに分岐予測の実装について詳細に述べられてた。
韓国の大学のFTPサイトになぜか古いのが上がってたりしたが今は多分無いな。
最新のはどれも概要的なことしか載ってない

ftp://download.intel.co.jp/jp/developer/jpdoc/iaopt_j.pdf
これか?

小さいループは最近数回の履歴からグローバルパターンテーブル参照の機構でいけるけど
でっかいループを検出する「ループ検出器」がどんなアルゴリズムになってるかは謎だな
とはいえ、少なくともフラグ監視なんて発想は出てこないと思うぞ

>>BTBなんて使ってない。
BTBは使ってるだろ

俺的にはμOpsフュージョンがホームラン級なら、
分岐予測にフラグ監視はグランドスラム級、
レスとスレはシングルヒット級
だな。

＞∀＜）っ-○●◎- ◆Pu/ODYSSEYは、しゃべり杉
自分のWebサイトでやれよ。

2chでは他の発言者を尊重して自重しろ。

>>83
無理言うな。
一連の流れを見ればそんな社会性のある奴じゃない事はわかる。

録音、503、メカと同類。

>>80
そいつそいつ。

ループ検出器の作動条件を調べてみるとええかもね。

いわゆるfor文は後置に展開されるけど、ループ検出が効いてない状態だと、BTBは前方ジャンプで埋まってるだろうから
ループを抜けるときに分岐ミスするのは想像に難くない。

でだ、ICCがループ毎にcmp/testを生成する理由ってのは（ｒｙ


> >>BTBなんて使ってない。
> BTBは使ってるだろ

ループ検出器で扱えないものをBTBを用いた動的分岐予測器で扱うという意味では正解だけど
ループ検出器自体はBTBを持ってないよ。
http://www.intel.co.jp/jp/developer/technology/itj/2003/volume07issue02/art03_pentiumm/p05_branch.htm

> ループ検出器で扱えないものをBTBを用いた動的分岐予測器で扱う
何か勘違いしているようだが、BTBはジャンプのターゲットアドレスを保持するバッファだぞ
ターゲットの情報も使わずにどうやって分岐予測するんだ？
まあ、分岐履歴テーブルなども含めて集合的にBTBと呼ぶ、と書いてあるが

>>78
そうだっけか。
融合の対象になるのは単一のx86命令から変換されたuOPsだけってこと？

compare&branchに融合するつー話はなんかで聞いた覚えがあるんだが、
jcxz命令とかか、他のCPUだったか、PARROTなんかのヨタ話だったかもだ。

まあいいや。おれは特定のCPUには詳しくないのよ。これからも頼むわ。

で、そのPentiumMの分岐予測器とVC++やICCのスケジューリングがどう関係あるんだ？

>>81
> でっかいループを検出する「ループ検出器」がどんなアルゴリズムになってるかは謎だな
ttp://www.intel.co.jp/jp/developer/technology/itj/2003/volume07issue02/art03_pentiumm/p05_branch.htm
分岐履歴のかわりにカウンタとリミットで判定してるぽいな。

あんたら職業柄こういうことに詳しいのかい？それとも情報工学科の院生さん？
プログラムが趣味でこんなことまで知ってるの？

>>65
> 遅延分岐って知らない？RISCとそのコンパイラでよく使われた最適化手法だけど。

ヴァカか。最適化手法じゃネーヨ。プロセッサデザイン上の実装のひとつだ。
知ったかは（ ・∀・ ）ｽｯﾃﾝﾛ!

>>84
録音といい団子といいセーラームーンといい、まともな議論できないと
自論押し付けてくる馬鹿ってなんとかならねーかなぁ。

まともな議論というかそもそも説明自体ができなくなってだな、
そのまま何度も同じことを繰り返すだけになるんだよな。

だから壊れたテープレコーダ→録音と呼ばれているわけだが。

遅延分岐はなぁ…必要悪の類だろ(w

気に入らないならほっときゃいい筈だが、答えてる人もいるからな。
そういう人は結局よしとして受け入れているのだろう。
ま、俺は別にこの手の話は嫌いじゃない
んで暫くはかまわんけど。

こんな間違った情報を垂れ流す電波野郎を放置するのは百害あって一利なし。

「遅延分岐」という言葉も正しい意味で使えてないしな。

団子ﾀﾝはヘネパタ＆パタヘネからやり直しという事で。

半端な知識でコンパイラの最適化云々いう奴はDPDAとかLR(1)を知らなかったりするんだよなぁ。。。

>>97
おいおい、また半可通の講釈が始まるぞｗｗ

それじゃあパパは、BNFで最適化コンパイラ書くぞっと

こうしたほうがいいと言うなら
自分でコンパイラを作ればいいのにね。

「言語処理の専門家」キタ？

昔クロックがないMPUが発明された話聞いたけどあれどうなったのかなぁ……

別に、発明っつか、普通に非同期設計のプロセッサぐらいできるよ
性能出ないけど

というかバグ取りが悪夢。

IBM、Powerを2倍高速にする手法を開発
http://www.itmedia.co.jp/news/articles/0602/07/news070.html

歪なんちゃらってやつ？

絶縁層でシリコン層を押しつぶしてどうこうと言ってるが。
とりあえず俺の知識では全面降伏。
つかシリコン層を押しつぶすとシリコンの挙動がどう変わるのかなんて知らん。

不正尻子って何だ？

絶縁層で区切って二層にするとかそういうこと？？

絶縁層ってのは厚さからして現行のPD-SOIだろ。
押しつぶすってことは圧縮ってことだから歪Siってことじゃねーの。

> しかし、このプロセスではプロセッサが過熱する傾向がある。
ってのはSOI特有のSelf-Heating現象かね。
絶縁層が同時に断熱層になってしまい熱が籠もりやすいってやつ。


素人だから知ってる単語並べてみただけだけど。

NECエレ、16bitマイクロコントローラを復活
http://pc.watch.impress.co.jp/docs/2006/0214/nec2.htm

UltraSPARC Architecture 2005

今までで一番エレガントな命令セットはどれだと思う？

x86

>>114
ﾜﾗﾀ

MIPS R2000

Z80

4004

MC68000

mips2 も捨てがたいがここはひとつ



　　　　　　　　　　6502

68000に一票

68000はアドレスレジスタとデータレジスタが分かれているのがアレなんだよな。

V810といってみるのはどうだろう？
#V850とかではなく。

V800系ならV83x。
Super8と言って見たいが既にあれはSamsung8状態だしなぁ。
やっぱり6502に一票かな…

68060

ふつーに Alpha。
MIPSも悪くないけど、ロードの遅延スロットとかディレイドジャンプ
とかイラネ。

Am29000

TMS9995

6809

6809は命令エンコードが非対称なのでキライ

Efficeonとか言ってみる。
……エレガントかどうかなんてどうでもいいよな。CMS使うんだもん。

>>130
内部命令がエレガントかどうかが問題となる。

68030

ある意味エレガントなんだろうが、68kみたいなゴシック調のもキライ

NS32032

初期のDSP

ビッグエンディアンの８ビットって何考えてんだろ

Nexgen 6x86

>>135
具体的に

SH4は結構いいCPUだと思うぞ。
性能そこそこ低消費電力で組み込みにはいい石だ。
個人的にはARMより好きだな。

>>139
そんな感じのネタふりを前俺がやった。
でも冷静に考えてみれば消費電力は組み込みにしてはでかいんじゃない？
DDR2使えるからそれでも良いのか？

そうだ、命令セットを挙げなきゃいけないんだ。
う〜ん……ペンティアムバイナリ？

いやARMはサムコードとか変態命令セットが嫌いなだけ。

>>135
初期のDSPなんてマイクロコード剥き出しって感じで
エレガントとは程遠いものだったような気がするんだが。

命令長が長い割にレジスタ少ないしな＜ARM

SHって、遅いんだよな
安価で低消費電力のARMと、ハイエンドのMIPS、PowerPCに挟まれてって感じ

そんなに遅くは無いと思うけど…
発展とかクロック向上って意味なら取り残された感が出てたけどね(^^;
つい最近、400MHzのSH4が出てきたけど。

…まぁ会社が悪いと言えばそうなんだが…
そもそも、あそこは何をプッシュしてんだかさっぱり解らん。
旧H系だけでもH8SやH8SXの性能向上が激しいからSH2は収束なのかなぁ?とか思うし。

最近出たのは600のはず。発表値では1000MIPS超える。
命令セットが違うのであてには出来ないけど。
性能的にはSH4だけどARMの売りはソフトウェア資産なんだよね。

LINUX端末でも出てくれればなぁ。POCKETPCはあてに出来ないし。

64-wayｱｰﾄﾈｲﾁｬｰ

>>142
プリミティブアートみたいなもん

68kは壮麗なISAを目指したはいいが、最後になってリソース不足でアドレス・データレジスタを分離したり
32ビットオフセットのアドレッシングモードを実装できなかったりした印象

6809も、あれやこれやと詰め込もうとしてオペコード足りなくなったんじゃねーの

>>148
どこがエレガントなんだｗ

>>149
レジスタ作りすぎでオペコードを圧迫したRCAのCOSMACという例も。

PowerPC ISAはだめですか

去年の「情報処理」のプロセッサ特集（No.）10、11遅まきながら読んだけど、
汎用を狙ったアーキテクチャは面白いのがないよなぁ…
タイルとかリコンフィギャラブルとかは面白いけど特定用途狙いみたいだし。

それはともかくアウトオブオーダープロセッサが10年前のIPCを保つために
どれだけのリソースを食ってるかは考慮の外なんだろうか？＞特集のまとめ人

（No.）10、11
↓
（No.10、11)

65系ｲｲ!

配線遅延のせいで、リコンフィギュアラブルプロセッサとか
ゲートアレイはクロックがあがらなくて、汎用プロセッサに勝ちにくいんだよな
もうIAしかないのかと

アセンブラ書いてた人なんだけど、プロセッサの構成とかデータシート上の話
ばっかりしてて面白いのか?

とかおもいました。

x86と68000とSHとH8とPICと8080とZ80書けます。

どうかんがえてもgccで最適化かけたほうがはやいのですが、
gccはgdbの使い方がわからんので使いません(お

楽しみ方は人それぞれ。
アーキテクチャオタからすればアンタのやってる事見て「似たような
プロセッサで代わり栄えのしないプログラム組んで何が面白いのかね」
と思うわけよ。

>>156
上にあれこれ載るようになってプロセッサのアーキテクチャなんか、
プログラムの書きやすさと関係なくなったから、順調に性能が上がる
分にはIAでも文句は出ない罠。

なにってそら、バグをだしてまともに動かないプログラムを、きちんと動くようにする
その工程が、いわゆるツンデレ攻略なわけですよ。


萌えませんか?

全然

>>159
禿同

>>157
ちょ、おま、それだけアセンブラが書けて、なんでgdbの使い方が分からんのだｗ
gdbこそ、最初はとっつきにくいが、だんだん慣れて手に馴染むと手放せなくなる、
真のツンデレツール。慣れすぎてデバッグコードを埋め込んだままリリースしたりする。

IMHO, それでも取れないバグを切り分けしてこそ真のツンデレラーだと思う

>>162
ＬＯＬ

>>158
初期のDSPでガンバレ

レジスタ・ウィンドウは、有効かどうかについて

アプリケーション分野ごとの統計分析が必要だと思う件について

>>166
くわしく。

>>165
ttp://yarchive.net/comp/register_windows.html

レジスタウィンドウで速くはなるけど
リネーミングが複雑になったり、大容量レジスタでクロックが下がったり
80年代のR2000が32本で、90年代のPowerやalphaも32本
今のソフトは当時のよりレジスタ増加がきくだろうけど
128本レジスタスタックってのは
無駄にリッチでは？

>>169
>128本レジスタスタックってのは
>無駄にリッチでは？
うおぅ！ なるほど、わかってきました。
無駄に思いますね。

x86ってレジスタウィンドウ使用して無い？
それともx86でレジスタウィンドウすると、
クロック向上の妨げになるからあえて採り入れないのかな？？？

ナノテクだろうとなんだろうと、金属に電気流して周波数に意味もたせてって時点でどれも同じ。
速度なら無重力場・真空での光が今のところ一番速いといわれているんだから、光を通過・遮断に意味をもたせれば最速スパコンの出来上がり。

それを束ねて同時間上で意味を持たせれば束ねるほどに高速になる。ぜんぜんむつかしくない。

>>171
> 光を通過・遮断

ここが最大のボトルネックだな

うぅ。スルーされた。

>>173
互換性がなくなるのでx86に今から追加するのは無理

>>155
えーと。65816についてはどう思いますか?

>>175
エミュ作者泣かせ

>>176
開発者泣かせでもあったぞ!!!
6502の拡張版ながらもううんこ石

というわけでC62を推しておくw

機関車の形式に見えた俺。

>>178
由来がそうなんだけどね

>>173,174

つ【V25/V35】

>>180
わたしの知っているV35は単にV30に周辺を突っ込んだだけのものなんだが。
V30にしてもそんなドラスティックなISAの変更ってあったっけ？

レジスタウィンドウ追加というとAMD64以上のISAの変更になるのでいろいろ難しいと思うね。

http://www.atmarkit.co.jp/fembedded/07ipflex/ipflex01.html

なんですか？これ・・

単純な処理要素を結合して演算パイプラインを構成するらしい。
パイプラインは短時間で動的に再構成可能。FPGAの上あたりの細粒度並列処理を狙う。
リコンフィギャラブルアーキテクチャと言うらしい。最近そっち方向の研究が流行ってるみたいだ。
http://www.hpcc.jp/sacsis/2004/include/amano-sacsis.pdf

>>183
けっきょく信号処理にしか使えないワナ

リコンフィギャラブルアーキテクチャでリダクションマシンを組むというネタも
どこかにあったと思うんで、信号処理だけでもないようなキモス。

一般に露出してる実装例が信号処理用途なのは同意。

リダクションマシンやってる人、まだいるのかorz

やっぱり今やってる人は少ないのか。
面白そうなんで勉強してみようと思うんだけど、本が無いのがなぁ。
データフローとかだとマイナーなりに本が出てるから、アマチュアでも
やりやすいんだが。

Cellをパソコン用に改良して出てこないかな。

>>188
PowerPC750で十分だろ。
Altivecが使いたいなら7400シリーズだ

あえてCellのようなものがいいというなら、PowerPC405シリーズをたくさん買ってくるといい

>>188
GPGPUでいいんじゃないかと。

GPGPU用のAPIが整備されて、実際に使い物になるのはいつごろですか？

早くマトリックスの世界になって欲しいです

>>191
それを言い出したらCellはどうなのかとｗ

>>193
「一見関係ありそうで関係ない話を始める」

まったく関係の無い話を始めるアンタよりましｗ

でもこのままx86のCPUなんかがパソコンで定着しちゃったら嫌なんだ
ぜひCellをパソコン向けに改良して欲しい。

>>196
Cell自体は（現時点の実装を見る限り）「汎用CPU+複数DSP」みたいなもんで、古の「メディアプロセッサ付きPC」と
大して変わらない。「汎用CPU」の部分は言わずもがな、「複数DSP」の部分も用途ごとのライブラリやAPIが被さる
だろうから、よほどハードウェアに近い部分でプログラミングするのでない限り、プログラマから見る姿は大して今の
PCと変らないと思う。

エキゾチックなアーキテクチャでプログラムを楽しみたいなら別の方法があるし。
（手軽なところではGPGPUとか。）

GPGPU用のAPIが整備されて、実際に使い物になるのはいつごろですか？

そんな時期は来ないから待つだけムダ。

Cellはパソコン向けには遅すぎる

>>187
20年くらい前のアーキテクチャの本にちょろっと載ってるくらい

>>200
PPEを強力なものに変えればおｋ。
SPEの数を増やすのもいい。

頭で妄想するのは簡単なんだよ。黒字ベースに持っていけるだけの研究開発費出してくれ。

>>201
やっぱりそんなもんか....orz
ちまちま論文を拾っていくしかないか。

結局、売れるか売れないかなんだよねえ・・・
特定用途に特化するか汎用性を売りにするか・・・

>>204
昔の論文はあんまり電子化されてないぽ

>>202
PPEを強力にしてSPEは無くせばいいとおもうよ

>>206
紙のを拾う。
とりあえず情報処理学会誌あたりから始めるか。

>>202,207

>>189

>>207
それ、ただのPowerPC（970系）だろｗ

１０個SPEがくっついてるPPEを４つつなげれば最高？

Conroeにはcmp/test+jccのMacro-op fusionが実装されるもよう。
遅延分岐については不明だが。

データ取りこぼしがこわいからスレッド切り替え頻度↑↑になってきてるんだろうけど
そういうのこそメニーコアに振りたくなるよね
（ちなみに漏れのとこだと500-5000回/秒ぐらい）


（初代スレのコピペ）
969 名前：Socket774：04/11/21 00:39:07 ID:z+YuR4Tk
クロックがGHzの時代でも秒60回程度のタスク切り替えのコストが響きますか？

975 名前：Socket774[sage] 投稿日：04/11/21 05:38:18 ID:6OkCsAGH
>>969
それは昔のBSDの話かな?

Windowsなんて、ものすごい数のスレッドが蠢いているから、かなりの回数だよ。
パフォーマンスモニタでSystemのContext Switches/secを見てくださいな。

そこでマルチスレッドアーキテクチャですよ。
ハイパースレッドで2面待ちなんて甘い甘い。

マルチコアはアーキテクチャ的工夫がなくていまいち好きになれん

まあスレッドのスケジューリングに関する話ならおもしろいんだけど、
今のところその機構はCPUの外（人間、OS、コンパイラ、ランタイム）にあるからね。

コンパイラの自動並列化は、ほとんどの場合パフォーマンス向上につながらず、
また致命的バグが潜む可能性もあるので、結局人間最適化しているという現状。

今のプログラマに負担を強いるやり方ってのは自ずと限界がある。

例えるならILP（命令レベルの並列性）において、みんながみんな
アセンブラで命令の並べ替えをして最適化しなきゃいけないような
人間アウトオブイオーダー・人間スケジューリング、
な世界をイメージするとその滑稽さがよくわかる。

動的スケジューリングも投機実行も所詮小手先。
やっぱりハードウェアマルチスレッドですよ。

とつぶやきつつ、Denelcor HEP→Cray　MTA2と敗北の歴史を刻みンヌ....orz

http://www.watch.impress.co.jp/game/docs/20050316/ps311.jpg
これって結局クタラキの妄想だったんでしょ？

>>212
CC生成命令と分岐命令をセットにして処理するってことはALUに分岐用RS
をくっつけたような構成になるってことか。1回のCC生成に対して2回以上
参照したり、CC生成命令と分岐命令が離れている場合はMarco-op fusion
にならないんだろうけど、どう処理が変わってくるのか？
これも実装の1つの選択肢だとは思うけど、演算実行と分岐判定を別々にやる
場合に比べてのメリットがわからん。2つの命令が1つになることで
命令スループットがやや良くなるとは思うけどたかが知れているだろ。
Micro-opsに分解してせっかくシンプルなRISC的処理を行っているのに
複雑化していいことがあるとは思えん。

CELLに夢みてる馬鹿が多いようだが、CELLはCPU１個ででかい
タスク１個（ゲーム）を効率的に処理するためのカスタムチップ。
複数タスクをコンテキストスイッチしながら処理する汎用PCには
まったく向かない。

SPEを使わない前提ならアリかもしれないが、それならX86とかの
ほうがよほど高速。PPEの出る幕はない。

SPEを使う前提だとコンテキストスイッチングがネックになる。
SPEはコンテキストスイッチングしないで重いタスクを高速に処理
するという思想なんで、汎用レジスタが１２８本とか恐ろしい数を
持っている。

SPEを使わないタスクばかりならいいが、それだとX86に及ばない。
SPEを使うタスクばかりだと限られたリソースの奪い合いになる。
なぜならコンテキストスイッチしない設計思想だからな。

ゲームぐらいにしか使えんよ。そのかわりシングルタスクなら
高速だがな。

>>221
他人に説教する前に，自分が何を書いてるか読み直した方が良いかと思うす。
　　-----------------------
　　SPEはコンテキストスイッチングしないで重いタスクを高速に処理
　　するという思想なんで、汎用レジスタが１２８本とか恐ろしい数を
　　-----------------------
AltiVec有りのPowerPCアーキテクチャわ，整数・浮動小数点・ベクトルで各32本のレジスタを持っているす。
96本と128本が大違い。。。ってのわ，相当ピントのずれた思い込みかと(笑)
更に容量に換算すれSPEのレジスタわ2倍になるすけど，PPEわマルチスレッドのためにレジスタを2セット備えて
いるすから，結局何も変わらないことになるす。

>>221
Cellが使いものにならなければPOWERやPowerPCを使えばいいので、どうでも良い。

論点がかみ合ってない悪寒

> 今のプログラマに負担を強いるやり方ってのは自ずと限界がある。

いやソフトウェアエンジニアの立場から見ても今までプログラマはH/Wの進化に
甘えすぎだと思うんだが・・・

フリーランチの時代は終わった、ってやつですか。

そして有料ランチの代金は結局おまいらが払うことになる

>>222
GPUがだんだんグラフィック専用プロセッサから演算処理プロセッサになってきてるから
PCの場合CellのSPEに相当する部分としてをGPUが使われるようになる予感

レジスタなんかよりLSの256KBのほうがはるかにでかいわけだが

SPEはMMUなかった気がする。
だからプロセススイッチするならLS丸ごと書き換えなきゃまずいんでは。
全部PICでコンパイルしてるならぎりぎりちょろまかせそうな気もしなくもないが。

>>230
あるけどDMA用だから役に立たんな

>>220
まあ明らかに効果があるといったレベルのものでもなさそうだな。

ただ、CCはリネームしないとするならそこに余計な逐次性が入ってしまうわけで、
うれしい局面はあるのかもしれん。

>>222
SPEは何個あると思ってんだ。その分かけてみろバカ。

>>233
バカだもん

>>233
　　---------------------
　　その分かけてみろバカ。
　　---------------------
レジスタの退避わ，各SPEが持つLSに対して行えば良いすから，何個あろうとレイテンシわ一緒すけど(笑)

SPUについては直接アクセスできるメモリが256KBしかない時点で、汎用プロセッサと
同等の多重タスク処理を求めるのは無理と思われ。Ｆorthみたく実メモリモデルで極端に
小さなモジュールを組み合わせてシステムを組むような環境ならいけるかも知れんけど。

>>228
それは無いような。ＧＰＵメーカーとしてはグラフィック処理以外に演算リソースを喰われて
描画性能が落ちるのは嫌だろうし、（特にヲタ向けハイエンド機種。）インテルにしても自社
プロセッサの仕事が他に奪われるのを黙っては見ていないと思う。（実際、メディアプロセッサ
に対してMMXで対抗した。）

しかし段々とそうやって汎用プロセッサの役割が特定機能ユニットに分担されるようになって
いくと、コア部分はシングルパイプ・インオーダーのシンプルなものに戻っていくのかも。

>>236
　　------------------------
　　Ｆorthみたく実メモリモデルで極端に小さなモジュールを組み合わせてシステムを組むような環境
　　------------------------
そういうのが，CELL対応のコードに要求される「新しいプログラミングパラダイム｣ってヤツだと思われるす。
公開されているCELLの性能を見る限り，見返りも大きいんじゃないすかね。。。

今になってやっと、主記憶内のデータ領域⇔SPEのLS、
なことをスケジューリングするミドルウェアが出てくるなんて遅すぎ。
http://techon.nikkeibp.co.jp/article/NEWS/20060308/114415/

CELLは、パソコンで使うなら、グラフィックスアクセラレータでしょう。
hpのVisualize fx10というビデオカードは、ビデオカード側にRISCプロセッサ6個積んでたりしたよ。

パソコンで使ってｳﾏｰなのは、XBOX 360に積まれているCPUだと思う。
3.2GHzで3コア6スレッド実行で、メモリのバンド幅もじゃぶじゃぶ。

>>239
　　--------------------
　　XBOX 360に積まれているCPUだと思う。
　　--------------------
拡張命令を除くとCELL PPEと同じモノす。
2-issueでin-orderのプロセッサすけど，速いと思うすか？自作板の方わMeromで「幅｣の有り難味を
理解したと思っていたすけどね。。。

Xenonはアービタ周りが腐ってるので問題外

>>239
もしかしてCELL＋PowerVRを夢見ているのか？
……俺もちょっと惹かれる。

>>239
6個くらいで驚くな。
SGIのReality Engine2は12個のIntel860XPプロセッサを頂点変換のために
搭載している。昔の3DグラフィックスシステムではRISCプロセッサを同様に
搭載したものが多い。
http://www.gisparks.tas.gov.au/sgi/ge10.jpg

>>240
2-issueでも3コアあれば、トータルで6-issueだよ。
in-orderつっても、2スレッドで隠蔽だよ。
同じトータルで6-issueでも、3-issueの2コアよりも、効率が高いと思う。

>>243
i860がSGIのモンスター級のマシンで使われたことがあるのは知ってるけど、
Visualize fx10は、ごく普通のOpenGLのビデオカードなんですよ。

手作業でレジスタアロケーションしたりスケジューリングしたりするのも新しいプログラミングパラダイムかね

手間をプロセッサの外に出すっつー考え方はItaniumが実現したが、
それが性能に結びついているとは言い難いんだよなぁ。

>>245
その辺が自動で簡単にできるように，in-orderになってるんだと思うす。
SPEでのタスク分割わ，人力に頼らざるを得ないと思うすけど。。。

ハード技術０のソフト屋のたわごと

・CPUの高クロック化はプロセスの微細化によってのみもたらされるべきである
・シングルコアでインオーダ発行のシングルパイプラインのプロセサをマルチプロセサで使用する
・遅延分岐の採用により分岐によるインタロックを行わない→必然的にパイプライン段数は少なく留めるべきである

こんな考え方はものすごい時代遅れなんでしょうね。

アセンブラをいじって面白いのは非パイプラインのCISCかシングルパイプラインのRISCなんですよね。
レジスタリネーミング、アウトオブオーダ発行のスーパースケーラなんてアーキテクチャを見ると、もはや人間は高級言語だけ使えってことなんでしょうかね。

>>246
それを言うならRISCやVLIWだと思う。

ItaniumはIPCという観点からは性能でてると思うよ。あれだけピーキーなアーキテクチャの割には。

インテルの衰退とAMDの繁栄 Part26
http://pc7.2ch.net/test/read.cgi/jisaku/1142021769/373

373 名前：Socket774[sage] 投稿日：2006/03/12(日) 18:50:45 ID:wbaGuMo1
MACオタって懲りずにまだいるんだな。
書き方がキモ過ぎって未だに分かってないな。「わ」とか「るす」とかマジ超寒い。
自分ではイケてるって勘違いしてるんだろうなｗ
素でドン引きだって気づいてないんだろうな・・・哀れ。
何をアピールしたいのか知らんが、自分で「MACオタ」とか名乗っても
MACというブランドに自己同一視するなんて
ただの痛い奴にしか周りには見えないｗ

大体こいつなんでこのスレに書き込んでいるのか意味不明。
スレタイからしてAMD好きな奴の為にあるスレにしか読めないんだけど？
やってる事はそもそもスレ違いだしIntelスレに帰れ・・・と言いたい所だが
こいつIntel本スレでも嫌われてるから帰る居場所が無いｗ
キチガイだからIntel好きな奴にすら受け入れてもらえずに
仕方なくここでAMDの悪口書いてストレス発散とか痛すぎ。
あぁ、あとは次世代CPUスレで動向についての見識をひけらかして
優越感に浸ることも忘れてはダメだｗ

まぁAppleがx86に宗旨鞍替えした途端に金魚の糞のように追従して
今までは何だったの？と思わせるほど節操も無くPPCを捨てて
Intel至上主義に走るような馬鹿には何を言っても無駄かm9（＾Д＾）ﾌﾟｷﾞｬｰ!!

>>248
現状のプロセッサ設計はなるべくしてそうなっているので、こういう「べき」論はナンセンス。
せめて設計目標を先に挙げてくれ。「俺はこういうのが好き」というのではちょっと弱い。

>>248みたいにプロを装って妄想を書く社会を知らない消防はたちが悪い

大原雄介がまたシッタカぶりを披露しています。
ttp://pcweb.mycom.co.jp/articles/2006/03/11/idf3/

> レジスタ間のデータコピー(移動だけならRegister Renamingで済む)を司っているものと思われる

> 命令のRe-orderやRetirementがIn-orderなのはちょっと驚き。普通、ここはOut-of-Orderで実行する

> RetirementがIn-orderなのは、Memory AccessをOOOで実行する関係で、一度Queueingする必要があるから、と考えられる。

こいつはなんのためにリアタイアメントユニットがあるのか知らんのか。

> このプリフェッチのメカニズムはいろいろあるが、大抵はアクセスがあったアドレスから1Line分(キャッシュの1回に格納するデータ量の単位)を取り込むといったレベルで、
> アクセスパターンまで解析した例は(研究レベルではともかく商用プロセッサとしては)これまで聞いたことがない。

マルコフプリフェッチャーならPOWER2あたりで実装されとると思った。

商用プロセッサでRetirementがOut-of-OrderなCPUはありますか？

>>248
>・CPUの高クロック化はプロセスの微細化によってのみもたらされるべきである
妄想も大概に。

>・シングルコアでインオーダ発行のシングルパイプラインのプロセサをマルチプロセサで使用する
シングルコアでマルチプロセッサ？
チップの数(=パッケージの数)をどんどん増やすわけ？
マルチプロセッサシステムをうまく動かすのはソフトは大変よ？
本当にソフト屋？

>・遅延分岐の採用により分岐によるインタロックを行わない→必然的にパイプライン段数は少なく留めるべきである
ハードの実装によってディレイスロットの数がばらばらになってバイナリ互換性がなくなるけど。
MIPSもR4000の時点で既にインタロックするようになっているの知ってる？
本当にソフト屋？

>こんな考え方はものすごい時代遅れなんでしょうね。
でなきゃバカ。

>アセンブラをいじって面白いのは非パイプラインのCISCかシングルパイプラインのRISCなんですよね。
>レジスタリネーミング、アウトオブオーダ発行のスーパースケーラなんてアーキテクチャを見ると、もはや人間は高級言語だけ使えってことなんでしょうかね。
本当にソフト屋？

>>254
360/91

>>255
>>248で俺はSunのNiagaraみたいな奴を想像したんだが。
ああいうのは面白いと思う。
自作板向きではないが。

>>257
>>>248で俺はSunのNiagaraみたいな奴を想像したんだが。
Niagaraはまったく想像できないけどなぁ。シングルコアって言ってるし。
アレはメニィコアだよね。

ひょっとして、シンプルコアでマルチプロセッサといいたかったんだろうか？

寄ってたかって指摘したら可哀想だから、そっとスルーしてあげようよ。

一介のソフトウェアプログラマというつもりでソフト屋と書いたのですが
違う意味に受け取られたのでしょうか。
ソフトウェア側からしかCPUを使用したことがなく、
CPUに関してはプロフェッショナルどころか門外漢です。
勉強中の身なので指摘、批判、嘲笑、大いに歓迎です。

>>260
もちろんそういう意味で解釈したよ。
その上で「ソフト屋とは思えない」発言が目立つって話。

>>255=258=261さん、返答ありがとうございます
私の考えは
・現在のCPUクロックは速すぎる→500MHz程度で充分
・インタロックのない遅延分岐→パイプライン段数は変えない
・Unix系のプログラムを考えるとマルチプロセサ化はそれほど難しくない
現在の集積度ならパイプライン5段で500MHzの実現は可能という勝手な思い込みに基づいています。
R4000系のようにパイプライン段数を増やすと、
バイナリ互換性のために遅延スロット＋インタロックなんて
MIPSはMicroprocessor with interlocked pipeline stagesの略ですか？
なんてことになるからパイプラインの増加は好ましくないと思っています。

>>260ﾄﾞﾝﾏｲ
だいたいﾊｰﾄﾞもｿﾌﾄもどっちもなきゃ使い物にならないしね。
そういう見方も必要。

248＞もはや人間は高級言語だけ使えってことなんでしょうかね。
んなこたーない
なぜなら構造化ｱｾﾝﾌﾞﾗ(C)とそのｵﾌﾞｼﾞｪｸﾄ指向拡張(C++)は絶対に高級言語なんかじゃないから


どうか・・・そう考えてください、おねがいしますです。




ところで自動ｽﾚｯﾄﾞ分解ｺﾝﾊﾟｲﾗ>>216なんとかなってくれないものか・・・

>>262
そんな貴殿には、IA-64をオススメします。
低いクロック、短いパイプラインですよ。

>>240

おいおい、XBOX360の方は3コアでCELLは1コアだろ
基礎体力は段違いじゃないか？

CELLは軽いコントロールロジックをPPEで、重いメディア処理をSPEでという
分担構造。PPEとSPEが協調して「１つのタスク＝ゲーム」を動かす作り。
SPEはコードとデータをまとめてローカルの高速RAMに投げ込む構造だから
タスクスイッチなどまったく想定していない。ゆえに汎用には使えない。
360みたいにPPCが３コアとかなら使えなくもないが、それならそれでインテル
やAMDのほうが一枚も二枚も上手。

所詮ゲーム用CPUはゲーム用でしかない。

>>263
CPUを隠蔽するプログラミング言語という意味で高級言語といっただけです。
アセンブラでさえ仮想プロセサを操作したりするし。
>>264
IA-64はIA-32の命令セットを内包するんですよね。VLIWやレジスタの多さはそそられるけど…
IA-32の血が入っていなければいいのに。

自分の中でプロセサの順位付けは
1位　R3000系MIPS：命令セット、アーキテクチャともシンプルで好き
2位　ARM：かなり気に入っていますがレジスタが少なすぎ
3位　PPC：ちょっと複雑なのが気になりますが好印象。ただビッグエンディアンなのがひっかかる
4位　SPARC：触ったことないけどいつか触りたい。PPCと同じくビッグエンディアンがひっかかる
5位　MIPS64：命令セットは好きだけどパイプライン段数多いしインタロックはするし
6位　SH：遅延スロットがあるのは好きだけど、レジスタ2オペランド、レジスタ数、命令語長が×
7位　IA-16：最適化を行うのが面白かった。最初に触ったCPUなので憎めない
-------
IA-32：世の中カネですか
なんですよね。68K系もZ80系もIA-64も接点がなかったのでよく知りませんでした。
だれか私をビッグエンディアンに改宗してくださればPPCに走るんですけど。
バイエンディアンといいつつもリトルで使っているのを見たことないです。

>>267
> IA-64はIA-32の命令セットを内包するんですよね。
しない

>>267
PPCが上位にきているのがかなり意外だが、Alphaはどうよ。

Intelが本気でPowerPCで作ると今のCoreDuoを超えますか？

>>262
96コアで性能2倍のコプロセッサ、米企業が発表
http://www.itmedia.co.jp/news/articles/0410/07/news039.html

>>267
案外ARMが高いね

個人的には全命令条件実行可能なのは結構好きだけど
このスレでは変態命令セットとかさんざんな言われようだから

ところでIA16ってx86の16bitコードのこと？

どこでそういう方言を使っているのかなぁ。

>>268=269　>>272
ARMは得点も多いが失点も多い2位です。個性的ですよね。
理想追求的な旧MIPSと現実的なARMって感じですか。
PPCは失点が少なく得点も少ない3位です。
PPCは欠点らしい欠点が見当たらない。

R3000以外の順位の理由は私のレベルを反映してわりと明快というか単純で、
プログラマ側から見たインタフェースである命令セットが大きくモノをいってます。
あとは汎用レジスタ数、レジスタオペランド数、エンディアン。
ハードウェアは門外漢ですが、シンプルなアーキテクチャが好きです。
なので分岐予測よりも遅延スロットが好き。
MIPS64はかわいさあまってにくさ100倍といったところでしょうか。

手の届くところにAlphaはないのでちょっと分かりません。

>>271
疎結合のネットワーク分散コンピューティングと密結合のプロセサの中間といった感じですかね。
現在の民生バスを考えると緩結合はわりと現実的な解なんでしょうか。

>>273
パイプライン化する前の16bitCPUの8086や80286のつもりで書きました。
（80286はパイプラインだったっけ？）

>>268
> >>267
> > IA-64はIA-32の命令セットを内包するんですよね。
> しない

補足
中にPentiumII (位の速度のIA-32 の Core)がオマケで入っているだけ．
それも，Montecitoからなくなるみたいだけど．

>>275 (=268?)
私の無知からくる頓珍漢な発言を正してくださって、ありがとうございます。

低いクロック、短いパイプラインにIA-32はオマケですか。
意外とイイ奴かも。
食わず嫌いで視野を狭めるのはいけませんね。
反省します。

>>273
IA64が出来てからIA32という用語が生まれ、時たまIA16という言葉も使われる。
あんま使われないが、使われるには使われる。
使用例が見たいならぐぐれば？

>>275
それは良く聞く話なんだけど、ソースある?

インテルの資料には、x86をデコードしてIA64と同じ演算ユニット・レジスタで実行しているように書いてある。

もしPentiumIIのコアが丸々入っていて、さらに同じクロックで動いているのるのなら、
IA-32のコードの実行速度は、もっともっと速いはず。

>>278
動向を知らなさすぎ。
つうか聞く前にちょっとは調べろ、何がソースだ
信憑性云々をいちいち問う以前の話w
http://www.google.com/search?num=50&hl=ja&q=IA-32+itanium+%E3%82%A8%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3&lr=lang_ja

IA64は初期の頃はIA32との互換性を維持するたに専用のデコード・ユニットを実装してた。
今はIA-32 ELというエミュレーション。例えるならTransmetaのCMSみたいなの。

>>277
どこからそういう奇妙な方言を仕入れてきたか興味があっただけなんで。
google引いてもそういう意味で使われていることはほとんどないんだよね。

少なくともこういう場所で説明なしに使って理解してもらえる言葉じゃないと思うよ。

PowerPCがRISCでCISCよりも無駄がないと聞きます。

x86のCPUと比べてPowerPCの方が遅い理由はなんですか？
他の技術で負けているということなのでしょうか？

　..::::::,､_,､::: ::::: ::: :
　　/ﾖﾐﾞヽ)-､. :: ::::
─（ﾉ─ヽ.ｿ┴─

IA64の32実行用コアは動けばイイやという代物だったから
マッキンリーの頃だったかにはエミュレーションの方が早くなってしまって
早晩なくなるだろうと言われていたな…。IA64自体が危ういが。

>>281
�@x86もRISCだから
�APPCの方が総じてクロックが低いから
�BPPCで高速に動くようなコーディングをしてないから

このうちの複数の理由による。
�AについてはPPC陣営の悪い癖というか，一歩先を行く
機能によってクロックの足を引っ張るというのと，フラグシップ
PPCの市場がとても狭いというのが原因。

余談だが，組込(ゲーム機等)と被らないPPCは
ほぼMac専用で上に行くとPOWERがある為に
IBMにやる気がないというのもIntelチップ採用の原因とされる。

>>279
話の流れから明記しなくてもわかってもらえると思って書かなかったのだけど、
> それも，Montecitoからなくなるみたいだけど．
ではなくて
> 中にPentiumII (位の速度のIA-32 の Core)がオマケで入っているだけ．
の話について、です。

>>284
(位の速度のIA-32 の Core)
(位の速度の)

ぜんぜん話が違ってくるじゃないですか。
最初から、そう書いてくださいよ。
びっくりしたなぁ、もう。

>>281
同じIA-32でも、pentiumよりconroeの方がずっと速いだろ?
命令セットって、本質的にあんま関係ないんだよ

>>283
970は、2.7Ghzも出てる
K8と遜色ないし、デスクトップ・サーバー用CPUでは
クロック最高の部類だ

>>278
> それは良く聞く話なんだけど、ソースある?
> インテルの資料には、x86をデコードしてIA64と同じ演算ユニット・レジスタで実行しているように書いてある。

http://h21007.www2.hp.com/dspp/files/unprotected/itanium2.pdf

の，29ページに，

The Itanium 2 processor’s IA-32 translation hardware engine is an enhanced and in-order version
of the original Itanium’s IA-32 translation engine. It provides x86 compatibility with Katmai (Pentium 3)
and earlier processors. It will execute IA-32 applications and I/O drivers directly.

An important advance in the Itanium 2 processor that allowed a simplification from an out-of-order to
an in-order IA-32 translation engine was the design of a one-cycle LAGEN unit. The LAGEN unit forms
the address for IA-32 instructions. On the original Itanium processor, this function takes 2 cycles.

The performance of the Itanium 2 processor’s IA-32 engine is expected to be comparable with
a 300 MHz Pentium Pro.

とか書いてあるね．
ISA は Pentium3相当だが，速度はPenPro300MHz くらいか．
(すまん，うろ覚えで書いたもんでちょっと違った)

あと，31ページの図や，32ページの写真には，IA-32 Engine という箱が独立して書かれているので，
一応 IA-32 相当のものが入っていると言っていい，，，，，かな？

31ページの図はパイプラインのステージ順に描かれているので、
IA-32の命令はIA-64の命令に変換されてることを示しているね。

でも32ページのダイのレイアウトの図では、IA-32の面積が広くて、
IA-32のコアが丸ごと入りそうな気もするんだよね・・・。

既存のソフトウェア資産を重視しない用途ではitaniumやpowerが選ばれる。
x86よりパワフルだから。
x86である必要の無いゲーム機もpowerを採用。
PowerPCもG5はスペック相応の性能だと思う。
G4はモトローラの技術力とやる気の無さ。
クロック狂騒時代、IBMはやる気満々だったがモトローラがついていけず。
当時はIBMがローエンドのG3、モトローラがハイエンドのG4担当。
G4より高クロックのG3は許さない、これがアップルの意向でIBMはかなり怒っていた。
同じG3でもIBM製G3は銅配線、モトローラ製G3はアルミ配線、技術力の格差がはっきり
してきて三角関係は微妙な事態に突入。

>>290
性能じゃなくて、マーケティングとかスケーラビリヒティーだろ
ハイエンドでpowerやitaniumが使われるのは

なお、ハイエンドだとある面ではデスクトップ以上に
ソフトウェア資産が重要

>>290

つか。
見た目のスペック表のすごさばかり追及して、
クロックを高める妨げにしてしまうという、
モトローラの悪癖が出ただけだろ＞G4

Altivecのレジスタ数の多さ、高機能さが
クロック上昇を妨げるガンだった。
これを無理に高クロック化したから、発熱がすごいことになった。

モトローラのG4をハイエンド用に決めてなかったら、
G4より底力のあるG3機だってあり得たのにな。

以前、エンタープライズ系の、あるサーバソフトの開発をやっていたとき、
CPUのクロックを上げても、ほとんどパフォーマンスが上がらない
ということで困ったことがある。

そのソフトはコードの99%とCPU時間の99%を、
エラーチェックとエラー時の対処とエラーの記録
に費やしていると言っても過言ではなく、

コードサイズが巨大で命令のキャッシュのヒット率が低く、
分岐が多すぎて 分岐や分岐予測のためのCPU内のリソースは足りないしで、
それはもう悲惨だった。

そういうのだと、Itaniumのようなアーキテクチャだと、性能が出そうな気がするよ。

>>293
>そのソフトはコードの99%と
こっちはともかく

>CPU時間の99%を、
こっちはありえないのでは？

>エラーチェックとエラー時の対処とエラーの記録
>に費やしていると言っても過言ではなく、
ほとんど時間が異常系の実行に費やされているっていうのは
そもそもの設計自体に重大な欠陥があるとしか思えん。

そんなウンコソフトなら、どんなプロセッサを持ってきてもどうにもならんと思うが。

そうだけど、ハイエンドプロセッサのほうが分岐のテーブルとか
キャッシュがでかいから、大きなワークロードに向いてるのは事実

>>292
　　----------------------
　　Altivecのレジスタ数の多さ、高機能さがクロック上昇を妨げるガンだった。
　　----------------------
未だにこういうデマを信じてるヒトがいたことわ驚きす。
現実に同じ4-stageのパイプライン構成であるゆえに，同一プロセスの7400 G4をしのぐ動作クロックの
75x G3わ出なかったす。その上，結局AltiVecを採用する羽目になったG5わ，クロック競争を繰り広げる
x86プロセッサ並の動作クロックを達成しているす。

IBMも過去の誤りを悟って，CELL PPEやXbox360 PXに採用されている組込向け標準コアにAltiVecを
取り入れたというのに，時代遅れのお馬鹿さんわ未だに与太話を信じてるというのわ，実に滑稽な話す(笑)

>>296
ヒント： 世代交代

アップルも誤りを悟って、Altivecを捨ててIntelを採用したようですが

>>298
PPCアーキテクチャから離れられないものとして，Appleを舐めてかかったIBMわPPEベースのロードマップを
示し，IntelからわMeromを提示された。。。というのが事実す。
今となってわ，Jobsの正しさわ自明かと思うすけど。。。

>>299
ジョブズというかアップルのな

まぁMerom/Conroeが期待できる事が唯一の救い…

全部IBMのせいなんだｗ

>>296
>現実に同じ4-stageのパイプライン構成であるゆえに，同一プロセスの7400 G4をしのぐ動作クロックの
>75x G3わ出なかったす。

Appleが使ってくれないのにそのクラスのプロセッサを作っても意味がないので作らなかっただけ。

>>303
　　---------------------
　　Appleが使ってくれないのにそのクラスのプロセッサを作っても意味がないので作らなかっただけ。
　　---------------------
Intelへのスイッチを見れば判るように，Appleわ高性能プロセッサに選り好みわしないす(笑)
そもそもG4登場から，G5発表までの1999-2003の間，IBMとMotorolaからのプロセッサ購入数わ，ほぼ
半々だったって知ってるすか？

IntelがPowerPCを作ってくれればいいのに。

>>305
散々既出だが、何度でも言いたくなるな

>>303
高クロックの750がどうか知らないが、アップルへの出荷数は全体としては大したことないすよ
まあ言わなくてもわかるか

>>306
アップルとしてはG4より速いG3があると困るって事情もわかってるよな？

>>307
その「高クロックの750」の話をしているわけだが。
＃ちゃんと「そのクラスの」と断ってるだろ？

IBMはインテルにさほど遅れる事なく1GHzのG3の試作品を発表してたよ。
不孝な事にG3はモトローラとIBMの両方で作ってた。
無論同じ仕様である事が求められた。
ま、IBMはアップルと切れて今度はAMDとタッグ組む。
パソコン市場への野望いまだ衰えず。

>>308
　　----------------------
　　アップルとしてはG4より速いG3があると困るって事情もわかってるよな？
　　----------------------
まったく困らないどころか，現実に存在したす(笑)
例えば2001年初頭のラインナップ
　・Power Mac G4 (Digital Audio): PPC7410/466MHz, PPC7410/533MHz
　・iMac (early 2001): PPC750/500MHz, PPC750CXe/600MHz

2000年夏もG3とG4わ同一クロックだったす。

>>309
　　----------------------
　　IBMはインテルにさほど遅れる事なく1GHzのG3の試作品を発表してたよ。
　　----------------------
腐れルーマーに騙されてデマを信じ込んでるみたいすね(笑)
当時のIBMのGHz PowerPCわ研究用の試作品す。
http://www.research.ibm.com/arl/projects/guTS.html
http://www.research.ibm.com/arl/projects/rivina.html
見ての通り64-bitプロセッサの試作品でG3とわ何の関係も無いす。

馬鹿にわ区別がつかなかったみたいすけど，GuTSと同時にISSCC98で試作G3が発表されたというのわ事実す。
ただし，こんな代物す。
http://bizns.nikkeibp.co.jp/cgi-bin/search/wcs-bun.cgi?ID=44727&FORM=biztechnews
　　------------------------
　　技術的な内容としては、米IBM社や韓国Samsung Electronics社が、SOI（silicon-on-insulater）を採用した
　　製造技術を使ってプロセサの動作周波数を引き上げた成果を発表する点が目新しい。IBMは、0.12μm
　　（実効トランジスタ長）技術に銅配線およびSOIを採用して、PowerPCプロセサが580MHz動作したことや、
　　1GHz動作のPLL（phase locked loop）回路を発表する。
　　------------------------
このSOI採用で580MHzで動いたチップってのがG3す。この時期にSOIウェアを量産できる訳が無いってのわ
もちろんとして，PPC7410 G4が寿命末期にわ550-600MHz品が出荷されていたことを考慮すると，特に驚くべき
動作周波数とわ言えないことが判る筈す。

>>310
>例えば2001年初頭のラインナップ
>　・Power Mac G4 (Digital Audio): PPC7410/466MHz, PPC7410/533MHz
2001/01の時点で733MHzが発表されているようだが？
＃出荷は2月
>　・iMac (early 2001): PPC750/500MHz, PPC750CXe/600MHz
2月に発表された水玉が500MHz。

>2000年夏もG3とG4わ同一クロックだったす。
2000年夏だと
iMacDV+がG3/450MHz
PowerMacG4(GigaEthernet)がG4/500MHz
なんだけど？

ちっとでたらめにもほどがあるんでないの？

>>313
>>　・iMac (early 2001): PPC750/500MHz, PPC750CXe/600MHz
>2月に発表された水玉が500MHz。
上位機種は600MHz品があるけど、どちらにせよ733MHzは超えない。

>>313 さん
　　-------------------
　　2001/01の時点で733MHzが発表されているようだが？
　　＃出荷は2月
　　-------------------
Macユーザーなら，7450/733MHzわ事実上4-5月まで出荷されず，7450/667MHzわ出荷されたかされないか
噂にも上らないうちに消えたのを覚えているかと思うす。

>>314 さん
　　-------------------
　　iMacDV+がG3/450MHz
　　-------------------
iMac DV Spesial Editionってご存知すか？

>>315
> Macユーザーなら，7450/733MHzわ事実上4-5月まで出荷されず，7450/667MHzわ出荷されたかされないか
> 噂にも上らないうちに消えたのを覚えているかと思うす。

それは「アップルとしてはG4より速いG3があって困る」話の補強にしかならないわけですが。
アップルとしてはG4>G3を維持するつもりでいたわけですから。

> iMac DV Spesial Editionってご存知すか？
確かにそれは500MHzでした。
dualとsingleでどうにか差別化を計っていた時期ですか。
少なくとも逆転しては困るとアップルは考えていたのでしょう。

>>316
　　---------------------
　　少なくとも逆転しては困るとアップルは考えていたのでしょう。
　　---------------------
研究レベルでもG3の動作クロックわ600MHzに満たないという事実を示されても，G3の動作クロックわ
マーケティングで決定されたと主張するすか。。。

>>305
>>306
インテルがStrongARM、そしてXScaleを作ったら、
子供の喧嘩に大人が出てくる雰囲気あったな。
もうMIPSもSHもタジタジ。
もしインテルがPowerPC作ったら・・・

>>318
XscaleもMIPSもSHも目指してる市場の方向性が違うからなぁ…。

WindowsCE系に関して言うなら、SHはそもそもPocket/HandheldPC2000な
モデルにさえ採用されてない(夢カスでの大ダメージが効いた?)。
MIPSも2000モデルでは各機種(OS変更程度の)マイナーチェンジがほとんど。

2000でStrongARM機が出てくる頃には、ぶっちゃけ
まぁPDAを作ってるベンダーもだけど、PDA分野をMIPS/SHは見限ってたんじゃないかと…。

SH系は、CE云々以前に、もうエンベデッド市場しか見てないでしょ。
開発サイドはともかく、営業サイドとしてはの話ね。

>>320
SHは最初から組み込み主体ってかその為の16bitだし、
売りこみデモとしてのCE機だったと思うよ。

でも、売れていたならCE機続けただろうとも思う訳で。

>>321
まぁSHの迷走期とも被るからな。
上位の開発がSuperH社で
ルネサスと分離していたあの頃は
どういうロードマップだったんだか。

PDA系ってゆーとドラゴンボールを思い出すんだが
あれって今どうなったの？

モトローラがARM系採用してジ・エンドでなかったか

ARMのやつもドラゴンボールではある

>>317
> 研究レベルでもG3の動作クロックわ600MHzに満たないという事実を示されても
それは98年の発表

世界で最も売れたARMはGBAという事実

>>326
>>312に書いた通りす。見直すとISSCC99の間違いすけど(笑)
で，この脳内妄想のソースわ見つかったすか？
　　-------------------------
　　IBMはインテルにさほど遅れる事なく1GHzのG3の試作品を発表してたよ。
　　----------------------

326じゃないけど
http://72.14.203.104/search?q=cache:bgqw6UWkUukJ:http://too.site.ne.jp/Mac/Macintosh/MacMemo/MacMemo0107_12.html+ibm+powerpc+g3+1GHz&lr=lang_ja&hl=ja&ie=EUC-JP&output=html&client=nttx

G3の1GHzは2001年10月だね。
pentiumIIIから一年半送れか。
当時Mac系の雑誌で騒いでた記憶がある。

なんか思い出してきたよ。
iMacに1GHzのG3が載ると思っていたのに廉価版G3の500MHzくらいになっててがっくりした記憶が。

>>329
リンク先読んでなくて申し訳ないが、
たしか750FXは2001年10月発表で、2002年前半に700だか800MHz出荷開始、後半に1GHzまで到達するという話だった。
ま、でもSOI採用で驚いたのは覚えてる
SOI採用プロセッサの出荷では、2002年1月の7455 1GHzの方が早かったかも

>>331
結局G3 1GHzの採用例はあったの？

>>329, >>331
750FX自体わ，Microprocessor Forum 2001で発表され130nmプロセス + SOI + low-k絶縁体と当時最新の
製造技術を導入して2002年初頭に700MHzで登場，将来的にわ1GHzに。。。って触れ込みだったす。
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/FBEAAB9F7A288ED787256AE200622214
ちなみに同時期のG4わ180nmプロセス+SOIで1GHz品を量産中で2002年1月末に新型PowerMacと共に
発表されたす。http://www.eet.com/story/OEG20020129S0036

750FXの方わ，その後low-kプロセスの大失敗でさっぱりクロックが上がらず，こんな風に揶揄される羽目に。。。
http://www.theinquirer.net/?article=5927

頭わるそうな文章だな。

Conroe/Meromに対抗できるプロセッサはいつごろ出てくるのか

事あるごとに書かれる「Athlon64 90nm SOI」のSOIは
>>333のIBMの技術だから笑える

他にも採用しているのを全部書かないとダメじゃん
まあ2chで書いてるやつは、自社技術だと思いこんでるのかもしれないがｗ

おれはどうしてもSPARC64の高性能ぶりが気になってしかたがない。

ってかお前ら、荒らしに構う奴も荒らしっていう2chの掟を忘れたか？
いつまで糞オタいじってんの。

>>338
お前は何をいってるんすか？

>>290
この前PCWatchで後藤が面白い記事書いてて

>既存のソフトウェア資産を重視しない用途ではitaniumやpowerが選ばれる。
〜
>x86である必要の無いゲーム機もpowerを採用。

な感じで今までゲーム業界やってきた。

しかし最近は開発環境の高度化＆ライブラリの複雑化、肥大化。
開発者がハードに「やっと」こなれてくる頃には
すでにモデルチェンジ、このスタイルを継続するのはもはや無理だと
いう内容。

結局Intelがこれだけ労力払ってx86維持してるには
ちゃんと理由があって
そのお陰でゲーム業界のような惨状にはならんわけだ。

>>340
>結局Intelがこれだけ労力払ってx86維持してるには
>ちゃんと理由があって
>そのお陰でゲーム業界のような惨状にはならんわけだ。

前半は全くその通りだが、これはゲーム業界の責任
ItaniumもPOWERも、脈々と続くものがある
例えばPPC970全面廃止でCellのみに移行する、というわけじゃないだろ？
それこそ440や750や10xだってあるわけで。
Cellを採用しちゃったのは採用側の責任

>>341
同意しとく

>>341
Ｘ箱360のPPE（みたいなもの）x3onlyはまだｿﾌﾄ屋さん(MS)的なのね


よくもわるくも(ｴﾝﾀｰﾃｲﾒﾝﾄからは)ｱｳﾄｻｲﾀﾞｰなのかも？

ろくなソフトも書いたことがない奴がドリーム全開で作ったのがCellだから責めるのはかわいそう

>>344
プロセッサアーキテクトがソフトを書くモノという説わ，初耳す(笑)

Andy Glewはもともとプログラマだった

>>345
君はもうちょっと見聞を広めたほうがいいよ

てか、くたらぎってプロセサアーキテクトじゃないだろ

>>344
特段変なアーキテクチャだとは思えないんだが？
むしろ、手堅いと思う。

確かに、MPEG2動画48本同時デコード、を行う上では手堅い作りだな。

まぁ、Cellは汎用プロセサとして創ったのならあれだが、
ゲーム機プロセサとして創ったわけだから、あれはあれでいいんじゃね

>>351
そのゲームデベロッパーから不満がきているわけだが

そりゃまた何ゆえ？

ゲハ厨が湧いてくるのでCellだけは勘弁してください

cellって別にラディカルじゃないだろ
3.2Ghzってクロックはすごいが

>>355
Cellはクロック上げやすい設計だとか言ってたな、たしか。
ベースの970とは違う構造だったかもしれないけど。

ちなみに、Cellは5Ghz超で動いてることが発表されている。

>>356
970とは関係ない
なお、実行部分のパイプラインは970やpentium4より深い

cellが楽しみ

なのはGKと信者だけ

>>359
なのはGreat king!?
そうか、Cellはアニヲタかつ信者、つまりゴトーへのメッセージだったんだよ!!!!!

なのはGoto Kitakore

>>356
5GHzってCell全体だっけ？
SPEだけかとおもった

公開キタよ
ttp://opensparc.sunsource.net/nonav/index.html

ちょっと古いけど↓これってどうなん？
http://www.theregister.co.uk/2006/03/14/sun_rock_deets/

NAPを推進する米Azul、ワンチップに48コアを統合した「Vega 2」発表
http://pcweb.mycom.co.jp/news/2006/03/29/100.html

単純化の極北↓
http://www.eforth.com.tw/images/eP32_Core_030305.pdf

PS3は幻想
http://www.watch.impress.co.jp/game/docs/20060329/3dps3.htm

西川善司...って、Oh!Xの人やん。
なつかすいーなーw
(U)さんとかもなんか記事書いてほしいよ。
PS3特集号とか云って1号だけでも復活してくんないかな？

>>368
Uさんて植木さんか
懐かしいな　てかまだバンクにいるの？

>>367
去年の発表時からカタログ上のピーク性能と
実効性能の乖離が大きいプロセッサという話はあったじゃない。

そのベクタユニットを詰め込むために削った機能がでかすぎた、と。

>>370
いや、でもそのカタログスペックがそのまま発揮できると思い込んでる連中の多いことと来たら…
ゲハ板のCellスレとかPS3本スレ覗くとよくわかるよ

単純にビデオのエンコードやデコード、
ゲームエンジンや物理ミドルウェア走らせる分には
次世代機の中では抜きん出てるから心配するな。

>>369
Oh!Xのサイトも無くなったのか鎌田さんとこのリンクからも消えたみたい。

MPEGカードみたいにPCI-Exあたりの基盤にして
ハードウェアエンコーダ/デコーダにした方が
良さそうだ。

つーかコンシューマゲーム機ではデコーダはともかく
エンコーダとして使うことは無いだろ。

>>367
>PowerPC 970は命令実行にアウトオブオーダー(Out-of-Order)式に
>対応しており、命令間の依存性がない場合に
>順不同で命令を実行するような仕組みを持っているが
>PPEにこうした機構は盛り込まれていない。
>PowerPC 970“互換”であって“相当”ではないのだ。

何で元々あった機構を外したんだろうね。
ここの意図が見えない。
高クロックを狙うための単純化なのかもしれんが
これを外しちゃ駄目だろ。

>>375
コスト、消費電力。

many coreではOoOを外すのはよくある事

>>375
ゲームのシーケンスをリアルタイム制御するのに
アウトオブオーダーの挙動がじゃまだとか？

>>376
あ〜やっぱそれかなぁ。
確かにリッチな回路構成にすると高くなるし。
何より設計がメンドくさいし。

セルを眺めてるとやっぱり「詰め込みすぎ」な感じがするな。
逆に今よりユニットの数減らして単体での機能を強化してたら
もう少し期待できたかも（　´∀｀）y-~~

>>379
任天堂「リッチなのならすでにいっぱいあるから、うちは750VXあたりを使わせてもらうお　（　＾ω＾）」

Xbox360CPUの名前って"PX"なんだー

>>380
750系は地味に優秀だよなぁ

>>375
んまゲーム機ごときに970フルセットは勿体ねえ、と
IBMが割り切ったのかもしれない。

IBM的にはメインはPOWERシリーズで
Cellなんて余興みたいなモンだし。

>>374
PS2を内蔵したHDDレコーダがあったじゃない。
PS3を内蔵したHDDレコーダが出ると思われ。

>>375
OoOで性能がぐっと向上するのは、
古いCPUに合わせて最適化されたコードを実行するとき。

ゲーム機の場合は途中でコアを変えたりはしないので、
コンパイラがきちっと最適化したコードを出力すればいい。

>>384
それもあるけど、OoOが真価を発揮するのはメモリアクセスのレイテンシーが予測不可能なときだよ

キャッシュにヒットするかどうかまで、コンパイラに見積もらせることができるようになる、という目論見なのかもよ。

いや、違うか。

メモリアクセスのレイテンシは、OoOではなく、マルチスレッドで隠蔽する
ってことだと思う。

ネトバなみに深いパイプラインだから
2スレッド走らせても、パイプラインストールはかなりのもんだろ
cellのPPEは、SPEにクロックを無理して合わせただけって感じ
素直にSPEの半クロックにしとけばよかったのでは?と思う

>ネトバなみに深いパイプラインだから

ネトバ並みじゃなくてネトバ以上にPPEのパイプラインは深い。

IntelはPrescottで分岐予想機能を強化して
影響を極力抑えたが、結局同クロック動作の北森より性能落としてしまった。

CELLのPPEがベースの970より分岐予想を強化した
なんて話は皆無だから実効性能は悲惨な事になってるだろ。

Willametで22段、Prescottで31段だっけか。
つーことは35段あたりかそれ以上?

7448は7段だっけ？

クロック上げるためにパイプラインを深くするのは
CPU設計の定石だからなぁ。

ttp://pc.watch.impress.co.jp/docs/2006/0306/kaigai247.htm
まあ反省（？）したのかしらんが
インテルの次期CPUは１４ステージに短縮化。
これぐらいだったらパイプラインハザード起きても
リカバリが容易だが。

>>392
14段（笑）は浅くないぞ

>>393
今時のCPUじゃ浅い方だろ。
Z80とか大昔のCPUを基準にしてるのか？

あの糞複雑なIA-64でも、今は8段だな。

そりゃx86をμOp変換→スケジューリング行程がなけりゃ
8段にも出来るわな。

Itaniumは、その行程をコンパイラがVLIWするんだが
現状は期待したほど上手くいってないわけだが。

非x86だと10段以下も珍しくない、というか普通な気がする。

昨今RISKで急激な伸びみせてんのPower系だけじゃね

○RISC

Power6って、Power5と同等のパイプラインで
4〜5Ghzを目指す予定
イカス

14段（笑）

GPUのパイプラインなんか100段クラスだしょ？
20や30なんてしょぼいしょぼい

> 糞複雑なIA-64
？？？

>>402
分岐しないわけですが。

たとえばネットワークプロセッサなんかには汎用プロセッサよりもはるかに高性能なものもあるわけだが
マルチコアマルチスレッドで性能を稼ぐのは
アーキテクトの敗北宣言と言ってよろしいか

もっとましな餌もってこい。

>>406
んじゃシングルスレッドの性能あげてくれ

>>405
特定の処理に特化した専用回路が速いのは当然だろう。

ハードウェアMPEGエンコーダは、CPUよりも省電力で速いよ、
なんて言うようなものですよ。

>>405
つタイルプロセッサ
ttp://pcweb.mycom.co.jp/articles/2006/01/01/dataflow/

>>408
そう言うことだな。

細粒度のリコンフィギャラブルマシンこそアーキテクトの敗北だと思う。
FPGAと何が違うのか小一時間問い詰めたい。

>>405のネットワークプロセッサは、Niagaraみたいなやつだと思ってくれ
たしかに専用回路もついとるが

niagaraってサンのか？（現UltraSPARC T1 ）

マルチスレッドマルチコアで性能を稼いでる典型じゃないか。

>>409
TRIPSか
坂井さんも2DトポロジーでなTRIPSみたいなものをやっていたわけだが
命令のコミットの粒度が荒くなるのは良し悪しなのだな
特にTRIPSはストアバッファからデータを読むということもできなさそうだし
ドツボにはまると強烈に偽の逐次性がはいってしまう

>>412
そうだよ
ネットワークプロセッサだと192スレッドとかのもある

もっとも命令のコミットは通常のプロセッサでも問題になっているので
インテルなんかもP4ベースの論文も出しているのだが
(もっともインテルは性能評価にこっそりと非常に都合のいい前提を混ぜるのであんまり信用ならん)

どっちにしろ戦略的撤退にしか見えないようなものを栄光の勝利と主張しているような気がするのだ
>TRIPS

>>414
ああ、何が言いたいのかやっとわかった。
自然に存在する並列性を生かすのが敗北だと言うのなら敗北だろうな。

>>416
ﾌﾟ

読解力ゼロで悪かったな（ｗ

で、何が言いたいわけよ。
IAの代わりに使えば低消費電力で高性能ってか？

>>418
>>407

Niagaraなんてたいしたことねーよ、というHPの♪鯖との比較記事
http://h71028.www7.hp.com/ERC/cache/280124-0-0-0-121.html
↑のと同じ様な構成でのシステム価格はSun T2000の方が1.5〜2倍も高い。

anandでもT2000 serverのレポ上がってる
http://www.anandtech.com/it/
スループットも消費電力もDP Opteronに敗れてる

>>418
こっちも悪かった
ただ、スーパースカラマシン(とその前身のデータフローマシン)の題目が

プログラムに存在する並列性を自然に抽出する

だったもんで

http://japan.zdnet.com/column/interview/story/0,2000053136,20097277,00.htm
Power6の中の人のお言葉
「重要なのは、システムのスループットを維持することと、
　シングルコアのパフォーマンスを維持することとのバランスです。」
「そういったこと（Niagara）を推し進めて、パフォーマンスの1つの
　面に特化しすぎると、大抵は厄介な事態に陥るということです。
　その他のことをすべて無視できるほど、世の中は甘くないのです。」

http://news.com.com/Talkin+about+Intels+next+generation/2008-1006_3-6047173.html?tag=st.num
Core Duoの中の人のお言葉
「マルチタスクやマルチスレッド環境では高い処理性能を実現できても、
　シングルスレッド環境でやってきた多数のソフトウェア開発者から
　"前の方が良かった"と文句を言われるだろう。」

>>410
FPGAだと、配線遅延のせいでクロックがむちゃくちゃ低くなる
少なくとも、プロセスルールを微細化させてもクロオクがあがらない
ゆえにリコンフィギュアラブルプロセサッサの登場らしい

まぁsunもｼﾝｸﾞﾙｺｱ性能↑完全に切り捨てたわけじゃないしね
Rockで自社開発に戻すorまだ富士通SPARC64かは？だけど

Rockも、Ultra SPARC T1と似たようなアーキティクチャらしい
16個のコアがあって、4コアでL1をキャッシュを共有
そして今回もOOOはなし
T1の性能もあんまよくないし、富士通とAMDにCPUは
任せたほうがいいと思う

（´-`）.｡oO（富士Sun誕生まだかなぁ…）

リコンフィギュアラブルも近いうちにスタティックデータフローになるさ

リコンフィギュアラブルプロセッサがFPGAの代替になるならうれしいね。
今のところは、偶然使えた用途以外では比較にならんでしょ。

難しい事一転じゃねぇーよ

256命令同時発行cpu作っときゃｽｹﾞ^んだろ？

そうだそうにﾁｹﾞｪｰﾈｪｰ

cellが最高です。

確かに扱い難さは最高だ

>>430
ﾊｲﾊｲ、Cellﾊｽｺﾞｲﾈ

ﾊｲﾊｲ、CellLightはもっとｽｺﾞｲです。

世の女が目の敵にするくらいだしな

CELL搭載のPCI Expressカードが出てくれればいいと思うんですけどね。
動画のエンコードやデコード等、いろいろ使い道はあるでしょう。

あとゲームの物理計算とかにも使える。

ClearSpeedのSIMDなプロセッサがあるじゃないか、既に。

汎用性を無視すれば特定用途で汎用CPUより一桁〜二桁は速くなるのはあたりまえ。
cellは汎用と専用の丁度中間か。

二次ｷｬｯｼｭを追いやって1次ｷｬｯｼｭを2MBにすれば速いんじゃねぇ？

うはっｗ天才ｵﾚｗｗｗｗｗｗｗｗｗｗｗｗｗ

なんか、むかしのPA-RISCがそんな設計だったような。

データ512K、命令1Mだっけか。
逆だったか?

米ＩＢＭ、消費電力4分の1の新型ＭＰＵ・能力は10倍
http://www.nikkei.co.jp/news/kaigai/20060405AT2M0500V05042006.html

>>441
一番多いときで、命令768KB、データ1.5MBだった
PA-RISCって昔は速かったんだけどね

昔のようにチップに積めるトランジスタとかの制約があるなら別だが、現在だとメリットねーんじゃね。
たとえば、2MBの１次キャッシュと2MBの2次キャッシュだと、結局、レイテンシや速度も同じになるだろ。

いや、間に挟まない分、レイテンシは若干有利か・・・

>>444
L1に高速なトランジスタや回路を用意するからL1とL2には差が出る(というか付ける)。
同じ回路で組めばL1もL2も一緒の速度になる。

つまり、L2止めて大容量L1って話は、
容量が少なくなるけど高速なメモリが良いのか、それとも多少とろくても大容量のメモリが良いのかってな
何時ものお話な訳だ。

>>444-445
今2GHz台なんかで2MBの１次ｷｬｯｼｭにしたら、たぶんﾚｲﾃﾝｼ大きいのしか作れなくて余裕で氏ねる

ウェディングピーチとなんか関係あるのか

Alphaも21164でつけたオンチップL2を21264で外したこともあるし、この先何があるかわからんわな。
マルチコワだとL1オンリーに戻るやつが出てくるかもしれん。

あとL1の必要性はレイテンシー以外にもポート数とか連想度とかいろいろあるどグヘヘ。

> マルチコワ

なんかテニス選手の名前みたいだ

L1とL2ってﾄﾗﾝｼﾞｽﾀの構造違うﾉｶ？
本当か？
本当だな？
本当なんだな？

L6キャッシュぐらいまで作れば、メインメモリいらなくね？

L10キャッシュぐらいまで作れば、ハードディスクいらなくね？

>>450
違うでしょ。

L1→速度重視
L2→サイズ重視

ごめん。
L2→サイズと低消費電力を重視

>>451
将来的に貫通電極でチップにメモリ直付けしれば、いらねーんじゃね

>>450
SRAMセルは基本的に同じだが、制御部が全然違う
ポート数とかセットアソシエティブ数とか
極端なこといえば、キャッシュもレジスタも
同じ6トランジスタSRAM

じゃあ全部L1の構造だけで構成すればｲｲジャマイカ！！！！！！

うわぁー！解決ｼﾁｬｯﾀﾖーーーーーヨヨヨ

>>457
レイテンシのでかいL1になるけどな。それもありかもしれんが。

自転車の黎明期に車輪をどんどん馬鹿でかくした時期があったが
結局現在のバランスに落ち着いてしまった。何事もバランスが肝心。

L1けっこう電気食うぞ

L1なんか64bitなんだから64kbで十分なんじゃないのか？

Conroe/2.4GHzの続報す。何故かNICがダメでCPU喰いまくりだったのを、とりあえず外して結果が
まともになってきたとか。。。
http://vic.expreview.com/read.php?2

Intel次世代スレッドと間違えたす。

RISCスレにそれ書くとはわざとなら喧嘩売ってるとしか思えない行為だ

>>460
良く分からんが、それって関係あるの？
bitとbiteだから合わせる意味無いんじゃ？

>>463
志村ースレタイスレタイ

根拠を示せないカスは情報操作が目的か

Sunが200人のSPARCエンジニアをレイオフ
http://www.theregister.co.uk/2006/04/07/sun_jupiter_gone
> SunはNiagaraをベースにして，Rockプロセサに接続し，通信処理などを
> オフロードするJupitorというプロセサを開発しているという噂だったのですが，
> このプロジェクトがキャンセルされたようです。これに伴い，他のプロジェクト
> などに人を移したりしたが，最終的には200人は首ということになったようです。
> 本筋のNiagaraとRockプロセサの開発路線には変更は無いとのことです。

>>467
富士通あたり引き取らないのかねえ。

ひきとらんだろ

US5がキャンセルになったときも大勢馘になっていたと思ったが
まだそんなに残っていたのか

たしかL1Dキャッシュのレイテンシ
北森：2(cycle)
プ：3(cycle)
あってる？＞ALL

ｱｯ�d

プレスコのL1はレイテンシ4だよ。

UltraSPARC T2 テープアウト
http://enterprise.watch.impress.co.jp/cda/foreign/2006/04/13/7616.html
http://pcweb.mycom.co.jp/news/2006/04/13/101.html

ちなみにCELLはレイテンシ8
遅すぎです

>>474
設計完了とテープアウトわ違うす。

Sun Microsystems Completes Design Tape-Out for Next-Generation,
Breakthrough UltraSPARC T2 CoolThreads Processor

Sun Ray 2/2FS、なんかいいなぁ

>>476
何とか言ってみろよwww

>>476
あなたのいうテープアウトの意味を教えてください。

どうも常識とは違う使い方をしているようですが・・・。

>>476
ttp://www.sun.com/smi/Press/sunflash/2006-04/sunflash.20060412.2.xml?cid=155
| Sun Microsystems Completes Design Tape-Out for Next-Generation,
| Breakthrough UltraSPARC T2 CoolThreads Processor

あれ、シリコン作って最初の製品が出てくるのは何つーんだっけ。
ロールアウトだっけ?

ファーストシリコンじゃねーの。

>>477-481
元記事読まずに失礼したす。しかし通常設計完了ってのわ、この位の段階だと思うす。
http://www.designchain.com/coverstory.asp?issue=spring03
テープアウトってのわ、これを製造用のマスクデータにして、工場に送れるようになった段階す。

Cellの技術を使ったCPUがパソコンに入る事はこの先期待できますか？

F1マシンが公道を走る事はこの先期待できますか？

>>485
Cellを開発した会社（のいずれか）が作ったCPUがパソコンに入る事があるならな

> テープアウトってのわ、これを製造用のマスクデータにして、工場に送れるようになった段階す。

違うでしょ

ゴールデンサンプル

百済ない言葉の話になるだけだから糞はスルーしろとあれほど（ｒ

tape out

　完成したLSIのレイアウトデータを磁気テープに書き込み、拡散プロセス用のマスクのデータをLSI製造部門に出荷することをいう。この後、拡散プロセスが行なわれて実際のチップが作成される。つまりテープアウトは、LSIの設計が完了したことを意味する。

　いったんテープアウトされると、設計にバグがあっても修正をすることができない。このため、もう一度テープアウトからやり直すしかない。


結局のところ、CAD屋がFabにデータを送ることということでいいのか？

まあ、いまどき磁気テープなんかでやりとりしないけどな

テープアウトについては
ttp://v-t.jp/premier/index.php?mode=show&UID=1117037100
の3.1.4を見れ。

>>493
こりゃあ、すごい。

UID付きだけど大丈夫なん？

UIDはUserIDではなくUniqueIDの略だと思うよ。

面白すぎて3時間も飛んだじゃねーか(w

みんな読むのに夢中なのか?

http://pc.watch.impress.co.jp/docs/2006/0419/kaigai262.htm
パイプラインたとえ、誰かくわしくかいせつキボンヌ

嶋はアーキテクトとしては評価してないというかダメぽと思っている

後世の人間だから言えること。
短時間にTr制限下でいかにつめこむかという現場じゃ
あるべきアーキテクチャを考えられない、
その訓練ができないってのはしょうがないんでは？

当時は、定量的なアプローチとか、そういう概念がなかったじゃないか。
まずは必要な機能を、いかに詰め込むか、ということが重要だったわけで。

Z80までの業績は評価できると思うが
それ以降がなぁ…

>>499
http://www8.ocn.ne.jp/~audiofan/oldies/single/single_ventures/002-pipeline.html

厳しいリソースの制約内でやりくりするのは非常に上手かったと思うのだが
上だけを見て山を登っている感も否定できない気がする

過疎過疎ってハァニィ〜age

CELLを見たときこれは駄目だと思った。私ならMIPS辺りを16個に
L2キャッシュを2Mぐらい積んで誤魔化しておくのだが、それなら少しは汎用性があり
そうだ。しかし、ゲーム専用かTV組込みLSIとしてみると魅力があるのかしら？
その道の専門家は如何でしょうか。

MIPSが16個だとシングルスレッドが遅いじゃろ

ゲームならXbox360のCPUのほうが良さげというのが多数派だけどね
ストリーム処理だとまたかわってくるかも知らんが

ゲームはシングルスレッドが遅くても構わないでしょう。

汎用CPUだと、キャッシュの制御やキャッシュの同期が
めんどくさいから、CELLはああいう形にしたんだろ
そもそも、MIPSコアで4waySIMDつけたら、16コアも入らない

>>508
xbox360のCPUが一番無難な感じだよな

用途を絞ると、キャッシュみたいな非明示的メモリ管理より
明示的メモリ管理のほうが効率良いわけで
cellのアプローチは正しいんじゃないかと思う

そういえばLSってキャッシュと違って明らかに発熱してるよな
http://pc.watch.impress.co.jp/docs/2005/0208/kaigaip051.jpg
キャッシュライン単位のアクセスと違ってコードによっては総なめになるからか?

>>512
じゃねーかな?
あと3.2Ghzって実行ユニットに合わせて
高クロックで動作してるとか

逐次処理主体のゲームこそシングルスレッド性能が大事だろ。

>>511
うまくフィットするアプリケーションならいいのだが
LSの256KBというサイズがあまりにも微妙なのだ

キャッシュならワークセットがオーバーしたところでゆるやかに性能が低下してゆくだけだが

>>514
エロゲーのシナリオ分岐じゃねーんだからさ。

大半のゲームでの重い処理は、グラフィックスなわけで、
そういうのは分散処理がやりやすいほうだよ。

CELLはSIMDだったっかしら夫々別に動くみたいだったが、
SIMD系の命令があるというだけですよね？
ゲームも御絵描きが主な仕事とすると、シングルスレド云々は
既存のゲームを前提にした話で意味のある発言ではないようなので
勝手に却下させていただきます。
CELLのように異種のCPUが別個に乗っているのと
多少遅くても同じ空間で統一して走るCPUが乗っているのと
どちらが使いやすいのでしょうか？
CELLみたいな孤立論理空間のCPUで御絵描きをうまく分担して実行するのは
面倒では無いかと思うのですが？

>>516
これから物理計算とAIが重くなってくるわけだが

物理計算はシングルスレッド性能が大切なんですか。

ﾜﾛｽｗ
さすがだ

コンセプトは悪くないが256KBは確かに微妙。

コア９つなんて明らかに多杉。ほとんどのアプリでは１／３も使われずに終わるだろう。
分散並列すれば速いのは猿でも分かる話で、それを人間の手で仕分けしてては駄目
http://2ch.dumper.jp/0001734092/

非対称マルチプロセッサというのは使い方が良ければ素晴らしい性能を発揮する。
ただし、以下の条件が揃っている必要がある。
1.メモリ空間の制約がないこと。お互いにメモリを共有できること。
2.非対称マルチプロセッサに対応した強力なデバッガがあること。
3.OSによるセンスの良い抽象化がされて簡単に使えること
Cellはこの3つのいずれもが欠けている。
http://hobby8.2ch.net/test/read.cgi/sony/1133737894/

それにしたってSPEのDMAキックとか、全てPPEに任してるわけで、コリャまた並列化
ライブラリやらなんやらを早めに提供しないと、PS2のEEと一緒で最初にコケるぞ…。
並列化はプログラマにとって、不要な苦痛ですな。プログラマは本来の問題を解決する
アルゴリズムなどの考案に専念して、並列化という言わば「無駄」な作業に時間を割きたくない
http://72.14.203.104/search?q=cache:dM7OyiI12e8J:sunset01.bne.jp/blog/index.php

WindowsやUNIXでマルチスレッドプログラムを組んだ経験のある方なら分かるかと思うが、
他に手段があるのであれば、なるべくマルチスレッド化は避けて通ろうとするだろう。
スレッドを生成するだけなら、関数一発で間単だが、一旦走り始めたスレッドを管理
するのはなかなか大変だ。C,C++言語（だけでなく現状の大半の言語）はもともと
逐次的に処理することを想定しているため並列的な処理に向いているとはいえない。
真面目にこういったことをゼロから構築していくには相当な努力と優秀な人材が必須となり、
中〜小規模な会社ではあまり現実的とはいえないだろう。
http://blog.so-net.ne.jp/pcgame/2005-03-28

ゲームの場合は調整などの後工程が作品の品質を決める。ここで、処理が遅いからといって
SPEの割り当て数を変えようものなら大変な作り直しになりかねない。私がメガドライブや
サターンを買ったのは、そのハード性能にわくわくできたからだ。夢を見ることができたからだ。
PS3にはそういった夢もない。
http://homepage1.nifty.com/bee/diary/20055.html

マルチコア・マルチスレッドは、当初は期待通りの効果を挙げることはできないとも述べている。
描画処理は並列化のいい見本となるが、ゲームプログラムそのものを並列化することは
予想以上に難しいことであり、このことが今後のゲーム開発をさらに難しくしていくことになるだろう
http://blog.so-net.ne.jp/pcgame/2005-08-23

火花がキャラクターに衝突するとか、水面の波の高さによってキャラクターの乗っている
船が揺れるといった、ゲームシステムに直接影響を与えるエフェクトは並列化できない。
PhysXを開発したAGEIAでは、物理効果を適応する範囲を複数のグループに分類する
手法を提案している。各グループは並列化の適応度によって分類されており、ゲームロジック
そのものへの関わり具合とリアルタイム性が高くなるほど並列化適応度は低くなる。
結局、CPUコアを10個積んだとしても現状ではコアを全て生かし切ることは難しく
今のところは3,4個あれば充分事足りると思われる
http://blog.so-net.ne.jp/pcgame/2005-09-15

取り合えず、定番となるデザインパターンが固まらないと、車輪の再発明大会が始まりそう
http://www.igda.jp/modules/newbb/viewtopic.php?topic_id=175&forum=8&post_id=851

そもそもゲーム処理というものは逐次的に処理しなくてはいけない部分が多いため、
分散コンピューティングに適さないということ。
http://blog.freelance.ne.jp/mizusawa/archives/200511/14_2017.php

今月号のアスキーで大原がCellを糞味噌にけなしてますぜ。
大原「この前のプロセッサフォーラムでもCellのソフトウェア環境の話がずいぶんあったんですよ。
すると、今はPPEの上でどうにか動かしますよと、1個か2個SPEを使うぶんには割と問題ないわけ、
ところが、そこから先になるとOSのレベルで何にもないんでドライバも含めて、全部アプリケーションで
書かないといけない、それを全部統合するようなOSという話はまだIBMですらコンセプトレベルでしか
提示されていないところを見ると、何もないんだな実体は」
後藤「東芝がSPEのスケジューリングの話をしていた。だからラボの中ではこういうことをやっているよと」
大原「けど、それが製品のクォリティになっているかというと全然違う話で」
http://game10.2ch.net/test/read.cgi/ghard/1133854327/

�@PS3の演算能力はXBOXより優れている。しかしソフトウェア技術が追いつかないため
　 見た目的にはXBOXと変わらない。HDTVで表示すると、720pへの伸張の影響で
　 XBOX360よりも画質が劣る可能性が高い。MGS4のような720ｐで作っているやつは別。
�A�@での演算能力は浮動小数点計算であり、AIなどについてはボトルネックが発生するが、
　 それでもXBOX360と比べれば高速に動かすことは可能である。しかしチップ数が過多なので、
　 同期処理に手間取りフレームレートが上がらない不具合も発生している模様。
�BXBOX360と違いシェーダーは殆ど使われない。これはPGの練度の問題。
　 しかしRanderwareなどXBOXに勝るとも劣らないクォリティの高いミドルウェアがあるので
　 ぱっと見では差は感じられないだろう。当然HDRも最初から切り捨てているが、
　 これも表現上の工夫で突破する腹づもりである。これは、機材が届くのが遅いため、
　 検証期間が短いことに起因する。事実、多くの社員をPS3のために入社させたが
　 まともに活用できない企業が続出した。
http://game10.2ch.net/test/read.cgi/ghard/1139634207/

『何人か開発者は、PS3の開発が難し過ぎた為、直ぐに逃げ出してしまいました。
　原因は、10個のプロセッサーやシェーダーetcに非常に手を焼いていて、
　ゲームに重要な部分はサッパリだからです。』
http://dona.dip.jp/modules/wordpress1/index.php?p=649

なんだこいつ

業界ではCellは「奇形児」って呼ばれてる。
Xenonは話題にすらならないが。

面白おかしく読ませてもらった。
SCEは単純にPS2の強化版を360よりも先に出せば良かったのに・・・。

自由にアクセスできるのが256KBで、後はレイテンシの長い外部メモリからロード…
MS-DOSの640KB縛りとEMSみたいだな。

xbox360とCELLわ同じ組み込み用PowerPCコア(P-X, PPE)を使ってるのにCELLを叩くヒトがいるのわ､
何故なんすかね(笑)
業界の古株でハードウェアオタクとしても有名な古川元MS-J会長のコメントす。
http://spaces.msn.com/furukawablog/PersonalSpace.aspx?_c11_blogpart_blogpart=blogview&_c=blogpart&partqs=amonth%3d4%26ayear%3d2006
　　-----------------------
　　さて、NAB2006では素晴らしいモノを沢山見つけたのだけど、最大の収穫でとにかく驚愕、つまり顎を
　　はずすほど驚いたのが...SONY殿がプライベート展示会場に設置していたCellコンピューティングによる
　　映像の世界であります。招待者のみへの展示でプレス非公開、写真撮影禁止という条件ですが..ご担当
　　の方に自分の眼で見たことはブログに書いてしまいますけれど、良いですね？と事前に確認を取って
　　あるので、言葉で説明いたしましょう。
　　-----------------------
詳細わ､リンク先をどうぞ。

何で同じコアを使ってるからと言う理由で同じ扱いをせねばならんのか。
構成が全然違うんだから評価も違って当然だろ。
PowerPC信者にはわからんことかもしれんけど。

マルチコアを活かそうとすればするほどパフォーマンスが落ちる箱○のXenon（+GPU）は論外

http://blogs.dion.ne.jp/arere/archives/1947629.html

>>523
>そもそもゲーム処理というものは逐次的に処理しなくてはいけない部分が多いため、
>分散コンピューティングに適さないということ。
(ﾟДﾟ)ﾊｧ?

>>529
ジョブズがCell叩いてたぜ。

PS1=R3000(MIPS)+ｸｯﾀﾘ(SONY)
PS2=R5900(MIPS)+ｸｯﾀﾘ(SONY)
PS3=PowerPC970(IBM)+GeForce7800(NVIDIA)+ｸｯﾀﾘ(SONY)

∴ SONY独自技術=ｸｯﾀﾘ

>>533 さん
CELL用のコードにわ､新しいプログラミングパラダイムが必要なので､既存のコードを高速に走らせる必要が
あったり､移植が簡易だったりする必要があるPCにわ不向きだからす。

>>534 さん
CELLのPowerPCコアわ､POWER4/PPC970とわ別の系統のモノす。

>>534
ソニー板とかでも見たけど、貼りすぎす。

難しいヘテロなマルチコアに挑戦したり、突貫工事のマルチコアを
デッチ上げるくらいなら、Athlon64 X2やCore Duoのマイナーチェンジ
バージョンでも作ってもらった方が良かったんじゃないかなあ。
レボがバカ売れするとは思えないけど、終わってみれば
採算とれたのはレボだけという状況になったりして。

>>537
Athlon64 X2じゃ発熱でかすぎ
Core Duoも似たようなもん

トップスピードを出すには汎用コアじゃ無理だしな
Athlon64やCoreでCellやXenonの理論的な最高と同等性能を出すためには、どのくらいのコストとクロックいると思う？

東芝の工場が抜けている。
結局ソニーにはクタタンのハッタリしかない。

ＣＥＬＬの話題になるとＣＰＵアーキテクチャについて語られない(語れないｗ)件

>>538
そりゃ同じ"理論値"を達成しようとしたらとんでもないことになるだろうよ。

次世代機で評価できるのは、果敢にマルチコアに挑戦したその心意気だけだ。

>>541
>次世代機で評価できるのは、果敢にマルチコアに挑戦したその心意気だけだ。

だが、それがいい。


冗談じゃなくて、テレビゲームなんてスペックを誇示する勝負みたいなもんだしな。
テレビゲーム市場が大きくなれたのも、PCとは一風（方向性）違った性能をユーザーがなんとなく受け止めてたからだと思う

ソフト開発がやりやすくなったとしても、Athlon64 X2並みのCPU採用！じゃインパクトないだろ

インテルも明らかに性能の劣るペンDをハッタリで誤魔化して売ってただろに

ＩＮＴＥＬやＡＭＤのＰＣ向け4コア8コアＣＰＵってどんな風に使うんだ？

>>544
Intelも頑張ってツール配布してるす。
http://www.intel.com/cd/software/products/asmo-na/eng/272688.htm
　　---------------------
　　Platform Support

* Supports Windows*, Linux*, and Mac OS*
* Supports 32-bit applications on IA-32 and Intel? EM64T platforms, and 64-bit applications on
　　　Itanium? 2 and Intel? EM64T platforms
* Supports Intel, Microsoft and GNU compilers
　　---------------------

>>542
そのスペックをPS2みたいに5〜6年で引き出せるならまだいいよ。
（できれば2〜3年で引き出してもらいたいが）
現状で伝わってくる情報だと、XBOX360は改善の兆しがないし、
PS3はまだ実機で動かせるロンチタイトルを公開できない。

最近一般誌で、見通しが明るくない次世代ゲーム機業界、
対称的に好調な携帯ゲーム、そのような記事をよく見かける。
世界的マーケットではまだ伸びるかもしれんが本当に大丈夫なんかいな。

>>545
あ、そうじゃなくて
ゲーム？エンコ？何に4コア使うのってこと

>>547
XeonMPやOnpteron8xxシリーズに聞いてごらんなさい

さっぱり理解できないが、Intelの中の人曰く「RMS」
http://www.itmedia.co.jp/news/articles/0402/20/news047.html
http://pc.watch.impress.co.jp/docs/2005/0112/kaigai147.htm

>>548
個人レベルでも大規模データベースや基幹系アプリケーションや流体力学計算を扱えってか？

>>549
Windows信者やLinux(x86版)厨である限り、インテルに流されるままよｗ

>>549
　　----------------
　　個人レベルでも大規模データベースや基幹系アプリケーションや流体力学計算を扱えってか？
　　----------------
ゲームやgoogleで､あなたもその手のアプリの恩恵にあずかっているかと思うす。

>>551
社会全体で役に立ってるのは当たりまえ。
個人で運用する意義・場面って？

欲しくないなら買わなければいいのでは。

いつも思うがコンシューマと業務系を混同して話す人が多すぎ

ゲーム機とPCを混同してる話人もたくさんいるよね

それはMACオタだからしょうがない

個人で云々の話になっちゃうと、今出てるCPUのほとんどが必要ないものになっちゃうよ

PCで大きなパワーが必要な場面はFPSゲーム、
動画エンコード・トランスコードやデジカメの画像処理くらいでしょ。
WSも含めると、グラフィックデザイン・DTP・DAW・レンダリング・CAD・コンパイル等等。

Longhornで導入するはずだった、ファイルシステムとデータベース管理・検索を
統合したWinFSなら、マルチコア・メニイコアを存分に生かせられるのだが。

SMPやクラスタリングで、並列処理の実績はすでに
あるんだから、cellの性能を引き出せるようになるのも時間の問題
いつ開発環境が整うか?ってことでしかない
超並列コンピュータじゃないんだから
開発環境側で、自働チューニングするのできなくないだろ

おいMACオタ、テープアウトについて説明してみろよ

>>559
SMPに比べて自由度がかなり制限されているのがCellの弱点なんだよ

> 開発環境側で、自働チューニングするのできなくないだろ
できなくないのとすでにできているのには天地の差だよ
まともな自動チューナーができるのは何時なのか予言してみたまえ

>>560
私が書いたこと >>484
プロセッサアーキテクトの草分け､嶋氏の説明
http://v-t.jp/premier/index.php?mode=show&UID=1117037100
　　----------------------
　　論理設計を1972年12月に始め、レイアウト設計を終了し、マスク製作用のデータベース作成である
　　テープアウトを終了したのが、８ヵ月後の、1973年８月９日であった。
　　----------------------
同じことがかいてあるということが理解できないヒトがいるとも思えないすけど(笑)

>>535
Cellのプログラミングパラダイムがクタ公の脳内にしか存在しないのが問題になっているのだよ

MACオタは、自分の都合の悪い意見を読んだ上で無視しているのではなくて、そもそも目に入っていないっぽいな

とりあえず読んでいるならテープアウトの説明をしたまえ

>>561
　　-------------------
　　できなくないのとすでにできているのには天地の差だよ
　　-------------------
SMPシステム用に､そんな便利なものが「すでにできている｣というのわ初耳すけど(笑)

>>564
お前は読解力がゼロなのか
できていないから問題だと書いてあるだろう

ＲＭＳ･･･つまりINTELはＧＰＧＰＵや”ＣＥＬＬボード(架空)”を目指してる？

おい560、テープアウトについて説明してみろよ

>>562のは一昔前の定義でしょ
どっちかというと最近は↓こっちの意味

http://www.cadence.co.jp/news/h15-11-11.html
> テープアウトとは、設計者がタイミングの検証まですべて終了し，
> 設計データをICマスク設計者に渡す段階を指すもので、LSIの設計が
> 完了したことを意味します。

マスクデータの作成は普通はfabの側でやるから

639 ：名無しさん必死だな ：2006/04/29(土) 02:13:07 ID:Z+wa8V1x
118 名前：名無しさん必死だな 本日のレス 投稿日：2006/04/29(土) 01:55:31 3VEZgJYI
　古川 享 ブログ
　http://spaces.msn.com/furukawablog/blog/cns!156823E649BD3714!3406.entry

　CELLのパワー自体は凄いらしい、ゲーム機になるとバスの転送能力などはこうはいかないが

663 ：名無しさん必死だな ：2006/04/29(土) 09:08:52 ID:cT0pvHhl
Cellって、低速デバイス(XDR)に書き戻すまでに超高速で色々やってしまおうって発想なのかな。

667 ：名無しさん必死だな ：2006/04/29(土) 09:20:34 ID:cT0pvHhl
現状でも複数プロセッサを積んだマシンはあるけど、
お互い低速バスとメモリで繋がってるのみ。結局殆どから回りしてる。
でもCellは小規模でありながら複数プロセッサが超高速バスで繋がって
パイプラインを築く事が出来るわけで、
Pen4を8個搭載しただけでは同じことは出来ない。
このあたりに他にない価値を見出す事が出来そう。

しかしPS3終わった・・・・。orz

Playstation 3?
http://www.youtube.com/watch?v=V1QTSwPmGxI&search=playstation3

>>542
ま、俺が一番好きなXBOX360タイトルがHexic HDだったりする訳だからな。
ぶっちゃけ見せ金的スペックだから。

BF2がぐりぐり動いてるの見るとまぁマァそこそこ安くて良いかもとか思うけどね。

Cellを、8コアのCPUだと思うから、ダメなんですよ。
シングルコアのCPUに、7個のアクセラレータを高速バスで接続したもの
というふうに考えればいいんですよ。

OSに管理させるのはPPEだけで、
7個のアクセラレータで実行するプログラムやデータは、
OSではなく、ユーザつまりゲームプログラムが管理すべきもの。

>>572
まああれだよ、
「時代はデュアルコア！」なーんて言ってたら8コアと名乗るものが出てきて、ファビョッタってことなんだよ。
別に複数コアなんて珍しいものでもx86だけのものでもない（どころか後発）のにね。


AMD次世代スレのテンプレはっとく（AMDとインテルと入れ替えればインテル用にもなる）

Aという技術がプロセッサ業界等で採用され始める（業界のトレンド）
→視野が狭いので知りもしない

オタ「Aという技術が他で採用されてるす。AMDもいずれ採用するんじゃないすかね」
→うざい。そんなわけないだろ

インテルがA技術の採用を発表する（インテル儲にとってトレンド）
→これだからインテルはｗ

AMDがA技術の採用を検討し始める
→これからはAの時代だ！（ここがAMD儲のいうトレンド）

>>573
自分で作ったテンプレをそんなに見て欲しかったのかい？
いい子だから、よそでやりなさい。

フリーランチが戻ってきた
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=6

>>575
ありゃりゃ
＞Conclusion 2 : The free lunch is back!
なんてホントに書いてあるのねｗ

回りまわって結局自分達の首しめるだけのことのようなｗｗｗ

自分達って誰のことだ？

多数CPUのSMAPでのアクセス調停にはCELLのような周回バスは最適だ、
共有領域への書き込みがあると無条件でバスを一周させればいい。
調停をL2キャッシュに任せることもできそうなので、調停のために極端に
遅くはならないし調停中にはPen4のHTのように別の作業してもいいだろう。
この頃のスパコンの数K個以上というCPUを調停しようというのではないのだから
工夫すれば多少は遅くなるが問題になるほどでもないはず。

http://japan.cnet.com/column/apple_onlamp/story/0,2000060061,20104527,00.htm

あながち、5年後にはCellがシェアを勝ち取ってたりしてな、PC CPUとしても。
Linuxの普及と共に。

妄想は計画的に

>>578
リングバスは、キャッシュコヒーレンシがすごく楽なんだろうが
レイテンシが長くなりそう
今のCPUのL2は10クロック以上なので
許容できなくもないかもしれないけど

不良リンチかよ

制御用のPPEはPowerの劣化版だから、Linuxの移植はたいして難しくはないかと。
ただ、SPEを使いこなすのは大変だから、劣化版じゃない普通のPowerを使った方がマシだと思う。

CellがモンスターCPUだが下手したら糞CPU程度かもしれないのは良く分かる。
PS3もしかり。

http://spaces.msn.com/furukawablog/blog/cns!156823E649BD3714!3406.entry
さすがにここまでやると骨が折れるだろうが凄いな

今の技術ならpen2ｺｱで2GHzぐらい動くだろ？それの8ｺｱで

んじゃ

その手のやつならむしろNiagaraだろ。
次期コアは16コア統合だっけか。

>>587
>>420

>>587
ttp://www.tv-asahi.co.jp/astro/contents/story_p/0008/

HPの比較記事ってSAPやん。
NiagaraでDBまで走らせてどうする。
WebサーバやApplicationサーバで比較せにゃ。

AMDがこういうインチキ宣伝をやりすぎたせいで､
　　「AMD Opteron、TPC-Cベンチマークで首位獲得｣ (実わコアあたりで揃えるとPOWER5が遥かに上)
　　http://www.itmedia.co.jp/enterprise/articles/0510/08/news016.html
TPCが怒って､結果の表示方を変えたす。新表示形式わP(プロセッサ数)/C(コア数)/T(スレッド数)が
併記されるようになって､こんな感じす。
http://www.tpc.org/tpcc/results/tpcc_advanced_sort.asp?FLTCOL1=tpcc.c_server_procs&FLTCHO1=4&ADDFILTERROW=&filterRowCount=1&SRTCOL1=tpcc.c_tpmc&SRTDIR1=DESC&ADDSORTROW=&sortRowCount=1&include_server_cpu=ON

>>591
単にマルチコアやマルチスレッドなどの新フィーチャーに対応しただけのように見えるし、
そもそもTPC-Cはコアあたりの性能を測るベンチじゃないだろ。
さらに言うならCPUメーカーの宣伝というより、各ベンダーのシステムの宣伝という方が適切。

> AMDがこういうインチキ宣伝をやりすぎたせいで

方々で「AMDわ」とか「アム虫わ」とか叫んでるが、○ntelの依頼によるバイトか何かか？
もしそうなら俺にも是非紹介してほしいw

>>592
　　--------------------
　　CPUメーカーの宣伝というより、各ベンダーのシステムの宣伝という方が適切。
　　--------------------
>>591で引用した記事のタイトルにAMDの名前わ有っても､システムベンダであるHPわ入ってない気が(笑)
ちなみに､AMD自身もこのネタ使っているす。
http://www.amd.com/jp-ja/Corporate/VirtualPressRoom/0,,51_104_543_13302~102332,00.html
　　====================
　　デュアルコアAMD Opｔeronプロセッサ880モデルを採用したHP ProLiant DL585サーバは、4 way x86
　　サーバの中で唯一TPC-C 200Kトランザクション スコアを超えたサーバです。
　　====================
流石に公式文書で嘘を書くと法的にヤバいせいで"x86サーバ"って注釈を入れているす。
　　

>>592
あぼ〜んだらけでよく分からんし、歴史にif文はないが、
もし仮にAppleがAMDを採用していたら、Macヲタは方々で
「Intelわ」（うわ虫唾が走る）と書いていただろうね。請け合うよ

>>593
> >>591で引用した記事のタイトルにAMDの名前わ有っても､システムベンダであるHPわ入ってない気が(笑)
都合によって原文わスルーすか？
> October 7, 2005
> AMD-HP Opteron Tops TPC-C Benchmark

MACオタかなりウザイからフィルタしておくか。

>>595
英語読めないんだから仕方がない

>>591
AMD信者ではないが、TPCが怒ったとデマを流されるのは不憫なので。

http://www.tpc.org/reports/status/BS-2005-05.asp
2005/2、マルチコア／スレッドを考慮したCPU数の取り扱いを検討するグループ作成。
http://www.tpc.org/reports/status/BS-2005-08.asp
2005/6、用語の定義、変更の影響の評価など、グループの作業が完了。
http://www.tpc.org/reports/status/BS-2005-09.asp
2005/8、TPC-H 2.3.0が発効。Processors/Cores/Threads数の記載が必要に。
http://www.tpc.org/reports/status/BS-2005-12.asp
2005/10、TPC-C 5.5が発効。Processors/Cores/Threads数の記載が必要に。
http://www.tpc.org/reports/status/BS-2006-02.asp
2005/12、TPC-App 1.1.2にてProcessors/Cores/Threads数の記載が必要に。

CELL…さようなら…

奇形児ネタ禁止

おっぱいスライダー！
http://ex14.2ch.net/test/read.cgi/news4vip/1147929857/

AMD64とかべらぼうに速いから、PICマイコソみたいな組み込み型1ﾁｰﾌﾟCPUを
オリジナルアーキティクチャみたいな感じでエミュレーション作ってみたい
んだけど。

そういうCPUのｱｰｷﾃｨｸﾁｬを妄想するエミュレータツールとかってないのかなぁ。
やっぱｻﾞｲﾘﾝｸｽとかFPGA見たいな奴にちまちま回路組んでつくってくしかないのかなぁ?

>>602
そう言う時のビヘイビア記述&verilog&VHDLシミュレータ…
synopsysとかにはもっと高度なツールがあるけどね。

復活したEfficeonはXboxポータブルに搭載か
http://pc.watch.impress.co.jp/docs/2006/0519/spf04.htm

>>604
マジか？
実現したら奇跡の復活劇だな……

ここで示されてる資料が興味深いな。
プロセッサのバラツキ具合とか。

EfficeonよりPowerPC750あたりの方が性能も高いし消費電力も低い気がするが

http://pc.watch.impress.co.jp/docs/2006/0520/kaigai271.htm

馬鹿が一匹まじっています

>>608
俺としてはBitBoysがATiに買収されていたことがショック
Glaze3Dが完全に消えたか…。

>>610
君の心の中で、生きているよ

ぶっちゃけEfficeonはゲーム向きじゃないよな。
やっぱipod対抗動画プレイヤー?

ipod対抗動画プレイヤーのVer.1がOrigami、
Ver2が次に出る。
買いなのはその次に出るやつだ。

>>607
XBOX1互換で作る＝CPUはx86　に直行したんだろ？
どーせｱﾌﾟﾘ配信に限定するならなんとでもなるのにね

http://pc.watch.impress.co.jp/docs/2006/0522/spf05.htm

>>598の怒りに触れてMACオタが消え去ったか

http://pc.watch.impress.co.jp/docs/2006/0523/freescale.htm

フリースケールは多機能路線突っ走るねぇ

http://pc.watch.impress.co.jp/docs/2006/0524/spf06.htm

>>617,619
PentiumとAthlonがどうのこうの、とか笑っちまうくらいの話だよなぁ…x86なんて…

http://pc.watch.impress.co.jp/docs/2006/0526/spf07.htm

ゲーハー板じゃ既出のネタすけど､Cell叩きに余念が無い皆さんのご意見わ如何すか？
http://www.cs.berkeley.edu/%7Esamw/projects/cell/LBL_SCS_march3.pdf
　　　　　　　　　Hammer/2.2GHz比　　　IPF/1.4GHz比
　DGEMM　　　　　　　12.8x　　　　　　　　　　　9.5x
　SpMV　　　　　　　＞ 8.4x　　　　　　　　　＞ 8.4x
　Stencil　　　　　　　　37.0x　　　　　　　　　　17.7x
　1D FFT　　　　　　　 10.6x　　　　　　　　　　 7.6x
　2D FFT　　　　　　　 13.4x　　　　　　　　　　30.6x

問題サイズにたいしてスケールしとらん

FFTの点数を大きくしていくとCellはギブアップするだろ?

http://pc.watch.impress.co.jp/docs/2006/0601/spf08.htm

アーキテクチャからちょっと外れるけど、パッケージの方はどんな感じ？
ピン数増える一方で凄いことにならないかな…

SPEは直接外界と繋がってないから、
そんな酷いことにはならんのじゃないか?

何か虚しさを感じるのは気のせいですか？

インテル、Itaniumの発売5周年を祝うパーティ
http://pc.watch.impress.co.jp/docs/2006/0602/intel.htm

Itanium2マシンが出荷開始されたために、Itaniumマシンはその出荷開始からたった12ヶ月後には、産業廃棄物として捨てられた。
1年でゴミになるマシンは、そうそうないよね。

http://enterprise.watch.impress.co.jp/cda/static/image/2006/06/01/intel02.jpg

Itaniumが発売されたころには、すでにPOWERがデュアルコア化してた

あまりの不甲斐なさに一度マイクロソフトに見捨てられたのが痛かったitanium。
マイクロソフト撤退によりlinuxが増殖してしまいitanium2に再度マイクロソフト降臨。
ドロドロだな。

>>626
http://journal.mycom.co.jp/articles/2006/06/02/ectc3/

不思議なルールが有るのかもしれんが
何故OSの仕組みとして解析済みのネイティブコードやマイクロオペをHDDにプログラム毎にキャッシュして保存しておかないんだろう？
イヒも無理矢理固有領域を用意してたし
DECのアレも何か変な事してたし

CPU側がデコード結果のI/O用意しなきゃ始まらんけどね。

>>634
HDDは遅い+デコードされたネイティブコードは元よりも大きくなる(より帯域を必要とする)。
つまり、下手にHDDキャッシュするより、その場でデコードした法が高速になる事が多いと考えられている。
コード密度と(キャッシュ構造含めた)メモリ帯域とのバランスは難しい。

ARMのThumbなんかはメモリの節約が主眼だったりするけれど、Thumb使った方が性能上がっちゃう時があったりするぐらい。

Transmetaは実質的にAMDの傘下か。

なるほどねメモリ帯域が問題になるのか
OS側でネイティブコード管理できればJavaをはじめとする無駄な中間コード技術が排除できると思ったのに。

携帯機器用途のJavaって電力効率最悪なんで
デコード結果とオリジナルコードをセグメント毎徐々に入れ替えて行って非効率なCPU時間の消費を抑えていく
のってスバラシイと思ったんだけど

アーム、新ファミリーの組み込み向けプロセッサー“ARM Cortex-R4”の説明会を開催
http://ascii24.com/news/i/tech/article/2006/06/07/662702-000.html
＞従来のThumb命令と、新しいThumb-2と比較して18〜22％高速になるという。

しかし何千万〜何億トランジスタだのが当たり前の感覚は何かが麻痺してるのかもな
＞ 18万〜22万ゲート
もちろんそれなりの性能だけど

>>637
JavaのJITが重いという問題は、CPUは関係ないな。
コードモーフィングするCPUだろうと、そうでなかろうと、重いのだから。

他にも、
OSがネイティブコードを管理してキャッシュして再利用しても、
それがうまく働くのはOSが管理しているコードだけであり、
JVMが動的に生成するコードに関してはキャッシュが働かない。

うまく働くようにするためには、JVMをOSに統合し、
OSというよりはJVMが、
ネイティブコードを管理してキャッシュしないといけない。

さらに、
Javaは動的にコードを生成することを前提としたアーキテクチャであり、
動的にコードを生成することでパフォーマンスが出るようになっていて、
一度生成したコードを生成し直すことも多々あるわけで・・・・。

結論としては、Javaを高速に実行したければ、
Efficeonとかのネイティブコードを直接出力するJVMと、
それをサポートするOSを作れ、と。

CONFIG_MICROCODE:

If you say Y here and also to "/dev file system support" in the
'File systems' section, you will be able to update the microcode on
Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
Pentium III, Pentium 4, Xeon etc. You will obviously need the
actual microcode binary data itself which is not shipped with the
Linux kernel.

こんな事やってるなら改造マイクロコードも可能なのかな?

バグ修正がせいぜいだと思うけどナ。

http://www.watch.impress.co.jp/av/docs/20060609/sce.htm

>>644

「相当高価なスーパーコンピュータに近い能力を実現した」

「1/60秒ごとに全てのアクションのレスポンスを返さないといけない。それをフルHDの映像で、
リアルタイムに全て作り出す。」

どう見ても嘘・大袈裟・まぎらわしい宣伝文句です。ありがとうございました。

>>645
その為の専用CPUだから。
pentiumやpowerみたいな汎用CPUには絶対無理な芸当。

>>645
いつまでもx86にこもってないで、外の世界にでてみろよ

>>644
相当高価なスーパーコンピュータは
>「Cellは、単精度(32bit)浮動小数点ですが、
>医療画像処理やエンターテインメントに適している」
なんて変な言い訳する必要が無いんだが。

単精度で科学演算やってるスパコンなんて存在しない。

>>637
Javaが重いのは、中間言語を使ってるからじゃなくて
メモリ管理とかセキュリティーとかで
実行時にしなくちゃいけないタスクが重いからだよ

>>648
アルゴリズムとか処理によっては
単精度でも済むものってあるんじゃないかな?
cellのメモリ帯域・レイテンシや単精度って点とかで
自然科学シミュレートには不向きなのは間違いないけど

>>645
単精度限定なら、1CPUのCrayX-1やSX-8より
速くできる処理はいくらでもあると思う
まぁ「スパコン並み」ってのは、速いことをあらわす
一般的な枕詞ではあるけどね

今後、「スパコン並み」と表記されてるコンピュータを見たら、
クレイの最初の奴程度だと思うことにしよう。

90年代半ばのCrayT90で、2Gflops/プロセッサだからな
何もかもがスパコン級だ

cellってすごーい（棒読み）
http://www.watch.impress.co.jp/av/docs/20060609/sce5.jpg

>>653
ぶっちゃけAltiVecの方がSPEより…

なにがずこいわけ?
身近な所ではGPU。
今となっては低性能なATIのRadeonX800でも12GFlops。
NvidiaのR600は512GFlops(予定)
くそ遅いpentium4やathlonの肩代わりしてるのが脇役のGPU。

http://pc.watch.impress.co.jp/docs/2005/0517/ps3.htm
>RSXとCellを合わせた浮動小数演算性能は2T FLOPSを超えるという。
2T FLOPSなら一応スパコン並だよね。
>90年代半ばのCrayT90
の1000倍だ。
ソニーがプレステ3にlinuxを載せたのは2T GFLOPSの性能はゲーム以外の用途が
あると考えているから。
数億円の医療機器の中にプレステ3が入っているかもしれない。
やたら医療機器を強調してるしもうやってるのかもね。

>>655
日本語でおｋ

奇形児ネタ禁止

>>648
> 単精度で科学演算やってるスパコンなんて存在しない。

え?

実際の計算ではなくベンチマークで恐縮だが、姫野ベンチは単精度だよ。

>>655
Linuxが走っているのはPowerPC系のコアだよ。

普通に書いた科学演算アプリは、Cellの強力な演算ユニットたちを使うことができないよ。

>>659
linuxの世界ではそういうのは自分で書くのが前提です。
PS3のlinux搭載は素人向けではないでしょう。

そうかなぁ。

全数Linuxをプリインストールで出荷するとか言ってるから、
組み込みOSとして位置づける可能性もあるよ。
セガのドリームキャストに積まれたWindowsCEみたいにさ。

それにしてもLinuxの世界っていうのは凄いんですね。
アプリを書く各人が、自分でLinuxを異種CPUのマルチプロセッサに対応するように、改造するもんなんだ。

自分なら演算ユニット群はLinuxの管理下には置かず、Linuxに対しては、
ユーザのアプリが演算ユニット群と通信したりメモリを共有するための仕組みを提供するだけに留めるなぁ。
つまり、既存のインテリジェントな拡張ボードの類いと同じ扱いね。

Cellを積んだPCI Expressカードなんかが出ると、エンコードやトリップ検索なんかに使えそうなんですが、どうでしょうか。。。
ああ、あとゲームの物理シミュレーションにも使えるかな。

トリップ検索が用途として普通に出てくるのにﾜﾛﾀ

「スーパーコンピューター並」ってのはコンピューター業界でもっとも陳腐なセールストークだよ。
科学技術演算用のいわゆるスパコンはメモリ性能が違いすぎる。
普通、8バイトの倍精度浮動小数点データなら2演算に1回アクセスできるように、
4Byte/FLOPS位のバンド幅のメモリを繋ぐから、CPUが2TFLOPSなら8TB/s位のメモリが必要。
これに対してPS3はCPUが本当に2TFLOPSでも、メモリは25.6GB/sしかない。

SONYは医療器具やスパコン作ったことないくせに大風呂敷広げちゃったのな。

タイマーきっかりの1年で壊れるんじゃどこも採用しないのが関の山。

６６６なら女子高生にレイプされる

暗号処理、つまりトリップ検索って高速化が簡単なんだよな
cell向き

そうでもないお

トリップ検索は金に糸目をつけなければ、専用のハードウェアを組んで、1クロックで1キーを検索できると思う。
やることが決まっているので、何百段、何千段というパイプラインを組んでしまえばいいのだから。

以前、世界中のPCの空き時間を使って暗号解析をやってみて、
暗号の強度を実際に試しましょうというプロジェクトがあったのだけど、
膨大な台数と時間を使って解析されていたのが、
専用のハードウェアを作ったところの参入により数日で解析が終わった、
という話があったよ。

CPUよりも遥かに速いスピードで3DES処理できる暗号化アクセラレータチップには、ヒートシンクすらついていないのだから。

>>669
トリップ生成のアルゴリズムは知らないが、どうせ論理演算とシフトと、あってもテーブルくらいだろ
FPGAじゃだめなん？

実際にFPGAに実装して連続トリップの価値を暴落させたﾔｼが居る

>>661
>アプリを書く各人が、自分でLinuxを異種CPUのマルチプロセッサに対応するように、改造するもんなんだ。
基本的にはそうなるでしょう。
こういう事なんです。
http://cell.scei.co.jp/pdf/SPU_language_extensions_v21_j.pdf
altavecやsseを動かすのと同様の対応になるかと。

http://pc.watch.impress.co.jp/docs/2006/0613/hinomaru.htm

>>673
汎用京速計算機のプロセサはぜひ日の丸ファウンドリで製造してほしい。

まだcellを過大評価してる奴がいるとは・・・

これ見て目を覚ませよｗ
http://www.theinquirer.net/?article=32171

>>675
つhttp://www.watch.impress.co.jp/av/docs/20060609/sce5.jpg

またGKか

SIMD的手法と言ってみるテスト


それにしても超珍ライターもビックリなグラフですな

16MB/sはさすがにtypoだろうが、
4GB/sでもじゅうぶん遅い。

>>674
>検討の結果、次のような結論を得て、事業化を断念し、6月末をもって解散することとなった。

すいません、、すれ違いかもしれませんが
ムーアマイクロプロセッサ特許ってどんなものですか？　
これを買った企業の動きとしてはその後どのような展開が予測できるでしょうか。

>>681
mooreマシンのmooreじゃなくて、forthで有名なmoore氏の特許だな。
AMD、富士通が和解してる程度には強力な物って事だ。

>>680
うは、よく読んでなかった……

cellが速いと何か困るのかしら?
専用CPUなんだから特定用途で汎用CPUの一桁や二桁は速くてあたりまえなんだけどな。
conroeより遥かに高速に処理できる数千円のDSPの存在とか上げたらまた怒りだすのだろうかw

俺としては、特定用途なら爆速だが汎用CPUと同じように使おうとするとグダグダなのに、
さもいかなる状況においても爆速であるかのように語る輩がうざい。

それなんて久夛良木健？

俺としては、IBM PowerPCの余興にすぎないのに、やっと2コア製品が登場したx86信者がファビョったり、
なぜか目の敵にして叩く輩がうざい。

それはCell信者がウザいせいだろ。

糞ニー自らが676みたいな久夛良ない比較をするから
嗤われてるんだろ。
そもそも特定の命令体系に特化したもの作りたければ
汎用CPU＋FPGAでもこの程度の数値は出ると思うがな。

まぁ何はともあれGK乙。

どうみてもCellは、PowerPC系コア + DSP多数 だよね。

>>689
FPGAで作ろうとすると無駄が多すぎて大変なことになるんじゃないかと。

GRAPEの元になった奴がFPGA(っていうかLatticeのCPLD)ぽかったやうな気がした。
FPGAやCPLDは乗算器苦手だけど。
最近の奴は乗算器向け要素(DSPブロック)が入ってるから良くなってるけど。

でもまぁ、特定アルゴリズム専用ハードウェアなら性能が出て当然と思われてるからね。
でも鬼の様な速度で進歩する汎用プロセッサ相手だと、なかなか勝ち続ける事は難しい…
分野しだいってのがねぇ…。

しかもなんか変なリングバスみたいなの使ってるしな

「ダイナミックリコンフィキャラブル」って知ってる？

昔なんかの本で読んだんだけど、発音を間違えたのか
ググっても出てこない。

キじゃなくてギ

>>694
あぎがとう。ググったら出てきた(*ﾟ∀ﾟ)

今流通してるFPGAでは内部ギガ超えの論理組めねーし。

いろいろ妄想したいもまいらに

つ[ Virtex4FX ]
つ[ DAP/DNA ]

DRPもあるでよ

1万円のデジカメの方が20万のパソコンより高速に画像処理やってるって事さ。
パソコンオタはけしからんと理不尽言うけど。

RISCのＰＣ市場に未来はあるか

PPCPの話ですか。

PC==IBM PCですから(r

riscかどうかはともかく、情報流出騒ぎなんかの関係でNCやシンクライアント的ニーズそのものはあるだろうが…

結局コストが壁。
CPUだけ安くなってもね…

ゼロから設計するシンクライアントととっくに量産しまくりのPCだとコストが全然違うからね。

じゃあもう無理だな。

既にOSとアプリのソースコードはある(=linux)
コンパイラさえ用意すれば後は全部揃っている状況。
x86やwindowsに縛られない新しいハードの成立するチャンスはある。

crayがIA-64をメインにする時代だ
intelやAMDより安くて速いの作るのは不可能

>>705
そんなチャンスは昔からあるのだけど。

SPARC系のワークステーションとか、あったでしょ。
でも、x86系のほうが安くて性能がいいでしょ。

むしろ昔の方がいろいろあったな

Alphaが最速だった時代が懐かしい…

>>706
何いってんの?
x86系よりcellの方がずっと安くて一桁、二桁速いでしょうに。
これは無視なわけ?
汎用CPUしか視野にないのはどうかと思うよ。

もちろん無視だ

特定用途専用ならDSPで済むしな。

>>710
cell搭載PCは、x86搭載PCよりも、安いの?

その前に、Cellは流血販売じゃなかったっけ。
1個につき2万だか3万だか損になるとかいう記憶があるわけだが。

>>714
　　-----------------
　　その前に、Cellは流血販売じゃなかったっけ。
　　-----------------
IBM, AMD, Sony, 東芝わ､SOIプロセスを共同開発してるんで､同プロセスのK8の値段とダイサイズ
を見れば､コストの予想わ､つくす。
　Windsor K8 (90nm Dual-Core 1MB L2 x 2): 230 mm^2
　Cell DD2 (90nm): 235 mm^2

ダイサイズは同じでも、1クロックでたくさんの仕事をしなければいけない演算器の面積が、K8よりもCellのほうが、ずっと広い。

キャッシュが少ない方が歩留まりは良さそうだけどね

ダイサイズからコストを見積もる計算法わ､こちらをどうぞ。
http://journal.mycom.co.jp/column/architecture/024/

>>717
逆だよ、逆

キャッシュはすでにかなり冗長な設計になっている

逆とは言えないだろ。
ダイサイズ小さくすればそれだけ多く取れるんだから。

CellでMacOSX動くように出来ないの？

>>721
エンディアンの違うx86にすら移植できたすから､ARMだろうがItaniumだろうが､32-bit以上の
メモリにアクセスできるプロセッサにわ移植可能かと思うす。

>>719
一般的にキャッシュの方がギチギチに詰め込むから歩留まりが悪い
冗長化して初めてロジック並みの歩留まりが確保できるわけで
インテルなんかもキャッシュ半分殺した石とか出してるでしょ？

>>721
出来ないよ。
そんなもんにジョブズがGOサイン出すわけがない。

Cellプロセッサなら、MacBookの最大10ば（ｒｙ

>>723
半分死んだキャッシュのは、ただの半不良品の利用

最近のロジック は、クリィティカルな箇所でいろいろ変わったことを
しているので、昔に くらべて歩留まり厳しくなっているよ

> いろいろ変わったこと

なんだろ？LowVthとか？

http://pc.watch.impress.co.jp/docs/2006/0619/riken.htm

グラフィック処理に特化したシステムを構築するならcellは汎用CPUの10倍〜100倍の性能を見込める。
いまさらクソ遅い汎用CPUで構築するのはアホ。
汎用CPUというレギュレーションを押しつけたい気持ちもわかるけどcellのような方向性もある。
cellの構成はオーダーメードで容易にユニットを取り換えられる意図もある。
もし倍々精度の浮動小数点演算の注文があればすぐにユニットを取り換えて提供できる。

すいません、ゲハのマンセースレに書き込もうと思って誤爆しますた。

仮にcellをPCに合わせてカスタマイズしたとしたら、
噂のCore2Duoと比べて何倍速いですか？

10倍〜100倍

ただしCellが得意な分野限定な。
汎用CPUと同じ使い方した場合どの程度の
性能が出るかは資料が無いため不明。
多分ズタボロ。

>>731
>仮にcellをPCに合わせてカスタマイズしたとしたら、

どんな風にカスタマイズするんですか？
PPEを強化してOOOEを可能にしたり？
カスタマイズとやらの内容が分らないと何とも言えませんねえ。

なんつーか、POWERの１つの流れにすぎないCellに過剰反応すすぎじゃね？

てか宣伝ウザ杉

>>731を読んで思ったが、やはりIntel POWERを作るべきだな。
Core2 Duoがx86じゃなかったらどんなにいいか

汎用性を犠牲にすれば高速化できるという好例だな。

理研ら、1PFLOPSの分子動力学専用コンピュータを開発
http://pc.watch.impress.co.jp/docs/2006/0619/riken.htm

流体演算とかはぼろぼろだろうな…

だからこそのHT3.0なんだろうな

>>738
そのシステムのキモは
>理研が開発した同名の分子動力学シミュレーション専用LSIを4,808個搭載
だからな。

ただ運用側（理研）も設計側もそこをキチンと分かってるから
汎用性の無さは問題にならない。

GK宣伝乙。
過剰反応はしたくないがウザ杉。
ジョブスにすら見捨てられたcellに
汎用CPUと同じものを期待するのがそもそも間違い。

この「分子動力学専用」コンピュータって思い切りの良さが素敵。

規格だけ速くなってもなあ>>HT3

HTのバスを外に引き出してPhysXみたいなのつければ同じ事。
Cell？話にならんよwwwwww
ttp://pc.watch.impress.co.jp/docs/2006/0602/slide117.jpg

>>738
専用LSIを24個積んだボードが201枚か。ラックに縦に20枚並んでいるから、10本か。
つまり、あの写真に写っているので全てか。

> デュアルコアXeonを256個搭載したサーバーを64台
という書き方は勘弁してほしい。4プロセッサのサーバを64台で合計256プロセッサの並列システム。

GKの粘着は雑音並かそれ以上だな

それでもcellのっけた鯖は出る

・・・それは非常にニッチである（hpc.co.jp風）

選択肢に縛られないような状況でも、Xeonしか使えないあたりがアレだな

その用途で、XeonとOpteronを比較したら、Xeonのほうがパフォーマンスが良かった、というだけじゃないか?

Dempseyの在庫処分

>>751
えーとね…言い直そうか

選択肢に縛られないような状況でも、XeonとOpteronしか頭に出てこないあたりがアレだな

こんなCPUが載ってる鯖なんか誰が買いますか？

･大量演算用のSPEだけならともかく制御用のPPEにもない予測分岐
･SPE無しでは同クロックのP4の1/5しかパフォーマンスがでないPPE
･SPEが遊んでいてもPPEが忙しいためSPEが使えないと言う事態が発生しそう
･アウトオブオーダー実行が出来ないというベースとなったPowerPC970より劣化しているPPE~ SPEその他
･SPEごとにDMAがついている謎仕様(通常はDMAコントローラーは1つでキューが複数)
･レイテンシが増加するリングバスを採用した内部バス
･SPEのスケジューリングはさまざまな要因を考慮してプログラマが自力組み
･データ+プログラムを256KBに収めないといけないSPE
･分岐予測がない上にデータ量の制限も有るSPE上で動くと言うカーネルベースプログラミング
･リングバス+メモリIOと周辺IOが離れているためメモリ→GPU転送がCPUの内部バスを通ると言う謎設計
･スパコンと言うが弱すぎる倍精度演算能力

>>754
>･スパコンと言うが弱すぎる倍精度演算能力

>>729の人が
>もし倍々精度の浮動小数点演算の注文があればすぐにユニットを取り換えて提供できる。

と言っていますがｗ
（倍々精度…？）

>選択肢に縛られないような状況
予算は縛りじゃないのかね
>>741でFAだろ

cellをサーバーに使う馬鹿はいないね。
画像処理専用ならパフォーマンスは普通のCPUの100倍くらいありそうだ。
専用CPUは用途が限定されるが特定用途では普通のCPUより100倍高速。

IBM、Cellベースのブレードサーバーを開発
ttp://pc.watch.impress.co.jp/docs/2006/0209/ibm.htm

>>758
値段提示出来ない、というか製品レベルは期待するなということで。

> Product Availability
> IBM intends to make the Cell BE-based system available for direct purchase
> beginning in the third quarter of 2006, with availability via special bids
> now.
ttp://www-03.ibm.com/press/us/en/pressrelease/19229.wss

Cell BEソリューション
ttp://www-06.ibm.com/jp/ibm/apto/cellbe/index.html
開発、支援、トレーニング、テスト。どう考えても実験です。

家電以外は1チップにするメリット無いし

Cellは3.2GHｚ以外認められないんでしょ？
出来の悪いCPUに関して、他社のCPUなら2.4GHｚの廉価版にして売ることができるけど
Cellは今のところ大規模な使い道がないよね。IBMのサーバーくらい？

コストが恐ろしいことになりそう。

>Cellは3.2GHｚ以外認められないんでしょ？
PS3のスペック表を3.2G回読み返せ

Cellは4.6Gじゃなかったっけか。

>>755
倍々精度は多分128bit浮動少数だろ。
しかしユニット取り替えるつっても、4倍長いレジスタと
演算器が要ると思うが、空間あるのか?

>>762
http://www.scei.co.jp/corporate/release/pdf/060509a.pdf（注PDF）
ないね。
でも360よりも下にはしないと思うんだけどなぁ。

マスコミにクロック詐称をすっぱ抜かれてPSPのクロックを333MHzから1〜333MHzに書き換えるような会社だからな。
何をやってきてもおかしくはない。

>>753
もっとよい選択肢があるのなら、ここで教えてもらえませんか?

>>763
将来の拡張性があるアーキテクチャだということであって、
注文があればすぐに量産し始めますよ、ということではないと思う。
たぶん、SPEやPPEの個数を変更するとか、その中身をいじるとなると、
それなりの開発時間がかかると思いますよ。

>>766
俺もXeonとOpteronしか思いつかなかった

技術者（笑）「俺はx86しか使わないから、Xeonを選んだんだ。使えないんじゃないぞ。使わない主義なんだ。」

>>743
専用とは銘打ってるが
あれだけジーオソ積んでりゃ他用途にも使えるけどな。

シリコンゲルマニウムチップが500GHzの新記録--IBMとジョージア工科大、超低温環境で
ttp://japan.cnet.com/news/ent/story/0,2000056022,20145807,00.htm

通常の室温での実験では、IBMとGITのチップは350GHz（毎秒3500億サイクル）を
記録した。この数字でも、現行の一般的なPC用プロセッサの速度である1.8〜3.8GHz
に比べれば、はるかに高速だ。だがSiGeチップは、より低温の環境下でさらなる
パフォーマンス向上を実現できる。

>>771
超伝導かと思ったら常温でも350GHzですか。
1クロックに光が1mmしか進めないよ。

Cellの動作周波数は4GHｚより大きい、間違いない！
http://pc.watch.impress.co.jp/docs/2005/0208/kaigaip006.jpg

（業界から数年遅れているが）これからはデュアルコアの時代だ！→Cell発表でふぁびょーんｗ
4GHz断念か…→Cell4GHz超でふぁびょーんｗ
Cell搭載PCって出るの？→プロセッサ＝パソコンという視野の狭さ（笑）
Cellって実はたいしたことないねｗ→POWERの１つに過ぎませんが？PowerPCは年間x86の４つくらい桁違いの出荷量です（　＾ω＾）

ま、ふざけて書いてしまったが、何が言いたいかというとな。

他の世界の製品に嫉妬してファビョるな、ファビョるくらいなら井戸の中のカエルのままで知らずにいろ。
知ってファビョるな、x86信者として堂々としていろ。
ってことだ。

Cellの汎用性が低いのは最初からわかっていたことだが、お前らは勝手に8コアという部分に反応していただけだろ？やっとデュアルになったころに出たもんだから。

( ﾟдﾟ)ﾎﾟｶｰﾝ

キチガイが落書きするスレはここですか？

　体は　コンパイラで　出来ている
I am the bone of my compiler

　血潮はL3で　心は分岐機構
L3cache is my body,and "Speculative load/Predication" is my blood.

　幾たびの戦場を越えて不敗
I have exceeded over a thousand benchmark score.

　ただ一度の敗走はなく
Unaware of loss.

　ただ一度の勝利もなし
Nor aware of gain.

　担い手はここに孤り。
Withstood pain to create many Records.

　トランジスタの丘でシリコンを鍛つ
waiting for one's arrival.

　ならば　　我が生涯に意味は不要ず
I have no regrets.This is the only path.

　この体は無限の最適化オプション(ILP)で出来ていた
My whole life was "unlimited optimization works"

　　　　　　　　　　　　　　　　　,.,.,.,.,.,.,.,
　　　　　　　　　　　　　　　zｲ彡彡ミミﾐ
　　　　　　　　　　　　　　 Yk彡彡ミミミﾐ
　　　　　　　　　　　　　　 i、,　ﾞ'うミミミﾐ
　　　　　　　　　　　　　　　}´　　「ﾞ｀ヾﾐ;ﾞ
　　　　　　　　　　　　　　　｀‐、ノ _／¨ヽ、
　　　　　　　　　　　 　 　 　　 ´r'´-‐ ﾍ＞ヽ、
　　　　　　　　　　　　　　　　,.ノ｀ヽヾ、　Y´;: }
　　　　　　　　　　　　　　　 {,;;..:;,:;.:;:;,:,;i　 ﾊ;.;.;i!
　　　　　　　　　　　　　　　 i,:;.;,.:;,:;.:;,;;:.　　 〉;.;|
　　　　　　　　　　　　　　　 ヽ,:;.:;,:;.;:.　　 /.;.;.;.i!
　　　　　　　　　　　　　　　　 iﾞ｀ﾞﾞﾞﾞ'ﾞ　／; ; ;/:.!
　　　　　　　　　　　　　　　　 |; ｀ー'´; ; ; ; ;ｉ':':|
　　　　　　　　　　　　　　　　 i; ; ;＿＿＿/」':':!
　　　　　　　　　　　　　　 ┌'￣＿＿＿＿ﾉ':':|
　　　　　　　　　　　　　　 └ '´　　　　　　 ヽ:|
　　「i　　　　　　　　　　　　 i丶　　　　　　　 i:|　 　 　 　 　 　 ／／
　　」L　　　　　　　　　　　 i|　 ＼　　　　　　 i!　　　　　　　／／
　　 ||　 r!　　⊥　　　　　　| i　　　、　　　　　|　　　　　 ／／
　　 ||　 Y　　 i!　　　　　　 ﾊ',　　　　、　　　　!　　　 ／／
　　 ii　　i　　 i!　　　　　　/　 ' ,　　　　　　　　|　 ／／

月厨は回線吊って首吊って氏ねよ

なんで月厨ってわかるんだよ

>>770
他用途に使ってしまったら、専用LSIが浮いてしまって、もったいないことになると思う。

>>774
ﾜﾛｽ
書き方はおかしいが同意

2001年のデュアルコアには反応しなかったくせに、Cellには反応したり
自作板の住人って、よくわからんよなー
まあ視野が狭すぎるのは間違いない

上から目線でしかモノを見られないかわいそうな奴が湧いてきてるな。
視野が狭いとかなんだとか。cellの話したいならゲハ板でやれば？

あれこれ騒がれてるが俺に言わせればCellの凄いところはメモリインタフェースの一点に尽きる

>>783
基本的に自作PCに関係のある話をする板だから、
POWER系のデュアルコアなんて眼中に無くて当然なわけで。

自作PCという縛り無しでCPUのアーキテクチャの話をしたければ、
どうぞハードウェア板でやってください、って感じだな。

Cellは自作PCで使えるようになるの?
Cell搭載のビデオカードが出るくらいか?

・RSXのトライアングルセットアップ能力は2億7500万トライアングル/秒、Xbox360
　は5億トライアングル/秒以上で、RSXの倍。
　すなわちPS3は360の半分の性能か？いや、事態はもっと悪い。
・メインメモリに対してはCellは25GBps, RSXは15-20GBpsのバンド幅がある。
　これは問題ない。
・CellとRSXのローカルメモリ(VRAM)間のバンド幅は16Mbpsである。(Read時)
　ギガではなく、メガ。
　あまりに大きな差があるため、SONYがPS3開発者に見せたプレゼンテーションに
　「これは誤植ではない」とまで書かれている。
・RSXのｼﾞｵﾒﾄﾘﾊﾟｲﾌﾟﾗｲﾝの書き戻しは役に立たない。
　（VRAM to Cell の Read が発生するため）
　すなわち、RSXでの処理はｼｪｰﾀﾞｰのみで完結させなければならない。
・「これは最終版では修正されます」という説明がなかったため、
　これは修正不能な問題だと思われ

>>786
だから、なぜCellに限り反応するんだ？

>>784
そうそう、いつも通りスルーしてx86の世界に閉じこもってるのがいいのさ

>>788
ごめんな、俺の日本語がおかしかったか。

Cellが自作PCで使えるようにならないのなら板違いだ、ってことを言いたかった。

>>788
後ろの一言は余計
上から目線ってのはまさにおまえのそういう発言だ。

AMDのCTOの意見

画像処理にはCellモデルは向いていると思います。
しかし、すべての用途に適しているわけではありません。
ソフトウェアの開発も困難です。PLAYSTATION 3の状況を見てください。
PLAYSTATION 3の問題の多くは、ソフトウェアの複雑さに起因しているのではないでしょうか。

これは難しいプログラミングモデルです。正しく処理できれば、
大きなメリットがあります。（AMDが検討しようとしているモデルは、）効率のよい
汎用プロセッサに、特定ワークロードに特化した軽量のコプロセッサを
追加していくというものです。現在のクライアントまたはサーバ環境では、
システムを特定のワークロードに最適化しようとすると、
他のワークロードの性能が落ちてしまいます。多くの企業にとって、これは重大な問題です。
どのワークロードも快適に処理できるようにしなければなりません。
ttp://japan.cnet.com/interview/story/0,2000055954,20139587,00.htm

ようはHT3はVLバス？

　　この焼肉プレートはSONY製なんですよ　 ／
￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　∧■∧　　　　　ｼﾞｭｰ
　 （　・∀・）　　　 )　 )　　　∧∧　　 ／￣￣￣￣￣￣￣￣￣￣
　 （ つ━　）　　 (　 (　　　(ﾟДﾟ,,)　＜　すごい火力だな
　　|　｜　|.　┌━━━┐⊂　　|　　 ＼＿＿＿＿＿＿＿＿＿＿
　 （＿_）＿） │　Cell　 │ (＿＿)〜

漫画家の誰だったかの「もっともっとCPUを速くして
焼肉しませう」というネタを思い出した。
Pen200あたりの時代に雑誌記事でウズラの卵焼いてたな。

>>771
非シリコンだと、日本企業も進んでるよ

>>794
486ＤＸ4でeyecomだったかな、がウズラの卵焼いてたなｗ

>>775
>他の世界の製品に嫉妬してファビョるな、ファビョるくらいなら井戸の中のカエルのままで知らずにいろ。
>知ってファビョるな、x86信者として堂々としていろ。

次スレのテンプレ入り

しない

が、しかし

　　そろそろ食べごろですよ　　　　／
￣￣￣∨￣￣￣￣￣￣￣￣￣￣
　　∧■∧　　　　　ｼｭｰ
　 （　・∀・）　　　 )　 )　　　∧∧　　 ／￣￣￣￣￣￣￣￣￣
　 （ つ━　）　　 (　 (　　　(ﾟДﾟ,,)　＜　真っ黒焦げだｺﾞﾙｧ!
　　|　｜　|.　┌━━━┐⊂　　|　　 ＼＿＿＿＿＿＿＿＿＿
　 （＿_）＿） │　Cell　 │ (＿＿)〜

「嫉妬してるな」のガイドライン
http://ex13.2ch.net/test/read.cgi/gline/1145447754/

>>786
PS3にはlinuxが載っているから自作に無関係でもないよ。
素人でもPS3を基にパソコンを作る事もできる。
パソコンにつないでエンコ専用boxにする事もできる。
PS3でffmpeg走らせたら凄まじい性能を発揮するのは容易に想像できる。
自作って事に対して視野が狭すぎるよ。
グラポ挿すだけが自作じゃない。

メインメモリ256MBのパソコンですか。

GK(sony.co.jp)が来てからすっかり糞スレになっちまった

>>802
> 素人でもPS3を基にパソコンを作る事もできる。
PS3を改造するのなら、メーカー製パソコンの改造と同じで、ハードウェア板でやるべきだろう。

> パソコンにつないでエンコ専用boxにする事もできる。
そのパソコンがメーカー製でも自作でも関係なく、パソコンの周辺機器ということだから、ハードウェア板でやるべきだろう。

昔パワマクG5でも同じ事ができると言っていた人がいたような気がする。

Cellの演算能力云々って言ったってな。

CPUとGPUを一体化したようなアーキテクチャだろ。
P4とかCoreDuoとかAthlon64x2あたりにGeForce7800/7900やらRADEONx1900あたりのシェーダユニットあわせたら、
Cellの何倍ぐらいの性能を発揮できる事やら。

ﾗﾃﾞﾖﾝX2x00のUnified Shaderに期待。

>>807
そうだとしても、それを形にしなきゃ意味がない。

>>809
それはCellも同じことですよね。
だいたい、P4もCore Duoも64X2もGF7800もﾗﾃﾞﾖﾝX1900も既に市場に出ていますが、
Cellは実質的にまだ市場に出ていない。（開発キットとかリファレンスキットとかいう形
では出ていますが）

>>810
何か勘違いしてるよ。
実際Cellはその様な構成で作ったでしょ。

>>807は
＞P4とかCoreDuoとかAthlon64x2あたりに
＞GeForce7800/7900やらRADEONx1900あたりのシェーダユニットあわせたら、
＞Cellの何倍ぐらいの性能を発揮できる事やら。
と言っているのに、

>>810は
＞P4もCore Duoも64X2もGF7800もﾗﾃﾞﾖﾝX1900も既に市場に出ていますが
と。

各々が単体で形になっている事言っているではないのですよ。

>>809
形にするというが、両方を搭載したPCが市場に流通してるだけじゃ駄目なのかい？

GPUの演算結果をCPUが利用できなきゃダメだと？
いまのところは、AVIVOとかPureVideo以外には知らんが（PreVideoは違うか)
VistaではGPUからCPUへのデータ転送のインタフェースも整備されて、
ビデオのエンコードを手始めに多くの用途が準備されている。

だいたいだな、GPUとCPUは、別にワンチップにまとめる必要など皆無。
Cellでそれらの機能を統合しているような扱いなのは、単にコストの都合でしかない。
(いちおう、Cellのほかに、GPUも載せるらしいとも聞くが、Cellの演算性能だけじゃ足りなかったからだろ？

>>811
＞実際Cellはその様な構成で作ったでしょ

コストの都合でワンチップ化してるだけだろ。

＞各々が単体で形になっている事言っているではないのですよ。

なぜ単体じゃダメなのだ？
オレが807に書いたことは、>810氏には正しく伝わってるが
(元から同じ様なことを考えてたから稚拙な文章でも通じたのか？)
>811氏にはマトモに通じていなさそうだ。

マルチコアで並列度を上げて性能向上を図るも
アムダール則のまんまと言うか性能がサチって、
そりゃどこもコア数を3か4で打ち止めにするわけだと気付いて
汎用コプロをのっけまくる構造にしたが、それでグラフィックもやろうとしたら
どこのバスがボトルネックになってるのか、パフォーマンスが宜しくないので
NVIDIAに専用ロジック作らせたような流れだったと思うわけだが。

そもそもCellが何したかったのか、何が出来るのか良く分からんわけだが
シェーダがユニファイドになって汎用性が上がってくるとCellのような方向に
行き着く気はしないでもない。まぁ行き着くころにはPS2みたいに進化の流れから
取り残された異質な存在となってるだろうけどな。

>>814
うん、どこのバスを太くするのが効果的かって事さえ、
あんまりマトモに追究できてなさそうだ＞Cell
EEも同様だったな。
開発に口出しするボスが、プロセッサのことをあまり理解してないヤツだったのかな？
開発者一個人の問題だったら、責任とって更迭で、
弱点欠点をCellまで持ち越さないはずだもんな。

ユニファイドのシェーダが出てきたら(＋D3D10）、
Cellとほぼ同じ事になるだろうって点は同意だが、
それなりに用途を見つけて生き残れると思う。

＞GPUとCPUは、別にワンチップにまとめる必要など皆無
そっくりそのまま全てを一つにしてる訳じゃないでしょ。

それに、
＞形にするというが、両方を搭載したPCが市場に流通してるだけじゃ駄目なのかい？
＞なぜ単体じゃダメなのだ？
あくまでCPUの範囲で考えて下さい。
CPUの枠での演算能力ですよ。

必要なのは、システム全体の能力だろ
どうしてCPU単体の能力だけに限定しなきゃならんのだ？

話してるのは、CPU単体での話でしょ。

ええとね、とりあえず ID: LP4CTT/Sは放置した方がいいと思うよ。

GPU用途で使う演算ユニットまでCPUに内蔵したからといって、
GPU以外の用途に使う汎用性が著しく上昇するわけじゃないし、
GPU演算器の汎用性を高めるだけならPCでも実現しようとしてるのにか？

だいいち、それぞれのコアは、クロックが高いだけでIPC低すぎるだろ。

>>819
スマン、雑草の種に如雨露で水をかけるような行為をしてしまったな。







いや、決して、「話の種」とか「水掛け論」とか言いたいわけじゃないぞ。

そういえば月刊ASCIIに載ってたけど、Cellによるマンデルブロ集合の演算は速かったねえ。
Athlon 64 X2の数十倍だっけ？

AMDはコプロセッサ戦略を打ち出していくようだけど、コプロセッサを活かすにはソフトウェア
書き換えないといけないだろうから、どれだけ普及するものやら…。

てかCell信者はいい加減Cellスレ帰ってやれ。

はぁ？　Cell信者って俺のことか？
少しでもCellのことを良く言ったら信者認定か？

>>822
それは単精度かな。
マンデルブロ集合を見たいと思ったら、倍精度はほしいところ。

実際に、Cellを使えばそういう用途なら激しく速い。
GPUと比べては、汎用性ではるかに勝る。

Athlon64のようなCPUや、強力なGPUにも
当然よさはある。
ケースバイケースという当たり前の結論。

GK(sony.co.jp)が来てからすっかり糞スレになっちまった

>>824
「少し」ﾜﾛﾀｗｗｗｗｗ



俺が認定してやるから出ていきな。PS3なんてどーでもいいんだよｗ

>>827
よし、じゃあ俺はお前を「Cell信者認定厨」と認定してやろう。
お前ごときに命令されて、はいそうですかと出て行く奴がいるかいないかは分かるな？

CellだってCPUだと思うが、主な用途がPS3ってだけで
語っちゃいけないって事はないだろ

>>828
わざと？sageろ

Cell 64
http://game10.2ch.net/test/read.cgi/ghard/1151116507/

>>828
自分で粘着してますと自白してるのは分かるかな？ｗ

>>815
PS2のGSが、GPUとしては異質な存在になったように
汎用MPUがCellみたいな方向性に行き着いたとして、
Cellは同種のプロセッサとは異質な存在なんだろう。
…という意味で書いたんだけどな。

グラフィックベンダーとCPUベンダーが垣根を越えてしまったら
グラフィックのほうは汎用性をどんどんあげて物理演算コプロカードみたいな
位置づけになってくるだろうし、CPUのほうはグラフィックを侵食してメイン
プロセッサと連携するのにシステムバスがボトルネックになりませんよみたいな
流れでくるんじゃないかと思ったんだが。
まぁCellはそれをやろうとして能力不足で失敗したんだと思ったが。

インテルは独力でやれるだろうし、AMDは一時流れたATi買収の噂の狙いがそれかと思ったわ。

PS2って、結局は、ピーク性能だけ高いけど
常時運用の平均速度がPCより圧倒的に遅かっただろ

かな〜り使用条件を制限しないとPCより高速とはならず、
その後もPCやPC用GPUの高性能化が続いたから、
PS2発売の時点で、すでにPC以下の性能になってた。

GSがGPUとしては異質だった理由は、
性能面での不利さゆえに真似したくならなかったから。

必死にCell関連ネタ振り続けてるがその話したけりゃゲハのテクノスレかCellスレ池。
そんなネタ山ほど出てるぞ（というか100%がいしゅつ）。
有用な情報を収集したり議論したいならここに留まる理由は何一つないぞ。

どこかに雇われて何かを宣伝したくて無理やり留まってるなら話は別だが。

あらしに反応するやつもあらしって良く聞く話だけどな。

結局AMDはどういう方向に行くのかな？

もしnVIDIAがCPUを造ったらどんなアーキになるか予想するとわくわくするのだが...

ここってx86以外の話はだめなの？

>>836
当面K8の改良しかない、とも言われるけど、
AMDもそれなりに考えて他のプロジェクトを止めたはずなわけで。
SSE強化されるそうだけど、
対Intelでぶっちぎりのスピード、とか期待しなければ性能出るんだろうな。
モバイル・組み込みではGeodeNX消滅、アルケミー売却、AMD　Efficeonは確定。
>>837
鼬甲斐のような気もするが、このスレではOKっぽい。
個人的にはGSの性能は実は結構凄いんだけど、バスのスピードが全然足りなかったと思う。

ほんと無理やりだなｗ

>>839
無理矢理留まってる、と言いたいのかも知れないが俺は８３７以前、
少なくとも５０レスは書き込んでない。
それにGSも結局バスがダメだったから性能がでなかった、と言っているのだし。

ちょいと先になるが、AMDはアメリカに新工場を造るらしい。45nmのニクイ奴だ。
プロセスで後塵を拝している現在の状況が改善されればCoreと肩を並べることになるだろう。

32nmでしょ

>>841
すまん。俺が間違ってた。

GSってもはやCPUですらないわけだが

やっぱPowerPCが最強だな
Intelが作ったらの話だけど

Power PC 603 100MHzはヒートシンクすら付いてない低発熱だたよ。

無印603なんてアップルにダメ出し食らったヘタレCPUじゃないか。

そういえば良く爆弾マークで再起動したね。

それってPowerPCのせいなの？

いや、System7のせいだと思う。
１６MBでも良く動いたもんだと思うけど。

漢字Talkとか最悪だったんですけど

>>846
確かキャッシュが601の半分だったんだよね。
でもそれよりもさらにダメなのは3DO2に搭載予定だったFPUレスの602だったそうだけど？

ゲテモノテクノロジがきましたよ
>"Reverse(Anti)-Hyper-Threading"技術って、
>X2の2個のコアを結合し6IPC(3IPCx2個分)のシングルコアをエミュレートする技術とのこと(CONROEは4IPC)。

329 名前：Socket774[sage] 投稿日：2006/06/24(土) 23:36:08 ID:GbdsoFH3
http://nueda.main.jp/blog/archives/002203.html
パフォーマンス次第でAM2化けるなこれ。
939で出来れば神なのにｗ

336 名前：Socket774[sage] 投稿日：2006/06/25(日) 00:38:21 ID:W3KCOSqT
Intelも同じことやるそうですｗ
ケンツで4コアを1CPUにｗ

98 名前：Socket774[sage] 投稿日：2006/06/25(日) 00:33:05 ID:Utko172H
なんか似たようなのが…
CMT (Core Multiplexing Technology)
http://www.xtremesystems.org/forums/showthread.php?t=104178

バス経由とHTによるCPU直結で差が出そう。

Quadro化みたいなもんですね。

ビデオカードの奴か?
あれは使ってない回路を使うようにするんじゃなかったか。
むしろMAXXだろ。

MAXXは違うな。
あれだ、Voodooの2枚組。

GPUは偶数･奇数ラインどころかピクセル単位で容易に並列化できるけど
CPUのシングルスレッドをどう複数のCPUに並列化するのか見当もつかないな。

Kentsfieldでやるって書かれてるけど、Conroe/Meromでは無理なの？

Intel POWERﾏﾀﾞｰ

久夛良木とかいうアフォがCellで鯖云々とか医療云々とか
言い出したのがそもそもの原因だよな。

とどのつまり、>>834でFAだと思う。
以後Cellの話したいならゲハ板でどうぞ。

Cellを医療機器に搭載って、悪い冗談にしか聞こえない。
そんな医療機器で検査とか分析とかされたくないｗ

汎用PowerPC採用の医療機器なんて珍しいもんじゃないしな

CTのvoxelをSPEのネットワークで効率的に処理しようってのが
元々の安易な思いつきなんだろうケドCellなんて不要だな
どうしても演算能力必要ならASIC組めば良いし。

そういえば昔大腸内視鏡検査やったとき、
この動画処理装置ってPowerPC搭載なんですよって検査技師が言ってたな。
肛門のすさまじい異物感でそれどころではなかったけど・・・

ここの板住人が考える、最良なCPU構成ってどんなのだろう。
皆どんなのがいいと思ってるのか興味津々

AMD PowerPC

>>846

乗り越えれば、二度と後戻りできない未曾有の快感が待っている。

趣味グラマとしてはCellは最悪だな。
シングルコアがちょっぱやでその上デュアルなら言うことなし。
アーキテクチャは正直どうでもいいやｗ

趣味ならピーキーなCellは面白いんじゃないの？
SIMD系使わないんならあれだけど。

「Core Microarchitecture」の速さの秘密は“CISCの美”
http://pc.watch.impress.co.jp/docs/2006/0626/kaigai285.htm

PS3でffmpeg走らせてエンコでconroeやathlonFXを蹴散らします。

GK乙

>>871
まぁ、その、なんだ、がんばれｗｗｗ

もういいよ、クタラッシュ(AAry

>>871
エンコが早くなる可能性を全然想像出来ない。
4x2 か 2x4 かしらんけど演算用ロードでカコカコストールする様が見えます
1個当たり256byteのキャッシュ積んでなにができるのやら

他のPowerPCを使えばいいだけの話なので、問題ない

AMDの4×4。
http://pc.watch.impress.co.jp/docs/2006/0626/amd.htm

こんなもん、よっぽど金に余裕があるヤツじゃないとできんわなぁ…。
そもそも、合計で消費電力どれぐらいになるんだ？

>>877
ネトバよりは電気食わないしｗ
でごまかす

今まで通りな。

単純に2倍でしょ？
マザーがちょっと変で10万超えする位で
15万+12万x2+9万x2+諸々 = 60万 Windows黎明期のちょっと良いパソコンなら普通の値段

4×4はAMDが放つ壮大なギャグ

SONARって音楽製作ソフトじゃなかったっけ。
グラフィック性能要るのか?

えーと、AM2でデュアルソケットやるつもりなの？
Opteron 1xxxやAthlon64シリーズでもデュアルできるようになるって事かね。

2台買うよりは4x4の方が低消費電力で低価格なんだよ。
世の中パソコンだけではないのだよ。
どんだけ視野が狭いんだか。

激安Woodcrestと比較される可哀相な子だっけ? >>4x4

AMDのRHTとやらがどの程度のパフォーマンスを稼げるのか真面目に検討してみたい
気もするけど面倒になってきた
つーか大した性能出ないだろうしなぁ、普通に考えて

そもそもどういう仕組みかすらハッキリしてないから検討もできないだろ。
期待できる仕組みだとっしても物理的に配線遅延とかあって性能出ないかも知れんし。

>>881
グラフィック性能は、せいぜいマルチディスプレイができる程度のものがあれば十分だが、
CPUパワーはべらぼうにいる。

デュアルソケットでデュアルコアより、MCMでクアッドコアを出してくれた方が10倍ぐらい良いが、
MCMのノウハウをあまり持ってないとか、
従来のFXと同じクロックを実現しようとすると通常のクーラーとヒートスプレッダで冷却できる
熱密度の上限を遙かに超えてしまうとか、そういう事情はあるのだろう。

>>885
シングルスレッド性能では1年かけてほとんど上がってなかったから、X2登場と同時に導入して欲しかったねぇ
Pentium4/Dの少し上の性能に居続けたからConroeに手こずるわけだしな

インテル、コミュニケーションズ部門を6億ドルで売却
http://headlines.yahoo.co.jp/hl?a=20060627-00000015-cnet-sci

462 ： 名無しさん [sage] ：2006/06/24(土) 23:29:26
>>460
>>191のやつだね。
きちんと依存関係を見て実行したり、順番通りにリタイヤさせたりするのを、
一体どうやって実現するのかが非常に疑問だ。
何しろ、別コアでデコードされた命令との依存関係を調べないといけないのだ。
更に別コアの計算結果を数clkで引っ張ってきたりする必要もある。
これじゃもう巨大な1コアCPUのハイパースレッディングだよねえ。


472 ： 名無しさん [] ：2006/06/26(月) 03:10:08
実際にはこういうレベルでしかやれない気がする。

for ( i = 0; i < 10000; i++) a[i] = Foo( b[i] ) ;

↓

core0:　for ( i = 0; i < 5000; i++) a[i] = Foo( b[i] ) ;

core1:　for ( i = 5000; i < 10000; i++) a[i] = Foo( b[i] ) ;


474 ： 名無しさん [sage] ：2006/06/26(月) 16:59:25
>>469
都合のいい振り分けをCPUが考えるにも、デコードしないといけないし、
それでそれだけ他コアへの参照が発生するとなると普通なら無意味だよなあ。
まあ、IPC6を狙うというよりも、実効IPCが1.3のケースで1.5が出れば万々歳、
という技術だと思う。

>>472
それこそコンパイラが対応すべきでしょう。
ていうかそんな技術だったら（俺としては）期待外れもいいとこだ。
でもコア同士が密接に絡み合うって技術的にありえなそうだしなあ・・・。

479 ： 名無しさん [sage] ：2006/06/27(火) 00:30:42
>>472
それ何てOpenMP?
今OpenMPはVisualC++にも入ってるのでまともな規格なら普及するでしょう。

クラスタのようなものは複雑なのかもしれませんが、
単純ループをスレッドに分割するくらいなら簡単に出来るわけですから
基本的にはOpenMPを差し置いてわざわざ専用ソフトをこしらえるまでもないですし
IntelのCPU上でも同様に動くコードが出来上がるのでアドバンテージになりません。

逆に弱小AMDのCPUでしか動かないような代物(uOPsバイナリを吐くとか)であれば、
3DNow!の二の舞です。
OpenMPが使いにくい、まともじゃないというので
AMDが独自のツールを作るというのはアリですが、CPUの機能とは言えません。

>>885>>886
そう言えば、GPUもデュアルコアにドライバで最適化したんだっけ。

485 ： 名無しさん [sage] ：2006/06/27(火) 08:58:15
>>481
いや、デコードした「後で」振り分けないといけないということ（命令はデコーダを選べない）。
つまり、パイプラインの途中で命令を違うコアに送る必要が出てくる。
コア間通信の線を引っ張るコストはすごいと思うし、コアの設計をかなり変える必要がある。
また、振り分けを考えるのも大変な作業で、パイプラインが長くなると思う。

Core1がCore0の担当を予測することについては、Core1に入った命令を知る必要があるので
予測は不可能であり、高い通信コストをかけてCore0から教えてもらうしかない。

> 同じ事をマルチコアでやらせるのでは*無い*という事
うん、そこがこの技術のキモだと思う。これは本当に嬉しい。
しかし、だからこそ難しい。

以前（>>191のとき）あったFPUを共有というのはどうだろう。
6IPCという看板は実行ユニットだけで、デコード・リタイヤは3IPCに止まるというもの。
だが、
http://pc.watch.impress.co.jp/docs/2006/0522/kaigai_5.jpg
この辺りのレイアウトを見ると、各コアのSIMDユニットは物理的に離れまくっている。
それどころか、数clkでコア間通信なども、とても無理そうだ。
3GHzなら、1clkで光が10cmしか進めない世界だからねえ。

何か自分で書いてて絶望的な気分になってきたよorz
依存関係のチェックをしてOoOのスケジュールとか、順番にリタイヤとか、
ただでさえ電力食いと言われる重い処理なのに、違うコアにある命令とできるわけがない。

本物の6IPCが可能なら、とっくにシングルコアでそうしてるはず（デュアルなんか出さずに）。
できないけど、何かを捨てることで、デュアルコアで6IPCの仮想CPUを作れた。
いやあ、相当捨てないとできそうにないです。。

難しく考えるから難しい。
GPU見てみなよ。

これっぱかしも難しく考えてないと思うけどな
で、GPUの何を見ればいいの？

そこでクラスタの出番です

アウトオブオーダの意味がわかってない
コプロセッサの意味がわかってない

あm(ry　は所詮その程度

>>753
ttp://www.riken.jp/r-world/info/release/press/2006/060619/index.html
> インテル社製の最新のデュアルコア インテルR XeonRプロセッサー 5000番台（開発コード名： Dempsey）
> コアを256個搭載した並列サーバー64台と、インテルR XeonRプロセッサー 3.2GHz(2次キャッシュ1MB)コアを
> 74個搭載した並列サーバー37台を接続した大規模な構成
(中略)
> 同システムは、今後のさらなる性能向上に向け、次世代のマイクロアーキテクチャー、インテルR CoreTM マイクロ
> アーキテクチャーに基づくデュアルコア インテル Xeon プロセッサー5100番台（開発コード名：Woodcrest）に
> 移行する予定で、すでに検証作業を開始しています。

ttp://pc.watch.impress.co.jp/docs/2006/0626/intel2_13.jpg

すぐにお役御免になったDempseyｶﾜｲｿｽ

80286とかV33とかの32bitモードの方が可哀想

無理なもんは無理だし適してる処理ならいくつコアがあっても活用できるって事。
こんな簡単な事もわからない馬鹿さに気づいてない。
エンコを考えてみよう。
4っつのコアが一斉にビデオの先頭からエンコを始めると大混乱だ。
画面を4分割してみようか?
それも面倒。
ビデオを4っつに分割してそれぞれをそれぞれのコアでエンコさせるくらいの知恵はあるわけ。
4本のビデオを同時エンコさせるのと等価。
隣のコアが何やってるかなんて関係ない。
GPUは高度な演算を行うがピクセル単位、各パイプラインが独立して仕事できる。
そうなるようにマイクロソフトはDirectXを設計してる。

何つーか、下手なSFに出てくるいい加減な夢の技術の解説を読んでる気分です。

>>900
……で？

久しぶりにルネサスのホームページ見たらSH5という単語が絶滅していた。
まあいいんだが。

>>900
適している処理でもシングルスレッドで書かれていたら活用できないでしょ。
そういうケースでもデュアルコアを活用できたらいいなという話。
更に、デュアルコアでは高速化できない逐次処理を高速化する
可能性も秘めているので、本当だったらすごいことなわけ。

>>904
OpenMPもアムダールの法則もろくに知らないあふぉですか?

>>904
えーと、シングルスレッドなコードから複数のスレッドを抽出するって話ですか？

>>905
OpenMPが使えるのはコンパイル前じゃんか。
あとなぜアムダールの法則が出てくる。

>>906
そういう話も上で出ていたので。
実際どうかは知らない。

何をやっても並列化できない(逐次実行部)からアムダール則なんてものがあるわけで。
発見的手法で大規模な並列化をおこなうと問題が起きるからOpenMPやMPIなんてものがあるわけで。

要するに>>852はデマだと？まあそれは俺も思う。

>>906
だからそれがクラスタ