男「まあともかくだ」

男「コンピュータと一言で言っても色々な分野があるわけで」

女「知らないけど」

男「あるんだよ」

女「そっか」

男「俺に分かる範囲は限られているから」

男「俺が知ってるところで汎用プロセッサについて話そうと思う」

女「コンピュータのコの字も出てないよぉ……」

男「コンピュータと言ったらプロセッサだろ」

女「わかんないんですが」

男「一般教養だが」

女「月が綺麗だねー」

男「そんな時間ではないだろ。って話を逸らすな」

女（君に教養とか言われたくないわ）

男「しかたがないからプロセッサの立ち位置から説明してやろう」

女（前にパソコン買うって相談したからかなあ）

男「コンピュータは主に入出力装置、主記憶装置、演算装置から構成されるんだ」

女「……はいはい」

男「入出力装置と主記憶装置がそれぞれ演算装置に接続されて、主記憶装置に書かれたプログラムに従って演算装置が処理を行い、必要であれば入力を得て、出力装置へ出力する」

女「具体的にどれが何かってところが分からないといまいちピンとこない」

男「ま、とりあえず概要ってヤツだ。どれが何かは分かるか？」

女「キーボードとかマウスが入力装置でディスプレイやスピーカが出力装置だよね」

男「そうだな」

男「これについてはそこまで説明することもないだろ？」

女「まあそうかな」

女「主記憶装置……はハードディスク、って言うんだっけ？　HDD？」

男「違う」

女「ええー、でもHDDにデータを保存するとか言うじゃない」

男「保存する場所はコンピュータにとってはあくまで補助でしかないんだな」

女「人間の視点を持ってよ」

男「コンピュータの話だって言ってるだろ」

女「納得できない」

男「まあ何を主だと考えるかは主観によると言えばその通りだけど、今回はHDDはモブなんだ」

女「じゃー何が主記憶装置なの」

男「メモリだ」

女「USBメモリ？」

男「ちがう」

女「えぇ……」

男「いわゆるDRAMだな」

女「いわゆると言われてももう何がなんだか分からないよ」

男「よく言われる例えを出すならテーブルだな」

女「テーブル？」

男「データと言う風呂敷を広げるための空間、それがメモリだ」

女「じゃあHDDはどういう立ち位置なの？」

男「そこに話を戻すのか」

女「違いが分からないと話が分からないじゃない」

男「HDDはその風呂敷を仕舞っておく場所だな。仕舞ってる風呂敷は使えないだろ？」

女「分かるような、分からないような」

男「図書館の本棚に本があるだけでは誰もその内容を知る事はできないが、テーブルの上にあればタイトルくらいは分かるだろ」

女「HDDは同じパソコンの中にあるのにそんなに遠いの？」

男「遠い。超遠い」

女「超なんだ」

男「例えるなら、メモリはちょっと県外に旅行程度の気分でアクセスできるが、HDDは海外旅行に行こうってくらい遠い」

女「そんな大げさな」

男「大げさじゃない」ｽﾞｲｯ

女「な、なんでそこで迫ってくるのよ」

男「本音を言うならメモリすらプロセッサからは遠い存在なんだ」

女「さっき気楽って言ったじゃない」

男「HDDに比べれば、だ」

女「じゃあHDDなんて使わなければ良いじゃない」

男「メモリはHDDよりアクセスしやすい代わりに色々と不便だからな」

女「どんなところが？」

男「HDDは遅い代わりに大容量のデータを長期間保存できるが」

男「メモリはHDDより速いが、代わりに保存できるデータが少ない」

女「どのくらい速さが違うの？」

男「う、HDDは計測方法によって速度がまちまちだが……」

男「HDDに有利な条件でメモリとの速度差は10倍、不利な条件なら1000倍程度…かね」

女「HDD遅い！」

男「しかしメモリは標準的な容量で4～8GB、多い人でも32GB程度だが、HDDは500GBから多い人だと２、3TBものデータを保存できるからな」

女「ちょうど反比例してるみたいだね」

男「その通り。保存できるデータ量が増えるってことは探索の時間が増える事を意味するからな」

女「なんとなく分かった」

男「まあメモリの重大な欠点は、HDDと違って長期的なデータ保持ができないってことがあるんだけどな」

女「どういうこと？」

男「HDDは電源を切ってもデータを保持できるだろ？」

女「そりゃあ記録装置なんだから当たり前じゃない」

男「当たり前じゃない」

女「記憶装置って言うのに……」

男「メモリってのはコンデンサを使ってデータを記憶してるんだ」

女「わたしは物理選択ではないので、電子部品の話とか全く分からないです」

男「コンデンサの原理から説明する意味はないから簡単に言うが」

男「コンデンサは定期的に電力を使ってデータ内容をリフレッシュしないとデータを保持できないんだ」

男「コンデンサはお漏らしで少しずつエネルギーを漏らしていくからな」

女「唐突に卑猥」

男「下ネタが好きで悪かったな」

女「ほかの女の人の前で下ネタ言ったらセクハラで訴えられるよ」

男「気を付けるよ」

男「話をまとめると、HDDはガッツリたくさんのデータを保存できるが遅い」

男「メモリは覚えられる量も少なくかつすぐ忘れるアホの子だけど速い」

男「HDDとメモリの違いはこんなところだな」

女「メモリはなんか水兵さんの格好をしてそう」

男「詳しくないがアホな子な設定とかあるのか？」

男「話がようやくコンピュータの構成の話まで戻ってこれる」

女「どこまで進む気なの」

男「だからプロセッサの話をしたいって言ってるだろ」

女「ええーっと、パソコンは入出力装置…キーボードやディスプレイと、主記憶装置…メモリと、演算装置から構成されるんだっけ」

男「お、ちゃんと覚えてるな。えらいえらい」ﾅﾃﾞﾅﾃﾞ

女「ふふん。話はちゃんと聞く方なのです」

男「さて、ようやくコンピュータの核、演算装置の話だ」

女「それが君の言ってたプロセッサ？」

男「その通り」

男「プロセスを進めるものだからプロセッサ、なんだろうな」

男「店のパソコンコーナーとかではCentral Processing Unit（中央演算装置）、CPUとか言われる部品だな」

男「一昔前に『もしIntelが入っていたら』なんてCMがやってたアレだ」

女「君にもIntelが入ってればなあ」

男「どういう意味だよ」

女「もっと気の利く良い男になってただろうに」

男「気が利かなくて悪かったな」

男「この演算装置、ここではCPUと言っておくが」

男「CPUはメモリの指定の場所にあるデータを命令として解釈して」

男「その命令に従ってデータをメモリから取得したり演算を行ったりするんだ」

女「指定の場所って固定されてるってこと？」

男「あー説明が悪かったな」

男「CPUはメモリのどこそこに命令が書かれてると覚えていて、」

男「その命令を実行すると、覚えていた場所を一つ横にずらすんだ」

男「こうやって一つずつ見る場所をずらすことによって、メモリ全体を舐める事ができる」

女「また卑猥な言い方を……」

男「？　どこが卑猥だったんだ？」

女「わたしが自意識過剰なみたいじゃない！」

男「なんかゴメン……」

男「これで、コンピュータにとって重要な人物が出そろったな」

女「キーボード、マウス、ディスプレイ、メモリ、CPU？」

男「その通り」

男「個々の役割についてはこれまで説明した通りだが、繋がりは最初に簡単に説明したきりだな」

女「そうね」

男「まあ最初ので分かる気もするが、片手落ちな説明も嫌だから改めて簡単に説明しよう」

男「動作の起点は常にCPUにあるんだ」

男「CPUがどこそこにある命令を教えろとメモリに要求する」

男「例えばその命令が、キーボードの入力を待てだったら待つし」

男「ディスプレイのどこそこの点を何色にしろだったらその通りにするわけだな」

女「でもメモリってアホの子だから電源付けたときには何も覚えてないんでしょ？」

男「う、、」

男「その辺りは起動用に専用の小さな記憶領域があって最初はこうしろって手続きを覚えているらしい」

男「いわゆるBIOSだとかUEFIとかの話だが…如何せんその辺りは詳しくないんだ」

女「その小さい領域はアホの子じゃないのね」

男「アホアホ言うな」

男「さて」

女「さて？」

男「ここまででコンピュータの大まかな構成は理解して貰えたかね」

女「多分」

男「よし」

男「では汎用プロセッサで最速を目指すロマンについて話そうか」

女「そういえばそういう話だったね…」

男「そういえばも何も、その話をしようとしたら話の骨を折ったのは女だろう」

女（そもそもそんな話を聞きたいわけではないのだけれど…わたしがパソコン買うために説明考えてきてくれたんだろうなあ）

女「君とわたしでは前提となる知識が違いすぎるから」

男「だからこうして話して説明してるだろ」

女「そうですね、話し合いは重要ですね。話さなければ伝わらないですよね」

男「なんで丁寧語なんだよ」

男「ようやく汎用プロセッサの話ができるわけだが」

男「どこから話したものかね」

女「一番話そうとしてたことのくせに内容がまとまってないの？」

男「今までの説明はほとんどテンプレでよく言う説明だが、この話を自分でまとめて人に話すのは女が初めてだからな」

女「そ、そっか」

女（……こんなことでちょっと嬉しいと思う自分が悔しい）

男「歴史……については話す必要ない気もするが、いきなりOoOスーパスカラの話をしてもな……」

女「いきなり意味の分からない単語が出てきた」

男「そうなるよな」

男「やっぱりインオーダ・プロセッサ、インオーダ・スーパスカラ・プロセッサ、アウトオブオーダ・スーパスカラ・プロセッサの順に話すのが良いな」

女「道のりが遠いことは分かったよ……」

男「ちなみにアウトオブオーダ（OoO）・スーパスカラの説明のあとはOoOとは直交する高速化の工夫についての話があるからな」

女「直交する工夫……？」

男「本質的に影響し合わない、互いに独立に実装可能な工夫、だとでも思ってくれ」

男「まずはインオーダのプロセッサについて説明しよう」

男「インオーダってのはin-order、つまり順序通りに処理を行うプロセッサってことだ」

女「順序ってなんの？」

男「プログラムの順序だな」

男「例えば四則演算だったら

・基本的には左側から計算をする

・掛け算や割り算が先で足し算や引き算を後にやる

・ただし括弧は（小さい方から）優先して計算される

ってルールがあって、その順序を守らなければ異なる答えが出てしまうだろ？」

女「そうだね」

男「計算に限った事ではないが、色々なプロセスは手順を守ってやるから正しい結果を出すことができるわけだ」

男「料理を作った後に食材を洗ったら料理が台無しだろ？」

女「当然ね」

男「だからプログラムの順序を守って命令を実行するのがインオーダ・プロセッサだ」

女「そういう話を聞くと、ただの当たり前をしてるだけだね」

男「まあそうだな。この話はインオーダでない、つまりアウトオブオーダの話をするための事前知識に過ぎない」

男「とは言え、OoOと直交するインオーダでもできる高速化の工夫があるんだ」

男「例えば、洗濯という仕事を例にして話をしよう」

男「インオーダに洗濯を実行するとどうなる？」

女「インオーダに、って大仰な。単純に洗濯カゴから洗濯機に洗濯物を入れて

洗濯が終わるのを待って、終わったら干して、乾いたらたたんで箪笥に片付ける。でしょ」

男「ちゃんと箪笥に片付けるのは偉いな」

女「いい奥さんになれると思うんだ」

男「女を嫁にする人は幸せだな」

女「……」

男「話が逸れたな。じゃあ洗濯物が大量にあって一度に洗濯機に入り切らなかったらどうする？」

