Pavilion dv2 Entertainment Notebookの存在を忘れてたな。沙耶です。
こっちは北京のショーで発表されてたAthlon NEO X2搭載版のデュアルコア型。

BTOで選べるようになってくれればいいんだけど。
本国は選べるんだけどなぁ。

AMD Turion(TM) Neo X2 Dual-Core Mobile Processor for Ultrathin Notebooks L625 (1.6 GHz)
Requires ATI Radeon HD Premium 3410 Graphics

+$50.00

うーん、とてもうらやましいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ +5000円かいｗ


さっさと日本もBTOできるようにしてください。在庫売りさばいてないで！

ちょいと待ちで見ておくか。ていうか本国側のBTOは全然質が違うけどな。Blu-Rayドライブも選べるし、パフォーマンスベースのモデルはデフォルトでメモリ4GBだし。

ぱかすか突っ込んでも$854.99ってとこなので、VISAあたりを用意していて、個人輸入を恐れないなら本国購入もありかと。消費税が15%近くあるけどｗｗｗｗｗ
MicrosoftWorksがついてくるのはとても要らないけどｗｗｗｗｗｗｗｗ　日本じゃWorks普及してないしね。家庭でOffice使うって世界だから。

向こうじゃ異常と思われてるかもしれないけどｗ


さて、と。ヒマだしな。

Atomについて語ってみるか。ネットブックによく用いられているAtomプロセッサ。そして、dv2やYukonで使われているC2D系やAthlonなどのCore系やAMD系アーキテクチャ。
たとえばこれらの二つを全く同じクロックのシングルコアで用意したとしたら、その二つで決定的な差異は生まれるか、否か。

沙耶的にいえば、この二つ、まったくの別物である。

誤解を恐れずに、あえて言うとすれば、Atomはi486の再設計であると言っていい。i486のダイ構造に、キャッシュの拡大や最近のCPU技術なんかを盛り込んだものの、基本的な思想と構造はi486のそれに近い。
アーキテクチャの根っこから違うのだ。

逆にいえば、ブラウザとメールをするだけならAtomで事足りる、というのは、i486クラスでも下手すれば事足りるレベルだということにほかならない。
まあクロックも違うし、いろいろ強化はされているんだけどねｗｗｗｗｗ

Core2系命令セット互換ではあるものの、その処理方法はCore2とは決定的に異なる。

Atomは、インオーダー実行と呼ばれる順列実行プロセッサなのだ。i486ベースだからさもありなん。
アウトオブオーダーのプロセッサに変わったのはPentiumProとかK5からである。
この点が、Atom系と現行プロセッサの決定的な違いでもあるし、Atomが現在のゲームなどに向かない、といわれる最大の理由でもある。
ちなみに静的なゲームには別にAtomで事足りる。Atomが向かないのは、3Dゲームだとか、もりもり動きまくるゲームとかだ。

インオーダー実行とアウトオブオーダー実行。この二つはいったいどう違うのだろうか。

1. 命令A
2. 命令B
3. 命令C(命令Aの結果を使う)
4. 命令D(命令Cの結果を使う)
5. 命令E
6. 命令F(命令Bの結果を使う)
7. 命令G

こういうプログラムがあったとしよう。
インオーダー実行は単純だ。上から順番に実行されていく。

ではアウトオブオーダーを見てみよう。これは、最終的には並列プロイセッサに向く仕様だが、プロセッサの構造が比較的複雑になってしまう欠点もある。

上記と同じプログラムをアウトオブオーダープロセッサに与えるとこうなる。

命令を読み取ると、アウトオブオーダープロセッサは一旦その命令を命令キャッシュに貯めてしまう。

命令キャッシュ内
1. 命令A
2. 命令B
3. 命令C(命令Aの結果を使う)
4. 命令D(命令Cの結果を使う)
5. 命令E
6. 命令F(命令Bの結果を使う)
7. 命令G

そして、ここから命令を順次プロセッサに渡して行くわけだが、この命令順はばらばらに分解される。

まず1.の命令Aがプロセッサに投入される。つぎに2.の命令B。そして、3の命令Cの段階で1.の命令Aがまだ結果を返してこない場合、インオーダープロセッサの場合命令Aの結果を待つ。

アウトオブオーダープロセッサは、これをすっとばす。もちろん、命令Aの結果が帰ってきてない場合、4.の命令Dも実行できないのだから、5.の命令Eなどのように他の命令結果に依存しない命令が先行実行される。

6.の段階でも同じ。命令Bの結果が帰ってきているなら実行されるが、なければ実行されずにキャッシュに残し、7,の命令Gを実行する。
3.4.6.の結果待ちオーダーは結果が戻り次第実行に移される。

まあ実際にはもっと複雑なのだけど、ざっくり書くとこんな感じ。
基本的にCPUへの命令は入力オペランドといって、パラメータをもらってから動くのだが、インオーダーは常にその入力オペランド待ちが発生する。
アウトオブオーダーの場合、入力オペランドが与えられた時点で命令の順序に関係なく実行ユニットにそれが渡される。

