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

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

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

1 :Socket774:04/11/21 21:45:10 ID:2HUks886
前スレ
http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/


2 :Socket774:04/11/21 21:46:51 ID:uzwVTaF3
2

3 :Socket774:04/11/21 21:47:35 ID:2HUks886
前スレ >>1 より

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

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

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

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

4 :Socket774:04/11/21 21:48:12 ID:GHw4v2cq
ぺ4様

5 :うさぎ会長:04/11/21 21:53:03 ID:gXyhp2yg
            ,.-t、,/ _ ̄~~`'ー- 、,  (__
            f  ,l.  ̄r< ̄ >- 、  ` く  l,__
          ,.〜',/ `ー'‐'^ヽ,__j,.ィ_ nヽ  \ ,.゙ヽ
         / / /     ,.    `y' \   ',  )
          ヽ//'// /' / ,.   ノ L._  ヽ  ト、 ,)
.         // / 'ム ノ / /'彡イイ| イ ノ fヾ!  | 'ー,
         l/l l  〃 //' 彡〃 |川.|.了ヽ__!|ヾ |. /{!
.         |从 //-く ム-彡'"二゙!从レ' i |`ー`)ーレ'  _j ポンポコ
      r、r、  |l V/' lr'。!     'スヽ',从 ,!└-- ァ,r=,ゴ      ポーン♪
     ヾヽヽ\. nl 、l゚ソ     /ー'。ミY/ /  ア / |_,ノ    。              |ヽ
      ヾヽヽヽ'、{. ',   .:    ゞニン^'j. / //ノ,! ハ   ー┼‐  ___ ヽ    ._| )
       \\^ `!ヾ、. ヽ‐1       /./ノ  / l. ハ L,  ノ | ヽ       _,ノ   (_|
        ヽ ヽ   }.ヽ, !ノ     |/   ./ l |-! | )
        /.)    ノ、ヽiゝ、、、--‐='7 ノ  ,ノ"7-v'--'く
      、'ー===i. /.  ス、 ( f  ハ.  / / / /   )  \
      /ヾ;、,_ゞ==イ ミ 〈{ 7イ. | ./  / ) l r‐'"     ヽ
.     /   `ー'  |〈 \ | |. | |. | /,ノ 〉 | _j       レ┐
    /      ,イ,〈 ミ、 ゙K、j ,. l | /ノ  Vメ、      ノ- ,ゝ
    /     /)>L>、 {、7゙,、j y'  / く.( )ヽ,    「  _ノ、_
    (      ノ /\ヽ〈ヽ,).l }   //ノ   ヽ _∧,r‐'   `ヽ、

6 :MACオタ:04/11/21 21:59:58 ID:UivSGDNJ
結局>>1じゃx86をマンセーしてるだけなのがイタいんすけど。。。

7 :MACオタ@訂正:04/11/21 22:00:37 ID:UivSGDNJ
上の>>1じゃなくて>>3すか。。。


8 :うさぎ会長:04/11/21 22:04:08 ID:gXyhp2yg
マックおた、きもいよ。

9 :Socket774:04/11/21 23:01:49 ID:M9dOfz9W
フリップフラップ直さなかったのか。
しかし今日のMAXオタ必死だな。

10 :Socket774:04/11/22 06:19:32 ID:nS08Uo9b
なんかここだけ板で浮いてるな
エロくない私にはさっぱり内容がわかんね・・・

11 :Socket774:04/11/22 07:14:44 ID:vI8Sk/JF
>>前スレ911
32bit固定命令長プロセッサでは大抵32レジスタ3オペランド(5bitx3=15bit)
16bit固定命令長プロセッサでは大抵16レジスタ2オペランド(4bitx2=8bit)
どちらも命令長の約半分がオペランドを指定するフィールドで占められているが
その辺何か意味があるのかもしれない。

12 :Socket774:04/11/22 08:10:24 ID:8oLg5JUn
遅いとバカにされるけどSPARCが大好きです♪

13 :Socket774:04/11/22 08:18:56 ID:1fAbwAyv
前スレ前半はSPARC信者が多かった。
が、後半からは何故かx86マンセー野郎が増加して、
さらにMACオタが乱入。

そして、レジスタ数とレジスタ待避のトレードオフという素人には
無謀すぎる話題に突入。

14 :Socket774:04/11/22 08:27:19 ID:1fAbwAyv
で、MACオタはx86 ISAのスケーラビリティの悪さについては
どうおもってるわけよ?

15 :MACオタ>14 さん:04/11/22 17:45:31 ID:285Id57b
>>14
ISA的にわ、ついこないだまで64-bitアドレスをサポートしていなかったという以外、別に問題
無いと思うす。ただ、実装自体わ携帯電話に入るような小さなチップも無く、サーバー用の
ハイエンドチップも無いというのが事実す。

16 :Op使い:04/11/23 01:45:56 ID:xi8/vTjg
前スレの後半見てて思ったけど、
レジスタがありすぎるとコンパイルに時間かかりそう..

#最近、Power5に興味もってきたりして..(^^;

17 :Socket774:04/11/23 02:50:57 ID:tSQJafcQ
>>11

