x86命令の所要クロック計測スレPart3

x86命令の所要クロッ� ..

2:1 ◆.MeromIYCE
07/01/10 12:33:18
関連サイト（日本語）
コピペで動くVC++のインラインアセンブラ例
URLﾘﾝｸ(www.fides.dti.ne.jp)
基本的な整数命令/スタックの使い方
URLﾘﾝｸ(ray.sakura.ne.jp)
FPUやMMX,SSEの命令解説など。最適化の色々な話がある
URLﾘﾝｸ(homepage1.nifty.com)
pentopt（古）の日本語訳など
URLﾘﾝｸ(hp.vector.co.jp)
Intelの日本語技術資料のダウンロード
URLﾘﾝｸ(www.intel.com)

関連サイト（英語）
Intelの最適化マニュアル（Core2についても載ってる）
URLﾘﾝｸ(developer.intel.com)
Software Optimization Guide for AMD64 Processors
URLﾘﾝｸ(www.amd.com)
Intel向け最適化手法やクロックテーブル、testp.zipで手軽にrdpmcが使える
URLﾘﾝｸ(www.agner.org)
各CPUのレイテンシ-スループットの表（K7K8あり）
URLﾘﾝｸ(swox.com)
x86CPUの各種データシート
URLﾘﾝｸ(www.sandpile.org)
AMD CodeAnalyst Performance Analyzer、AMD用パイプラインの様子がわかるシミュレータ
URLﾘﾝｸ(developer.amd.com)

CPU関係の記事が読めるかもしれない場所
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(www.geocities.jp)
URLﾘﾝｸ(mypage.odn.ne.jp)

3:デフォルトの名無しさん
07/01/10 14:51:35
　　　　　　　　　　ヽ　/ /⌒＼
　　　　　　　　／ヽヽ|/⌒＼ii|＼
　　　　　　　／／ヾゞ//／＼＼|
　　　　　　　|／　　 |;;;;;;|/ハ　＼|
　　　　　　　　　　 |;;;;/／⌒ヽ
　　　　　　　　　　 |;/（　＾ω＾） >>1おっおっおっ乙枯ー
.　　　　　　　　　　　|｛　∪　　∪
　　　　　　　　　　 |;;ヾ.,____,ノ
　　　　　　　　　　 |;;; |
　　　　　　　　　　 |;;;;;|
　　　　　　　　　　 |;;;;;|

4:デフォルトの名無しさん
07/01/10 16:41:55
>>1
STARGA乙ERS

5:1 ◆.MeromIYCE
07/01/11 13:23:52
前スレ埋まりました。

6:デフォルトの名無しさん
07/01/11 21:01:08
GJ!

7:デフォルトの名無しさん
07/01/12 16:01:16
2ch閉鎖したらどーすんの？

8:デフォルトの名無しさん
07/01/13 00:37:09
大原が入稿してからついに一週間経つのにまだ掲載されてないなんて
サボりすぎってレベルじゃねーぞ

9:・∀・）っ-○◎● ◆DanGorION6
07/01/14 02:32:10
珍しいなム板で500KB制限って

ただでさえ長文とソースコードの多いスレだけど

10:デフォルトの名無しさん
07/01/14 21:51:15
第189回 Core MicroArchitectureをもうすこし(13)
URLﾘﾝｸ(journal.mycom.co.jp)

やっと5日入稿分が来たよ
相変わらずこのスレ見てるな

11:デフォルトの名無しさん
07/01/14 22:00:42
このスレとは関係ないけど

> 例えば昨年のComputexでMobile向け新コアの説明がちょっとあったが、Memory Controllerと
> Hyper Transport Linkのみがモバイルに最適化されたという話で、コアそのものはK8L(というか、
> Revision H世代?)と共通になってゆく模様だ。

そのリンク先を見る限りモバイル向けコアはK8Lとは違うように見えるのだが…

12:デフォルトの名無しさん
07/01/14 23:17:12
サーバーを意識した設計だがRASは無い

13:1 ◆.MeromIYCE
07/01/14 23:38:58
俺はnopは実行ユニット使ってると思っていた。そこで実験。Dothanで。
結果は大体見えるけど、初心忘るべからずってことで生真面目にやってみますね。

ループ回数は1000回、10000回で測定。場合に応じて回数を変化させて傾向を見る。
lp:
and edx,edx
dec eax
jnz lp
これはキッカリ1.5clk/loop。

lp:
xchg eax,eax ; nopと書くのと同じマシン語になる
dec eax ; ここをecxに変えても所要クロックは全く同じ
jnz lp
これは1.56clk/loop程度。なぜちょっとだけ遅いのだ。
nopが遅いってことではなくて、loopが整数クロックでない複雑さが影響している感じ？
もっとも、2clk未満なのでnopとdec eaxに依存関係がないのはわかった。
（ていうかnopを連続させるベンチを見れば、nop同士にも依存関係がないのは明らか）

たぶん、nop命令は同時使用レジスタ数とかのシバリとかも関係ないだろう。
（普通のxchg命令はレイテンシが2clkと遅いので計測からはよくわからなかった）

14:1 ◆.MeromIYCE
07/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でも同じじゃないかな。

クロック計測の観点から言えば、「実行する」と表現した方がわかりやすいと思う。
この辺は言葉の問題なので、適宜使い分け。

15:1 ◆.MeromIYCE
07/01/17 18:51:26
IA32 x86 JITアセンブラ Xbyak
URLﾘﾝｸ(homepage1.nifty.com)

動的アセンブル。なかなか使いやすそう。
mov(ecx, n); などと関数にしてしまう実装が面白い。

