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

ゆるゆる〜っと実測していきましょう。

過去ログ
x86命令の所要クロック計測スレPart4
http://hibari.2ch.net/test/read.cgi/tech/1212157132/
x86命令の所要クロック計測スレPart3
http://pc11.2ch.net/test/read.cgi/tech/1168399966/
x86命令の所要クロック計測スレPart2
http://pc10.2ch.net/test/read.cgi/tech/1136527588/l50
x86命令の所要クロック計測スレ
http://pc8.2ch.net/test/read.cgi/tech/1103609337/l50

関連スレ
アセンブラ…　(゜□゜) ↑アッー！↓
http://pc10.2ch.net/test/read.cgi/tech/1148402614/l50
MMX SSE 3D NOW!のプログラミング
http://pc10.2ch.net/test/read.cgi/tech/1085749218/l50
CPUアーキテクチャについて語れ 5
http://pc9.2ch.net/test/read.cgi/jisaku/1159238563/l50
【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】
http://pc9.2ch.net/test/read.cgi/notepc/1160039483/l50
もしくは、自作板にて「次世代」でスレタイ検索

まとめサイト（過去ログ置き場）
http://www.wikihouse.com/x86clocker/index.php?FrontPage

関連サイト（日本語）
コピペで動くVC++のインラインアセンブラ例
http://www.fides.dti.ne.jp/~tokai/vc/mmxab2.html
基本的な整数命令/スタックの使い方
http://ray.sakura.ne.jp/asm/
FPUやMMX,SSEの命令解説など。最適化の色々な話がある
http://homepage1.nifty.com/herumi/adv.html
pentopt（古）の日本語訳など
http://hp.vector.co.jp/authors/VA003988/
Intelの日本語技術資料のダウンロード
http://www.intel.com/jp/developer/download/index.htm

関連サイト（英語）
Intelの最適化マニュアル（Core2についても載ってる）
http://developer.intel.com/products/processor/manuals/index.htm
Software Optimization Guide for AMD64 Processors
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7203,00.html
Intel向け最適化手法やクロックテーブル、testp.zipで手軽にrdpmcが使える
http://www.agner.org/optimize/
各CPUのレイテンシ-スループットの表（K7K8あり）
http://swox.com/doc/x86-timing.pdf
x86CPUの各種データシート
http://www.sandpile.org/
AMD CodeAnalyst Performance Analyzer、AMD用パイプラインの様子がわかるシミュレータ
http://developer.amd.com/downloads.jsp

CPU関係の記事が読めるかもしれない場所
http://pc.watch.impress.co.jp/
http://www.geocities.jp/andosprocinfo/
http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html

>>1
乙

前スレ>>4から拾ってきた
>テンプレに入れて欲しい
>http://instlatx64.fw.hu/

Bulldozerのマニュアル読んでて面白かったので久々にチラ裏日記を更新した。
そろそろあのサイトの移転先考えないと。

JohnのMLにコミットしておくか

>>5
＞おそらく6コアあるPhenom IIのほうがマシである。
暇ができたらちょっと検証してみてよ。

Intel vs AMDってPen4 vs AthlonXPの時を除いてそれより前からもそれより後も
Intelはピーク性能、AMDは安くてそこそこの性能って感じじゃね？

AMDはベンチマークには現れにくいが足回りが良くてワーストケースに強かったイメージがある。
サーバー向き。

もっとも、最近はその足回りもIntelに抜かれた感がある。
抜かれようが抜かれまいが、AMDの性格上DESやらエンコやらパイ焼きみたいな数値演算メインの処理で比較したらIntelに有利だと思う。

>>7
NetBurst vs K7
においても、
> Intelはピーク性能、AMDは安くてそこそこの性能
だったと思うが

K7って爆熱&お馬鹿プリフェッチ&高レイテンシFSBで、
足回りが悪かったよ。

キャッシュがヒットしない領域に入った途端に、
Pentium3にも突き放される低速っぷり。

>>8
> Pen4 vs AthlonXPの時を除いて
って書いてるのに。
バカなの？

>>9
日本語わからないの?

>>10
レス番間違えてるよ。

>>11
いやいや合ってますってば。

だめだこりゃ

>>13
おまえがな

