[x86]CPUアーキテクチャについて語れ！[RISC]

■戻る■ 自作PCに戻る元のスレッド全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

1 名前：Socket774 ：04/04/19 15:59 ID:xbBch3+r: お前らいい加減、無能なAMD房・Intel房に振りまわされず、
エンコ時間がどうとかPIがどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。

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

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

さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！
2 名前：Socket774 ：04/04/19 16:00 ID:mp08SBe2: ２げっとおおお
3 名前：剣山ﾓｶ ◆lfYWD.onQ2 ：04/04/19 16:01 ID:IFIAHoq5: 3
4 名前：Socket774 ：04/04/19 16:02 ID:W4UAIL3H: ヤダ！
5 名前：Socket774 ：04/04/19 16:02 ID:xbBch3+r: PC用CPU作ってる主な半導体メーカ：

IBM
http://www.ibm.com/

Intel
http://www.intel.com/

AMD
http://www.amd.com/

VIA Technology
http://www.viatech.com/
6 名前：Socket774 ：04/04/19 16:04 ID:xbBch3+r: お前らはこれからRISCかCISC、どちらになると思いますか？

最近は元気の無いRISC陣ですが、.net frameworkが普及すれば、
ちょっとしたきっかけで逆転するかもしれませんよ。
7 名前：Socket774 ：04/04/19 16:05 ID:mp08SBe2: むつかしすぎて分かんない・・・orz
8 名前：Socket774 ：04/04/19 16:07 ID:xbBch3+r: お前ら・・・まさかCPUのアーキテクチャも理解しないで、
HTだのパイプラインだの語っていたわけじゃあるまい？
9 名前：うさだ萌へ ◆yGAhoNiShI ：04/04/19 16:08 ID:v2F/lsw6: なーんも知らん
10 名前：さっきゅん ◆WAHAH0fe4c ：04/04/19 16:10 ID:PoavHFnz: 禿同
11 名前：Socket774 ：04/04/19 16:12 ID:xbBch3+r: http://e-words.jp/w/RISC.html

RISC　【縮小命令セットコンピュータ】
読み方：リスク
フルスペル： Reduced Instruction Set Computer

マイクロプロセッサの設計様式の一つ。
個々の命令を簡略化することにより
パイプライン処理(並行して複数の命令を処理する方式)の効率を高め、
処理性能の向上をはかっている。
ワークステーション用のCPUにはこの型のプロセッサが多い。
Sun Microsystems社のSPARCや
DEC社(現在はCompaq Computer社の一部門)のAlpha、
IBM社とMotorola社のPowerPCなどが有名。
12 名前：Socket774 ：04/04/19 16:12 ID:xbBch3+r: http://e-words.jp/w/CISC.html

CISC　【複合命令セットコンピュータ】
読み方：シスク
フルスペル： Complex Instruction Set Computer

マイクロプロセッサの設計様式の一つ。
個々の命令を高級言語に近づけ、
複雑な処理を実行できるようにすることで処理能力の向上をはかっている。
パソコン用のCPUとしてあわせて9割以上のシェアを持つ
Intel社のx86シリーズとその互換プロセッサがこの型である。
13 名前：Socket774 ：04/04/19 16:14 ID:xbBch3+r: http://e-words.jp/w/SRAM.html
SRAM
読み方：エスラム
フルスペル： Static Random Access Memory

RAMの一種。記憶素子としてフリップフロップ回路を用いるもので、
記憶保持のための動作を必要としない。
そのぶん高速に動作するが、
回路が複雑になり集積度を上げにくいという欠点をもつ。
14 名前：Socket774 ：04/04/19 16:14 ID:xbBch3+r: http://e-words.jp/w/E38395E383AAE38383E38397E38395E383ADE38383E38397E59B9EE8B7AF.html

フリップフロップ回路　【flip-flop circuit】
読み方：フリップフロップカイロ

　「high」と「low」の二つの安定状態を持つ電子回路。
二つの状態を「0」と「1」に対応させることで、1ビットの情報を保持できる。
加える信号によって二つの状態が交互に変化するようにできている。
大規模な電子回路を構成する基本的な素子で、SRAMや、
マイクロプロセッサ内部のフラグやレジスタ等の記憶回路に使われる。
15 名前：Socket774 ：04/04/19 16:16 ID:xbBch3+r: ちなみに、SRAM(=フリップフラップ回路)は4～6回路で構成され、
Intelは従来より6回路で構成するSRAMを頑なに使ってきたが、
Pentium Mでは4回路のフリップフラップ回路を使用。
電気的な特性による4回路のSRAMの脆弱性については、
公表していない方法にて解決したもよう。
16 名前：Socket774 ：04/04/19 16:18 ID:xbBch3+r: http://e-words.jp/w/E38391E382A4E38397E383A9E382A4E383B3.html

パイプライン　【pipeline】
読み方：パイプライン

マイクロプロセッサ(MPU)の高速化手法の一つ。

　プロセッサ内での1つの命令を処理は、
命令の読み込み、解釈、実行、結果の書き込みなどのように、
複数の段階からなるサイクルで構成されている。
通常は、前の命令のサイクルが完全に終わらないと、
次の命令を処理し始めることはできない。

　各段階の処理機構を独立して動作させることにより、
流れ作業的に、前の命令のサイクルが終わる前に
次の命令を処理し始めるのがパイプライン処理である。
工場の流れ作業で使うベルトコンベヤのようなものだと言える。

　パイプライン機構を備えたプロセッサでは、
前の命令の実行を行なっているときに
次の命令の解釈を行なうといった処理が可能になる。

　複数のパイプラインで並列に命令を
処理できるようにする機構をスーパースカラという。
パイプラインのうち段階数が多いものは
「スーパーパイプライン」と呼ばれる
(最も極端なパイプラインを持つPentium 4では
特に「ハイパーパイプライン」を自称する)。
17 名前：Socket774 ：04/04/19 16:19 ID:xbBch3+r: http://e-words.jp/w/E382B9E383BCE38391E383BCE382B9E382ABE383A9.html

スーパースカラ　【superscalar】
読み方：スーパースカラ

マイクロプロセッサ(MPU)の高速化手法の一つ。
プロセッサの中に複数の処理系統(パイプライン)を用意し、
複数の命令を並列に処理すること。
18 名前：Socket774 ：04/04/19 16:20 ID:xbBch3+r: http://e-words.jp/w/VLIW.html

VLIW

読み方：ブイエルアイダブリュー
フルスペル： Very Long Instruction Word

マイクロプロセッサの高速化技術の一つ。
依存関係にない複数の命令を一つの命令としてまとめて同時に実行する。
同時実行される命令の数は常に一定に保たれ、
規定の数に達しない場合は「何もしない」命令で埋められる。
1命令の長さが従来のプロセッサに比べてきわめて長いため、
このような名前で呼ばれる。

追記：有名なのはノートPCに使われているT社のCPU。
19 名前：Socket774 ：04/04/19 16:24 ID:xbBch3+r: http://e-words.jp/w/SISD.html

SISD
読み方：シスド
フルスペル： Single Instruction/Single Data

　マイクロプロセッサにおいて、
1つの命令で1つのデータを扱う処理方式。
SIMDやMIMDとの対比に用いられる用語である。

http://e-words.jp/w/MIMD.html

MIMD
読み方：ミムド
フルスペル： Multiple Instruction/Multiple Data

複数のマイクロプロセッサを搭載した並列コンピュータ上で、
複数のプロセッサが複数の異なるデータを並行処理する方式。
SISDやSIMDとの対比に用いられる用語である。

http://e-words.jp/w/SIMD.html

SIMD
読み方：シムド
フルスペル： Single Instruction/Multiple Data

マイクロプロセッサにおいて、1つの命令で複数のデータを扱う処理方式。
DSPやスーパーコンピュータで利用されている。
Intel社のマイクロプロセッサに組みこまれている
MMXやSSEなどのマルチメディア拡張機能もSIMDの応用である。

追記：1つの命令で1つのデータを処理するのがSISD、
1つの命令で複数のデータに同じ処理をするのがSIMD、
複数の命令で複数のデータを処理するのがMIMD。
20 名前：Socket774 ：04/04/19 16:33 ID:xbBch3+r: パイプラインとスーパスカラ(別読：スーパースケーラ)についてご覧あれ。

第1章　パソコンの基礎知識
http://pc1.moo.jp/kiso/cpu5.htm
21 名前：Socket774 ：04/04/19 16:44 ID:xbBch3+r: 最近よく耳・目にするアウトオブオーダー(Out of Order)とは何だろうか？

Pentium(全)やAthlon(全)はパイプライン方式のCPUである事は言うまでもないが、
このパイプライン制御ではある問題が発生します。

パイプライン方式のプロセッサでは、その構造上、
各命令が完全に処理される前に次の命令(仮に命令2)の処理が始まる事になりますが、
この時、先に読み込まれた命令(仮に命令1)に分岐命令等が含まれていた場合、
つまり命令2が命令1の実行結果によって異なる場合、
命令2を命令1の処理完了前に読み込む事が出来ません(実際はもうちょっと複雑)。

一般的にこのような命令1と命令2の関係をインオブオーダー(In of Order)と呼び、
この関係の無い命令1と命令2の関係をアウトオブオーダー(Out of Order)と呼びます。

この時、当然アウトオブオーダー関係の命令を実行していった方が、
全体の処理時間は短くてすむことになります。
その為、最新のPC向けプロセッサでは、
出来るだけOut of Order関係の命令を同時に処理するよう、
命令の処理順序を入れ替えたりします。
22 名前：Socket774 ：04/04/19 16:53 ID:xbBch3+r: また、いくら並べ替えるといっても全ての命令が
アウトオブオーダーになるわけではありませんので、
先に実行されると"予想される"命令2の処理をやってしまう、
という考え方も行われています。

この場合、予想が当たれば、分岐しない場合と同じように、
連続して次々と命令を実行出来るため大変高速です。

しかし、一度予想が外れるとそれまで処理していた
命令2の処理を中断しなければならないばかりか、
新たな(本来処理すべき)命令2の処理を初めから行わなければなりません。
このような負の遺産を一般にペナルティと呼びます。

そしてこの考え方では、どの命令2を実行するか、
その"判定があたる確立"が大変重要となります。
その判定の事を"分岐予想"と呼び、最新のプロセッサでは、
分岐予想テーブル等を用いて、当る確立を高める努力がなされています。
例えばPentium 4の分岐予想は、
80～90%の確立で当たるといわれています。
23 名前：Socket774 ：04/04/19 16:56 ID:Yrb98hrb: >>1が一生懸命なのは判るが、正直カラ回り気味かと
24 名前：Socket774 ：04/04/19 16:58 ID:HUYW35Qr: こゆまじめな話をまじめに聞けないから便所の落書きっていわれるんだよな…
25 名前：Socket774 ：04/04/19 17:09 ID:xbBch3+r: しかし信じられん。こんなにCPUスレが乱立しているから、
さぞ知識のある奴がいるのかと思ったら、
まさか誰も興味すら持たないとは・・・