でも、いざ使おうと思うと、何に使ったらいいかわからないな。
自己書き換えよりは安全でスマートな方法だが、
定数部分の自己書き換えの範疇を超えた使い方があれば面白い。

16:デフォルトの名無しさん
07/01/17 20:48:36
計算式や正規表現のようなユーザから来る可変な表現からプログラムを生成。

17:デフォルトの名無しさん
07/01/18 03:40:29
Cの関数のような表記のアセンブラといえば、CELLのもそうじゃなかったっけ?
#つーか、あれは関数表記のインラインアセンブラなのかも知らんが。

18:デフォルトの名無しさん
07/01/18 03:59:06
そりゃIntrinsicsじゃないのか？
URLﾘﾝｸ(en.wikipedia.org)

VC++のMMX/SSE対応とか。

19:・∀・）っ-○◎● ◆DanGorION6
07/01/18 06:52:49
あれはもともとIntelコンパイラの組み込み関数

CellのはCode WarriorのAltiVec拡張と同じ構文ルールだが
あちらは「演算子」なんだな。
Cで「関数」のオーバーライドはサポートしてないはずだ。
たとえばvec_addもしくはspu_addはvector int とvector shortでは別の操作になる

20:1 ◆.MeromIYCE
07/01/18 23:53:42
>>16
正規表現か。難しそうだな。
結局、定数書き換え以上のことやろうとすると、コンパイラみたいなのを
自作してプログラムに入れないといけないんだよな。

ぶっちゃけ定数埋め込みだけでも意義は大きいと思うし、
最後に0.99をかける処理をする/しないの選択みたいな要素が8個あれば
高速化を考えれば普通なら256通りのコードを用意する必要があるわけだから、
そういうのに使ってもいい。

>>17
べつにmov(ecx, n); でmov ecx, n を実行するわけじゃなくて、
将来実行するコードにmov ecx, n のマシン語を追加しているのだ。
単なる表記法の話とは違う。

21:デフォルトの名無しさん
07/01/19 00:23:01
>20
callが並べられれば既に最適化されている一連の関数をどういった順序で、ないし、どういったパラメータで呼ぶかが決められる。
比較処理の削減、BTBの節約程度にしかならんがな。

22:・∀・）っ-○◎● ◆DanGorION6
07/01/19 00:53:26
正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ
（言語処理系だとHaskellとかに使われてるね）

現実には後方参照とか量指定とかのリッチな機能使いたがるから
一意に定まる部分文字列をBoyer-Moore法などを用いて先行して評価し
NFAを評価するほうが主流なんだよな
これは鬼車なんかが使ってる。

自己書き換えでNFAのバックトラッキングを高速に処理するとかできれば
理想だけど、まあ無理だ罠。
とにかくメモリレイテンシが重要。

＃投機スレッディングが有効かと思ったり

23:デフォルトの名無しさん
07/01/21 01:38:34
第190回 Core MicroArchitectureをもうすこし
URLﾘﾝｸ(journal.mycom.co.jp)

24:・∀・）っ-○◎● ◆DanGorION6
07/01/21 03:07:36
> そうなると、そうすると

もちつけｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
最近仕事が粗いな

つーか、リオーダバッファが96エントリもあれば局所的なユニット不足って
十分解消できると思うんだがね俺の考えでは

ROBを深くしてロード命令を先行して実行してれば
たいがいのコードって

つーか、リオーダバッファが96エントリもあれば局所的なロードユニット不足って
十分解消できると思うんだがね
そのためにMemory disambiguationがある。
ストア命令が一個もないループなんぞ【逸】般的でしかない。

64bitではSSE2までは標準命令セットだから、そのへんの実行効率についても
検証していただきたいところだね。

25:・∀・）っ-○◎● ◆DanGorION6
07/01/21 03:21:32
俺くどいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

26:デフォルトの名無しさん
07/01/21 04:13:03
URLﾘﾝｸ(journal.mycom.co.jp)

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:デフォルトの名無しさん
07/01/21 04:15:27
つづき

URLﾘﾝｸ(journal.mycom.co.jp)

これと同じことを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が、95M

Penteium4だと
プレセラで(376-248)/2=64M
プレスコットで125-62=63M
割といい感じと言うか、ほぼぴったり！
しかしトランジスタ数がCore2の3倍に達することになるが。

長々と書いたが、半分大原氏に向けて書いたつもり。
ここをみてる様だから。

参考文献
URLﾘﾝｸ(www.sandpile.org)

28:デフォルトの名無しさん
07/01/21 07:39:11
大原なんてどうでも良い
もちっと突っ込んだ話に進めよう

29:・∀・）っ-○◎● ◆DanGorION6
07/01/21 12:48:50
「モノ書くってレベルじゃねーぞ」

30:デフォルトの名無しさん
07/01/21 14:47:40
大原氏の検証が正しいどうかかわからないが、Core2のトランジスタ数が少ないのは事実であろう。いずれにせよ、Core2のトランジスタ効率はかなり良い。
K8の60-70%程度の演算パイプライントランジスタ数で、120％の性能を発揮しているのだから。
遡れば、K7 2200万トランジスタに対して、Pen3 950万トランジスタで、クロック当たり性能がほぼ互角だったのだから、AMDのアーキテクチャーには無駄が多いのかもな。

K8のブロック図を見ても
コンプレックスデコーダー*3
対称型ALU*3
AGU*3
馬鹿正直設計と言えるかもしれない。

31:・∀・）っ-○◎● ◆DanGorION6
07/01/21 15:12:30
その上整数パイプラインとFP/SIMDパイプラインに分かれてる。

32:デフォルトの名無しさん
07/01/21 15:26:22
その代わりK8はスレッド数が増えても急激な性能の低下はないね。
Core2はコア数×2スレッド以上になると急に遅くなる。