女「当然２回、3回に分けて洗濯するでしょ」

男「箪笥に片付けてから2回目の洗濯機を回すのか？」

女「そんなことしてたら馬鹿じゃない。洗濯機はとっくに空いてるのに」

男「そういうことだな」

男「"洗濯"という仕事を箪笥にしまうまでだとまとめてしまえば、2回目の洗濯は1回目の洗濯物を箪笥にしまうまで実行できないが、実際には"洗濯"そのものは洗濯機さえ空いていればいつでもできるわけだ」

男「これがいわゆるパイプライン化、だ」

女「イメージはなんとなく分かるけど、パイプライン化って言葉は全然分からない」

男「プロセッサの仕事を一言で表すと、"メモリ上に書かれた命令を色々と頑張って実行する"だ」

女「そうだね」

男「だがこの"色々と頑張って"の部分は思いのほか長い」

男「だからここを小分けしようって話だな」

女「具体的にはどんな風に分けてるの？」

男「まあプロセッサ毎に色々と違いはあると思うが、大きくは5個くらいに分けられるな」

男「①命令を読み出す。②命令を解釈する。③必要なデータを揃える。④計算をする。⑤結果を書き込む」

男「ああ、そういえば重要な話を忘れてた」

女「じゅ、重要な話？」ﾄﾞｷﾄﾞｷ

男「プロセッサは内部にレジスタって言う、小容量で超高速な記憶領域を持ってるんだ」

女「ですよね、知ってました」

男「なんだ、知ってたのか」

女「違うよ」

男「さっきメモリの説明をしたときにちょっと話したけど、」

男「メモリはCPUから見るとやっぱり遅い」

男「だから計算をする都度にメモリ上のデータを使うってのは非現実的なんだ」

男「CPUはせいぜい2入力1出力程度の計算しかできないからな」

女「2入力1出力の話と計算の都度メモリに書き込むことが非効率って因果関係がよく分かんない」

男「例えば1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1って計算をするときに」

男「メモリから先頭2つの1を読んで足して2を出して、それをメモリに書き込む」

男「また2を読み出して、3つ目の1を読み出して足して3をメモリに書き込む」

男「これを16回繰り返すことになるが、計算の途中結果である2や3って結果はメモリに書き戻す必要はないよな」

女「一気に16個読み込んで足せば良いじゃない」

男「2入力1出力が基本だと言ったろ」

女「あ、なるほど」

男「まあ演算子も含めれば3入力なんだけど」ﾎﾞｿｯ

男「そんな事情とあとは命令の記述されてる場所を記憶するって意味もあって、レジスタという記憶領域をわずかながらにもっているわけだ」

女「わずかなの」

男「さっきも言ったけど、記憶領域が増えればそれだけ動作が遅くなるからね」

男「論理的には恐らく32個から64個くらいしかレジスタはないと思う。これはプロセッサというか命令セット・アーキテクチャで規定されてることだから調べれば分かると思うが」

女「論理的にはとか命令セット？　とかってわざと分かりづらい言い方しようとしてない？」

男「インオーダ・プロセッサでは論理的なレジスタ数と物理的なレジスタ数は一致するがOoOでは必ずしもそうではないからなぁ……。そして命令セット・アーキテクチャはまあ、あれだ人間で言うところの英語なのか日本語なのか、どの言語を使ってるかってことだな」

男「重要なのはレジスタってものがプロセッサ上でデータを記憶してるって話だ」

男「だからさっきのパイプライン化の話で③のデータを揃える、⑤の結果を書き込むってのはレジスタから、レジスタにってことだ」

男「メモリに書き戻したい場合はさっきの構成なら、④の計算を行うに分類されるわけだな」

女「えーっとインオーダ・プロセッサは命令を前から順に処理するだけだけど、処理の手順を小分けすることで高速化している…っと」

男「そうだな。あとは基本的な知識として、プロセッサにはレジスタと言う小さくて速い記憶領域があるってことだ」

女「インオーダ・プロセッサの話はこれで終わり？」

男「概要はこんなところだな」

女「今までのは概要なんだ……」

男「さっきの1+1+1+…って例を思い出してみると」

男「最初の1＋1の結果をレジスタに書き戻すと次の２+1を実行するわけだが」

男「パイプラインは④で計算、⑤で書き戻しだ」

女「言いたいことがよく分からない」

男「2っていう計算結果は④で出ているが⑤で書き戻されるまで次の命令は2を使うことができないって話だ」

女「パイプライン化したのにそれじゃあ意味ないじゃない？」

男「まあパイプライン化しなければそもそも計算結果2が出てないタイミングに2が出てるとも言えるわけだから遅くなってるわけではない」

女「本当なら1個待てば良いところがパイプライン化で2個待つから遅くなってない？」

男「パイプライン化のメリットを根本的に分かってないな」

女「む」

男「分割する前の全体の動作と、①から⑤に分割した後の①から⑤までの全ての動作にかかる時間は理想的には同じだ」

男「パイプライン化する前では⑤を終えたあとに、次の命令の①が始まるんだ」

男「だが、パイプライン化をすることによって連続的に各ステージの処理を行うことができるわけだ」

男「だからインオーダ・プロセッサにおいてパイプライン化する前より遅くなることは普通はない」

女「むー」

男「とは言え、2が書き戻ってくるまで次の計算はできないわけだから、2+1の実行タイミングは必然的に1テンポ遅れるよな」

女「なんかもったいない」

男「そう、もったいない」

男「この何かしらの理由によって動作が止まることをストールと言います」

男「しかしストールしないで頑張る方法があることもある」

男「今回はどっちだろうか」

女「訊くってことはしなくても大丈夫？」

男「うむ」

男「さっきは結果を書き戻されないと読めないから使えないと言ったが」

男「演算処理というのは定数時間で終わるので、結果が戻ってくるタイミングを計算しておくことができる」

男「予め結果が戻ってくるタイミングを計算して、書き戻し→読み出しって言う2つのプロセスを計算結果を直接演算器へ送るという1つのプロセスに変換するんだ」

男「これをフォワーディングと言う」

女「計算結果が出るタイミングを計算するのに演算器を使ってしまうのはもったいない気がする」

男「それ専用の回路が別にあるから、それのせいで演算器が減るってことはないよ」

女「そういうもの？」

男「今の時代、プロセッサの多くを占めるのはそういう補助用回路だからなあ」

男「インオーダ・プロセッサでの高速化の工夫はこんなところだな」

女「ふう」

男「次はスーパスカラ・プロセッサな」

女「や、休まないの」

男「む、まあ確かにコンピュータの構成から話始めたから根を詰め過ぎたかも知れないな」

女「ちょっとティーブレイクしようよ」

お（茶）休み

なんか賢くなった気がする
わかりやすい！

>>35
わかりやすいと言ってもらえると嬉しい
頑張って専門用語とかは説明するようにしてますが分からなかったり、あるいは話で触れてないけどこの辺が気になるってところがあればきいてください
分かる範囲で答えます

女「君はホントにパソコン好きだね」

男「そうでもない。単にそれしか知らないだけだ」

男「それにコンピュータについて知ってることも少ない」

女「よく分かんないや」

男「ソフトには疎いんだよ。プロトコル、、ソフトやハード上での約束事なんて覚えられないからな」

女「君は形式に拘らないものね」

男「統合的にやれば最高効率を出せるからな」

女「汎用プロセッサの話をしてたのに汎用的じゃない」

男「ぐっ」

男「人の作ったものを理解して読み下すのはしんどいんだよ」

女「ならそれを理解できる人を頼ってしまえば良いじゃない」

男「自分が分からない部分があるのは怖いだろ」

女「むう」

女「わたしを頼ってもいいのだけれど」

男「女は頼りになる部分がないだろ」

女「君の生活の手助けくらいはできるよ」

男「そういうことは婚約者にでも言え」

女「じゃあ結婚しよう」

男「え」

女「結婚」

男「いやそもそも付き合ってもいないだろ」

女「じゃあ付き合おう」

男「そもそも女は俺のこと好きじゃ」
女「好きだから言ってる」

男「俺なんか」
女「君なんかじゃない」

男「お…………。よろしくお願いします」

女「……うん」

男「じゃ、じゃあ気を取り直してスーパスカラ・プロセッサの話に戻ろうか」

女「え」

男「ここまでの話をまとめるとインオーダなプロセッサはプログラム順に一つずつ命令を実行するが、パイプライン化によって1列に複数の命令を処理していたわけだ」

女「ちょっと」

男「なに」

女「わたしと君は付き合ってるんだよね」

男「どうもそうらしい」

女「2人きりだよね」

男「だな」

女「ほかにもっと色々やるべきことがあるのでは？」

男「……俺はインオーダにしか物事を処理できないから」

女「むぅ……」

男「さて話を戻すと、今インオーダ・プロセッサは1列に複数の命令をと表現したわけだが」

男「この表現を借りるならスーパスカラ・プロセッサは1行で複数の命令を実行するんだ」

女「……一度にたくさんってこと？」

男「そういうことだな」

男「これはパイプライン化と直交してるからインオーダ・プロセッサの改良、インオーダ・スーパスカラ・プロセッサだな」

男「話は単純で、一度に複数の命令を読み込んで実行可能な分だけ一気に実行するってものだ」

女「実行可能な分だけっていうのが気になる言い方だね」

男「また1+1+1+…の例だが、これは前の実行結果がないと2つ目3つ目の足し算を実行できないから1行で実行することができないだろ」

女「なるほど」

男「こういう実行できるかできないか、をプロセッサが解析するのがスーパスカラ・プロセッサなわけだ」

女「また気になる言い回しを」

男「鋭い、さすが女」ﾅﾃﾞﾅﾃﾞ

女「ふふふん」

男「敢えてさっきみたいな言い方をした理由はVLIWプロセッサなる存在があるからだ」

女「VLIW？」

男「Very Long Instruction Word、超長命令語の略だな」

男「命令の長さってのは命令セット・アーキテクチャによって異なり」

男「最近のプロセッサは多分64bitの命令長で、昔だと恐らく32bitや16bitあるいは可変長の命令長だったんだが」

男「VLIWは128bitという長い1つの命令だったんだな」

女「16とか32の時代で128bitってこと？」

男「そういうこと」

女「なんでそんなに長いの？」

男「128bitで一つの命令と言ったが、その実は128bitの中に複数の命令が入ってるイメージだな」

男「ただ128bitで不可分だからVery long Instructionなわけだ」

女「…それは普通に16bitや32bitの命令をたくさん並べたら駄目だったの？」

男「VLIWにおいて128bit内に記述された命令は全て並列実行可能なことが保証されているんだ」

男「つまりスーパスカラ・プロセッサのように並列可能かどうかのチェックをプロセッサが行う必要が一切ない」

男「ハードウェア的なコストとしては最初に説明したインオーダ・プロセッサとほぼ同じになるわけだな」

女「そう考えたらVLIWの方が良いように聞こえる」

男「実際、そう考えていた人も当時はいたみたいだし、今でも一部用途ではVLIWが良いと言う話もあるらしい」

男「VLIWの最大の欠点はプロセッサ毎にバイナリを置き換えないと駄目だってことだな」

女「バイナリとは」

男「そこで詰まるか」

男「単に機械が理解できる0か1かで構成された言語だ、っていうと命令セットと説明がすこし被るな……」

男「例えば同じアルファベットを使う言語でもローマ字と英語は違うよな」

女「うん」

男「このときのアルファベットがバイナリ、ローマ字や英語ってのが命令セット、かなあ」