削除依頼出してきた方が良いか・・・
26 名前：Socket774 ：04/04/19 17:12 ID:Yrb98hrb: 正直SMID以外の内容は1990年(１月号ぐらい？)のSuperAsciiに全て書かれてる
今更語るほどの事でもない
27 名前：Socket774 ：04/04/19 17:13 ID:PoavHFnz: そもそも板違いじゃないの？
28 名前：Socket774 ：04/04/19 17:13 ID:Yrb98hrb: ああすまん、１０月号だったかもしれん
29 名前：Socket774 ：04/04/19 17:15 ID:HUYW35Qr: そこで萌えCPU作成本みながら2ch式ﾊｲｴﾝﾄﾞCPUの設計するんじゃないのか。
自作板だけに。
30 名前：うさだ萌へ ◆yGAhoNiShI ：04/04/19 17:17 ID:v2F/lsw6: いくら知識つけても、CPUの設計なんて世界中で何人がやらせてもらえるんだよ
31 名前：Socket774 ：04/04/19 17:18 ID:PoavHFnz: FPGA使えば個人でもできる
32 名前：Socket774 ：04/04/19 17:30 ID:Yrb98hrb: >>29
AlteraMAXで4004でも作れば？('A`)
33 名前：Socket774 ：04/04/19 17:49 ID:HUYW35Qr: とりあえず32bit全加算器を 1段でつくるのと
32段でパイプ処理するのとを、設計して比較してみると楽しいぞ？
34 名前：Socket774 ：04/04/19 18:50 ID:62qCx3yH: >>25
そんな事を書くと、
それを書きたいがためにスレ立てたのではと邪推してしまうぞ。
脳ある鷹は鷹のつめですｗ
35 名前：Socket774 ：04/04/19 19:48 ID:Am1Iih+j: >19
MISDは?
36 名前：Socket774 ：04/04/19 20:52 ID:1w5Zm78V: ARMﾜｼｮｰｨ
37 名前：Socket774 ：04/04/19 21:59 ID:mCzgR/pk: スルーされる>>26。

ここは15年前に2chがあったらスレになりました。
38 名前：ネタふってみる ：04/04/20 07:28 ID://r7Q2AL: SPARCの、メモリ待ちの間に別スレッドの作業するっつー技術は面白いと思った。
39 名前：1 ：04/04/20 10:58 ID:YUG4KRHR: >>38
たしかにSPARCは色々と面白い仕組みを搭載していると聞きいています。
そういえばAlphaも似たような仕組みを搭載していませんでした？
40 名前：Socket774 ：04/04/20 13:26 ID:i1ToaY7t: http://www.ieice.org/jpn/books/kaishikiji/199910/19991001.html
41 名前：Socket774 ：04/04/20 13:33 ID:/aWbcpbp: >>37
喪前の世界は2chだけで構成されてんのか
42 名前：Socket774 ：04/04/20 13:50 ID:/KOdfewY: スーパースカラの説明にただのスカラプロセッサ
ベクトルプロセッサが全く見えてこないのは
如何なものかと。
43 名前：38 ：04/04/20 18:28 ID:oF+DZzPK: 21364は、単にコア4つ統合して4スレッド並行作業させてるだけじゃ
なかったっけか。

他のCPUだとメモリアクセス時にボケーっと待ってるのに対し、
SPARCのは別スレッドの作業して、メモリが反応する頃に
元のスレッドの作業を再開するんだと思った。

遅いと評判のC3と同じシングルスケーラコア1つで4スレッドを処理、
これを8つ格納した1個のCPUパッケージで合計32スレッドを処理する。

あまり細かい事は知らないので専門家カモン。
44 名前：Socket774 ：04/04/21 10:29 ID:We9VaRpB: >>43
同時に32スレッドですか？すげーな。
45 名前：Socket774 ：04/04/21 12:22 ID:C062+oEh: Pen4やAthlonってスレッドの切り替えに何クロックくらいかかるんですか？
46 名前：Socket774 ：04/04/21 13:13 ID:jnJgfs7K: ３クロックくらい？
47 名前：Socket774 ：04/04/21 15:15 ID:DSW571cD: >>45
スレッドの切り替え時間は，そのOSに依存する。
48 名前：Socket774 ：04/04/21 16:06 ID:vHo151Yl: x86アーキテクチャについて語るだけならCPUハード部分に深入りしすぎ。
まぁ、RISCとCISCについての比較とかはx86アーキテクチャ依存部分でも
あるから解るけどさー（x86はCISC系）

で、ついでに上記の補足CISCは従来型のCPUと思ってok
RISC:
命令語が少ないので、CPU内部の命令語解析処理部分が小さい。←これが目的
命令語が少ないので、語長が揃いパイプライン化しやすい。
命令語が少ないので、同じ処理ならCISCよりメモリが必要。
49 名前：Socket774 ：04/04/21 19:57 ID:eyK6Lekz: 最近のCISCは内部でRISC変換、RISCは命令数増やしまくってCISCみてーになってるし。
なんかおかしくね？それとも理想的なCPUに近似してきてるって事？
その挙句100W駆動てバッカじゃねーの・・・
50 名前：Socket774 ：04/04/21 21:28 ID:C062+oEh: メモリ－レジスタ間の処理がロードとストアしかないだけで
A=B*C+Dとかが１命令でできるし
51 名前：Socket774 ：04/04/22 19:54 ID:JQGC2Jlr: >>49
x86もWindowsも普及しすぎた為に互換性(以下略
52 名前：Socket774 ：04/04/22 22:45 ID:iWzh8IZ1: パイプラインが深いと分岐予測ペナルティーによる喪失が大きいのは解るのですが、
スーパースカラーで並列に処理しようとしても、依存関係がある場合は、
他のパイプラインに振り分けて処理出来ないので同じに思えてしまいます。
依存関係の有る処理に対する二者の優劣はあるのですか？
あるとすればどのような事に起因するのですか？
そこが解らない。
53 名前：Socket774 ：04/04/23 00:39 ID:Qt/VQEvM: 依存関係のある命令では、スーパスケーラでもスーパパイプラインでも
結果が出るまで次の命令の実行に移れない点で同時実行はできません。
命令を入れ替え、パイプから出てくるのをまってから次の命令を投入する
形になり、その点では優劣はどっちもかわらないんじゃないかな。

スーパスケーラが、一サイクル中に同時実行できる演算数を増やす工夫に対し、
スーパパイプラインは一サイクルにかかる時間を短くする工夫※なので、ふつうは
両方をバランスよく同時に投入してCPUを作ります。Pentium4然り。

※ロジックのゲート速度は今やほとんど上げられないため、回路が複雑になると
その回路に入った信号が出てくるまでの時間は長くなります。つまり一サイクル
にかかるが長くなってしまうわけで、その逆数たるクロックは高くできません。
54 名前：Socket774 ：04/04/23 01:16 ID:Qt/VQEvM: 二進の足し算はご存知でしょうか。
二進は0か1しかありませんから、1+1の答えは0で、桁上がりが一つ発生します。

二桁の足し算の場合、一桁目の桁上がりを、二桁目に足します。
これは十進数の足し算でも同じですよね。
11+11の場合、最初に 1+1を計算して一の位は 0、桁上がりは1。
次に 10+10に10を足して、ニの位は 1+1+1ですから 1、桁上がりは1
同様に、32bit分の計算を行う場合、下の桁から順番に桁上がりを考えながら32回足していきます。

一つ分の桁と桁上がりの分を足す回路を全加算器っていいますが、この回路でかかる時間を
たとえば1秒としてみましょう。32bitの加算は下の桁の桁上がりが出てくるまで次の桁の計算に
入れませんから、全加算器を32回繰り返すのと同じ時間がかかり、32秒かかります。

スーパスケーラは、この加算回路をたとえば二つもっているものです。
同時に別の足し算を二つこなせますから、32秒の実行時間中に二つの演算が行えます。
倍の処理性能ですね。

一方、スーパパイプラインは、たとえば1bit全加算器一つ一つを1ステージにしちゃいます。
32個のレジスタを用意しておいて、1bit計算したら1bitずつストアしていきます。
一回の計算に32回1bitの全加算器をまわします。でも、1ステージは 1bitの全加算器を一回
しか通しませんから、なんと1秒で処理が可能になり、先ほどと比べて32倍も早く次のステップ
に進めます！

でも、32回繰り返すので一つの足し算にかかる時間は結局32秒かかり最初と
変わりません。ただ、1ステージ終ったら、下の桁では別の計算をさせることが可能ですね。
結果として、なんと！32秒で32個の足し算が可能になります！（最初に31秒の空白時間があります）

なんかすごそうですけど、カッコの中身もすごく気になりますね（笑
つまり、そーゆーことなんです。
55 名前：Socket774 ：04/04/23 02:06 ID:pvrP7fWs: >>53
お答えいただきありがとうごさいました。
という事は、アス論系がペン④系に比べて、分岐の多い処理に強いというのは、
ペン④よりスーパースケラー方向である事とは直接関係はないとの理解で良いのでしょうか？
別の言い方をすると、ペン④のパイプが深い事自体が原因ではなくて、
パイプ深い割にはクロックを稼げていない事で、分岐の多い処理
で不利になっているとの理解で良いすか？
56 名前：Socket774 ：04/04/23 02:40 ID:pvrP7fWs: >>54を読んで
>>55の疑問も解けました。
丁寧な説明本当にありがとうございました。m(__)m
クロック速さをパイプの段数で割って考えないと、依存関係の有る処理の速さは見えて来ない
と言う事ですね。
57 名前：Socket774 ：04/04/23 02:59 ID:ovgCbSft: x68なら語れるんだが、よくワカンネ
58 名前：Socket774 ：04/04/23 03:31 ID:2VhjBzOk: おい、CRISPはどこに消えたんだ?
59 名前：Socket774 ：04/04/23 05:49 ID:I/xqR3gx: ほらよっと　がんばって勉強してね～

広島市立大学アーキテクチャ　お勧め
http://www.arch.ce.hiroshima-cu.ac.jp/~kitamura/public/architecture_2003.htm

東大コンピュータハードウェア　資料だけだとわかりにくい
http://www.mtl.t.u-tokyo.ac.jp/~sakai/hard/

京大コンピュータアーキテクチャ　細か過ぎ
http://www.lab3.kuis.kyoto-u.ac.jp/members/tomita/lecture/lecture.html

東工大計算機システム講義・演習　ハードウェアの設計の話が中心
http://matsu-www.is.titech.ac.jp/~naoya/ta/compsys2003/

英語のは有名大学のをふたつ

Stanford Computer Architecture & Organization
http://www.stanford.edu/class/ee282/handouts.html

MIT Computer System Architecture
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-823Computer-System-ArchitectureSpring2002/LectureNotes/index.htm
60 名前：Socket774 ：04/04/23 09:48 ID:eUB8kbTE: パイプラインの各段の処理時間が等しい時、

処理時間 = ( パイプライン段数 + 命令数 - 1 ) × 1段の処理時間

となることが知られています。
61 名前：なぜPentium 4はクロックのわりに遅いのか・・・ 1 ：04/04/23 09:52 ID:eUB8kbTE: 一般にPentium 4はAthlonやPentium 3系よりもクロック当りの性能が低い事が知られていますが、
これはハイパーパイプライン(余りに長いためIntelがつけた名前)という仕組みだけでなく、
Pentium 4のコア構造、半導体テクノロジー等、様々な要因が密接に関係しています。
62 名前：Socket774 ：04/04/23 10:00 ID:XygWom31: 俺自身かなり技術論は好きなんだが、このスレが盛り上がらないのは
技術について語り会うってよりもネットちょっと調べれば分かる程度の
内容を、独り言のように連続投稿する人がいるので
それでひいちゃう人が多いんじゃないかとｵﾓﾀ。

Itanium2スレとかIntel次世代はちゃんとコミュニケーション(煽り合いも含めて)
があるからそれなりに技術論が盛り上がってるし。
63 名前：なぜPentium 4はクロックのわりに遅いのか・・・ 2 ：04/04/23 10:00 ID:eUB8kbTE: まずはCPUというか半導体の仕組み自体をおさらいしておきましょう。
CPUは2進数で計算をするという事は良く知られていますが、
これは実際には電気回路によって構成された論理回路によって実現されています。
そして論理回路は、さらに次の原始的な仕組みに分解する事ができます。

ソース<->ゲート<->ドレイン

この時、ゲートは通電可能か通電不可能を変更する事ができるシリコンです。
ゲートが通電可能な場合、ソースに電力を与えるとドレインからも電力を取れます。
ゲートが通電不可能な場合、ソースに電力を与えてもドレインからは電力が取れません。

この単純な仕組みによってCPUは構成されています。
64 名前：Socket774 ：04/04/23 10:01 ID:eUB8kbTE: >>62
OK。じゃあ連続投稿止めるからネタ提供してくれよ
65 名前：Socket774 ：04/04/23 10:03 ID:qSs+361h: >>63
いい加減な事書くな
トランジスタの基礎をもう一回勉強してこい
66 名前：Socket774 ：04/04/23 10:29 ID:1uIF7LsS: >>65
確かに、FETの説明で「電力を取れます」は無いよなw

俺もこのスレタイみた時は、いいスレできたじゃんとか思っだけど
正直スレの内容読んだらなんか自閉症的な連続投稿ばかりで
書き込む気がしなくなったな。
Intel vs AMDスレみたいな過度の煽り合いは不毛だと思うが、
ある程度の煽り合いはスレの肥やしになるんだよな。
そういう意味で>>65みたいなレスは貴重。

>>1の方針自体は悪く無いスレだから方向転換しつつ巧く育てていきたいスレだとは思う。

漏れもここで一つネタ振っておこう。
x86CPUが内部RISC化してCISCの弱点を克服してきたって言われてる
訳だけど、プログラムレベルでレジスタがたった8本ってのは糞過ぎる。
レジスタリネーミングとかコンパイラの最適化で逃げているが
やっぱり元が糞なものはどうしょうもない。この点に関しては絶対に今時のRISCに勝てない。
煽り的反論大歓迎。
67 名前：Socket774 ：04/04/23 10:48 ID:v2w9JcUV: >>66
AMD64で解決しませんか？
68 名前：Socket774 ：04/04/23 10:50 ID:XygWom31: >プログラムレベルでレジスタがたった8本ってのは糞過ぎる。

今時x86をアッセンブラで組むやつなんてほとんどいねえんだし
もしも本当に論理レジスタ本数で困ってるなら64bit拡張の際にたったの
16本程度の拡張で済ませる訳ねーだろｳﾞｫｹ!!
内部レジスタ使ってスケジューリングで誤魔化せば8本でもたいして困ってないんだよｳﾞｫｹ!!
それに拡張命令セットの方の方なら潤沢にレジスタあるだろｳﾞｫｹ!!

知ったかは氏ね!!
69 名前：Socket774 ：04/04/23 10:50 ID:qSs+361h: 16個は多杉
使いきれない
70 名前：Socket774 ：04/04/23 10:51 ID:bLINDbMj: そもそもトランジスタの説明で

電力を取れます

はねぇだろ。
バイポーラとかFET以前の問題。

つーかリア厨か？
電圧何Aとか
電流何Vとかいうような馬鹿？
71 名前：Socket774 ：04/04/23 10:55 ID:9NtWgErj: >>66
x86のレジスタが少ないことを克服するのがPentium4(Willamette,Northwood)の
低レイテンシL1キャッシュ。「x86のL1なんてしょせんスピルがほとんど
でしょ」と割り切って、小容量(8KB)・低レイテンシ(2cyc)に振った。
IA-64のレジスタが2KB(8B*128本*2セット)であるのに比べて、その4倍でしかない。
これの効果は明らかで、Northwood(ベースのXeon)は明らかにRISCと互角。
(Itanium2スレのベンチマーク結果見てるよね)
要するに「高速にスピルできればレジスタなんて少なくてもOK」ということ。

せっかくのこの特長を、L1キャッシュ容量を16KBに増やしてレイテンシ4cycと
増やしてしまったPrescottがクソなのはこの板の常識。
72 名前：Socket774 ：04/04/23 10:56 ID:bLINDbMj: 正直8本とか言って有り余ってる。

PICとかAVRで完全アセンブラで組むと2本（つーかALUが足し算できる最低本数）
あれば事足りる。
アセンブラで組むとしてもレジスタを考慮したくない。
73 名前：Socket774 ：04/04/23 10:59 ID:v2w9JcUV: >>68
同意。

そもそもx86アーキテクチャなんて終わってるんだから、
今更レジスタ増やしたりされてもかえって迷惑。
これからはJavaや.net frameworkどんどん使って、
早く新しいアーキテクチャに移行しないと、業界が滅びる。
74 名前：Socket774 ：04/04/23 11:03 ID:5YQCLa+R: 漏れ>>33 = >>53-54 なんだけど、>>1 や>>11-22とは別なんでよろしく^^;

>>66のネタは http://pc4.2ch.net/test/read.cgi/jisaku/1081898975/
の>860あたりで既出なんだけど、まぁ25年も前の腐れたアーキテクチャを
後生大事につかってる漏れらが悪いんだわさ。嫌ならとっととItaniumに
逝けってことﾃﾞｽﾖ。

それ以前にSparcだってAlphaだってMipsだってあったわけだし。
AMDならAm29kだ。肉まんﾏﾝｾｰ
75 名前：Socket774 ：04/04/23 11:03 ID:2OqBsav5: 未だにコンパイラは386でも動作するコードしか吐けないわけだ・・・通常は。
MMX・CMOV・SSE・SSE2、それぞれジワジワと効いてくる命令だけに、なーんも使ってくれんのはキツイ。

そこで出てきたのが、CLIを環境に合わせて最適にJITコンパイルする、と。
ｘ86 → 最適なx86に再コンパイルしてくれるのが一番良いんだが・・・無理な話か。
76 名前：Socket774 ：04/04/23 11:06 ID:v2w9JcUV: >>75
いや、だからこその.net frameworkとLongHornなんじゃないか？
77 名前：Socket774 ：04/04/23 11:12 ID:bLINDbMj: >>７５
通常じゃない場合は拡張命令を自動生成使用してくれるの？

前処理で、人間が手動で拡張命令が実行できる形にしないと
いけないイメージがあったんだけど、コンパイラが拡張命令が
使用できる形に無理やりデータの順番とかいい感じの塊だとか
に直してくれたりする？

趣味だとその辺りの資料が殆どなくて、人間が手動で前処理する場合の
解説は、日本語のネット上だと午後とかまるもが解説してた程度なんで資
料キボンヌ。
78 名前：66 ：04/04/23 11:14 ID:1uIF7LsS: もっともっと煽りЩ(ﾟДﾟШ)ｶﾑｫｰﾝと言うことで煽り返したいところだが
俺の知識レベルでは正直苦しい。。。。
もちっと必死にググってネタ仕入れて煽り返してやるからな覚悟してよろ藻前ら

>>69
>16個は多杉使いきれないぞw　お前プログラム組んだことないだろ(ﾌﾟ

くらい言ってくれたらなお嬉しいw

>>74
いいぞ、そのイキだ。
それとお前はもっと言葉遣いに気を使え。
とにかくデス、マス調の丁寧言葉はヤメとけ。
レス読んでるやつを挑発して馬鹿にするくらいの書き方をしろ。
79 名前：Socket774 ：04/04/23 11:15 ID:qSs+361h: やーいばか
80 名前：Socket774 ：04/04/23 11:21 ID:2OqBsav5: >>77
GCCにCMOV使用の最適化オプション有り。
VC7でfloatをSSE系で演算する最適化が追加・・・ま、その程度。やる気ナシ。

>>69
おまえさん（人間）がasmでカリカリ書くのなんか想定しとらん。
コンパイラの最適化自由度の為にレジスタ本数は重要。
81 名前：Socket774 ：04/04/23 11:27 ID:v2w9JcUV: >>80
つーかSSEはAthlon系で遅いんでイラネ。
82 名前：Socket774 ：04/04/23 11:29 ID:bLINDbMj: >>80
ああ、やっぱその程度か・・

素人考えにも難しそうだからなぁ。
83 名前：Socket774 ：04/04/23 11:30 ID:5YQCLa+R: >>78
え～、だって淫厨vs明日厨の>873あたりで煽ったら、ついてきてくんなかったじゃん。
漏れ様寂しさのあまり枕をｳｨｽﾊﾟｰ夜用に変えたんだぞ。
84 名前：Socket774 ：04/04/23 11:35 ID:v2w9JcUV: >>83
>ｳｨｽﾊﾟｰ夜用
お前、ｶﾜｲｲ香具師だな。

ところで、ゲーム系はさておき浮動小数点演算ってそんなに使いまつか？
今まで組んできたプログラムでは、一度も使った事が無い・・・
85 名前：Socket774 ：04/04/23 11:48 ID:v2w9JcUV: ごめん。誤：今まで組んできた　正：最近組んだ
86 名前：Socket774 ：04/04/23 12:00 ID:3//jvn7T: >>84
多いか少ないかは案件によるんじゃねーの？
使うべきところで使うようにしてるとしか言い様がねぇ…
87 名前：Socket774 ：04/04/23 13:31 ID:5YQCLa+R: >>84
ｹｺﾝするかい？ﾔｻｼｸしてね（藁

ゲーム用なんてそれこそ固定小数点演算でいいじゃんよ。
とかいうとなんか一部の、自称異様に目がいい香具師等から非難GoGoなんだけどさ。

最近はテーブル参照するより複雑な浮動小数点計算さしてｷｬｽﾄしたほうが速いなんて
ｱﾌｫな事が平気でおきうるから、そゆときにはいいんじゃね？
88 名前：Socket774 ：04/04/23 13:50 ID:v2w9JcUV: 前略)おまいら、Pentium-Mの凄さをもっと実感するべきだと思います(以下略
89 名前：Socket774 ：04/04/23 14:50 ID:2OqBsav5: やっぱり究極的には、>>71が示すように、L1キャッシュのレイテンシをレジスタ並にして、
mem-memで直接演算する（レジスタ無し）アーキテクチャとかあったら楽チンそうだなー
90 名前：Socket774 ：04/04/23 15:19 ID:e3iPEFLp: >>77
MSコンパイラは知らんが...
intelコンパイラは自動ベクトル化でSSE使ってくれる。
実行時環境に合わせて動作変更するコードも自動的にやってくれるから便利～。
91 名前：Socket774 ：04/04/23 17:46 ID:XygWom31: >>89
実効アドレッシング・モードをハードウェアレベルで実装するってことか？
CISCのRISC化の流れと逆行してて正直メリットがあんまりワカラン。
命令サイズも無駄に大きくなりそうだし。
それこそ素直にレジスタ増やした方がいいんちゃうか？
92 名前：Socket774 ：04/04/23 18:01 ID:HjBlHuZf
93 名前：Socket774 ：04/04/23 20:37 ID:9NtWgErj: 過去との互換性を捨てて新しい命令セットアーキテクチャを作るなら、レジスタは
少ないよりは多い方がいい。しかし、128本×２組あるItaniumの性能がx86よりすごく
高いか，というと大したことない。Itanium2スレでは、『確かにItanium2は高性能だが
わざわざアーキテクチャを変更してまで移行する程の差はない』というのが主な
意見だった。
94 名前：Socket774 ：04/04/23 20:48 ID:bBTC51tL: >89
すでにクロック向上の足かせになってたりしてな
95 名前：Socket774 ：04/04/23 22:00 ID:9NtWgErj: >>94
Northwood→PrescottでCMOSテクノロジの進歩以上にクロックを向上させる必要は
あったのか、Intelを小一時間．．．
無理してクロックを引き上げるのはかえって性能を落とすのは当然で、
IBMはPOWER4→POWER5でクロックを同じにして、マイクロアーキテクチャの
改善だけで性能を上げている。
"クロック周波数マーケッティング"に毒されていません？
96 名前：Socket774 ：04/04/23 23:53 ID:/7TQ6769: >>95
そいつはわかりきっているが、いざやると全く売れなくなるから。
クロック周波数だけで性能を予測する素人厨がユーザーの過半数
である限りクロック至上主義マーケティングはゆずれまい。
97 名前：Socket774 ：04/04/24 02:11 ID:+fw1pIR6: 『レジスタがもっと必要か』に関するAMDの資料があった。

これ↓の10ページ。
http://www.hotchips.org/archive/hc14/hc14pres_pdf/26_x86-64_ISA_HC_v7.pdf
アプリ毎に、それの何%の関数がレジスタがいくつあればいいか出てる。
例えば、スプレッドシートだと75%の関数はレジスタは7個以下でOK、20%が8～15個、
4%が16～32個、33個以上レジスタが必要な関数は1%、とか出てる。
全体だと、7個あればどのアプリでも60%はカバー、15個なら一部のアプリを除き
90%以上で、「レジスタは16個」というAMD64(このプレゼンではまだx86-64って
言ってる)の設計理由になってる。
本当は実行回数の重み付けをすべきだと思うけど。(１回しか実行されない関数なら
どうでもいいし、100万回実行される関数なら１個でもがんばって対応した方がいい)

14ページには、SPECint2000でどうなったか、が出ている。
　　①平均命令長　3.4→3.8に増えた。　　REX prefix分が増えた。
　　②実行命令数　10%削減。　　レジスタが増えた効果でロード・ストアが減った。
　　③ロード数　26%削減、ストア数　36%削減。　　すごい減ってる。
これはAMD64のコードとは言っても計算は32bitでやっていると思うので、
レジスタ拡張の効果がでているのだと思う。

AMD64/EM64T(←両方書かないとアム厨って言われちゃう)は「メモリが4GB以上無いと
意味がない」と思ってたけど、レジスタ拡張は意外と性能に効くかもしれない。
AMD64/EM64Tをサポートしたアプリが出てくるのが楽しみだな。
98 名前：Socket774 ：04/04/24 02:12 ID:+fw1pIR6: 上で１個は紹介したけど、ここ↓にあるAMD３部作とItanium2の発表は詳しいのでお勧め。
http://www.hotchips.org/archive/archive_hc14_toc.html
99 名前：Socket774 ：04/04/24 02:15 ID:+fw1pIR6: >>96
今度Intelがモデルナンバーの大キャンペーンをやるから
マイクロアーキテクチャの進歩の方向性は正常化する？
100 名前：Socket774 ：04/04/24 05:25 ID:gjeS+Gl8: （ ´,_ゝ｀）
101 名前：89 ：04/04/24 08:29 ID:5gXRSOQz: >>91
レジスタ構成・本数に縛られるより、メモリアドレッシングのみに縛られるアーキテクチャの方が、
何かと都合がいいんじゃないかと思ったんだよね。

ビジネス・サーバ・ゲーム他、大半のソフトウェアがC++もしくはC#・Javaで書かれ肥大化しており、
移植性・保守性を求めて抽象化させられている現状・・・（バイナリすらバイトコード＝抽象化）
Itaniumの128*2・64bitなんていつ窮屈になるかわからんし、いずれまた現状のCPUみたいに、
論理レジスタ構成を内部で独自の物理レジスタ構成に変換するハメに・・・

それだったらいっその事、メモリ同士の四則論理演算だけを表向き定義して、
CPU内部で自由にゴチャゴチャやってもらえりゃ良いんでないの？と。
キャッシュ容量その他ダウンサイズして携帯CPU・・・は無謀かｗ Itaniumじゃそうはいかんだろうしなぁ

「分岐命令を如何に使わずロジックを実装するか」という問題を少しでも軽くする為にも・・・
（関数の強引なinline化、ifの置換をソース・コンパイラ双方が積極的に行っていく必要がある）
102 名前：Socket774 ：04/04/24 12:15 ID:kP/xzF63: ねえ、例えばパイプラインの段数だけ仮想CPU作って、
個々のスレッドを処理するってのはどうだろうか。
そうすれば、依存関係はなくなるし、
レジスタなんかを仮想CPU分用意すれば・・・
103 名前：Socket774 ：04/04/24 12:44 ID:ayMH8bwE: >>102
もしかしてCPU内部命令レベルでも
命令語レベルと同じ本数だけしかレジスタが無いと思ってるとか？

第一依存関係はパイプラインよりもむしろスーパースカラーの方の問題だろ。
104 名前：Socket774 ：04/04/24 14:25 ID:kP/xzF63: >>103
違う違う。

現状、x86系プロセッサのパイプライン・スーパスカラは、
分岐処理等によってパイプラインハザードが起こるでしょ？
でも、パイプライン上の全ステップで、常に異なるスレッドを処理すれば、
つまりパイプラインで連続して実行する処理を常に異なるスレッドからフェッチすれば、
ハザードはほとんど発生しない、のではないかと考えた。

で、さらにそれを実現する為に、同時実行可能なスレッド数(=パイプライン段数)
分のレジスタを用意して、各スレッドの扱うレジスタをマップしてやれば、
メモリのロード・ストアや、タスクの切り替えオーバーヘッドも
節約できるのではないか・・・と思ったんだが。
105 名前：Socket774 ：04/04/24 14:26 ID:kP/xzF63: つまり、レジスタ数=従来のレジスタ数×パイプライン段数、ね。
106 名前：Socket774 ：04/04/24 14:29 ID:cTiLWagl: スレッドの並列性が上がっても単一スレッドのIPCは下がる一方
107 名前：Socket774 ：04/04/24 14:47 ID:HJX6AnM+: >>104
それはHTTを拡張したような話をしてるのか
マルチコアの話をしてるのか、投機スレッドの話をしてるのか
それとも全然違う話をしてるのかいまいちよく分からん。
108 名前：Socket774 ：04/04/24 15:18 ID:a3p/Ekc+: >>104
パイプライン段数分くらいのMulti Threadingをやるというアイデアの問題点は以下。

(1) サーバ以外のクライアントPCやワークステーションでは、そんなにたくさんの
　　実行すべきスレッドが存在していない。絶対10個もないでしょう。
(2) レジスタを大量に持つのが大変。8本×20セットとして160本。
　　このくらいだと、面積も大きいし、クロック周波数のネックになり易い。
(3) 共用資源(キャッシュやTLB)の容量が不足する。

つまり、インプリメントするにはたくさんのトランジスタが必要な割りに
それを活かせるだけの仕事が無いので遊んでしまうので、非常にチップ面積の
無駄使いになるような気がする。
109 名前：Socket774 ：04/04/24 20:04 ID:pCRzu7G1: そもそも依存関係のないパイプラインってなんだよ
それはパイプラインにならんだろう
各ステージが依存関係があるからこそ細分化が可能なのに
110 名前：Socket774 ：04/04/24 20:41 ID:kP/xzF63: 皆レスthanx

>>107
HTTを拡張したような話です。

>>108
1&>>106. 仮想CPUの数を動的に変化させれば改善されません？
2. キャッシュを考えたら微々たるものでは？
3. キャッシュを減らしてしまえ！

>>109
？
111 名前：Socket774 ：04/04/24 20:43 ID:kP/xzF63: つまりPentium 4のように分岐予想の為に豪華な資源を用意せず、
分岐自体を減らしてしまってはどうか？というアプローチだったり。
112 名前：Socket774 ：04/04/24 20:53 ID:HP/ztHfS: 整数絶対値命令くらいいい加減に載せてくれ
113 名前：Socket774 ：04/04/24 22:05 ID:ehIoXtU5: >>110
取り敢えずシミュレーション結果出せ。
つぎに回路規模を見積もれ。
114 名前：108 ：04/04/24 22:20 ID:a3p/Ekc+: >>110
(1) 仮想CPUの数を減らしたら結局パイプラインが遊んでしまうのでアイデアの前提が成り立たない。
(2) レジスタは多ポート・高速である必要があり、読み書きポート数が少なく数サイクルかけて
　　アクセスして良いキャッシュとは世界が違う。
(3) 20個のスレッドを同時に動かせばいくら共通部があるといっても、1スレッド当たりの容量は
　　1/10くらいかな。1.6KBのキャッシュって意味ありますか？
115 名前：Socket774 ：04/04/24 22:34 ID:pCRzu7G1: やはりパイプラインを理解してないんだな
投機スレッドの話をしてるに過ぎない
ハイパーマルチスレッディングって感じだが
116 名前：Socket774 ：04/04/24 23:20 ID:ayMH8bwE: なんにせよ、ネタを振ってくれた>>102には感謝する。
117 名前：Socket774 ：04/04/25 00:44 ID:CJ8tfptr: >>102
ちなみにネットワークプロセッサで似たような奴ある。
118 名前：Socket774 ：04/04/25 01:32 ID:FV14x75f: >>108
1)10個くらいは普通に動くけどね。In-active ではあるかな。
2)現状のPenitum4でも128個、時期NetBurstだと256本位は普通に乗せるし、
UltraでないSparcでも160本もってました。
3)これを解決するのがNetBurst的アプローチなんですけどね。