33:デフォルトの名無しさん
07/01/21 15:29:39
ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、
具体的にどれくらい?

34:・∀・）っ-○◎● ◆DanGorION6
07/01/21 15:34:56
単純に1スレッドだけだと2MB～4MBのキャッシュを占有できるからじゃないの？

なにが原因があるのかは知らないが
コンテクストスイッチングに弱点があるとして
HyperThreadingとマルチコア化で同時処理スレッド数を稼ぐ方針だから
差し引きオッケーになるんじゃねーの

35:デフォルトの名無しさん
07/01/21 15:52:36
Intelの共有キャッシュ = 再構成可能キャッシュ

36:デフォルトの名無しさん
07/01/21 15:59:52
そうだね。
黙っててもマルチコア化は進んでいくわけだから、シングルスレッド強化のほうが、むしろ理にかなってるとも言える。
また、1コア当たりのトランジスタ数を抑える方が、コアを増やす上で、これまた理にかなっているだろう。

K8Lは、さらに1コア当たりのトランジスタ数を増やすようであるが、
面積で言えば、20％ほど増える。単純計算では5000万トランジスタぐらいか。
K8 5000万対Core2 2870万で互角以上なら、多少のマイナスも問題ないだろうし、
さらに5000万対2870万 x2コアって戦い方も出来る。

37:デフォルトの名無しさん
07/01/21 16:08:42
何言ってんの？K8といえば今やX2だろう。

38:1 ◆.MeromIYCE
07/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の戦いは楽しみだ。

39:・∀・）っ-○◎● ◆DanGorION6
07/01/21 23:37:33
K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを
K8Lではディスパッチ後にデコードするようになってる。
このへんってどんな効果あるんだろ

40:1 ◆.MeromIYCE
07/01/21 23:51:02
>>39
SIMDの方にディスパッチしてから64bit単位で命令を解釈し、
ある程度トランジスタを割いてうまくスケジュールして、
同じピークSIMD性能のCore2を超える実性能を叩き出す、
というのが俺の希望だが、実際どうだろね。
ディスパッチ前の命令の単位が64bitから128bitに変わったことが
影響していると考えていいと思うけど。

41:デフォルトの名無しさん
07/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なんて最初から誰も考えちゃいないのに。

42:デフォルトの名無しさん
07/01/22 02:02:48
Intelerお久

43:デフォルトの名無しさん
07/01/22 03:57:13
どこが優っていて、どこが劣っているとか、
それは最終的には関係なく、結果叩きだされる性能が指標なわけで…

最近のベンチマーク結果にメモリ帯域とか、レイテンシ計測が出てくる不思議さ。
なんというか、100M決勝で10M加速を比べられているような…
IPCもその意味をなすことが今後は難しいんじゃないですかね?

大原記事はこれから読むw

44:デフォルトの名無しさん
07/01/22 04:25:04
読んだ。
AMDのCPUは実行IPC3で常に回っていて(脳内or観測的希望)
intelのCPUはIPC4を謳ってい入るがそんなわけねーよ(AMD比)pgr、ということなのか…

瞬間風速だとしても、それを出せない回路でその数字を謳うのはある種詐欺なわけで、
たとえ一瞬だとしてもそれが出せることは大いに喜ぶべきことなのでは?
(その宣伝を気に入る、気に入らないという話ではないこと前提でｗ)
それを意識するあまり平均性能が落ちるとかならいざ知らず、
ほとんどのベンチマークで勝っているわけで、without メモリコントローラ。

45:デフォルトの名無しさん
07/01/22 10:40:18
おはようございます。
なんだよ、観測的希望ってw
やっぱり眠い時レスしちゃダメなんですね。
大原氏ごめんね。

46:1 ◆.MeromIYCE
07/01/22 14:20:45
>>43
論旨には賛同するが、メモリ帯域やレイテンシ計測は是非やって欲しいよ。
もちろん、そういう計測をそのままCPUの性能と思ってしまうのは論外だが、
「自分はこの処理をさせたいが、どのCPUがいいだろう？」と思ったときに
一般アプリの実性能ベンチだけではイマイチ検討のしようがない。

まあ、こういうのは最近の流行りじゃないんだろうねぇ。
確かに俺も、とりあえず帯域ベンチやっときましたみたいな記事を見ると、
色々誤解が広まりそうで嫌な感じはする。

47:デフォルトの名無しさん
07/01/22 17:20:36
CPUの性能を調べることと素性を調べることの差って感じか

48:デフォルトの名無しさん
07/01/22 17:55:49
周波数特性だけで盲目的に音質を語るな

49:1 ◆.MeromIYCE
07/01/22 19:03:17
>>47
そうだね。
あと、ベンチって結果から製品を選ぶのが目的と見せかけて
むしろ好奇心を満たすものという面が大きい。
性能より素性を知りたい人が少ないってのが寂しい。

>>48
そういう意味じゃ、CPUは速いのが正義だから、まだ簡単だ。
MP3とACCの比較とか、ありゃあ泥沼になるわけだ。

50:デフォルトの名無しさん
07/01/22 19:32:31
マルチコアはいつから使えるコアになるのか？
URLﾘﾝｸ(www.ne.jp)

51:1 ◆.MeromIYCE
07/01/22 20:12:17
>>50
実際にどっちを買うべきかという話ではなくて、CPUメーカーがシングルコア路線を続けた方が
動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話だね。

結局、俺は使ったことがないからわからないんだよな。
それに、Pen4からCore2Duoに乗り換えた人は、
Coreアーキだから速いのか、デュアルコアだから速いのか、Pen4が遅かっただけなのか、
何が原因だか容易には知ることができないだろう。