>16bit固定命令長プロセッサでは大抵16レジスタ2オペランド(4bitx2=8bit)

そうか? ARMやMIPSの16bitISAでは8レジスタ3オペランド(3bitx3=9bit)だぞ。

まぁ、いずれにせよレジスタ指定に割り当てられるビット数はその程度が
妥当だろうね。もっとも、思い切ってイミディエイトやディスプレイスメントの
ビット数を削ってしまえば多レジスタISAというのも可能ではある。
例えば128本3オペランド(7bitx3=21bit)なんていうCPUも過去にはあった。
まぁ、自分で命令ビットパターンを考えてみるのもなかなか面白いものではあるよ。


18 :Socket774:04/11/23 03:38:23 ID:qYpOJoCv
>>16
>レジスタがありすぎるとコンパイルに時間かかりそう..
すべてのコンパイラに該当するものではありませんが
GCCでは擬似レジスタが無限にあるものと想定して
コード生成をした後現実のレジスタ,メモリ参照に
変換するという手法をとっていたようなので
レジスタ数が多いことはコンパイラに対して
デメリットにはならないのでは。

>>17
>例えば128本3オペランド(7bitx3=21bit)なんていうCPUも過去にはあった。
Itaniumって既に過去のものなのか......orz


19 :Socket774:04/11/23 11:52:09 ID:Hm+00xLI
>>17
そういえばそうですね。
こちらは32bitMCUの類のネイティブな命令セットをを想定していました<16x2
使い勝手としては16x2のほうが8x3よりよいかと思います。
#8x3のISAはどちらも32bit長命令セットの縮小命令セットであるのは注目すべきでしょう。

20 :Socket774:04/11/23 22:53:50 ID:tSQJafcQ
>>18

Itaniumって32bit命令長だったんだぁ。
# VLIWは全く頭になかったよ。

>>19

確かに8x3は32bitの縮小ですね。
実はMIPS16の命令セットを決めた人間に話を聞いたことがある。
色々と理屈は言っていたが、結局は勘で決めているとしか見えなかったよ。

21 :Socket774:04/11/23 23:34:21 ID:qYpOJoCv
>>20
Itaniumの命令長は41bit長×3+付加情報5bit=128bitです。

>>17が過去に32bit命令長で128レジスタのCPUがあったという
ことでしたらこちらの早とちりです。


22 :17,20:04/11/24 10:07:20 ID:rAqyQNcI
>>21

ご丁寧にすいません。
17で「32bit命令長」って明記しなかった私が悪うございました。
Itaniumのスロットが41bitというのは確認してたのですが、
20ではちょっと遊んでボケてみました。申し訳ないです。
ちなみに、17で書いたのはAm29000のことです。

23 :Socket774:04/11/24 17:50:18 ID:pn/WswmT
Am29000はオペコード、オペランド3つそれぞれ8bitです。
レジスタは192個まで実装されてたんだったかな。

24 :17,20:04/11/25 00:32:35 ID:gL2DuRux
>>23

ガーン、完全に記憶違いでした。ありがとうございます。
少し休養します。

25 :Socket774:04/11/27 13:14:16 ID:5fwPPFwE
877 名前:名無しさん必死だな[] 投稿日:04/11/27 12:50:53 ID:nmcyavCi
日本は猿マネでここまで来たんだよ。結局はアメリカ西洋が無いと
何も出来ないのはペリーが来た頃からわかってただろ。

加工は得意だが発想が無いんだよ。今じゃ製造関係の信用すら無くなった。
今までやってきた事も結局はまねごとじゃん。
コンピューターって物を開発した訳でも無く、コンピューターって物を
遊びに使ったって事で当たっただけであってさ

あっちの評価が上がったのは軍事関係にコンピューターを使ってるから
技術が上がればもの凄い物は作れるんだよ。日本はそれを加工しただけ

26 :Socket774:04/11/27 22:37:55 ID:LYfNsstS
インテルのCPUの産みの親は、日本人ですが、何か。

27 :Socket774:04/11/27 22:47:03 ID:DexpoBAT
インテルの起源は韓国にあり。。。プギャーっと

28 :Socket774:04/11/28 18:18:07 ID:EcNT5VtM
中森章は半可通なので判っていないのはいいとして
http://www.cqpub.co.jp/intrface/toku/2003/200311/toku2.htm
嶋正利まで
「ただ,IBM の失敗は自分の成功に価値を見いださなかったことである.」
なんてことを言っているので失望した。
http://www.ieice.org/jpn/books/kaishikiji/199910/19991001.html

実際はIBMはRISC技術を極めて重要視していたわけだが。
http://www.cs.clemson.edu/~mark/architects.html

29 :Socket774:04/11/28 21:05:50 ID:KOiwSMD3
IBMみたいな超大企業の場合、重要視といっても、本当に重要視されていたのか
わからない見たいな部分があって…。いかんせん重役の数が多すぎて…(笑)

30 :Socket774:04/11/29 03:31:56 ID:PD0Wt7F8
かなり早い時期に手を出していたのは確かだけど結局日の目は見なかったわけで。
持ってるリソースが大きいので片手までやった仕事でもたいした仕事だったというだけの話だと思うね。

