過去ログ
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
乙
>テンプレに入れて欲しい
>http://instlatx64.fw.hu/
そろそろあのサイトの移転先考えないと。
JohnのMLにコミットしておくか
＞おそらく6コアあるPhenom IIのほうがマシである。
暇ができたらちょっと検証してみてよ。
Intelはピーク性能、AMDは安くてそこそこの性能って感じじゃね？
AMDはベンチマークには現れにくいが足回りが良くてワーストケースに強かったイメージがある。
サーバー向き。
もっとも、最近はその足回りもIntelに抜かれた感がある。
抜かれようが抜かれまいが、AMDの性格上DESやらエンコやらパイ焼きみたいな数値演算メインの処理で比較したらIntelに有利だと思う。
NetBurst vs K7
においても、
> Intelはピーク性能、AMDは安くてそこそこの性能
だったと思うが
K7って爆熱&お馬鹿プリフェッチ&高レイテンシFSBで、
足回りが悪かったよ。
キャッシュがヒットしない領域に入った途端に、
Pentium3にも突き放される低速っぷり。
> Pen4 vs AthlonXPの時を除いて
って書いてるのに。
バカなの？
日本語わからないの?
レス番間違えてるよ。
いやいや合ってますってば。
おまえがな
相手が間違っているという前提で読むから誤読するんじゃね?
落ち付いて>>7と>>8を読んでみ?
>イメージがある
>有利だと思う
ここは計測スレだデータを示せ
少しは紳士的な団子さんを見習えよ。
そもそもK7,K8はDECのalphaの系譜なのだから
安くてそこそこの性能なんて言われちゃおしまいだろ
そりゃそうだが、アーキテクチャをx86にした時点で別の視点で見られてしまうからな
「いかに速いx86か」でしかなくなってしまう
2chなんかでは、マルチプロセッサ構成で使ってもいない連中がPoint-to-Point接続の優位性を語ってて、おかしかった
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以降の路線を守り続けているが、目指す方向がほとんど同じに最近は思えてきた。
買収で開発を取り込んでるだけのAMDに
もしAMDがなかったらもっとCPUの値段が馬鹿高いぞ
>>24
そのコードを全コアで一斉に走らせた場合、
Bulldozerは実行ユニットを2コアで共有している分、
Sandy Bridgeよりも遅くならないか?
かつてリソースを占有できるという前提で書かれたコードが、
Pentium4のHyperThreadingで悲惨なことになったように、
あまりタイトすぎると・・・。
8KBとか16KBの小さいキャッシュを更に共有するとか、おかしいこと山の如し。
BulldozerはL1独立なのでL1容量がネックになるコードは性能が落ちるというより
最初から遅いと思う。1スレッドだけ走らせたからってL1Dが32KBとしてして使えるわけじゃ無しに
最初から16KB固定割り当てだしね。
ただし、2コア同時にキャッシュミス or prefetchしたらL2の帯域大丈夫かしら？ってのはある。
HPC版と銘打ったNehalem-EXの6コア・2.66GHz版は最初からHTは無効にしてある。
一方BulldozerのSIMD命令はレイテンシが大きすぎるので2スレッド使わないと埋まらない気がする。
レイテンシも大きい事が多いけど
K8でメモリの足回りが良くなってから本当に速くなった
そりゃIntelが、帯域幅を犠牲にしてでも共有FSBで100nsのほうが速いよ、って言うわけだ。
100ns程度だったんだけどな
まあK7をフォトレタッチソフトのような大部分がメモリとのやり取りにCPU
タイムを費やすような用途に使う事はもうないでしょう
Phenom][やAthlonX2が出てるんですから
古い物で記憶もあやふやになっとる
IntelもCode i7でトリプルチャンネルなんてやっちゃってるし
余程メモリが速度の足を引っ張るのが怖いんだろうな
もともとサーバ向けだし。ハイエンドデスクトップ向けでマスク共用して実質的なコストダウンしてるだけの話で
デスクトップ向けに3ch必要なわけではない。
実際4コアだと2chも3chも大して実効性能変わらんでしょ。
2chで6コアの製品はAMDしかないから知らんが。
それはシングルCPUの話だよね。
デュアルCPUだと、
CPU(0)→ノースブリッジ→CPU(1)→ノースブリッジ→メモリ→ノースブリッジ→CPU(0)
ってな感じで、200nsもかかったらしい。
>>34
いや実際、メモリがボトルネックになるでしょ。
複数のコアのメモリアクセスがキューに並べば、レイテンシが悪化する。
だから、複数のメモリコントローラにアクセスが分散させてレイテンシの悪化を軽減しようとしてる。
K7時代のデュアルチャネルは、アドレスは1系統でデータが2倍というタイプ、
つまり、2つのDIMMを束ねて128bit幅のDIMMとして使うような方式だったが、
今のデュアルチャネル・トリプルチャネルは、アドレスが2系統・3系統あるのよね。
あ、デュアルCPUの話でしたか
当時はマルチコアなんか無かったからすっかりわすれていました
SMPをすっかり忘れていました
そういえばAthlonXPをMP相当に改造してSMPで動くようにするとか
実験工作が流行ったような記憶が・・・
K7のデータバスは1本しかありませんから、nForce2のなんちゃって
デュアルチャンネルはノースブリッジに2本のメモリバスがあり、それを
ノースブリッジ内で合成して1本にして出力する物で、メモリインター
リープの考え方の延長上にありました
だから性能的には大して上がらず、単に売れ線を意識しただけの
ような格好だったと思います
いまのデュアルチャンネルはメモリを実質的に128bitや196bitとみなせ
ますから、実数演算やSIMD命令で相当性能が上がっていますね
K7はデュアルだとFSB266まで、しかもレイテンシ大で、CPUが1GHzの頃はよかったが、
2GHzにもなると、ボトルネックになった。まぁその頃はOpteronへの移行が始まってたが。
EV6は、せっかくPoint-to-Point接続で、共有FSBのクロックが上げられない制限がないのに、
FSB333や400に対応したチップセットが投入されないという、もったいないことになってたね。
Windows VistaのDWM1.0ではGDIが全てCPU上で処理されてからDirectXでGPUに転送、だったせいで
メインメモリ帯域がPCの使用感に与える影響は半端じゃなかった。メモリが遅いともたもたスクロールになる。
DWM1.1になってそこまでの影響はなくなったな。
2Dアクセラレーションを切った今時のGPUでエディタでマクロを使った時の
もたつき感はそのせいか
でもBitBltだけは残してあるんだよね？
だったらIGPなんてどうなんだって話だわ
同じビデオチップを同じクロックで動かしても、ビデオメモリが違うと、かなり違う。
GeForce4MXクラスでも、
SDR 166MTs 64bit幅
DDR 400MTs 128bit幅
では、雲泥の差だった。
違いがでない理屈だろ上のは
それとWDDMだよな書きたいのは
食うだろう
> IGPなんてどうなんだ
IGPだと、メインメモリをビデオメモリとして使うので、
GDIがソフトウェア処理でもハードウェア処理でも、
同じじゃないか? ということなら、Yesだ。
IGPはパフォーマンスが悪かった。
まずCPUがGDIエミュレーションルーチンを走らせてメインメモリ上のサーフェースにお絵描きする
それをテクスチャに変換してVRAM (IGPだとこれもメインメモリ) にメモリtoメモリのコピーをする
そしてIGPはD3Dでテクスチャを読んでフレームバッファ (IGPだとこれもry) にレンダリングする
そしてビデオ出力部がフレームバッファを読んで出力する
つまり、メインメモリ上で「書いて読んで書いて読んで書いて読む」ことになる
ちなみにXP以前のドライバモデルなら、「書いて読む」だけだ
そんなわけで少なければ2倍、多ければ3倍になるわけだ
XPでも、GDI処理がGPUで非同期実行されるからCPU時間で見ればあまり差がないように見えていただけで、IGPは遅かった。
bitbltのすぐ後にさらにGDIのapiを呼び出せば、その相応の時間待たされることで隠蔽されていた処理時間が見えるようになる。
Radeonは描画がトロいよ。
・メモリのフィルが無駄に遅い(リードモディファイライトするから???)
・エミュレーションするときにCPUのキャッシュの内容が一掃される
だと思うわ。
大してダイ面積食ってるわけでもなかろうに
っていうのがマイクロソフトの判断だったのだろう。
でも実際には再描画が遅いのではなく、初回描画が遅かったのだ。
今後OSレベルで多用する事になるだろうし
アルファブレンドとかメモリの転送速度に比べたら誤差みたいな計算量だし。
アクセラレートのしようがないと思う。
Vistaが遅いのは本当に描画アーキテクチャが原因なのか？
スーパーフェッチとかそういうところじゃね？
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辺りなら問題ないけどね。
まあそういうこったね
あと、遅いっていうのはスループットだけじゃなくてレイテンシでも遅い
つまり>>45の各段にはバッファが入っていてパイプライン的に処理されていくので
アプリがクライアント領域に描画してからデバイスに出力されるまでは3フレームタイミング遅れる
この分だけでも、「再描画がD3Dだけでできる」というメリットは帳消しだと思うね
CocoaのGUI部品ってWindowsのそれと比べてオーナードロー／カスタムドローの
自由度低いから嫌いなんだが、描画方法が変わっちゃうと良し悪しなんだよなぁ
フレームの遅延、1フレーム単位でも、人間に知覚できるんだよね。
キーボードからテキストを入力するときの応答が速いときと遅いときがあって、
最初はCPU負荷かと思ったら、そうでもなくて、突き詰めていったら液晶モニタだった。
入力信号と画面から出る光をフォトトランジスタで受けた信号のタイミングを調べたら、
モニタの電源を入れるタイミング等々によって、
入力信号からパネル表示までの遅延時間に、約1フレーム分のバラツキがあった。
おそらくFRC(フレーム・レート・コンバータ)によって入力信号とパネル表示が非同期で行われてるかだろう。
http://journal.mycom.co.jp/special/2011/zacate/menu.html
大原節
32bit + PAE
64bit
下にいくほどページテーブルが肥大化していくよね。
メモリアクセスのオーバーヘッドは、どれくらい違うの?
なぜx86はSMTやってるのに、強力なフェッチ・デコードなの?
フェッチ・デコードは1クロックで処理する命令数が増えると指数関数的にデカく、電気食いになるよね。
1つのフェッチ・デコードで2スレッドを交互に処理するのではなく、
2つのフェッチ・デコードで各スレッド専用で処理したほうが、
シングルスレッドのパフォーマンスは低下するけれども、
消費電力が下げられるのでは?
AppleはiPadは失敗したけどAndroidは大成功だしなあ
Open OSだからすぐに中華でパクりそうだけど
マテマテ
AndroidはAppleではなく絡んでるのはGoogleだぞ
今の所はiPhoneのシェアが高すぎてAndroidはどうなるか未知数だが
ニコニコ生放送を見ていても最近Androidの端末を使用している人が
増えていると感じる
シングルスレッドの性能が限界に達しているので、メインストリームのプロセッサで性能を落とすわけにはいかないんでしょう。
並列化出来ない仕事だってあるからね。
Pentium3よりも遅くなる処理がある
って
散々叩かれたものね。
B.5 Amended Latency for Selected FMA Instructions
によれば(FMA/IMAC)と(XBAR/MAL/STO)間のデータ移動で1サイクルの
ペナルティがあるようだ
IntelのCPUでも異なるドメイン間のデータ移動でペナルティが発生するが
各ドメインに演算ユニットが配置してあるので適切な命令を選択すれば
ペナルティを回避できる
ハアアアァアアアァアァァァァァアァァアァアアアァァァアァァアアァァアァアァァアァア？？？？？
うるさいゴミ
Rubyだとつけなくてよくなるんだけど
ゴミだよなぁほんと
http://www.friweb.hu/instlatx64/
確かにLlanoの整数除算は速くなってるね
FP除算は速くなってないようだけど
Intelの場合、整数とFPの除算器を共用しいているせいか、両方速くなったりするもんだけど、AMDは別個なんだね
整数側が間借りしてるような感に見える。
整数DIVは商を求めてから非除数 - 商×除数で剰余を求めてるような。
4ビットずつ辞書引きをして引き算をするという操作を反復して商を求める。
アルゴリズムにもっと良いものがあるかどうかは知らないが
intelがそうするのならそれなりの理由があるのだろう
ってことになると整数と実数で別々に持つよりは共通の強力なユニットを1つだけ
持つほうが合理的だわな。
bullちゃんのレイテンシー＆スループット
のL:とかT:ってどういう意味？
Throughput: 次の命令に移れるまで
Throughput: ひとつき