で、無理にThread意識する以前にReOrderingってのがあってですね、HTTや
>>102のような発想をしないですむようにできる「はず」なんですよ。

しかし、想像を絶するほど深いPipeLineをつくっちゃったおかげで、局所的な
オプティマイズによる命令の入れ替えの限度を超えてしまい、パイプがスカスカ
になっちゃった。そのつじつまあわせたるHTTや投機スレッドなんぞに力入れる
くらいなら、もっと他に力入れる所は、ありますよね：）
119 名前：Socket774 ：04/04/25 13:32 ID:8Q7/TKk6: RC5-72 の専用回路とSETI@homeの専用回路を付けて
あとは普通のPenで十分でないだろか。
120 名前：102 ：04/04/25 13:37 ID:7pLayrtN: つまりね、パイプラインに投入する各命令を、
異なるスレッドから順番に取り出すわけよ。
例えば、スレッド1の命令を1つ投入したら、
次にスレッド2の命令を1つ投入、次はスレッド3といった具合にね。
そして、最後までいったら始めのスレッドに戻る。
だから、有効スレッド数に応じて、擬似マルチタスク度も変化するわけ。

キャッシュは遅いとの指摘だが、
だからこそ、レジスタを増やして速度を上げるんじゃないか。

またこの構造のCPUでは、パイプラインが20段もあるCPUを想定していない。
そもそも、分岐予想やリオーダリングを無くして、
パイプライン段数を減らそうという考えなので、想定段数は多くても10数段。

そして、このアイディアの最大の特徴は、
OSが行っていたタスクの切り替えを少なくする事にある。
つまり、レジスタからキャッシュ・メモリへの待避が、
格段に少なくなる、とう点にある。
121 名前：Socket774 ：04/04/25 13:58 ID:2KyV91o5: にしても、何もレジスタを各ステージ毎に持つ必要は無いと思うが。
従来通り内部レジスタ増やしてレジスタリネーミングでいった方が
リソースの効率高いんと違うか？

それとスレの盛り上がりのためにも引き続き頑張ってくれ>>102
あえて重箱の隅をつつくような反論しつつw応援してるぞ。
122 名前：102 ：04/04/25 14:04 ID:7pLayrtN: >>121
それは、インプリメント時の問題と考えますがどうでしょう？

PS.これからもスレを盛り上げるようがんがってゆきます
123 名前：Socket774 ：04/04/25 14:04 ID:CJ8tfptr: だからシミュレーションしてみろと…

最大何スレッド動かすと良いかなんて性能と回路規模のトレードオフなんだからさ。
使える半導体ルールにもよるんだよ。
124 名前：102 ：04/04/25 14:12 ID:7pLayrtN: >>123
流石にそこまで技術・時間ともにありません。
もし可能ならば、代わりにやってみてください。
125 名前：Socket774 ：04/04/25 14:16 ID:bhbGfDJC: >>120
誰が”そのスレッドが依存関係がない”と判断してｷｬｯｼｭにもってきてくれるのかね？
”ｷｬｯｼｭ内から”ならばBTBにﾃｰﾌﾞﾙ作るのは誰なんだ？
126 名前：Socket774 ：04/04/25 14:33 ID:bhbGfDJC: あと前提がおかしい

>分岐処理等によってパイプラインハザードが起こるでしょ？
>でも、パイプライン上の全ステップで、常に異なるスレッドを処理すれば、
>つまりパイプラインで連続して実行する処理を常に異なるスレッドからフェッチすれば、
>ハザードはほとんど発生しない、のではないかと考えた。

