x86命令の所要クロック計測スレPart5
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2011/04/09(土) 16:43:11.05過去ログ
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
0002デフォルトの名無しさん
2011/04/09(土) 16:44:16.50コピペで動く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
0003デフォルトの名無しさん
2011/04/09(土) 17:01:22.55乙
0004デフォルトの名無しさん
2011/04/09(土) 19:28:25.78>テンプレに入れて欲しい
>http://instlatx64.fw.hu/
0005,,・´∀｀・,,）っ-○○○
2011/04/11(月) 22:10:11.30そろそろあのサイトの移転先考えないと。
JohnのMLにコミットしておくか
0006デフォルトの名無しさん
2011/04/12(火) 02:42:01.93＞おそらく6コアあるPhenom IIのほうがマシである。
暇ができたらちょっと検証してみてよ。
0007デフォルトの名無しさん
2011/04/12(火) 08:02:38.41Intelはピーク性能、AMDは安くてそこそこの性能って感じじゃね？
AMDはベンチマークには現れにくいが足回りが良くてワーストケースに強かったイメージがある。
サーバー向き。
もっとも、最近はその足回りもIntelに抜かれた感がある。
抜かれようが抜かれまいが、AMDの性格上DESやらエンコやらパイ焼きみたいな数値演算メインの処理で比較したらIntelに有利だと思う。
0008デフォルトの名無しさん
2011/04/12(火) 08:57:23.85NetBurst vs K7
においても、
> Intelはピーク性能、AMDは安くてそこそこの性能
だったと思うが
K7って爆熱&お馬鹿プリフェッチ&高レイテンシFSBで、
足回りが悪かったよ。
キャッシュがヒットしない領域に入った途端に、
Pentium3にも突き放される低速っぷり。
0009デフォルトの名無しさん
2011/04/12(火) 12:40:32.85> Pen4 vs AthlonXPの時を除いて
って書いてるのに。
バカなの？
0010デフォルトの名無しさん
2011/04/12(火) 13:07:20.54日本語わからないの?
0011デフォルトの名無しさん
2011/04/12(火) 13:13:27.73レス番間違えてるよ。
0012デフォルトの名無しさん
2011/04/12(火) 13:28:05.14いやいや合ってますってば。
0013デフォルトの名無しさん
2011/04/12(火) 13:31:44.960014デフォルトの名無しさん
2011/04/12(火) 13:34:40.12おまえがな
相手が間違っているという前提で読むから誤読するんじゃね?
落ち付いて>>7と>>8を読んでみ?
0015デフォルトの名無しさん
2011/04/12(火) 13:53:51.560016デフォルトの名無しさん
2011/04/12(火) 17:40:11.760017デフォルトの名無しさん
2011/04/12(火) 18:46:26.13>イメージがある
>有利だと思う
ここは計測スレだデータを示せ
0018デフォルトの名無しさん
2011/04/12(火) 20:55:19.220019デフォルトの名無しさん
2011/04/12(火) 22:47:48.81少しは紳士的な団子さんを見習えよ。
0020デフォルトの名無しさん
2011/04/12(火) 23:39:16.69そもそもK7,K8はDECのalphaの系譜なのだから
安くてそこそこの性能なんて言われちゃおしまいだろ
0021デフォルトの名無しさん
2011/04/12(火) 23:43:52.330022デフォルトの名無しさん
2011/04/13(水) 05:33:35.85そりゃそうだが、アーキテクチャをx86にした時点で別の視点で見られてしまうからな
「いかに速いx86か」でしかなくなってしまう
0023デフォルトの名無しさん
2011/04/13(水) 09:28:54.862chなんかでは、マルチプロセッサ構成で使ってもいない連中がPoint-to-Point接続の優位性を語ってて、おかしかった
0024,,・´∀｀・,,）っ-○○○
2011/04/14(木) 04:15:22.93Bulldozerは同モジュールあたりで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ビット化してきたことで
性能が出やすくなってる印象。
0025デフォルトの名無しさん
2011/04/14(木) 04:35:35.14AMDは価格相当の性能を出しているのだと思えば、Intel並みの性能が欲しければ
ハイエンドのCPUを買ってもIntelより安いのだし、「安かろう悪かろう」という市場原理
そのままのような希ガス。
逆にAMDが安価でIntelを突拍子も無く抜くような物を作るとAMDが独禁法の敵に
されるような気がする。
IntelはCoreアーキテクチャ以降もっさりのくびきから逃れる事が出来たし、AMDは頑なに
K5以降の路線を守り続けているが、目指す方向がほとんど同じに最近は思えてきた。
0026デフォルトの名無しさん
2011/04/14(木) 05:23:25.03買収で開発を取り込んでるだけのAMDに
0027デフォルトの名無しさん
2011/04/14(木) 07:47:19.01もしAMDがなかったらもっとCPUの値段が馬鹿高いぞ
0028デフォルトの名無しさん
2011/04/14(木) 10:12:38.73>>24
そのコードを全コアで一斉に走らせた場合、
Bulldozerは実行ユニットを2コアで共有している分、
Sandy Bridgeよりも遅くならないか?
かつてリソースを占有できるという前提で書かれたコードが、
Pentium4のHyperThreadingで悲惨なことになったように、
あまりタイトすぎると・・・。
0029,,・´∀｀・,,）っ-○○○
2011/04/14(木) 12:15:12.088KBとか16KBの小さいキャッシュを更に共有するとか、おかしいこと山の如し。
BulldozerはL1独立なのでL1容量がネックになるコードは性能が落ちるというより
最初から遅いと思う。1スレッドだけ走らせたからってL1Dが32KBとしてして使えるわけじゃ無しに
最初から16KB固定割り当てだしね。
ただし、2コア同時にキャッシュミス or prefetchしたらL2の帯域大丈夫かしら？ってのはある。
HPC版と銘打ったNehalem-EXの6コア・2.66GHz版は最初からHTは無効にしてある。
一方BulldozerのSIMD命令はレイテンシが大きすぎるので2スレッド使わないと埋まらない気がする。
0030デフォルトの名無しさん
2011/04/14(木) 12:40:15.040031デフォルトの名無しさん
2011/04/15(金) 02:21:42.30レイテンシも大きい事が多いけど
K8でメモリの足回りが良くなってから本当に速くなった
0032デフォルトの名無しさん
2011/04/15(金) 10:23:32.33そりゃIntelが、帯域幅を犠牲にしてでも共有FSBで100nsのほうが速いよ、って言うわけだ。
0033デフォルトの名無しさん
2011/04/15(金) 17:50:04.78100ns程度だったんだけどな
まあK7をフォトレタッチソフトのような大部分がメモリとのやり取りにCPU
タイムを費やすような用途に使う事はもうないでしょう
Phenom][やAthlonX2が出てるんですから
0034デフォルトの名無しさん
2011/04/15(金) 17:51:57.11古い物で記憶もあやふやになっとる
IntelもCode i7でトリプルチャンネルなんてやっちゃってるし
余程メモリが速度の足を引っ張るのが怖いんだろうな
0035,,・´∀｀・,,）っ-○○○
2011/04/15(金) 18:35:23.50もともとサーバ向けだし。ハイエンドデスクトップ向けでマスク共用して実質的なコストダウンしてるだけの話で
デスクトップ向けに3ch必要なわけではない。
実際4コアだと2chも3chも大して実効性能変わらんでしょ。
2chで6コアの製品はAMDしかないから知らんが。
0036デフォルトの名無しさん
2011/04/15(金) 18:40:07.91それはシングルCPUの話だよね。
デュアルCPUだと、
CPU(0)→ノースブリッジ→CPU(1)→ノースブリッジ→メモリ→ノースブリッジ→CPU(0)
ってな感じで、200nsもかかったらしい。
>>34
いや実際、メモリがボトルネックになるでしょ。
複数のコアのメモリアクセスがキューに並べば、レイテンシが悪化する。
だから、複数のメモリコントローラにアクセスが分散させてレイテンシの悪化を軽減しようとしてる。
K7時代のデュアルチャネルは、アドレスは1系統でデータが2倍というタイプ、
つまり、2つのDIMMを束ねて128bit幅のDIMMとして使うような方式だったが、
今のデュアルチャネル・トリプルチャネルは、アドレスが2系統・3系統あるのよね。
0037デフォルトの名無しさん
2011/04/15(金) 20:20:21.95あ、デュアルCPUの話でしたか
当時はマルチコアなんか無かったからすっかりわすれていました
SMPをすっかり忘れていました
そういえばAthlonXPをMP相当に改造してSMPで動くようにするとか
実験工作が流行ったような記憶が・・・
K7のデータバスは1本しかありませんから、nForce2のなんちゃって
デュアルチャンネルはノースブリッジに2本のメモリバスがあり、それを
ノースブリッジ内で合成して1本にして出力する物で、メモリインター
リープの考え方の延長上にありました
だから性能的には大して上がらず、単に売れ線を意識しただけの
ような格好だったと思います
いまのデュアルチャンネルはメモリを実質的に128bitや196bitとみなせ
ますから、実数演算やSIMD命令で相当性能が上がっていますね
0038デフォルトの名無しさん
2011/04/15(金) 20:49:26.38K7はデュアルだとFSB266まで、しかもレイテンシ大で、CPUが1GHzの頃はよかったが、
2GHzにもなると、ボトルネックになった。まぁその頃はOpteronへの移行が始まってたが。
EV6は、せっかくPoint-to-Point接続で、共有FSBのクロックが上げられない制限がないのに、
FSB333や400に対応したチップセットが投入されないという、もったいないことになってたね。
0039デフォルトの名無しさん
2011/04/16(土) 14:31:35.97Windows VistaのDWM1.0ではGDIが全てCPU上で処理されてからDirectXでGPUに転送、だったせいで
メインメモリ帯域がPCの使用感に与える影響は半端じゃなかった。メモリが遅いともたもたスクロールになる。
DWM1.1になってそこまでの影響はなくなったな。
0040デフォルトの名無しさん
2011/04/16(土) 14:50:47.442Dアクセラレーションを切った今時のGPUでエディタでマクロを使った時の
もたつき感はそのせいか
でもBitBltだけは残してあるんだよね？
0041デフォルトの名無しさん
2011/04/16(土) 22:18:56.82だったらIGPなんてどうなんだって話だわ
0042デフォルトの名無しさん
2011/04/17(日) 09:03:18.37同じビデオチップを同じクロックで動かしても、ビデオメモリが違うと、かなり違う。
GeForce4MXクラスでも、
SDR 166MTs 64bit幅
DDR 400MTs 128bit幅
では、雲泥の差だった。
0043デフォルトの名無しさん
2011/04/17(日) 12:59:01.94違いがでない理屈だろ上のは
それとWDDMだよな書きたいのは
0044デフォルトの名無しさん
2011/04/17(日) 13:55:29.25食うだろう
> IGPなんてどうなんだ
IGPだと、メインメモリをビデオメモリとして使うので、
GDIがソフトウェア処理でもハードウェア処理でも、
同じじゃないか? ということなら、Yesだ。
IGPはパフォーマンスが悪かった。
0045デフォルトの名無しさん
2011/04/17(日) 15:17:41.05まずCPUがGDIエミュレーションルーチンを走らせてメインメモリ上のサーフェースにお絵描きする
それをテクスチャに変換してVRAM (IGPだとこれもメインメモリ) にメモリtoメモリのコピーをする
そしてIGPはD3Dでテクスチャを読んでフレームバッファ (IGPだとこれもry) にレンダリングする
そしてビデオ出力部がフレームバッファを読んで出力する
つまり、メインメモリ上で「書いて読んで書いて読んで書いて読む」ことになる
ちなみにXP以前のドライバモデルなら、「書いて読む」だけだ
0046デフォルトの名無しさん
2011/04/17(日) 15:18:41.12そんなわけで少なければ2倍、多ければ3倍になるわけだ
0047デフォルトの名無しさん
2011/04/17(日) 18:50:15.680048デフォルトの名無しさん
2011/04/17(日) 19:22:59.83XPでも、GDI処理がGPUで非同期実行されるからCPU時間で見ればあまり差がないように見えていただけで、IGPは遅かった。
bitbltのすぐ後にさらにGDIのapiを呼び出せば、その相応の時間待たされることで隠蔽されていた処理時間が見えるようになる。
0049デフォルトの名無しさん
2011/04/17(日) 21:09:43.84Radeonは描画がトロいよ。
0050,,・´∀｀・,,）っ-○○○
2011/04/17(日) 21:19:56.590051デフォルトの名無しさん
2011/04/18(月) 14:26:59.69・メモリのフィルが無駄に遅い(リードモディファイライトするから???)
・エミュレーションするときにCPUのキャッシュの内容が一掃される
だと思うわ。
0052デフォルトの名無しさん
2011/04/18(月) 15:02:55.49大してダイ面積食ってるわけでもなかろうに
0053デフォルトの名無しさん
2011/04/18(月) 18:39:49.51っていうのがマイクロソフトの判断だったのだろう。
でも実際には再描画が遅いのではなく、初回描画が遅かったのだ。
0054デフォルトの名無しさん
2011/04/18(月) 18:56:00.20今後OSレベルで多用する事になるだろうし
0055デフォルトの名無しさん
2011/04/18(月) 19:28:31.39アルファブレンドとかメモリの転送速度に比べたら誤差みたいな計算量だし。
アクセラレートのしようがないと思う。
Vistaが遅いのは本当に描画アーキテクチャが原因なのか？
スーパーフェッチとかそういうところじゃね？
0056デフォルトの名無しさん
2011/04/18(月) 21:45:59.54D3Dの描画はともかく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辺りなら問題ないけどね。
0057デフォルトの名無しさん
2011/04/18(月) 22:45:31.930058デフォルトの名無しさん
2011/04/18(月) 23:34:13.940059デフォルトの名無しさん
2011/04/19(火) 03:40:32.20まあそういうこったね
あと、遅いっていうのはスループットだけじゃなくてレイテンシでも遅い
つまり>>45の各段にはバッファが入っていてパイプライン的に処理されていくので
アプリがクライアント領域に描画してからデバイスに出力されるまでは3フレームタイミング遅れる
この分だけでも、「再描画がD3Dだけでできる」というメリットは帳消しだと思うね
0060,,・´∀｀・,,）っ-○○○
2011/04/19(火) 03:46:08.08CocoaのGUI部品ってWindowsのそれと比べてオーナードロー／カスタムドローの
自由度低いから嫌いなんだが、描画方法が変わっちゃうと良し悪しなんだよなぁ
0061デフォルトの名無しさん
2011/04/19(火) 14:01:00.61フレームの遅延、1フレーム単位でも、人間に知覚できるんだよね。
キーボードからテキストを入力するときの応答が速いときと遅いときがあって、
最初はCPU負荷かと思ったら、そうでもなくて、突き詰めていったら液晶モニタだった。
入力信号と画面から出る光をフォトトランジスタで受けた信号のタイミングを調べたら、
モニタの電源を入れるタイミング等々によって、
入力信号からパネル表示までの遅延時間に、約1フレーム分のバラツキがあった。
おそらくFRC(フレーム・レート・コンバータ)によって入力信号とパネル表示が非同期で行われてるかだろう。
0062デフォルトの名無しさん
2011/04/28(木) 21:37:10.99http://journal.mycom.co.jp/special/2011/zacate/menu.html
大原節
0063デフォルトの名無しさん
2011/05/11(水) 09:24:45.1332bit + PAE
64bit
下にいくほどページテーブルが肥大化していくよね。
メモリアクセスのオーバーヘッドは、どれくらい違うの?
0064デフォルトの名無しさん
2011/05/11(水) 11:44:43.47なぜx86はSMTやってるのに、強力なフェッチ・デコードなの?
フェッチ・デコードは1クロックで処理する命令数が増えると指数関数的にデカく、電気食いになるよね。
1つのフェッチ・デコードで2スレッドを交互に処理するのではなく、
2つのフェッチ・デコードで各スレッド専用で処理したほうが、
シングルスレッドのパフォーマンスは低下するけれども、
消費電力が下げられるのでは?
0065,,・´∀｀・,,）っ-○○○
2011/05/11(水) 11:54:37.300066デフォルトの名無しさん
2011/05/11(水) 12:30:19.50AppleはiPadは失敗したけどAndroidは大成功だしなあ
Open OSだからすぐに中華でパクりそうだけど
0067デフォルトの名無しさん
2011/05/11(水) 16:03:33.64マテマテ
AndroidはAppleではなく絡んでるのはGoogleだぞ
今の所はiPhoneのシェアが高すぎてAndroidはどうなるか未知数だが
ニコニコ生放送を見ていても最近Androidの端末を使用している人が
増えていると感じる
0068デフォルトの名無しさん
2011/05/12(木) 15:19:27.82シングルスレッドの性能が限界に達しているので、メインストリームのプロセッサで性能を落とすわけにはいかないんでしょう。
並列化出来ない仕事だってあるからね。
0069デフォルトの名無しさん
2011/05/12(木) 16:37:13.69Pentium3よりも遅くなる処理がある
って
散々叩かれたものね。
0070デフォルトの名無しさん
2011/05/13(金) 23:37:02.71B.5 Amended Latency for Selected FMA Instructions
によれば(FMA/IMAC)と(XBAR/MAL/STO)間のデータ移動で1サイクルの
ペナルティがあるようだ
IntelのCPUでも異なるドメイン間のデータ移動でペナルティが発生するが
各ドメインに演算ユニットが配置してあるので適切な命令を選択すれば
ペナルティを回避できる
0072天使 ◆uL5esZLBSE
2011/07/02(土) 16:25:52.13ハアアアァアアアァアァァァァァアァァアァアアアァァァアァァアアァァアァアァァアァア？？？？？
うるさいゴミ
0073天使 ◆uL5esZLBSE
2011/07/02(土) 19:18:13.81Rubyだとつけなくてよくなるんだけど
ゴミだよなぁほんと
0074デフォルトの名無しさん
2011/07/11(月) 01:19:18.180075デフォルトの名無しさん
2011/07/22(金) 14:01:37.28http://www.friweb.hu/instlatx64/
確かにLlanoの整数除算は速くなってるね
FP除算は速くなってないようだけど
Intelの場合、整数とFPの除算器を共用しいているせいか、両方速くなったりするもんだけど、AMDは別個なんだね
0076,,・´∀｀・,,）っ-○○○
2011/09/04(日) 20:39:56.33整数側が間借りしてるような感に見える。
整数DIVは商を求めてから非除数 - 商×除数で剰余を求めてるような。
0077デフォルトの名無しさん
2011/09/09(金) 19:08:51.010078,,・´∀｀・,,）っ-○○○
2011/09/11(日) 20:58:20.034ビットずつ辞書引きをして引き算をするという操作を反復して商を求める。
0079デフォルトの名無しさん
2011/10/08(土) 06:52:14.25アルゴリズムにもっと良いものがあるかどうかは知らないが
intelがそうするのならそれなりの理由があるのだろう
0080,,・´∀｀・,,）っ-○○○
2011/10/08(土) 07:47:06.40ってことになると整数と実数で別々に持つよりは共通の強力なユニットを1つだけ
持つほうが合理的だわな。
0081デフォルトの名無しさん
2011/10/20(木) 19:24:52.03bullちゃんのレイテンシー＆スループット
0082デフォルトの名無しさん
2011/11/09(水) 22:30:07.360083デフォルトの名無しさん
2011/12/13(火) 05:55:10.72のL:とかT:ってどういう意味？
0085デフォルトの名無しさん
2011/12/13(火) 21:32:58.98Throughput: ひとつき
0086デフォルトの名無しさん
2012/01/23(月) 14:21:46.67この業界だとThroughputの逆数のことを単にThroughputと言うことが多いよね
マニュアルとかにはReciprocal Throughputと書いてある
0087デフォルトの名無しさん
2012/01/24(火) 01:16:18.55日本人固有の造語というわけじゃなくてIntelがそう呼んでるからな。
もっとも、Intelは往々にして言語力が怪しい気がする。
0088デフォルトの名無しさん
2012/01/25(水) 11:58:38.460089,,・´∀｀・,,）っ-○○○
2012/02/02(木) 22:35:53.87スループットの指標には違いないだろ
0090,,・´∀｀・,,）っ-○○○
2012/02/02(木) 22:40:30.630091デフォルトの名無しさん
2012/02/25(土) 15:09:41.540092デフォルトの名無しさん
2012/04/24(火) 20:18:31.72http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf
2.1.7 IntelR Microarchitecture Code Name Ivy Bridge
にMicroarchitectureの変更点が書いてある
0093デフォルトの名無しさん
2012/06/26(火) 22:50:12.38> 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)
とは一体何だったのか？
0094デフォルトの名無しさん
2012/06/27(水) 09:38:40.710095デフォルトの名無しさん
2012/07/07(土) 16:45:23.88浮動小数点の除算、平方根系の命令が速くなっている以外は
スカラのシフト、ローテートの高速化ぐらいか
ただ肝心のレジスタ間movが消えるってのは効果が見えないな...
0096,,・´∀｀・,,）っ-○○○
2012/07/08(日) 20:50:38.82pshufbとかpandnとか多用してるとdestを保存したい場合って結構出てくるんだけど。
0097デフォルトの名無しさん
2012/07/08(日) 22:12:32.60数値上はmovとかmovapsとかmovdqaが全部スループット0.25になるはずなのに
Sandyと変わってないので
0098デフォルトの名無しさん
2012/07/08(日) 22:17:15.71ツールがちゃんと測れていないということでもなさそうだし。
0099,,・´∀｀・,,）っ-○○○
2012/07/08(日) 23:38:51.74LU/STA×2、STD×1、ALU×３の6ポートだけど、レジスタ間movを処理できるのは3ポートだけで
スケジューラのほうは1サイクル4オペレーション以上処理できるようになってないとか？
命令個別のスループットサイクルより、どっちかというと実際のコードシーケンスにおける
実効レイテンシの削減に効果的な技術だと思ってるんだが。
ただ、かつてのFXCHほどにはインパクトないかもしれないね。
0100デフォルトの名無しさん
2012/07/09(月) 01:16:46.52zeroing idiomsと同じくリネーミングの段階で終わるもんだと思うんだけど。
zeroing idiomsはちゃんとスループット0.25出てるし。
まあ
movdqa xmm1, xmm0
pand xmm2, xmm1
pand xmm3, xmm1
pand xmm4, xmm1
みたいなのが1サイクルで回るか調べてみればいいんだけど。Ivyがあれば
0101,,・´∀｀・,,）っ-○○○
2012/07/09(月) 01:25:47.62Ivy BridgeはAVX対応でのみ得られるメリットを従来SSEでも一部享受できるようにしたことに
意味があると思う。
もちろんμOPs Cacheによる16バイトフェッチ帯域上限の緩和とかLoadユニット2重化とか
Sandy Bridgeの時点で実装された高速化要因があるんだけども。
■ このスレッドは過去ログ倉庫に格納されています