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

実測してみては？

皆さんこういう場合の計測ってのは、
かなりの回数ループさせてRDTSC読んでって
ことをやってらっしゃるんですか？

途中でコンテキストスイッチングが入ったりして、
うまく計測できないんですが・・・
つまり、計測しても分散が大きすぎて。

もしかして何らかの特別な計測用ツールを
使ってらっしゃいますか？

>>953
SetPriorityClass(handle, REALTIME_PRIORITY_CLASS);

を使うと、ほとんどコンテキスト・スイッチングを阻止出来る。
但し、これはデバイス・ドライバのCPU時間まで横取りしてしまう
ため、万が一暴走するとリセットするしかなくなる。

そこに気をつければ大丈夫。

このロード命令が16個あるループは、L1ヒットならPenMでもPen4でも16clk/loopで回る。
lp:
;prefetcht0 [esi+64]
mov eax,[esi] ; アクセス順変えでは、ここをmov eax,[esi+64] に変更。
mov eax,[esi+4]
・・・
mov eax,[esi+60]
add esi,64
dec ecx
jnz lp

L1ミスL2ヒットの場合だが、PenMでは25clk/loop。
プリフェッチを使うと20clk/loop、アクセス順変えで19clk/loopまで速くできる。

Pen4では、23clk/loop。
L2からL1へのプリフェッチは仕様上使えない。アクセス順変えで17clk/loopになる。

帯域の差でPen4が勝っている。てか、ロードに依存する命令がないからPen4でも速いのか。

そこで、movをaddに変更。これで、ロードに次の加算命令が依存するようになる。
lp:
;mov ebx,[esi+64] ; movによるL1へのプリフェッチ。prefetcht0 [esi+64] の代替として働く。
add eax,[esi] ; アクセス順変えでは、ここをadd eax,[esi+64] に変更。
add eax,[esi+4]
・・・
add eax,[esi+60]
add esi,64
dec ecx
jnz lp

PenMでの結果は変化なし。
Pen4のL1ミスL2ヒットで、23clk/loop。これは変わってない。
アクセス順変えで22clk/loop。movをaddにすることで3clk遅くなっている。
movによるプリフェッチ（プリフェッチ結果に依存する命令がない点でアクセス順変えと異なる）を
使うと、18clk/loopになる。17load/loopなので満足できる速さだ。リプレイはしてないだろう。

プリフェッチなどを使わない通常のコードでは、ループ先頭でL1ミスするが、
そのときにOoOして代わりに実行できるロードは次のループ（64byte先）までやってこない。
なのでOoOが効果的にできなくてL2帯域が引き出せない。
これを解決するのがprefetcht0などのプリフェッチ命令。アクセス順変えも、この効果がある。

普通、アクセス順変えではループ先頭でL1ミスしても、L2からL1へ転送してる間に
前回のループ先頭でプリフェッチしてあるデータへのL1ヒットのロード命令を実行できるので
L2レイテンシをゴッソリ隠蔽することができる。
ところがPen4の場合はL1ミスに気づくのが依存するadd命令を発行した後だったりするので、
投機実行を破棄してやり直しの手間がかかる。何と言うか、アクセス順を変えた意味がない。
L1ミスしてL2からL1へ転送している間に、依存していない命令をやってれば害はないのだが、
依存している命令をL1ヒットしたつもりで発行してしまうと、リプレイで遅くなる。

プリフェッチなしで23clkが変わらないのは、ロードに依存するadd eax,[esi+4] が、
[esi+4]もL1に乗ってないので投機実行できず、リプレイも起きないからだろう。

HTオンでSuperPI100万桁の2個起動やったら73秒と73秒だった。
１個起動だと53秒なので、L1L2共有にも関わらず1.45倍のユニット稼働率だ。

>>899のコードは23clk/loop。psでもpdでも同じ。

＃ここまでのPen4は、Noothwood-3.06GHz、PC1066 512MB。