男「全く知らない人には大差がないように見えるけど、多少知ってれば全く違うってことくらいは分かるだろ」

女「つまり英語で書かれてた文書を、同じアルファベットを使うけど、翻訳してローマ字に置き換える。ってのがバイナリを置き換えるってこと？」

男「まあそんな感じ」

男「スーパスカラ・プロセッサはインオーダ・プロセッサと同じ言葉を使っても高速化することができるが」

男「VLIWで高速化をするためにはVLIW用の言葉を使わなければならないってことだ」

女「言語の壁かあ」

男「特にVLIWは128bitという大きさだが、仮に発展したとなると更に語長が伸びて違うバイナリを用意する必要が出ただろうな」

男「そういう後方互換性のなさがVLIWが流行らなかった大きな理由だ」

女「なんだか排他的な話だね」

男「残念ながらな」

男「もう一つVLIWの重大な欠点としては、

・命令の並列実行可能かどうかの判別の多くは実行時でないと分からない

ってのがあるな」

女「予め並列かどうかを予測するには限界があるってこと？」

男「うむ」

男「色々な場面で重要になるが、プログラム上で分岐命令の実行頻度はおよそ20%程度だと言われてる」

男「つまり5回に1回はプログラムが非連続になる可能性がある」

男「そういう部分で事前に予測して並列性を取り出すのが難しいわけだな」

女「そんなたくさん分岐してるんだ」

男「さてスーパスカラ・プロセッサの話はこんなところかな」

女「VLIWの話の方が多かった気がする」

男「スーパスカラの考え方自体が簡単だからな」

女「一気に複数の命令を同時に実行しちゃおうってことだよね」

女「たくさんの人が頑張ってる感じかな」

男「そうだと言ってやりたいが、それだとマルチ・コアと被るから、個人的には千手観音のイメージかな」

女「マルチ・コア……？」

男「マルチ・コアはとりあえず置いといて、プロセッサは複数の演算器を持っているが、それは人ではなく手のイメージってことだ」

女「ふーん？」

>>21あたりからついていけない

>>48
パソコンのメモリ上にはAをしてBをしてCだったらDそうじゃなかったらEっていう手続きがずらっと書いてある
それをその手順の通り何も考えずに一つずつ実行していくのがインオーダ・プロセッサで>>21に書いてあること
パイプライン化は
していない場合：プロセッサはAの命令を読み込んで解釈して実行して結果を出す、というプロセスの後、Bという命令を読み出す。
している場合：Aの命令を読み出し終えて、解釈しはじめると、同時に次のBという命令の読み出しを始める。Bの読み出しとAの解釈が終わると、Aを実行して、Bを解釈して、Cを読みはじめる。
ここまでが>>28

>>21から分からないと言われると一番知ってもらいたいプロセッサの話だから悲しい
もう少し練り直してみるかなあ

女「ねえ」

男「なに？」

女「やっぱりインオーダ・プロセッサの説明もう一度聞きたい」

男「む、分かりにくかったかな」

女「えーっとプログラムを順序通り実行することとパイプライン化してるっていう話だったよね」

男「うむ」

男「んー途中でレジスタの話とかをはさんだのが失敗だったかな……、すっかり言い忘れてたのがいかんかったか」

男「とりあえずじゃあ、プロセッサの役割の復習と、その内部構造について説明しよう」

男「プロセッサの役割は"プログラムを読み出して色々頑張って実行する"だったな」

女「うん」

男「ではそのために必要な要素、内部構造について考えていこう」

女「必要な要素ねえ」

①
男「メモリから命令を読み出すためにはメモリのどこに命令があるかを覚えておく必要があるよな」

女「そうだったね。それにレジスタっていうのを使うっていう話だったよね」

男「そう、いくつかあるレジスタのうちの一つをそのためだけに割り当てるわけだな」

男「1つの命令を読み出し終えたときに、そのレジスタに書かれた値を一つ増やすことによって、次のタイミングで読み出される命令は今読み出した命令の次の命令になるわけだ」

女「そのレジスタの値を増やすのには命令が要らないの？」

男「そういうルールでプロセッサが作られてるから要らない」

②
男「次に読み込んだ命令を解釈するためのデコーダ」

女「そういえば何も思ってなかったけど、機械が読める言葉を送ってるのに解釈する必要があるの？」

男「足し算をしろーって言われたら、手計算する人もいるし、電卓使う人もいるし、パソコンを使う人もいるだろ？」

女「そうだろうけど、それとなんの関係が？」

男「そのプロセッサにとってどの機能を使えばその命令を実行できるか、を解釈してるんだ」

女「ふむう」

③
男「で、その解釈に基づいて必要なデータをレジスタというプロセッサ用の記憶領域から読み出す」

女「これがさっき唐突に話の骨を折ったところだね」

男「悪かったって……」

男「レジスタからデータを読み出すと言ったけど、場合によっては命令中に直接計算に必要な数字が書かれている場合もあるな」

男「いずれにせよここで、計算に必要なデータを揃えるわけだ」

④
男「さて計算に必要なデータはすでに出そろっているわけだから、あとは演算器にその値をぶっ込めば計算をしてくれるわけだ」

女「演算器ってなに」

男「おおう、そこ分からずに聞いてたのかい」

女「なんとなく演算する機械かなくらいで聞き流してた」

男「その通りだけどな。演算器の具体的な構成の話はかなり複雑になるから、ここでは単なる電卓だと思ってくれればいい」

女「ふむふむ、でもメモリにアクセスできちゃうと」

男「うぐっ。いやまあそういう凄い電卓なんだって思ってくれ」

⑤
男「演算器を通れば演算処理が完了してるわけだからその結果を適切なレジスタに書き込むわけだ」

女「よく考えたらプロセッサの記憶領域に過ぎないレジスタに値があっても、外には出力されなくない？」

男「それはメモリに書き戻すのと同じ要領で、適切な出力装置に改めて書き戻すという命令を実行するわけだ」

女「とりあえずプロセッサのレジスタ上で計算して、計算が全て終わったら別の命令を使って適切な出力場所に返す、と」

男「うむ」

男「以上がプロセッサが1つの命令を実行する流れだな」

女「分かったような分からないような」

男「ちなみに①から⑤はパイプライン化の各項目に対応している」

女「おお、ほんとうだ」

男「パイプライン化しないとき、2つの命令を処理するためには一つ目の命令が⑤まで終わると二つ目の命令が①の段階に入るわけだが」

男「パイプライン化をしていると一つ目の命令が②の段階で二つ目の命令は①の段階に入ることができる」

男「図で書くとこんな感じだな」

パイプライン化無：
1①②③④⑤
2①②③④⑤
パイプライン化有：
1①②③④⑤
2①②③④⑤

女「最初からこの図を使えば良かったのでは」

男「あくまで口頭で説明しきりたい気持ちがあった」

男「図を見れば分かる通り、パイプライン化すると合計6コマで終わることが、していないと10コマかかるわけだ」

図の修正
パイプライン化無：
1①②③④⑤
＿＿＿＿＿2①②③④⑤
パイプライン化有：
1①②③④⑤
＿2①②③④⑤

男「インオーダ・プロセッサの話とパイプライン化の話はこれで大丈夫かね」

女「わたしは多分大丈夫かな」

男「女以外に誰かいるのか？」

何回か読んだらなんとなく理解できた気がする
こういうの有難いな

>>62
情報系出身でもプロセッサ周りの話は嫌がる人が多いから悔しくて書いてます
本編の大半がパソコンを使う上では役に立たない知識だと断っておきます

男「さて話が前後したから少しだけまとめようか」

女「パソコンは主に入出力装置、主記憶装置、演算装置から構成されていて、今回は演算装置、プロセッサを主軸に話を進めているんだよね」

男「うむ」

女「最新のプロセッサについて説明をするために、基本的な作りのプロセッサから説明をしている最中……なんだよね？」

男「その認識で正しい。では、プロセッサを構成する主な部品を、とりあえず2個、役割と一緒に挙げてみよう」

女「ええー……、プロセッサの記憶領域であるレジスタと、計算とか色々する演算器？」

男「今回登場回数が多かったのはその辺りだな。ほかには命令を解釈するデコーダや、敢えて正式名称を出していない"命令がどの位置かを記憶している特殊なレジスタ"が出てきたな」

男「さて、これまで説明してきたプロセッサはどんなものだった？」

女「えーっと、最初が単にプログラム順に一つずつ命令を実行していくのインオーダ・プロセッサで、次がプログラム順に複数の命令を同時に実行していくのスーパスカラ・プロセッサ、だよね」

男「その通り。あとはスーパスカラ・プロセッサの対抗馬だったVLIWというのも説明したな」

男「これらすべてに共通して施されている高速化の工夫は？」

女「パイプライン化だよね」

男「完璧」

男「ではようやく現代のプロセッサ、OoOスーパスカラ・プロセッサの話だ」

女「OoOってなんだっけ……」

男「Out-of-Order、アウトオブオーダだな」

女「故障中？」

男「残念ながら違う。が、流石に英語は詳しいな」

女「君の英語力がなさ過ぎるんだよ」

男「ぐっ、それは否定できないな」

男「OoOは故障中ではなく文字通り順序を無視したって程度の意味だ」

女「In-orderに対応してるって言ってたのを今思い出したよ」

男「ちゃんと話を聞いて覚えてるから女は偉いよな」ﾅﾃﾞﾅﾃﾞ

女「ふふふふん」

女「あれ、でもプログラムは順序を守って実行しないといけないんじゃないんだっけ？」

男「その通りなんだけど、その通りじゃないんだ」

女「分かりやすく言ってよ」

男「ご飯を炊きながらでも煮物は作れるだろってことだな」

女「この話を聞きながらでも夕飯は作れるよってこと？」

男「そういうこと。というかもうそんな時間か」

女「夕飯食べていくよね？」

男「ん、じゃあいただきます」

男「俺が女の手だったとして、俺が米を洗うことと、女が野菜を切ると言う作業はレシピ的には不連続に書かれたことだが、並行して行うことができる作業だよな」

女「ん、なるほど」

男「順序通りでなければならないものとそうでないものがあるから、順序通りでなくともいけるものを探してできるものはできるだけ早く並行して実行するのがOoOスーパスカラなわけだ」

女「分かったから手を動かして」

男「おっとゴメン」

女「君との話は楽しいけど、落ち着いて話せるときに話したい」

男「……」

女「なんでそこで黙っちゃうの？」

男「照れる」

女「かわいい」

男「いただきます」

女「どうぞ」

男「……」

女「……どう？」

男「美味いです」

女「なんで敬語なの？」

男「いや、なんか色々と嬉しくて」

男「自分のためにご飯を作ってくれる人がいて、その人が一緒にご飯を食べてくれて」

男「そんでもってその人が俺を好きでいてくれると言うのがなんかこう、なあ」

女「君はわたしのこと好きじゃないの？」

男「……好きです」

女「ならそう言ってよ、わたしばかりが君を好きみたいなのは、、なんかこう、なあ」

男「わかった」

男「さて、OoOスーパスカラについて身を持って体験してもらったところで」

女「素直にごちそうになったところでって言えば良いじゃない」

男「ご馳走さまでした」

女「お粗末様でした」

男「OoOの技術的な話をしよう」

女「大変そう」

男「大変なんだよなあこれが」

男「スーパスカラのときは細かい話をしなかったが」

男「並列実行可能かどうか、は後続の命令が先に実行される命令の実行結果を使うかどうかによって判断するんだ」

