久々にx86の所要クロック計測スレをROMって勉強。
前回、C2DのIPCが4または5に達することができるか話していたが、PCwebから大原雄介さんが実際のところIPCは3あたりを狙っているっじゃないかと議論が出てそっちの方向へ。
いつのまにかアーキテクチャの話やハードウェアの話になってしまった。そういうスレッドは他にあるから、このスレッドでは実際にIPC3以上で実行できるx86命令を集めてみるとかで良かったんじゃないかな。
NOPは命令実行として1カウントされているけど、レジスタや実行ユニットを利用していない。
1 ◆.MeromIYCE ：2007/01/14(日) 23:40:26
lp:
nop
nop
mov eax,[esi]
dec ecx
jnz lp
これは2.0clk/loopで回る。lp:
nop
nop
and eax,eax
dec ecx
jnz lp
こっちは2.6clk/loop。nopがALU（Dothanでは2個）を使っているのがわかる。
1loopでALUを5回使うので、必ず2.5clk以上かかるのだ。nopは、命令ポインタであるeipの値を1増やす以外何もしない命令だが、
CPU内での扱いで言うと、レイテンシ1・スループット1の命令としてALUを1個使うが、
その他スケジュールなどでの制限事項には引っかからないタチのいい1byte命令、
という感じで、これは他のCPUでも同じじゃないかな。クロック計測の観点から言えば、「実行する」と表現した方がわかりやすいと思う。
この辺は言葉の問題なので、適宜使い分け。
NOPって調節用だから実際に実行していると思ってた。
IntelのCPUの論理回路に使われているトランジスタ数について
デフォルトの名無しさん ：2007/01/21(日) 04:13:03
http://journal.mycom.co.jp/column/sopinion/190/REV.FのDualCore 2MB L2で227.4Mトランジスタ
1MB L2で、153.8Mトランジスタと言われている。つまり、227.4-153.8=73.6Mトランジスタが、1MB L2の容量と思われる。
2MBだとｘ2で147.2
227.4-147.2=80.2がL2を除いたトランジスタ数。
41.1Mが1コアあたりのトランジスタ数となる。
ちなみに、512KBのシングルコアは81.1Mと言われているので
81.1-36.8=44.3ほどDualCoreの数値と比べ、少し多いが、
後述するメモコンなどの共用部分は、1コアでも1つ持つので、割とあってるかもしれない。ここから大原氏のいうL1キャッシュの容量7Mを差し引いて34.1Mトランジスタ
さらにメモコン部分のL2以外のダイ面積に占める割合からすると14％なので、
単純計算で5.75M、これを両コアで共有するため、半分として2.88Mトランジスタ。
34.1-2.875＝31.22Mである。メモコンのトランジスタ数については、前述の数値で言えば、
DualCoreとSingleCoreでコア辺り3.2Mの差があるので、
あたらずも遠からずかな。27 ：デフォルトの名無しさん ：2007/01/21(日) 04:15:27
つづきhttp://journal.mycom.co.jp/column/sopinion/190/
これと同じことをCore2でやると
Core2 4MB版が291M
Core2 2MB版が167M
であるから、(291-167)*2で248Mトランジスタ
（291-248）/2=21.5M
過去のP6アーキテクチャのくらべると、両コアの共用部分を差し引いても少ないように思う。その他Core2のキャッシュ計算法から、過去のCPUのトランジスタ数を推定すると
2MBのCoreDuoが、(151.6-124M)/2=13.8M
2MBのドタン,PentiumMが、140-124M=16M
1MBのバニアス,PentiumMが、77M-62M=15M
256KBのPentium3が、28.1M-15.5=12.6M
L2外付けのPentium3が、95MPenteium4だと
プレセラで(376-248)/2=64M
プレスコットで125-62=63M
割といい感じと言うか、ほぼぴったり！
しかしトランジスタ数がCore2の3倍に達することになるが。長々と書いたが、半分大原氏に向けて書いたつもり。
ここをみてる様だから。参考文献
http://www.sandpile.org/index.htm30 ：デフォルトの名無しさん ：2007/01/21(日) 14:47:40
大原氏の検証が正しいどうかかわからないが、Core2のトランジスタ数が少ないのは事実であろう。いずれにせよ、Core2のトランジスタ効率はかなり良い。
K8の60-70%程度の演算パイプライントランジスタ数で、120％の性能を発揮しているのだから。
遡れば、K7 2200万トランジスタに対して、Pen3 950万トランジスタで、クロック当たり性能がほぼ互角だったのだから、AMDのアーキテクチャーには無駄が多いのかもな。K8のブロック図を見ても
コンプレックスデコーダー*3
対称型ALU*3
AGU*3
馬鹿正直設計と言えるかもしれない。31 ：・∀・）っ-○◎● ◆DanGorION6 ：2007/01/21(日) 15:12:30
その上整数パイプラインとFP/SIMDパイプラインに分かれてる。32 ：デフォルトの名無しさん ：2007/01/21(日) 15:26:22
その代わりK8はスレッド数が増えても急激な性能の低下はないね。
Core2はコア数×2スレッド以上になると急に遅くなる。33 ：デフォルトの名無しさん ：2007/01/21(日) 15:29:39
ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、
具体的にどれくらい?34 ：・∀・）っ-○◎● ◆DanGorION6 ：2007/01/21(日) 15:34:56
単純に1スレッドだけだと2MB〜4MBのキャッシュを占有できるからじゃないの？なにが原因があるのかは知らないが
コンテクストスイッチングに弱点があるとして
HyperThreadingとマルチコア化で同時処理スレッド数を稼ぐ方針だから
差し引きオッケーになるんじゃねーの1 ◆.MeromIYCE ：2007/01/21(日) 23:32:22
>>23
4issueのCPUで演算パイプラインが常時IPC4で回るとかあり得ないのは
当然のことだと思うのだが、意図的に間違えてるのか？
そういう意味じゃCore2もK8もIPC3すら全く達成できてない/する気がない。それとは別に、パイプラインを3→4に強化すれば高速化するのは間違いない。
その高速化に対して、IPC4+のケースがあることも、そうじゃないことも貢献している。
その他色々な強化を積み重ねて、Core2はあのスピードを手に入れたのだ。
K8だってCore2だって、IPCが1.4のところを1.5にしようと必死に頑張って作ったはず。あと、俺はむしろK8の演算器（(ALU+L/S)*3）が過剰でバランスが悪いと感じる。
もっとも、これがK8のパワーの源だとも思うし、実際にはそう悪くないのだろう。
よく言われることだけど、ALUが過剰とかキャッシュだけ多いとかいうのは
設計思想の違いで、どちらが良い悪いというものではない。
バランスが悪いとダメだけど、K8やCore2がそこまでバランスが悪いとは思わない。ところで、大原さんは別にCore2を貶してるわけじゃないんだよね。
ただ、「Core2は（x86命令で）IPC4を狙った設計ではない」と主張してるだけで、
4issueは無駄だとか、K8より性能が劣るとか、設計が悪いとかは、言ってない。
なぜそう主張したいのかが、さっぱりわからないんだけど。今度のK8Lは、「より確実にIPC3を出し続けることを狙ったCPU」だと思う。
このK8Lと、「IPC4を狙ってデコード・スケジュールでつまづく」Core2の戦いは楽しみだ。：デフォルトの名無しさん ：2007/01/21(日) 23:54:41
そそ、Intel processorが特別ピーキーで(絶妙な)設計なだよなー（・∀・）
AMDに限らず、RISC processorでも馬鹿正直といったら失礼だけど、大雑把なつくりのがおおいし。Intel processorは、伝統的に速くなるところはそれだけ投資するし、速くならないところは細部でも積極的にケチる。
社内で実プログラムの動作が研究し尽くされていて、開発能力に余裕がなければできない芸当。
decode BWみたいに局所計測系benchmarkの単調な命令の羅列ではまったく実力がわからん。
Intel processorは、いつも公開されるarchitecture的なspecから予想されるよりも実性能が高い。
これはcompilerの出来だけの問題ではない。あと、大原はIPCという言葉の使い方がよろしくない。
IPC xxを狙ったarchitectureという考えをそもそも捨て去らないと…。
実効3IPCや4IPCなんて最初から誰も考えちゃいないのに。デフォルトの名無しさん ：2007/01/27(土) 19:25:36
>>27
http://journal.mycom.co.jp/articles/2005/07/14/yonah/002.htmlCoppermine 1394万
Banias 2038万
Dothan 2676万
Yonah 1918+1918万61 ：デフォルトの名無しさん ：2007/01/28(日) 00:54:47
>>59
それは読んだよ。しかし、大原氏の計算方式だと、、同じコアのキャッシュ容量違いで、コアトランジスタの数が変わる理由が説明できない。
たとえば、X2の512KBと、１MB版は
512KB 15380万個 1MB 22740万個だが
コアトランジスタの数は
512KB 5708万個 1MB 4859万個となり、900万個の差が説明できない。あと、K8の場合、24KBのプリデコードビットもキャッシュ量として計算すべきじゃないか？とか思ったり
で、整合性を持たせた結果、個人的に”こんなものか”とはじき出した数字がこれくらい。
初代 K7 1360万
初代 K8 1770万
90nm K8 2660万
Rev.F K8 DualCore 2870万
Rev.F K8 SingleCore 2990万
Pentium3 773万
PentiumM (130nm) 1146万
PentiumM (90nm) 1246万
CoreDuo 1326万
Core2 Duo 2096万過去のCPUの傾向から言うと
1バイトあたりのトランジスタ数はK8が約70個、PentiumMが約60個という傾向も見えてきた。
なかには40個台のもあるが、これでは6トランジスタでは作れないので、（6トランジスタで作るには、最低54個必要）、4トランジスタで作っているか、公式発表の数字がうそか、どちらかだろう。
たしか大原さんはyohnaが出たときに、あまりにトランジスタの増加が少なくって不思議に思って論理回路のサイズを計算したはず、その計算を使っているのかな？計算方法で値がかなり違ってくるけど、同じ計算方法なら相対的な差はある程度わかる。
PentiumIII系列のCPUは無駄の少ないトランジスタの使い方をしている。C2Dでも3×simple decorderと1×complex decorderを持つし、2つの実行ユニットともう1つの実行ユットは役割がことなる。こういった相似形でない回路だと設計コストが増えてしまうからリソースの多いIntelの強みだろうな。
また、x86命令のうち使用頻度の少ないものにはリソースを割かないのだろう(LCP判定とか面白い http://journal.mycom.co.jp/column/sopinion/180/)。こうするとトランジスタを減らせるだけでなくてパイプラインの段数を減らせる。C2Dがクロック耐性が高いのには、こんな理由があるのでないだろうか。
Perlスクリプトを使っているとAtholonの方が圧倒的に速い気がするけど、Coreは無駄の多いコードでも処理が速いはずなので、あれは生成されるコードに古い命令が入っているからかな。C2Dはわからん、あの大容量L2キャッシュはすごく利きそうだけど。
IPC4に効果があるかという問題についてはSPARCの例なのでx86も同じであるかわからいだけど、実行できる間で1/5から1/6くらいが4命令同時実行できるようだ。http://journal.mycom.co.jp/articles/2006/12/11/sparc64/001.html その一方で、同程度の時間から4倍もの時間が実行できなかったりしている。トータルで見ると1/6*4/3*1/4から1/5*4/3*1/2と計算して3%から7.5%くらいの性能向上になるはず。実行ユニットは33%増になるので、全体のうち実行ユニットが占める割合が1/3以下くらいだったら、まぁ悪くないコストになるかも。利用していない4/5の時間は電力を切っておけるので、パイプライン段数を増やしてクロックを上げるよりもメリットはあるかも。
次世代Athlonの演算に割り当てとデコードの順番が逆になる件
・∀・）っ-○◎● ◆DanGorION6 ：2007/01/21(日) 23:37:33
K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを
K8Lではディスパッチ後にデコードするようになってる。
このへんってどんな効果あるんだろ40 ：1 ◆.MeromIYCE ：2007/01/21(日) 23:51:02
>>39
SIMDの方にディスパッチしてから64bit単位で命令を解釈し、
ある程度トランジスタを割いてうまくスケジュールして、
同じピークSIMD性能のCore2を超える実性能を叩き出す、
というのが俺の希望だが、実際どうだろね。
ディスパッチ前の命令の単位が64bitから128bitに変わったことが
影響していると考えていいと思うけど。
整数演算とFP/SIMD演算に関連性が少ないので、あわせてスケジュールするメリットが少なかったということじゃないかな。それと先にデコードするとμOPが増えてしまって次世代で演算ユニットを拡張したメリットがなくなってしまうのかもしれん。
たしかXbox360のCPUでも同じようなことしていた。Intelのような、どっちも実行できる演算ユニットと独立した演算ユニットのどっちが良いのかね。Floatの比較してあとに何らかの処理すると、ちょっとレイテンシが増える？
正規表現について
22 ：・∀・）っ-○◎● ◆DanGorION6 ：2007/01/19(金) 00:53:26
正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ
（言語処理系だとHaskellとかに使われてるね）現実には後方参照とか量指定とかのリッチな機能使いたがるから
一意に定まる部分文字列をBoyer-Moore法などを用いて先行して評価し
NFAを評価するほうが主流なんだよな
これは鬼車なんかが使ってる。自己書き換えでNFAのバックトラッキングを高速に処理するとかできれば
理想だけど、まあ無理だ罠。
とにかくメモリレイテンシが重要。＃投機スレッディングが有効かと思ったり
同意。メモリアクセスが多すぎてボトルネックになっている。独立したデータが多数あれば、論理スレッド＋大容量キャッシュ+帯域確保が有効だね。その場合、2スレッドなんかじゃなくて4スレッドくらいほしいけど、ピーキーなCPUになってしまうな。プログラムがCPUにアクセスしたときに使っていないring2-ring3あたりを利用してプログラム内でスレッドを幾つ用意するか変更できると良いなぁ。関係ないけど論理スレッドの鬼門はキャッシュ汚染とみた。まだこの辺が改良の余地あり？