相手が間違っているという前提で読むから誤読するんじゃね?
落ち付いて>>7と>>8を読んでみ?

お互いに誤読して勝手に盛り上がっているに一票。

だめだこりゃ

>>7
>イメージがある
>有利だと思う
ここは計測スレだデータを示せ

だめだこりゃ

間違いを認められずに煽りあいとか恥ずかしくないのか？
少しは紳士的な団子さんを見習えよ。

athlonXPはK7世代だよな
そもそもK7,K8はDECのalphaの系譜なのだから
安くてそこそこの性能なんて言われちゃおしまいだろ

でも実際、安くてそこそこでオタクに受けてたじゃん

>>20
そりゃそうだが、アーキテクチャをx86にした時点で別の視点で見られてしまうからな
「いかに速いx86か」でしかなくなってしまう

なつかしいなintel vs AMDのFSB論争

2chなんかでは、マルチプロセッサ構成で使ってもいない連中がPoint-to-Point接続の優位性を語ってて、おかしかった

ちなみに、机上シミュレーションだとSHA-1/SHA-256のSIMD並列化コードでは
Bulldozerは同モジュールあたりでSandy Bridgeよりも良い数字が出てる。
もちろんXOPを使った場合ね。AVXだと同等以下に落ちる。

整数演算メインの処理で、SIMDクラスタのPort0は乗算が使えないところでは
使い道ないとは最初思ったんだけど、vpmacc* の第2引数に1とか-1を指定してみ？
レイテンシは大きいものの加減算に使えるんだよね。

整数は従来SSEやAVXの範疇ではIntelには負けるがXOPさえ使えば同等かそれ以上（ものによる）
の性能を引き出せる余地はある。
（更に欲をいうならPort 0にPort2,3と同じSIMD ALUをおいてくれさえすればSSE/AVXでも良い数字出るはず）

一方FPは完全にSandy Bridgeのほうが飴が美味しいですわ。
AMDは従来128ビットSIMDコアの実効1.4倍くらいの性能を目指してきたと思う。
FMACの片方とシャッフルユニットが同じポートだったり、そもそも制約が多い。
128ビットSIMDのまま性能を伸ばそうとしたからどうしても伸び白が小さくなってしまう。
Sandy Bridgeは256ビット化することで実効1.8倍（Intel曰く）を目指してきた。
FADD/FMULだけでなくシャッフルユニットも含めてフル256ビット化してきたことで
性能が出やすくなってる印象。

まあいいんじゃね

AMDは価格相当の性能を出しているのだと思えば、Intel並みの性能が欲しければ
ハイエンドのCPUを買ってもIntelより安いのだし、「安かろう悪かろう」という市場原理
そのままのような希ガス。

逆にAMDが安価でIntelを突拍子も無く抜くような物を作るとAMDが独禁法の敵に
されるような気がする。

IntelはCoreアーキテクチャ以降もっさりのくびきから逃れる事が出来たし、AMDは頑なに
K5以降の路線を守り続けているが、目指す方向がほとんど同じに最近は思えてきた。

k5以降の路線ってなんだよ
買収で開発を取り込んでるだけのAMDに

しかしAMDの存在がありがたいだろ
もしAMDがなかったらもっとCPUの値段が馬鹿高いぞ

そして64ビットはIA-64だっただろう・・・

>>24
そのコードを全コアで一斉に走らせた場合、
Bulldozerは実行ユニットを2コアで共有している分、
Sandy Bridgeよりも遅くならないか?

かつてリソースを占有できるという前提で書かれたコードが、
Pentium4のHyperThreadingで悲惨なことになったように、
あまりタイトすぎると・・・。

Pentium4でHTを使うとトータルスループットが落ちる原因ってL1キャッシュミスでそ。
8KBとか16KBの小さいキャッシュを更に共有するとか、おかしいこと山の如し。

BulldozerはL1独立なのでL1容量がネックになるコードは性能が落ちるというより
最初から遅いと思う。1スレッドだけ走らせたからってL1Dが32KBとしてして使えるわけじゃ無しに
最初から16KB固定割り当てだしね。