男「これは後続の命令が読み出すレジスタの番号と、先行する命令が実行結果を書き込むレジスタの番号を一致比較することで行う」

女「一致してるということはその結果を使うから同時には実行できない、と」

男「うむ」

男「単純なスーパスカラのときは先頭の命令から最長でそのプロセッサが並列実行可能な距離だけ離れた命令を比較するだけ」

男「具体的には4～8程度の命令についてソースとなるレジスタ番号と書き込み先、デスティネーションとなるレジスタ番号を比較するだけだったわけだ」

女「単純ってインオーダのときは、だよね」

男「うむ、OoOとなるとさらに遠くまでその比較を行う必要がある」

女「どのくらい見るの？」

男「理想的にはプロセッサが並列実行可能な数だけ命令が見つかるまでだな」

男「だが命令は普通メモリに格納されていて、ほとんどの命令はプロセッサからは見ることができない」

女「メモリ内にある命令はプロセッサには見えないの？」

男「うむ。次にメモリのどこを読めば良いかは分かっていても、その中身は読めるまで全く分からないんだ」

男「だからプロセッサはさっき言ったような比較処理を行うために発行キューという命令を蓄えるバッファを持つ」

男「ここに数十の命令を溜め込み、その中から同時に実行可能なものを探す。これがOoOスーパスカラのやってることだ」

女「バッファ？」

男「日本語に訳すと緩衝とかだな」

女「それは分かるけど」

男「あまり深い意味はないと思うが、情報系の用語としては"とりあえずモノを蓄える何か"って感じかなあ？　少なくともここではそう思っててくれ」

女「今回はそのモノが命令で、何かと言うの部品なのね」

女「色々な教科の教科書を並べてそれぞれを先頭から同時に読み込んでいく感じかな」

男「例えば数学について単元毎の参考書を並べて、三角関数、対数、微積分を同時に勉強する感じかな」

女「わたしの言った例と大差ない気がするんだけど……」

男「より近い作業の中で異なる部分を見つけてるってことだ」

女「そういうものかなぁ」

男「さて、OoO実行する上で大きな問題があるんだ」

女「どんな？」

男「その答えはVLIWのときに一度言ったことなんだが」

女「うーん？」

男「発行キューに数十の命令を蓄えるためには数十先の命令まで正確にどこから読むか分かってないといけないよな」

女「うん……あ」

男「気付いたか？」

女「プログラムの20%が分岐命令だからどこの命令を見ればいいかはせいぜい５、6個しか分からないんだ」

男「その通り」

女「じゃあどうやって数十個の命令を溜め込むの？」

男「分岐予測って技術を使うんだ」

女「でも実行するまで分岐結果は予測できないからVLIWは流行らなかったんでしょう？」

男「実は分岐予測はプログラム生成時点で8割程度の精度で予測できるんだけどな」

女「君は嘘つきだな」

男「8割程度の精度では分岐命令の出現頻度を考えたら意味ないけどな」

女「8割あってても駄目なの？」

男「5回に一度分岐すると言うことはおよそ15個の命令を読むために3回の分岐が現れる」

男「1回の予測精度が8割と言うことは、3回全てが正しく予測できている確率は、0.8x0.8x0.8 = 0.512だな」

男「30個先の命令を正確に読み取れる確率はおよそ1/4になる」

女「……確かに」

男「個人的な感覚では予測精度は99％くらいまで上がらないとOoOスーパスカラでの性能向上は見込めないな」

女「そんなに予測精度あげられるの！？」

男「プログラムによるが、多くのプログラムはできるな」

男「例えば分岐命令で多いパターンにループの脱出条件がある」

女「わたしはプログラムを書かないのでループとか脱出条件と言われてもうっすらしか分からない」

男「イメージ通りだと思うが、例えば次の構文を例にしようか。右側はプログラムの説明な」

i = 0;　　　　　　 // i を0にセットする
while (1) {　　　　// breakされるまでwhile(1){ }で囲まれた部分を繰り返す
　if ( i == 10 ) {　 // i が10だったらbreakを実行
　　break;
　}
　i = i + 1;　　　　 // i に1を加える
}　　　　　　　　　// while文の終了

男「このプログラムは分かるか？」

女「iを1ずつ足していって、10になったらループを抜ける？」

男「そう」

男「例えばこの構文ならば、常にifの中が不成立だと予測しておけば予測精度は9割だ」

女「うん」

男「常に成立あるいは不成立だと考えられる分岐もある。抽象的な書き方をするが」

x = Select 0 or 1;　　　// xに0を入れるか1を入れるか選ぶ
while(1){
　if ( x == 0 ) {　　　　 // 0が選択されていたならば実行
　　...
　}
　if ( x == 1 ) {　　　　// 1が選択されていたならば実行
　　...
　}
}

男「こういうプログラムであれば、一方は常に不成立だが、一方は常に成立するよな」

女「こういう分岐なら一方を成立、一方を不成立と正しく予測すれば予測精度は10割だね」

男「そういうことだな。つまり分岐命令毎にどちらになりやすいかを記録しておくことが重要なわけだ」

男「1つ目の10周したら抜けるという例はプログラム生成時の予測で9割正確に予測できるが」

男「2つ目の例はプログラム生成時には予測できないってことは分かるか？」

女「Selectって部分でユーザによって入力されるから？」

男「そういうことだ。0になるか1になるかはユーザ次第で五分五分というわけだな」

男「だから生成時の予測では5割しか当たらない」

女「むう、確かに」

男「しかし実際にフタを開けて実行してみれば、一方は常に成立、もう一方は常に不成立だ」

女「そうだね」

男「これを予測するために必要なのはそれぞれの分岐の実際の実行結果の履歴だ」

女「前回が不成立だったから今回も不成立ですって言う感じにするの？」

男「大雑把にはそんな感じだな」

女「大雑把にはということは厳密には違うと」

男「実際に過去一つ分の結果だけを見る方法があったのは事実だが、それでは結果が交互に入れ替わるようなパターンとかをとらえられないだろ？」

女「分岐ってそんな色々なパターンがあるの？」

男「プログラマ次第だが、あるにはある」

男「そこで静的に同一な分岐命令毎に一定数の分岐結果の履歴を記録するローカル分岐履歴表というものを用意する」

女「性的に同一？」

男「なんでちょっと赤くなってるんだ？　静的に同一ってのは、例の if 文はループ中に何度も呼ばれているが、テキスト上では同じ if 文だろ。これが静的に同一な分岐命令だ。静的にという言い方があるのは同じ if 文でも呼ばれたときを区別する言い方として動的に異なる命令と表現するからだ」

女「動的に同一はないの？」

男「それはつまり全く同じ命令だな」

女「プログラム上で何度も呼ばれることのある一つの分岐命令が静的に同一な分岐命令？」

男「そう。実行中は何回も出現するが、テキストの上では一つしか存在しない分岐命令」

男「で、このローカル分岐履歴表にいくつかの履歴を覚えておくことで過去の挙動を知り、次の挙動を予測するわけ」

女「ローカルって言うってことはグローバルもあるの？」

男「うむ。グローバル分岐履歴表は全ての分岐命令の履歴を一つのFIFOで構成するんだ」

女「ふぁいふぉ…？」

男「それもダメか」

女「君はわたしを馬鹿だと思っているでしょ」

男「そんなことはない、むしろ凄い人だと思ってる」

女「むー」

男「でFIFOのことだが、これはFirst In First Outの略だ」

女「最初に入って最初に出る？」

男「そう、要するに待ち行列、キューだな。最初に並んだ人が最初に抜けられる」

女「最初からそう言えば良いのに」

男「世間一般がどうかは知らないが、この界隈ではFIFOで通じるんだよ」

男「話を履歴表に戻すが、この履歴表に記録されたパターンと自分自身がどの分岐命令であるかという情報を使って」

男「分岐予測表を参照することによってパターンと分岐に対応した分岐予測を得ることができる」

女「おおー」

女「あれ？　でも結局どの分岐命令かって情報が必要ならローカル分岐履歴表だけで良いのでは？」

男「ふむ、鋭い」ﾅﾃﾞﾅﾃﾞ

女「ふふふふふん」

男「ローカル分岐履歴表の欠点は冗長性だな」

男「静的に同一な分岐命令について記録する為に多くの領域を用意するが、余る可能性が高いし、余らなければ競合する可能性が高い」

女「競合するの？」

男「資源を無限に用意するわけにはいかないから、現実的には分岐命令をハッシュするわけだな」

女「ハッシュ……？」

男「無限の値を適当な範囲に割り振ることだとでも思ってくれ」

男「例えば100で割ったときの余り0～99までのどれかに当てはめる、とかな」

女「分かったような気がする」

男「その点、グローバル履歴表はそもそも一つの履歴表しか持たないから」

男「不当に遠い履歴を永遠に持つこともないし、省資源なわけだ」

女「んーなるほど？」

男「どこかの研究によればそれぞれの履歴表を理想的に実装した場合の平均的な予測精度はそれぞれ97%、96%くらいらしい」

女「99%にはいかないんだねえ」

男「色々なプログラムを合わせた平均だからな。ほとんどが99%で一部が平均を下げてるって感じなのだろ」

男「ま、俺も分岐予測周りは詳しくないんだけどな」

女「これで詳しくないのかあ」

男「複数の分岐命令が同時に来た場合とか、そもそも非連続な命令列を同時に読み出すためのトレースとか」

男「分岐予測周りには色々と雑務がついて回るからな」

女「大変なんだねえ……」

男「だな。今言った形式以外の分岐予測も色々とあったと思うから気になるなら自分なりにやり方を考えると楽しいかもな」

男「さて、分岐予測の話をしたけれども、予測に基づいた投機実行をするってことは」

男「投機に失敗したときのことを考えてフォローするための手続きが必要だよな」

女「ん、確かに」

男「しかも今はOoOっていう非常に複雑なことをやっているわけだ」

男「例えば、俺が前もって女に誕生日プレゼントを用意したら、渡すよりも前に全く同じものを女が買ってしまったとしよう」

女「あらら」

男「そうすると俺はそのプレゼントを泣く泣く破棄して、新たに別のプレゼントを用意するわけだ」

男「つまり俺は、万が一に備えてもう一度プレゼントを買い直すだけの資源=金を持っておく必要があるわけだな」

女「いや、そこまでしなくとも・・」

男「いやする」

男「プロセッサで言うところの資源とはデータだな」

女「レジスタの値を分岐予測が完了するまで保持するってこと？」

男「半分正解で半分外れ」

女「むむむむ」

男「分岐予測は次から次に現れるから、それを全て終わるまでなんて待っていたらプログラムが終了するまでレジスタを解放できないからな」

男「ここで重要になるのが論理レジスタと物理レジスタって概念だ」

女「論理レジスタは前もチラッと出てきたね」

男「論理レジスタはプログラム上で使用されるレジスタで、物理レジスタは実際のプロセッサ上でのレジスタだな」

男「例えば静的に同一な命令は全て同じ論理レジスタを使うわけだが、呼ばれる都度に異なる物理レジスタを使うんだ」

女「？？？」

男「論理レジスタをL○として

L1 = L1 + L2

という命令があったとしよう」

女「L1とL2を足した結果をL1に代入する、だよね」

男「そう」

男「ここで物理レジスタ番号をP○として、さっきの命令を2回連続で実行したときの物理レジスタは

P3 = P1 + P2
P4 = P3 + P2

こんな風に割り当てられる」

女「L1がP1、P3、P４になってる？」

男「そう。で、論理レジスタが最新では物理レジスタの何番に割り当てられているかを覚えている表がえーっと、なんて名前だったかな……まあそういう表があるんだ」