俺は前から、体感したYonahの速さからデュアルコアをすすめる人の多くが、
CoreSoloでも同じ速さを感じるのではないかと思っていたが、これも確かめるのが難しい。

一方、Intelとすれば、シングルでも非常に高速なYonahやConroeで
デュアルコアをスタートさせたため、商売としては成功したと言えるだろう。
（いや、ネトバのデュアルはスタート以前というか・・・それでもエンコは強かった）

52:デフォルトの名無しさん
07/01/22 20:47:04
>CPUメーカーがシングルコア路線を続けた方が動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話

IntelはメニーコアのマイルストーンとしてAdaptability(適応性)ってのを挙げてる。
シングルコア強化路線「だけ」ではムーアの法則に追随できないから、
まず前提としてシングルスレッド性能の強化があって、
その開発期間の隙間を埋めるのがコアの増加なんだと思う。
例えばDMTなんか65nmに微細化した今でも実装されてないし。

53:1 ◆.MeromIYCE
07/01/22 21:27:29
>>52
AdaptabilityやDMTの意味がわからないが、
前提となるコストと熱設計の中で最も性能の高いものを作るだけじゃないの？
開発期間の隙間と言っても、開発が済んだらコアを減らすわけでもないだろうし。

54:デフォルトの名無しさん
07/01/23 01:46:26
Speculative MultiThreadingによってILPの壁を突き破れるようになるまで
シングル、マルチを無駄に意識させられるんだと思われ。
ILPを挙げるのに、これ以上トランジスタと電力に投資するのが非効率だから
TLPを意識しましょうっていうのは実際逃げだろうけど、
タイタニックじゃないけど、逃げなきゃいけない状況(それ以上の解が見つからない状況)なのに
意固地に頑張る必要もないはず。
メモリレイテンシの隠蔽の効果が、めいっぱい頑張ったシングルコアを超えずとも
良い勝負かつ、より低消費電力ならそっちが正解だと思う。

そういう点から、例え現状しょうがなく目指したとしても、
むこうに今よりもbetterな解があるならそれで良いジャマイカ派。

55:デフォルトの名無しさん
07/01/23 02:29:49
SpMTが高めるのはMLPだ。
"ILPの壁を突き破る"という表現はおかしい。

56:デフォルトの名無しさん
07/01/23 04:35:11
ILPという言葉に関しては、一つのスレッドに対して使う言葉なのかな。
並列性の高まるスレッドが別であることに対しては無効であるなら認識不足だった。
勉強になります。

Wikipedia項目ﾘﾝｸ
これ読む限りじゃ、投機実行もILPを高める手法の一つにはカウントされてる模様。

57:1 ◆.MeromIYCE
07/01/23 16:12:57
>>56
> Speculative MultiThreadingによってILPの壁を突き破れるようになる
の「ILPの壁」というのは、「シングルスレッド処理のIPC向上の壁」と言えばいいんじゃない？
ILPと言うと、メモリ以外の命令同士の依存関係を何とかするみたいな感じを受けるから。
＃メモリアクセスもI（命令）だと言われればそうだけど。

俺は、メモリ以外のILPの問題の方が本質的だと思うので、ここではILPという言葉は使わない。
手動でプリフェッチすれば同等の性能が出るであろう技術には個人的に萌えない。

しかし、SpMTによって、手動でprefetch命令を入れたのに匹敵する効果が得られるなら、
これこそプログラマに優しい、「逃げない」技術なのかもしれないとも思った。

> 投機実行
それは、文脈からして条件分岐命令に対する投機実行のことだから、
投機的マルチスレッディングとは関係ないと思われる。

>>54
逃げなきゃいけない状況なら逃げないといけないね。
何事もバランス、中庸。
>>53ではああ言ったが、最後の2行は同意。単純に対応ソフトの普及促進にもなるし。

58:デフォルトの名無しさん
07/01/23 19:59:29
AMD Rev.F Processor には、RDTSCPという命令が追加されているらしいな
URLﾘﾝｸ(www.atmarkit.co.jp)

59:デフォルトの名無しさん
07/01/27 19:25:36
>>27
URLﾘﾝｸ(journal.mycom.co.jp)

Coppermine 1394万
Banias 2038万
Dothan 2676万
Yonah 1918+1918万

60:・∀・）っ-○◎● ◆DanGorION6
07/01/27 21:07:17
大腹自身の記事かよｗ

61:デフォルトの名無しさん
07/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トランジスタで作っているか、公式発表の数字がうそか、どちらかだろう。

62:・∀・）っ-○◎● ◆DanGorION6
07/01/28 01:05:20
Pentium Mは4トランジスタじゃなかったっけ

ってソースがこれだったｗｗｗｗ
URLﾘﾝｸ(journal.mycom.co.jp)

大原氏は記事書く際はちゃんとウラを取って欲しいな

63:デフォルトの名無しさん
07/01/28 16:02:55
まあ大原もここのスレ住人も、ほとんどが確たるウラをとらずに好き
放題発言しているだけだけどな。５０歩１００歩じゃねーか？

ソースを張っても、そのソースが本当に正しいかウラが取れてるわけ
じゃない場合が多いし。ソースが大原記事なんてのがその典型ｗ

64:デフォルトの名無しさん
07/01/28 17:27:01
PenMが4トランジスタSRAMってのは間違い。
大原自身が訂正してたよ。
6トランジスタです。

65:デフォルトの名無しさん
07/01/28 17:29:57
そろそろclock計測の話題に戻ろうよ。
ここは実験と実証のスレで、理屈と情報、妄想だけのスレなんて他所にたくさんあるわけだし。