ただし、2コア同時にキャッシュミス or prefetchしたらL2の帯域大丈夫かしら？ってのはある。
HPC版と銘打ったNehalem-EXの6コア・2.66GHz版は最初からHTは無効にしてある。
一方BulldozerのSIMD命令はレイテンシが大きすぎるので2スレッド使わないと埋まらない気がする。

なるほど

そだなあAMDは伝統的にL1が大きいからね
レイテンシも大きい事が多いけど
K8でメモリの足回りが良くなってから本当に速くなった

K7のメモリが遅すぎた。いくらなんでもレイテンシ200nsは遅すぎだった。
そりゃIntelが、帯域幅を犠牲にしてでも共有FSBで100nsのほうが速いよ、って言うわけだ。

nForce4というなんちゃってデュアルチャンネルノースブリッジチップだったら
100ns程度だったんだけどな

まあK7をフォトレタッチソフトのような大部分がメモリとのやり取りにCPU
タイムを費やすような用途に使う事はもうないでしょう

Phenom][やAthlonX2が出てるんですから

悪いnForce2だった
古い物で記憶もあやふやになっとる
IntelもCode i7でトリプルチャンネルなんてやっちゃってるし
余程メモリが速度の足を引っ張るのが怖いんだろうな

LGA1366は最大6コアをサポートするプラットフォームだからチャネル数増やすのは当たり前では？
もともとサーバ向けだし。ハイエンドデスクトップ向けでマスク共用して実質的なコストダウンしてるだけの話で
デスクトップ向けに3ch必要なわけではない。

実際4コアだと2chも3chも大して実効性能変わらんでしょ。
2chで6コアの製品はAMDしかないから知らんが。

>>33
それはシングルCPUの話だよね。

デュアルCPUだと、
CPU(0)→ノースブリッジ→CPU(1)→ノースブリッジ→メモリ→ノースブリッジ→CPU(0)
ってな感じで、200nsもかかったらしい。

>>34
いや実際、メモリがボトルネックになるでしょ。

複数のコアのメモリアクセスがキューに並べば、レイテンシが悪化する。
だから、複数のメモリコントローラにアクセスが分散させてレイテンシの悪化を軽減しようとしてる。

K7時代のデュアルチャネルは、アドレスは1系統でデータが2倍というタイプ、
つまり、2つのDIMMを束ねて128bit幅のDIMMとして使うような方式だったが、
今のデュアルチャネル・トリプルチャネルは、アドレスが2系統・3系統あるのよね。

>>36
あ、デュアルCPUの話でしたか
当時はマルチコアなんか無かったからすっかりわすれていました
SMPをすっかり忘れていました
そういえばAthlonXPをMP相当に改造してSMPで動くようにするとか
実験工作が流行ったような記憶が・・・

K7のデータバスは1本しかありませんから、nForce2のなんちゃって
デュアルチャンネルはノースブリッジに2本のメモリバスがあり、それを
ノースブリッジ内で合成して1本にして出力する物で、メモリインター
リープの考え方の延長上にありました

だから性能的には大して上がらず、単に売れ線を意識しただけの
ような格好だったと思います

いまのデュアルチャンネルはメモリを実質的に128bitや196bitとみなせ
ますから、実数演算やSIMD命令で相当性能が上がっていますね

nForceのデュアルチャネルは、CPUのためというよりは、メインメモリ共有の内蔵GPUのためだったね。

K7はデュアルだとFSB266まで、しかもレイテンシ大で、CPUが1GHzの頃はよかったが、
2GHzにもなると、ボトルネックになった。まぁその頃はOpteronへの移行が始まってたが。

EV6は、せっかくPoint-to-Point接続で、共有FSBのクロックが上げられない制限がないのに、
FSB333や400に対応したチップセットが投入されないという、もったいないことになってたね。

>>35
Windows VistaのDWM1.0ではGDIが全てCPU上で処理されてからDirectXでGPUに転送、だったせいで
メインメモリ帯域がPCの使用感に与える影響は半端じゃなかった。メモリが遅いともたもたスクロールになる。
DWM1.1になってそこまでの影響はなくなったな。

>>39
2Dアクセラレーションを切った今時のGPUでエディタでマクロを使った時の
もたつき感はそのせいか

でもBitBltだけは残してあるんだよね？

そんなに食うわけ無いだろ
だったらIGPなんてどうなんだって話だわ

WindowsのGDI処理の速度は、ビデオメモリの帯域幅に大きく依存してる。
同じビデオチップを同じクロックで動かしても、ビデオメモリが違うと、かなり違う。

GeForce4MXクラスでも、
SDR 166MTs 64bit幅
DDR 400MTs 128bit幅
では、雲泥の差だった。

だから、もともと帯域食い合ってるIGPだったら
違いがでない理屈だろ上のは

それとWDDMだよな書きたいのは

> そんなに食うわけない

食うだろう

> IGPなんてどうなんだ

IGPだと、メインメモリをビデオメモリとして使うので、
GDIがソフトウェア処理でもハードウェア処理でも、
同じじゃないか? ということなら、Yesだ。

IGPはパフォーマンスが悪かった。

IGPだと本当に悲惨なことになる

まずCPUがGDIエミュレーションルーチンを走らせてメインメモリ上のサーフェースにお絵描きする
それをテクスチャに変換してVRAM (IGPだとこれもメインメモリ) にメモリtoメモリのコピーをする
そしてIGPはD3Dでテクスチャを読んでフレームバッファ (IGPだとこれもry) にレンダリングする
そしてビデオ出力部がフレームバッファを読んで出力する

つまり、メインメモリ上で「書いて読んで書いて読んで書いて読む」ことになる
ちなみにXP以前のドライバモデルなら、「書いて読む」だけだ

あ、フレームバッファは外付けのもあるな
そんなわけで少なければ2倍、多ければ3倍になるわけだ

VistaでG45のほうが790GXより快適なのは何で？

>>45に加えて、
XPでも、GDI処理がGPUで非同期実行されるからCPU時間で見ればあまり差がないように見えていただけで、IGPは遅かった。
bitbltのすぐ後にさらにGDIのapiを呼び出せば、その相応の時間待たされることで隠蔽されていた処理時間が見えるようになる。

>>47
Radeonは描画がトロいよ。

現行Radeonは2D機能はエミュレーションだからな。ドライバタイム無駄に長いし。

CPUによるエミュレーションの最大の問題点は、
・メモリのフィルが無駄に遅い(リードモディファイライトするから???)
・エミュレーションするときにCPUのキャッシュの内容が一掃される
だと思うわ。

2Dアクセラレーション復活しろカスと言いたいよな
大してダイ面積食ってるわけでもなかろうに

ウィンドウの重なり処理を3Dでやれば、都度の再描画がなくなるし、今のCPUは速いので、アクセラレーション必要ない
っていうのがマイクロソフトの判断だったのだろう。

でも実際には再描画が遅いのではなく、初回描画が遅かったのだ。

更なるベクターグラフィックのアクセラレーションとかに期待してみたい
今後OSレベルで多用する事になるだろうし

54のベクタグラフィックは置いといて、現状の2Dはメモリの転送だけだろ。
アルファブレンドとかメモリの転送速度に比べたら誤差みたいな計算量だし。
アクセラレートのしようがないと思う。

Vistaが遅いのは本当に描画アーキテクチャが原因なのか？
スーパーフェッチとかそういうところじゃね？

>>55
D3Dの描画はともかくGDIは遅いよ。
Core(TM)2 Duo CPU E8500 @ 3.16GHz(3.16GHz x 2)Radeon X1950 Pro／OS XPSP3
1920x1080 32bpp 120Hz／1.26Gpixel(s)/sec／184.67FPS
Core(TM) i7-2600K CPU @ 3.40GHz (3.41GHz x 8)HD Graphics Family／OS XPSP3
1920x1080 32bpp 60Hz／453.73Mpixel(s)/sec／64.21FPS

Win7でも2600で456.42Mpixel(s)/sec／77.04FPS程度

D3D描画だとGTX460やHD5800辺りなら問題ないけどね。

何の数値？

エロゲベンtなのは確定的に明らか

>>53
まあそういうこったね
あと、遅いっていうのはスループットだけじゃなくてレイテンシでも遅い
つまり>>45の各段にはバッファが入っていてパイプライン的に処理されていくので
アプリがクライアント領域に描画してからデバイスに出力されるまでは3フレームタイミング遅れる
この分だけでも、「再描画がD3Dだけでできる」というメリットは帳消しだと思うね

MacOSの真似やりたかったんだねゲイツは。
CocoaのGUI部品ってWindowsのそれと比べてオーナードロー／カスタムドローの
自由度低いから嫌いなんだが、描画方法が変わっちゃうと良し悪しなんだよなぁ

>>59
フレームの遅延、1フレーム単位でも、人間に知覚できるんだよね。

キーボードからテキストを入力するときの応答が速いときと遅いときがあって、
最初はCPU負荷かと思ったら、そうでもなくて、突き詰めていったら液晶モニタだった。

入力信号と画面から出る光をフォトトランジスタで受けた信号のタイミングを調べたら、
モニタの電源を入れるタイミング等々によって、
入力信号からパネル表示までの遅延時間に、約1フレーム分のバラツキがあった。
おそらくFRC(フレーム・レート・コンバータ)によって入力信号とパネル表示が非同期で行われてるかだろう。

第一世代「AMD Fusion」プロセッサを試す - Zacate搭載Mini-ITXで徹底検証
http://journal.mycom.co.jp/special/2011/zacate/menu.html

大原節

32bit
32bit + PAE
64bit

下にいくほどページテーブルが肥大化していくよね。
メモリアクセスのオーバーヘッドは、どれくらい違うの?

もひとつ

なぜx86はSMTやってるのに、強力なフェッチ・デコードなの?
フェッチ・デコードは1クロックで処理する命令数が増えると指数関数的にデカく、電気食いになるよね。

1つのフェッチ・デコードで2スレッドを交互に処理するのではなく、
2つのフェッチ・デコードで各スレッド専用で処理したほうが、
シングルスレッドのパフォーマンスは低下するけれども、
消費電力が下げられるのでは?

スレッド毎にフロントエンド分けるなら2コアにしたほうがマシだな

>>60
AppleはiPadは失敗したけどAndroidは大成功だしなあ
Open OSだからすぐに中華でパクりそうだけど

>>66
マテマテ
AndroidはAppleではなく絡んでるのはGoogleだぞ
今の所はiPhoneのシェアが高すぎてAndroidはどうなるか未知数だが
ニコニコ生放送を見ていても最近Androidの端末を使用している人が
増えていると感じる

>>64
シングルスレッドの性能が限界に達しているので、メインストリームのプロセッサで性能を落とすわけにはいかないんでしょう。
並列化出来ない仕事だってあるからね。

Pentium4のときに
Pentium3よりも遅くなる処理がある
って
散々叩かれたものね。

http://support.amd.com/us/Processor_TechDocs/47414.pdf

B.5 Amended Latency for Selected FMA Instructions
によれば(FMA/IMAC)と(XBAR/MAL/STO)間のデータ移動で1サイクルの
ペナルティがあるようだ

IntelのCPUでも異なるドメイン間のデータ移動でペナルティが発生するが
各ドメインに演算ユニットが配置してあるので適切な命令を選択すれば
ペナルティを回避できる

aeskeygenassistは全然assistっぽくない。

＞ Open OSだからすぐに中華でパクりそうだけど
ハアアアァアアアァアァァァァァアァァアァアアアァァァアァァアアァァアァアァァアァア？？？？？
うるさいゴミ

これ ； デリミタっていうんだけどさ、よく打ち忘れるよね
Rubyだとつけなくてよくなるんだけど


ゴミだよなぁほんと

ゴミすぎて最近はIDEが補完してくれるわけだが。

>>75

http://www.friweb.hu/instlatx64/
確かにLlanoの整数除算は速くなってるね
FP除算は速くなってないようだけど

Intelの場合、整数とFPの除算器を共用しいているせいか、両方速くなったりするもんだけど、AMDは別個なんだね

IntelのCPUの除算ユニットは、μOPs数考えるとFP乗算器としてデザインされてるものを
整数側が間借りしてるような感に見える。
整数DIVは商を求めてから非除数 - 商×除数で剰余を求めてるような。

逆数求めて掛けているとかどうでしょう？

Radix-16 SRTっていうハードウェア実装されたアルゴリズムを使っている。
4ビットずつ辞書引きをして引き算をするという操作を反復して商を求める。

整数にするだけだったら小数点以下は反復しないだけでおｋだしね
アルゴリズムにもっと良いものがあるかどうかは知らないが
intelがそうするのならそれなりの理由があるのだろう

しょっちゅう使うもんでもないけど使うときには性能が欲しい。
ってことになると整数と実数で別々に持つよりは共通の強力なユニットを1つだけ
持つほうが合理的だわな。

http://www.friweb.hu/instlatx64/

bullちゃんのレイテンシー＆スループット

Bullちゃんは複雑怪奇

http://www.friweb.hu/instlatx64/
のL:とかT:ってどういう意味？

Latency: 結果が出るまで
Throughput: 次の命令に移れるまで

Latency: とつき
Throughput: ひとつき

Throughputって単位時間当たりの命令実行可能数だけど
この業界だとThroughputの逆数のことを単にThroughputと言うことが多いよね
マニュアルとかにはReciprocal Throughputと書いてある

徒競走で10秒のタイムと言うべきところを10秒のスピードと言っても通じるようなもんじゃね?

日本人固有の造語というわけじゃなくてIntelがそう呼んでるからな。
もっとも、Intelは往々にして言語力が怪しい気がする。

10秒のタイムは十秒でしょ。

処理量あたりの時間でも時間当たりの処理量でも
スループットの指標には違いないだろ

というか逆数の方が消費サイクルの概算がしやすい

ダンゴさんマジかっこいい

Intelの最適化マニュアルがIvy Bridgeに対応
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf

2.1.7 IntelR Microarchitecture Code Name Ivy Bridge
にMicroarchitectureの変更点が書いてある

http://users.atw.hu/instlatx64/CentaurHauls00006FC_CNQ_Isaiah_InstLatX64.txt
> 824 SSE :MULPS xmm, xmm L: 1.86ns= 3.0c T: 0.62ns= 1.00c

http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=5507
> Efficient floating point unit (2 clock SP multiplies)

とは一体何だったのか？

古いサンプルなんじゃない

Ivyの計測結果が載ってたけど
浮動小数点の除算、平方根系の命令が速くなっている以外は
スカラのシフト、ローテートの高速化ぐらいか

ただ肝心のレジスタ間movが消えるってのは効果が見えないな...

効果はレジスタ間movを多用してるソフトでないと実感しにくいかもね。
pshufbとかpandnとか多用してるとdestを保存したい場合って結構出てくるんだけど。

いやそういう話じゃなくて
数値上はmovとかmovapsとかmovdqaが全部スループット0.25になるはずなのに
Sandyと変わってないので

Bulldozerのmovaps/movdqaはちゃんとスループット0.25とデコーダの数値が見えてるので
ツールがちゃんと測れていないということでもなさそうだし。

>>97
LU/STA×2、STD×1、ALU×３の6ポートだけど、レジスタ間movを処理できるのは3ポートだけで
スケジューラのほうは1サイクル4オペレーション以上処理できるようになってないとか？

命令個別のスループットサイクルより、どっちかというと実際のコードシーケンスにおける
実効レイテンシの削減に効果的な技術だと思ってるんだが。

ただ、かつてのFXCHほどにはインパクトないかもしれないね。

Intelのマニュアルにはスケジューラと実行ユニットを消費せずにフロントエンドで実行するって書いてあるんだけどねえ。
zeroing idiomsと同じくリネーミングの段階で終わるもんだと思うんだけど。
zeroing idiomsはちゃんとスループット0.25出てるし。

まあ
movdqa xmm1, xmm0
pand xmm2, xmm1
pand xmm3, xmm1
pand xmm4, xmm1
みたいなのが1サイクルで回るか調べてみればいいんだけど。Ivyがあれば

μOPsが内部的に3〜4レジスタオペランドに拡張されたってだけでも十分進化なんだけども
Ivy BridgeはAVX対応でのみ得られるメリットを従来SSEでも一部享受できるようにしたことに
意味があると思う。
もちろんμOPs Cacheによる16バイトフェッチ帯域上限の緩和とかLoadユニット2重化とか
Sandy Bridgeの時点で実装された高速化要因があるんだけども。