女「記憶力はほんとに怪しいよね」

男「はははは」

男「ま、まあとりあえず、最新のL1が何であるかと最古のL1が何であるかさえ分かっていれば、過去と未来を繫ぐことができるんだ」

女「意味分かんないよ？」

男「ちゃんと説明はするが若干長くなるのと、反復を覚悟してくれ」

女「ここまででも何度も頭の中で反芻してるのに」

男「プロセッサにはRe-Order Buffer(ROB)というFIFOがあってな」

男「発行キューでは実行可能順に命令が発行、実行されていくが、ROBは読み出したときから読み出した順に実行終了した命令を吐き捨てていくんだ」

女「命令を吐き捨てるだけの部品？」

男「例外が発生しない限りはそうだな」

男「例外さえなければROBはただプログラム順に命令を捨てていく部品だ」

男「そしてそれはつまり、そこまではプログラム的に正しく実行できたことを保証するわけだ。これをコミットと言う」

女「例外が発生すると？」

男「プロセッサを例外が発生する前の状態まで戻す」

女「それをどうやってやるのって訊いてるのだけれど」

男「逆なんだな。ROBが命令を捨てたときに情報を捨てるんだ」

女「その説明分かんないからね」

男「むう……」

男「さっきのL1がP1、P3、P4に割り振られた例で

仮に1行目のP3 = P1 + P2が実行されてROBからコミットされたとすると」

女「ふむ」

男「この時点でP1はもうL1として使われることは絶対にないよな？」

女「ちょっと待って落ち着いて考える」

女「えーっと、1行目が破棄、コミットされた時点でプログラム順に一番古いL1はP3ってことになる、、のかな？」

男「その通り。だからP1はもうL1として呼ばれることは絶対にないんだ」

男「さっき言った最新と最古のL1が分かっていれば良いってのはそういうことな」

女「ROB内で最古の論理レジスタに対応する物理レジスタを保護しておけばいかなる例外にも対応できて、最新の論理レジスタに対応する物理レジスタが分かっていれば新たな命令がどの物理レジスタからデータを得れば良いか分かる、か」

男「そういうことだな。あと間についてはメモリから読み出された時点で最新の対応する物理レジスタ番号を記憶しておけば良いってことだ」

女「ちょっと待って」

男「なんだ？」

女「結局、ROB内にある情報がいまいちよく分からない」

男「おっと、具体的な話をしてなかったな。ROBが持つ情報は主に、"自分の書き込み先の論理レジスタ番号"と、"自分と同じ論理レジスタに書き込む命令が使った物理レジスタ番号"だな」

女「えーっと、ROB内に記録されている物理レジスタの内容は保護されていて、具体的な意味としては、ROBに書かれているということはまだ使われる可能性がある物理レジスタだということ？」

男「そういうことだ、そういうのを理解した上で、さっきまでの話を思い返してみると良い」

男「レジスタ周りの話はROBさえあれば解決できるが、メモリ周りはそうもいかない」

女「メモリの内容もコミットされるまでメモリに反映してはだめってことだよね」

男「その通り」

男「だからwrite bufferなるバッファを用意して、コミットと同じタイミングでメモリに書き込み結果を反映するんだ」

男「さてここまでで話をちょっと整理すると」

女「OoOスーパスカラ・プロセッサは

・本来のプログラム順とは無関係に命令を実行する
・そのために多くの命令を同時に見るための発行キューを持つ
・そして多くの連続した命令を正確に読み出すための分岐予測機構を持つ
・投機ミスの補償を行うための回路を持つ

ってところ？」

男「さすが女、賢い」ﾅﾃﾞﾅﾃﾞ

女「ふふふふふふん」

男「そろそろふが多い」

女「むう」

男「さて、OoOスーパスカラ・プロセッサという話は概ねの話はこれで終わりだ」

女「長かったぁ」

男「しかしプロセッサはまだまだ多くの問題を抱えているからな」

男「更なる高速化についてみていこう」

女「その前にまたティーブレイク！」

修正しながら投稿した結果、修正が必要になると言う悪循環
ちょくちょく言葉がおかしい
直近だと
「という話は概ねの話は終わりだ」→「の話は概ね終わりだ」

凄く勉強になる
CPUの作り方(メイドの本)にはこんな詳しいこと書いてなかったしそもそも対象読者が違ったからな～
x86SIMDとかARMのthumb2とかどうやってやってるのかさっぱりだし
使い方はわかってても中はブラックボックスだからな

こういうの勉強するうえで参考にした書籍,サイトって何かありますか?(なるべく日本語がいいな)

あとFPUの原理つまり浮動小数演算をただのトランジスタでどう実装してるかが長年の疑問
まさか全加算機だけをガチャガチャやってるわけじゃないでしょ?

>>95,96
ふええ、まさか真面目にCPUを扱ってる人がくるとは思ってなかったです……
読んだ本については、
インオーダ・プロセッサについては
パターソン&ヘネシー著『コンピュータの構成と設計』第4版上下巻
スーパスカラ・プロセッサやVLIWについては
安藤秀樹著『命令レベル並列処理-プロセッサアーキテクチャとコンパイラ-』
です。ここまでのことなら全てこれらの本にもっと詳しく書いてあります。
2冊目の本は、パタヘネの上巻（3版以前なら下巻の途中）程度までを理解したうえで読まないと難しいかもしれません。

具体的なFPUの実装の話は聞いた記憶がない（もしかしたら授業を寝ていたかも）ですが、FPの処理は和や差は指数部を元に仮数部をビットシフトして計算をするだけだと思います。
積や商は指数部の和と、仮数部の積をとるだけだと思います。
シミュレータ上でもFP系命令の実行サイクル数はINT系に比べ数倍長いので、テクニカルなことはせず素直に計算していると思います。
こういう解答で良いでしょうか？

自分自身まだ勉強中の身なので、知らないことも多いです
SIMDの実装も知らないですし、thumb2は今初めて聞きました
自分なりのSIMDの実装に対する考えは、xワード分のデータを格納できる特殊なレジスタと、その長さ分のデータを入力できる一つの演算器で構成されているのだと思います。
演算器ないでは1ワード毎に繰り上がりをカットすれば2入力x出力を実現できるという寸法です。
ただ、プロセッサと言うのは思いのほか色々な作りになっているそうなので、命令セットがしっかりしていてきちんと入出力できれば、細かいことは知らなくとも良いのだと思いますよ。

>>97
レスありがとう
明日丸善で探してみる

あとlogとかexprとかsinとかの命令はやっぱり中でテイラー展開して加減乗に落としてるんですかね

>>99
自分が使っているシミュレータの命令セットを見る限りlogやexp、sinらしいのは見当たらないですね
平方根ぽいのはありますが
RISCの考え方からしても恐らく、計算の多くはソフトウェアで頑張る方針なのだと思います

>>100

x86 FPU 命令 とかでググったらfyl2xとかあって内部でlog2(x)を計算してるようにしか見えない
英語斜め読みだから自信ないけど
log2xの場合，log2(仮小数部)を求めてるときにテイラー展開以外の方法なのかなって事を言いたかった

バッファってどこに持つんですか？レジスタ？メモリ？
メモリに置くならアクセスの遅さは解消できないしレジスタなら無駄遣い極まりない気が

机がメモリならレジスタは手みたいなもんですかね

>>101
おおう、本当だ・・早々に嘘をついてしまったかな・・・
確かにFPUの詳細を見るとlog2xを計算できるようですね
そうだとすると演算器が中でどんな風にlogの小数部を処理しているか、は全く勉強したことがないです
力及ばずですみません
先ほど紹介した本にも演算器についても全加算器程度の説明しか載っていなかったと思います（もしかしたら全加算器すら載っていなかったかもしれないです）

>>102
>>32の最後の行にちらっと書いたように、最近のプロセッサというのは計算の補助のための回路を大量にもっています
ROBや分岐予測表、分岐履歴表、発行キューと言った、ここまでで出てきた部品は全てプロセッサのチップ上にレジスタとは別に置かれています。（今後出てくるかも知れない部品も特に断りがなければチップ上におかれています）
ただ、その構成は全てSRAMなので構造的にはレジスタと同じです。
プロセッサの計算速度と消費電力の比で考えるとインオーダ・プロセッサの方が高効率だという事もよくあります
しかし圧倒的にOoOスーパスカラ・プロセッサの方が速く、そして今の時代においては多少の電力を犠牲にしても速さを求める傾向があります
例としてはスマートフォンとガラケーで、スマホの方が売れている、とかですね

手、というと記憶領域の表現に少しそぐわないかもしれないと思いつつもでもそれくらいの距離感ではあります
レジスタは手の平の上のメモですかね。

>>104
フォワーディング機構がSRAMなわけがない…
表、バッファ、FIFO、キューと呼ばれるものはSRAMです

また嘘書いたよ…
厳密に単純なFIFOならばランダム・アクセスできないからSRAMじゃない
ただ、ROBは多くの場合SRAMで構成されていると思います
理由は例外の書き込みなど、必ずしも先頭または最後尾ではない位置へのアクセスが発生するからです

発行キューのプロセッサの処理可能な命令の数っていうのはつまりパイプラインの段数ってことですか？
と思ったけどパイプラインはインオーダの機構でOoOには関係がないのか？

グローバル分岐表って過去の自分のデータが出るまでoutを連打することになるからすぐに枯渇するのでは？

なんだか大量にしょうもない質問をしている気ががが
一度勉強してみようかな

>>107
並列処理とパイプラインは直交してるので並列実行可能数とパイプライン段数は無関係です
発行キューから発行（実行可能な命令を演算器に送ること）可能な命令数はプロセッサの設計時に、消費電力や搭載している演算器などとの兼ね合いをみて設計者が自由に決定することができます
細かい話は省略しますが、発行キューのパラメータは全てプロセッサの消費電力に大きく関わってくるのでこの辺りの数字はかなり慎重に決められていると思います

自分の実験環境下では3〜4の発行幅を想定する事が多かったですね（これが適切かは検証した事がないですが…

演算器が複数ないと並列に命令を実行できないのでは？
分業することで実質並列というのはわかるんですが……

>>108
グローバルの方の説明がかなり雑だったなあと反省中
1ループ中に実行される分岐命令は多くの場合数個程度だと思います。
そして、グローバル分岐履歴表はローカル履歴のように個々の分岐毎にテーブルを用意する必要がないので長めに確保できます。
なので、履歴表は数回〜数十回分のループの履歴をもつことができると思います
で、そのグローバル履歴そのものと分岐命令のアドレス（命令が格納されてた方のアドレス。飛び先のアドレスではない）を結合して分岐予測表を参照すると過去に同じパターンで静的に同一な分岐命令がどんな分岐結果を出したかが分かります。
もし、1ループ中でグローバル履歴が枯渇してしまえばまあうん。目も当てられないです。ですが、先にも書いた通り、グローバル履歴は一本に統一してる分長めの資源を確保しやすいです。

ふふふ、勉強してもらえるならそれは既に僕の術中に嵌っているということなのです（嬉しい）

>>110
本編中では一切断ってなかったので分かりづらかったですね…
スーパスカラ・プロセッサでは演算器は複数搭載されています。
あと、演算器と一言で言っても、大きく整数系、FP系、Mem系の3種類があり、実装によってはここからさらに論理演算用、和差用、積商用と別れることもあります。
全てを万能の演算器にしない理由は使用率などの点から無駄なコストになることを避けているんです

あー違う勘違いしてました
インオーダ→スーパスカラ→インオーダ再び
の流れでスーパスカラの内容が頭からすっ飛んでた

