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

「おしっこをして手をあらってでてくる」。
トイレが一室しかないと混雑時は長蛇の列ができます。

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

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

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

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

7ステージに分解すると、なんと 7人が同時に処理できます。
これがパイプラインです。

トイレの利用はおしっこだけではありません。
うんこもします。どういう手順でしょうか。

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

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

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

これがスーパスケーラです。

うんこする時間と、ズボンとパンツを脱ぐ時間は同じでしょうか。
いいえ、うんこする時間のほうが圧倒的に長いです。

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

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

パイプラインは、一ステージ毎タイミングを合わせて処理をします。
一番時間がかかる処理は、例では60秒ですから、トイレにはいってから出てくる
まで60秒x8回、480秒の時間がかかります。

ちょっと発想を広げ、時間のかかる処理を分解してみましょう。

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秒ですね。
前より早く処理が完了しました。しかしクロックが倍になったけどトイレに
かかる時間は半分にはなりません。

これが、スーパパイプラインです。

あなたは今、これから迎えるであろう至福の時を迎える為にパンツをおろし、
あとは出すだけという所です。しかし！あろうことか神の声が轟きます。

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

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

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

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

その分、女子トイレの利用率は下がります。
これがハザードです。

トイレの危険はまだまだいっぱいあります。
トイレットペーパーが無くなったらどうでしょうか。尻を拭くことが出来ず、
それ以降のステージは凍結してしまいます。

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

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

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

そう思うでしょう？

トイレが汚いとあまり気持ち言いものじゃありません。
知った人が前にすましてたら、そのトイレがきれいかどうか聞いてみるといい
ですね。でも、その人がトイレから出てくるまで聞けませんから、待ってる事に
なります。

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

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

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

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

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

これが依存関係です。

そこで、トイレがきれいか同か聞かなくてもいい人を先に通してみると
どうでしょう。どうせあなたは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秒後には全員でてきています。

処理を入れ換えてあげると、トイレの利用率はあがり全体の処理時間が短縮
されることがあります。これがリオーダです。

大勢が素早く滞り無く気持ちよくなる工夫はいろいろあります。

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


とここまで書いておいて、トイレを流すのを忘れていたことに気がつきました。
くさいです。ちゃんと流しましょう。

ﾜﾛﾀ
他にまともなたとえはないのか・・・

しかもさらっと流し読みした感じ、言ってること正しいし・・・ｗ

スカラ

防御魔法のひとつ
仲間１人の守備力を５０％上げることができる
使用するとMP（マジックポイント）２ポイント消費される

俺もクチを突っ込もうとして、ざっと読んだ感じでは一箇所も破綻が無いのに感心した。

もう少し人に気軽に見せられる例えか、萌えられる例えだったら友人に見せたいくらいだw

>>150
それをえらい良い効率でやっているのがHTその他なんだな。
すでにアウトオブオーダ出来てるんで大した物量かけずにね。

固定でコンテキストを切り替えるのは前にも書いたけどネットワーク
プロセッサで使ってるのがある。スループット重視でレイテンシはあ
きらめるわけだな。

HT は入口は別々でも中では一つの便器しかない男女兼用トイレみたいなものか。

B6tZVOSSの偉業に拍手・・・ﾊﾟﾁ ﾊﾟﾁ ﾊﾟﾁ
こんなもの２ちゃんでしか読めない