>>948
>>858,>>865-869を参照。
ラインサイズをダイレクトに返してもらうのはPenMでも無理なので、eaxに2を入れてcpuidを使う。
そうすると、eax.ebx,ecx,edxの各バイト16個に情報が返り、
例えばその中に2ch（にちゃんねるじゃないよ）があったらL1のラインサイズは64byte、とか。
詳しくはIntelの命令セットリファレンスのCPUIDのところを見てくれ。

実測方法を考えるのも面白いよ。
(2^n)byte毎にメモリアクセスして、nと所要クロックの関係から推測するとか。

>>949
どういうコードでどうなったか詳細キボンヌ。

>>957
リザベーション・ステーションの件ですか？
CPUはAthlon64で、VS2003でコンパイルしたマージソートのプロジェクトを
食わせたら、所々で起きてました。

mov ecx, xxxxxxxxっていうメモリから即値を読み込む所で決まって起きて
いました。リザベーション・ステーションは、今からユニットにデコードしたmicro-OPS
(AMDではMacroOPS?)を溜めておく所ですが、あまりにも単調な命令ばかり
続くと、リタイヤメントの所で引っ掛かってしまい、溢れるようです。リタイヤメント
は実行ユニットと違い、インオーダーですからね。いろんな依存が絡んでくるん
でしょう。

x86の32bitモードでもワーキングレジスタ数は少ないですから、リネーミング
をしても溢れてしまうんでしょうね。

x86-64になれば、レジスタ数がぐっと増えるので、リタイヤメントに伴うストール
は減るのではないかと期待しています。その代わり、コンテクストスイッチング
が重くなりますけど。

>>958
ありがとうです。
単純な命令が一気に流れ込むと3MacroOPS/clkのリタイヤ限界を超えるのかな。
>>959はよくわからないけど、リネームするとリタイヤが重くなったりするの？

俺もAthlon機が1台欲しいな。。


>>950
xmm0やxmm1が計算済みなら前者が速そうだけど、実際はどうだろうね。
理論では簡単に判定できないタイプだと思うので、実測がおすすめ。

>>953
ループ回数を適度に減らし、1ms以下で完了するようにすればOKかと。
俺は1万clk程度で終わる測定ならPCで音楽を聴きながら測定したりもするが、全然平気。

>>957 THX。
2ch(にちゃんねるじゃないよ)ってなんのことかと思いましたが、
Intel の命令リファレンスみて理解しました。 0x2c が

「L1キャッシュ 32K バイト、
　8 ウェイ・セット・アソシアティブ、
　64バイト・ライン・サイズ」

ってのを意味していたんですね。これで prefetchx命令の
配置を切り替えることができそうです。

といっても、ラインサイズが64バイトのプロセッサで
32バイトの処理ごとに(過剰に)プリフェッチした時の計測値と
64バイトの処理ごとにプリフェッチした時の計測値で
ほとんど差が出なかったので、切り替える意味があるのかどうか・・・

>>960
リネームしても、RAWハザード依存は消せないので、コンパイラの癖に
よってはストールを引き起こす場合がある、という事かもしれません。
実際、他のプロジェクトもいくつかCodeAnalystに食わせてみましたが、
長いストールはミスブランチとDATA TLB Missを除いてあまりありませ
んでした。たまたまそのマージソートのプロジェクトだけが癖を持っていた
ようです。

そうですね、Athlon64は、AMDサイトから落とせるCodeAnalyst
(無料、登録必要)が動かせるので、 一台あったら面白いと思いますよ。

>>962
いや、レジスタが少ないことによってストールしてるなら
リタイヤはネックにならないと思ったので。

リタイヤをボトルネックにするには、かなりの最適化が必要だよ。
ネックがリタイヤじゃないとすれば、ハザードで実行ユニットが遊んでしまい、
デコーダから流れてきた命令が溜まっているという状況ですね。