66:・∀・）っ-○◎● ◆DanGorION6
07/01/28 18:13:52
素人が個人ブログや掲示板に自己満足記事投稿するのと
企業から金貰って大衆に読んで貰うための記事をかくのと
全然影響力・説得力が違うがね。

67:デフォルトの名無しさん
07/01/28 18:36:11
クロック数計測してもTr数はわからんし。

―大事なのは素材ではなくその精神なのです。

68:デフォルトの名無しさん
07/01/28 18:49:20
>>66
大企業メディアの情報の質、正確性、量、速度が
個人サイトの集合を上回っているとはいえなくなりつつある
ネット社会の現代、こういうライター稼業のなんてもう流行らないのかも。

しかし、それにしても国内のハードウエアレビューは質が低い。
AnandTechやTom's, INQなどは個人サイトが反映しても死ぬ気がしないんだけど、
国内ではそのような優良サイトがない。情報も一方的だし、ライターの記事は情報が少なく、遅い。

69:デフォルトの名無しさん
07/01/28 22:35:46
この計算はあってるの？

URLﾘﾝｸ(www.anandtech.com)
If we assume that 288M transistors (6T SRAM) will be used by the 6MB cache,
that leaves 122M transistors for L1 cache and the rest of the core.
Applying the same calculation to Conroe gives us 99M transistors left over,
meaning that there are roughly 23% more core-logic,
control and L1 transistors being used in Penryn than in Conroe.

70:デフォルトの名無しさん
07/01/28 23:07:10
第191回 Core MicroArchitectureをもうすこし(15)
URLﾘﾝｸ(journal.mycom.co.jp)

71:デフォルトの名無しさん
07/01/29 02:38:23
>>70
なんかどうみても、これスレを読んでいて、且つこのスレに対して
言い訳してるようにしか読めないな。

大原氏には悪いけど。

72:デフォルトの名無しさん
07/01/29 02:50:03
>>70
話の持っていきかたの無理矢理感が・・・・・

73:・∀・）っ-○◎● ◆DanGorION6
07/01/29 02:59:02
どんな下手な書き方してもIPC=3を出せるハードという意味なら永久に無理に決まってる。
ソフト側も「IPC=3を出せるコード」であることが前提。

74:デフォルトの名無しさん
07/01/29 03:14:52
そこでEPIC

75:・∀・）っ-○◎● ◆DanGorION6
07/01/29 03:45:05
4IPCを狙ったアーキじゃないって論は云々はどっちかというと
この人の記事を読んで真に受けただけじゃなかろうか
URLﾘﾝｸ(www.ne.jp)

別に　ALU+Load, ALU, ALU, Store
もしくは　ALU, ALU, ALU, Load or Store
でもx86換算4命令になるわけだがな。
インオーダで実行するわけじゃないんだから、3IPC以上出せないというのは
大きな間違いだよね。

従来のアーキテクチャではストア命令が来る度に、格納先が確定するまで
後続のロードとそれに依存する命令を発行できないという縛りがあるわけで、
レジスタが少なくロードストア頻度の高いx86でIPC=3を実現する上で大きな縛りになってる。
Core 2で導入されたMemory Disambiguationはそのへんを解決してる。

大原氏はCore 2で平均IPCを引き上げるためのその辺の機構を正当に見てない希ガス。

安藤壽茂氏なんかの記事はちゃんとそのへんも触れてる。

76:Store forwarding
07/01/29 06:45:21
キャッシュラインサイズが256Bというのもその辺考えてるのかもな。

77:デフォルトの名無しさん
07/01/29 17:55:37
>>76
キャッシュラインサイズが256Bって何？

78:デフォルトの名無しさん
07/01/29 20:47:10
P6,Netburstでは、unknown store-addressがあってもそれ以降の別のストアはアドレス計算できれば発行可能。
またunknown load-addressがあってもそれ以降の(アドレス計算可能な)ロードやストアは発行可能。
唯一できなかったパターンがunknown store-address以降の(アドレス計算可能な)ロード発行で、
これはCore 2で可能になった。

これに対してK7,K8では、unknown store-addresがあるとそれ以降のロードやストアは発行できない。
またunknown load-addressがあってもそれ以降のロードやストアを発行できない。
ロードやストアのAGU命令はインオーダー発行になっているようだ。
K8Lでロードのアウトオブオーダー発行が実装されるが、
どの程度のアウトオブオーダーなのか、またそれによってどの程度性能が向上するのか、
楽しみではある。

計測情報源：URLﾘﾝｸ(www.realworldtech.com)

79:デフォルトの名無しさん
07/01/30 05:36:05
今回のは何を言いたいのかさっぱい伝わってこないのだが…
これなら昔の電波の方がよっぽど読み応えがあったｗ

80:デフォルトの名無しさん
07/01/31 20:10:09
URLﾘﾝｸ(pc.watch.impress.co.jp)
これらのプロセッサでは、Coreマイクロアーキテクチャとしては初めて
Hyper-Threading Technology(HTテクノロジ)をサポートすることになる

81:デフォルトの名無しさん
07/01/31 22:45:47
Penryn does not have HT
URLﾘﾝｸ(www.theinquirer.net)

82:デフォルトの名無しさん
07/02/01 02:07:56
URLﾘﾝｸ(grape.astron.s.u-tokyo.ac.jp)
むーん、オールジャパンってそういう話か、というか、それはそうなんだけど、そんなので計算機作れるのかよ、、、

83:デフォルトの名無しさん
07/02/01 04:32:35
Vista 64bit版も出た事だし、そろそろx86-64の話題が欲しいですね。
スレ違いか？

84:・∀・）っ-○◎● ◆DanGorION6
07/02/04 15:21:39
URLﾘﾝｸ(www.anandtech.com)

