« 2006年07月 | メイン | 2006年09月 »

2006年08月13日

64bitがわかる

おくればせながら、 いただきありがとうございますm(_ _)m

いや企画趣旨はやね氏の言う通り「おじさんむけ入門」とか「フレッシュマン向け入門」の筈で、それに沿って書いてた筈なのですが、出来上がってみると業界向けになってしまったという。しかも何の業界だかよくわからない(苦笑)

投稿者 ohara : 07:51 | コメント (1) | トラックバック

2006年08月10日

ベンチマーク記事の補足の補足

このエントリと、このエントリに対する簡単な補足など。

x86命令レベルでIPC=4を目指すためには何が必要か、を考えると3つの要件が出てきます。

(1) デコーダがSustainedで4命令/Cycleのデコードが可能なこと
(2) スケジューラが、Sustainedで4命令/Cycle相当のμOpsを送り込めること
(3) 実行ユニットが、Sustainedで4命令/Cycle相当のμOpsを実行できること

で、実は(1)と(3)はすごく簡単。要するに力技でデコードユニットと実行ユニットを並べれば済みます。当然キャッシュ帯域とかメモリ帯域はより高い性能が必要になるわけですが、これはCPUコアの外の問題なので、ここでは割愛。

で、一番難しいのはおそらく(2)です。つまり命令間の依存関係を上手くほぐして、独立に実行可能な様にすることで、これがうまく行かないと幾らデコーダや実行ユニットを並べても、実効性能が低いまんまということになります。

そもそもK7→K8でIPCが20%ほど向上してるわけですが、これが何で成し遂げられたかというと、デコード→スケジューラ段の見直しなんですね。これは両方のパイプラインを比較するとわかります。で、今のCoreが、んじゃIPC=4に耐えるだけの依存関係解消能力を持っているか、というと甚だ怪しい気がします。

あとDecoder 0のスループット。これでも判るとおり、NOPですらIPCは2.9命令/Cycle程度になってます。そもそもRMMAでNOPをひたすら投入した場合に、それをどのDecoderで処理するかが明確になってないんですが、仮にNOPの場合はDecoder 0〜3が均等に使われるとします。そうすると、スループットの期待値はDecoder 0のスループットをα、Decoder 1〜3のスループットを1とすると

仮にDecoder 0のスループットをαとすると、
((α+2)×3+3)÷/4
つーことになります。で、この結果が2.9なわけですから、計算すると
α=(2.9×4)÷3−3≒0.87(命令/Cycle)
というあたりですね。

で、一番疑ってるのは「仮にNOPの場合はDecoder 0〜3が均等に使われる」という前提そのものだったりします。つーのは、そもそもCoreはFetch/PreDecodeのステージで、Length Markingの処理を行う訳ですが、この時点でSingle μOpかどうか判断ができる訳です。で、Single μOpと判ってるものを、わざわざComplex Decoderに送り込むかなぁ?と。このあたりはもう少し考察しないといけないんですが、そんな非効率的な事はしないんじゃないかなぁ、というのが私の率直な感想です。つまり、Decode 1〜3がそもそもスループットが1よりちょい少なく、結果としてIPC=2.9程度になっている、と。
ただこれを確認するためには、LCP以外で2つのμOpsになるようなx86命令で同じことをやってスループット確認しないといかんのですが、まずプログラム考えるところから始めないといけないのがなんとも(苦笑)

つーわけで、そのうち時間ができたら何か書くかもしれません。出来ない気もするけど(自爆)

投稿者 ohara : 04:41 | コメント (0) | トラックバック

2006年08月08日

夕暮れ

投稿者 ohara : 19:22 | コメント (5) | トラックバック

2006年08月07日

ベンチマーク記事の補足

Core2ベンチマークの完成版が割と好評(?)な様で、3週間もかけてベンチ取った甲斐があるというものである。で、色々な場所でそれぞれ批評を頂いていたりする。

そんなお一つが「Intel Core 2各種ベンチまとめ記事@MYCOM」であるが、やっぱり結論に至る途中過程が判りにくかったようなので、補足。

こちらの記事での指摘、簡単に言えば「Decode段のスループットが3命令/Cycleなので、『実質的にはx86命令で3命令/Cycleを狙ったアーキテクチャである。』と考察しているが、でもALU命令ばっかりしかテストしてないじゃん」という話。

この指摘はその通りなのですが、もう少し話は複雑だったりします。

そもそも判りにくいのが、μOpレベルのIPCとx86命令相当でのIPCの換算。実はCore2に関しては、1つのx86命令が幾つのμOpに変換されるか、今のところ明示的に示されてません。ただ過去の経緯から言えば、x86が1つないし2つのμOpに変換されると考えるべきです。なので、x86でIPC=3を実現するためには、最大6つの実行ユニット(≠ALU)が必要となります。何で≠かというと、1つのx86が2つのμOpになるのは、ALU命令+ロードストア命令、というパターンがあるからで、この場合ALUが6個あっても無駄で、ALU3つとロードストア3つが無いとIPC=3を実現できません。これを馬鹿正直に実装したのがK7/K8ということになります。

んでCore2は?というと、(元記事にも指摘がありましたが)これで指摘があるように、Simple ALUが3組、LoadとStoreが別々に1つという構成。FPUを別にすれば、最大5つのμOpを実行できる計算になります。なので、1つのμOpに変換できるx86命令を上手く組み合わせれば、x86換算でIPC=5が狙えるんじゃないのか?という事でしょう。言い換えれば、今のデコードスループットが3Bytes/Cycleなり6Bytes/Cycleなのは、特定の命令ばっかりまとめて処理してるからこのあたりでピークが来るのであって、もっとバラエティに富んだ命令だったら実行段のスループットがもう少し上がり、結果としてデコードスループットももう少しあがるんじゃないのか?というあたりが指摘されております(解釈が間違っていたらご指摘ください)