現状のHTTで2ｽﾚｯﾄﾞが動いている時
片一方のｽﾚｯﾄﾞでﾐｽﾋｯﾄが起これば全てのｽﾃｰｼﾞは廃棄される
どのｽﾃｰｼﾞがどのｽﾚｯﾄﾞかﾁｪｯｸする機構がないからだが
そんな機構を導入するより読み直したほうが速いからだ

もし10ｽﾃｰｼﾞあって10ｽﾚｯﾄﾞ動かしても同じこと
ﾐｽﾋｯﾄ以外の9ｽﾚｯﾄﾞは実行されることになるが
その後のｽﾚｯﾄﾞ=ﾐｽﾋｯﾄしたｽﾚｯﾄﾞはﾊｻﾞｰﾄﾞになる
9ｽﾃｰｼﾞ分しか有利にならない

現状のHTだってｷｬｯｼｭ内ﾐｽﾋｯﾄ程度のﾊｻﾞｰﾄﾞはたいしたことないんだよ
ﾒﾓﾘまで読みに逝かなきゃならんときが巨大なﾊｻﾞｰﾄﾞなんだ
9ｽﾃｰｼﾞ有利にするためにｽﾚｯﾄﾞが無依存であることをﾁｪｯｸする機構をいれるのか？
投機ｽﾚｯﾄﾞでいいんでないか？
127 名前：Socket774 ：04/04/25 14:33 ID:8Q7/TKk6: スレッド数可変なら、OSからはどう見えるの、
固定スレッドじゃないと XP 様は対応できないような。
128 名前：Socket774 ：04/04/25 14:35 ID:bhbGfDJC: >>127
いやまぁOS,ｱﾌﾟﾘは作り直しでしょう
そこは目をつぶらないと・・・
129 名前：102 ：04/04/25 15:29 ID:7pLayrtN: OS・アプリにはあまり変更を加える必要はないと思う。
OSは次に実行すべきスレッドの一覧と、次にカーネルが呼ばれるタイミングをCPUに提供し、
CPUはそれに従って一定量の処理を行えばいいんだし。

それから、どのステージがどのスレッドであるかは、意識する必要すらない。
なぜならレジスタリネームのような機構を用いれば、
CPUからは1つの断続的なプログラムとして扱えるから。

つまり、OS側から見れば複数のスレッドを実行しているが、
CPU側から考えれば、単一のスレッドを処理しているのとなんら変わらない。

もし相互のスレッドに依存関係がある場合、
それは既存のプログラムと同じ依存関係を示すから、
単にハザード処理をするだけでよい。

しかもこのアーキテクチャのよい点は、各スレッドの動作が遅いという点、
スレッドの動作自体が遅い為に、L1キャッシュのレイテンシが解消される。
つまり、あるスレッドがメモリから値をロードしたとしても、
そのスレッドが次に処理されるのは、最大でパイプライン段数分だけ後になる為、
その間にキャッシュからデータを読み込める。
130 名前：102 ：04/04/25 15:30 ID:7pLayrtN: >OS・アプリにはあまり変更を加える必要はないと思う。
は誤植。たしかにOSのスレッド管理には変更を加える必要がある。
131 名前：102 ：04/04/25 15:32 ID:7pLayrtN: このアーキテクチャは>>38氏が書いているSPARCのそれみたいなもの。
132 名前：Socket774 ：04/04/25 17:25 ID:CJ8tfptr: >>131
同じつもりならHTも同じ。
違うつもりなら何が違うかまとめたほうがよい。
133 名前：Socket774 ：04/04/25 19:13 ID:bhbGfDJC: >>129
相当OSをいじらないと
>OSは次に実行すべきスレッドの一覧と、次にカーネルが呼ばれるタイミングをCPUに提供し、
>CPUはそれに従って一定量の処理を行えばいいんだし
はできないよ。ｽﾚｯﾄﾞ=.exeじゃない
またそのOS自体もそのCPUで動かすわけだし、たいへんだわ

またやはり>>108の問題点が解決されない
>>126に書いたようにHTの問題はｽﾃｰｼﾞ分のｸﾛｯｸが無駄になるﾊｻﾞｰﾄﾞではない
HTでもｲﾝｵｰﾀﾞｰでﾌｪｯﾁされるときはｷｬｯｼｭﾚｲﾃﾝｼは隠蔽される
問題なのはﾄﾚｰｽｷｬｯｼｭにすら分岐先がないときなんだよ
それを10仮想CPU分用意するのか？
ﾚｼﾞｽﾀの増量はﾃﾞｰﾀﾁｬｯｼｭに有効なだけだよ

もしﾄﾚｰｽｷｬｯｼｭにﾋｯﾄすれば
>そのスレッドが次に処理されるのは、最大でパイプライン段数分だけ後になる為、
>その間にキャッシュからデータを読み込める。
になるがﾄﾚｰｽｷｬｯｼｭになければ現状のﾈｯﾄﾊﾞｰｽﾄと変わらない
しかも分岐予測を減らすって？？
余計ﾊｻﾞｰﾄﾞが増えるよ

現状のHTの問題は単純なﾊﾟｲﾌﾟﾗｲﾝﾊｻﾞｰﾄﾞじゃない
そんなのAMDだって同じだよ
2ｽﾚｯﾄﾞ動作ですらｷｬｯｼｭや演算器の奪い合いで
綺麗にﾊﾟｲﾌﾟﾗｲﾝが流れないんだよ？
134 名前：102 ：04/04/25 19:53 ID:7pLayrtN: >>133
そもそも長いパイプラインは想定してないんだよ。
このアーキテクチャの目的は、現状の長いパイプラインを捨て、
膨大な資源を分岐予想に使うのを止め、
無駄なオーバーヘッドを極力少なくする事。
Athlon 64なんて4ステップもフェッチとデコードに費やしてるぞ。

だから、そもそもトレースキャッシュなんて必要ない。
キャッシュに無かったら主記憶から読み取れば良い。
その間に他の処理を出来るんだから。
もちろん、クロックを落として、そのかわりに
複雑な演算をすべて1クロックで完了するようにしる。

何度も書いてるが、このアーキテクチャではハザードを阻止しない。
ハザードの発生を容認し、発生しても空き時間を有効利用する。
135 名前：Socket774 ：04/04/25 20:20 ID:CJ8tfptr: パイプライン作らないとスループットが出ません。
簡単に言うといつもハザードが出ているパイプラインと同じ速度になります。

キャッシュミスしたときに他の処理をすると言いますが、他の処理はどこから
読めるのか考えてみた？

複雑な命令が1クロックで終わるようにするということは、すべての命令が一番
複雑な命令の速度にあうまで待ちが入ると言う意味です。その待ちは回路設計の
余裕にはなりますが、別のスレッドへの割り当ても出来ません。

ハザードが発生した飽き時間を使うということはハザードの阻止をしているんだよ。
ハザード無視と言うのはR3000みたいなものを言う。
136 名前：Socket774 ：04/04/25 20:29 ID:bhbGfDJC: >>134
10といったから10ｽﾃｰｼﾞとして書いてるんだが？

ﾄﾚｰｽｷｬｯｼｭがいらない？
つまりﾃﾞｰﾀとｺｰﾄﾞを区別なくｷｬｯｼｭするってことね
いずれにしろｷｬｯｼｭ格納時に10ｽﾚｯﾄﾞなら10個の領域にわけなければならない
共有できないからな
共有してるとﾊｻﾞｰﾄﾞのたびにｷｬｯｼｭﾁｪｯｸが必要になる
それならやはり膨大なｷｬｯｼｭが必要
10CPU分のﾈ

基本的にはﾒﾓﾘから直に読まない
ｷｬｯｼｭになければ、ﾒﾓﾘ>ｷｬｯｼｭ転送してからｷｬｯｼｭを読む
そうでなければﾚｲﾃﾝｼがでかいからな
またﾒﾓﾘ>ｷｬｯｼｭ間も別ｱﾄﾞﾚｽから読み込むか
ﾒﾓﾘ上ですでに依存関係のないようかつ連続読み込みできる配置になってなければならない
10ｽﾚｯﾄﾞ周期に配置させるわけだ
そうしなければｷｬｯｼｭへの転送するたびに莫大なﾚｲﾃﾝｼが発生する
CPU内のｵｰﾊﾞｰﾍｯﾄﾞなんかより
CPU<>ﾒﾓﾘ間のｵｰﾊﾞｰﾍｯﾄﾞを選択するってことか？
ﾌﾟﾛｸﾞﾗﾑ組むのもたいへんだが、ﾒﾓﾘｺﾝﾄﾛｰﾗも相当賢くないといけない
1ｽﾚｯﾄﾞ毎ﾗﾝﾀﾞﾑｱｸｾｽし続ける気か？

ﾊﾟｲﾌﾟﾗｲﾝを短くして5ｽﾃｰｼﾞとしよう
1ｽﾚｯﾄﾞがﾐｽﾋｯﾄする
1ｽﾚｯﾄﾞ分のｷｬｯｼｭがﾘｽﾄｱされる
残り4ｽﾚｯﾄﾞは1ｽﾚｯﾄﾞ分処理があがる
そのかわりﾐｽﾋｯﾄした1ｽﾚｯﾄﾞは莫大なﾊｻﾞｰﾄﾞが発生する
無論ｷｬｯｼｭが5倍あればﾊｻﾞｰﾄﾞはたいしたことない
でもｷｬｯｼｭが5倍って・・・・
137 名前：Socket774 ：04/04/25 20:31 ID:bhbGfDJC: あぁわかった
486DXをｵﾝﾀﾞｲ10ﾏﾙﾁｺｱにしろってことか？
138 名前：Socket774 ：04/04/25 21:26 ID:CJ8tfptr: >>136
Trace CacheはただのI-Cacheでは無いよ。
だからTrace Cache無し=Unified Cacheではない。
139 名前：Socket774 ：04/04/25 22:33 ID:bhbGfDJC: >>138
それはわかるが、おまいさんのｼｽﾃﾑでは
ﾃﾞｰﾀｷｬｯｼｭもｺｰﾄﾞｷｬｯｼｭもわけないんでしょ？
というかわけたらえらいことになるが
140 名前：Socket774 ：04/04/25 22:40 ID:bhbGfDJC: 要は
ﾚｼﾞｽﾀでｷｬｯｼｭのかわりを務められるのはﾃﾞｰﾀｷｬｯｼｭだ
といっているのよ
ｺｰﾄﾞ用のｷｬｯｼｭはどうするのかって訊いてる
ｷｬｯｼｭを増やさない、というなら10もの仮想CPU分のｺｰﾄﾞを
頻繁にﾒﾓﾘ＞ｷｬｯｼｭしなければならない以上
ﾚｲﾃﾝｼが増大する
しかも依存関係皆無ならﾌﾟﾛｸﾞﾗﾑがそれ用か
ﾒﾓﾘｺﾝﾄﾛｰﾗが相当ｸﾚﾊﾞｰじゃなきゃ
ｲﾝｵｰﾀﾞｰでｷｬｯｼｭできない
それはどうするの？ってこと
141 名前：Socket774 ：04/04/25 22:55 ID:CJ8tfptr: >>139
138は102ではない。102のアーキはキャッシュは別けても問題ないと思うがよく
わからん。

102は>>131と言ったり>>134と言ったりわけわからん。
HTは性能が実際に出ているわけだけど、性能のでないのを作ってどうするんだ？

汎用性を減らして回路規模を小さくしつつ性能出すと言う考えなら、ターゲット
アプリをはっきりさせないと話にならないよ。
142 名前：Socket774 ：04/04/25 23:33 ID:bhbGfDJC: >>141
ごめんごめん
IDよく見てなかったわ
まぁ102がHTT拡張と定義してるんでﾄﾚｰｽｷｬｯｼｭにこだわったんだけどね
ﾃﾞｰﾀとｺｰﾄﾞを分けてなおかつ10CPU分というのはすごいことになるような気がするんだが
あくまでも汎用性を目指したHTTの拡張ってことなら、ね
汎用性を減らそうとは思ってないんでは？
143 名前：Socket774 ：04/04/25 23:36 ID:FV14x75f: とりあえず>>136は頭に血が上りすぎて、I-Cacheが一枚岩と勘違い:-)
ふつ～はBlock(Page)サイズごとに独立したコードを収められる。
144 名前：Socket774 ：04/04/25 23:51 ID:bhbGfDJC: >>143
いや現状でどうこうということではなくて
10ｽﾃｰｼﾞが依存関係なしということは
ｲﾝｵｰﾀﾞｰで処理するには厳密に10ｽﾃｰｼﾞ毎
ｷｬｯｼｭ内にｽﾄｱされるか、10個に分割するしかないんじゃない？
ｷｬｯｼｭに対するﾚｲﾃﾝｼが毎ｸﾛｯｸ起きるでしょ
ところがﾐｽﾋｯﾄしたときでも他ｽﾚｯﾄﾞが止まらないってことは
10分割しかない
ところがｷｬｯｼｭの全量を現状から増加させる必要はないっていうんで
逆にそれじゃﾒﾓﾘに対するﾚｲﾃﾝｼが増えるだけで
ﾒﾘｯﾄないんじゃない？って訊いてるんだが
あくまでも
>だから、そもそもトレースキャッシュなんて必要ない。
>キャッシュに無かったら主記憶から読み取れば良い。
に対する疑問なんだが
145 名前：Socket774 ：04/04/26 00:00 ID:YZh0YRTf: 1)ステージ分のAddressGeneratorを内蔵して、1ClockごとにFetchパイプにつめる
2)デコーダ部分で10CPU分をエミュレート、コア部分は完全シーケンシャル動作に
　してトレースキャッシュ部分はリングバッファ的に回す。

3分で思いついた手は上の二つ。他にも手はありそうだね。
146 名前：Socket774 ：04/04/26 00:06 ID:86GpYuw3: HTと何が違うのかと…
147 名前：Socket774 ：04/04/26 01:17 ID:X8yq1+fp: >>143
136みたいに熱い書き方してくれる人がいないと
以前のような過疎スレに戻ってしまうからな

一部の人が巧い具合にレスが付く書き方してくれてるので
なかなか良い具合にスレが進行してるなと思ってたりする
148 名前：Socket774 ：04/04/26 10:23 ID:YZh0YRTf: レスついてもなぁ、内容がなぁ。

>>102のアイデアを要約するとだね、個々のスレッドにとってはパイプの無いCPUを
構成すれば、ハザードなんて発生しえないしそのための分岐予測は不要だ、っていう
ことなんだよね。つまり>>137が正解に近い。が、1GHzでまわせる10段パイプのCPU
でそれを行うと、一つのスレッドにとっては100MHzのCPUでしかない点を忘れてる。
そして、残念ながら性能は100MHzのCPUｘ10個分にはならない※。

で、>>108の一連の指摘はさ、そういうところを指摘したいんだろうとは思うけど、
つっこみどころが間違っててさぁ、反論できちゃうんだよね ^^;
物理的な数の限界は、数で解決されちゃうからね。レジスタの数でいえば、Prescott
なんか64ビットの汎用レジスタを256本もってますぜ？（半分死んでるけど）。