Penrynはdual coreだ。そしてquad coreはただそれらを二つパッケージに封入しただけだ。
ただ、あとからシングルダイの製品が登場するかもしれない。
トランジスタ数が4億1000万なので、Penrynが6MBの共有L2 cacheを持つと予想できる。
Penrynのロジック部はConroeの進化形になるだろう。
キャッシュの増量分以上の機能的・性能的追加が期待できる。

2億8800万トランジスタが6T-SRAMの共有L2キャッシュに利用されているとすれば
残り1億2200万トランジスタはL1キャッシュとコアに費やされていることになる。
同じ計算をConroeに適用すると、9千9百万のトランジスタがコアとL1 cacheに割り当てられている。
これらの事実はPenrynではConroeと比較して23%多いトランジスタがL1 cache, 論理, 制御に
使用されるのを意味する。

追加される機能が不明である現時点でさえ、SSE4のサポートがそれらのトランジスタの
かなりの部分を占めると予想するだろう。またIntelが45nmでクロックを上げるので
Penrynが3GHzよりも高いクロックで登場するのを容易に予想できる。
Conroeのオーバークロック耐性を考えると、Penrynのクロックが非常に良いのを見ても
そんなに驚かないだろう。

85:デフォルトの名無しさん
07/02/04 22:47:06
第192回 Core MicroArchitectureをもうすこし(16)
URLﾘﾝｸ(journal.mycom.co.jp)

86:・∀・）っ-○◎● ◆DanGorION6
07/02/04 22:57:40

　　ま　た　2　ち　ゃ　ん　ソ　ー　ス　か

87:デフォルトの名無しさん
07/02/04 23:13:12
> Penrynの世代でHyper-Threadingが搭載されるという。

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

88:デフォルトの名無しさん
07/02/05 00:31:26
今回のこれは大原を弄るのは酷かもな…
ネタの正確性はともかく言ってること自体は間違ってないというか、同意できる
つーかYorkfieldの中身が変更されたと判明した後もガセネタ流し続けたCharlie Demerjianは死ねｗ

89:デフォルトの名無しさん
07/02/05 01:17:24
409 ：名称未設定：2007/02/02(金) 17:22:28 ID:I0BGTsMO0
URLﾘﾝｸ(journal.mycom.co.jp)
URLﾘﾝｸ(journal.mycom.co.jp)

生ハムメロンワロスｗ

90:デフォルトの名無しさん
07/02/05 01:42:10
つーか、なんか論点がずれてるというか、大雑把な主張になってきたな。
もともとIPC=3を技術的に細かく検証しているはずだった気がするが、
いつのまにか
「発熱や消費電力が上がる関係でIPC=3は無理です」
になってる。

なら最初からそう言って終わっとけば良かった気がするが…

91:デフォルトの名無しさん
07/02/05 01:59:27
このシリーズはいつまで続くんじゃー！

92:デフォルトの名無しさん
07/02/05 02:05:06
Core2がIPC=4じゃないとする主張の理由の中に
K8がIPC=3であると思わせる部分がある時点で
大原記事wwwとなるのは明白。

93:デフォルトの名無しさん
07/02/05 04:56:57
元々はCoreMAとK8のIPC向上に対するアプローチの違いを言いたかったような気がするが。
細かく突っ込んでいって逆に全体像が見えなくなった感じだな。

94:1 ◆.MeromIYCE
07/02/05 19:11:14
>>89
Meromと果物のmelonをかけてるのだろうか？

Penrynに、L2キャッシュ増量とSSE4実装以外の目立った改善があるのか気になるね。
遅くなるプリフィックスと64bitでのマクロフュージョン、シャッフル系SSE命令などが考えられる。
まあ、このうち１つも対応されない可能性も大きいとは思うが。
命令フェッチ幅を32byteにするのはいずれ必要だけど、Penrynの次のアーキ辺りが妥当か。

95:デフォルトの名無しさん
07/02/05 19:14:56
Windows生ハム

96:デフォルトの名無しさん
07/02/05 22:51:33
AMDの方は L3キャッシュだろ。もうどうなる事やら。

97:デフォルトの名無しさん
07/02/06 00:03:52
トランジスタ増やしすぎたらいくら微細化してるとしても
クロック上げるのも難しいと思うのですよねぇ

98:デフォルトの名無しさん
07/02/06 02:25:15
そういえばK8LのL3は面積からしてZ-RAMじゃないな
大原妄想乙でした

99:1 ◆.MeromIYCE
07/02/06 07:04:51
初代スレの398でやったdivのレイテンシ測定をするプログラムを作ったので、
色々なCPUで試してみてくださいまし。
URLﾘﾝｸ(www.wikihouse.com)

Dothanでの結果は、こんな感じ。
除数大↓　被除数大→
15 23 39 39 39 - - -
15 15 23 39 39 39 - -
15 15 23 23 39 39 39 -
15 15 23 23 39 39 39 39

>>95
Windows生ハムの遅さを高速なmelonプロセッサがおおまかカバー、
melonプロセッサがWindows生ハムの素晴らしい機能を引き出す、
ってか。
いや、Vistaの話じゃないですよ。

100:デフォルトの名無しさん
07/02/06 10:43:10
Opteron146(Socket939 core=Venus)の結果をば。
除数大↓　被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40

101:デフォルトの名無しさん
07/02/06 11:53:40
Pentium 4 630 Prescott 90 nm
CPUID F.4.3

除数大↓　被除数大→
68 68 67 68 68 - - -
69 71 67 68 69 69 - -
69 69 69 69 70 68 70 -
69 69 70 73 71 71 69 69

102:デフォルトの名無しさん
07/02/06 13:10:50
Pentium 4 631 CedarMill 65nm
CPUID F.6.5

