【CRISC】CPUアーキテクチャについて語れ【EPIC】3
- 1 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 18:46:03 ID:/wNwBa14
- 【天麩羅】
お前らいい加減、無能な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/
- 2 名前:Socket774 :2006/02/04(土) 18:48:52 ID:a8Z41XR/
- 2het
- 3 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 18:49:32 ID:/wNwBa14
- 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
- 4 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 19:05:50 ID:/wNwBa14
- 同じコード@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
- 5 名前:Socket774 :2006/02/04(土) 19:24:21 ID:fGs8Vom0
- その例ではVC++よりICCの最適化が優れている事はわかったが何が言いたいの?
斜め上を突っ走る人間のする事は理解できん。
- 6 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 19:29:54 ID:/wNwBa14
- VC++がアフォなだけかと。
- 7 名前:Socket774 :2006/02/04(土) 20:03:27 ID:heuhKxUf
- >>2-6
板違い帰れ。
- 8 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 20:16:16 ID:/wNwBa14
- もっとも、このコード自体あんま良くない。
アンロールしても依存関係で並列化できるところが少ないし。
分岐ペナルティの話にしても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++と似たようなレベルよ。
- 9 名前:Socket774 :2006/02/04(土) 20:23:46 ID:jHMZW75q
- Mac用にもIntelがコンパイラ提供するんだろ?
- 10 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 20:33:09 ID:/wNwBa14
- IntelがLinux版程度のものでも無償提供するかどうかは疑問だけどね。
また、IntelにしてみればObjective-C対応のコンパイラなんて作ってられないだろうし、
そうなるとコンパイラの使い分けが必要になったり。どちらにしろ開発者は苦労するね。
AppleがC/C++向けのフレームワークの開発再開してくれれば俺は喜んで禿について逝く。
Cocoa大嫌い。
- 11 名前:Socket774 :2006/02/04(土) 20:54:50 ID:RVjdZHR5
- 変な粘着が住み着いてしまいましたねorz
- 12 名前:Socket774 :2006/02/04(土) 21:22:16 ID:DNyS4NCb
- 細粒度のデータフローマシンがお好き?
- 13 名前:Socket774 :2006/02/04(土) 23:29:19 ID:9T+qF3Go
- >>糞固定
前のスレでも我慢してたがCPUアーテクチャを語るスレだといい加減気づけ。
というか、何を語りたいのか意味不明だから勘弁してくれ。
文章垂れ流しをしているようにしか見えないから。チラシの裏に(ry
いずれにせよ、かなりスレ違いだからさ、その辺を空気読めよ。
- 14 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/04(土) 23:57:24 ID:/wNwBa14
- まぁなんだ、CPUアーキテクチャの特性を知らずしてソフトの最適化を語るほど愚かではないから
基本的に突っ込まれたら知ってる範囲で問答しようぜよ。
何ならDinamic BindingやPolymorphismなどのオブジェクト指向的機能を取り入れた
コードを処理するのに有効な間接分岐予測の実装について小一時間でも。
MacOSはPentium Mベースのアーキテクチャに移行して正解かもわからんね。
JavaとかObjective-Cでありがちなスタック処理も間接分岐も強い。
こういう切り口でいくらでも議論は成り立つと思うがな。
無論当方とて別板別スレの同窓会やりたい気はないのだが、ストーカーって怖いものだね。
- 15 名前:Socket774 :2006/02/05(日) 00:02:38 ID:L0pHnhnR
- IBMはもうPC用よりもゲーム用等に適した作りのチップを作る事に力を入れたいから切り捨てたって事なんでしょうね、きっと…
- 16 名前:Socket774 :2006/02/05(日) 00:24:29 ID:e3rOXwOO
- サーバ用マルチコアの習作なんじゃないの?
- 17 名前:Socket774 :2006/02/05(日) 00:33:50 ID:bVzEMXwj
- > 知ってる範囲
公園の水溜りより狭く浅い知識で語られても迷惑千万だからもうくんな。
- 18 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/05(日) 00:36:30 ID:R0hFAHW0
- これでもR8CやSHも叩いたことあるが。あとGeForceのシェーダもな。
- 19 名前:Socket774 :2006/02/05(日) 00:39:45 ID:bVzEMXwj
- その程度の基礎的なことで知識があると勘違いしているのか。
いい加減そのみかん箱より狭い世界から外に出たほうがいいぞ。
- 20 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/05(日) 00:42:27 ID:R0hFAHW0
- >>19は博学らしいのでさぞ語ってくれるのだろうなwww
- 21 名前:Socket774 :2006/02/05(日) 01:00:26 ID:FSQuBh5V
- お前の個人スレじゃないんだから、
もちっと発言を減らせ。
- 22 名前:Socket774 :2006/02/05(日) 02:11:29 ID:Jfoz0fjZ
- >>団子
VC++の最適化が気に入らないならMS news groupや開発者blogとかに書けばいい。
意外にまともに対応してくれる事もあるぞ。まぁ、あのコードの意味は突っ込まれるかも
しれんがな・・・
gccの最適化が気に入らなければ・・・中略・・・自分でやれって言われるかもしれんがな・・・
どちらにせよDinamicとか書いている英語力では(ry
ところでRISCとCISCはカバーしているがEPICは叩いた事ないのか?
- 23 名前:Socket774 :2006/02/05(日) 02:30:25 ID:bVzEMXwj
- >>20
さんざ語ってきてるし他の連中も語ってきてるし、
何よりお前間違い指摘されても理解できてねーし。
そのちり紙より薄いプライドに泥塗られて火病る前にちったぁ雰囲気読め、吉外。
- 24 名前:Socket774 :2006/02/05(日) 02:40:28 ID:e3rOXwOO
- 団子が話に参加してもいいけど、団子の話するのはやめにしよう。
うざいものがよけいうざくなる。
PWRfecientとかそういうのの話はないのか。
- 25 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/05(日) 03:26:22 ID:R0hFAHW0
- >>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
- 26 名前:Socket774 :2006/02/05(日) 03:34:12 ID:lLevhF0Z
- コンパイラが馬鹿コード吐いて困ってます
コントロールレジスタを使わなくて済む整数キャスト用の命令付けてください
- 27 名前:Socket774 :2006/02/05(日) 03:43:12 ID:hWI4B0Pg
- そうだな、せっかくの良スレをたかが一匹の糞で潰すのはもったいない。
そういえばAMDとIntelでマルチコアへの見方が違うけど面白いな。
- 28 名前:Socket774 :2006/02/05(日) 04:59:03 ID:uWF8TQ8B
- RISCも何も普通にスケジューリングするとそうなる
- 29 名前:Socket774 :2006/02/05(日) 05:31:42 ID:R3agvamu
- パイプラインが導入された時点でフラグ変更命令とフラグ非変更命令の
入れ替えなんてのは普通にあったな。
- 30 名前:Socket774 :2006/02/05(日) 12:57:47 ID:cQxSzYmp
- OSもハードで実装した例とかってある?
めっちゃ軽そうやん?
- 31 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/05(日) 13:20:23 ID:R0hFAHW0
- >>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にチューニングされてるとは言いがたい。
- 32 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/05(日) 13:28:46 ID:R0hFAHW0
- 格納するアドレスが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
- 33 名前:Socket774 :2006/02/05(日) 13:48:57 ID:S6MmMDNc
- >>30
OS専用命令やハードウェアなら実装されている。
例えばMMU等ハードウェアや管理系命令、タスク間&マルチプロセッサ通信命令等。
- 34 名前:Socket774 :2006/02/05(日) 16:37:00 ID:FSQuBh5V
- >>25
> Itaniumは実機は叩いたことは無いがいちおう無駄に命令セットの概要は知ってるお。
知ったかぶり表明ですね。
勇気がありますな。
- 35 名前:Socket774 :2006/02/05(日) 17:56:15 ID:uWF8TQ8B
- SYMBOL
- 36 名前:Socket774 :2006/02/05(日) 19:04:17 ID:qQ2o4RPr
- シムボル
- 37 名前:Socket774 :2006/02/05(日) 23:52:29 ID:t2Dj6f++
- >>団子
スレ違いって何度も言われているのに何でVCの話を必死になって続けてるの?
- 38 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 00:24:12 ID:WwONqoe8
- 単に「MMX/SSEの最適化が出鱈目」ってことで脳内解決しとくわ。
ここには分岐予測のアルゴリズムについて語れる人が居ないということもわかった。
- 39 名前:Socket774 :2006/02/06(月) 00:42:00 ID:PiylUZTv
- 分岐予測の話題など出たこともないのだが
- 40 名前:Socket774 :2006/02/06(月) 01:00:20 ID:Ap7Hk9cA
- じゃあ消えろ
- 41 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 01:02:26 ID:WwONqoe8
- 確かに敢えて出さなかったがVCがフラグ値をなるべくjccの実行より早く更新させたがる理由を考える上で
分岐予測の機構は外せないだろ。
decやaddの命令のレイテンシはせいぜい1か2程度なので、ここまで必死にフラグ更新とjccの
実行タイミングに間を置きたがる理由は分岐がらみの問題以外に無い。
IntelのコンパイラがやるのはあくまでIntelの石向けの最適化なので、互換CPUでの最適化まで保障しない。
たとえばAMDやVIAの石だとマイクロアーキテクチャの実装がIntelとえらく違うのかな、とか。
AMDの最適化マニュアルはろくに読んだことがないので暇なときに目を通すけど、徒労に終わるかもしれんね。
- 42 名前:Socket774 :2006/02/06(月) 01:05:43 ID:XuA1ZqCo
- ここはコンパイラ屋さんがくる所じゃないよ
- 43 名前:Socket774 :2006/02/06(月) 01:11:29 ID:PiylUZTv
- 分岐予測はフェッチ時にやるんだよ馬鹿
- 44 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 01:21:05 ID:WwONqoe8
- >>42
ベクトル型にしろスカラ型にしろ、ハードの特性を生かす有効な最適化手法を知らずに
ハードについて語れることなんてほとんど無い気がするけど
>>43
その通りだよ。
現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
でもフェッチはインオーダだろ。
- 45 名前:Socket774 :2006/02/06(月) 01:54:27 ID:D8mPbwi+
- 手段と目的が入れ替わっとるとは思わんですか?
最適化はプログラマの手助けであって、CPUの高速化ではなかった(少なくとも最初は)
CPUの目的はインストラクションの実行ではなく、データ演算のためだった(少なくとも最初は)
パソコンの目的は速さを競うためではなく、何かアプリを動かすためだった(少なくとも最初は)
- 46 名前:Socket774 :2006/02/06(月) 02:16:31 ID:/GIML5Lw
- > ベクトル型にしろスカラ型にしろ、ハードの特性を生かす有効な最適化手法を知らずに
> ハードについて語れることなんてほとんど無い気がするけど
明らかに遅いコードを見てアーキテクチャを語る事は無駄だな。
団子はこのスレに池。
x86命令の所要クロック計測スレPart2
http://pc8.2ch.net/test/read.cgi/tech/1136527588/
> 現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
instruction decoderがsymmetricでない場合は問題がある。
- 47 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 02:28:15 ID:WwONqoe8
- そのスレなら見てるよ。目ぼしい知識はないから書き込みはしないけどね。
> > 現行のx86互換アーキは実行はアウトオブオーダだから命令の並びなんてたいした問題じゃない。
> instruction decoderがsymmetricでない場合は問題がある。
ほらそうやって論点をずらす。問題はフラグ変更とjccの関係。
- 48 名前:Socket774 :2006/02/06(月) 03:09:54 ID:JfWCHSaN
- 馬鹿だなぁ。
お前のオナニースレの間違いを指摘しただけ。
間違いを指摘されて開き直る馬鹿相手に議論なんて無意味だし
議論していないんだから論点なんて存在しない。
- 49 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 03:21:18 ID:WwONqoe8
- > instruction decoderがsymmetricでない場合は問題がある。
俺が話題を限定して言ってるのは明白なのにこんなわざわざ知ってる範囲のことを得意げに
語られても困るって話よ。ID違うけど何か工作中だったのかな。
「お前のスレ」か。じゃあ俺に所有権認めたのね。じゃあこのスレに書き込まないでくれる?
- 50 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 03:26:22 ID:WwONqoe8
- ついでに言うが「thread」と「response」を間違えたと言い訳するならますます墓穴ですよ
このまったく非なる語彙をうっかり間違えるようなのはコンピュータ技術について語る以前の問題なので。
- 51 名前:Socket774 :2006/02/06(月) 03:28:32 ID:JfWCHSaN
- 「の」には所有以外の意味もある事はしらないのですか?
- 52 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/06(月) 03:32:50 ID:WwONqoe8
- ここを「オナニースレ」といったことは肯定しつつ苦しい反撃しますかwwww
朝早いんで寝るよ。昼寝したから眠くないけど。
- 53 名前:Socket774 :2006/02/06(月) 04:11:59 ID:XuA1ZqCo
- >>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
- 54 名前:Socket774 :2006/02/06(月) 05:24:05 ID:6FhlB5zU
- どうみても団子の立てた団子のオナニースレです。
本当にありがとうございました。
- 55 名前:Socket774 :2006/02/06(月) 05:57:13 ID:6FhlB5zU
- スレの所有権を宣言するウンコwww
- 56 名前:Socket774 :2006/02/06(月) 07:04:44 ID:731q5lFg
- プログラム板で相手にされなかったからって、
他板の良心的スレに張り付いて荒らし続ける人って嫌いです
- 57 名前:Socket774 :2006/02/06(月) 08:17:13 ID:gCeKaASj
- MACヲタよりはマシだけどな
- 58 名前:Socket774 :2006/02/06(月) 10:26:49 ID:JfWCHSaN
- MACヲタは間違いを認めるので団子よりマシ
- 59 名前:Socket774 :2006/02/06(月) 11:16:22 ID:fJavgCyo
- 何の役にもたたねーし間違い指摘されても理解できてねーし
マジで荒らし以外の何物でもないよな。せめて便所ネタでも書けりゃいいのに。
- 60 名前:Socket774 :2006/02/06(月) 19:18:16 ID:Ej94t4LI
- 2-60を透明あぼーんで桶?
- 61 名前:Socket774 :2006/02/06(月) 23:21:08 ID:VVojhyI+
- >>56
団子は鳥屋に勝った香具師だ見くびるな
- 62 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 00:34:16 ID:T7yiuvqt
- MSのコンパイラの動きはバグとかじゃなくて何か確信をもってやってるように見えたんでね。
x86で「遅延分岐」が有効かどうか?
MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを
フラグ確定だけ先に持ってきても、どのフラグを使うか、どこにジャンプするかの情報はJCCのほうにあるわけだから
意味ないようにも見える。事実Intelコンパイラはこんな動きをしてない。
Intel CPU以外の何かでは役に立つ情報なのかもしれない。
かわりにIntelコンパイラがVC++より多めに吐いてるものがtestやcmpなどの比較命令だが、コレは実は(以下自制)
このへんの理屈は分岐予測の実装に絡んでくるはずなんだな。
まぁ先にも指摘があるようにこのへんは基本的にブラックボックスなので想像に頼るしかないところは多いと思う。
この話題はム板に丁度その議論やってるスレ(メロンアイス鳥つけてる人のスレじゃないよ)見つけたんで
そっちで投げてみるわ。今は反芻している。
>>55
まぁべつに長居する気はないが「お前のスレ」って言われれば「じゃあ命令される筋合い無いね」って切り返すのは
当然と思いますが、何か?
以下めんどくさいので略
- 63 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 00:35:46 ID:T7yiuvqt
- -MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを
+MSのコンパイラの例の動きは、フラグを早期に確定させることでパイプラインハザードを回避or軽減するためのものでは?
- 64 名前:Socket774 :2006/02/07(火) 00:57:41 ID:1pSEKBge
- >>62
> MSのコンパイラの動きはバグとかじゃなくて何か確信をもってやってるように見えたんでね。
バグでも特別な処理でもなく、普通にスケジューリングするとそうなる(こともある)っつの。
> x86で「遅延分岐」が有効かどうか?(以下略)
全く意味不明
> このへんの理屈は分岐予測の実装に絡んでくるはずなんだな。
どこがどう絡むのか、想像でもいいから書いてみろや。
- 65 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 01:12:35 ID:T7yiuvqt
- 改めて聞くけど、>>32も、普通にスケジューリングするとそうなる範囲内?
自論は、「Intel CPUにはあくまで無意味」だが、何か別のアーキテクチャの分岐処理では有効な
スケジューリングじゃないかという話。
遅延分岐って知らない?RISCとそのコンパイラでよく使われた最適化手法だけど。
分岐先判明後に数命令、どっちに分岐しても悪い作用の無い命令を続けることっで
分岐のペナルティを回避するというやつ。
フラグ更新とjccの間の命令数命令が、ある何かのアーキテクチャでは、
パイプラインストールを隠蔽するために使われるのでは、という仮説。
まぁこれはむしろ分岐予測じゃなくて分岐確定後の処理寄りだけどね。
- 66 名前:Socket774 :2006/02/07(火) 01:25:41 ID:1pSEKBge
- >>65
> 改めて聞くけど、>>32も、普通にスケジューリングするとそうなる範囲内?
そうなる範囲内
> 遅延分岐って知らない?RISCとそのコンパイラでよく使われた最適化手法だけど。
遅延分岐はハードウェアの話だ。
x86に遅延分岐が実装されたことは一度もない。
> フラグ更新とjccの間の命令数命令が、ある何かのアーキテクチャでは、 パイプラインストールを隠蔽するために使われるのでは、という仮説。
大抵のアーキテクチャでは、一般的に(条件コードを含めて)データ依存関係のある場合はそうなる。
どうでもいいがパイプラインストールを隠蔽というのはおかしな言い方だぞ。
> まぁこれはむしろ分岐予測じゃなくて分岐確定後の処理寄りだけどね。
だから分岐予測は全然関係ねーの。
- 67 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 01:34:10 ID:T7yiuvqt
-
>大抵のアーキテクチャでは、一般的に(条件コードを含めて)データ依存関係のある場合はそうなる。
依存関係ね。はい。
これをやらないと、具体的にどこどこに依存関係の問題が発生するのでしょうか?
あと、ICCの最適化ではjccの直前でcmpやtest命令を発行しフラグ変更してますがこれは悪い例ですか?
>>66
分岐予測はフラグ変更を監視してるんじゃないんの?今の仮説にはたしかに直接は関係ないけど。
- 68 名前:Socket774 :2006/02/07(火) 01:58:50 ID:cJz9J2jA
- 何をしたいんだコイツ?空気読めない馬鹿って本気でウザいな。
誰一人として支持すらしてくれないのによくやるよ…自己満足甚だしい。
- 69 名前:Socket774 :2006/02/07(火) 02:01:19 ID:1pSEKBge
- >>67
> これをやらないと、具体的にどこどこに依存関係の問題が発生するのでしょうか?
一般的には、データフローグラフを幅優先でtraverseすると並列度の高いコードができる。
そうすると自動的にproducerとconsumer命令の間に無関係の命令がたくさん入りこむ。
実際はリソースの制限があるのでもっと複雑なスケジューリングをやってる。
> 分岐予測はフラグ変更を監視してるんじゃないんの?
してない。
分岐のresolveにはもちろんフラグの値が必要だが、分岐を予測する時はフラグは見ない。
- 70 名前:Socket774 :2006/02/07(火) 02:05:39 ID:JmLLwh9p
- MIPS、マルチスレッディング対応の32bitコアファミリを発表
ttp://pc.watch.impress.co.jp/docs/2006/0207/mips.htm
- 71 名前:Socket774 :2006/02/07(火) 02:07:39 ID:OmAJCc74
- >>67
>分岐予測はフラグ変更を監視
分岐予測なのにフラグを監視してどーする。予測じゃねーじゃんw
- 72 名前:Socket774 :2006/02/07(火) 02:11:15 ID:DYVyuZtY
- > 分岐予測はフラグ変更を監視してるんじゃないんの?
( ゚д゚)ポカーン
- 73 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 02:36:08 ID:T7yiuvqt
- あれ?jcc発行時の履歴だけで判定してんだっけ?
フラグ値の変化も予測に反映されてる筈だが?
まあいいや。
>>69の説明じゃ、再三逝ってる、最終のフラグ変更とjccの間の不自然な間隔の説明になってない罠。
依存関係ならたとえばpmovmskb直後のmov [mem], dxにだってある。
[eax+ecx+1]なんてやったら命令長が増える。そこまでしてやる必要のあることか?
全部その理屈で説明可能?
故意にか回答を避けられてるようだがICCについても薀蓄よろしく。
スケジューリングがまったく別物なのでそもそも無理か。
うちはいちおういろいろ並べ替えてみてパフォーマンステストは行っているが合理的に正しいという結論に達した。
- 74 名前:Socket774 :2006/02/07(火) 02:47:09 ID:QLjPXeIe
- いつも楽しみにこのスレを覗かせてもらっている者です
最近知ったかぶりをみんなでいじめる書き込みばかりで読むのが嫌になります
でも分岐予測はフラグ変更を監視うんぬんという発言は致命的すぎます
- 75 名前:Socket774 :2006/02/07(火) 02:58:37 ID:1pSEKBge
- >>73
> フラグ値の変化も予測に反映されてる筈だが?
どっからそういうウソ知識を。。。
分岐予測は基本的には分岐命令のアドレスと分岐履歴しか使わん。
> 最終のフラグ変更とjccの間の不自然な間隔の説明になってない罠。
おまいはdec eaxが一体どこにあれば自然だというんだ。
dec eaxとjccの間にはループ本体があるだけじゃん。
iccもべつにおかしくはないだろ。こんな短いコードならどう並べたところで大差ない。
P6以上ならdec-cmp-jccでuopsフュージョンやってるかもしれん。
- 76 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 03:02:08 ID:T7yiuvqt
- 致命的なのは文脈上どうみても勘違いしたとしか思えない「スレ」と「レス」の間違い以上のものはないかと。
もちろん、古典的な分岐予測システムは分岐方向・アドレスの履歴テーブルを使ってるのは承知なんだけどさ、
ループ検出器の機構を頭の悪い俺に説明してくれない?
- 77 名前:Socket774 :2006/02/07(火) 03:11:06 ID:1pSEKBge
- >>76
> もちろん、古典的な分岐予測システムは分岐方向・アドレスの履歴テーブルを使ってるのは承知なんだけどさ、
使ってない。
> ループ検出器の機構を頭の悪い俺に説明してくれない?
お前の脳内機構の説明もできない。
- 78 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 03:14:14 ID:T7yiuvqt
- >>75
μOPsフュージョンが命令の「再結合」だと思ってる人発見wwww
> P6以上ならdec-cmp-jccでuopsフュージョンやってるかもしれん。
ホームラン級の(ry
μOPsフュージョンてのは
従来P6ではレジスタ・メモリ間オペレーションは、メモリロードとオペレーションに分離して処理してた。
2つ以上のμOPに分解するのは複雑なアルゴリズムが必要なので、3つのデコーダのうちの
1つComplexDecorderパスでしかデコードできなかった。
(VC++では今でも/G6ではメモリ・レジスタ間オペレーションの生成をなるべく避ける)
Pentium Mでは、デコードステージで分解せず1つのμOPとして扱い、そのままスケジューリング→
実行前のステージで分離→実行→再結合してからリタイヤという機構を導入したの。
それで3割ほど内部効率があがった。
決して既存のx86命令を結合する技術じゃないよ。
- 79 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 03:31:08 ID:T7yiuvqt
- μOPsフュージョン知らないならPenMの分岐予測器の実装も知るわけ無いよな。
ちなみにループ検出器ってのはPentium Mに搭載された履歴を使うのではなく、ループ回数を完全にカウントして
完全に分岐方向を当ててしまうものなんだけど、当然ながらこいつにはBTBなんて使ってない。
Pentium II/IIIあたりの時代のIA32最適化マニュアルに分岐予測の実装について詳細に述べられてた。
韓国の大学のFTPサイトになぜか古いのが上がってたりしたが今は多分無いな。
最新のはどれも概要的なことしか載ってない
- 80 名前:Socket774 :2006/02/07(火) 03:38:17 ID:JmLLwh9p
- ftp://download.intel.co.jp/jp/developer/jpdoc/iaopt_j.pdf
これか?
- 81 名前:Socket774 :2006/02/07(火) 03:41:35 ID:QLjPXeIe
- 小さいループは最近数回の履歴からグローバルパターンテーブル参照の機構でいけるけど
でっかいループを検出する「ループ検出器」がどんなアルゴリズムになってるかは謎だな
とはいえ、少なくともフラグ監視なんて発想は出てこないと思うぞ
>>BTBなんて使ってない。
BTBは使ってるだろ
- 82 名前:Socket774 :2006/02/07(火) 03:47:17 ID:qLVExI4Y
- 俺的にはμOpsフュージョンがホームラン級なら、
分岐予測にフラグ監視はグランドスラム級、
レスとスレはシングルヒット級
だな。
- 83 名前:Socket774 :2006/02/07(火) 03:59:46 ID:xyTVTZE7
- >∀<)っ-○●◎- ◆Pu/ODYSSEYは、しゃべり杉
自分のWebサイトでやれよ。
2chでは他の発言者を尊重して自重しろ。
- 84 名前:Socket774 :2006/02/07(火) 04:05:46 ID:qLVExI4Y
- >>83
無理言うな。
一連の流れを見ればそんな社会性のある奴じゃない事はわかる。
録音、503、メカと同類。
- 85 名前:>∀<)っ-○●◎- ◆Pu/ODYSSEY :2006/02/07(火) 04:19:45 ID:T7yiuvqt
- >>80
そいつそいつ。
ループ検出器の作動条件を調べてみるとええかもね。
いわゆるfor文は後置に展開されるけど、ループ検出が効いてない状態だと、BTBは前方ジャンプで埋まってるだろうから
ループを抜けるときに分岐ミスするのは想像に難くない。
でだ、ICCがループ毎にcmp/testを生成する理由ってのは(ry
> >>BTBなんて使ってない。
> BTBは使ってるだろ
ループ検出器で扱えないものをBTBを用いた動的分岐予測器で扱うという意味では正解だけど
ループ検出器自体はBTBを持ってないよ。
http://www.intel.co.jp/jp/developer/technology/itj/2003/volume07issue02/art03_pentiumm/p05_branch.htm
- 86 名前:Socket774 :2006/02/07(火) 04:57:16 ID:QLjPXeIe
- > ループ検出器で扱えないものをBTBを用いた動的分岐予測器で扱う
何か勘違いしているようだが、BTBはジャンプのターゲットアドレスを保持するバッファだぞ
ターゲットの情報も使わずにどうやって分岐予測するんだ?
まあ、分岐履歴テーブルなども含めて集合的にBTBと呼ぶ、と書いてあるが
- 87 名前:Socket774 :2006/02/07(火) 05:02:06 ID:1pSEKBge
- >>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
分岐履歴のかわりにカウンタとリミットで判定してるぽいな。
- 88 名前:Socket774 :2006/02/07(火) 05:27:21 ID:EVPY3bqX
- あんたら職業柄こういうことに詳しいのかい?それとも情報工学科の院生さん?
プログラムが趣味でこんなことまで知ってるの?
- 89 名前:Socket774 :2006/02/07(火) 08:14:49 ID:OsoCAvfd
- >>65
> 遅延分岐って知らない?RISCとそのコンパイラでよく使われた最適化手法だけど。
ヴァカか。最適化手法じゃネーヨ。プロセッサデザイン上の実装のひとつだ。
知ったかは( ・∀・ )スッテンロ!
- 90 名前:Socket774 :2006/02/07(火) 10:05:58 ID:Cm8yp0q/
- >>84
録音といい団子といいセーラームーンといい、まともな議論できないと
自論押し付けてくる馬鹿ってなんとかならねーかなぁ。
- 91 名前:Socket774 :2006/02/07(火) 10:10:05 ID:Okxr04QJ
- まともな議論というかそもそも説明自体ができなくなってだな、
そのまま何度も同じことを繰り返すだけになるんだよな。
だから壊れたテープレコーダ→録音と呼ばれているわけだが。
- 92 名前:Socket774 :2006/02/07(火) 10:37:39 ID:1eHiBY0i
- 遅延分岐はなぁ…必要悪の類だろ(w
- 93 名前:Socket774 :2006/02/07(火) 12:36:26 ID:dWzBEOZA
- 気に入らないならほっときゃいい筈だが、答えてる人もいるからな。
そういう人は結局よしとして受け入れているのだろう。
ま、俺は別にこの手の話は嫌いじゃない
んで暫くはかまわんけど。
- 94 名前:Socket774 :2006/02/07(火) 13:53:18 ID:pXD+EW1c
- こんな間違った情報を垂れ流す電波野郎を放置するのは百害あって一利なし。
- 95 名前:Socket774 :2006/02/07(火) 14:20:58 ID:Okxr04QJ
- 「遅延分岐」という言葉も正しい意味で使えてないしな。
- 96 名前:Socket774 :2006/02/07(火) 16:02:40 ID:oozlk2es
- 団子タンはヘネパタ&パタヘネからやり直しという事で。
- 97 名前:Socket774 :2006/02/07(火) 16:33:21 ID:f6K5ua3V
- 半端な知識でコンパイラの最適化云々いう奴はDPDAとかLR(1)を知らなかったりするんだよなぁ。。。
- 98 名前:Socket774 :2006/02/07(火) 23:17:59 ID:iaEEuOuz
- >>97
おいおい、また半可通の講釈が始まるぞww
- 99 名前:Socket774 :2006/02/08(水) 02:14:53 ID:JbpupqZe
- それじゃあパパは、BNFで最適化コンパイラ書くぞっと
- 100 名前:Socket774 :2006/02/08(水) 15:09:17 ID:7NCqBuUQ
- こうしたほうがいいと言うなら
自分でコンパイラを作ればいいのにね。
- 101 名前:Socket774 :2006/02/08(水) 15:16:54 ID:eHW2h/5O
- 「言語処理の専門家」キタ?
- 102 名前:Socket774 :2006/02/09(木) 01:51:38 ID:4vE2Bya9
- 昔クロックがないMPUが発明された話聞いたけどあれどうなったのかなぁ……
- 103 名前:Socket774 :2006/02/09(木) 09:03:03 ID:Vtw04e8P
- 別に、発明っつか、普通に非同期設計のプロセッサぐらいできるよ
性能出ないけど
- 104 名前:Socket774 :2006/02/09(木) 09:36:35 ID:oPfcCjQ3
- というかバグ取りが悪夢。
- 105 名前:Socket774 :2006/02/09(木) 18:34:48 ID:V3PNXmqQ
- IBM、Powerを2倍高速にする手法を開発
http://www.itmedia.co.jp/news/articles/0602/07/news070.html
- 106 名前:Socket774 :2006/02/09(木) 21:28:37 ID:Vtw04e8P
- 歪なんちゃらってやつ?
- 107 名前:Socket774 :2006/02/09(木) 21:38:29 ID:ET3DgZF8
- 絶縁層でシリコン層を押しつぶしてどうこうと言ってるが。
とりあえず俺の知識では全面降伏。
つかシリコン層を押しつぶすとシリコンの挙動がどう変わるのかなんて知らん。
- 108 名前:Socket774 :2006/02/09(木) 21:39:47 ID:sLZV+qKh
- 不正尻子って何だ?
- 109 名前:Socket774 :2006/02/09(木) 22:05:11 ID:okADDKmc
- 絶縁層で区切って二層にするとかそういうこと??
- 110 名前:Socket774 :2006/02/09(木) 22:27:24 ID:Lp2MxNKU
- 絶縁層ってのは厚さからして現行のPD-SOIだろ。
押しつぶすってことは圧縮ってことだから歪Siってことじゃねーの。
> しかし、このプロセスではプロセッサが過熱する傾向がある。
ってのはSOI特有のSelf-Heating現象かね。
絶縁層が同時に断熱層になってしまい熱が籠もりやすいってやつ。
素人だから知ってる単語並べてみただけだけど。
- 111 名前:Socket774 :2006/02/14(火) 00:03:23 ID:xo/CLeFH
- NECエレ、16bitマイクロコントローラを復活
http://pc.watch.impress.co.jp/docs/2006/0214/nec2.htm
- 112 名前:Socket774 :2006/02/18(土) 17:23:57 ID:XoZZ4UWP
- UltraSPARC Architecture 2005
- 113 名前:Socket774 :2006/02/20(月) 13:27:26 ID:E9Ddttt3
- 今までで一番エレガントな命令セットはどれだと思う?
- 114 名前:Socket774 :2006/02/20(月) 13:42:48 ID:3+WRFWR2
- x86
- 115 名前:Socket774 :2006/02/20(月) 16:41:40 ID:dnzLM+sn
- >>114
ワラタ
- 116 名前:Socket774 :2006/02/20(月) 22:53:31 ID:YwRVgdLP
- MIPS R2000
- 117 名前:Socket774 :2006/02/20(月) 22:57:02 ID:p7W1CHLu
- Z80
- 118 名前:Socket774 :2006/02/21(火) 00:06:40 ID:VU77Lx6U
- 4004
- 119 名前:Socket774 :2006/02/21(火) 01:04:35 ID:NroXVXcz
- MC68000
- 120 名前:Socket774 :2006/02/21(火) 06:33:09 ID:mMPL3wkC
- mips2 も捨てがたいがここはひとつ
6502
- 121 名前:Socket774 :2006/02/21(火) 15:52:45 ID:n7gh1yu1
- 68000に一票
- 122 名前:Socket774 :2006/02/21(火) 16:20:13 ID:5oqk4m3P
- 68000はアドレスレジスタとデータレジスタが分かれているのがアレなんだよな。
V810といってみるのはどうだろう?
#V850とかではなく。
- 123 名前:Socket774 :2006/02/21(火) 18:28:45 ID:jsdo1oUO
- V800系ならV83x。
Super8と言って見たいが既にあれはSamsung8状態だしなぁ。
やっぱり6502に一票かな…
- 124 名前:Socket774 :2006/02/21(火) 20:08:01 ID:0zThO1iI
- 68060
- 125 名前:Socket774 :2006/02/21(火) 20:08:01 ID:dIsrB587
- ふつーに Alpha。
MIPSも悪くないけど、ロードの遅延スロットとかディレイドジャンプ
とかイラネ。
- 126 名前:Socket774 :2006/02/21(火) 20:47:36 ID:6GCQdzEn
- Am29000
- 127 名前:Socket774 :2006/02/21(火) 21:23:43 ID:E/17w4ho
- TMS9995
- 128 名前:Socket774 :2006/02/22(水) 00:04:46 ID:n97Dg4Wl
- 6809
- 129 名前:Socket774 :2006/02/22(水) 01:34:42 ID:ypNDgYD5
- 6809は命令エンコードが非対称なのでキライ
- 130 名前:Socket774 :2006/02/22(水) 02:36:40 ID:/3gm55vG
- Efficeonとか言ってみる。
……エレガントかどうかなんてどうでもいいよな。CMS使うんだもん。
- 131 名前:Socket774 :2006/02/22(水) 10:23:56 ID:eaTnyYg9
- >>130
内部命令がエレガントかどうかが問題となる。
- 132 名前:Socket774 :2006/02/22(水) 12:03:07 ID:cUz0VUBW
- 68030
- 133 名前:Socket774 :2006/02/22(水) 15:23:31 ID:ypNDgYD5
- ある意味エレガントなんだろうが、68kみたいなゴシック調のもキライ
- 134 名前:Socket774 :2006/02/22(水) 16:18:26 ID:nZmGp9+y
- NS32032
- 135 名前:Socket774 :2006/02/22(水) 22:20:31 ID:ypNDgYD5
- 初期のDSP
- 136 名前:Socket774 :2006/02/22(水) 23:44:13 ID:rBMRXNxN
- ビッグエンディアンの8ビットって何考えてんだろ
- 137 名前:Socket774 :2006/02/23(木) 00:15:23 ID:qHt0mZ5T
- Nexgen 6x86
- 138 名前:Socket774 :2006/02/23(木) 00:48:38 ID:mvUTKJ11
- >>135
具体的に
- 139 名前:Socket774 :2006/02/23(木) 01:49:54 ID:GXlceMLV
- SH4は結構いいCPUだと思うぞ。
性能そこそこ低消費電力で組み込みにはいい石だ。
個人的にはARMより好きだな。
- 140 名前:Socket774 :2006/02/23(木) 02:04:08 ID:RrjfMIfv
- >>139
そんな感じのネタふりを前俺がやった。
でも冷静に考えてみれば消費電力は組み込みにしてはでかいんじゃない?
DDR2使えるからそれでも良いのか?
そうだ、命令セットを挙げなきゃいけないんだ。
う〜ん……ペンティアムバイナリ?
- 141 名前:Socket774 :2006/02/23(木) 02:35:24 ID:GXlceMLV
- いやARMはサムコードとか変態命令セットが嫌いなだけ。
- 142 名前:Socket774 :2006/02/23(木) 08:26:57 ID:GUCLmJn2
- >>135
初期のDSPなんてマイクロコード剥き出しって感じで
エレガントとは程遠いものだったような気がするんだが。
- 143 名前:Socket774 :2006/02/23(木) 09:09:55 ID:hqrYJtBk
- 命令長が長い割にレジスタ少ないしな<ARM
- 144 名前:Socket774 :2006/02/23(木) 15:32:31 ID:R3leZ2BK
- SHって、遅いんだよな
安価で低消費電力のARMと、ハイエンドのMIPS、PowerPCに挟まれてって感じ
- 145 名前:Socket774 :2006/02/23(木) 16:35:04 ID:m3K1zOUq
- そんなに遅くは無いと思うけど…
発展とかクロック向上って意味なら取り残された感が出てたけどね(^^;
つい最近、400MHzのSH4が出てきたけど。
…まぁ会社が悪いと言えばそうなんだが…
そもそも、あそこは何をプッシュしてんだかさっぱり解らん。
旧H系だけでもH8SやH8SXの性能向上が激しいからSH2は収束なのかなぁ?とか思うし。
- 146 名前:Socket774 :2006/02/23(木) 18:38:07 ID:avKm/ZbK
- 最近出たのは600のはず。発表値では1000MIPS超える。
命令セットが違うのであてには出来ないけど。
性能的にはSH4だけどARMの売りはソフトウェア資産なんだよね。
LINUX端末でも出てくれればなぁ。POCKETPCはあてに出来ないし。
- 147 名前:Socket774 :2006/02/23(木) 18:43:15 ID:lrtvsn70
- 64-wayアートネイチャー
- 148 名前:Socket774 :2006/02/24(金) 03:29:06 ID:gDVVYa5C
- >>142
プリミティブアートみたいなもん
- 149 名前:Socket774 :2006/02/24(金) 06:09:26 ID:gDVVYa5C
- 68kは壮麗なISAを目指したはいいが、最後になってリソース不足でアドレス・データレジスタを分離したり
32ビットオフセットのアドレッシングモードを実装できなかったりした印象
6809も、あれやこれやと詰め込もうとしてオペコード足りなくなったんじゃねーの
- 150 名前:Socket774 :2006/02/24(金) 07:02:15 ID:1CuPRhxv
- >>148
どこがエレガントなんだw
- 151 名前:Socket774 :2006/02/24(金) 09:24:19 ID:p0pIph+7
- >>149
レジスタ作りすぎでオペコードを圧迫したRCAのCOSMACという例も。
- 152 名前:Socket774 :2006/02/24(金) 12:45:11 ID:U4Jzovoz
- PowerPC ISAはだめですか
- 153 名前:Socket774 :2006/02/24(金) 22:44:08 ID:p0pIph+7
- 去年の「情報処理」のプロセッサ特集(No.)10、11遅まきながら読んだけど、
汎用を狙ったアーキテクチャは面白いのがないよなぁ…
タイルとかリコンフィギャラブルとかは面白いけど特定用途狙いみたいだし。
それはともかくアウトオブオーダープロセッサが10年前のIPCを保つために
どれだけのリソースを食ってるかは考慮の外なんだろうか?>特集のまとめ人
- 154 名前:Socket774 :2006/02/24(金) 22:45:03 ID:p0pIph+7
- (No.)10、11
↓
(No.10、11)
- 155 名前:Socket774 :2006/02/25(土) 08:13:53 ID:TK7IiXie
- 65系イイ!
- 156 名前:Socket774 :2006/02/25(土) 08:21:38 ID:pppxzFHI
- 配線遅延のせいで、リコンフィギュアラブルプロセッサとか
ゲートアレイはクロックがあがらなくて、汎用プロセッサに勝ちにくいんだよな
もうIAしかないのかと
- 157 名前:Socket774 :2006/02/25(土) 10:24:47 ID:2335KuUB
- アセンブラ書いてた人なんだけど、プロセッサの構成とかデータシート上の話
ばっかりしてて面白いのか?
とかおもいました。
x86と68000とSHとH8とPICと8080とZ80書けます。
どうかんがえてもgccで最適化かけたほうがはやいのですが、
gccはgdbの使い方がわからんので使いません(お
- 158 名前:Socket774 :2006/02/25(土) 10:33:14 ID:PyBhEFs5
- 楽しみ方は人それぞれ。
アーキテクチャオタからすればアンタのやってる事見て「似たような
プロセッサで代わり栄えのしないプログラム組んで何が面白いのかね」
と思うわけよ。
>>156
上にあれこれ載るようになってプロセッサのアーキテクチャなんか、
プログラムの書きやすさと関係なくなったから、順調に性能が上がる
分にはIAでも文句は出ない罠。
- 159 名前:Socket774 :2006/02/25(土) 10:38:34 ID:2335KuUB
- なにってそら、バグをだしてまともに動かないプログラムを、きちんと動くようにする
その工程が、いわゆるツンデレ攻略なわけですよ。
萌えませんか?
- 160 名前:Socket774 :2006/02/25(土) 10:59:02 ID:7lzQooue
- 全然
- 161 名前:Socket774 :2006/02/25(土) 11:20:47 ID:vAxeFfGM
- >>159
禿同
- 162 名前:Socket774 :2006/02/25(土) 17:10:15 ID:nn8gM7to
- >>157
ちょ、おま、それだけアセンブラが書けて、なんでgdbの使い方が分からんのだw
gdbこそ、最初はとっつきにくいが、だんだん慣れて手に馴染むと手放せなくなる、
真のツンデレツール。慣れすぎてデバッグコードを埋め込んだままリリースしたりする。
IMHO, それでも取れないバグを切り分けしてこそ真のツンデレラーだと思う
- 163 名前:Socket774 :2006/02/25(土) 21:40:40 ID:IFC40pvN
- >>162
LOL
- 164 名前:Socket774 :2006/02/25(土) 23:00:19 ID:LzrrlbFq
- >>158
初期のDSPでガンバレ
- 165 名前:Socket774 :2006/02/27(月) 13:57:45 ID:OjSV4Q/M
- レジスタ・ウィンドウは、有効かどうかについて
- 166 名前:Socket774 :2006/02/27(月) 14:07:14 ID:bQqTsn3B
- アプリケーション分野ごとの統計分析が必要だと思う件について
- 167 名前:Socket774 :2006/02/27(月) 14:20:57 ID:OjSV4Q/M
- >>166
くわしく。
- 168 名前:Socket774 :2006/02/27(月) 15:29:56 ID:U6xTLvBH
- >>165
ttp://yarchive.net/comp/register_windows.html
- 169 名前:Socket774 :2006/02/27(月) 16:31:37 ID:iPijvYpL
- レジスタウィンドウで速くはなるけど
リネーミングが複雑になったり、大容量レジスタでクロックが下がったり
80年代のR2000が32本で、90年代のPowerやalphaも32本
今のソフトは当時のよりレジスタ増加がきくだろうけど
128本レジスタスタックってのは
無駄にリッチでは?
- 170 名前:Socket774 :2006/02/27(月) 20:12:07 ID:OjSV4Q/M
- >>169
>128本レジスタスタックってのは
>無駄にリッチでは?
うおぅ! なるほど、わかってきました。
無駄に思いますね。
x86ってレジスタウィンドウ使用して無い?
それともx86でレジスタウィンドウすると、
クロック向上の妨げになるからあえて採り入れないのかな???
- 171 名前:Socket774 :2006/02/27(月) 20:57:46 ID:MPxn6SHJ
- ナノテクだろうとなんだろうと、金属に電気流して周波数に意味もたせてって時点でどれも同じ。
速度なら無重力場・真空での光が今のところ一番速いといわれているんだから、光を通過・遮断に意味をもたせれば最速スパコンの出来上がり。
それを束ねて同時間上で意味を持たせれば束ねるほどに高速になる。ぜんぜんむつかしくない。
- 172 名前:Socket774 :2006/02/27(月) 23:01:16 ID:9NTh/DVj
- >>171
> 光を通過・遮断
ここが最大のボトルネックだな
- 173 名前:170 :2006/02/27(月) 23:08:26 ID:OjSV4Q/M
- うぅ。スルーされた。
- 174 名前:Socket774 :2006/02/28(火) 00:06:05 ID:DWAU0ieu
- >>173
互換性がなくなるのでx86に今から追加するのは無理
- 175 名前:Socket774 :2006/03/01(水) 01:39:21 ID:cpyD/hak
- >>155
えーと。65816についてはどう思いますか?
- 176 名前:Socket774 :2006/03/01(水) 03:58:49 ID:GnVN+RWx
- >>175
エミュ作者泣かせ
- 177 名前:175 :2006/03/01(水) 06:39:39 ID:cpyD/hak
- >>176
開発者泣かせでもあったぞ!!!
6502の拡張版ながらもううんこ石
というわけでC62を推しておくw
- 178 名前:Socket774 :2006/03/01(水) 07:29:15 ID:FI3uF4Br
- 機関車の形式に見えた俺。
- 179 名前:Socket774 :2006/03/01(水) 17:05:43 ID:GnVN+RWx
- >>178
由来がそうなんだけどね
- 180 名前:Socket774 :2006/03/01(水) 18:06:55 ID:l5HNXc4r
- >>173,174
つ【V25/V35】
- 181 名前:Socket774 :2006/03/01(水) 20:04:01 ID:wKtrKn2r
- >>180
わたしの知っているV35は単にV30に周辺を突っ込んだだけのものなんだが。
V30にしてもそんなドラスティックなISAの変更ってあったっけ?
レジスタウィンドウ追加というとAMD64以上のISAの変更になるのでいろいろ難しいと思うね。
- 182 名前:Socket774 :2006/03/01(水) 20:29:35 ID:j9NX1KZ2
- http://www.atmarkit.co.jp/fembedded/07ipflex/ipflex01.html
なんですか?これ・・
- 183 名前:Socket774 :2006/03/01(水) 21:23:10 ID:l5HNXc4r
- 単純な処理要素を結合して演算パイプラインを構成するらしい。
パイプラインは短時間で動的に再構成可能。FPGAの上あたりの細粒度並列処理を狙う。
リコンフィギャラブルアーキテクチャと言うらしい。最近そっち方向の研究が流行ってるみたいだ。
http://www.hpcc.jp/sacsis/2004/include/amano-sacsis.pdf
- 184 名前:Socket774 :2006/03/03(金) 05:52:35 ID:Fnh8txcc
- >>183
けっきょく信号処理にしか使えないワナ
- 185 名前:Socket774 :2006/03/03(金) 09:38:06 ID:2ZqbJbBq
- リコンフィギャラブルアーキテクチャでリダクションマシンを組むというネタも
どこかにあったと思うんで、信号処理だけでもないようなキモス。
一般に露出してる実装例が信号処理用途なのは同意。
- 186 名前:Socket774 :2006/03/04(土) 05:19:20 ID:KxiglkAt
- リダクションマシンやってる人、まだいるのかorz
- 187 名前:Socket774 :2006/03/04(土) 11:50:03 ID:zTiWyu4E
- やっぱり今やってる人は少ないのか。
面白そうなんで勉強してみようと思うんだけど、本が無いのがなぁ。
データフローとかだとマイナーなりに本が出てるから、アマチュアでも
やりやすいんだが。
- 188 名前:Socket774 :2006/03/04(土) 13:40:44 ID:7QqdMD3o
- Cellをパソコン用に改良して出てこないかな。
- 189 名前:Socket774 :2006/03/04(土) 19:39:48 ID:ELrwO8dR
- >>188
PowerPC750で十分だろ。
Altivecが使いたいなら7400シリーズだ
あえてCellのようなものがいいというなら、PowerPC405シリーズをたくさん買ってくるといい
- 190 名前:Socket774 :2006/03/04(土) 20:28:17 ID:zTiWyu4E
- >>188
GPGPUでいいんじゃないかと。
- 191 名前:Socket774 :2006/03/04(土) 20:38:05 ID:QGlKCHEQ
- GPGPU用のAPIが整備されて、実際に使い物になるのはいつごろですか?
- 192 名前:Socket774 :2006/03/04(土) 20:40:10 ID:76jFhW93
- 早くマトリックスの世界になって欲しいです
- 193 名前:Socket774 :2006/03/04(土) 21:27:29 ID:zTiWyu4E
- >>191
それを言い出したらCellはどうなのかとw
- 194 名前:Socket774 :2006/03/04(土) 22:18:30 ID:tiF2EG5d
- >>193
「一見関係ありそうで関係ない話を始める」
- 195 名前:Socket774 :2006/03/04(土) 22:47:32 ID:zTiWyu4E
- まったく関係の無い話を始めるアンタよりましw
- 196 名前:Socket774 :2006/03/04(土) 22:59:14 ID:4Zt58vwH
- でもこのままx86のCPUなんかがパソコンで定着しちゃったら嫌なんだ
ぜひCellをパソコン向けに改良して欲しい。
- 197 名前:Socket774 :2006/03/04(土) 23:26:51 ID:zTiWyu4E
- >>196
Cell自体は(現時点の実装を見る限り)「汎用CPU+複数DSP」みたいなもんで、古の「メディアプロセッサ付きPC」と
大して変わらない。「汎用CPU」の部分は言わずもがな、「複数DSP」の部分も用途ごとのライブラリやAPIが被さる
だろうから、よほどハードウェアに近い部分でプログラミングするのでない限り、プログラマから見る姿は大して今の
PCと変らないと思う。
エキゾチックなアーキテクチャでプログラムを楽しみたいなら別の方法があるし。
(手軽なところではGPGPUとか。)
- 198 名前:Socket774 :2006/03/04(土) 23:35:05 ID:cd9ol5aM
- GPGPU用のAPIが整備されて、実際に使い物になるのはいつごろですか?
- 199 名前:Socket774 :2006/03/04(土) 23:44:14 ID:zTiWyu4E
- そんな時期は来ないから待つだけムダ。
- 200 名前:Socket774 :2006/03/05(日) 03:52:43 ID:5f4jUaNH
- Cellはパソコン向けには遅すぎる
- 201 名前:Socket774 :2006/03/05(日) 03:56:24 ID:5f4jUaNH
- >>187
20年くらい前のアーキテクチャの本にちょろっと載ってるくらい
- 202 名前:Socket774 :2006/03/05(日) 04:29:23 ID:6zlI3Qb1
- >>200
PPEを強力なものに変えればおk。
SPEの数を増やすのもいい。
- 203 名前:Socket774 :2006/03/05(日) 07:11:47 ID:6cOqkQ8R
- 頭で妄想するのは簡単なんだよ。黒字ベースに持っていけるだけの研究開発費出してくれ。
- 204 名前:Socket774 :2006/03/05(日) 08:33:13 ID:57whuXU2
- >>201
やっぱりそんなもんか....orz
ちまちま論文を拾っていくしかないか。
- 205 名前:Socket774 :2006/03/05(日) 12:12:24 ID:LJxfxo0P
- 結局、売れるか売れないかなんだよねえ・・・
特定用途に特化するか汎用性を売りにするか・・・
- 206 名前:Socket774 :2006/03/06(月) 22:28:17 ID:PmDpLi8S
- >>204
昔の論文はあんまり電子化されてないぽ
- 207 名前:Socket774 :2006/03/06(月) 22:49:38 ID:PmDpLi8S
- >>202
PPEを強力にしてSPEは無くせばいいとおもうよ
- 208 名前:Socket774 :2006/03/06(月) 23:30:19 ID:hoiwCiEp
- >>206
紙のを拾う。
とりあえず情報処理学会誌あたりから始めるか。
- 209 名前:Socket774 :2006/03/07(火) 00:09:17 ID:TemWQEMk
- >>202,207
>>189
- 210 名前:Socket774 :2006/03/07(火) 12:11:55 ID:/O/RWaI/
- >>207
それ、ただのPowerPC(970系)だろw
- 211 名前:Socket774 :2006/03/07(火) 14:42:42 ID:D045qrkP
- 10個SPEがくっついてるPPEを4つつなげれば最高?
- 212 名前:Socket774 :2006/03/09(木) 00:49:47 ID:dRjFwmBv
- Conroeにはcmp/test+jccのMacro-op fusionが実装されるもよう。
遅延分岐については不明だが。
- 213 名前:Socket774 :2006/03/10(金) 20:28:23 ID:N52rpjVd
- データ取りこぼしがこわいからスレッド切り替え頻度↑↑になってきてるんだろうけど
そういうのこそメニーコアに振りたくなるよね
(ちなみに漏れのとこだと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を見てくださいな。
- 214 名前:バートソ :2006/03/10(金) 20:49:41 ID:ZjzCFyCb
- そこでマルチスレッドアーキテクチャですよ。
ハイパースレッドで2面待ちなんて甘い甘い。
- 215 名前:Socket774 :2006/03/11(土) 05:03:25 ID:yKeuixTa
- マルチコアはアーキテクチャ的工夫がなくていまいち好きになれん
- 216 名前:Socket774 :2006/03/11(土) 09:10:29 ID:hJqXqnRy
- まあスレッドのスケジューリングに関する話ならおもしろいんだけど、
今のところその機構はCPUの外(人間、OS、コンパイラ、ランタイム)にあるからね。
コンパイラの自動並列化は、ほとんどの場合パフォーマンス向上につながらず、
また致命的バグが潜む可能性もあるので、結局人間最適化しているという現状。
- 217 名前:Socket774 :2006/03/11(土) 09:34:43 ID:hJqXqnRy
- 今のプログラマに負担を強いるやり方ってのは自ずと限界がある。
例えるならILP(命令レベルの並列性)において、みんながみんな
アセンブラで命令の並べ替えをして最適化しなきゃいけないような
人間アウトオブイオーダー・人間スケジューリング、
な世界をイメージするとその滑稽さがよくわかる。
- 218 名前:バートソ :2006/03/11(土) 09:42:01 ID:t/Wp9fZw
- 動的スケジューリングも投機実行も所詮小手先。
やっぱりハードウェアマルチスレッドですよ。
とつぶやきつつ、Denelcor HEP→Cray MTA2と敗北の歴史を刻みンヌ....orz
- 219 名前:Socket774 :2006/03/11(土) 09:53:56 ID:YFI3HNjl
- http://www.watch.impress.co.jp/game/docs/20050316/ps311.jpg
これって結局クタラキの妄想だったんでしょ?
- 220 名前:Socket774 :2006/03/11(土) 12:11:54 ID:qkiPnZ9E
- >>212
CC生成命令と分岐命令をセットにして処理するってことはALUに分岐用RS
をくっつけたような構成になるってことか。1回のCC生成に対して2回以上
参照したり、CC生成命令と分岐命令が離れている場合はMarco-op fusion
にならないんだろうけど、どう処理が変わってくるのか?
これも実装の1つの選択肢だとは思うけど、演算実行と分岐判定を別々にやる
場合に比べてのメリットがわからん。2つの命令が1つになることで
命令スループットがやや良くなるとは思うけどたかが知れているだろ。
Micro-opsに分解してせっかくシンプルなRISC的処理を行っているのに
複雑化していいことがあるとは思えん。
- 221 名前:Socket774 :2006/03/11(土) 14:58:23 ID:spyuYa0g
- CELLに夢みてる馬鹿が多いようだが、CELLはCPU1個ででかい
タスク1個(ゲーム)を効率的に処理するためのカスタムチップ。
複数タスクをコンテキストスイッチしながら処理する汎用PCには
まったく向かない。
SPEを使わない前提ならアリかもしれないが、それならX86とかの
ほうがよほど高速。PPEの出る幕はない。
SPEを使う前提だとコンテキストスイッチングがネックになる。
SPEはコンテキストスイッチングしないで重いタスクを高速に処理
するという思想なんで、汎用レジスタが128本とか恐ろしい数を
持っている。
SPEを使わないタスクばかりならいいが、それだとX86に及ばない。
SPEを使うタスクばかりだと限られたリソースの奪い合いになる。
なぜならコンテキストスイッチしない設計思想だからな。
ゲームぐらいにしか使えんよ。そのかわりシングルタスクなら
高速だがな。
- 222 名前:MACオタ>221 さん :2006/03/11(土) 15:22:25 ID:W5p9ddCr
- >>221
他人に説教する前に,自分が何を書いてるか読み直した方が良いかと思うす。
-----------------------
SPEはコンテキストスイッチングしないで重いタスクを高速に処理
するという思想なんで、汎用レジスタが128本とか恐ろしい数を
-----------------------
AltiVec有りのPowerPCアーキテクチャわ,整数・浮動小数点・ベクトルで各32本のレジスタを持っているす。
96本と128本が大違い。。。ってのわ,相当ピントのずれた思い込みかと(笑)
更に容量に換算すれSPEのレジスタわ2倍になるすけど,PPEわマルチスレッドのためにレジスタを2セット備えて
いるすから,結局何も変わらないことになるす。
- 223 名前:Socket774 :2006/03/11(土) 15:48:14 ID:k/nxWS46
- >>221
Cellが使いものにならなければPOWERやPowerPCを使えばいいので、どうでも良い。
- 224 名前:Socket774 :2006/03/11(土) 17:18:42 ID:t/Wp9fZw
- 論点がかみ合ってない悪寒
- 225 名前:Socket774 :2006/03/11(土) 17:55:04 ID:afROO2O5
- > 今のプログラマに負担を強いるやり方ってのは自ずと限界がある。
いやソフトウェアエンジニアの立場から見ても今までプログラマはH/Wの進化に
甘えすぎだと思うんだが・・・
- 226 名前:Socket774 :2006/03/11(土) 19:39:52 ID:xkZtzpAn
- フリーランチの時代は終わった、ってやつですか。
- 227 名前:Socket774 :2006/03/11(土) 20:54:00 ID:YFI3HNjl
- そして有料ランチの代金は結局おまいらが払うことになる
- 228 名前:Socket774 :2006/03/12(日) 00:51:45 ID:oRPR7UQ2
- >>222
GPUがだんだんグラフィック専用プロセッサから演算処理プロセッサになってきてるから
PCの場合CellのSPEに相当する部分としてをGPUが使われるようになる予感
- 229 名前:Socket774 :2006/03/12(日) 00:52:43 ID:Bwr4Qhja
- レジスタなんかよりLSの256KBのほうがはるかにでかいわけだが
- 230 名前:Socket774 :2006/03/12(日) 01:09:55 ID:q9pSN5mi
- SPEはMMUなかった気がする。
だからプロセススイッチするならLS丸ごと書き換えなきゃまずいんでは。
全部PICでコンパイルしてるならぎりぎりちょろまかせそうな気もしなくもないが。
- 231 名前:Socket774 :2006/03/12(日) 02:12:24 ID:Bwr4Qhja
- >>230
あるけどDMA用だから役に立たんな
- 232 名前:Socket774 :2006/03/12(日) 03:05:21 ID:Bwr4Qhja
- >>220
まあ明らかに効果があるといったレベルのものでもなさそうだな。
ただ、CCはリネームしないとするならそこに余計な逐次性が入ってしまうわけで、
うれしい局面はあるのかもしれん。
- 233 名前:Socket774 :2006/03/12(日) 08:42:26 ID:1TB24caL
- >>222
SPEは何個あると思ってんだ。その分かけてみろバカ。
- 234 名前:Socket774 :2006/03/12(日) 09:35:07 ID:RXenFb/s
- >>233
バカだもん
- 235 名前:MACオタ>233 さん :2006/03/12(日) 09:38:49 ID:ksHUgGwY
- >>233
---------------------
その分かけてみろバカ。
---------------------
レジスタの退避わ,各SPEが持つLSに対して行えば良いすから,何個あろうとレイテンシわ一緒すけど(笑)
- 236 名前:Socket774 :2006/03/12(日) 09:58:22 ID:6GxjndxS
- SPUについては直接アクセスできるメモリが256KBしかない時点で、汎用プロセッサと
同等の多重タスク処理を求めるのは無理と思われ。Forthみたく実メモリモデルで極端に
小さなモジュールを組み合わせてシステムを組むような環境ならいけるかも知れんけど。
>>228
それは無いような。GPUメーカーとしてはグラフィック処理以外に演算リソースを喰われて
描画性能が落ちるのは嫌だろうし、(特にヲタ向けハイエンド機種。)インテルにしても自社
プロセッサの仕事が他に奪われるのを黙っては見ていないと思う。(実際、メディアプロセッサ
に対してMMXで対抗した。)
しかし段々とそうやって汎用プロセッサの役割が特定機能ユニットに分担されるようになって
いくと、コア部分はシングルパイプ・インオーダーのシンプルなものに戻っていくのかも。
- 237 名前:MACオタ>236 さん :2006/03/12(日) 11:27:19 ID:ksHUgGwY
- >>236
------------------------
Forthみたく実メモリモデルで極端に小さなモジュールを組み合わせてシステムを組むような環境
------------------------
そういうのが,CELL対応のコードに要求される「新しいプログラミングパラダイム」ってヤツだと思われるす。
公開されているCELLの性能を見る限り,見返りも大きいんじゃないすかね。。。
- 238 名前:Socket774 :2006/03/12(日) 11:43:12 ID:L3Vku/ha
- 今になってやっと、主記憶内のデータ領域⇔SPEのLS、
なことをスケジューリングするミドルウェアが出てくるなんて遅すぎ。
http://techon.nikkeibp.co.jp/article/NEWS/20060308/114415/
- 239 名前:Socket774 :2006/03/12(日) 11:48:33 ID:moal2ul4
- CELLは、パソコンで使うなら、グラフィックスアクセラレータでしょう。
hpのVisualize fx10というビデオカードは、ビデオカード側にRISCプロセッサ6個積んでたりしたよ。
パソコンで使ってウマーなのは、XBOX 360に積まれているCPUだと思う。
3.2GHzで3コア6スレッド実行で、メモリのバンド幅もじゃぶじゃぶ。
- 240 名前:MACオタ>239 さん :2006/03/12(日) 12:02:43 ID:ksHUgGwY
- >>239
--------------------
XBOX 360に積まれているCPUだと思う。
--------------------
拡張命令を除くとCELL PPEと同じモノす。
2-issueでin-orderのプロセッサすけど,速いと思うすか?自作板の方わMeromで「幅」の有り難味を
理解したと思っていたすけどね。。。
- 241 名前:Socket774 :2006/03/12(日) 12:12:25 ID:T055XUhl
- Xenonはアービタ周りが腐ってるので問題外
- 242 名前:Socket774 :2006/03/12(日) 12:30:51 ID:CsUeYa1y
- >>239
もしかしてCELL+PowerVRを夢見ているのか?
……俺もちょっと惹かれる。
- 243 名前:Socket774 :2006/03/12(日) 14:41:39 ID:nxXYE+rf
- >>239
6個くらいで驚くな。
SGIのReality Engine2は12個のIntel860XPプロセッサを頂点変換のために
搭載している。昔の3DグラフィックスシステムではRISCプロセッサを同様に
搭載したものが多い。
http://www.gisparks.tas.gov.au/sgi/ge10.jpg
- 244 名前:239 :2006/03/12(日) 17:32:09 ID:moal2ul4
- >>240
2-issueでも3コアあれば、トータルで6-issueだよ。
in-orderつっても、2スレッドで隠蔽だよ。
同じトータルで6-issueでも、3-issueの2コアよりも、効率が高いと思う。
>>243
i860がSGIのモンスター級のマシンで使われたことがあるのは知ってるけど、
Visualize fx10は、ごく普通のOpenGLのビデオカードなんですよ。
- 245 名前:Socket774 :2006/03/12(日) 20:51:38 ID:Bwr4Qhja
- 手作業でレジスタアロケーションしたりスケジューリングしたりするのも新しいプログラミングパラダイムかね
- 246 名前:Socket774 :2006/03/12(日) 22:02:27 ID:QHzxVq2k
- 手間をプロセッサの外に出すっつー考え方はItaniumが実現したが、
それが性能に結びついているとは言い難いんだよなぁ。
- 247 名前:MACオタ>245 さん :2006/03/12(日) 22:05:03 ID:ksHUgGwY
- >>245
その辺が自動で簡単にできるように,in-orderになってるんだと思うす。
SPEでのタスク分割わ,人力に頼らざるを得ないと思うすけど。。。
- 248 名前:Socket774 :2006/03/13(月) 02:33:06 ID:DbXv55JI
- ハード技術0のソフト屋のたわごと
・CPUの高クロック化はプロセスの微細化によってのみもたらされるべきである
・シングルコアでインオーダ発行のシングルパイプラインのプロセサをマルチプロセサで使用する
・遅延分岐の採用により分岐によるインタロックを行わない→必然的にパイプライン段数は少なく留めるべきである
こんな考え方はものすごい時代遅れなんでしょうね。
アセンブラをいじって面白いのは非パイプラインのCISCかシングルパイプラインのRISCなんですよね。
レジスタリネーミング、アウトオブオーダ発行のスーパースケーラなんてアーキテクチャを見ると、もはや人間は高級言語だけ使えってことなんでしょうかね。
- 249 名前:Socket774 :2006/03/13(月) 02:38:19 ID:lK0eRsCW
- >>246
それを言うならRISCやVLIWだと思う。
ItaniumはIPCという観点からは性能でてると思うよ。あれだけピーキーなアーキテクチャの割には。
- 250 名前:Socket774 :2006/03/13(月) 02:49:03 ID:OGy+g6gw
- インテルの衰退とAMDの繁栄 Part26
http://pc7.2ch.net/test/read.cgi/jisaku/1142021769/373
373 名前:Socket774[sage] 投稿日:2006/03/12(日) 18:50:45 ID:wbaGuMo1
MACオタって懲りずにまだいるんだな。
書き方がキモ過ぎって未だに分かってないな。「わ」とか「るす」とかマジ超寒い。
自分ではイケてるって勘違いしてるんだろうなw
素でドン引きだって気づいてないんだろうな・・・哀れ。
何をアピールしたいのか知らんが、自分で「MACオタ」とか名乗っても
MACというブランドに自己同一視するなんて
ただの痛い奴にしか周りには見えないw
大体こいつなんでこのスレに書き込んでいるのか意味不明。
スレタイからしてAMD好きな奴の為にあるスレにしか読めないんだけど?
やってる事はそもそもスレ違いだしIntelスレに帰れ・・・と言いたい所だが
こいつIntel本スレでも嫌われてるから帰る居場所が無いw
キチガイだからIntel好きな奴にすら受け入れてもらえずに
仕方なくここでAMDの悪口書いてストレス発散とか痛すぎ。
あぁ、あとは次世代CPUスレで動向についての見識をひけらかして
優越感に浸ることも忘れてはダメだw
まぁAppleがx86に宗旨鞍替えした途端に金魚の糞のように追従して
今までは何だったの?と思わせるほど節操も無くPPCを捨てて
Intel至上主義に走るような馬鹿には何を言っても無駄かm9(^Д^)プギャー!!
- 251 名前:Socket774 :2006/03/13(月) 03:02:05 ID:H2iSGrXX
- >>248
現状のプロセッサ設計はなるべくしてそうなっているので、こういう「べき」論はナンセンス。
せめて設計目標を先に挙げてくれ。「俺はこういうのが好き」というのではちょっと弱い。
- 252 名前:Socket774 :2006/03/13(月) 06:52:39 ID:GMVeAF4I
- >>248みたいにプロを装って妄想を書く社会を知らない消防はたちが悪い
- 253 名前:Socket774 :2006/03/13(月) 07:24:26 ID:H2iSGrXX
- 大原雄介がまたシッタカぶりを披露しています。
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あたりで実装されとると思った。
- 254 名前:Socket774 :2006/03/13(月) 08:52:40 ID:yla2OOG2
- 商用プロセッサでRetirementがOut-of-OrderなCPUはありますか?
- 255 名前:Socket774 :2006/03/13(月) 09:14:09 ID:QRDlIscc
- >>248
>・CPUの高クロック化はプロセスの微細化によってのみもたらされるべきである
妄想も大概に。
>・シングルコアでインオーダ発行のシングルパイプラインのプロセサをマルチプロセサで使用する
シングルコアでマルチプロセッサ?
チップの数(=パッケージの数)をどんどん増やすわけ?
マルチプロセッサシステムをうまく動かすのはソフトは大変よ?
本当にソフト屋?
>・遅延分岐の採用により分岐によるインタロックを行わない→必然的にパイプライン段数は少なく留めるべきである
ハードの実装によってディレイスロットの数がばらばらになってバイナリ互換性がなくなるけど。
MIPSもR4000の時点で既にインタロックするようになっているの知ってる?
本当にソフト屋?
>こんな考え方はものすごい時代遅れなんでしょうね。
でなきゃバカ。
>アセンブラをいじって面白いのは非パイプラインのCISCかシングルパイプラインのRISCなんですよね。
>レジスタリネーミング、アウトオブオーダ発行のスーパースケーラなんてアーキテクチャを見ると、もはや人間は高級言語だけ使えってことなんでしょうかね。
本当にソフト屋?
- 256 名前:Socket774 :2006/03/13(月) 09:24:19 ID:H2iSGrXX
- >>254
360/91
- 257 名前:Socket774 :2006/03/13(月) 10:15:57 ID:0t/AG87J
- >>255
>>248で俺はSunのNiagaraみたいな奴を想像したんだが。
ああいうのは面白いと思う。
自作板向きではないが。
- 258 名前:Socket774 :2006/03/13(月) 10:24:45 ID:QRDlIscc
- >>257
>>>248で俺はSunのNiagaraみたいな奴を想像したんだが。
Niagaraはまったく想像できないけどなぁ。シングルコアって言ってるし。
アレはメニィコアだよね。
ひょっとして、シンプルコアでマルチプロセッサといいたかったんだろうか?
- 259 名前:Socket774 :2006/03/13(月) 12:34:33 ID:lK0eRsCW
- 寄ってたかって指摘したら可哀想だから、そっとスルーしてあげようよ。
- 260 名前:248 :2006/03/13(月) 17:23:21 ID:DbXv55JI
- 一介のソフトウェアプログラマというつもりでソフト屋と書いたのですが
違う意味に受け取られたのでしょうか。
ソフトウェア側からしかCPUを使用したことがなく、
CPUに関してはプロフェッショナルどころか門外漢です。
勉強中の身なので指摘、批判、嘲笑、大いに歓迎です。
- 261 名前:Socket774 :2006/03/13(月) 17:41:10 ID:QRDlIscc
- >>260
もちろんそういう意味で解釈したよ。
その上で「ソフト屋とは思えない」発言が目立つって話。
- 262 名前:248 :2006/03/13(月) 18:11:02 ID:DbXv55JI
- >>255=258=261さん、返答ありがとうございます
私の考えは
・現在のCPUクロックは速すぎる→500MHz程度で充分
・インタロックのない遅延分岐→パイプライン段数は変えない
・Unix系のプログラムを考えるとマルチプロセサ化はそれほど難しくない
現在の集積度ならパイプライン5段で500MHzの実現は可能という勝手な思い込みに基づいています。
R4000系のようにパイプライン段数を増やすと、
バイナリ互換性のために遅延スロット+インタロックなんて
MIPSはMicroprocessor with interlocked pipeline stagesの略ですか?
なんてことになるからパイプラインの増加は好ましくないと思っています。
- 263 名前:Socket774 :2006/03/13(月) 18:43:15 ID:6tsjXAOb
- >>260ドンマイ
だいたいハードもソフトもどっちもなきゃ使い物にならないしね。
そういう見方も必要。
248>もはや人間は高級言語だけ使えってことなんでしょうかね。
んなこたーない
なぜなら構造化アセンブラ(C)とそのオブジェクト指向拡張(C++)は絶対に高級言語なんかじゃないから
どうか・・・そう考えてください、おねがいしますです。
ところで自動スレッド分解コンパイラ>>216なんとかなってくれないものか・・・
- 264 名前:Socket774 :2006/03/13(月) 19:49:54 ID:lK0eRsCW
- >>262
そんな貴殿には、IA-64をオススメします。
低いクロック、短いパイプラインですよ。
- 265 名前:Socket774 :2006/03/13(月) 20:50:12 ID:bHKmSMXQ
- >>240
おいおい、XBOX360の方は3コアでCELLは1コアだろ
基礎体力は段違いじゃないか?
- 266 名前:Socket774 :2006/03/13(月) 23:00:07 ID:I152LA3M
- CELLは軽いコントロールロジックをPPEで、重いメディア処理をSPEでという
分担構造。PPEとSPEが協調して「1つのタスク=ゲーム」を動かす作り。
SPEはコードとデータをまとめてローカルの高速RAMに投げ込む構造だから
タスクスイッチなどまったく想定していない。ゆえに汎用には使えない。
360みたいにPPCが3コアとかなら使えなくもないが、それならそれでインテル
やAMDのほうが一枚も二枚も上手。
所詮ゲーム用CPUはゲーム用でしかない。
- 267 名前:248 :2006/03/14(火) 00:33:20 ID:0TTT5FBQ
- >>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に走るんですけど。
バイエンディアンといいつつもリトルで使っているのを見たことないです。
- 268 名前:Socket774 :2006/03/14(火) 01:27:04 ID:SQXuzcB5
- >>267
> IA-64はIA-32の命令セットを内包するんですよね。
しない
- 269 名前:Socket774 :2006/03/14(火) 02:27:34 ID:SQXuzcB5
- >>267
PPCが上位にきているのがかなり意外だが、Alphaはどうよ。
- 270 名前:Socket774 :2006/03/14(火) 09:12:46 ID:HUHe1ow8
- Intelが本気でPowerPCで作ると今のCoreDuoを超えますか?
- 271 名前:Socket774 :2006/03/14(火) 16:32:20 ID:gtWZbKcx
- >>262
96コアで性能2倍のコプロセッサ、米企業が発表
http://www.itmedia.co.jp/news/articles/0410/07/news039.html
- 272 名前:Socket774 :2006/03/14(火) 20:36:14 ID:ulMCU1hI
- >>267
案外ARMが高いね
個人的には全命令条件実行可能なのは結構好きだけど
このスレでは変態命令セットとかさんざんな言われようだから
- 273 名前:Socket774 :2006/03/14(火) 21:26:36 ID:zKy0fSR7
- ところでIA16ってx86の16bitコードのこと?
どこでそういう方言を使っているのかなぁ。
- 274 名前:248 :2006/03/14(火) 23:19:58 ID:0TTT5FBQ
- >>268=269 >>272
ARMは得点も多いが失点も多い2位です。個性的ですよね。
理想追求的な旧MIPSと現実的なARMって感じですか。
PPCは失点が少なく得点も少ない3位です。
PPCは欠点らしい欠点が見当たらない。
R3000以外の順位の理由は私のレベルを反映してわりと明快というか単純で、
プログラマ側から見たインタフェースである命令セットが大きくモノをいってます。
あとは汎用レジスタ数、レジスタオペランド数、エンディアン。
ハードウェアは門外漢ですが、シンプルなアーキテクチャが好きです。
なので分岐予測よりも遅延スロットが好き。
MIPS64はかわいさあまってにくさ100倍といったところでしょうか。
手の届くところにAlphaはないのでちょっと分かりません。
>>271
疎結合のネットワーク分散コンピューティングと密結合のプロセサの中間といった感じですかね。
現在の民生バスを考えると緩結合はわりと現実的な解なんでしょうか。
>>273
パイプライン化する前の16bitCPUの8086や80286のつもりで書きました。
(80286はパイプラインだったっけ?)
- 275 名前:Socket774 :2006/03/15(水) 00:26:33 ID:hR3F9Wtr
- >>268
> >>267
> > IA-64はIA-32の命令セットを内包するんですよね。
> しない
補足
中にPentiumII (位の速度のIA-32 の Core)がオマケで入っているだけ.
それも,Montecitoからなくなるみたいだけど.
- 276 名前:248 :2006/03/15(水) 01:19:23 ID:7CLr+FtJ
- >>275 (=268?)
私の無知からくる頓珍漢な発言を正してくださって、ありがとうございます。
低いクロック、短いパイプラインにIA-32はオマケですか。
意外とイイ奴かも。
食わず嫌いで視野を狭めるのはいけませんね。
反省します。
- 277 名前:Socket774 :2006/03/15(水) 01:29:22 ID:aWwKe31c
- >>273
IA64が出来てからIA32という用語が生まれ、時たまIA16という言葉も使われる。
あんま使われないが、使われるには使われる。
使用例が見たいならぐぐれば?
- 278 名前:Socket774 :2006/03/15(水) 04:37:57 ID:AHvfLwU5
- >>275
それは良く聞く話なんだけど、ソースある?
インテルの資料には、x86をデコードしてIA64と同じ演算ユニット・レジスタで実行しているように書いてある。
もしPentiumIIのコアが丸々入っていて、さらに同じクロックで動いているのるのなら、
IA-32のコードの実行速度は、もっともっと速いはず。
- 279 名前:Socket774 :2006/03/15(水) 04:54:44 ID:4zS1zWm5
- >>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みたいなの。
- 280 名前:Socket774 :2006/03/15(水) 09:01:42 ID:U0MrNJaa
- >>277
どこからそういう奇妙な方言を仕入れてきたか興味があっただけなんで。
google引いてもそういう意味で使われていることはほとんどないんだよね。
少なくともこういう場所で説明なしに使って理解してもらえる言葉じゃないと思うよ。
- 281 名前:Socket774 :2006/03/15(水) 09:08:56 ID:T3BjiAO8
- PowerPCがRISCでCISCよりも無駄がないと聞きます。
x86のCPUと比べてPowerPCの方が遅い理由はなんですか?
他の技術で負けているということなのでしょうか?
- 282 名前:Socket774 :2006/03/15(水) 09:44:20 ID:ESOwS5KJ
- ..::::::,、_,、::: ::::: ::: :
/ヨミ゙ヽ)-、. :: ::::
─(ノ─ヽ.ソ┴─
- 283 名前:Socket774 :2006/03/15(水) 12:29:13 ID:isE5+ao7
- IA64の32実行用コアは動けばイイやという代物だったから
マッキンリーの頃だったかにはエミュレーションの方が早くなってしまって
早晩なくなるだろうと言われていたな…。IA64自体が危ういが。
>>281
@x86もRISCだから
APPCの方が総じてクロックが低いから
BPPCで高速に動くようなコーディングをしてないから
このうちの複数の理由による。
AについてはPPC陣営の悪い癖というか,一歩先を行く
機能によってクロックの足を引っ張るというのと,フラグシップ
PPCの市場がとても狭いというのが原因。
余談だが,組込(ゲーム機等)と被らないPPCは
ほぼMac専用で上に行くとPOWERがある為に
IBMにやる気がないというのもIntelチップ採用の原因とされる。
- 284 名前:Socket774 :2006/03/15(水) 13:52:22 ID:AHvfLwU5
- >>279
話の流れから明記しなくてもわかってもらえると思って書かなかったのだけど、
> それも,Montecitoからなくなるみたいだけど.
ではなくて
> 中にPentiumII (位の速度のIA-32 の Core)がオマケで入っているだけ.
の話について、です。
- 285 名前:Socket774 :2006/03/15(水) 19:53:43 ID:IY7Z1lFr
- >>284
(位の速度のIA-32 の Core)
(位の速度の)
- 286 名前:Socket774 :2006/03/15(水) 20:59:29 ID:AHvfLwU5
- ぜんぜん話が違ってくるじゃないですか。
最初から、そう書いてくださいよ。
びっくりしたなぁ、もう。
- 287 名前:Socket774 :2006/03/15(水) 21:18:22 ID:f7fBP6fh
- >>281
同じIA-32でも、pentiumよりconroeの方がずっと速いだろ?
命令セットって、本質的にあんま関係ないんだよ
>>283
970は、2.7Ghzも出てる
K8と遜色ないし、デスクトップ・サーバー用CPUでは
クロック最高の部類だ
- 288 名前:275 :2006/03/15(水) 22:12:09 ID:hR3F9Wtr
- >>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 相当のものが入っていると言っていい,,,,,かな?
- 289 名前:Socket774 :2006/03/16(木) 00:49:02 ID:NkQ7YZ8y
- 31ページの図はパイプラインのステージ順に描かれているので、
IA-32の命令はIA-64の命令に変換されてることを示しているね。
でも32ページのダイのレイアウトの図では、IA-32の面積が広くて、
IA-32のコアが丸ごと入りそうな気もするんだよね・・・。
- 290 名前:Socket774 :2006/03/16(木) 01:51:49 ID:E5aOg5oc
- 既存のソフトウェア資産を重視しない用途ではitaniumやpowerが選ばれる。
x86よりパワフルだから。
x86である必要の無いゲーム機もpowerを採用。
PowerPCもG5はスペック相応の性能だと思う。
G4はモトローラの技術力とやる気の無さ。
クロック狂騒時代、IBMはやる気満々だったがモトローラがついていけず。
当時はIBMがローエンドのG3、モトローラがハイエンドのG4担当。
G4より高クロックのG3は許さない、これがアップルの意向でIBMはかなり怒っていた。
同じG3でもIBM製G3は銅配線、モトローラ製G3はアルミ配線、技術力の格差がはっきり
してきて三角関係は微妙な事態に突入。
- 291 名前:Socket774 :2006/03/16(木) 02:12:11 ID:1YbsZ089
- >>290
性能じゃなくて、マーケティングとかスケーラビリヒティーだろ
ハイエンドでpowerやitaniumが使われるのは
なお、ハイエンドだとある面ではデスクトップ以上に
ソフトウェア資産が重要
- 292 名前:Socket774 :2006/03/16(木) 07:56:42 ID:L/JLr5yQ
- >>290
つか。
見た目のスペック表のすごさばかり追及して、
クロックを高める妨げにしてしまうという、
モトローラの悪癖が出ただけだろ>G4
Altivecのレジスタ数の多さ、高機能さが
クロック上昇を妨げるガンだった。
これを無理に高クロック化したから、発熱がすごいことになった。
モトローラのG4をハイエンド用に決めてなかったら、
G4より底力のあるG3機だってあり得たのにな。
- 293 名前:Socket774 :2006/03/16(木) 11:52:18 ID:NkQ7YZ8y
- 以前、エンタープライズ系の、あるサーバソフトの開発をやっていたとき、
CPUのクロックを上げても、ほとんどパフォーマンスが上がらない
ということで困ったことがある。
そのソフトはコードの99%とCPU時間の99%を、
エラーチェックとエラー時の対処とエラーの記録
に費やしていると言っても過言ではなく、
コードサイズが巨大で命令のキャッシュのヒット率が低く、
分岐が多すぎて 分岐や分岐予測のためのCPU内のリソースは足りないしで、
それはもう悲惨だった。
そういうのだと、Itaniumのようなアーキテクチャだと、性能が出そうな気がするよ。
- 294 名前:Socket774 :2006/03/16(木) 12:01:49 ID:fc3jCsBD
- >>293
>そのソフトはコードの99%と
こっちはともかく
>CPU時間の99%を、
こっちはありえないのでは?
>エラーチェックとエラー時の対処とエラーの記録
>に費やしていると言っても過言ではなく、
ほとんど時間が異常系の実行に費やされているっていうのは
そもそもの設計自体に重大な欠陥があるとしか思えん。
そんなウンコソフトなら、どんなプロセッサを持ってきてもどうにもならんと思うが。
- 295 名前:Socket774 :2006/03/16(木) 18:04:42 ID:1zgjQBrP
- そうだけど、ハイエンドプロセッサのほうが分岐のテーブルとか
キャッシュがでかいから、大きなワークロードに向いてるのは事実
- 296 名前:MACオタ>292 さん :2006/03/18(土) 00:17:55 ID:uXVRKq/u
- >>292
----------------------
Altivecのレジスタ数の多さ、高機能さがクロック上昇を妨げるガンだった。
----------------------
未だにこういうデマを信じてるヒトがいたことわ驚きす。
現実に同じ4-stageのパイプライン構成であるゆえに,同一プロセスの7400 G4をしのぐ動作クロックの
75x G3わ出なかったす。その上,結局AltiVecを採用する羽目になったG5わ,クロック競争を繰り広げる
x86プロセッサ並の動作クロックを達成しているす。
IBMも過去の誤りを悟って,CELL PPEやXbox360 PXに採用されている組込向け標準コアにAltiVecを
取り入れたというのに,時代遅れのお馬鹿さんわ未だに与太話を信じてるというのわ,実に滑稽な話す(笑)
- 297 名前:Socket774 :2006/03/18(土) 02:52:39 ID:ZgrBcRpF
- >>296
ヒント: 世代交代
- 298 名前:Socket774 :2006/03/18(土) 10:18:16 ID:hA7DT/OA
- アップルも誤りを悟って、Altivecを捨ててIntelを採用したようですが
- 299 名前:MACオタ>298 さん :2006/03/18(土) 10:54:22 ID:uXVRKq/u
- >>298
PPCアーキテクチャから離れられないものとして,Appleを舐めてかかったIBMわPPEベースのロードマップを
示し,IntelからわMeromを提示された。。。というのが事実す。
今となってわ,Jobsの正しさわ自明かと思うすけど。。。
- 300 名前:Socket774 :2006/03/18(土) 11:39:15 ID:ovRjIfAi
- >>299
ジョブズというかアップルのな
- 301 名前:Socket774 :2006/03/18(土) 12:11:32 ID:uQZT8kZu
- まぁMerom/Conroeが期待できる事が唯一の救い…
- 302 名前:Socket774 :2006/03/18(土) 12:25:36 ID:hA7DT/OA
- 全部IBMのせいなんだw
- 303 名前:Socket774 :2006/03/18(土) 12:48:00 ID:zlWt315h
- >>296
>現実に同じ4-stageのパイプライン構成であるゆえに,同一プロセスの7400 G4をしのぐ動作クロックの
>75x G3わ出なかったす。
Appleが使ってくれないのにそのクラスのプロセッサを作っても意味がないので作らなかっただけ。
- 304 名前:MACオタ>303 さん :2006/03/18(土) 13:08:45 ID:uXVRKq/u
- >>303
---------------------
Appleが使ってくれないのにそのクラスのプロセッサを作っても意味がないので作らなかっただけ。
---------------------
Intelへのスイッチを見れば判るように,Appleわ高性能プロセッサに選り好みわしないす(笑)
そもそもG4登場から,G5発表までの1999-2003の間,IBMとMotorolaからのプロセッサ購入数わ,ほぼ
半々だったって知ってるすか?
- 305 名前:Socket774 :2006/03/18(土) 13:17:43 ID:uQZT8kZu
- IntelがPowerPCを作ってくれればいいのに。
- 306 名前:Socket774 :2006/03/18(土) 14:14:17 ID:YwcbcftQ
- >>305
散々既出だが、何度でも言いたくなるな
- 307 名前:Socket774 :2006/03/18(土) 14:16:05 ID:YwcbcftQ
- >>303
高クロックの750がどうか知らないが、アップルへの出荷数は全体としては大したことないすよ
まあ言わなくてもわかるか
- 308 名前:Socket774 :2006/03/18(土) 14:38:42 ID:zlWt315h
- >>306
アップルとしてはG4より速いG3があると困るって事情もわかってるよな?
>>307
その「高クロックの750」の話をしているわけだが。
#ちゃんと「そのクラスの」と断ってるだろ?
- 309 名前:Socket774 :2006/03/18(土) 14:56:15 ID:/g3CJZMx
- IBMはインテルにさほど遅れる事なく1GHzのG3の試作品を発表してたよ。
不孝な事にG3はモトローラとIBMの両方で作ってた。
無論同じ仕様である事が求められた。
ま、IBMはアップルと切れて今度はAMDとタッグ組む。
パソコン市場への野望いまだ衰えず。
- 310 名前:MACオタ>308 さん :2006/03/18(土) 14:58:48 ID:uXVRKq/u
- >>308
----------------------
アップルとしてはG4より速いG3があると困るって事情もわかってるよな?
----------------------
まったく困らないどころか,現実に存在したす(笑)
例えば2001年初頭のラインナップ
・Power Mac G4 (Digital Audio): PPC7410/466MHz, PPC7410/533MHz
・iMac (early 2001): PPC750/500MHz, PPC750CXe/600MHz
2000年夏もG3とG4わ同一クロックだったす。
- 311 名前:MACオタ>309 さん :2006/03/18(土) 15:03:22 ID:uXVRKq/u
- >>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とわ何の関係も無いす。
- 312 名前:MACオタ@補足 :2006/03/18(土) 15:17:49 ID:uXVRKq/u
- 馬鹿にわ区別がつかなかったみたいすけど,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品が出荷されていたことを考慮すると,特に驚くべき
動作周波数とわ言えないことが判る筈す。
- 313 名前:Socket774 :2006/03/18(土) 15:30:04 ID:zlWt315h
- >>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
なんだけど?
ちっとでたらめにもほどがあるんでないの?
- 314 名前:Socket774 :2006/03/18(土) 15:33:04 ID:zlWt315h
- >>313
>> ・iMac (early 2001): PPC750/500MHz, PPC750CXe/600MHz
>2月に発表された水玉が500MHz。
上位機種は600MHz品があるけど、どちらにせよ733MHzは超えない。
- 315 名前:MACオタ :2006/03/18(土) 15:38:04 ID:uXVRKq/u
- >>313 さん
-------------------
2001/01の時点で733MHzが発表されているようだが?
#出荷は2月
-------------------
Macユーザーなら,7450/733MHzわ事実上4-5月まで出荷されず,7450/667MHzわ出荷されたかされないか
噂にも上らないうちに消えたのを覚えているかと思うす。
>>314 さん
-------------------
iMacDV+がG3/450MHz
-------------------
iMac DV Spesial Editionってご存知すか?
- 316 名前:Socket774 :2006/03/18(土) 15:51:22 ID:zlWt315h
- >>315
> Macユーザーなら,7450/733MHzわ事実上4-5月まで出荷されず,7450/667MHzわ出荷されたかされないか
> 噂にも上らないうちに消えたのを覚えているかと思うす。
それは「アップルとしてはG4より速いG3があって困る」話の補強にしかならないわけですが。
アップルとしてはG4>G3を維持するつもりでいたわけですから。
> iMac DV Spesial Editionってご存知すか?
確かにそれは500MHzでした。
dualとsingleでどうにか差別化を計っていた時期ですか。
少なくとも逆転しては困るとアップルは考えていたのでしょう。
- 317 名前:MACオタ>316 :2006/03/18(土) 16:07:35 ID:uXVRKq/u
- >>316
---------------------
少なくとも逆転しては困るとアップルは考えていたのでしょう。
---------------------
研究レベルでもG3の動作クロックわ600MHzに満たないという事実を示されても,G3の動作クロックわ
マーケティングで決定されたと主張するすか。。。
- 318 名前:Socket774 :2006/03/18(土) 16:09:12 ID:A4ZY19YF
- >>305
>>306
インテルがStrongARM、そしてXScaleを作ったら、
子供の喧嘩に大人が出てくる雰囲気あったな。
もうMIPSもSHもタジタジ。
もしインテルがPowerPC作ったら・・・
- 319 名前:Socket774 :2006/03/18(土) 20:25:24 ID:EbsvnMQ6
- >>318
XscaleもMIPSもSHも目指してる市場の方向性が違うからなぁ…。
WindowsCE系に関して言うなら、SHはそもそもPocket/HandheldPC2000な
モデルにさえ採用されてない(夢カスでの大ダメージが効いた?)。
MIPSも2000モデルでは各機種(OS変更程度の)マイナーチェンジがほとんど。
2000でStrongARM機が出てくる頃には、ぶっちゃけ
まぁPDAを作ってるベンダーもだけど、PDA分野をMIPS/SHは見限ってたんじゃないかと…。
- 320 名前:Socket774 :2006/03/18(土) 21:11:28 ID:VcCD3huP
- SH系は、CE云々以前に、もうエンベデッド市場しか見てないでしょ。
開発サイドはともかく、営業サイドとしてはの話ね。
- 321 名前:Socket774 :2006/03/18(土) 21:51:04 ID:EbsvnMQ6
- >>320
SHは最初から組み込み主体ってかその為の16bitだし、
売りこみデモとしてのCE機だったと思うよ。
でも、売れていたならCE機続けただろうとも思う訳で。
- 322 名前:Socket774 :2006/03/18(土) 22:56:25 ID:j4XgKlW2
- >>321
まぁSHの迷走期とも被るからな。
上位の開発がSuperH社で
ルネサスと分離していたあの頃は
どういうロードマップだったんだか。
- 323 名前:Socket774 :2006/03/18(土) 23:07:44 ID:O9dn+GVq
- PDA系ってゆーとドラゴンボールを思い出すんだが
あれって今どうなったの?
- 324 名前:Socket774 :2006/03/18(土) 23:11:59 ID:j4XgKlW2
- モトローラがARM系採用してジ・エンドでなかったか
- 325 名前:Socket774 :2006/03/18(土) 23:53:06 ID:ZgrBcRpF
- ARMのやつもドラゴンボールではある
- 326 名前:Socket774 :2006/03/19(日) 00:04:29 ID:mfqqr/a3
- >>317
> 研究レベルでもG3の動作クロックわ600MHzに満たないという事実を示されても
それは98年の発表
- 327 名前:Socket774 :2006/03/19(日) 01:13:08 ID:Om73/icH
- 世界で最も売れたARMはGBAという事実
- 328 名前:MACオタ>326 さん :2006/03/19(日) 10:35:10 ID:FleFeaND
- >>326
>>312に書いた通りす。見直すとISSCC99の間違いすけど(笑)
で,この脳内妄想のソースわ見つかったすか?
-------------------------
IBMはインテルにさほど遅れる事なく1GHzのG3の試作品を発表してたよ。
----------------------
- 329 名前:Socket774 :2006/03/19(日) 16:43:37 ID:KKkfbELA
- 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系の雑誌で騒いでた記憶がある。
- 330 名前:Socket774 :2006/03/19(日) 16:45:46 ID:KKkfbELA
- なんか思い出してきたよ。
iMacに1GHzのG3が載ると思っていたのに廉価版G3の500MHzくらいになっててがっくりした記憶が。
- 331 名前:Socket774 :2006/03/19(日) 19:30:25 ID:Ahdge2j8
- >>329
リンク先読んでなくて申し訳ないが、
たしか750FXは2001年10月発表で、2002年前半に700だか800MHz出荷開始、後半に1GHzまで到達するという話だった。
ま、でもSOI採用で驚いたのは覚えてる
SOI採用プロセッサの出荷では、2002年1月の7455 1GHzの方が早かったかも
- 332 名前:Socket774 :2006/03/19(日) 23:00:36 ID:mfqqr/a3
- >>331
結局G3 1GHzの採用例はあったの?
- 333 名前:MACオタ>329, 331 さん :2006/03/20(月) 00:20:17 ID:s03r4DX7
- >>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
- 334 名前:Socket774 :2006/03/20(月) 01:47:54 ID:aUOyi0Bk
- 頭わるそうな文章だな。
- 335 名前:Socket774 :2006/03/20(月) 03:18:24 ID:etegJ5Ls
- Conroe/Meromに対抗できるプロセッサはいつごろ出てくるのか
- 336 名前:Socket774 :2006/03/20(月) 03:44:16 ID:wZhbI+fi
- 事あるごとに書かれる「Athlon64 90nm SOI」のSOIは
>>333のIBMの技術だから笑える
他にも採用しているのを全部書かないとダメじゃん
まあ2chで書いてるやつは、自社技術だと思いこんでるのかもしれないがw
- 337 名前:Socket774 :2006/03/20(月) 03:55:07 ID:etegJ5Ls
- おれはどうしてもSPARC64の高性能ぶりが気になってしかたがない。
- 338 名前:Socket774 :2006/03/20(月) 18:00:52 ID:8gKKv+jy
- ってかお前ら、荒らしに構う奴も荒らしっていう2chの掟を忘れたか?
いつまで糞オタいじってんの。
- 339 名前:Socket774 :2006/03/20(月) 23:23:07 ID:/aKHHKfZ
- >>338
お前は何をいってるんすか?
- 340 名前:Socket774 :2006/03/20(月) 23:50:25 ID:aXBJXzWn
- >>290
この前PCWatchで後藤が面白い記事書いてて
>既存のソフトウェア資産を重視しない用途ではitaniumやpowerが選ばれる。
〜
>x86である必要の無いゲーム機もpowerを採用。
な感じで今までゲーム業界やってきた。
しかし最近は開発環境の高度化&ライブラリの複雑化、肥大化。
開発者がハードに「やっと」こなれてくる頃には
すでにモデルチェンジ、このスタイルを継続するのはもはや無理だと
いう内容。
結局Intelがこれだけ労力払ってx86維持してるには
ちゃんと理由があって
そのお陰でゲーム業界のような惨状にはならんわけだ。
- 341 名前:Socket774 :2006/03/20(月) 23:53:52 ID:/aKHHKfZ
- >>340
>結局Intelがこれだけ労力払ってx86維持してるには
>ちゃんと理由があって
>そのお陰でゲーム業界のような惨状にはならんわけだ。
前半は全くその通りだが、これはゲーム業界の責任
ItaniumもPOWERも、脈々と続くものがある
例えばPPC970全面廃止でCellのみに移行する、というわけじゃないだろ?
それこそ440や750や10xだってあるわけで。
Cellを採用しちゃったのは採用側の責任
- 342 名前:Socket774 :2006/03/21(火) 00:08:09 ID:l+UWDQAJ
- >>341
同意しとく
- 343 名前:Socket774 :2006/03/21(火) 19:56:25 ID:1Ao9CpuA
- >>341
X箱360のPPE(みたいなもの)x3onlyはまだソフト屋さん(MS)的なのね
よくもわるくも(エンターテイメントからは)アウトサイダーなのかも?
- 344 名前:Socket774 :2006/03/22(水) 00:57:14 ID:dEVa0BS4
- ろくなソフトも書いたことがない奴がドリーム全開で作ったのがCellだから責めるのはかわいそう
- 345 名前:MACオタ>344 さん :2006/03/22(水) 01:03:55 ID:abgVcQI8
- >>344
プロセッサアーキテクトがソフトを書くモノという説わ,初耳す(笑)
- 346 名前:Socket774 :2006/03/22(水) 01:14:22 ID:msr/3HLt
- Andy Glewはもともとプログラマだった
- 347 名前:Socket774 :2006/03/22(水) 02:03:47 ID:dEVa0BS4
- >>345
君はもうちょっと見聞を広めたほうがいいよ
- 348 名前:Socket774 :2006/03/22(水) 02:30:08 ID:OF5GjU+1
- てか、くたらぎってプロセサアーキテクトじゃないだろ
- 349 名前:Socket774 :2006/03/22(水) 10:46:18 ID:YQ+x7A6I
- >>344
特段変なアーキテクチャだとは思えないんだが?
むしろ、手堅いと思う。
- 350 名前:Socket774 :2006/03/22(水) 12:36:11 ID:JtnbUSn1
- 確かに、MPEG2動画48本同時デコード、を行う上では手堅い作りだな。
- 351 名前:Socket774 :2006/03/22(水) 13:30:43 ID:Da2x0FjY
- まぁ、Cellは汎用プロセサとして創ったのならあれだが、
ゲーム機プロセサとして創ったわけだから、あれはあれでいいんじゃね
- 352 名前:Socket774 :2006/03/22(水) 14:43:57 ID:dEVa0BS4
- >>351
そのゲームデベロッパーから不満がきているわけだが
- 353 名前:Socket774 :2006/03/22(水) 16:16:16 ID:YQ+x7A6I
- そりゃまた何ゆえ?
- 354 名前:Socket774 :2006/03/22(水) 17:47:10 ID:Z+jT/9R5
- ゲハ厨が湧いてくるのでCellだけは勘弁してください
- 355 名前:Socket774 :2006/03/22(水) 19:34:56 ID:ZB1fIePO
- cellって別にラディカルじゃないだろ
3.2Ghzってクロックはすごいが
- 356 名前:Socket774 :2006/03/22(水) 19:47:13 ID:5P2sjGLI
- >>355
Cellはクロック上げやすい設計だとか言ってたな、たしか。
ベースの970とは違う構造だったかもしれないけど。
ちなみに、Cellは5Ghz超で動いてることが発表されている。
- 357 名前:Socket774 :2006/03/22(水) 19:50:23 ID:ZB1fIePO
- >>356
970とは関係ない
なお、実行部分のパイプラインは970やpentium4より深い
- 358 名前:Socket774 :2006/03/22(水) 20:25:33 ID:gT2m524A
- cellが楽しみ
- 359 名前:Socket774 :2006/03/22(水) 20:33:45 ID:lBerqlvG
- なのはGKと信者だけ
- 360 名前:Socket774 :2006/03/22(水) 22:19:49 ID:Hb2Amb4h
- >>359
なのはGreat king!?
そうか、Cellはアニヲタかつ信者、つまりゴトーへのメッセージだったんだよ!!!!!
- 361 名前:Socket774 :2006/03/22(水) 22:22:58 ID:5ZeD6OSG
- なのはGoto Kitakore
- 362 名前:Socket774 :2006/03/24(金) 01:21:50 ID:pvx057+C
- >>356
5GHzってCell全体だっけ?
SPEだけかとおもった
- 363 名前:Socket774 :2006/03/25(土) 15:15:13 ID:aRDGH1rj
- 公開キタよ
ttp://opensparc.sunsource.net/nonav/index.html
- 364 名前:Socket774 :2006/03/28(火) 23:47:54 ID:PBTyVsW3
- ちょっと古いけど↓これってどうなん?
http://www.theregister.co.uk/2006/03/14/sun_rock_deets/
- 365 名前:Socket774 :2006/03/29(水) 12:40:36 ID:H4OnGL9Y
- NAPを推進する米Azul、ワンチップに48コアを統合した「Vega 2」発表