そういえば、Pen4-3.06で測定していて思ったが、
コンパイル速度がDothan-1.1よりずっと遅いのだ。
正確には測ってないけど、倍は違う。
他の要因があったのかな？

>>963
うーんそうかもしれません。コンパイラはVS2003のC++で、最適化をONに
した時とOFFにした時では、だいぶパイプラインの様子が違います。レジスタ
変数を使わなくなると、メモリのReadWrite命令が増えますね。

実際に実行時間を測定すると(QueryPerformanceCounter()等で)、
最適化ON/OFFで大きく変わるものと、あまり変わらないものがあります。
L1/L2キャッシュも関係してくるので、単純な事は言えないのでしょうが・・・・

Pentium4はトレースキャッシュの容量が割と小さく、しかもmicro-OPSの
サイズが大きいので、ただでさえ小さいL1キャッシュをさらに小さくしていると
聞きました。実際、セカンドマシンはPentium4 3.2GHzですが、Athlon64
に比べるとDivXのエンコードは結構健闘していますが、それ以外のすべて
のシチュエーションで遅いです。体感速度も”もっさり”しているのを感じます。

Athlon64は、L1コードキャッシュ・データキャッシュ共に64KBと、Athlon時代
からの伝統(?)で大きいせいか(Latencyは3ですけど)かなりキビキビ感じます。

Yonahのベンチ
http://www.hkepc.com/hwdb/yonah-dualcore-5.htm

なぜかπが異常に早い。

元々PenMは得意だったのと
バスクロック向上やFPUとかのチューニングはいっていると
明言されてるんだし当たり前では

PenMって消費電力で圧倒、性能もバランスがよく
欠点はエンコ系だったのがそれがYonahで改善されて
現在最も全方位なバランスのいい石になったと思う

マルチスレッドの最適化の場合アセンブリレベルでのチューニングより
動並列化させるかの設計のほうが重要だから
割と面白い

>>954
>SetPriorityClass(handle, REALTIME_PRIORITY_CLASS);
>を使うと、ほとんどコンテキスト・スイッチングを阻止出来る。

これ、同様のことをLinuxでするには
プライオリティを一時的に挙げればよい、ということでしょうか？

Yonah発表でマイクロアーキテクチャ公開されないかな？

>>967
LinuxカーネルのスケジューラではCPU占有できなかったはず。
というわけでカーネルモジュール使えｗｗ