で、この指摘に対するお答えですが「その可能性はあるが、微妙」というもの。まずはこちらをごらん頂きたいのですが、そもそもデコード段は最大4命令/Cycleで、うちDecode 0のみ全x86命令を、Decoder 1〜3はSingle μOpのみをサポートしていると明記しています。つまり、デコード段では最大5μOpを生成できる「筈」です。

で、NOPを始めとするSingle μOpに関してはほぼ3μOps/Cycleで実行できていることから、Decoder 1〜3のスループットは1μOp/Cycleであると想像されます。問題はDecoder 0のスループットです。これがどの位か?というのは概ね想像が付きます。それはこれ。LCP(Length Change Prefix)がついた命令はおそらくDecoder1〜3では扱えないのでしょう。結果、0.275命令/Cycleという、かなり遅めの結果になっていますが、Decoder 0はこのあたりが性能の限界ではないかと思っています。このあたりはもう少し様々な命令を突っ込んでみないと断言できないので記事には書かなかったんですが。なので、フルに動いても3.3命令/Cycle(x86換算)程度という可能性が非常に高いと私は考えています。

勿論ここにはMacroOps Fusionの話は一切加味してません。なので、これの効果でひょっとするともう少し性能が上がるかもしれませんが、それでも4命令/Cycleには行かないと思っています。というのは、MacroOps Fusionは2つのALUに対しての命令(こちらの最後でまとめてますが)なので、Load/Storeユニットは使ってくれないからです。

あと、このデコーダ段の制約を抜きに話をすると、Core MicroarchitectureがピークでIPC=5を狙えるというのなら、K7/K8はIPC=6を狙えるアーキテクチャっつーことになっちまいます。K7/K8は一応デコード段がx86命令換算で3命令/Cycleのデコード性能なので、普通に考えるとこんな形でμOpが投入される可能性は低いのですが、今スケジューラに3つのLoad命令がデータ待ちしていて、そこに後から3つのALU命令(例えばNOP)がデコーダからやってきて、これが一斉に実行ユニットに投入されるとピーク時にはIPC=6という事になります。これは別にAMDのみならずIntelのP6/P4も同じなんですが、にも関わらずAMDやIntelがこーいう事を言わないのは「そんなケースは殆どない」からです。上の例(つまり3つのLoadと3つのNOP)のケースでは、確かに投入したCycleではIPC=6ですが、その前はIPC=0(つまりデータ待ちをしている)なので、平均すればやっぱりIPC=3っつーことになりますし。

そういった事も加味して、「Coreではデコード段が最大5μOps/Cycleと言っているけど、実質は(x86で)3命令/CycleそこそこがSustained Rateっぽい。また実行ユニットも最大5μOps/Cycleと言っているけど、x86で換算すると概ね3命令/Cycleがピークっぽい。ということで、『x86命令換算で3命令/Cycleを狙ったアーキテクチャ』とみなすのが妥当であろう」という判断をしております。

というような話は、本当は記事にして原稿料を稼ぐのが賢明なんだろうなぁ(笑)

23:17補足:
というよーな事を書いたら編集部から「勿体無いのでこっちに送ってください」といわれた(笑)。
でも記事にするとTB送ったりコメントつけたりできない(編集部にメールを送っていただければ転送してもらえますが)のと、ちょこちょこ手直しできない(上の文章、5回ほど書き直してます)のがネック。だからといってMYCOM JournalをMTで作れというのも無茶な話だしなぁ。

投稿者 ohara : 19:56 | コメント (1) | トラックバック

2006年08月01日

フロリダ7日目〜帰国

一旦2時過ぎに起床。軽くパンだけ焼いて食し、2度寝。起きたら午後4時過ぎ(!)。真剣に疲れてるようだ。
とりあえず夕食は

Spicy peanut noodles。Spicyとか書いてある割にはあんまりスパイシーでなく、しかも甘い。だめだこれは。
で、そこからテープ起しなどを始めつつ、適当に荷物の片付けもしたり。
0時過ぎに最後の食事。

Shrimp & angel hair pasta。まぁ及第点というレベルか。

結局出発までに2本目の原稿完成せず。そのまま8時頃にHotelをCheckout。途中でガソリンを入れつつ空港へ。空港に降り立つと、まぁオーランドらしい光景を見かけたり。
DSCF2277.jpg
まぁ遊びに来るのが普通だよな。で、オーランド空港で朝食。

ツナサンド。本当はスナックがおまけなのだが、要らないと言ったら「んじゃバナナ1本持ってけ」実にシンプルというか。
で、Orlandoあたりでは、普段見かけないLocal Airが落ちてる。

多分ここの機体。
さて、Orlando→DetroitはFirstにUpgrade出来たが、まぁ2時間だし、寝てるだけだし。で、Detroitでポカミス。一旦荷物のPickupが必要な気がして外に出てしまう。気が付いてすぐに戻るが、Security Checkで時間が掛かり、SportsBarでタバコを吸う機会を逃す(T_T)。結局何もないまま、乗換。
帰りのメシは

ちきーん。もう一つはびーふだが、メニューみただけで不味そうと判る代物。で、朝食は

オムレツ。まぁ可も無く不可も無く。多少定刻より遅れ、18時そこそこに成田到着。結局帰宅したのは22時近く。そのまま沈没。

投稿者 ohara : 19:25 | コメント (3) | トラックバック