スーパスカラは同時実行可能的なことが書いてありますね

>>113
可能って書いただけでその根拠は書いてなかったのでこちらにも大分非があります
やっぱり1日2日で適当に書いてさらにそれを修正しながら上げるなんてことはやるべきじゃなかったかも知れないと反省中

RoBは並列実行可能な処理系ごとに存在するってことであってますかね

あのー……分岐予測表ってなんぞいや

RoBによって命令レベルでのロールバックができることはわかるんですが予測ミスをして別の分岐にとんだ場合に発行キューは一度リセットすることになるじゃないですか
その時にすでに完了してしまっている命令のロールバックってどうするんですかね

>>115
ROBは一つのコアに一つですね。今の場合はシングルコアを想定した話なので1つです。

分岐予測表は一瞬本編に出ている！一瞬は…
分岐予測表は名前の通りその表に対応する分岐命令の分岐予測（より正確には前回までに表が参照されたときの結果）が記録されている表です。
過去1回分の履歴を参照するだけならば、履歴表など用意せずに、静的に同一な分岐命令ごとの分岐予測表を参照すればいいわけです
ただ、交互に成立不成立を繰り返すような場合などをとらえるために、分岐予測表を見る前に履歴表を参照し、履歴表の情報を加えた上で、分岐予測表の参照先を考えることで、過去のパターンに応じた予測を可能にしています

>>116
プロセッサ中の状態を確定するために必要な情報は
・論理レジスタの値
・現在見ているプログラムの位置情報
・メモリのデータ状態
です。
そして、ROBで古い論理レジスタに対応する物理レジスタを保護しているため、論理レジスタはロールバック可能です
プログラムの位置情報はROBに合わせて記述されています（本編では説明が抜けていました）
メモリのデータ状態はwrite bufferによってコミットされていない命令はメモリを犯さないため問題ありません

エラー検出時にROBの後方にある命令についてはすべて破棄します。
発行キュー内や実行中、完了済みの命令については確かに破棄は難しいかもしれないですが、各々がどこかの物理レジスタに書き込んだとしても、ロールバックによってどの論理レジスタにも対応づけられていないため、特に問題ありません。

女「なんだか意味の分からない言葉が頭の中でぐーるぐる」

男「女、大丈夫か？」

女「テイラーさんがメイド服を着てブラックボックスに入ったらFP加算してコンパイラが頑張るるるー」

男「おい！」

女「履歴表はあくまで履歴であって予測してくれるわけではないー」

男「おい！」

女「ハッ！」

女「あれ、ティーブレイクは？」

男「いや、もう飲み終わったぞ」

女「お茶を淹れた記憶がないんだけどなあ」

男「さて、かなり最初の方で言ったことだが、メモリってのはプロセッサに比べるとかなり遅いんだ」

女「言ってたね」

男「だから本音を言えば、メモリへのアクセスもしたくない」

女「そんな無茶な……」

男「しかし思い返してほしいが、本来データはHDDにあるのに、ここまでHDDを意識することなくプログラムを実行できただろ？」

女「それはメモリにデータがあるっていう話だと思ってたから」

男「そう、数個のプログラムを展開する程度ならばHDDほどの容量がなくともメモリで十分だからということでもあるな」

男「さらに言うならば局所的にはメモリほどの容量すらいらないんだ」

女「ええー」

男「プログラムはループが多く、時間的局所性があるから、プログラム全体のなかでそのとき必要な部分ってのは意外に小さいんだ」

男「そしてその小さい中でループ処理をしたりするから、数KB～MBのメモリ空間があれば十分なわけだ」

男「そういう小さいメモリの代わりを果たす記憶領域をキャッシュと呼ぶ」

女「お金お金」

男「ちがう」

男「このキャッシュってのはプロセッサから見ると実質メモリに見えている空間だから、プロセッサというと違うような気もするけど」

男「距離の問題からプロセッサのチップ上に積まれるということもあって、やっぱりプロセッサなのかなと」

女「どっちなのよ」

男「……プロセッサかな」

男「このキャッシュ周りはけっこう複雑でさ」

女「ここまでも十分に複雑だったのだけれど」

男「なんか態度がツンケンしてきた」

女「こんな夜中に男女で二人きりなのにこんな話をしてるのかと思ったら悲しくなってきた」

男「あわわわ」

男「でもまあ女が最初に言った通り、ロマンのある話だよ？」

女「ロマンチックとロマンが違うってことはよく分かったよ」

男「ふえぇ……」

男「そのまあなんといいますか」

男「女のことは好きなんだけどさ」

男「こう、俺がチキンと言いますか」

男「何をすれば良いのか分からないんですよ」

女「……」

男「そのー……」

女「…っぷ」

男「？」

女「あははは、君はそうだよね！　うん、それでいいよ！」

女「わたしの好きな君はほんとに不器用だもんね」

男「褒められてない」

女「褒めてないからね」

男「えー、コホン」

男「では気を取り直してキャッシュの話をしようと思います」

女「お金は将来設計に大事だもんね」

男「そっちのキャッシュはおいおいね」

女「うん」

男「キャッシュはほかの記憶装置と同じく大きくなると遅く、小さければ早くアクセスできる」

男「プロセッサが1つ状態を進めるのを1サイクルとして、小さいキャッシュであれば2、3サイクル、大きなキャッシュでは10～20サイクル程度でデータを得ることができる」

女「メモリは？」

男「一般的には200～500サイクルくらいらしい。論文によってはもっと長く設定してあるものもあるが、結局はプロセッサとメモリの関係の話だから厳密にこうだとは言えないが」

女「そう考えるとキャッシュはすごく速いね」

男「うむ」

男「メモリ、というかキャッシュにデータを読みに行く命令をロード命令と言うが、このロード命令は一般的にプログラム全体の20%程度だと言われている」

女「分岐とロードだけで4割行っちゃったよ」

男「意外に往来のための資源が多いってことだな」

男「それだけの量があるから、その1回当りのアクセス・サイクル数は短いにこしたことはないわけだ」

女「まあ速い方が嬉しいよね」

男「もし、仮に1回でもメモリ、今後は敢えてメイン・メモリと言うが、にアクセスしようとした場合について考えよう」

男「比較的速い200サイクルで結果を得られるメイン・メモリだと考える」

男「発行キューの大きさはおよそ数十だと行ったけれども、例えば64個、ROBが128個の命令を保持できるとしよう」

男「でもって、1サイクルで最大4つの命令を読み出しと実行が可能だとする」

男「200サイクルの間に読み出すことができる命令数は最大で4 x 200 = 800だよな」

女「うん」

男「しかし、発行キューは800もない。もちろんROBもな」

女「でも200サイクルの間に実行できる命令は発行キューから消えるし、実行終了した命令はROBから順にコミットされていくでしょ？」

男「とりあえずROBについて考えると、少なくともメイン・メモリ・アクセスを行っているロード命令はその結果が返ってくるまでコミットできない」

女「あ、じゃあ800個もROBで命令を記憶しなきゃ駄目なのか」

男「ま、どうせ発行キューで止まるからROBの心配も必要ないけどな」

男「データは大抵チェーン状に連続して使われるから、どこかで止まると、その次も連鎖的に止まるんだ」

男「そうなると適当に用意した64個なんてすぐに埋まってしまうんだよ」

男「で、こういう資源のうちのどれか一つでも埋まり切ってしまうと、プロセッサ全体がストールして、ロードの結果が返ってくるのをまつわけだ」

女「そうなるとメイン・メモリには1回でもアクセスしたくないって思うね」

女「あれ、でも局所性があるとは言っても一回目にキャッシュにデータを読み込むためにはメモリ・アクセスが必要なんじゃ」

男「鋭い」

女「ふふ…ん」

男「どした？」

女「なんでもない」

女（撫でてもらえると思った自分が恥ずかしい）

男「そんなわけでキャッシュにも予測器をつけるんだ」

女「ここでも予測かあ」

男「色々な予測方法があるが、簡単なところだとストライド予測かね」

男「例えば配列の1番目２番目とアクセスが来たら次は3番4番とアクセスがくるだろうなーって予測する」

女「配列とは」

男「おっとそうだったな」

男「配列ってのは複数のデータがメモリ上に1列に保存されている空間だ」

女「一列？」

男「そう。配列の一人目、二人目、三人目と言うような形でアクセスできる」

女「なるほど」

女「メモリ上で連続になっているから一人目、二人目と来たら次は3、4だと予測できると」

男「うむ」

男「実装もほかの予測器と大差はない」

男「静的に同一なロード命令に対して読み込んだアドレスを記憶する」

男「そして再び静的に同一なロード命令が実行されたとき、新たに実行されたロード命令のアドレスと古いロード命令のアドレスの差分をとり、その差分も合わせて記憶する」

男「さらに新しい静的に同一なロード命令がきたら同様にアドレスの差分を取り、今とった差分と前回とった差分の記録を比べ一致すれば、一定数ずつズレていると予測し、今回のアドレス+差分の領域のデータを事前に取得してくるわけだ」

女「一個しか取ってこないのはもったいなくない？」

男「取ってくる数については、プロセッサ設計の段階で決定するみたいだな」

女「じゃあ必ずしも1つではないんだ」

男「おそらく」

女「君はここまでの説明全部に若干自信なさげだよね」

男「記憶力には自信がなくてなあ。正直こういう方式があるのは覚えてるんだけど、本当にストライド予測って名前だったかも覚えてない」

女「え」

男「この手の予測は連続するミスには対応できるが非連続なミスには対応できないんだよな」

女「非連続なミス？」

男「んー、ぱっと分かりやすい例が出ない」

男「さっきまでは配列の上から順にアクセスすると言っていたが、」

男「例えばアクセスする番号をランダムに決定したとしよう」

女「なんでそれが必要なのかは分からないけど、まあ確かに非連続なメモリ空間にアクセスするね」

男「非連続なメモリ・アクセスが発生すると予測することは困難だよな」

女「ランダムだと言ってるのに予測できたらランダムじゃないものね」

男「うむ、全くその通りだな」

男「だが、やはり止まるのは極力避けたい」

女「数百サイクルも止まるって聞くと流石にね」

男「しかも非連続で毎回ミスするとしたら、もう目も当てられないだろ」

女「うわあ、確かに……」

男「非連続なメモリ・アクセスを完全に消滅させることは不可能だが、」

男「複数のメモリ・アクセスを並列に実行して、アクセス時間を隠蔽する事は可能だ」

女「んん？　いまいち分からない」

男「パイプライン化のときと同じような考えだな」

男「また図を出すぞ。1、2はメモリ・アクセス、Sは資源不足でプロセッサ全体がストールしてる期間だ」

駄目な例：
1┠────────┨
. 　　　S┠───┨　　　
.　　　　　　　　　　　2┠────────┨
良い例：
1┠────────┨
. 　　　S┠────┨
.　　2┠────────┨

男「こういう風にプロセッサが完全にストールする前に2つ目のメモリ・アクセスを実行できれば、全体の実行時間を縮めることが可能だろ？」

女「確かにね」

男「この手の手法はプロセッサ業界ではかなり熱心に研究される分野なんだよ」

女「……へー」

ああ半角スペースは問答無用で消えるのか・・・
駄目な例：
1┠────────┨
______S┠───┨
_____________2┠────────┨
良い例：
1┠────────┨
______S┠────┨
___2┠────────┨

また全然上手く書けてねえ・・・もう嫌だ
1┠────────┨
＿＿＿S┠───┨
＿＿＿＿＿＿2┠────────┨
良い例：
1┠────────┨
＿＿＿S┠────┨
＿2┠────────┨