>>969 が〜ん、カーネルスペースにまで手を出す
勇気と技量がないんで、やめときます(笑

RTカーネル使えばできなくもないが
俺の覚えてる限り、RTにロクな実装がない。

root で動かす限り、カーネルモードモジュールは難しくないべ。

>>969
Linuxは、ソフトウェアアフィニティだからな。

>>969
FreeBSDならrtprio(2)、Linuxだとsched_setscheduler(2)で
リアルタイム優先度に変更してやれば似たようなことできるっぽい。

さあて、そろそろスレのまとめ（>>171みたいなの）を作るか。
ログを保存してあるのはいいけど、自分でもどこに何書いたかわかんないし。

次スレは「x86命令の所要クロック計測スレPart2」でいいかな。
ってもうすぐ980か。次スレの１に何を書くかとか議論したかったのにできん（ニガワラ

>>974 Wiki は無いんですか？

>>975
ないと思うけど。
ていうかこの分じゃスレのまとめも貼れないまま埋まってしまうな。困った。
まとめ制作は長くて大変だし、いっそ今新スレを立ててしまおうか。
新スレで進行してれば旧スレが止まるからゆっくりまとめ貼れるし。

所要クロックでんでん(なぜか変換できない)は
実情に即さないスレタイなので
もっとパイプラインとかスーパースカラ臭がする名前とか

もっと厨臭いスレタイきぼん

アウトオブオーダーとかでもつければ良いんでね？

でも最終的には>>1が所要クロックを測定して確かめてるじゃん。

スレのまとめ。専用ブラウザ使えばポップアップできます。

>15-18 MMXとSSEのQ&A
>22で組み込み関数の話は出てるよ。>137-148は気づいていたのかな。
>23 キャッシュの仕組み
>27-31 PentiumMのSSE2のクロック数
>34 μopフュージョンについて
>35 K7/K8のデコーダ
>40 P4/PMのSSE/MMX比較
>41 P6のL2はエライ
>43-44 CPUの内部構造
>47 P4とK7のキャッシュレイテンシ/LoadBench（リンク）
>52 パイプラインの比喩（リンク）。>58はコンビニ。
>61-62 K8の128bit pandとandpdは違う？/K8のLoadは64bit*2/clk
>65,67,69,75,77,85 SIMDとALUのQ&A。
>68 吉野家コピペ
>73 mulpsを入れると速くなる謎。
>78-81 ロード・ストアする派とレジスタで何とかする派
>81-117 分岐。実験結果は>81,86,111,113
>84 初心者のためのアセンブラリンク
>87-97 乱数について盛り上がった
>99-110 内部構造を予測しつつ測定法を吟味
>114 RISCの分岐処理など
>116-117 予測ミスのペナルティがパイプラインの段数より少ない理由を予想
>118 ライフゲームを作った感想
>123 Prescottの触り心地
>128-131 MMXの並列動作。よく考えたらMMX2はユニット限られてた。
>132,500 キャッシュラインをまたぐペナルティ
>133-135,153,167 プリフェッチについて
>149,154 lddquはps[lr]ldqで実装されてる。
>152 Pentium4の触り心地
>154-165 デュアルコアの話

メモリアクセスの季節。

>167,170 プリフェッチの実験＠PenM
>172 3つのDoublePath命令のデコードは2clk
>182-186 Pentium4とCeleronとコンパイラの質問
>187-192,>196-199 自己書き換えアセンブラ、C、Java、色々な最適化
>200 Visual C++ Toolkit 2003はタダで使える
>216-221,>228-229 for (i=0; i<1000; i++) q+=p[i];のコンパイル結果検証
>222 キャッシュのWay数の実験
>234-250 68kとかの昔話
>233,240 トリップ検索
>261-280 C#のトリップベンチ
>292-293,>500 ランダムリードの実験（ロード命令同士の依存性なし）
>301 Banias-1.5GHｚのloadbench
>308 新しいオモチャって何だったんだろう・・・
>314-317 複雑なソフト、進む仮想化、語り
>332 BIOSでL2キャッシュを無効にしてみた
>342-348,>362,>368-383 CPUとGPUの違い
>364-366 メモリレイテンシの測定（依存チェーンあり）
>397,398,649 divの実験
>400 Cの整数除算はコンパイラが乗算に最適化してしまうこともある
>409-413 SpeedStepを試す
>414 宇宙ヤバイのコピペ
>415-424 x86に、CellのSPEみたいなのはどうか
>425-434 ビッグエンディアンの利点/カコイイ
>435 QueryPerformanceCounterとrdtscでSpeedStepの実験
>446-458 pcwebのメモリベンチ
>457-473 中間言語、Java、GC
>476,478,481,491 １がメモリベンチを作ってみました
>493-497,499,501 メモリアクセスの並列実行って何よ？
>503 閉塞感が漂ってくる。いわゆるネタ切れ。

雑談、パーシャル、トレース。

>513 x86CPUのレイテンシとスループットの表（リンク）
>515-517 １がメモリベンチを改変
>518-529 pcwatchのベンチ記事に難癖をつける/ベンチとは何か
>530-544 Yonahの情報。結局単純に帯域倍というだけだったかな
>545-546,549-550,564,582-583 依存関係を避けたい派とメモリアクセスは極力減らす派
>547,553,556,562,565,575 PentiumMはこんなところが速い！
>566-572 どんなアプリに対して最適化すべきか
>584 movdquは分解した方が速い
>592 YonahのCPUコアの拡張
>593-610 その後ちょい雑談
>613 μopsフュージョン
>614-629 SpeedStep/EISTについての妄想たち
>636-638 YonahのL2帯域が糞速いけど実際どーよ？
>639-647,>653-654 Pen4のSIMDユニットは何bitで周波数はコアクロックの何倍か
>650-651 addpdのレイテンシがどう工夫しても3にしか見えない（公称レイテンシは4）
>655-665 やめたいスタック式FPUとやめられない互換性80bit/実行ユニットと演算器
>666-677 パーシャルストール
>675,680,690,693 movzxに関する致命的な勘違い
>678-679 パーシャルフラグストールの実験
>694-696 ワロタ
>699,702,706,711 パーシャルアクセスに際しての追加μopは何者
>700,701 SIMDでハンドコーディングの時代です
>703-709 分岐ヒントのプリフィックス
>713,714,730 トレースキャッシュの功罪/Meromはトレースじゃないっぽ
>716-729 トレースキャッシュってuops用の命令キャッシュと何が違うの？
>733-747 IA-64とNetBurst/64bitの互換性

Yonah、Merom、色々なアーキ。

>749,750,756 クロックゲーティングを見ようとしたが見えず
>751-763,965-966 YonahのSuperPIがやたら速い件/Athlonの排他キャッシュの是非
>764,>796-800,807,>886-889,891 １がメモリベンチを改変。K6-2/K6-2+/Pen3
>765 PenM用チップセットたち
>766-780,786-791 AthlonX2も交えてSuperPI関連
>781-784,792 クロック数の表。有名どころへのリンクもあり
>792-795 昔の石は最適化のしがいは最高でしたよ
>800-804 あの時代のK5
>812 SSE命令がフュージョンするとどうなるか
>813 キャッシュラインの捨て方、擬似LRU(least recently used)置換アルゴリズム
>830-836 ページカラーリングについて
>837-843 アラインメント違反は例外が発生するんですか？
>844-851,877,880 L1/L2をできるだけクリアしたいのですが
>852,>855-859 Pen4のパーシャルレジスタ
>853,858,860,861,863 prefetch*命令でプリフェッチされるのは何バイト単位？
>865-869,957 キャッシュラインのサイズってどうやって調べればいい？
>870-875,879 パワレポのYonahベンチ
>876,881-885 Yonahのベンチお届けです
>890,>892-897 Pen4で、ストア命令は2つのμOPに分解されるとは限らない
>898-900,957 マンデルブロ集合
>901-925,928 MeromのSpeculative Load/Pen4の投機ロード/IA-64のld.sとの違い
>932-938 ダウンカウンタのループ
>942,944 同じ命令数なら、ブランチフリーにした方が実行速度はアップする？
>939-943,947,955-956 前に貼られてたxbitの記事/Pen4のreplayの実験
>945 キャッシュの動作
>949,958-960,962-964 リザベーション・ステーションの件
>953-954,960,967,969-973 コンテキストスイッチングが入って計測できない

新スレです。
http://pc8.2ch.net/test/read.cgi/tech/1136527588/


>>977
内容からすると「実測で知るx86CPUのマイクロアーキテクチャ」て感じかな。
俺も色々考えたんだけど、スレタイとしてよさげなのが思いつかないんだよねえ。

OoO 2issue

>>980
乙

われながら、よく連投規制にかからなかったものだ。


このスレでの積み残し。

キャッシュラインをまたいだときの挙動
movとprefetcht0の違い
VBでnasm使って状況依存のコード生成
PenMでL2の寝ているブロックを起こす遅延
P4のL2を切る（BIOSで切れない）

次スレではYonahの結果がたのしみ

うめ

(･∀･)

そういやMSRに関する詳細な公式の資料ってあったっけ？
Appendix.H?

うめ

しっかりうめんかい

うめ

u m e

u m e

u m e

u m e

u m e

u m e

このスレッドはHLTしました。
新しいスレッドをたててくさい。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。