2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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
2げっとおおお

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年(1月号ぐらい?)のSuperAsciiに全て書かれてる
今更語るほどの事でもない


27 :Socket774:04/04/19 17:13 ID:PoavHFnz
そもそも板違いじゃないの?

28 :Socket774:04/04/19 17:13 ID:Yrb98hrb
ああすまん、10月号だったかもしれん

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
そんな事を書くと、
それを書きたいがためにスレ立てたのではと邪推してしまうぞ。
脳ある鷹は鷹のつめですw

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
3クロックくらい?

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とかが1命令でできるし

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
お答えいただきありがとうごさいました。
という事は、アス論系がペンC系に比べて、分岐の多い処理に強いというのは、
ペンCよりスーパースケラー方向である事とは直接関係はないとの理解で良いのでしょうか?
別の言い方をすると、ペンCのパイプが深い事自体が原因ではなくて、
パイプ深い割にはクロックを稼げていない事で、分岐の多い処理
で不利に なっているとの理解で良いすか?

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コンパイルする、と。
x86 → 最適なx86に再コンパイルしてくれるのが一番良いんだが・・・無理な話か。

76 :Socket774:04/04/23 11:06 ID:v2w9JcUV
>>75
いや、だからこその.net frameworkとLongHornなんじゃないか?

77 :Socket774:04/04/23 11:12 ID:bLINDbMj
>>75
通常じゃない場合は拡張命令を自動生成使用してくれるの?

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

趣味だとその辺りの資料が殆どなくて、人間が手動で前処理する場合の
解説は、日本語のネット上だと午後とかまるもが解説してた程度なんで資
料キボンヌ。


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本×2組ある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って
言ってる)の設計理由になってる。
本当は実行回数の重み付けをすべきだと思うけど。(1回しか実行されない関数なら
どうでもいいし、100万回実行される関数なら1個でもがんばって対応した方がいい)

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

AMD64/EM64T(←両方書かないとアム厨って言われちゃう)は「メモリが4GB以上無いと
意味がない」と思ってたけど、レジスタ拡張は意外と性能に効くかもしれない。
AMD64/EM64Tをサポートしたアプリが出てくるのが楽しみだな。

98 :Socket774:04/04/24 02:12 ID:+fw1pIR6
上で1個は紹介したけど、ここ↓にあるAMD3部作と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・・・は無謀かw 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のCPUx10個分にはならない※。

で、>>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
しかもさらっと流し読みした感じ、言ってること正しいし・・・w


166 :Socket774:04/04/26 17:39 ID:odrGp1l3
スカラ

防御魔法のひとつ
仲間1人の守備力を50%上げることができる
使用するとMP(マジックポイント)2ポイント消費される

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の偉業に拍手・・・パチ パチ パチ
こんなもの2ちゃんでしか読めない

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
ついでに紙は別々、といったところかw

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
プレスコは30人が1つのトイレに入れるっつーことだな。

175 :Socket774:04/04/27 14:23 ID:PxKlASst
>>174
という事は最初の一人が早速つまずくと、30人目はそのうち
我慢できなくなってお漏らししてしまう罠(w

CPUもあまり待たされた命令はスキップしてしまったらどうだ
ろうか。(ヲイヲイ)

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 とかわらんような。

インテルが無理に詰めれば子供4人なら同時に便器に座れることを
発見して SSE 命令を作り、最近大人4人も座らせようとしてるが
これはさすがに評判がわるかったり、のような。


185 :Socket774:04/04/29 18:00 ID:8Gb1mD9D
>>184
作った人の意識なんて関係ないけど。

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


あと、車にたとえるのはやめろ。


186 :Socket774:04/04/30 15:48 ID:8NnvVvfM
>>185
ここまできて例えをやめろはないだろうw

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の3倍ぐらいの命令ステップが必要なんだよな

何考えて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
1.MMXをONにする。
2.MMX命令を実行する。
3.MMXをOFFにする。

実装当時は浮動小数レジスタと切り替えだったんで。まあ、命令数が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外部にベクトル演算器つけてた
時とくらべたら、ベクトルレジスタいじるステップが入るんだから
騒ぐほどのもんじゃないだろ。



それよりもだ、余計なレジスタ増えるわモードの保存もしなくちゃだわで、
例外処理発生時のペナルティが痛いンだYO!


204 :Socket774:04/05/10 11:14 ID:6LDexDUM
>>203
その積和の性能が低すぎるんだよSSEは
FPUの1.5倍くらいじゃバカ杉

78 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)