※以前の研究とか見ると、密結合のマルチプロセッサはバス競合などの理由から、
有効なCPU数は4つないし多くても8つくらいまで、といわれてきた（性能がサチる）けど、
400MHzのメモリバスをもった100MHzのCPUが10個だと、案外性能でたりするかもね(笑
149 名前：Socket774 ：04/04/26 10:34 ID:dagIouhn: 知らない間に良スレに成長してるな。
150 名前：102 ：04/04/26 10:42 ID:+KEvbB8j: >>148

たしかに、実行すべきスレッドが10かそれ以上あれば、
100MHzのCPUが10個という状況になるが、>>145氏のいわれた通り、
コア部分はシーケンシャルな動作になるので、
バス競合等の問題は起こりえないと考えます。

そして、実行すべきスレッドが10以下ならば、
順番に繰り返し実行されるので、200MHzのCPUが5個、
300MHzのCPUが3個、500MHzのCPUが1個、といった状況が考えられる。

つまるところ、今までに私が提示したアーキテクチャは、
OSの内部からスレッドの情報を取り込み、
異なる複数スレッド間では、処理依存度が極端に低い事を利用して
出来る限りパイプラインの各ステップで実行する処理に依存関係のない状態を作り出し、
さらにOSのタスク切り替えの一部分もCPU側でやってしまおう、
という考えの元に考えられた実行系サンプルです。

つまりはOSとCPUの密統合といえるかもしれません。

私はそんな知識も技術もありませんので、
多少理論が無茶苦茶な部分もあったりしますが、
その辺はフォローよろしくお願いしますぽ。
151 名前：Socket774 ：04/04/26 12:09 ID:B6tZVOSS: > そして、実行すべきスレッドが10以下ならば、
> 順番に繰り返し実行されるので、200MHzのCPUが5個、
> 300MHzのCPUが3個、500MHzのCPUが1個、といった状況が考えられる。

この状況を許す時点で、最初の前提が崩れるから、NG.
1GHz/10段のパイプに入ってから出るまで、次の命令を投入できないのが、
あなたのアイデアであり、投入しないからこそパイプの破綻が起こりえない。
暇なときは暇にしておかないと、元の木阿弥。

> つまりはOSとCPUの密統合といえるかもしれません。
OSはCPUにプログラムを投入するだけなんで、結合もなにもないです。
もっと正確にいうと、タスクやスレッドの切り替え毎に、各CPUの
プログラムカウンタ他、状態レジスタを設定しなおしてるだけ。
OS自身も、そこに含まれます。
152 名前：Socket774 ：04/04/26 12:13 ID:B6tZVOSS: あ、それからIDころころ変わって申し訳ないけど、
俺>>74=>>143=>>148=>>151なんでよろしく。
153 名前：Socket774 ：04/04/26 12:14 ID:B6tZVOSS: うう、>>145もな。
154 名前：Socket774 ：04/04/26 17:19 ID:B6tZVOSS: ここらでもう一度おさらいしてみよう。
155 名前：・良く分かるパイプライン ：04/04/26 17:20 ID:B6tZVOSS: 「おしっこをして手をあらってでてくる」。
トイレが一室しかないと混雑時は長蛇の列ができます。

1.おしっこをする
2.手を洗う。

二段のパイプにすると、手を洗ってる間に別の人が用を足せるようになります。
トイレ一室で二人が気持ちよくなれて、効率が倍になります。

もうすこし深くしてみましょう。

1.ジッパーを下げる
2.ちんちんとりだす
3.放尿する
4.しずくを切ってちんちんしまう。
5.ジッパーをあげる
6.手を洗う
7.紙を使って手をふく

7ステージに分解すると、なんと 7人が同時に処理できます。
これがパイプラインです。
156 名前：・良く分かるスーパスケーラ ：04/04/26 17:21 ID:B6tZVOSS: トイレの利用はおしっこだけではありません。
うんこもします。どういう手順でしょうか。

1.ジッパーを下げる
2.ズボンとパンツを下ろす
3.便器に座ってふんばる（出す）
4.汚れた尻を拭く
5.ズボンとパンツをあげる
6.ジッパーを上げる
7.手を洗う
8.紙を使って手を拭く

前半と後半は同じ処理ですが、途中がおしっことは別処理です。
ということは、小便器と大便器をわけると、途中は並列に処理ができそうです。

うんちとおしっこは処理時間が異なるので、手を洗ったりする所でどっちかが
待たされる事もありえますが、理想的には効率は倍になります。

これがスーパスケーラです。
157 名前：・良く分かるスーパパイプライン ：04/04/26 17:22 ID:B6tZVOSS: うんこする時間と、ズボンとパンツを脱ぐ時間は同じでしょうか。
いいえ、うんこする時間のほうが圧倒的に長いです。

ということは、前の人がうんこしてる間パンツを下ろす人は尻をだしたまま
ぼ～とまっていなくてはいけません。かかる時間を考慮してみましょう。
括弧内は、実際に処理に必要な時間です。

1.ジッパーを下げる(5秒)
2.ズボンとパンツを下ろす(20秒)
3.便器に座ってふんばる(60秒)
4.汚れた尻を拭く(30秒)
5.ズボンとパンツをあげる(20秒)
6.ジッパーを上げる(5秒)
7.手を洗う(60秒)
8.紙を使って手を拭く(30秒)

パイプラインは、一ステージ毎タイミングを合わせて処理をします。
一番時間がかかる処理は、例では60秒ですから、トイレにはいってから出てくる
まで60秒x8回、480秒の時間がかかります。
158 名前：・スーパーパイプライン（続き） ：04/04/26 17:23 ID:B6tZVOSS: ちょっと発想を広げ、時間のかかる処理を分解してみましょう。

1.ジッパーを下げる(5秒)
2.ズボンとパンツを下ろす(20秒)
3.便器に座る(10秒)
4.一回目ふんばる(30秒)
5.二回目ふんばる(30秒)
6.汚れた尻を拭く(30秒)
7.ズボンとパンツをあげる(20秒)
8.ジッパーを上げる(5秒)
9.手に石鹸をつけて泡立てる(30秒)
10.泡を洗い流す(30秒)
11.紙を使って手を拭く(30秒)

ステージ数は増えてしまいましたが、1ステージにかかる時間は30秒と半分に
なりました。クロックでいうと倍のクロックに出来ることになります。

トータルでかかる時間はどうでしょう。30秒x11で 330秒ですね。
前より早く処理が完了しました。しかしクロックが倍になったけどトイレに
かかる時間は半分にはなりません。

これが、スーパパイプラインです。
159 名前：・緊急事態発生 ：04/04/26 17:24 ID:B6tZVOSS: あなたは今、これから迎えるであろう至福の時を迎える為にパンツをおろし、
あとは出すだけという所です。しかし！あろうことか神の声が轟きます。

「なにをしている、ここは女子便所だぞ」

条件判断ミスです。あなたの後ろには、つられて入って来てしまった数人の男性が、
ジッパーをさげズボンを降ろし、尻をだしたまま待っています。
しかし、ここで用を足すわけにいきません。あなたは数名の男性と共に廊下に
ほうりだされます。

あなたはもう一度、正しいトイレにいってジッパーを降ろす所から始めなくては
いけません。

一方女子トイレはというと、あなた達がほうりだされた事により三つの席が
空いてしまいました。ステージは規則正しく順番に進みますから、この席は
もう埋まりません。三つ分の埋まっていない席の為、女子トイレは利用される
ことなく無駄な時間が経過するでしょう。

その分、女子トイレの利用率は下がります。
これがハザードです。
160 名前：・その他の危険 ：04/04/26 17:25 ID:B6tZVOSS: トイレの危険はまだまだいっぱいあります。
トイレットペーパーが無くなったらどうでしょうか。尻を拭くことが出来ず、
それ以降のステージは凍結してしまいます。

手拭きのペーパータオルが無くなる危険もあるし、汲み取り式のトイレだと
肥溜めがいっぱいになってしまう事もあるでしょう。

その度にあなたは、本来やりたかった放尿を一時中断し、紙をとってきたり
汲み取ったりしないといけません。

本来は放尿や脱糞だけできればどんなに気持ちの良いことか。
そこで、トイレ掃除の人を雇って紙の補充をしてもらったり、汲み取り業者
を雇って定期的に組み上げてもらいます。お金がかかりますが知っちゃこっちゃ
ありません。それで本来の目的が気持ちよく遂行できるなら安いものです。

そう思うでしょう？
161 名前：・依存関係 ：04/04/26 17:26 ID:B6tZVOSS: トイレが汚いとあまり気持ち言いものじゃありません。
知った人が前にすましてたら、そのトイレがきれいかどうか聞いてみるといい
ですね。でも、その人がトイレから出てくるまで聞けませんから、待ってる事に
なります。

折角11ステージにも増えて、同時に11人処理できるトイレも、入って来て
くれなければ利用率は下がります。

あなたと連れが二人います。
一人がトイレに行きました。あなたともう一人の連れは入りたいけど綺麗か
気になります。

この時、全体にあかる時間は

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
3.もう一人の連れは、あなたに続いて入れるので出てくるはあなたから30秒遅れ。

聞かずに入れば330+30+30で390秒で済む所が、トータルで690秒もかかって
しまいました。

これが依存関係です。
162 名前：・リオーダ ：04/04/26 17:27 ID:B6tZVOSS: そこで、トイレがきれいか同か聞かなくてもいい人を先に通してみると
どうでしょう。どうせあなたは10ステージ分経過するまでトイレには
入れないんです。

丁度バスツアーの観光バスがサービスエリアに到着しました。あなたと、もう
一人の連れとの間に並んでます。おばはんは男トイレでも気にしません。

処理時間はどれだけでしょうか。

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
3.あなたの後ろに並んでしまったおばはんが10人。入りきるで300秒。
4.もう一人の連れはその30秒後にトイレに入れるので、入れるのは
あなたが入ってから330秒遅れ、さらに330秒の処理時間。

あなたのグループはトータル 990秒かかります。
おばはんは、あなたが入った後にしか入れませんから、330+30で360秒後に
トイレにはいって、全員がでてくるのは330秒後ですから、690秒後です。

先におばはんをいれてみたらどうなるでしょう？

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.一人目が入って30秒後におばはんが入り始めて10人入るのに300秒。
3.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
4.もう一人の連れは、あなたにつづいて入れるので出てくるのはあなたから30秒遅れ。

あなたのグループは、トータル690秒で済みます。
おばはんは30秒後にははいってますから、なんと360秒後には全員でてきています。

処理を入れ換えてあげると、トイレの利用率はあがり全体の処理時間が短縮
されることがあります。これがリオーダです。
163 名前：・いろんな工夫 ：04/04/26 17:28 ID:B6tZVOSS: 大勢が素早く滞り無く気持ちよくなる工夫はいろいろあります。

トイレを二部屋用意するとか(Dualトイレ)、使用中のトイレに行列ができない
ように振り分けて上げるとか(Threadコントロール)、トイレに待合室とかつくっ
ておくと(Cache)、すれ違え無い程廊下が狭くてもまとめて入室させたり退室さ
せれば(WriteBack)混乱は減りますね。

とここまで書いておいて、トイレを流すのを忘れていたことに気がつきました。
くさいです。ちゃんと流しましょう。
164 名前：Socket774 ：04/04/26 17:35 ID:dagIouhn: ﾜﾛﾀ
他にまともなたとえはないのか・・・
165 名前：Socket774 ：04/04/26 17:39 ID:awEMNttN: しかもさらっと流し読みした感じ、言ってること正しいし・・・ｗ
166 名前：Socket774 ：04/04/26 17:39 ID:odrGp1l3: スカラ

防御魔法のひとつ
仲間１人の守備力を５０％上げることができる
使用するとMP（マジックポイント）２ポイント消費される
167 名前：Socket774 ：04/04/26 17:41 ID:MDVdwW/y: 俺もクチを突っ込もうとして、ざっと読んだ感じでは一箇所も破綻が無いのに感心した。

もう少し人に気軽に見せられる例えか、萌えられる例えだったら友人に見せたいくらいだw
168 名前：Socket774 ：04/04/26 21:02 ID:86GpYuw3: >>150
それをえらい良い効率でやっているのがHTその他なんだな。
すでにアウトオブオーダ出来てるんで大した物量かけずにね。

固定でコンテキストを切り替えるのは前にも書いたけどネットワーク
プロセッサで使ってるのがある。スループット重視でレイテンシはあ
きらめるわけだな。
169 名前：Socket774 ：04/04/26 21:24 ID:IIA5aNqb: HT は入口は別々でも中では一つの便器しかない男女兼用トイレみたいなものか。
170 名前：Socket774 ：04/04/26 23:37 ID:QCdidARo: B6tZVOSSの偉業に拍手・・・ﾊﾟﾁﾊﾟﾁﾊﾟﾁ
こんなもの２ちゃんでしか読めない
171 名前：Socket774 ：04/04/27 05:27 ID:t15Y+NkR: 　　　　彡ミミミヽﾉ彡ミミ)
　　　((彡ミミミミ))彡彡)))彡)
　　　彡彡ﾞﾞﾞﾞﾞ"ﾞﾞ""""""ヾ彡彡)
　　　ﾐ彡ﾞ　　　　　　　　ﾐﾐミ彡
　　((ミ彡 jニﾆｺ　iﾆニｺ. ,|ミミ))
　　ミ彡　 fｴ:ｴi　　 fｴｴ) .|ﾐミ彡
　　ミ彡|　　））　| |　｀（（　|ﾐ彡
　 ((ﾐ彡| 　（（　-し｀)　））|ﾐﾐミ　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　ゞ|　））　､,!　」（ (　|ソ　　　＜　B6tZVOSSよ感動したぞ
　　　　　ヽ（（￣￣￣' ) ）/　　　　　＼＿＿＿＿＿＿＿＿＿＿
　　　　　,.|＼､)　　　' ( ／|､　
　　￣￣| ｀＼.`──'´／ |￣￣｀
　　　　　＼　~＼,,／~　 /
　　　　　　　＼／▽＼／
172 名前：Socket774 ：04/04/27 10:21 ID:EZAjmzxt: >>169
ついでに紙は別々、といったところかｗ
173 名前：Socket774 ：04/04/27 12:08 ID:l28nHlEW: 米新興メーカー、稼働中に新命令を追加できるチップを開発
http://japan.cnet.com/news/ent/story/0,2000047623,20065688,00.htm
どうですか？
174 名前：Socket774 ：04/04/27 14:04 ID:Y/apR8OO: プレスコは３０人が１つのトイレに入れるっつーことだな。
175 名前：Socket774 ：04/04/27 14:23 ID:PxKlASst: >>174
という事は最初の一人が早速つまずくと、３０人目はそのうち
我慢できなくなってお漏らししてしまう罠（ｗ

ＣＰＵもあまり待たされた命令はスキップしてしまったらどうだ
ろうか。（ヲイヲイ）
176 名前：Socket774 ：04/04/27 14:26 ID:dlsf7sWb: P6 はオシリからうんこの頭が見えた人からトイレに入るように
改良した。これがアウトオブオーダだよ。
177 名前：Socket774 ：04/04/27 15:11 ID:ky1zUeX2: >>174
ﾌﾟﾚｽｺｯﾄ、というより、NetBurstの偉大な点は、排泄行為をまったく別のものに
置き換えた点にあります。

高性能な人工透析器を別途配することにより、腎臓->膀胱->放尿といった
古来よりつづく非効率的なプロセスを、連続的な透析により完全にカバーし
かつ（局所的な時間帯に限って言えば）滞る事無く処理が可能となります。

また、人工透析器に繋がっている間は新しく体内で尿毒素が発生しても
ちんちんをだしたりしまったりという放尿に伴う予備作業を行わずして
処理を繰り返すことも可能となり、ここでもさらに効率が上がります。

また人工透析器をより高性能なものに交換することや、人工透析器への接続
方法を改良することはまったく独立して行えますので、将来の改良も容易に
なるという利点も生みます。

通院し人工透析器に繋がるまでは若干の労力と時間を要しますが、それは些細な問題です。

NetBurstにおける目的はあくまで体内から尿毒素を排出することにあり、
効率的に排出できるのであれば、それは目的に対し完全な勝利だからです。
178 名前：Socket774 ：04/04/27 18:03 ID:dlsf7sWb: >>177

それでも昔ながらのやり方が好きな人の為に普通の便器も置いてあって
実はそっちの方が人気があるのは秘密だよ．
179 名前：Socket774 ：04/04/27 23:25 ID:0ekE0vnA: 話の途中でスマンが、
アホな漏れにはSIMDとベクトルプロセッサの違いがわからん。
どちらも複数のデータを同時に処理するぐらいにしか書かれてない。
この二つの違いを教えて>エロイ人。

あとDSPとかゆう物について
漏れは今持ってるサターンについてるらしいことしか知らんが
決まった計算しかしない代わりに高速と聞いてる。
これは単にクロックが高いのか、それともSIMDみたく複数のデータを同時に処理できるからなのか
どっちなんだ。
180 名前：Socket774 ：04/04/27 23:48 ID:fmarAkfQ: ベクトルプロセッサはSIMDの特殊系っていうか一部。

行列計算にとにかく強烈に特化したもの。
もっと単純化すると、積和算を延々と行うだけになる
（減算、除算は加算、積算で代用できるから）。

DSPは、ある入力に対し一意に出力が決まるという条件で特化されたもの。
別にSIMDでなくてもいい。極端な話、メモリ素子で構成できる:-)
181 名前：Socket774 ：04/04/28 00:28 ID:/L1toHMn: DSP=マイコンと考えて問題ない。少なくとも今は。
メーカーがそういう名前で読んでるから。別にPCのCPUと比べて速いわけ
ではない。
182 名前：179 ：04/04/28 01:05 ID:ery2fJwX: >180
>181
サンクス。
SIMDとベクトルプロセッサは元は同じなのね。
自動車に例えるなら普通車がスカラプロセッサ、
サーキットしか走らんF3000がSIMDで
F1マシンがベクトルプロセッサってとこか。

あとDSPの性能はCPUの16倍ってな話を見ただけなんで
それもCPUが25Mhzしか無い頃の話だしな
高速には出来るんだけど今でも必要十分で進歩してないってことか。

PCではRIVAなんかのの古いビデオチップやサウンドブラスターに乗ってる奴なんか
は固定の機能しかもっとらんからDSPに近いのかな。
(TNTクラスになると内部に積和算ユニットを備えているらしい。)

ま、こんな夜中にレスありがと！。
183 名前：Socket774 ：04/04/28 02:14 ID:KP5ISNId: >>182
なんか違う。
SIMDの実装の一つがベクトルプロセッサ。
例えるならレースマシンがSIMDでF1マシンがベクトル。

DSPは名前の通りデジタル信号処理に特化したプロセッサ。
命令体系のほとんどがMMXみたいな専門命令なので
そういう処理をうまくやらせると同クロック・同規模のCPUよりは速くなる。
MMXみたいな専門命令とは要するに並列SIMDだったり積和演算が1命令だったりするってこと。
最近はCPUがそんな拡張命令を持ったり、CPUの演算速度がDSP並になったりして形無しぎみ。

ついでに外から見て固定の機能を持ってるかどうかと内部の実装はあまり関係ない。
たとえばキーボードはCPU（マイコン）入ってるけど固定の機能しかしないのと同じ。
184 名前：Socket774 ：04/04/28 02:54 ID:NaDmXs7w: クレイは別に SIMD とか意識して作ったわけではないので
分類方法としてあまりふさわしくないような。
SIMD っていう用語が人気なのは MMX命令のおかげ？

ベクトル長レジスタの中身で処理する要素数がかわるあたり
102さんの主張に近いような。

DSP は使える回路量が少ない頃に積和演算だけ豪華にしたというような。

P4 も得意なのはエンコード位じゃあ、DSP とかわらんような。

インテルが無理に詰めれば子供４人なら同時に便器に座れることを
発見して SSE 命令を作り、最近大人４人も座らせようとしてるが
これはさすがに評判がわるかったり、のような。
185 名前：Socket774 ：04/04/29 18:00 ID:8Gb1mD9D: >>184
作った人の意識なんて関係ないけど。

DSPはディジタル信号処理を目的としている(た)けど、マイコンとそれほど違うわけじゃない。
メーカの商品に対する考え方の違いで、DSPとかマイコンとかに分類してるだけ。

あと、車にたとえるのはやめろ。
186 名前：Socket774 ：04/04/30 15:48 ID:8NnvVvfM: >>185
ここまできて例えをやめろはないだろうｗ

SIMDがトイレで、ベクトルが和式便器みたいなもんか。
187 名前：Socket774 ：04/04/30 19:09 ID:q6Sa36I+: >>186
dirty na tatoe ha YAMERO
188 名前：Socket774 ：04/04/30 21:08 ID:v8Aw6YIc: 実際にプログラム組むと普通のDSPの３倍ぐらいの命令ステップが必要なんだよな

何考えてSSEやMMXのアーキテクチャ決めてるんだか
189 名前：Socket774 ：04/04/30 23:10 ID:2ysmugKd: >>186
SISD/SIMD/MIMDはFlynnによる分類で、ベクトルはSIMDになる。
この分類法が適切かどうかは別だが、この分類によればSIMD以外に成り得ない。

SIMDが便器で、ベクトルが和式便器と言うべきだろう。
190 名前：Socket774 ：04/04/30 23:11 ID:3+kQfAoN: >>188
汎用性
191 名前：Socket774 ：04/04/30 23:15 ID:2ysmugKd: >>190
MPEGとか3D処理とかじゃないの？ MMXの頃はそんなことを言っていたような気がする。

>>188
3倍かかったプログラムってどんな処理？
192 名前：Socket774 ：04/05/02 23:41 ID:aE118Gvj: Itanium2 1.5GHz → 64bit Windows Server2003
Opteron 248 → WindowsXP 64bit Edition
Athlon 64 FX-53 → WindowsXP 64bit Edition
Pentium4 HT Extreme Edition 3.4GHz → WindowsXP
Alpha21364 → Tru64 UNIX V5.1b
POWER4+ 1.9GHz → AIX 5L
SPARC64 V 1.3GHz → Solaris9 Operating Environment/SPARC

高パフォーマンスのCPUといえば
この辺が比較対象になるといえよう
あとのはちょっとアレ
193 名前：Socket774 ：04/05/05 22:01 ID:cweZVLZ+: PC向けCPUじゃなくてすまんが、EmotionEngineはVUに14個浮動少数点
演算器があるけどあの演算器全てに効率よく命令を送れるの？
VU同様Vliwアーキテクチャのia64でもコンパイラによる命令の並列化には
限度があるというし。
194 名前：Socket774 ：04/05/05 22:54 ID:v98DSjGN: ここはハイレベルなインターネットですね。
195 名前：Socket774 ：04/05/05 23:51 ID:Mpff1ykE: >>193
送れるか？でなくて送れるようなアプリを多用するからそのようなアーキになる。
IA64の問題は、こちらの方がアプリの幅が広いと言う事だな。
196 名前：Socket774 ：04/05/07 12:55 ID:/uDZzM+v: >>191
１．ＭＭＸをＯＮにする。
２．ＭＭＸ命令を実行する。
３．ＭＭＸをＯＦＦにする。

実装当時は浮動小数レジスタと切り替えだったんで。まあ、命令数が3倍になるわけじゃないが
ロクでもないのは確か。割り込み絡めばもうパフォーマンスの低下は必至なわけで。
197 名前：Socket774 ：04/05/07 13:19 ID:3UDtaLP6: MMXの最大の欠点は固定小数点で1.0を表現できないこと
SSE,SSE2,SSE3の最大の欠点はベクトル処理が加減算しかできないこと
198 名前：Socket774 ：04/05/07 15:31 ID:wqleEWhS: >>197
＞ベクトル処理が加減算しかできないこと

mulps、divps・・・
199 名前：Socket774 ：04/05/07 17:18 ID:sRmSBz+D: >>197
おまい固定小数点知らないだろ。
200 名前：Socket774 ：04/05/09 13:16 ID:e5HKg1JZ: ここは話が難しいねえ
201 名前：Socket774 ：04/05/09 13:37 ID:6BObo0hG: SSEを誉めるヤツ＝＝アセンブラでSSEコードを書いたこと無いヤツ
202 名前：Socket774 ：04/05/09 15:06 ID:qQijBS4j: >>201
コンパイラで性能がでれば良いのです。

…どういうふうに嫌なのか書いてくれないと話がつながらない。
203 名前：Socket774 ：04/05/10 02:54 ID:XvOmvoWQ: そろそろあげとくか…。

>>197
｢積和算」ができなきゃ「ベクトル(行列）演算」にならんだろーが。
数学やりなおしてこいな ^^

>>196
いいんだよ、本来は2.のステップを延々と何千回も繰り返すんだから、
前後の手続きなんて小さい小さい。
DSP単体利用なら言うとおりだけど、CPU外部にベクトル演算器つけてた
時とくらべたら、ベクトルレジスタいじるステップが入るんだから
騒ぐほどのもんじゃないだろ。

それよりもだ、余計なレジスタ増えるわモードの保存もしなくちゃだわで、
例外処理発生時のペナルティが痛いﾝだＹＯ!
204 名前：Socket774 ：04/05/10 11:14 ID:6LDexDUM: >>203
その積和の性能が低すぎるんだよSSEは
FPUの１．５倍くらいじゃバカ杉
205 名前：Socket774 ：04/05/12 09:18 ID:3HEqsI+h: >>196
ON（？）にする命令なんかねーぞｗ
206 名前：Socket774 ：04/05/13 10:45 ID:5X6lzPUn: ここ好きなんでAge
207 名前：Socket774 ：04/05/13 13:35 ID:AmDTVr8Q: >>203
DX5.0以前ならMMXの使い道もいろいろあったけど、いまじゃな・・・。
サウンドとムービーエンコードくらいか？

>>205
あれ、そのままレジスタ叩いたら使えるんだっけか。FloatとMMXの切り替え命令が
あったと思ってたけど勘違いかな。
208 名前：Socket774 ：04/05/13 14:30 ID:h7dbnL5x: >>207
OFFにする時のみEMMS命令を実行だったかも。
209 名前：Socket774 ：04/05/13 14:35 ID:s0wmqZPp: 拡張命令云々よりもCPU自体、コンピューターの中では
一個の演算ユニット何だから色々と騒いでもしょうがない。

それよりチップセット、マザーボード、OSの進歩の遅さの方が問題。
現状メモリ帯域6.4GBと言っても実帯域はその数分の一で
ｘ86CPUは一般OSじゃ４GBしかまともにメモリー扱えないし、
OSの方もXPじゃ、アプリ３GB制限あるので
自分的にはCPU性能よりそっちの方が気になる。

特に重い処理の大半が遅い大半がメモリー関係だと思うし、
FSBを現行４倍以上にし、メモリーも32GBぐらいにしないと
CPUは遊んでいる状態だと言ってみる。
・・・・ただし、それを上げる方がCPU性能上げるより遥かに面倒と言う罠
210 名前：Socket774 ：04/05/13 15:35 ID:htrFI+Vl: >>209
ちと、無い物ねだり杉
211 名前：DNS未登録さん ：04/05/13 17:50 ID:P/kfZItN: メモリの量は処理内容によって変わりすぎるからあれだけど、
バス幅はほんとにイタイよね。

リニアなメモリ空間マンセーになって久しいけど、そろそろ利用者側も
意識変える必要があるかも。

たとえばだけど、アドレスレジスタ毎に異なるメモリバスが存在していたら
どうだ？利用データによってメモリセットを選択できれば、今ほどのバス幅
は要求しなくても高速にデータアクセス可能にはなりそう。
212 名前：Socket774 ：04/05/13 18:06 ID:65MPdUBe: >>211
実際動いてるバスは1本か2本になると思うのは気のせい？
213 名前：Socket774 ：04/05/13 18:15 ID:/KJv91m1: >>211
メモリインタリーブ・・・
214 名前：DNS未登録さん ：04/05/13 18:32 ID:P/kfZItN: >>212
そこが味噌。

どうあがいてもメモリはCPUの速度においつけないから、メモリアクセスしにいったら
放置して別処理させるのよ。

大型機やHighEndなWSだと昔からやっている技術なんだけど、RDRAMでPCにようやく
導入か？っておもったら市場に受け入れられず消えたｗ

>>213
メモリアクセス待ちでバスを開放しないと、いくらインターリーブしてもダメ。
また、メモリデバイスが一つだと、バスを開放しても次のメモリリクエストだせないから
やっぱりダメ。

で、実はAm29000はインストラクションバスとデータバスを個別にもってて、
直線性のあるインストラクションバスはVRAMのシリアルポートにつないじゃえ
って発想なんだけど、ある意味、二つのアドレスレジスタに対し二つのバスを
用意した一例。
215 名前：Socket774 ：04/05/13 20:14 ID:M3vKFOJY: >>208
３DNow!の解説には無くても動くけど最初のMMX命令でEMMSと同様の処理が発生するから
FEMMSではさんだ方が速いと書いてあったな
216 名前：Socket774 ：04/05/13 20:23 ID:ehtTaVxF: CQから出てる中森章の「マイクロプロセッサ・アーキテクチャ入門」は
このスレ的に面白いと思うのでおすすめ
217 名前：Socket774 ：04/05/13 21:19 ID:6sJvDktR: そういや本棚の奥にその手の解説書があったんだった。
いいことを思い出させてくれたよ、サンクス>>216
218 名前：Socket774 ：04/05/13 21:44 ID:70c4u7x3: >>214
I/D分離するのはバーバードアーキテクチャと言ってそーとー昔からある。
219 名前：Socket774 ：04/05/13 23:11 ID:i50LLaWw: ＞最初のMMX命令でEMMSと同様の処理が発生するから

いい加減なこと書くなよ。

EMMS命令は8つあるFPUレジスタのタグワードをすべて有効にする(11)にする命令。
MMX命令によってレジスタに書き込まれると、タグワードは無効(00)になるんだよ。
220 名前：Socket774 ：04/05/13 23:39 ID:HI8n14Yq: >>218

そーなんだよなー。

で、I/D別にメモリバスを用意できないからってんでキャッシュだけ
分離して妥協したのが486/Pentinum。
キャッシュからの命令取り込みと実メモリとの並列動作を実現
(BSB/FSBの分離)したのがPentinumPro系バス。
で、メモリからキャッシュへの転送ってのはある程度まとめて
転送したほうが便利(メモリアクセスの局所性、キャッシュのラインフィル動作)。
そういう目的向けの機能が用意されたのがPB-SRAMであり、SD/DDR-DRAM。
FastPageなDRAMもそういう目的には便利に活用できる。

で、214が言う機能の壁はマルチタスク動作じゃないかな？
221 名前：Socket774 ：04/05/13 23:52 ID:M3vKFOJY: >>219
物理的なレジスタは別物だから切り替えにものすごく時間がかかるんだが
MMX>FPUは遅いけどFPU>MMXは速いのか
知らんかったよサンクス
222 名前：Socket774 ：04/05/14 00:06 ID:hING/Zqo: >>219
君も間違っているし。
EMMS使うとタグは8つすべて「空」11になる。
EMMS以外のMMX命令を使うとタグはすべて「有効」00になる。
ちなみに無効は10。

あと、やろうと思えばEMMSを呼ばずにMMXとx87を混在させることができる。
遅いか速いかは分からないけど。
223 名前：211,214 ：04/05/14 00:12 ID:8DUXxRQD: MPUの世界でハーバードアーキテクチャを歌ったのはMC68000あたりからなんだが、
残念ながらメモリデバイスに伸びるまずまで分離できてなかったんだよね。
けど、肉まんを例にだしたのはちょっと失敗だったかも。反省。

で、ノンリニアなメモリ空間の実装は以前からありはしたのだが、当時メモリは
高速かつ高価なデバイスでありCPUと同期動作が可能だったけど大量実装は出来なかった。
Z8000、MC68000あたりはインストラクションとデータ、スタックで明確に
アドレス空間を分離していた（68kにいたってはスーパバイザモードとユーザモード
も分けられた）けど、わざわざ分ける事はされなかった（した実装ってあるのかな？）

さて、211での問題点はなにかっていうと、各メモリバスにつながれたメモリデバイスに
相当の無駄がでるあたり。それと、PMMUの実装が面倒な点。そして、アプリケーションと
OSがメモリの実装状況によって最適化しないと効果が出ない点。
マルチタスク動作に支障はでないよ ^^

今やるとすると、、
・CPU内部
　CPUコア各部に独立したAGを搭載し、各Function毎にデータキャッシュへ
　同時アクセスさせる。排他アクセスにしないとイタイけどそれはブロック単位で制御

・外部バス
　データキャッシュをブロック単位で複数に分割し、個別にバスコントロール。
　もしくはRDRAMのようにメモリリクエストとデータをパケットにまとめてやり取り
　するようにし、リクエスト出したら一旦開放するとか。

かなぁ。

いまのメモリ帯域の狭さは、メモリバスがその名の通り「バス」動作している点にあって、
クロック倍にしても倍にしか速くならないのがイタイ。
どうせ外部記憶装置並みに遅いデバイスなら、外部記憶装置としてつかう事考えてもいいかもね。
224 名前：211,214 ：04/05/14 00:15 ID:8DUXxRQD: あ、それと、
・シーケンシャルにしか動作できない
・片方向でしかデータをながせない
のもイタイ点。
225 名前：Socket774 ：04/05/14 00:37 ID:GDn0NZGE: >>223
>マルチタスク動作に支障はでないよ ^^

コンテキストスイッチ時のペナルティが大きくならねぇか？って話。
226 名前：Socket774 ：04/05/14 00:43 ID:cIqAF+Kl: CPU性能＝命令セット×マイクロアーキテクチャ×製造技術
結局のところ設計や工場に投資できる金のあるところが勝つ。
金がある＝CPUが売れてる＝普及した古い命令セット＝汚い命令セット
かくしてAlphaやTRONのような美しい命令セットは滅び
x86やPowerPCのような汚い命令セットが世界を席巻する訳だ。
227 名前：Socket774 ：04/05/14 00:44 ID:Ka+SpH6I: >>223
当時はパッケージング等の問題もあったと思われ。

ハーバードアーキテクチャが完璧かと言えばそうでは
ないよね…データテーブルとか面倒だし。
228 名前：211,214 ：04/05/14 00:54 ID:8DUXxRQD: >>225
メモリ待ちになるのはどっちも同じ話だし、メモリリクエスト後待ち状態に
なったらその時点でもコンテキストの切り替えしてもいいから、むしろ
ペナルティは小さくならないか？

メモリ側は状態管理しないといけないからインテリジェンスになる必要はあるけど。

見落としてる点があったら指摘よろしく ^^
229 名前：Socket774 ：04/05/14 01:25 ID:J/pnPbXn: 保守
230 名前：Socket774 ：04/05/14 01:28 ID:gKKyzkl5: なんとなくわかったような気もするが、かなり複雑な回路になりそうやな
そこまでやると、かえってレイテンシが増えてしまいそうな気もする
単純にL3キャッシュをアホみたいに積むほうが速くなりそうな
231 名前：Socket774 ：04/05/14 01:32 ID:VYbIjOI2: >>227
パッケージングの問題は過去のものでは無い気が。
ついでにCPUコア内部のバス引き廻しも爆発的に増えちゃって
クロック上げられなくならないかな。

ちょっと違うけど、漏れは10年位前に命令を分類して、種類毎に
別々のメモリバスにつながったメモリからプロセッサに供給する
っつーCPUの試作なんてのをやってたけど、やはりLSIデザインが
破綻しちゃった思い出が・・・
232 名前：Socket774 ：04/05/14 01:33 ID:iEAKJs0O: >>226
>かくしてAlphaやTRONのような美しい命令セットは滅び

TRONってTRONプロセッサってヤツ？
233 名前：Socket774 ：04/05/14 01:45 ID:Ka+SpH6I: >>231
今時のは半分くらい電源用ピンのようなｗ
234 名前：Socket774 ：04/05/14 01:46 ID:TwuHrATU: >226
美しい、汚いってのは?トーシロにもわかるように説明きぼん

無理（理解することが）？
235 名前：Socket774 ：04/05/14 02:30 ID:7jY5RAAU: >>226
キャッシュが内蔵する様になったからねぇ(´ー｀)y─┛~~
236 名前：Socket774 ：04/05/14 04:17 ID:o8pcTKwR: x86の有利な点を無理に言えと言われれば、レジスタが少ないので
コンテクストスイッチが少し速くなる可能性がある事かいな。

x86-64なんかでは、増えたレジスタをスイッチの度に全部待避する
んだろうか？
237 名前：211,214 ：04/05/14 07:10 ID:8DUXxRQD: >>230
うん、メモリコントロール部分の回路もメモリ側も相当複雑になるだろうし、
コストも相当かかるようになっちゃうだろうね。実際 RDRAMって高くて市場に
受け入れられなかったわけだし。

>>231
やったんだｗ
内外のデータバスを双方向シリアルにして、外部数GHzでまわしたらどうなるかなぁ。
238 名前：某スレの5 ：04/05/14 07:42 ID:6QTclobL: もうワイヤードロジックだのCRISPなどといった言葉は出てこないのね。
初期のCISC vs RISCで散々使われた言葉なんだけどさ。
239 名前：Socket774 ：04/05/14 09:26 ID:VYbIjOI2: >>237
今だったらそうするだろうねぇ。
しかし、高性能プロセッサ設計の仕事自体が漏れの周辺では殆ど
なくなっちゃったw

>>238
CISC RISC論争はもうほとんど意味無いと思う。強いて今からやるなら
これからは VLIW だよ派 vs スーパースカラまだ無敵だよ派
かな？
240 名前：Socket774 ：04/05/14 10:31 ID:fbKCb2R/: >>236
そりゃやらなきゃまずいでせう。
プロセス間でレジスタの中身を共有するなら、
その分はなにもしなくてもいいけど。
241 名前：Socket774 ：04/05/14 12:36 ID:a9fVobXs: >>234
無理・・・じゃないかな。
アセンブラレベルを理解できれば、分かると思う。

そんな漏れはZ80→8086で泣きそうになった男・・・。
242 名前：Socket774 ：04/05/14 12:40 ID:wflXmd8a: 今どきのメモリは連続アクセスする分には充分速いから(プリフェッチとかできる)、
レジスタ退避みたいに連続したアクセスなら比較的性能を出し易いのでは。
243 名前：Socket774 ：04/05/14 12:54 ID:wflXmd8a: >>239
IA-64も2006年のTukwilaで動的命令スケジューリングが入るらしい。
http://pc.watch.impress.co.jp/docs/2004/0305/kaigai070.htm
コンパイラの生成した順序とは違う順序で命令を実行できるCPUをVLIWって呼ぶの？

Any sufficiently advanced VLIW is indistinguishable from Superscalar.
(c) Arthur C. Clarke
244 名前：Socket774 ：04/05/14 14:14 ID:nRcYMjIn: http://pc5.2ch.net/test/read.cgi/jisaku/1083865295/542-549
でも書いたけど、Intelって

IA64コード -> μOps -> スーパースカラプロセッサ (out-of-order)

なんちゅうことをやろうとしてたみたいだからねぇ。
Tukwilaもバンドルあたり3つの命令を一度バラして、バンドルを超えて
out-of-order で発行するとかいう構造になるのかもね。

ついでにEfficeonは http://pcweb.mycom.co.jp/news/2003/10/16/19_10.jpg
見る限り、実行ユニットは in-orderだけど、CMSが命令スケジューリング
してるみたいだから

x86コード -> CMS (out-of-order発行) -> VLIWプロセッサ (in-order)

ですな。
245 名前：Socket774 ：04/05/14 22:08 ID:geXAPL4r: これからは，スーパースカラプロセッサにしても，
VLIW プロセッサにしても，マルチスレッド化 (特にSMT) に向かうのでは？
などと最近勉強しはじめた新米の戯言をお許しください。
でもマルチスレッド VLIW って，初心者からみるとよさそうなんだけどなあ...。
246 名前：Socket774 ：04/05/14 22:10 ID:2mpM2oWG: >>223
68000はハーバードアーキじゃねー。

メモリスループットを増やしたかったら、インターリーブしたり、
リクエストをアウトスタンディングに発行できるようにする方が素直。
(互換性、汎用性、性能重視の場合)

>>243
VLIWはDelayed Branchやインターロック無し実行と同じように盲腸になった
ようだな。(性能を重視するプロセッサにおいては)
247 名前：Socket774 ：04/05/14 23:03 ID:GDn0NZGE: >>246

盲腸っつーか、当初からVLIWが抱えてる問題。
バイナリコンパチを捨てるなら簡単だが、
IA-64の場合はそこまでハイエンドにはなれないからね。

その点直接ネイティブを見せないEfficeonは上手くやった。
248 名前：Socket774 ：04/05/14 23:23 ID:8DUXxRQD: >>246
研究者方面での意見はしらんがMC68000はモトローラいわくハーバードアーキテクチャを
特徴の一つとしたMPU。内部バス構造がその所以。

インターリーブはバスを100%近く活用するための手段であって、100%をこえるための手段でもない。
パラレルにするかビット幅増やす方が素直。それができないからこその代替手段がインターリーブ。

アウトスタンディングにメモリリクエストを発行するってのが何を指してるかｺﾞﾒﾝ、わからん。
WriteBackなどの、コア側の要求に対し非同期にメモリ操作を行うものを指してるのなら、これも
100%近く活用するための工夫。

>>209が｢メモリおせぇ、FSB速くしろ（帯域増やせ）」と叫んでるから、その解決を考えてるんだよね。
現行のメモリ帯域を有効活用する手段の、さらに次。

うーん、期待してた突っ込みはそういう常識的な部分じゃなくて、、>>225的なのが欲しいなぁ^^
おそらくだけど、メモリ空間を細分化させた場合、その構造に特化されたデータ構造のプログラムは
劇的に速くなるけど、それから外れる場合はメモリマネージメントに恐ろしい手間がかかるはずなんだよね。

SunFireやSGI Originなんかは、システムとして非常に大きなメモリをもつことが可能なのだけど、
蓋を開けてみると実は2～4CPUに通常の構造で共有されるメモリをのせたSMPシステムを一単位にして、
それを数十～数百単位のせ、さらに相互にメモリ参照できるようにしてる。

ある程度以上は分散アーキテクチャにしちゃったほうがいいっていう割り切りなんだろうなぁ、って
僕は思ってみてるけど、どうだろう。
249 名前：247 ：04/05/15 00:44 ID:uIlRQr+q: がーん。
間違えた～。

VLIWが抱えてる問題じゃなくて「バイナリコンパチが抱えてる問題」だった…。

IA-64はバイナリコンパチのまま命令拡張が出来る改良型VLIWだから
動的スケジューリングを載せる必要性が出てくるのね…。
250 名前：Socket774 ：04/05/15 01:33 ID:zfRjET+x: IA-64はVLIWとは言わず、EPICと言ってるな・・・。

Itanium→Itanium2で中身変わったけど、バイナリコンパチ。
ただし、どっちに最適化するかで、パフォーマンスは多少変わる。
251 名前：Socket774 ：04/05/15 02:33 ID:/jNN/fIw: >>248
内部バス分離でハーバードアーキかよ。マーケティング用語だな。

100%越えたら動かんだろ。チットは考えろ。

だいたいバスバス言っているけど、バスに拘ってる段階でダメなんだよ。
CPUにメモリコントローラ内蔵は安価で効果がありそうじゃないか。

Originは知らんがSunFireはSMP(厳密には違うだろう)で、分散アーキじゃねー。
どのCPUからも全メモリにアクセスできるだろうが。分散マシンとか言ったら
設計者泣くぞ。(多分パーティションは切れるだろうがそれは話が別)
252 名前：Socket774 ：04/05/15 04:48 ID:z7Ahfmcu: うーん、煽りたいだけの半可通は放置したほうがいいのかな？

SunFireの場合SMP構造を持っているのはCPUモジュール単位で4CPUは一組になります。
これをクロスバスイッチ式のデータパスで相互に接続し、別モジュールに搭載された
メモリを直接操作できるようになっていますが、アクセス速度には相当のペナルティが
課せられます。

モジュールを一つのプロセッサとみなした場合、モジュール間は対称構造をもちますので、
その意味ではシンメトリックかもしれませんが、メモリを内包してるのでちょっとそれは
乱暴でしょう。

実際のプロセッサから見た場合、対称構造になるのは同一モジュール内に存在するプロセッサ
だけですから、別モジュールに存在するCPUはSMPとはいえません。

ソフトウェア的に見た場合にも、すべてのプロセッサをSMPとしてコントロールすると、
あるプロセッサがスレッドを実行しようとした場合、そのインストラクションおよび
データが自モジュール内に存在するとは限らず（むしろない場合のほうが多くなる）、
前述のメモリアクセスのペナルティが課せられることとなります。

残念ながら私もSunOSのソースを見たことはないんで、SunFireにおけるタスクスケジューラが
どのようになっているかはわかりませんので、ペナルティを甘んじて受けてるのか、素直に
スレッドを各モジュールごとにばら撒いてるかは想像の範囲を出ません。
253 名前：Socket774 ：04/05/15 10:34 ID:joOkFrti: そのクラスのマシンはNUMAでしょ。
Origin は cc-NUMA と明記してたと思うけど、SunFire はどうなんだろう。
254 名前：半可通 ：04/05/15 13:08 ID:/jNN/fIw: >>252
SUNはSMPと言ってるがな。
Cacheを付けた段階で厳密な意味でのSMPなんて存在しないよ。
1つの保守単位となるボード上に複数のCPUを載せ、かつ複数ボードを搭載できる
製品をSMPと言っているのはたくさんある。もちろん厳密な意味ではSMPでは
ないが、それを気にしているのか？キャッシュ無しバス結合マルチプロセッサ
以外はSMPになり得なくなる。

どこのメモリに載っているかより、どこのタグにヒットするかの方がレイテンシの
差が大きい場合もあると言っておこう。

あと、SunOSのソースを見なくても『Solaris Internal』に載っているかも知れん。
読んでみれ。
255 名前：Socket774 ：04/05/15 14:33 ID:idS32bh0: キャッシュがあってもSMPって普通は言うと思う。もし「キャッシュがあったらSMPではない」なんて言うのが
SMPの定義だったら「世の中にはSMPなんて存在しない」ということになってしまうからね。だから厳密な意味の
SMPの定義は「どのCPUから見てもどのメインメモリも等latency・等Bandwidthに見える」だと思う。
この条件に合うのは、いまだにシェアードバスにこだわっているIntelのXeon/Itanium2でシェアードバス結合が
使える4way以下のシステムとIBMのメインフレームだけでしょう。それ以外は全てccNUMAと言っても良いと思う。
(2coreのCPUを使った2wayのシステムも厳密な意味でSMPだけど)厳密なSMPを実現するには非常にコストがかかるので、
無理して厳密なSMPなんてやらないで、ある程度ccNUMA的なシステムを作って、あとはソフトウェアの使いこなしに任せる、
というのが現在の技術の流れだと思う。Linux kernelだって一生懸命NUMAサポートを入れているし。
256 名前：Socket774 ：04/05/15 16:15 ID:/jNN/fIw: 255の主張ではSunFireはccNUMAになってしまいますが、そういう意味？
あと、SMPマシンにLatencyの違うDIMMを差すだけでSMPじゃなくなると言う
主張にも見えますが？
普通はそんな厳密な事は気にしていなくて、SunFireはSMPに分類するだろう。

ところでSunFireのボード内/ボード間Latency/バンド幅の差は公表されてる？
257 名前：Socket774 ：04/05/15 23:40 ID:idS32bh0: 広義に言えばSunFireでもIBMのRegattaでもHPのSuperdomeでも大規模SMPはもうccNUMAと言えると思う。
たぶん、80年代だったらああいう構成ならccNUMAと呼んだと思う。(Opteronもそう)
ただ現実には昔のccNUMAと比べてローカルメモリとリモートメモリのアクセスタイムの差が大分小さいから、
あまり性能のことをうるさく言わなければ、普通のSMPとして使えるんだと思う。
だた、性能をうるさく言うとソフトウェアがローカルメモリとリモートメモリを意識した処理をする必要が
あって、今やLinux kernelだってそれを意識したCPU/メモリ割当てとかをやろうとしている。
Linuxがやろうとしている位だから、各ベンダーのUnix(Solaris/AIX/HP-UX)は既に絶対やっていると思う。
258 名前：Socket774 ：04/05/16 00:42 ID:CQeyOTcj: SunはSunFireをSMPとしか呼んでいないし、少なくともSolaris7はSMPにしか
対応していない。(『Solaris Internal』)

『Solaris Internal』では、システムインターコネクト(ボード間インター
コネクト)が均一なアクセスタイムを実現するために十分なバンド幅
があるものがSMPであるとしている。
259 名前：257 ：04/05/16 01:04 ID:aqoCpppm: だからSunFire/SolarisはSingle imangeでは性能が悪くて、パーティショニングして使うんだ。
Bandwidthが確保されていても、レイテンシの差は絶対あるんだから、それを意識した制御は
OS側でやるべきだと思うよ。
260 名前：Socket774 ：04/05/16 01:11 ID:aqoCpppm: だいたいSunFire(SPARC)みたいな時代遅れの性能の悪いシステムの話がなんでされているんだろう。
元々SunFireもCrayが設計していたのをSunが買ったんだと思うから、Sunはもう何年も自分で
まともなハイエンドのハードウェアを開発していないんじゃないかな。
UltraSPARCⅣだって、結局UltraSPRACⅢのデュアルコア版にすぎないし。
261 名前：Socket774 ：04/05/16 01:25 ID:CQeyOTcj: パーティション切らない時にローカルボードのメモリアクセスが遅くならない
ことを言わないとSMPで無い事を言えません。

> ところでSunFireのボード内/ボード間Latency/バンド幅の差は公表されてる？

257は知ってるのだろうが、知らなければSunはSMPだと言ってる以外何も言えません。
(というより何が言いたいのかさっぱり分からない)
262 名前：Socket774 ：04/05/16 02:25 ID:aqoCpppm: パーティションを使わない場合、SunFireの構成ならローカルメモリとリモートメモリのレイテンシの差が
あるのはハードウェアの構成上明らか、という考察では不足？
Bandwidthはわからないけど、レイテンシは絶対違うでしょう。
でもSunのSMPの定義と私の"厳密な意味の"SMPの定義は違っていて、Sunの定義だとレイテンシが違っても
Bandwidthが違わなければSMPと言って良いから、SunのSMPの定義に従えばSunFireはSMPかもしれない。
でもどうせSunFireのBandwidthなんて激低だろうから、どうでもいいのでは。
263 名前：Socket774 ：04/05/16 12:55 ID:CQeyOTcj: あなたの定義だとSMPマザーボードにレイテンシの違うDIMMを差すとccNUMAに
なるんですね？

根拠もなくSunFireをccNUMAと主張するよりは現実的。
レイテンシは絶対違うという考察なんてどこにも出て来てない。まずSunFire
のキャッシュコヒーレンシプロトコルの説明から始めた方がいいですよ。

>>260
このスレは思い付きとか言い合って楽しんでる(?)んだから古くてもいいじゃん。
新しい方が良ければネタ振ってよ。
264 名前：Socket774 ：04/05/16 12:59 ID:Vg9ZZwCy: Efficeonマンセー
265 名前：1 ：04/05/16 17:51 ID:PFVC4Hwa: だんだんとスレが生きてきましたね。
一瞬削除願い出そうかと思ったが、出さなくてよかった。
266 名前：Socket774 ：04/05/16 23:16 ID:D2lGqmDh: またかなり話が難しくなってきました。
初心者を置いていかないように適度にトイレで例を示してください。お願いします
267 名前：Socket774 ：04/05/17 00:40 ID:jg7lrt0d: 少なくとも性能対消費電力が重要視される分野ex)Embeddedなど)以外では、
Hardwareの仮想化ってのはここ数年来大分注目されてる分野だと思うけれど？

例えばIA64の性能向上がムーアの法則を上回るなんて言われてるのも、
それ遺体は眉唾だけど、IA32で同じ事を言うよりは信憑性があるように、
今後は最新プロセスと高度な論理設計技術を持ってるメーカーは
益々VLIW(CMS？)的なアプローチの方が有効になると思うんですがどうでしょう。
268 名前：Socket774 ：04/05/17 00:41 ID:jg7lrt0d: あ、>>267は>>247に対してス。
269 名前：Socket774 ：04/05/18 04:51 ID:xBtH3Tra: http://www.idg.co.jp/sw/back/series/200005_01_kernel.html
----
サン・マイクロシステムズが出荷しているマルチプロセッサ・システムは「SMP」と
呼ばれるアーキテクチャを実装している。これは、「Symmetric Multi Processor
（対称型マルチプロセッサ）」と「Shared Memory MultiProcessor（共有メモリ型
マルチプロセッサ）」という2つの用語の頭文字をとったものである。サンのシス
テムは、どちらの用語にも当てはまる設計がなされている。
----

もはや、SunFire15Kあたりは、前者の意味でSMPと言っているだけという気がする。
これなら、NUMAとSMPは直交する概念だ。
270 名前：Socket774 ：04/05/18 05:35 ID:xBtH3Tra: すまん、>269の補足。

リンク先を読めばわかるが、ここでいう「対称型」は、どのプロセッサも同じOSの
機能を処理できる構成を指していて、プロセッサからメモリが等距離とかいう
構成ではない。
271 名前：Socket774 ：04/05/18 10:52 ID:dCU2dMFp: しばらく見られんかった…age。

>>270
SunFireのSMPは、ある程度ハードウェア構造をさしてはいるけど、
どっちかっていうとSoftware(OS) Parspective な言い方だよね。
それで性能がでるかは別の話。

ただ、無駄にコストかけるよりは、こういう割り切りをある程度行って
アプリケーションチューニングするのが、今のトレンドなきがする。

スパコン方面のアーキテクチャは知らないのでごめん明るい人よろしく。

>>266
SMPやバス構造を便所で説明するのﾑｽﾞｶｼｲんだよな ^^;
考えてみるけどできなかったらｺﾞﾒﾝ
272 名前：Socket774 ：04/05/18 11:48 ID:H5clhrf8: ┌────┐　　　　　　　　┌────┐
│　部屋　│　　　　　　　　│　部屋　│　
│　　　　　│　　　　　　　　│　　　　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　　 ││　　　　　　　　　　　　 ││
　　 │└─────────-┘│
　　 │┌─────────-┐│
　　 ││　　　　　　　　　　　　 ││
┌─┘└─┐　　　　　　　　┌─┘└─┐
│.　トイレ . │　　　　　　　　│.　トイレ　 .|
└────┘　　　　　　　　└────┘　

┌────┐　　　　　　　　┌────┐
│　部屋　│　　　　　　　　│　部屋　│　
│　　　　　│　　　　　　　　│　　　　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　　 ││　　　　　　　　　　　　 ││
　　 │└─────────-┘│
　　 └─────┐┌───-─┘
　　　　　　　　 ││
　　　　 ┌───┘└───┐
　　　　 │　　　　トイレ　　　　.│
　　　　 └────────┘
273 名前：Socket774 ：04/05/18 12:43 ID:x7lPfqA+: >>272
上手い！
274 名前：Socket774 ：04/05/18 15:30 ID:QyCi5Mrf: またトイレかよ！ｗ
275 名前：Socket774 ：04/05/18 19:33 ID:nxT5sLq6: これだとトイレがメモリで部屋がプロセッサになるのですか？
276 名前：Socket774 ：04/05/18 23:33 ID:WbQKRzbK: >274
266ですが、初心者にはこれが一番わかりやすいんですよ(･∀･)
277 名前：Socket774 ：04/05/19 12:02 ID:SuXTd04W: >>275
排泄要求を出すのは部屋側だけど処理するのはトイレだし、
データ（人）の流れは部屋からトイレだから、プロセッサとメモリの関係と
ちょと反しちゃう希ガス…。
278 名前：Socket774 ：04/05/21 14:34 ID:6AX3fDuH: SunFireのメモリ管理について、ちょっと調べてました。
Sun Technical Bulletin 10/2002、「SunFire 3800-6800 動的再編成」、
Sun Technical Bulletin 7/2002、「SunFire V880サーバアーキテクチャ」他
テクニカルブリテンからの理解です。

少し古いんで、SunFireE25000などでは変更されてる可能性はあります。

まず、UltraSparcIII(IV)は、物理メモリのコントロールは8GB（16GB)まで
しか行えません。ここは大きなポイントで、これはシステム全体に存在する
32GB～576GBという、大きなメモリ空間を透過的に扱うことができない事を
示します。

さて、この問題を解決するため、OSにおけるメモリ管理では、各CPUボード毎に
スワップを禁止した常駐エリア設け、ここに各CPU毎のリソースを動的に管理する、
OSの基礎部分を常駐させます。

それ以外の非常駐エリアはページ管理され、リソースの動的管理機構とvmのページング
機構により、必要に応じマップを行い、アプリケーション側に対し完全に隠蔽します。

こうして、アプリケーションから見た場合、SunFireのシステムはSMPシステムとされますが、
OSレベルではメモリ（以外にも、各リソース）配置を意識したものとなっています。

はしょった説明だけど、こんなとこで、どかな？
つっこみ訂正よろ。
279 名前：Socket774 ：04/05/21 15:11 ID:NPMsAeqI: ＞リソースの動的管理機構とvmのページング機構により、必要に応じマップを行い、
ここ良く分らない
物理メモリが8/16GBしか扱えないんなら"必要に応じマップ"ってできるの？
テクニカルブリテンのURL貼って
280 名前：Socket774 ：04/05/21 21:06 ID:ED1yKCoz: >>279
一度に扱える物理アドレス空間が8/16GBってことちゃうの？これ。
何かにこんな仕組みがあった・・・。
あー名前が思い出せねえ・・・。
281 名前：Socket774 ：04/05/21 22:29 ID:NPMsAeqI: 「マップを行う」っていうのはCPUが仮想記憶でVirtual→realの変換を行うことじゃないの？
そしてCPUの扱えるrealメモリの容量が8/16GBだとしたら、それ以上のメモリ空間をどうやって
マップするのかな？　と言う質問。
282 名前：Socket774 ：04/05/22 02:14 ID:v63PcT5s: おそなりました。
TechnocalBulletinは紙媒体で保守会社（CTCとか）からもらってるので、
URLはｺﾞﾒﾝ。

かわりにこのあたり、かな？
http://jp.sun.com/products/wp/

アクセスできないはずのメモリにどうやってアクセスしてるのか、私もそれ
疑問です。

今WhitePaper読み漁り中ですが、SplitExpanderというのが各CPU/メモリボードと
バスの間に存在しており、ドメインの分離や合体をコントロールしてますので、
もしかするとここでバンク切り替え的に、同一ドメインに属したCPU/メモリボードの
メモリ空間を写してる、、のかなぁ？
283 名前：Socket774 ：04/05/22 02:32 ID:v63PcT5s: …。
よく考えたらさぁ、核となるシステムプログラムが各CPU毎に独立して
存在してるなら、擬似SMPするのに別に他のCPUが占有するメモリにアクセス
しにいく必要、ないじゃん。

元々いまどきのvmは物理メモリなんてただの仮想空間のためのキャッシュに
過ぎないわけで、仮想メモリ空間のマップ情報だけ各CPUごとに共有していれば
いいわけ。

特にtextは thread 毎に各CPUに割り当てられた際に page-in すればいいわけで。

問題は data 領域なんだけど、これはキャッシュと一緒でコヒーレンシさえ
保っておけば、まったく同じコピーがあちこちに存在してても問題なく、実際
Sunのインターコネクトにはその機構が備わってる。

SunFireが実際そうかは、まだ理解できてないけど、vmの機構をうまく使って
隠しちゃえば、ユーザは簡単に騙せそう ;-)

遅くていいなら、Ethernet越しにだってできるよ。
284 名前：Socket774 ：04/05/22 14:11 ID:dPkAriVy: 遅かったらダメなんです。
285 名前：Socket774 ：04/05/23 06:40 ID:lgnIZbX8: http://www.diku.dk/undervisning/2004f/303/SunFireplane.pdf
"The Sun Fireplane System Interconnect"の6～7ページを見る限り、
CPUからは全てのメモリ空間がアクセスできるようにみえる。

CPUが要求するアドレスをアドレスバスに出せば、Fireplane経由で
全部のCPU（メモリコントローラ）まで届いて、該当アドレスを持つ奴が
（それが自CPUのメモリコントローラか他CPUのメモリコントローラかに
かかわらず）データバスにデータを流してくれる。
286 名前：285 ：04/05/23 07:14 ID:lgnIZbX8: 小さいマシンの場合だとどうかと思ったが、UltraSPARC III Cu User's Manual
http://www.sun.com/processors/manuals/USIIIv2.pdf のpage2-14の2cpu
構成を見ると、あまり動きに違いはなさそう。アドレスバスにアドレスを流せば
データを持ってる奴がデータバスにデータを流すと。

>278
>まず、UltraSparcIII(IV)は、物理メモリのコントロールは8GB（16GB)まで
>しか行えません。ここは大きなポイントで、これはシステム全体に存在する
>32GB～576GBという、大きなメモリ空間を透過的に扱うことができない事を
>示します。

メモリ空間を透過的に扱えないというのがわからないなぁ。アクセスを透過
的に扱う仕掛けはあるのだから（と俺は思ってる）、別の何かがあるのか？

>さて、この問題を解決するため、OSにおけるメモリ管理では、各CPUボード毎に
>スワップを禁止した常駐エリア設け、ここに各CPU毎のリソースを動的に管理する、
>OSの基礎部分を常駐させます。

常駐エリアを設けるのはCPU毎ではなくてCPUボード毎？CPUの制限を回避
するためならCPU毎に持ちそうなものだが。それとも、CPUボード＝1CPUの
モジュール？

では、そろそろ寝るわ。
287 名前：Socket774 ：04/05/23 14:04 ID:+nQGBcYR: UltraSPARC IIIはアドレスバスがあるのか？
初代UltraSPARCはUPAだったが。
288 名前：Socket774 ：04/05/23 22:13 ID:9ZpK2pdG: http://jp.sun.com/products/wp/server/WP_V440.pdf
こいつなんかは、CPUとメモリが1:1で載って、JBusで合計4つが載るから、
CPU毎に常駐ｴﾘｱが存在するのだろうな。

一方で、
http://jp.sun.com/products/wp/UEarch/docs/UEARC03.html
は、メモリボードごとに複数のCPUが載り、一つのメモリモジュールを共有
するため、ここに限っては純SMP構造をとって、ボード毎に常駐ｴﾘｱを持つん
だろう。

で、各CPU/Memoryボードにはアドレスコントローラが載っているようだが、
こいつが搭載されたメモリの他FirePlaneを解したメモリリクエストを行っ
ているみたいで、UPA(たぶんFirePlaneも）に出力