　　　　彡ミミミヽ ﾉ彡ミミ)
　　　((彡ミミミミ))彡彡)))彡)
　　　彡彡ﾞﾞﾞﾞﾞ"ﾞﾞ""""""ヾ彡彡)
　　　ﾐ彡ﾞ　　　　　　　 　 ﾐﾐミ彡
　　((ミ彡 jニﾆｺ　iﾆニｺ. ,|ミミ))
　　ミ彡　 fｴ:ｴi　　 fｴｴ) .|ﾐミ彡
　　ミ彡|　　） ）　| |　｀（ （　|ﾐ彡
　 ((ﾐ彡| 　（ （　-し｀)　） ）|ﾐﾐミ　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　 ゞ|　 ） ）　 ､,!　」（ (　|ソ　　　＜　B6tZVOSSよ 感動したぞ
　　　　　ヽ（ （￣￣￣' ) ）/　　　　 　＼＿＿＿＿＿＿＿＿＿＿
　　　　　,.|＼､)　 　　' ( ／|､　
　　￣￣| ｀＼.`──'´／ |￣￣｀
　　　　　 ＼　~＼,,／~　 /
　　　　　　　＼／▽＼／

>>169
ついでに紙は別々、といったところかｗ

米新興メーカー、稼働中に新命令を追加できるチップを開発
http://japan.cnet.com/news/ent/story/0,2000047623,20065688,00.htm
どうですか？

プレスコは３０人が１つのトイレに入れるっつーことだな。

>>174
という事は最初の一人が早速つまずくと、３０人目はそのうち
我慢できなくなってお漏らししてしまう罠（ｗ

ＣＰＵもあまり待たされた命令はスキップしてしまったらどうだ
ろうか。（ヲイヲイ）

P6 はオシリからうんこの頭が見えた人からトイレに入るように
改良した。これがアウトオブオーダだよ。

>>174
ﾌﾟﾚｽｺｯﾄ、というより、NetBurstの偉大な点は、排泄行為をまったく別のものに
置き換えた点にあります。

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

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

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

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

NetBurstにおける目的はあくまで体内から尿毒素を排出することにあり、
効率的に排出できるのであれば、それは目的に対し完全な勝利だからです。

>>177

それでも昔ながらのやり方が好きな人の為に普通の便器も置いてあって
実はそっちの方が人気があるのは秘密だよ．

話の途中でスマンが、
アホな漏れにはSIMDとベクトルプロセッサの違いがわからん。
どちらも複数のデータを同時に処理するぐらいにしか書かれてない。
この二つの違いを教えて>エロイ人。

あとDSPとかゆう物について
漏れは今持ってるサターンについてるらしいことしか知らんが
決まった計算しかしない代わりに高速と聞いてる。
これは単にクロックが高いのか、それともSIMDみたく複数のデータを同時に処理できるからなのか
どっちなんだ。

ベクトルプロセッサはSIMDの特殊系っていうか一部。

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

DSPは、ある入力に対し一意に出力が決まるという条件で特化されたもの。
別にSIMDでなくてもいい。極端な話、メモリ素子で構成できる:-)

DSP=マイコンと考えて問題ない。少なくとも今は。
メーカーがそういう名前で読んでるから。別にPCのCPUと比べて速いわけ
ではない。

>180
>181
サンクス。
SIMDとベクトルプロセッサは元は同じなのね。
自動車に例えるなら普通車がスカラプロセッサ、
サーキットしか走らんF3000がSIMDで
F1マシンがベクトルプロセッサってとこか。

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

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



ま、こんな夜中にレスありがと！。

>>182
なんか違う。
SIMDの実装の一つがベクトルプロセッサ。
例えるならレースマシンがSIMDでF1マシンがベクトル。


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


ついでに外から見て固定の機能を持ってるかどうかと内部の実装はあまり関係ない。
たとえばキーボードはCPU（マイコン）入ってるけど固定の機能しかしないのと同じ。

クレイは別に SIMD とか意識して作ったわけではないので
分類方法としてあまりふさわしくないような。
SIMD っていう用語が人気なのは MMX命令のおかげ？

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

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

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

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

>>184
作った人の意識なんて関係ないけど。

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


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

>>185
ここまできて例えをやめろはないだろうｗ

SIMDがトイレで、ベクトルが和式便器みたいなもんか。

>>186
dirty na tatoe ha YAMERO

実際にプログラム組むと普通のDSPの３倍ぐらいの命令ステップが必要なんだよな

何考えてSSEやMMXのアーキテクチャ決めてるんだか

>>186
SISD/SIMD/MIMDはFlynnによる分類で、ベクトルはSIMDになる。
この分類法が適切かどうかは別だが、この分類によればSIMD以外に成り得ない。

SIMDが便器で、ベクトルが和式便器と言うべきだろう。

>>188
汎用性

>>190
MPEGとか3D処理とかじゃないの？ MMXの頃はそんなことを言っていたような気がする。

>>188
3倍かかったプログラムってどんな処理？

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といえば
この辺が比較対象になるといえよう
あとのはちょっとアレ

PC向けCPUじゃなくてすまんが、EmotionEngineはVUに14個浮動少数点
演算器があるけどあの演算器全てに効率よく命令を送れるの？
VU同様Vliwアーキテクチャのia64でもコンパイラによる命令の並列化には
限度があるというし。

ここはハイレベルなインターネットですね。

>>193
送れるか？でなくて送れるようなアプリを多用するからそのようなアーキになる。
IA64の問題は、こちらの方がアプリの幅が広いと言う事だな。

>>191
１．ＭＭＸをＯＮにする。
２．ＭＭＸ命令を実行する。
３．ＭＭＸをＯＦＦにする。

実装当時は浮動小数レジスタと切り替えだったんで。まあ、命令数が3倍になるわけじゃないが
ロクでもないのは確か。 割り込み絡めばもうパフォーマンスの低下は必至なわけで。

MMXの最大の欠点は固定小数点で1.0を表現できないこと
SSE,SSE2,SSE3の最大の欠点はベクトル処理が加減算しかできないこと

>>197
＞ベクトル処理が加減算しかできないこと

mulps、divps・・・

>>197
おまい固定小数点知らないだろ。

ここは話が難しいねえ

SSEを誉めるヤツ＝＝アセンブラでSSEコードを書いたこと無いヤツ

>>201
コンパイラで性能がでれば良いのです。

…どういうふうに嫌なのか書いてくれないと話がつながらない。

そろそろあげとくか…。

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

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



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

>>203
その積和の性能が低すぎるんだよSSEは
FPUの１．５倍くらいじゃバカ杉

>>196
ON（？）にする命令なんかねーぞｗ

ここ好きなんでAge

>>203
DX5.0以前ならMMXの使い道もいろいろあったけど、いまじゃな・・・。
サウンドとムービーエンコードくらいか？

>>205
あれ、そのままレジスタ叩いたら使えるんだっけか。FloatとMMXの切り替え命令が
あったと思ってたけど勘違いかな。

>>207
OFFにする時のみEMMS命令を実行だったかも。

拡張命令云々よりもCPU自体、コンピューターの中では
一個の演算ユニット何だから色々と騒いでもしょうがない。

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

特に重い処理の大半が遅い大半がメモリー関係だと思うし、
FSBを現行４倍以上にし、メモリーも32GBぐらいにしないと
CPUは遊んでいる状態だと言ってみる。
・・・・ただし、それを上げる方がCPU性能上げるより遥かに面倒と言う罠

>>209
ちと、無い物ねだり杉

メモリの量は処理内容によって変わりすぎるからあれだけど、
バス幅はほんとにイタイよね。

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

たとえばだけど、アドレスレジスタ毎に異なるメモリバスが存在していたら
どうだ？利用データによってメモリセットを選択できれば、今ほどのバス幅
は要求しなくても高速にデータアクセス可能にはなりそう。

>>211
実際動いてるバスは1本か2本になると思うのは気のせい？

>>211
メモリインタリーブ・・・

>>212
そこが味噌。

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

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

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


で、実はAm29000はインストラクションバスとデータバスを個別にもってて、
直線性のあるインストラクションバスはVRAMのシリアルポートにつないじゃえ
って発想なんだけど、ある意味、二つのアドレスレジスタに対し二つのバスを
用意した一例。

>>208
３DNow!の解説には無くても動くけど最初のMMX命令でEMMSと同様の処理が発生するから
FEMMSではさんだ方が速いと書いてあったな

CQから出てる中森章の「マイクロプロセッサ・アーキテクチャ入門」は
このスレ的に面白いと思うのでおすすめ

そういや本棚の奥にその手の解説書があったんだった。
いいことを思い出させてくれたよ、サンクス>>216

>>214
I/D分離するのはバーバードアーキテクチャと言ってそーとー昔からある。

＞最初のMMX命令でEMMSと同様の処理が発生するから

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

EMMS命令は8つあるFPUレジスタのタグワードをすべて有効にする(11)にする命令。
MMX命令によってレジスタに書き込まれると、タグワードは無効(00)になるんだよ。

>>218

そーなんだよなー。

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

で、214が言う機能の壁はマルチタスク動作じゃないかな？

>>219
物理的なレジスタは別物だから切り替えにものすごく時間がかかるんだが
MMX>FPUは遅いけどFPU>MMXは速いのか
知らんかったよサンクス

>>219
君も間違っているし。
EMMS使うとタグは8つすべて「空」11になる。
EMMS以外のMMX命令を使うとタグはすべて「有効」00になる。
ちなみに無効は10。

あと、やろうと思えばEMMSを呼ばずにMMXとx87を混在させることができる。
遅いか速いかは分からないけど。

MPUの世界でハーバードアーキテクチャを歌ったのはMC68000あたりからなんだが、
残念ながらメモリデバイスに伸びるまずまで分離できてなかったんだよね。
けど、肉まんを例にだしたのはちょっと失敗だったかも。反省。

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

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

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

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

かなぁ。

いまのメモリ帯域の狭さは、メモリバスがその名の通り「バス」動作している点にあって、
クロック倍にしても倍にしか速くならないのがイタイ。
どうせ外部記憶装置並みに遅いデバイスなら、外部記憶装置としてつかう事考えてもいいかもね。

あ、それと、
・シーケンシャルにしか動作できない
・片方向でしかデータをながせない
のもイタイ点。

>>223
>マルチタスク動作に支障はでないよ ^^

コンテキストスイッチ時のペナルティが大きくならねぇか？って話。

CPU性能＝命令セット×マイクロアーキテクチャ×製造技術
結局のところ設計や工場に投資できる金のあるところが勝つ。
金がある＝CPUが売れてる＝普及した古い命令セット＝汚い命令セット
かくしてAlphaやTRONのような美しい命令セットは滅び
x86やPowerPCのような汚い命令セットが世界を席巻する訳だ。

>>223
当時はパッケージング等の問題もあったと思われ。

ハーバードアーキテクチャが完璧かと言えばそうでは
ないよね…データテーブルとか面倒だし。

>>225
メモリ待ちになるのはどっちも同じ話だし、メモリリクエスト後待ち状態に
なったらその時点でもコンテキストの切り替えしてもいいから、むしろ
ペナルティは小さくならないか？

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

見落としてる点があったら指摘よろしく ^^

保守

なんとなくわかったような気もするが、かなり複雑な回路になりそうやな
そこまでやると、かえってレイテンシが増えてしまいそうな気もする
単純にL3キャッシュをアホみたいに積むほうが速くなりそうな

>>227
パッケージングの問題は過去のものでは無い気が。
ついでにCPUコア内部のバス引き廻しも爆発的に増えちゃって
クロック上げられなくならないかな。

ちょっと違うけど、漏れは10年位前に命令を分類して、種類毎に
別々のメモリバスにつながったメモリからプロセッサに供給する
っつーCPUの試作なんてのをやってたけど、やはりLSIデザインが
破綻しちゃった思い出が・・・

>>226
>かくしてAlphaやTRONのような美しい命令セットは滅び

TRONってTRONプロセッサってヤツ？

>>231
今時のは半分くらい電源用ピンのようなｗ

>226
美しい、汚いってのは?トーシロにもわかるように説明きぼん

無理（理解することが）？

>>226
キャッシュが内蔵する様になったからねぇ(´ー｀)y─┛~~

x86の有利な点を無理に言えと言われれば、レジスタが少ないので
コンテクストスイッチが少し速くなる可能性がある事かいな。

x86-64なんかでは、増えたレジスタをスイッチの度に全部待避する
んだろうか？

>>230
うん、メモリコントロール部分の回路もメモリ側も相当複雑になるだろうし、
コストも相当かかるようになっちゃうだろうね。実際 RDRAMって高くて市場に
受け入れられなかったわけだし。

>>231
やったんだｗ
内外のデータバスを双方向シリアルにして、外部数GHzでまわしたらどうなるかなぁ。

もうワイヤードロジックだのCRISPなどといった言葉は出てこないのね。
初期のCISC vs RISCで散々使われた言葉なんだけどさ。

>>237
今だったらそうするだろうねぇ。
しかし、高性能プロセッサ設計の仕事自体が漏れの周辺では殆ど
なくなっちゃったw

>>238
CISC RISC論争はもうほとんど意味無いと思う。強いて今からやるなら
これからは VLIW だよ派 vs スーパースカラまだ無敵だよ派
かな？

>>236
そりゃやらなきゃまずいでせう。
プロセス間でレジスタの中身を共有するなら、
その分はなにもしなくてもいいけど。

>>234
無理・・・じゃないかな。
アセンブラレベルを理解できれば、分かると思う。

そんな漏れはZ80→8086で泣きそうになった男・・・。

今どきのメモリは連続アクセスする分には充分速いから(プリフェッチとかできる)、
レジスタ退避みたいに連続したアクセスなら比較的性能を出し易いのでは。

>>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

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)

ですな。

これからは，スーパースカラプロセッサにしても，
VLIW プロセッサにしても，マルチスレッド化 (特にSMT) に向かうのでは？
などと最近勉強しはじめた新米の戯言をお許しください。
でもマルチスレッド VLIW って，初心者からみるとよさそうなんだけどなあ...。

>>223
68000はハーバードアーキじゃねー。

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

>>243
VLIWはDelayed Branchやインターロック無し実行と同じように盲腸になった
ようだな。(性能を重視するプロセッサにおいては)

>>246

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

その点直接ネイティブを見せないEfficeonは上手くやった。

>>246
研究者方面での意見はしらんがMC68000はモトローラいわくハーバードアーキテクチャを
特徴の一つとしたMPU。内部バス構造がその所以。

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

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

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


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

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

ある程度以上は分散アーキテクチャにしちゃったほうがいいっていう割り切りなんだろうなぁ、って
僕は思ってみてるけど、どうだろう。

がーん。
間違えた〜。

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

IA-64はバイナリコンパチのまま命令拡張が出来る改良型VLIWだから
動的スケジューリングを載せる必要性が出てくるのね…。

IA-64はVLIWとは言わず、EPICと言ってるな・・・。

Itanium→Itanium2で中身変わったけど、バイナリコンパチ。
ただし、どっちに最適化するかで、パフォーマンスは多少変わる。

>>248
内部バス分離でハーバードアーキかよ。マーケティング用語だな。

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

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

Originは知らんがSunFireはSMP(厳密には違うだろう)で、分散アーキじゃねー。
どのCPUからも全メモリにアクセスできるだろうが。分散マシンとか言ったら
設計者泣くぞ。(多分パーティションは切れるだろうがそれは話が別)

うーん、煽りたいだけの半可通は放置したほうがいいのかな？

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

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

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

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

残念ながら私もSunOSのソースを見たことはないんで、SunFireにおけるタスクスケジューラが
どのようになっているかはわかりませんので、ペナルティを甘んじて受けてるのか、素直に
スレッドを各モジュールごとにばら撒いてるかは想像の範囲を出ません。

そのクラスのマシンはNUMAでしょ。
Origin は cc-NUMA と明記してたと思うけど、SunFire はどうなんだろう。

>>252
SUNはSMPと言ってるがな。
Cacheを付けた段階で厳密な意味でのSMPなんて存在しないよ。
1つの保守単位となるボード上に複数のCPUを載せ、かつ複数ボードを搭載できる
製品をSMPと言っているのはたくさんある。もちろん厳密な意味ではSMPでは
ないが、それを気にしているのか？ キャッシュ無しバス結合マルチプロセッサ
以外はSMPになり得なくなる。

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

あと、SunOSのソースを見なくても『Solaris Internal』に載っているかも知れん。
読んでみれ。

キャッシュがあってもSMPって普通は言うと思う。もし「キャッシュがあったらSMPではない」なんて言うのが
SMPの定義だったら「世の中にはSMPなんて存在しない」ということになってしまうからね。だから厳密な意味の
SMPの定義は「どのCPUから見てもどのメインメモリも等latency・等Bandwidthに見える」だと思う。
この条件に合うのは、いまだにシェアードバスにこだわっているIntelのXeon/Itanium2でシェアードバス結合が
使える4way以下のシステムとIBMのメインフレームだけでしょう。それ以外は全てccNUMAと言っても良いと思う。
(2coreのCPUを使った2wayのシステムも厳密な意味でSMPだけど)厳密なSMPを実現するには非常にコストがかかるので、
無理して厳密なSMPなんてやらないで、ある程度ccNUMA的なシステムを作って、あとはソフトウェアの使いこなしに任せる、
というのが現在の技術の流れだと思う。Linux kernelだって一生懸命NUMAサポートを入れているし。

255の主張ではSunFireはccNUMAになってしまいますが、そういう意味？
あと、SMPマシンにLatencyの違うDIMMを差すだけでSMPじゃなくなると言う
主張にも見えますが？
普通はそんな厳密な事は気にしていなくて、SunFireはSMPに分類するだろう。

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

広義に言えばSunFireでもIBMのRegattaでもHPのSuperdomeでも大規模SMPはもうccNUMAと言えると思う。
たぶん、80年代だったらああいう構成ならccNUMAと呼んだと思う。(Opteronもそう)
ただ現実には昔のccNUMAと比べてローカルメモリとリモートメモリのアクセスタイムの差が大分小さいから、
あまり性能のことをうるさく言わなければ、普通のSMPとして使えるんだと思う。
だた、性能をうるさく言うとソフトウェアがローカルメモリとリモートメモリを意識した処理をする必要が
あって、今やLinux kernelだってそれを意識したCPU/メモリ割当てとかをやろうとしている。
Linuxがやろうとしている位だから、各ベンダーのUnix(Solaris/AIX/HP-UX)は既に絶対やっていると思う。

SunはSunFireをSMPとしか呼んでいないし、少なくともSolaris7はSMPにしか
対応していない。(『Solaris Internal』)

『Solaris Internal』では、システムインターコネクト(ボード間インター
コネクト)が均一なアクセスタイムを実現するために十分なバンド幅
があるものがSMPであるとしている。

だからSunFire/SolarisはSingle imangeでは性能が悪くて、パーティショニングして使うんだ。
Bandwidthが確保されていても、レイテンシの差は絶対あるんだから、それを意識した制御は
OS側でやるべきだと思うよ。

だいたいSunFire(SPARC)みたいな時代遅れの性能の悪いシステムの話がなんでされているんだろう。
元々SunFireもCrayが設計していたのをSunが買ったんだと思うから、Sunはもう何年も自分で
まともなハイエンドのハードウェアを開発していないんじゃないかな。
UltraSPARC�Wだって、結局UltraSPRAC�Vのデュアルコア版にすぎないし。

パーティション切らない時にローカルボードのメモリアクセスが遅くならない
ことを言わないとSMPで無い事を言えません。

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

257は知ってるのだろうが、知らなければSunはSMPだと言ってる以外何も言えません。
(というより何が言いたいのかさっぱり分からない)

パーティションを使わない場合、SunFireの構成ならローカルメモリとリモートメモリのレイテンシの差が
あるのはハードウェアの構成上明らか、という考察では不足？
Bandwidthはわからないけど、レイテンシは絶対違うでしょう。
でもSunのSMPの定義と私の"厳密な意味の"SMPの定義は違っていて、Sunの定義だとレイテンシが違っても
Bandwidthが違わなければSMPと言って良いから、SunのSMPの定義に従えばSunFireはSMPかもしれない。
でもどうせSunFireのBandwidthなんて激低だろうから、どうでもいいのでは。

あなたの定義だとSMPマザーボードにレイテンシの違うDIMMを差すとccNUMAに
なるんですね？

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

>>260
このスレは思い付きとか言い合って楽しんでる(?)んだから古くてもいいじゃん。
新しい方が良ければネタ振ってよ。

Efficeonマンセー

だんだんとスレが生きてきましたね。
一瞬削除願い出そうかと思ったが、出さなくてよかった。

またかなり話が難しくなってきました。
初心者を置いていかないように適度にトイレで例を示してください。お願いします

少なくとも性能対消費電力が重要視される分野ex)Embeddedなど)以外では、
Hardwareの仮想化ってのはここ数年来大分注目されてる分野だと思うけれど？

例えばIA64の性能向上がムーアの法則を上回るなんて言われてるのも、
それ遺体は眉唾だけど、IA32で同じ事を言うよりは信憑性があるように、
今後は最新プロセスと高度な論理設計技術を持ってるメーカーは
益々VLIW(CMS？)的なアプローチの方が有効になると思うんですがどうでしょう。

あ、>>267は>>247に対してス。

http://www.idg.co.jp/sw/back/series/200005_01_kernel.html
----
サン・マイクロシステムズが出荷しているマルチプロセッサ・システムは「SMP」と
呼ばれるアーキテクチャを実装している。これは、「Symmetric Multi Processor
（対称型マルチプロセッサ）」と「Shared Memory MultiProcessor（共有メモリ型
マルチプロセッサ）」という2つの用語の頭文字をとったものである。サンのシス
テムは、どちらの用語にも当てはまる設計がなされている。
----

もはや、SunFire15Kあたりは、前者の意味でSMPと言っているだけという気がする。
これなら、NUMAとSMPは直交する概念だ。

すまん、>269の補足。

リンク先を読めばわかるが、ここでいう「対称型」は、どのプロセッサも同じOSの
機能を処理できる構成を指していて、プロセッサからメモリが等距離とかいう
構成ではない。

しばらく見られんかった…age。

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

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

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

>>266
SMPやバス構造を便所で説明するのﾑｽﾞｶｼｲんだよな ^^;
考えてみるけどできなかったらｺﾞﾒﾝ

┌────┐　　　　　　　　┌────┐
│　 部屋 　│　　　　　　　　│　 部屋 　│　
│　 　 　　　│　　　　　　　　│　 　 　 　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　 　 ││　　　　　　　　　 　 　 　 ││
　 　 │└─────────-┘│
　 　 │┌─────────-┐│
　 　 ││　　　　　　　　　 　 　 　 ││
┌─┘└─┐　　　　　　　　┌─┘└─┐
│.　トイレ . │　　　　　　　　│.　トイレ　 .|
└────┘　　　　　　　　└────┘　

┌────┐　　　　　　　　┌────┐
│　 部屋 　│　　　　　　　　│　 部屋 　│　
│　 　 　　　│　　　　　　　　│　 　 　 　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　 　 ││　　　　　　　　　 　 　 　 ││
　 　 │└─────────-┘│
　 　 └─────┐┌───-─┘
　 　 　 　 　 　 　 　 ││
　 　 　 　 ┌───┘└───┐
　 　 　 　 │　　　　トイレ　　　　.│
　 　 　 　 └────────┘