このため、CPUの実行ユニットの数、というのが重要になってくるわけだ。これがPentiumPro、いわゆる586系以降の特徴。
CPUの基本概念でいうなら、PentiumPro以降のアーキテクチャはそれほど異常に大きな変化をしていない。逆にいえば、486と586は別モノと言っていいほどの変わり方をした、ということでもある。
ここからさらに実行ユニットを多段化し、予測分岐を行わせたりするのだが、このあたりはもうマイクロコードの理論にしっかり踏み込まないと何言ってんのかさっぱりわからない。

このようにアウトオブオーダーは命令フェッチから順序どおりに実行しない。このため、並列に多数の実行ユニットへ命令をどかどか投げてしまうことができる。CPUが入力オペランド待ちになって止まることが少なくなる。

最終的にこれはマルチコアプロセッサなどの効率的稼働率にも影響を与えてくる。

ちなみにこのアウトオブオーダー実行とかと、プロセスレベルでのマルチスレッド実行はまるで話が違うので間違えないように。あくまでアウトオブオーダーはコア単位の中での並列度を高める工夫。
全く無関係ではないけども、そこまで密な関係性はない。

このアウトオブオーダー実行はRISCなどに見られる単機能命令セットでは効果が薄い。
が、CISCにおける超長命令であるVLIWでは効果が高い。

もっと面白い動作もプロセッサコアの中では行われる。

1. 命令A
2. 命令B(命令Aの結果が0なら命令Hへジャンプ)
3. 命令C(命令Aの結果を使う)
4. 命令D(命令Cの結果が1なら実行->どっかへジャンプ)
5. 命令E
6. 命令F(命令Cの結果が0なら実行->どっかへジャンプ)
7. 命令G(どっかへジャンプ)
8. 命令H
9. 命令I(もとの位置に戻る)

さて。

このプログラムを実行すると、ある種の投機実行が行われる。予測などとも呼ばれるし、ジャンプに関しては遅延実行などとも呼ばれる。

1.の命令Aが発端だ。もちろんアウトオブオーダーなので、命令Eは並列実行されていく。
2の命令Bを見ると、命令Aの結果が必要となる。もし、命令Aの結果が0なら命令Hを実行せねばならない。

これをみたプロセッサは、先に命令Hを実行してしまう。これが、投機的実行による分岐予測。
命令Aの結果が0ではないか、と予測された場合に多段パイプラインにAの結果が0だったことにして動作をおこなってしまう。Aの結果を0と仮定しているので、当然アウトオブオーダーはAの結果が”帰ってきていないにもかかわらず”命令Cを実行、Cの結果がAが0ならCが0になる場合、命令Dを無視、命令EとFを実行し、ジャンプ先の命令を参照しに行く。

ここまで2動作でやる。これが予測分岐と投機的実行。Aの予測分岐と、それによるCの予測が行われている。
ところがAの結果が0じゃありませんでした、ってなると巻き戻さねばならない。実行になげたC/E/Fの命令へ取り消し命令を出し、Aの結果として1をセットし直して、C、そしてDの実行を再投入する。

これが予測ミスによるプロセッサのロス。

よってパイプラインが深ければ深いほど、予測ミスのダメージが大きくなる。パイプラインってのは連鎖実行できる命令のつながりの数のこと。
この場合Aの実行、Aの結果を使ってのBの実行、Hの実行、Iの実行、そしてもどってCの実行。ここまででパイプラインの段数5。パイプラインの段数はプロセッサによってきまっているが、段数分まではほとんどノータイムでプロセッサコアに命令をばかすか投入していける。

この中に条件分岐があった場合、プロセッサは予測を行うわけだ。たぶんこっちじゃね？ってくらいの感覚でｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

この予測ミスを取り返すために、”両方計算しときゃよくね？”という暴論かつ正論が現れる。

つまり、Aが1のとき、0のとき両方をプロセッサの実行ユニットに投げてしまい、結果がわかり次第どっちかの実行ユニットの出した結果を即座に返してしまう。

これも投機的実行の一種。

3. 命令C(命令Aの結果を使う)
4. 命令D(命令Cの結果が1なら実行->どっかへジャンプ)
5. 命令E
6. 命令F(命令Cの結果が0なら実行->どっかへジャンプ)
7. 命令G(どっかへジャンプ)

ここの部分。3.の命令Cをどっかの実行ユニットに投げる。予測でどっちかの結果でのパイプラインをつなぎ、たとえば0だったとしてEとFを実行する。これとは別に、1だったとしてDも別の実行ユニットに並列実行してジャンプ先の命令をフェッチして実行に移す。

Aが0だと確定したらDの実行ユニットの結果をぽいして実行したことすら見なかったことにする。一方1だったら、EとFの実行をキャンセルして、パイプラインにいきなりもう一個の実行ユニットで実行された結果を接続してしまう。巻き戻して再実行する手間を最小限にする工夫の一つ。

Atomはこれらの予測分岐などは行えない。インオーダー型のプロセッサだからだ。

こういった分岐しまくるパターンはゲームなんかではよく出てくる。また、プロセッサの利用効率も高いため、こういうものすごい細かいレベルで速度の違いってのは生まれてくるのだ。

CPUのクロックってのは、単にこの一つひとつの命令が一秒間に何回実行できるか、を示した数字。

インオーダープロセッサのクロックを高めても、入力オペランド待ちになるとクロックの割には…？ってことが発生することがおわかりになるだろうか。

すごいざっくり適当に書きなぐったからどっか間違えてたらｹﾝﾁｬﾅﾖ！