除数大↓　被除数大→
84 88 88 87 87 - - -
88 88 88 88 88 87 - -
87 88 87 87 87 87 88 -
87 87 87 87 88 87 88 88

103:デフォルトの名無しさん
07/02/06 13:42:24
Athlon XP-M 1800+ Thoroughbred Low Power
除数大↓　被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41

K6-2 400MHz Chomper Extended
除数大↓　被除数大→
19 19 19 19 19 - - -
19 19 19 19 19 19 - -
19 19 19 19 19 19 19 -
19 19 19 19 19 19 19 19

104:デフォルトの名無しさん
07/02/06 15:07:00
動かしてみるに吝かではないのだけれど、CPUの情報もプログラムで拾って表示してくれると便利だと思う。
それと、Linux版が欲しいとか贅沢も言ってみる。

ってことで、手元のCeleron 2GHz(という以外判らない)
除数大↓　被除数大→
51 51 51 51 51 - - -
51 51 51 51 51 51 - -
51 51 51 51 51 51 51 -
51 51 51 51 51 51 51 51

105:デフォルトの名無しさん
07/02/06 17:56:32
Celeron　1.7GHz(Willamette-128K)

除数大↓　被除数大→
50　50　50　50　50　-　-　-　
50　50　50　50　50　50　-　-　
50　50　50　50　50　50　50　-　
50　50　50　50　50　50　50　50　

106:デフォルトの名無しさん
07/02/06 18:00:28
Opteron144(Venus)だけど>>100と同じ結果

107:デフォルトの名無しさん
07/02/06 18:19:44
Pentium II

除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

108:デフォルトの名無しさん
07/02/06 18:23:44
Conroe

除数大↓　被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41

109:1 ◆.MeromIYCE
07/02/06 22:02:53
みなさんありがとう。
小さい数の割り算だと速くなるのはPenM～Core2だけみたいだね。
Pen4はステッピングが進むにつれて遅くなってくなあ。これがネトバだよな。好きだ。
K7/K8が、PenMの遅いところと同等程度。意外と速くないが、整数はこんなものか。
K6-2は低クロックとはいえさすが。今にして思えば味のある石だった。
PenIIがPenMと似た数字なのが面白い。PenMも地味にいい改良してるよなあ。

>>104
↓こういうのを表示できるようにして、後でアップします。
GenuineIntel Family:6 Model:D Stepping:6

Linuxは誰かにコンパイルしてもらいたいが、それにしてもVC++のインラインアセンブラはまずい。
アセンブラ部をNASM用にすることは可能だと思うので、ちょっと挑戦してみる。

>>108
あれ！？ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。
PenMの改善点を洗練させた感じだ。
基本的に被除数が32bitに収まる場合を高速化してるみたいだな。

Yonahのときに、割り算が速くなるという話があったが、Core2も同じか？
持ってる人Yonahの測定お願いします。

110:デフォルトの名無しさん
07/02/06 22:05:10
YonahとBaniasの計測がほしいね。それで完璧。

111:・∀・）っ-○◎● ◆DanGorION6
07/02/06 22:41:06
GCCなら-masm=intelオプションでほぼそのまんま移植できた希ガス

112:・∀・）っ-○◎● ◆DanGorION6
07/02/06 22:42:54
ほれPentium M（Banias）

除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

113:1 ◆.MeromIYCE
07/02/06 22:50:46
>>112
マジで！！！？？

114:デフォルトの名無しさん
07/02/06 22:52:44
今までの計測結果を見ると、
Banias->Dothanで大きな除算の改良が入ったように見える。
除数によって大きくlatencyが変化しているのはConroeのみなので、
もしかすると、Yonahから除数側の改良が入ったのかも知れず。
Yonahの計測結果ﾏﾀﾞｰ??

115:デフォルトの名無しさん
07/02/06 23:13:16
いや、除数側の改良もDothanからか。
Yonahでの発表は厳密にはウソってことでFA?

116:デフォルトの名無しさん
07/02/06 23:19:49
AMDFAM10について考察希望
ｽﾚﾘﾝｸ(jisaku板:557番),558,606-609,644-646

最新版はsvnで
svn co svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i386

117:1 ◆.MeromIYCE
07/02/06 23:26:08
>>99の測定は、下のコードと、そこからdiv ebxを抜かしたコードとの
差をdiv命令のレイテンシとしている。
lp:
add eax,xa ; xa,xdはメモリ
mov edx,xd ; 被除数は毎回破壊されるので毎回読み込む
div ebx
mov esi,eax ; レジスタをクリアして、かつ依存関係を保たせるあがき
neg eax
add eax,esi
dec ecx
jnz lp

いちおうPenMでは正しい結果を出してると思うけど（以前の測定でも散々追試してるし）、
ループ処理がそれなりに重いのでCPUによっては微妙かもしれないと不安になってきた。
もう少しいい処理・わかりやすいループのアイデアある？
まず、ループをアンロールというのはやろうと思う。

118:1 ◆.MeromIYCE
07/02/06 23:50:27
>>115
いや、Yonahの発表からすると、Yonahの時点でCore2の速さだったんじゃない？
どうも新しいCPUはレイテンシが微増する傾向があるみたいなので、
Yonah（PenMと同じ世代）がCore2（新しい）より速いということも考えられる。
>>108を見ると、PenMを改良したものからピッタリ2clk遅くなっている感じだ。

>>116
コンパイラの対応からK8Lの特徴を読み取ろうというのか。
costを見ればいいのかな。コンパイラに必要な情報というのはいい情報かも。。

119:デフォルトの名無しさん
07/02/07 01:43:41
Merom T5600
除数大↓　被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41

