« 8月は | メイン | BSD »

2006年09月05日

突っ込み

Freescaleの8bit MCUの記事とかにも色々ご指摘を頂いていて、やっぱり1歩踏み込んだ記事を書くとちゃんと突っ込みが入るなぁ、とか思ったり。

で、話はふたたびコレこれとかこれでも少し書いたけど、要するにCore MircoArch.は何を目指してるんだ、という話。

で、いつも拝見している「たるさんのパソコンフィールド」でも突っ込みを頂いたので、少しお返事がてら考えてみたいと思う。

RightMarkの結果だけでは「3 x86命令/Cycleを狙った構造」なのか、「実行ユニットがPoorなので3 x86命令/Cycleしかでない」のか判らないのはご指摘の通り。根本的なところで言えば、RightMarkの問題というよりもx86命令の形でしか投入できず、内部ではMicroOpsで処理されるというあたりが、もうどうしようも無いとも言えます。勿論色々なパターンを追試すれば見えてくるものも有ると思います。その点では今回(時間の制約もあって)RightMarkしか出来なかったとか、Banias/Dothan/Yonahを試せなかったというあたりが悔やまれるところではあります。

いや実際、これの追試のためにYonah買おうかと思ったんですが、Core2 Duoより高いんですよね(^^;) DothanはThinkPad X31あるのですぐ試せるんですが。

で、次にボトルネックの問題。律速段階がどこにあるかというと、可能性は
・Decoder
・Scheduler
・Executor
のいずれ(もしくは複数)と考えられる。ここで問題なのは、「仮に4 x86命令/Cycleを見据えた場合、その命令コンビネーションはいかなる形になるのか?」という話。IntelのP6/NetBurst/Banias・Dothan・Yonahといった昨今のアーキテクチャは、大雑把に言えば2 ALU+Load/Storeという構造をとっている。この構造でも結構3 x86命令/Cycleに近いところまで行くというのは、例えばDothanが同クロックのK8に近い(orこれを上回る)性能を出すことから推察可能。となると、3 x86命令/Cycleにおける一般的な命令のCombinationは 2ALU+Load or Storeのパターンが多い様に推察できる。x86の場合、何しろ3オペランド命令はないわ、汎用レジスタは少ないわなので、アセンブラをハンドオプティマイズした場合はともかく普通にコンパイラを掛けたプログラムの場合、どうしてもスタックを多用しがちになる。これは必然的にLoad/Storeの比重が高まるわけで、3 x86命令/Cycleを超える先ではこの比重が更に高まりそうに思える。なので、実際真剣に4 x86命令/Cycleを狙うのであれば、たろ氏とは逆にLoad/Storeユニットの数が足りない様に思う。3 ALUに2 Load/1 Storeあたりが適正なユニット数じゃないか、というのが私の「直感」。Storeが1でいいのは、どうせ書き出しは遅いからStoreユニットを増やすよりもWrite Bufferを強化したほうが得策だと思うため。にも関わらずCore MicroArch.が1 Load/1 Storeで事足れりとしているあたりが、私がExecutorがボトルネックにはならないと考える主要な理由である。
んじゃどこで?というとこれが難しくって、原稿ではDecoderの問題を示したが、後から考えるとSchedulerが詰まってるためじゃないか?なんて気もしてきている。アベンド氏への2度目のお返事でも書いた話だが、Decoder 0のスループットが正直良くわからないので、4 x86命令/Cycleのデコードが可能かどうかは現状謎。で、RightMarkの様にNOPだのADDだのだけといった、依存関係が少なく投機実行させやすいプログラムはともかく、普通のプログラムで依存関係ありまくりのものを、どこまで解して投機実行させられる能力がSchedulerにあるのかも現状謎。そんなあたりも踏まえて、あーいう結論になったとご理解いただければ幸いであります。

正直このあたりはもう外から見てても判らなくって、なのでArchitectの中の人(このあたりの人ですね)をIDFとかで捕まえて聞くしか無いんですが、果たして素直に教えてくれるか。そもそもValentine氏に関しては、前回のIDFでさんざ捕まえてあれこれ聞きまくったので、今回は警戒して来てくれない気もするし。Moolyは間違いなくIDFに居ると思うが、もう偉くなってしまったんでそうそう捕まえられないし、そこまで細かい事は知らないだろうし。

という訳で、本エントリの結論として「おっしゃる通り、原因は確定できません」ということで、お返事に代えさせていただきます。

あと注釈について。fxchは一見ナイスな気もするんですが、Decoder 1〜3のSimple Decoderで解釈してくれるかしらん?試してみないと。NOPに関してはちょっと悩んだんですが、これをScheduleで消尽させてしまうと、昔のNOPを使ってタイミング取ったりしてたプログラムが全滅しそうな。なので、実際にExecutorがどう動くかはアレですが、少なくともSlotは確保してるだろう、というのが私の見解です。Intelは過去との互換性には神経質で、仮に変更があれば絶対にアナウンスが入ると思うのですが、HPCデベロッパー・カンファレンスではNOPに関する話は一切なかったので、おそらくこれは何かしらやっている、と判断しています。

今後もこういった技術的な突っ込み、お待ちしておりますm(_ _)m

投稿者 ohara : 2006年09月05日 05:41

トラックバック

このエントリーのトラックバックURL:
http://www.nekobaka.com/cgi-bin/MT-3.11/mt-tb.cgi/155

コメント

組み合わせによっては、5 IPC でるという話みたいですよ。
http://pc8.2ch.net/test/read.cgi/tech/1136527588/592-

投稿者 : 2006年09月05日 12:21

コメントしてください




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)