図は諦める。気持ちで読み取ってください。

男「退屈そうだな」

女「……そんなことないよ？」

男「って、眠いのか」

女「……大丈夫大丈夫」

男「いや、明日も休みとはいえ、こんな時間まで話し込んじまったな。すまん帰るわ」

女「……帰ったら怒るよ」

男「怒る前に寝そうじゃねーか」

女「……泣くよ」

男「あー、分かったから、泊まるから泣きそうな顔やめてくれ」

女「……よろしい」

男「……」

女「……話続けないの？」

男「寝るのには邪魔だろ」

女「……良い子守唄になる」

男「失礼だな」

女「……君の声は心地いいからね」

男「そう言われると悪い気はしないが……」

女「まあ君も一緒に寝ようか」

男「女はベッドで寝ろよ」

女「？　君もベッドで寝るんだよ？」

男「え」

女「……嫌なの？」

男「ちょっと本能と戦うわ」

女「……負けても大丈夫だよ。慰めてあげるから」

男「そういえば風呂入ってない」

女「…………」

男「そこは真剣に考えるんだな」

女「……今わたしくさい？」

男「ちょ、近い」

女「……くさいのかな。。」

男「そんなことない、良いにおいだって」

女「……えへへへ」

女「……じゃあ大丈夫らねえ」

男「呂律も回ってない……」

女「ねー、君と本能の戦いは今どんな感じなの？」

男「待て、それ以上近づくな。やめろ」

女「……負けそうになったら教えてねえ」

男「うあぁ……背中にひっつくのは反則だろ……」

おやすみ

丸善いってパタヘネ本見てきました
しかし値段高すぎだろ(白目)

乙

>>143
パタヘネについては図書館で済ませるくらいで良いかもしれない
あれは趣味で買おうと思えないレベルの値段と厚さですね・・

ﾁｭﾝﾁｭﾝ

男「……これが世に言う朝チュンか……」

男「なんもしてねーけど」

女「・・おはよう」

男「おはよう」

男「さて、」

女「君のたくさんのおっかけをどうしようかという話？」

男「俺をどんな人間だと思ってるんだ」

女「モテモテな男」

男「そう思ってるのは女くらいだからな」

女「わたしの見る目が高いからね」

男「女の見る目がないんだろ……」

男「さて、メモリ上で不連続なデータへ連続してアクセスするということはプログラム的にはままあることなんだな」

女「昨日の話に戻っちゃうかー」

男「こういう状況を打破しよう方法の一つがrunahead方式だ」

女「先走り」

男「黙りなさい」

女「言ったのは男じゃない」

男「runaheadについて説明するぞ」

男「メモリ・アクセスが発生するとその間にプロセッサの資源は尽きてしまうことがほとんどで、そうすると普通はプロセッサが止まるわけだ」

女「そう言ってたね」

男「しかしもう少しだけ頑張って実行することができれば次のメモリ・アクセスをする命令を見つけることができる可能性もあるわけだ」

女「そりゃあ可能性はね」

男「だからもう少し頑張ろうという話がrunahead。原理自体は昨日図で簡単に説明したな」

男「runaheadモードに入る条件自体は自由に設定できるが、普通はメモリ・アクセスを起こした命令がROBの先頭に達したとき、らしいな」

男「このとき、プロセッサはとりあえずこのときのプロセッサ状態を全て記憶する。記憶方法はなんでも良いから、ここではそういう専用のバッファがあるとでも思っておこう」

男「で、仮にメモリ・アクセスの結果が0だったと仮定してプログラムの実行を無理矢理続ける」

女「そんなことしたら全然違う結果が出ちゃうのでは」

男「そのためにrunaheadモードになる直前の記録をとってあるわけだ」

男「仮の実行が終わったらまた開始地点まで戻れるようにな」

女「戻ることが分かってるのに先に進むの？」

男「さっきも言ったが、目的はちょっと先にあるかも知れないメイン・メモリにアクセスするロード命令を見つけることだからな」

女「でも実行がキャンセルされたら意味ないのでは？」

男「メイン・メモリからキャッシュにデータをコピーしておくことが重要だからな」

女「あ、キャッシュへのコピーはキャンセルされないんだ」

男「キャッシュはプロセッサ状態と関係ないからな」

女「そのプロセッサ状態って何なの？」

男「プロセッサ状態が同一であれば、何度実行しても同じ結果となる状態、かな。具体的には、

・論理レジスタの状態が全く同じ
・メモリの内容が同一
・プログラムの位置が同一

ならば何度実行しても同じ結果が出る」

男「色々な予測表の状態によっては多少実行時間に差はあるだろうがな」

女「ふーん？」

男「runaheadモードの間に、多くのメモリ・アクセスを行うロード命令を仮実行できれば、runaheadモードが終了したときにはキャッシュにその分だけ新たに必要なデータが揃っているわけだ」

女「何をもってrunaheadモードは終了するの？」

男「これも自由に設定できるが、開始との対応付けをするならば、開始のきっかけになったメモリ・アクセスが完了したら、だろうな」

男「一定サイクル数というような設定もできるし、次のメモリ・アクセスを見つけるまでと設定する事もしようと思えばできる」

女「へー」

男「個人的にはrunaheadは凄い画期的なロマンのある方式だと思うが、女には面白くなかったか」

女「まあ面白さは分からないね」

男「そうか。こういうのをMemoy Level Parallelism(MLP)を利用する手法って言って、プロセッサの性能向上を目指している人たちはこぞってこれを利用しようとしてるのに」

男「ほかの手法だとほかに＋αの専用回路を足す必要があるのに対して、runaheadは特に部品を足すことなくMLPを利用できるイケてる手法なんだけどなあ」

女「プロセッサ状態を記憶する専用回路を積むとか言ってたじゃない」

男「ここまででその説明をしてなかったからとりあえず専用回路と言ってしまったな」

女「専用ではないの？」

男「プロセッサ状態を記録するチェックポイントという回路があるな」

女「それはROBで状態を戻すのとは違うの？」

男「ROBを使えば確かに状態のロールバックは可能になるが、ROBを使う場合、コミットの直前まで予測ミスの訂正ができないんだ」

男「ROBはコミットされた命令の正しさを証明する部品だからな」

男「しかし実際には実行が完了した時点で状態のロールバックが必要ならばするべき、だろ？」

女「エラーだと分かっている処理を続ける必要はないね」

男「だからチェックポイントはエラーが発生しうる命令が読み出されるされる度にプロセッサ状態を記憶して溜めるんだ」

男「そして実際にエラーが発生したら、対応するチェックポイントからプロセッサ状態を即時復元する」

男「これによって無駄な実行数を減らすわけだな」

女「なるほど」

男「runaheadではこのチェックポイントを利用するから、実質追加の資源は必要ないわけだ」

女「君が話したかった最終的なことはこれ？」

男「むむ、なにか不満だと言いたげだな」

女「OoOの話の方が凄かったし面白かったと思うよ」

女「尻すぼみな感じ」

男「ぐぬぬ」

女「OoOくらい革新的な方法のあとじゃね」

男「どーせ俺なんか……」

女「わたしが君を傷つけたみたいなオーラ出さないでよ」

男「傷物にされました」

女「えぇー……」

男「まあちょっと傷ついたけど、高速化についてはまだ色々な話があるんだ」

女（あのまま最後まで打ちのめした方が良かったかもしれない）

女「色々ってあとどのくらいあるの？」

男「えーっと、メモリ周りの話だとキャッシュの階層化やロード・ストアの依存解析、マルチ・タスクに関する話でマルチ・スレッディングやマルチ・コアの話とか、あとはマルチ・コアに関連してホモジニアス/ヘテロジニアスの善し悪しとか……」

女「……」

女「あのさ」

男「はい」

女「わたしがパソコンを買いたいって相談したからこういう話をしてくれたんだよね？」

男「……」

男「そ、そりゃあもちろんね！」

女「その間は何かな」

男「いや、なんか女にパソコンの話をしなきゃってことは覚えてたんだけど」

男「自分に分かるパソコンの話をしようと思っていたら方向がかなり偏ってしまったなぁ……と」

女「まさか今までの話ってパソコン買う上で役に立たない？」

男「むしろ、キャッシュの階層構造やマルチ・スレッディング、マルチ・コアの話はパソコンを買う上で多少の指標にはなるかな……と」

女「つまり、ここまでは全く役に立たないってことだよね」

男「あうあう……」

女「はああああああぁぁぁ…………」

女「頑張って聞いてたのは全部君の趣味の話だったのかあああああああ」

男「ゴメン」

女「いや、いいよ。勝手に思い込んでたわたしが悪いし、君が楽しそうに話してるのを聞くのは好きだから」

女「ただ、君がわたしのために頑張って説明を考えてきてくれたのだと思って、頑張って聞いてたわたしが間抜けだったと……思ってるだけで……」

男「あの……」

女「はい」

男「なんかゴメン」

女「いいよ」

男「うん」

男「もしかしてプロセッサの説明に感動して告白を？」

女「それはないから安心して」

男「はい」

女「ホントに馬鹿だよね」

男「ゴメン」

女「許す」

男「パソコン、今から買いに行かない？」

女「ん、そうだね。せっかく君がいるんだから良いの見繕ってもらおうかな」

女「あれだけ語れるんだから、わたしに合うのを選んでくれるよね？」

男「なんかプレッシャーが」

女「まあ多少はね？」

女「さて、お店に着いたは良いけれど」

女「どれが良いのかさっぱり分かりません」

女「君が説明してくれた単語のうち、スペック説明欄に載ってる言葉ほとんどない！」

男「ははははは……」

女「最初に説明してくれたメモリくらいしか役に立ちそうにない」

女「HDDもあるヤツとないヤツあるし」

男「それはSSDが代わりについてるんだな」

女「SSD？」

男「Solid State Drive。HDDは文字通り固い円盤がクルクル回って円盤状に書かれた磁気データを探すわけだが」

男「SSDではメモリと同様にアドレッシングで指定した場所から直接データを得られる」

女「データの取得方法に差があるってことすら初耳だよ」

男「あれ？　えーと、HDDの方はさっきも言った通り、目的位置に辿り着くまでひたすら円盤を回すんだ」

男「これに対してメモリなどはRandom Access Memory(RAM)と言われて、データの位置に関わらず位置を指定すると定数時間でデータを得ることができるんだ」

男「で、RAMは文字通りランダム・アクセスでも連続アクセスでも一定時間で結果を出せるが、HDDは連続アクセスにはある程度強いが、ランダム・アクセスする度に円盤を駆け回る必要がある」

女「その分HDDは遅いってこと？」

男「らしいよ」

男「個人的な感想はHDDをSSDに換装するとOSの起動時間が半分くらいに縮む」

女「おおー」

男「あとはそれぞれのメリット・デメリットを簡単に説明すると」

HDD
メリット
・保存量当たりの値段が安い（5円/GB程度）
・単体で大容量のものが多い
デメリット
・回転してるので揺れに弱い
・唐突に壊れる（いつ壊れてもおかしくないし、いつまでも壊れないかも知れない）

SSD
メリット
・高速
・振動に強い
デメリット
・単体では小容量のものが多い
・高価
・いつか必ず壊れる（書き込み上限数が存在する）

男「こんなところかね」

女「どっちも壊れるんだね」

男「機械だからな」

女「お勧めはどっちなの？」

男「拘らないのであればHDDで良いと思うけど」

男「システム用のディスクをSSD、データ用のディスクをHDDで、ってのが使い勝手が良いと思う」