31 :Socket774:04/11/29 10:47:11 ID:XoEGDlfe
>>30
中森章登場

32 :Socket774:04/11/29 14:55:36 ID:C8KVE+li
>>28
おせっかいかもしれんが

http://www.cqpub.co.jp/interface/toku/2003/200311/toku2.htm
中森の記事は↑こっちだな。interfaceのeが抜けてる。

この記事は以前本で読んだが、
「紙面が尽きた」とか言ってSHシリーズの文章がなかったのが、
個人的には腑に落ちなかった。

今でこそARMがRISCマイコンの最大勢力かもしれんが、
数年前なら「世界でいちばん売れている32ビットマイコン」とも言われていたらしいSHシリーズ。
何か書けることもあっただろうに…

誰かSHシリーズについて熱い想いを語ってくれる人キボンヌ

33 :Socket774:04/11/29 16:35:55 ID:2CV3J99/
>>32
きちんと評価したわけではないが、あんまり好きではない。

34 :Socket774:04/11/29 17:43:33 ID:cPGo4NHy
>>32

HOTCHIPSか何かで日立が発表したとき、パターソンが
「そいつの何処がRISCな訳?」と突っ込んだってな逸話は有名だな。
確かに純粋RISCの立場からすれば、16bitに圧縮されたコードセットは
邪道でRISCとは言い切れないだろうよ。
だが、その後SparkやMIPSが追従した訳で、受け入れられた訳だが。

そしてセガと共に滅んだ…じゃなくて、結局、現ルネサスもそうだが
SHとH8の棲み分けでかなり悩んでるんだろうな。
さっさとH8を縮小してSHに一本化してた方が良かったと思うんだがねぇ…。

35 :Socket774:04/11/29 18:54:21 ID:PD0Wt7F8
>>32
中森たんはNの人間だから。
Hのプロセッサの話はあまり詳しくないからできなかったというところでないかな。
VR4131の手抜きスーパースカラとか、V850の怪しい話とかは書けるみたいだけど。

36 :Socket774:04/11/29 19:38:27 ID:AKwZ2gwS
>>34
パターソンってそんなドキュンだったんだ。なるほど。
工学にろくな教授がいないことをまたしても証明してしまったな。

37 :Socket774:04/11/29 19:57:47 ID:IgItYhdA
パーシャルレジスタストールってメモリアクセスでも起こるんだな
北森だと30クロックぐらいカラ回り
AthlonXpだと全然平気なのに

38 :Socket774:04/11/29 20:21:06 ID:2CV3J99/
>>37
なんでそんなかかるんだろうね。
AMDにがっつり特許おさえられてるとか?

39 :Socket774:04/11/29 21:26:16 ID:C8KVE+li
>>34
そんな事言ってたんだ。

漏れはSHシリーズは使ったことないんだが、
定数のロードは確かにアレだとオモタ。
て優香、無理して命令コードを16ビット長にしなくても良かったんじゃないのかなあ。

ルネサスの場合、
旧日立のプロセッサだけでなく、旧三菱のプロセッサもあるから、
ホント大変だろうね。

>>35
>>28>>32の中森の文章では、国産のプロセッサは軒並み割愛されてるんだよね。
富士通がSPARCと絡んでるとかは除いて。

御前、それでも日本人かー!!ってオモタヨw

40 :Socket774:04/11/29 23:08:35 ID:5vUievo3
>>39
32bit長命令だとメモリを16bitバスにぶら下げた場合、
フェッチの時間が倍になって、とっても悲しいからのう…

かといって32bitバスにすると基板でかくなってお金がかかるので、
これまた困る。

まああの時代では16bit長つーのがそれなりに最適な選択だったと思うですよ。
問題は互換性のためにそれをひきずりまくった事ではないかと。


41 :Socket774:04/11/29 23:30:58 ID:ayc9vRYd
>>40
命令キャッシュなかったの?

まあコード密度は高かった(MIPS比1.5倍くらい)

ISAはSH5になってかなりマトモというか普通になった。

42 :Socket774:04/11/30 00:05:28 ID:HfGMv9PV
>>36
SYMBOLだのレジスタウィンドウだのロクな発明してないしな。

マトモなのはRAIDくらいなもんか?

43 :Socket774:04/11/30 03:27:17 ID:tPaXcyDA
SHはコード密度優先でキャッシュも少ない量しか搭載してない…。
っていうかダイサイズや消費電力を減らすためにそうなってる訳だが。
逆にキャッシュの効きは良いんだから、沢山積めば良いのにとも思う訳だが、
絶対性能を求めるようなもんでも無かった訳で…。

まぁそういうプロセッサだからMIPSや(Thumb無し)ARMとは趣が違う…。

44 :Socket774:04/11/30 06:46:29 ID:6S9OFngO
>>34
H8は小ロットとアマチュアの強い味方です。やめないで。

45 :Socket774:04/11/30 08:29:20 ID:y7FKGhY5
Cellは4.6GHzで動作 - ISSCC2005の開催概要が明らかに
http://pcweb.mycom.co.jp/news/2004/11/29/011.html