Pentium M 1.40GHz
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Athlon 64 X2 4800
除数大↓　被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40

Sempron 3000+(Socket A)
除数大↓　被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41

120:デフォルトの名無しさん
07/02/07 06:02:45
>>109
> あれ！？ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。

C1E等でクロック倍率が下がっている時でも
FSB１カウントにつきTSCは最高クロック倍率（
E6600なら9）ずつカウントアップする仕様みたい。
どんな時でもrdtscを２回実行すると、その差は必ず
(E6600の場合)9の倍数になる。

2コアでほぼ同時にrdtscを実行すると2コアともほぼ近い値が返ってきたが、
MBのBIOSをアップデートしたら、2コアで全く異なる値が返るようになってしまった。
その後、WinXPのデュアルコアパッチを入れたら2コアでほぼ近い値が返るようになった。

121:1 ◆.MeromIYCE
07/02/07 08:09:24
>>120
なるほど！数字としては今までと同じで、精度がコアの倍率分だけ悪くなっているのか。
2コアで同じ時計を持てるのは嬉しいが、やはりクロック単位の測定にはちょっと痛いな。

カウンタはどこにあるのだろう？
マザーボードのBIOSで影響するということはCPUの外だとも思えるが、
それだと2コアで異なる値が返ることがあるという現象に説明がつかない。
カウンタはコア毎にあって、CPUが起動するときに合わせるのかな？

>>99
CPUIDを表示するのと、>>117で言ったアンロール（2回）をやったのをアップし直した。
アドレスは同じ。

122:デフォルトの名無しさん
07/02/07 08:39:01
Core Duo T2400 1.83GHz
除数大↓　被除数大→
14 22 30 38 38 - - -
7 14 22 30 38 38 - -
7 7 14 22 38 38 38 -
7 7 7 14 38 38 38 38

123:122
07/02/07 08:45:22
更新されてたの気づかなかった
同じ環境

GenuineIntel Family:8 Model:E Stepping:6
除数大↓　被除数大→
15 23 31 39 39 - - -
8 15 23 31 39 39 - -
8 8 15 23 39 39 39 -
8 8 8 15 39 39 39 39

124:デフォルトの名無しさん
07/02/07 11:35:52
>>100を本日アップ分で再計測

AuthenticAMD Family:1 Model:7 Stepping:F
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

125:・∀・）っ-{}@{}@{}@ ◆DanGorION6
07/02/07 13:10:10
ソース読んだ
FamilyとStepping逆じゃね？

126:デフォルトの名無しさん
07/02/07 13:18:45
Core 2 Duo E6300

GenuineIntel Family:6 Model:F Stepping:6
除数大↓　被除数大→
20 30 39 48 48 - - -
12 20 30 39 48 48 - -
12 12 20 30 48 48 48 -
12 12 12 20 48 48 48 48

127:デフォルトの名無しさん
07/02/07 15:33:54
>>126 この結果ってCPUのクロック倍率が落ちた状態じゃないかな？
EISTやC1Eで自動的にクロック倍率が落ちるので、
FSB同期のrdtscでクロック数を計測するのはいろいろと面倒かも。

128:デフォルトの名無しさん
07/02/07 17:56:51
Merom T5600
GenuineIntel Family:6 Model:F Stepping:6
除数大↓　被除数大→
18 26 34 42 42 - - -
11 18 26 34 42 42 - -
11 11 18 26 42 42 42 -
11 11 11 18 42 42 42 42

PentiumM 1.4GHz
GenuineIntel Family:5 Model:9 Stepping:6
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Athlon 64 X2 4800
AuthenticAMD Family:2 Model:3 Stepping:F
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Sempron 3000+
AuthenticAMD Family:0 Model:A Stepping:6
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

129:デフォルトの名無しさん
07/02/07 21:51:56
>>103再計測。やっぱFamilyとStepping逆だね。
AuthenticAMD Family:6 Model:8 Stepping:1
除数大↓　被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

AuthenticAMD Family:5 Model:8 Stepping:C
除数大↓　被除数大→
18 18 18 18 18 - - -
18 18 18 18 18 18 - -
18 18 18 18 18 18 18 -
18 18 18 18 18 18 18 18

130:デフォルトの名無しさん
07/02/07 22:33:58
GenuineIntel Family:6 Model:8 Stepping:6
除数大↓　被除数大→
38 38 38 38 38 - - -
38 38 38 38 38 38 - -
38 38 38 38 38 38 38 -
38 38 38 38 38 38 38 38

131:1 ◆.MeromIYCE
07/02/08 00:02:01
>>123
二度手間ごめん。しかも結果違うorz
おそらく>123の方が正解。
これで、Core2のdivはYonahを2clk遅くしたものだとわかった。
Banias→荒削りのDothan→完成形のYonah→Meromの変化が面白い。

>>124 >>129
これも結果が異なるのか。やはり測定法に問題ありだな。
>>123 >>130とは逆にクロック数が減っているが、ALUパワーの差、かな。
K6-2も（当時としては）ALUが強い。対してP6系は総合的に速い割にALUは弱い。
2つのループの差からクロック数を求めているため、div以外の特徴も混ざってしまう。。

>>125
うあ～！俺のDothanはFamilyとSteppingが同じだから気がつかなかったよ。
指摘サンクス。後でこっそり修正しておきます。

>>127
確かに>126は2割、>128は1割だけクロック数が増えているな。
CPUのクロックが落ちても（今までのCPUと違って）rdtscのクロックは変わらないということか。
ただ、誤差が1～2割というのはSpeedStepにしては少ない感じがする。
ある程度のタイミングで補正はしてくるのか？

測定した人たちへ：毎度ヘボプログラムでごめんなさい。

次ページ