女「見た感じ、両方付いてるのなさそうだけど」

男「ならSSDのものを買って、HDDを増設するって感じかな」

女「わたしにやれるでしょうか」

男「……その目は俺にやれって言ってるよな」

女「タダとは言わないよ。わたしをあげよう」

男「それをタダって言うんだ」

女「本能に負けちゃえー」

女「OSっていまいち違いが分からないんだけど」

男「ここに並んでるのは全部Windows 8.1で違いないからな」

女「恥ずかしい……」

男「ま、そういうこともある」

男「OSは色々と言われることが多いけれども、なんだかんだで慣れの問題が大きいと思う」

女「慣れかー」

男「もちろんマイナーなOSに慣れてしまえば、他人にパソコンを貸せば非難され、他人にパソコンを借りれば叩くということになりかねないが」

女「えええー……」

男「ちなみに今Windows 8シリーズはマイクロソフト社の黒歴史になるかもしれないと専らの噂だ」

女「えええー……」

男「ま、Me、Vista、7と使ってきた俺からしてみれば、Meほどの逸材は今後現れないと思うから心配しないで良いと思うぞ」

女「そのMeってどんな」
男「聞くな」

男「OSといえばmacを使うって手もあるがな」

女「含みのある言い方するね」

男「Windowsと比較できるほど両方を使い込んでるわけではないが、時々やりたいことがやれないことがあるな」

男「俺が詳しくないせいって可能性もあるが」

女「それじゃあわたしにもできないかな」

男「そもそも女が俺みたいなことをしようってことにはならないだろうがな」

女「確かにー」

男「どちらも手に馴染んでない状況ならmacもすぐに手に馴染む使いやすさがあると思う」

男「とくにスクロールに関してはWindowsゴミだからな」

女「ゴミって……」

男「あー忘れてくれ、きっと俺が知らないなにか対策はあるだろうし」

女「メモリはどのくらい必要なの？」

男「使い方によるけどなあ」

男「インターネットのウェブサイト見るソフトをブラウザと言いますが、

俺が使ってるブラウザは起動してるだけでおよそ400MBくらいのメモリを消費するらしい」

女「多いのか少ないのかよく分からない」

男「色々とあるソフトの中ではかなり多い」

男「1つのタブを追加で平均10MBくらい増える」

男「Wordは起動しただけで80MBくらいで一つファイルを開く都度に10MBくらいのメモリが必要になる印象だな」

男「もちろん、ブラウザなら見るウェブページ、Wordなら開くファイルによってこの値は変わるだろうがな」

女「じゃあ動画サイトで音楽を聞きながら作業をしようと思うとどのくらい必要？」

男「ナガラ族か」

女「き、君もでしょ！」

男「どのくらい同時展開するかによるけどな」

男「ただまあ色々な常駐ソフトを込みで考えても4GBあれば大抵は足りると思う」

男「ゲームをする人、動画を編集する人、無意味に多重にファイルを開く癖のある人、でなければ8GBあれば確実に足りるかな」

女「じゃあこのお店のパソコンはほとんど大丈夫だね」

男「今はVistaとは時代が違うからな」

女「なんか遠い目をしてるよ」

男「Vistaは悪い子じゃないんだよ」

女「おーい？」

男「おっとゴメン、ちょっと昔を思い出してたわ」

女「入出力装置には拘るべきなの？」

男「普通の人は拘らないけどな」

女「普通じゃない人は拘るの？」

男「その言い方はやめなさい」

男「キーボードやマウスの使いやすい、使いにくいは慣れ以外の要因も結構大きいのだと気付いたよ」

女「そういうものなの？」

男「大学時代の研究室で使ってたキーボードが使いやすかったから自分も買おうかと思ったら2万して諦めた」

女「ふえぇ……」

男「ディスプレイは少し拘った方が良いかもな」

女「具体的には？」

男「目が疲れやすいなら光沢のないディスプレイを選ぶべきだし」

男「最近のウェブページの作り的にワイドディスプレイ、とこれは普通に買えばワイドだな」

男「あとは置く場所にもよるが、デスクトップPCなら23、4インチくらいは欲しくなると思う」

女「ふむふむ、そうなるとSSDでディスプレイを大きめの光沢なしと思うと大分しぼられてくるね」

男「見た目の綺麗さって意味なら光沢はむしろあった方が良いんだけどな」

女「目はすぐしょぼしょぼだよ」

男「じゃあ仕方がないな」

女「えーっと、補助記憶装置、主記憶装置、入出力装置についてはこれで大丈夫？」

男「補助記憶装置と言えばDVDやBD、あとはSDカードやマイナーどころでXDカード、色々とあるぞ」

女「マイナーどころはさすがに、と思うけどSDやDVDは見れた方が良いかな」

男「DVDドライブはデスクトップなら大抵ついてるな。SD…も大丈夫だな」

男「ただBDはまだあるヤツとないヤツが別れてるか？」

女「見ないと思うけどなあ」

男「VHSがDVDになるのと同じ流れだと思えばそう遠くなくBDにすり替わると思うけどな」

女「そういうもの？」

男「その頃には新しいパソコンを買ってるとも思う」

女「じゃあどっちでも良いかな」

女「さて、あとは演算装置について見れば良いのかな？」

男「そうだな」

女「CPUのスペック説明に書いてあるの、動作周波数とコア数とスレッド数、キャッシュ・サイズくらいで」

女「君が言ってたROBとか発行キューのことなんて出てこないね」

男「またその話を」

女「ふふふふ」

女「分からないから教えてよ」

男「ふむ」

男「動作周波数は、1秒でどれだけのサイクルを進められるかってことだな」

男「3GHzと書いてあれば3Gサイクルの動作を進められるから、コア当たり3Gの命令を実行できると考えがちだが実際にはコア内には複数の演算器があるから3G以上の実行をすることが可能だな」

女「コアとは」

男「最近のプロセッサは一つのチップに複数のプロセッサが載っていて、それぞれをコア、全体でプロセッサと呼ぶようになってるわけだ」

女「コア=プロセッサなんだ」

男「コア∈プロセッサだな」

男「まあとりあえず周波数は大きいほど速い良いプロセッサってことだな」

男「でコア数はさっきも言った通りプロセッサの数だから、多い方が良いわけだ」

男「スレッド数も多い方が良いものだが、説明は複雑なんだな」

女「長くなる感じ？」

男「真面目に説明するとな」

女「簡単に」

男「同時に扱えるプログラム数」

女「すごく簡単に説明できてるじゃない」

男「不適切だと思うがな」

女「まああながち間違いでもないのでしょ？」

男「自信はない。スレッド・レベルの話はあまり調べたことがないからな」

男「さて最後はキャッシュ・サイズだったな」

女「キャッシュが大きいと遅くなるから一概に大きいのが良いわけではないのでしょ？」

男「よく見るとキャッシュの前にL2とかL3とか書いてあるだろ」

女「あ、確かに」

男「キャッシュはメモリ→L3キャッシュ→L2キャッシュ→L1キャッシュ→プロセッサみたいな階層構造になってることが多いんだ」

男「CPUによってはL3が無くてL2までとかだけどな」

女「Lは何？」

男「Level」

女「何の面白みもない」

男「まあ仕方がない。で、このキャッシュ・サイズってのは大抵一番大きいキャッシュの大きさが書かれてるんだ」

女「へえー」

男「L1キャッシュは速さのために容量を最小限にしているが、L２やL3はある程度、速さを犠牲にして容量を獲得する」

男「メイン・メモリへのアクセスに比べれば10倍以上マシだからな」

女「そうだったね」

男「L1の容量と速さについても調べられるなら比較検討はかなり複雑になると思うけど」

男「一番大きいキャッシュについてだけでは単純に大きいものが有利かなという程度しか評価できないな」

男「強いて言えばL3まである方が有利な可能性は高い」

男「まあ消費電力はその分食うけどね」

女「どれくらい？」

男「キャッシュ・システムが占める消費電力については流石に知らない」

男「だがCPUの一般的な消費電力は80W程度で、最高スペックのものでも130Wくらいだな」

女「高いのか低いのかよく分からない」

男「人間は60Wくらいのヒーターだそうだ」

女「その比較ではわけわかんないよ」

女「結局CPUはどんなのを選べば良いの？」

男「最近のは軒並みマルチ・タスクが得意だからなぁ」

男「やっぱり動画編集、ゲーム、何故か多重にファイルを開く、ってことをしない人なら特に拘る部品ではないと思う」

女「あれだけ高速化のロマンがーって言ってたのに」

男「一般過程向けのプロセッサは今はプロセッサだけが先行してる形になってるな」

女「ソフトがついてきてない？」

男「そういうこと」

女「意味ないじゃない」

男「プロセッサが今の家庭用のものより100倍遅かった時代に、これより速いプロセッサは要らないと考えた人たちが多くいたそうだけど」

男「今、家庭用のパソコンが100倍遅くなったら阿鼻叫喚であることは間違いない」

女「……いつかはソフトが追いつくってこと？」

男「きっとな」

男「とはいえ、ナガラ族だと分かっているならコア数やスレッド数の大きいものを選んだ方が良いかな」

男「周波数は多分、女の使い方ならあまり実感がわかないと思う」

女「おかげでサクサクと数台にまで絞れました」

男「役に立ったようで何より」

女「決め手とかはあるの？」

男「デザイン、ブランド、サポートかな」

女「デザイン……パソコンに可愛いとかもないよね」

男「パソコンはみんな可愛いもんな」

女「……」

男「な、なんだよ」

女「……別に良いけどね」

女「ブランドもパソコンじゃあ全然分からないし」

女「サポート、ね」

男「サポートの評判がいいメーカーって言うとどこだったかな……」

女「男」

男「え、今名前で呼んだ？」

女「サポートは君にしてもらうからいい」

男「その目はずるい」

女「タダじゃないよ？」

男「だからそれはタダなんだって」

女「むむむ」

女「結局決め手は君の好みだったね」

男「サポートしなきゃならない以上、俺が扱いやすいこともそれなりに重要だろ」

女「まあそうだね」

女「ただいまー」

男「一人暮らしなのに」

女「気持ちの問題でしょ」

女「さて」

男「さて？」

女「君はサポートをタダでするのが嫌そうだったよね」

男「嫌とまでは言ってないだろ」

女「ふふふ、そんな君に朗報ですよ」

男「な、なんだよ」

女「先払いです」ｴｲﾔ–

男「ちょ、えおい」ｶﾞﾀｶﾞﾀｯ

男「もう少し穏やかにすることは出来なかったのか」

女「少しは反省してるよ」

男「お互いにタンコブができて反省してなかったらビックリだよ」

女「はい……」

女「でも気持ちよかったでしょ？」

男「実は俺よりも下ネタが好きだろ？」

女「ちょっとだけね」

女「不満ならこれから本番も良いよ？」

男「それはまだとっておくよ」

女「せっかくお風呂で汗流してあげたのに」

男「パソコンを買うってイベントの中に重大なイベントが埋もれたせいでうやむやでもやもやする」

女「正確に言うと君がプロセッサの説明をするという不要なイベントの中で重要なイベントが発生したんだけどね」

男「不要とか言うなよ」

女「あの話を切りたくて言い出した感は否めないから不要ではなかったかも」

男「そういう理由だったのか」

女「け、結果オーライだよ」

男「グダグダだなあ」

女「君が頓珍漢だからだよ」

男「否定できないのが辛いな」

女「わたしがいるから大丈夫」

男「……頼りにしてるよ」

女「任せなさい」

終わり