>>44
はげどう。ただ個々のチップのライフサイクルは短いような
気がする。もうちょっとラインナップを整理してほしい。

46 :Socket774:04/11/30 12:35:02 ID:tPaXcyDA
>>44

ただ単に、フラッシュ内蔵したH8ピンコンパチで焼き方も
一緒で安価なSHが出てくりゃ良いだけの事だ罠。

47 :Socket774:04/11/30 18:40:48 ID:+WLIdXE1
フラッシュ内蔵したH8ピンコンパチで焼き方も
一緒で安価なItaniumが出てきたらどうしますか。

48 :Socket774:04/11/30 19:54:50 ID:wwqlsrSa
>>47
コードデンシティが低いし、自分でバンドルをつめるのも面倒だから嫌。


49 :Socket774:04/12/01 21:34:08 ID:0BB4e3rB
>>48
そしてIA64-16が

50 :Socket774:04/12/03 21:13:14 ID:5vYLW2xV
あはは

ほんとにオープンアーキ化しちゃうのね
http://power.org/

51 :Socket774:04/12/03 23:40:23 ID:nEj1Tdb4
自分らの実装能力に絶対の自信があるっていう意味だろうなあ

52 :Socket774:04/12/14 04:19:40 ID:5c7i4jnp
「遅延スロット」ってRISC系CPUで主に実装されているんですか?

53 :Socket774:04/12/14 22:54:45 ID:GWYZv8mL
遅延かーサターンのPAR弄ってたときに勉強したな。
RISCアーキ出る前には既にあった。
目新しい技術ではないです。

えーと、コンパイラにコード吐かせると遅延有効活用できないときはNOP入れられるんだっけ?
ウロオボエンガー

54 :Socket774:04/12/14 23:12:11 ID:dJc2kTqU
ウホッ、久しぶりのカキコw
みんなどうしたのかと思ったyo!
て優香、みんなもっと書き込みщ(゚Д゚щ)カモォォォン!!!

…っていうくらいなら自分で書き込めよ、ってオモタ('A`)

「遅延スロット」っていうのは、
RISCというよりパイプライン構造のプロセッサに関係のある概念だな。
まあ通常、RISCプロセッサ=パイプライン構造なんで、
RISCに関する書籍とかを読んでれば自然と出てくる言葉だけどね。

55 :あってる?:04/12/15 04:27:09 ID:V1fHRb0d
>>52
実装というか副作用というか
分岐ステージ分割して高速化狙いしたCPUだと
分岐条件成立がわかるまでに分岐命令直後の命令が(分岐するから本当なら後の命令なんか実行する必要がない場合でも)パイプラインを抜けちゃう(=実行完了)

何も考えないでインラインアセンブラ組むと誤動作の原因になる
分岐命令直後にNOP詰めとけば間違いないけどそれじゃ性能上がらないんで問題ない命令を何とか詰め込む
まぁコンパイラの方がうまかったりするけどw

56 :Socket774:04/12/15 20:45:37 ID:KBDIg/YO
盲腸だな。

57 :Socket774:04/12/15 21:34:49 ID:HEe63dcd
RISCは CPUとコンパイラがピッタリ協調して 初めて意味がある。
なのに、バイナリコンパチとか言い出した時から、RISCはRISCでなくなったね。

58 :Socket774:04/12/16 06:12:56 ID:akKGXhup
CPUのOOOって凄いね。

PalominoコアのAthlonを相手に、コードの最適化やってるんだけど、
手で命令の順序を入れ換えてあげても、処理速度が変らない。
つまり、すでにCPUのOOOが適切に入れ換えてくれてた、ということ。

まぁ、漏れの技術力がないだけなのかもしれないけどね・・・・

59 :Socket774:04/12/16 11:00:06 ID:rk7dDlBe
>>58
Intel系でやってみそ
実行ユニットもデコーダも中途半端だからNOPはさんだ方が速くなったりするぞ
NetBurstになるとストールしまくるのでフラグを使った小細工は禁止

60 :Socket774:04/12/16 17:21:15 ID:dFqLIY8J
>>58
AMDからダウソできる CodeAnalyst は、使ってみた?

61 :58:04/12/16 22:31:51 ID:akKGXhup
>>59
Pentium4で走らせてみたらびっくりしましたよ。

Athlonで、
A1→A2→A3→B1→B2→B3
というような処理(それぞれ前段の処理結果を使うので並列に処理できない)を、
命令単位で細かくやったりせず、C言語で数行ごとに切替えるだけで、
A1→B1→A2→B2→A3→B3
のように並べ替えたら、処理時間が62%に縮まりました。
ところがPentium4では、116%に延びてしまいました。

MMXを使った部分では同じコードの調整で、
Athlonで88%に縮まったのに対して、Pentium4では72%にまで縮まりました。

インテルのCPUは、ちゃんとスケジューリングしてあげないといけないんですね。
Pentium4はまだいいほうで、Itaniumに至ってはコンパイラの性能差出過ぎですよ。

>>60
使ってないです。
インテルのVTuneに相当するものがあるのですか。しかもフリーですか。素晴らしすぎる。
ありがとうございます。試してみます。

いまはVC++用のプロファイラを使って当たりを付けて、処理時間を測りながら試行錯誤してます。
インテルとAMDのドキュメントに書かれている、パフォーマンス上の注意点の多さと、
自分で書くよりも、コンパイラに任せたほうが結果が良かったりして、凹んでいたところです。

62 :Socket774:04/12/16 23:59:54 ID:yun3hOMM
ItaniumはVLIWなのでコンパイラで性能差が出まくるのはしゃーない

63 :Socket774:04/12/17 02:40:59 ID:jVgBWPiT
Itanium2に最適化してると、ただでさえ遅いItaniumは、さらに若干遅くなるんだよね。
そういう宿命なんだけど、なんだかさみしくなる。

64 :Socket774:04/12/18 20:17:19 ID:Cq4vwZkE
HPはItanium共同開発から撤退らしいし…。


65 :Socket774:04/12/19 15:09:05 ID:5Rpk3xqZ
Longhornが予定通り出れば.netが普及するからチャンスがあるが、
このままだと消えてゆく運命かもな・・・Itanium/2

66 :Socket774:04/12/19 17:08:20 ID:dhza31VC
.netとItaniumとどういう関係が?

67 :Socket774:04/12/19 20:17:45 ID:dpJQftSS
全面的に.net化すると、OS以外はCPUアーキテクチャから独立するから。

68 :Socket774:04/12/20 13:28:12 ID:mDtQlZMl
>>66
おまい、自分の興味ある記事しか見ないタイプだろ。

69 :60:04/12/21 13:34:16 ID:7tCq/vEC
>>61
何を作ってるかはあえて聞かないが
手でスケジューリングは、涅槃が待っているのでがんがれ。

70 :58:04/12/21 21:43:20 ID:6sXn4cAW
>>60
CodeAnalystを試してみました。

速く走るコードはパイプラインが整然と流れていて美しかったです。
もうこれ以上速くはならないよ、ということを突きつけられたのでもあるのだけど。

少し遅いコードでも、ストールしまくってるわけではなく、手でスケジューリングする余地はないように見えました。

インテルもこういうツールをフリーで出してくれればいいのに。
NetBurstのパイプラインストールが激しいのを見てみたいです。

71 :Socket774:04/12/21 23:32:49 ID:/lvy1TZp
>>68
そうでもない。
レス返さなかったのは、スレ違いだと思ったから。
# OSやJava,Ruby,.netの話しても詰まんないでしょ。

72 :Socket774:04/12/22 00:09:07 ID:Katp9BdD
>>60>>70
私も早速DLして試してみました。CodeAnalyst。
所々パイプラインが切れているのは、Br mispredictやBank Conflictです。
L1データキャッシュはセット・アソシエイティブ数が少ないので、L2からの再ロードが
ここで起きているようです。L2でもバンクがぶつかった場合はメモリからロードするので、
相当ストールがかかっていますが、これは極たまにです。

Br mispredictは初回のCALLや、条件分岐で起きていますが、後の方に行くと
学習してしまい、CALLされてもパイプラインが途切れていません。

それにしてもAthlonのパイプラインは優秀です。クロック数が低くても速度が速い理由
が一目瞭然です。

73 :Socket774:04/12/22 00:21:27 ID:Katp9BdD
しかし、x86 FPUを使ったら赤枠にピンクのストールだらけ!さすがに厳しいか・・・・
x86 FPUはRISC FPUに比べて性能が悪い傾向がありますが、これはXMMでも
使えば少しは改善されるのでしょうか。

74 :Socket774:04/12/22 00:54:13 ID:qQtY6n6I
>>70
>NetBurstのパイプラインストールが激しいのを見てみたいです。
プのストールを想像するとハァハァ
それにしてもなんでこんなCPUが開発できたんだろ

75 :Socket774:04/12/22 01:06:12 ID:hE+LsD90
http://pc.watch.impress.co.jp/docs/2004/1221/kaigai143.htm

本文二行目・・・

ん?PenMの開発ネームは何だって?w

76 :Socket774:04/12/22 07:21:55 ID:GV3eNjEw
ドタンだと問題でも?

77 :Socket774:04/12/22 15:30:38 ID:rfl26WIM
http://www.merriam-webster.com/cgi-bin/dictionary?book=Dictionary&va=Dothan&x=27&y=19

78 :Socket774:04/12/22 16:18:46 ID:KMaNCYpM
thの音に対する日本語表記はしょうがねぇじゃん。
ドタンでもドサンでもお好きなように。


79 :Socket774:04/12/22 19:01:54 ID:Katp9BdD
土炭

80 :Socket774:04/12/22 19:26:21 ID:p6xjsn/P
弩タン・・・

81 :Socket774:04/12/23 01:13:14 ID:jpYo8+9o
土産?(違

82 :Socket774:04/12/23 01:45:32 ID:6TF54xuU
いまさらぶり返すようなネタか?>Dothan

83 :Socket774:04/12/23 02:11:18 ID:GO8Z7CeH
ドウサンだと思ってた。つかアーキの話か?これ。

84 :Socket774:04/12/23 02:42:18 ID:NpZXFRys
まあいいや。

それはともかくインテルのPARROTってどうよ。
俺はもうイリノイの連中のタワ言を信じるのはやめるべきだと思うのだが。

85 :Socket774:04/12/23 04:51:51 ID:6TF54xuU
PARROTは後藤たんの記事を読んだだけだけど、
現在の技術の流れからいっても
まあ妥当なテクノロジだと思ったよ。
記事を読んだら0.1秒でtransmetaの朴李だと分かったけどw

て優香、イリノイってなんか悪い噂があるの?

86 :Socket774:04/12/23 10:13:23 ID:GC04LHy6
AMDをパクったあとはトランスメタでつか。
Intelもプライドってもんが無くなってきたなぁ。ブランドは技術に裏付けされたプライドと努力から
生まれるもんだと思うが・・・('A`)

87 :Socket774:04/12/23 14:13:19 ID:xhdoZgC7
プライドがあったらプなんて出てこんだろ
31段スーパーストールアーキテクチャ

88 :Socket774:04/12/23 14:49:02 ID:hjDFgQpX
CodeAnalystを使ってみたいから、AMDベースのマシン組みたくなってきた。

89 :Socket774:04/12/23 17:20:48 ID:NpZXFRys
ホットスポットに最適化したアーキテクチャは、うまくいけば
たしかに性能はいいのだが、外乱(割り込みとか)に弱いのよ。

論文でやってるような性能評価はアプリケーションレベルの
シミュレーションなので、外乱が一切ない状況なので、
実際は論文のようにうまくいかないことは、すでにPentium4と
Itaniumで懲りたんじゃないのかと小一時間。。


90 :Socket774:04/12/27 00:16:10 ID:Ro24r0cI
>>86
パクリメーカはAMDだろ。
編厨にはIntelの技術は何でもパクリにみえるんだね。
編厨の脳みそのエラッタ誰か改善してくれ。

91 :Socket774:04/12/27 00:42:42 ID:Ro24r0cI
PARROTはTransmetaのアーキに似てはいるが、
技術的トレンドから言って、Transmetaと似たようなものになってしまった
と見るのだ妥当だと思われ。
これはP6とNexGen開発時期が重なっていて同じようなアーキに
落ち着いた状況と似ている。

それからイリノイじゃなくてイスラエルチームの技術なんだけどね。
ちゃんと論文見て確認してくれ。

92 :Socket774:04/12/27 01:01:10 ID:Ro24r0cI
実はこの手の動的コード最適化技術は、盛んに研究されていて
特にいちはやく目をつけていたのはTransmetaではなく、実はIBM(1997)。
ttp://www.research.ibm.com/vliw/isca31/Daisy%20-%20Dynamic%20Compilation%20For%20100%20percent%20Architectural%20Compatibility.pdf

マイクロアーキの開発にはそのときどきのトレンドってものがあって、
動的コード最適化やトレースキャッシュ系の技術は最近さかんに研究されている
分野のひとつで、IntelのPARROTもそのトレンドにのったもの。

すぐに"パクリ"という表現で片付ける香具師はまったくこの分野のトレンド
がわかってないと思う。

93 :Socket774:04/12/27 14:32:00 ID:NbqIW9XY
だからPARROTはイリノイのrePlayその他が元になってるんだってば。
http://www.cs.ucsd.edu/users/calder/classes/spring04/240B/papers/PARROT-ISCA04.pdf
ほれ。

94 :Socket774:04/12/27 15:15:13 ID:LnMMFek3
>>90
IntelとAMDはアーキテクチャ分野で技術提携してますが
拡張アーキテクチャの相互利用、相互開発でしょ。

95 :Socket774:04/12/27 18:59:44 ID:Tm1XnSq7
故・ノイマン博士>>>>越えられない壁>>>>CPUベンダ

これ定説。

96 :Socket774:04/12/27 23:19:07 ID:F14fk8x3
>>89にも書いたが、
インテルはprecise interruptをどうやって実装するつもりなんだ。
特許ネタだから出てこんのか。

97 :Socket774:04/12/28 01:26:32 ID:LvfgMejP
>>96
DaisyやらCrusoeやらが採用している方法では
問題があるんですか?

98 :Socket774:04/12/28 18:37:52 ID:vEjDIYkw
>>91
まぁ最適化がおまけだとするとwww
エミュレータをソフト〜ハードのどこに実装するかではあるよね

ソフトだけ:
OS組み込みで完全にソフトでやるのが
PPCで68kコードのMacOSとか
Itaniumでx86実行するIA-32EL(Itanium自体にx86ハードエミュもあるけど早くも互換性のためだけ?)

ソフト+ちょっとハード:
OSからもBIOSからもただのx86互換チップにしか見えない(Transmeta以外はVLIWコードを直接走らせることはできない)
けれどCMS=ソフトでx86エミュレート(?)してるクルーソー・エフィシオン

ハード(+ほんの少しソフト?)
PARROT? リコンフィギュアラブルが最近の流行だから
ある意味でソフト的な要素ってことになるのかな?

99 :Socket774:04/12/28 18:50:47 ID:vEjDIYkw
>>95
故・ノイマン博士 ってフォン・ノイマンのこと?
EDSACの論理担当をやってただけなのに
(すでにノイマンは高名な数学者だったのでプロジェクトの箔付けの意味で開発してた大学の意向?)実装担当者が考えたプログラム内蔵方式(いわゆるノイマン式)を
自分の名前で研究発表しちゃったもんだから実装担当者は怒ってプロジェクトやめちゃったらしいよ

100 :Socket774:04/12/29 00:30:51 ID:QPBpOjIX
エビのうんこたれ

101 :Socket774:04/12/29 02:56:46 ID:rg3FfbST
>>99
そんなのどこでも聞く話じゃないか(涙

102 :Socket774:04/12/29 06:08:34 ID:InW08WYh
>>93
その論文の具体的にどこがイリノイのが元になってるのか?
無理に自分の意見押し通そうとするなよ。

103 :Socket774:04/12/29 14:46:09 ID:QPBpOjIX
>>102
2ページ目のおわりのほうに
Our results complement and strengthen the rePlay study
showing the significant contribution of dynamic optimizations
to IA-32 based processors.
(略)
とあるだろうが。

英語読めないんなら言ってくれ。翻訳してやるから。

104 :Socket774:04/12/29 15:09:01 ID:InW08WYh
>>103
結構だが、それで>>84がイリノイ大学の論文は信用できないって言う理由は何故
なんだろうか?

105 :Socket774:04/12/30 09:44:12 ID:1h2GwW+E
プロセッサの性能向上には
1.性能が出ない場合をなんとかカバーする
2.もともと性能が出ているところをさらに速くする
と二通りの方向性があって、victim cacheなんかは1なんだけど、
イリノイ大の研究はほとんどが2なのよ。

rePLayとかPARROTみたいなトレースの最適化が有効になるためには
そもそもトレースキャッシュのヒット率が高くないといけないわけだが、
論文でやってるようなアプリケーションレベルの性能評価環境に比べて、
実機は割り込みやらコンテクストスイッチやらがあるので
同じ容量でもヒット率は(俺感覚では、かなり)下がる→
思ったほど性能が出ない、という破目になる。

もっとも実環境での性能評価は大学レベルでは極めて難しいので仕方がない
のではあるのだが、それはいいとして、
どうもネタが最大限有効になるようなパラメータチューニングやってるっぽい。

というわけで、論文にでている性能評価を鵜呑みにするのは危険じゃねーの。

106 :Socket774:04/12/30 15:16:03 ID:CrjJUiah
その「俺感覚」について詳しく。
割り込みの影響なんて、たいして効かないと思ってた。

107 :Socket774:04/12/30 20:53:48 ID:kWYdBiJt
>>106

105ではないけれど、論文発表だと大抵のキャッシュヒット率は90%台にのせてるのだな。
で、例えキャッシュを倍にしても、少なくとも数字の上では数パーセントもヒット率は
変化しないんだ、これが。

ところが、実際にキャッシュが増大されたCPUを使ってみると…
体感出来るぐらいには変化しちゃうんだなぁ…(^^;;;

108 :Socket774:04/12/30 21:02:47 ID:CrjJUiah
90%台のHit率が数%変わったら大違いだと思うよ。
Miss率で考えたら分かる。

109 :Socket774:04/12/30 21:10:23 ID:1h2GwW+E
Rotenbergの論文
http://www.tinker.ncsu.edu/ericro/UW/papers/TC_micro29.pdf
の最後のほうにも出ているが、トレースキャッシュは一般的にヒット率が低い。
理由は、本文2.2に出ているが
Specifically, a trace cache hit requires that
(1) the fetch address match the tag and
(2) the branch predictions match the branch flags.
ついでに、トレースキャッシュは同じアドレスの命令を複数ラインに
コピーするため、実効的な容量はさらに減る。

ところで、割り込みが起きると普通のキャッシュと同様に有効なキャッシュ
ラインが追い出されるが、実は分岐予測テーブルのほうも分岐履歴が乱され、
予測率が低下する。
トレースキャッシュの場合は、2があるので普通のキャッシュに比べさらに
不利になるわけ。

110 :Socket774:04/12/30 22:37:42 ID:aN/iCZ2/
キャッシュって何msecも保持し続けないと効果が薄いなんてことはないと思う。

毎秒1万回、コンテキストスイッチする場合でも、
1GHzのCPUなら0.1msecに100kクロックもある。

それにコンテキストスイッチしなくても、
同一コンテキストでキャッシュから追い出したりすることもある。

111 :Socket774:04/12/31 14:47:55 ID:qkmwWzDS
パーシャル・パイプラインストールって何?おしえてprz

112 :Socket774:04/12/31 15:06:27 ID:Q8PsfqlS
>>111
まじめに作るのめんどくせーし、誰も使ってなさそうだから適当に作っちゃえ、
ってこと。細かいことを飛ばすとそういうことだ。

113 :111:04/12/31 15:46:12 ID:qkmwWzDS
>>112
細かいこともよろしく(うまくググれないんで)

114 :Socket774:04/12/31 17:41:31 ID:Q8PsfqlS
>>113
パーシャル・ストール
パーシャル・レジスタ・ストール
パーシャル・フラグ・ストール
パーシャル・メモリ・ストール

ググれたけど。要するにレジスタをつなげた時のために、まじめに(ry


115 :Socket774:04/12/31 18:46:30 ID:qkmwWzDS
>>114Thanks

どうも「パーシャル・パイプラインストール」では中心をついてなかったようです(´・ω・`)ショボーン
パイプライン全体っていうよりも主に演算ユニット関係みたいですし

116 :あけおめ:05/01/07 01:52:52 ID:PHKtVMq8
バイトコード直接実行型JAVAチップとか(FPUだけど)x87とか
昔一時スタック構造レジスタ・アーキテクチャがなんで流行したの?
今からするとわざわざ(偽)依存性作ってるだけにしか思えないんだけど
メリットくわしく教えてprz

117 :Socket774:05/01/07 02:27:32 ID:euve/a5b
>>116

スタックマシンに関してはちょっと調べれば一杯出てくると思うけど…。
っていうか逆ポーランド記法との相性が良くてコンパイラの設計がしやすいって
のが古典スタックマシンでの最大のメリットだったような…。
スタック操作は基本操作の一つな訳で、関数コールなんかでも頻繁に登場したり
する訳だから、ネイティブで操作できるってのは大きなメリットになりうる。
forthなんて専門に扱える言語もある訳だし。後でデメリットも判明した訳だが。

で、x87やJAVAはその手の流行からは後の話で、そういう都合では無いだろう。

x87は命令コードの節約とか色々な都合からそうなってるんだと思うね。
JAVAバイトコードに関しては当初から色々と言われているけど。
なんかの学会でパターソンだかが「なんで今更スタックマシン?x86ネイティブ
コードの方が良い。なんたって十分普及してる〜」と突っ込んだらしいぞ(笑)
正直JAVAは設計者の趣味でそうなってるんだと思う訳だが(^^;

118 :Socket774:05/01/07 04:22:26 ID:PHKtVMq8
>>117THX
なるほろ

119 :Socket774:05/01/07 10:52:48 ID:Zs1yttfw
Javaのバイトコードがスタックマシンになっている理由は
・コード密度
・検証のしやすさ
・スタックマシンのほうが性能のよいインタプリタが実装可能
ってところ。

年寄りはひっこめってカンジ>パターソン

120 :Socket774:05/01/07 20:55:08 ID:HGzA2hK+
ハードで実装するときは高速化が難しいんだけどね<スタックマシン


121 :Socket774:05/01/07 21:27:42 ID:J8BhqoX0
時代が違うからね。CPUにパイプラインもスーパースケーラも実装されてなく、
メモリアクセスがノーウェイトだった頃は十分に存在意義があったと思う。

122 :Socket774:05/01/07 21:47:11 ID:29DTjhte
そういやJAVAは、最初はアプレットで売り出したんだよな。
コード密度は重要な気がする。

Sunの奴らはFORTH大好きだからスタックマシンになったんじゃないのか…

123 :Socket774:05/01/07 22:37:49 ID:Zs1yttfw
トロンチップをスタックマシンにしたかったが産業界から猛反発を食った坂村さん

124 :Socket774:05/01/08 00:01:51 ID:UA5T6RIA
それはともかく、今日日ヘネパタは教科書としては二流だな。
読まなくていいよあんなの。

125 :Socket774:05/01/08 00:33:33 ID:bolYybsj
じゃあパタヘネは?

126 :Socket774:05/01/08 00:51:10 ID:UA5T6RIA
パタヘネは学部向けとしてはわりといい本だと思う。

127 :Socket774:05/01/08 01:53:18 ID:UA5T6RIA
http://www.amazon.com/exec/obidos/tg/detail/-/0072829680/qid=1105116635/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
http://www.amazon.com/exec/obidos/tg/detail/-/0818684003/qid=1105116664/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
この2冊が今のベストだと思う。

128 :Socket774:05/01/08 04:58:04 ID:dpxcTJV2
英語の勉強のために、表紙に白地にそろばんが書かれている本を古本で買いました。
再生紙に、しょぼい装丁、いまどきMIPS R2000/3000かよ、でも500円なら英語の勉強には安いな、と。

読んでみてビックリ。
こりゃ面白い。
結局、英語の勉強にはなりませんでしたが・・・。

129 :Socket774:05/01/08 17:19:41 ID:UA5T6RIA
http://computer-refuge.org/bitsavers/cdc/DesignOfAComputer_CDC6600.pdf

130 :Socket774:05/01/08 19:05:09 ID:UA5T6RIA
あとはまあ、これでも読んどけ
http://www.amazon.co.jp/exec/obidos/ASIN/4331506231/qid%3D1105178689/250-6820354-3087400

131 :Socket774:05/01/08 20:05:16 ID:UA5T6RIA
これはどうよ。
http://www.amazon.com/exec/obidos/tg/detail/-/0201105578/qid=1105182149/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
俺んとこにはまだきてないが、Blaauwはわりと神。

132 :128:05/01/08 20:55:55 ID:dpxcTJV2
漏れが読んだのはパタヘネの1st editionだったのかな・・・

amazonにある、2nd editionや3rd editionとも表紙が違うから。

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

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

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