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

Penrynとあんま変わってないじゃないか。
良くも悪くも

こっちはいい傾向だな
http://www.freeweb.hu/instlatx64/MemLatX64_GenuineIntel00106A2_GainestownES_2666MHz.txt

Penryn
http://www.freeweb.hu/instlatx64/InstLatX64_GenuineIntel0010676_Core_Harpertown_2800MHz.txt
1153 SSSE3 :PHADDD xmm, xmm L: 1.07ns= 3.0c T: 0.72ns= 2.00c
1170 SSE4.1:MPSADBW xmm, xmm, imm8 L: 1.79ns= 5.0c T: 0.72ns= 2.00c
1171 SSE4.1:PHMINPOSUW xmm, xmm L: 1.43ns= 4.0c T: 1.43ns= 4.00c

Nehalem
Inst 1153 SSSE3 : PHADDD xmm, xmm L: 1.06ns= 2.8c T: 0.56ns= 1.50c
Inst 1170 SSE4.1: MPSADBW xmm, xmm, imm8 L: 1.81ns= 4.8c T: 0.37ns= 1.00c
Inst 1171 SSE4.1: PHMINPOSUW xmm, xmm L: 1.12ns= 3.0c T: 0.37ns= 1.00c

シャッフル命令強化？
さて、まるもに投稿してくるか

http://pc11.2ch.net/test/read.cgi/avi/1225343648/236
http://pc11.2ch.net/test/read.cgi/avi/1225343648/281

>>290
> シャッフル命令強化？
Integer Shufflesが倍になった
ttp://pc.watch.impress.co.jp/docs/2008/0403/kaigai13.jpg

punpck/pack/pshufのスループットが(packのMMXレジスタ版を除き)倍になっている

やっぱりそうか
Radix-16 Dividerとシャッフルユニットって回路共有できるんじゃないかと思ってたけど
Penrynではなぜか別々だったんだよな

PADDQのスループットレイテンシが良くなってるな。

>Radix-16 Dividerとシャッフルユニットって回路共有できるんじゃないかと思ってたけど
できねーよw

pshufbを1サイクルでやるのに必要な回路って4ビット（16Way）のテーブル参照じゃん。
Radix-16も原理的には同じクロスバースイッチによる実装だよ。

まあ実際に回路共有してるかどうかは知らんがどちらもIntelでは45nmプロセスで初めて実装された
同水準の技術というのは事実だな。

団子はプログラムだけかたってりゃいい。
無理に回路の話するな。

どっちも4ビットのテーブル参照ユニットだよ。
radix-16の実装についての論文は嗜んでおります。多分君らよりはモノ読んでるから。

もの読んでも理解できてないんじゃ意味ないし、読んだうちにはいりませんよ。
あるレジスタ値をシャッフルするようなネットワークなんて今時のプロセッサ内には沢山ある。
回路の世界では、実装は共通化しないで分離、専用化した方が高速なのが普通。
むりにハードを語る必要はない。

専用化（笑）

除算命令をパイプラインのどこでマイクロコードに分解してると思う？
無理にハード語るなよ

ダンコ″さんが饒舌になるとスレが湧き上がるな

>除算命令をパイプラインのどこでマイクロコードに分解してると思う？
>無理にハード語るなよ
団子ワラタ
こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

http://www.agner.org/optimize/instruction_tables.pdf

どこに除算命令をシングルμOPで実行できるx86処理系があるんですか？

>>302←恥ずかしい奴だな。無知なら黙っておけばいいものを。

http://www.agner.org/optimize/instruction_tables.pdf
http://www.agner.org/optimize/instruction_tables.pdf
http://www.agner.org/optimize/instruction_tables.pdf
http://www.agner.org/optimize/instruction_tables.pdf

おいおい、団子よ、誤魔化そうとするなよ。
おれはシングルuopとはいってない。
だが、団子は、uopに細かくばらすことで回路を共用にできると思ってるんだろw

はいはい、恥ずかしいから帰っていいよ。

次来るときは共用してない根拠を示してね
その逆の説明は、多くのx86アーキテクチャで除算命令とシャッフル命令の発行ポートが同一な
理由の説明にもなってしまう

>除算命令をパイプラインのどこでマイクロコードに分解してると思う？
この答えは猿でもわかるデコーダだが、団子はこの先何を言いたいのでしょう?
無知をさらしたくないならレスをしない方が身のためかもよ。

>次来るときは共用してない根拠を示してね
やっぱマジでuop効果だとおもってるんだな団子先生は。
偉大だ。自分で提示しているソースにそもそもそれを否定する内容がかかれているともいざ知らず。
除算命令はuopを一体何個生成しているのでしょう?
ハードはなるべく語らない方が身のためだ。これが僕からのアドバイスです。

もう恥ずかしいから出てくるなよ。
マイクロオペレーション数とかかってるクロック数数えてみな。
馬鹿にはわからない真実がある。

アー馬鹿には理解不能だけどな

>マイクロオペレーション数とかかってるクロック数数えてみな。
自分で自分の間違いに気づいたのか、単なる電波なのか。
お団子くんの必死の弁解ショーがこれから始まります。

別ユニットであると自信を持って言える根拠ってなんだろうね

１．俺の脳内アーキテクチャではそうだ
２．俺はIntelの中の人だ
３．とりあえず団子の言うことだから苦し紛れでも否定しとけ

俺は断定も否定もしてないが、ただ、μOP数に着目すれば
シャッフルユニットと辞書引き用のユニットで別々に持つ必然性もないことだけはわかるな。

つーかpshufbが辞書引きでなくてなんだって話になるけどな。
辞書引きする値の供給元が定数ROMかレジスタかって違いか

とりあえずSSE4.2のテキストサーチが汎用のシャッフルユニットの組み合わせで実装されてる程度には
除算命令も汎用ユニットに対するマイクロオペレーションの組み合わせで実装されてるよ

タ″ンゴさんの連投れスレが猛烈にヒートアップしたな

DIV/IDIVの32bit版ですよ

・Core 2(65nm)
　μOPs=4
　L=18-42 T=12-36

・Core 2(45nm) （Super Shuffle Engine / Radix-16搭載）
　μOps=7
　L=14-23　T=？？

45nmでは大幅に除算の性能上がってるのにμOPsが増えてるのはなんでだろうね？
むしろ7μOPsの内訳はなんだろうね？

はい、これ宿題ね。

7μOpsの内訳、資料に書いてあるわ

Port 0: 2
Port 1: 3
Port 5: 2

うん、確かにばら撒いてるな

＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw


馬鹿丸出しだな

↓↓↓ダンゴ先生（ＮＧワード）の勝利宣言が続きます↓↓↓

ヲーーーーーーーーーーーーーウィWWWWWWWWW
「除算は除算専用ユニットで処理される」とか恥ずかしい事言ってたフェンス君出てコーーーーーーーーーウィWWWWWWWW
ああどうしてフェンス君はこんなにも脳内がお花畑なんだWWWWWWWW
チクショオオオオオオオオオオオオオｵｵｵWWWWWWWWW

おれはフェンス君じゃないよw
団子の脳内CPUにはユニット未満の回路構成単位はないみたいでワラタ。
複数サイクルかかるのはなんでもuopに分解されてるからとでもおもってんのか、こいつはw

事実複数μOPｓに分解されてるジャン。
言い訳になってないよ。

レイテンシチェインがあり複数命令をインターリーブできない場合はスループットも内部OPｓ数以上になることはあるね。
P5までのx87命令が代表例。

【7μOpsの内訳】

Port 0: 2
Port 1: 3
Port 5: 2

＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

恥ずかしくないですか？

>>321
で、自分でuop数と実行レイテンシを比較した考察はどうだったんだ?
お前の頭には1uopで動く一般的な"除算器"(もちろん実行ユニットやポートと1対1とは限らない)という概念がないのね。
知らないからw

＞お前の頭には1uopで動く一般的な"除算器"(もちろん実行ユニットやポートと1対1とは限らない)という概念がないのね。

PenPro/2/3でDIVが1μOPなのは知ってるよ。
しかし、少なくともCore 2以降のx86には無いし今後実装されることもないでしょう

>>323
おれは除算専用ではない汎用的な"ユニット"にばらまくと団子が思っていると書いているが?
団子は"命令ポート"に数命令が渡されるのを、除算中のRadix単位の反復処理に対応するものだと勘違いしている
(必死に今ごまかそうとしている)。

Penrynには【除算専用ユニット】が全ALUポートに2:3:2で存在するのか
すげーな

>>326
じゃあ何の命令を発行してるの？
除算ユニットは何番ポートにあるの？

↑団子がここまで馬鹿だとは最初に書いたおれも思わなかった。
除算専用ユニットか、それよりも汎用的なユニットに除算器で処理するような内容を分解しているのか?
という話で元々かいていて、uop数とレイテンシを比較してどう団子は考えたの?
ときいているんだよ。お前は一体何様なんだ? 話をこじらして逃げようとしているだけ。

ちゃんと読み返せばわかるとおり、
おれは2つ以上のuopに除算命令が分解されることはない
なんて一切かいてない。適当な団子よりも言葉を選んでいるし、あと百回読んでからレスしろよ。

馬鹿はお前だ。
除算専用ユニットでの1μOPで完結してるとして残りの6μOPｓは何のために何の命令を発行してるんだ

　答　　え　　て　　み　　ろ　　よ

お前の間違いはそこにある。

「おれ」を漢字で書かないのはフェンス症候群

言っておくけど、NOPは、発行せずにリタイヤだよ。

>>331
詳細はわからないが、
通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?
で、団子はuopに分解するのにスループットが悪かったり、そもそもレイテンシが
一致しないのをどう説明するんだ?

パイプライン化されてない命令が複数サイクルかかるのは一つの事実だけど
除算命令が複数μOPｓに分解される事実を否定するものでは無いな

だから複数uopを生成しないなんておれは書いてないだろ。

>どっちも4ビットのテーブル参照ユニットだよ。
>radix-16の実装についての論文は嗜んでおります。多分君らよりはモノ読んでるから。
>俺は断定も否定もしてないが、ただ、μOP数に着目すれば
>シャッフルユニットと辞書引き用のユニットで別々に持つ必然性もないことだけはわかるな。

はやくこの大風呂敷を説明しろよ。

＞通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?

何の例外だよ。何のフラグだよ。
お前は何も具体的なこと理解してないのに思い込みでモノをいうんだな。

結局お前はRadix-16の論文読んでないんだな。
ちなみに8ビットの除算だと4μOPsで済んでるし
64ビットだとより多くのμOPｓ数がかかってる

＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

逃げようとしても無駄だよ。
>お前は何も具体的なこと理解してないのに思い込みでモノをいうんだな。
それはお前の方。uopが複数かかる要因は色々考えられる。Intelが詳細を公開しているわけでもないし、
正直、具体的にはわからない。何ビットかの単位でuopを分けているのかもしれないが、そもそもraidx-16の実装は
ユニット内部の話なので関係がない。
偉大なる団子さんは、具体的かつ断定的事実をuop数とレイテンシの数字から
発見したらしいからそれを説明して欲しい。

＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
前後の流れをみて読めばわかるとおり、除算専用のユニットではなく、汎用的なユニットにばらまいて処理している
と書いているのであって、複数のuopそのものを否定しているわけではない。
以前から知っていることだし、そんなことは今更書くわけない。

逃げてるのはお前だろ。
自分では具体的な証拠も示さないくせに
無根拠な主張だけは延々やるんだな

負け犬よ。ごたくはいいからμOPsの内訳を答えろよ。
答えられないなら赤い顔に水でもかぶってさっさと寝ろ

>無根拠な主張だけは延々やるんだな
だから団子は根拠をいつになったら説明するんだよw
あの.pdf資料だってここにいるやつは観てるだろ。
今更なにを説明しろと。
http://pc.watch.impress.co.jp/docs/2007/0524/mpf01_04.jpg
この図をみて、radix-16が実行ユニットの実装の話であり、
シャッフルユニットとの共有とかuopの分割はレベルの違う話である。
ただそれだけのこと。団子はそれがわかってないから、おれの文意味すらわからない。

整数除算で起きる特殊例外なんてせいぜいdivide by zeroくらいだぞ？
フラグ更新なんて分岐条件フラグを更新するaddやandが1μOPで済んでる程度に低コスト。

6μOPの内訳の妄想としては稚拙すぎる。

他にもスケジューリング単純化の都合で使わないALUを麻痺るとか?

Fused uopな故に、実際にはuopなんて生成していないが、
ポートが使えずに、uopが生成されたかのように見えるとか?

結局これがすべて最初から最後までハードワイヤードロジックで実装されてると思ってるんだろ
http://pc.watch.impress.co.jp/docs/2007/0524/mpf01_04.jpg

それが大間違いだよ

風呂敷あと何枚ひろげたら気が済むんだ?
そろそろたたまないとエヴァ●ゲリオンの二の舞だよ。

>>341
人に答えさせようとするよりも、自分からビシッと示して、話をスパッと終わらせたほうがいいと思う。

俺がやる必要ないし
すべてハードワイヤードロジックで実装されてるっていう思い込みありきだから
現実世界の事実と照合したときに矛盾ばかりが浮上する。それだけ。

で、自説のほうが間違いだから、現実のほうに対して思い込みありきの矛盾解消を求めてくる←今ココ

無理だって。だって思い込みの時点で間違ってるんだもん。

一応フォローしておくけどQSL＝テーブル参照
つーかさ、ADD/SUBもAND/OR/XORも専用のサブユニット用意してるわけじゃないんだぜ。
出来るだけ共用化することでトランジスタ数を抑えられる。クロックゲーティングに必要なトランジスタ数もね。
実際どういう構成になってるかは中の人しか知りえないことだよ。

中の人でないと自ら白状してるから、まあ脳内アーキテクチャが根拠なんだろうけど
案の定、現実世界の事実との矛盾にぶち当たってる。

ダンゴさんのエスプリの効いたレスでスレがあふれ返っているな

いや、自分は団子さんが正しいと思ってる。
このスレでカマッテチャンの相手をしてスレをハイペースで延ばすくらいなら、ズバリ説明してトドメさしたほうが、再発しなくていいかな、と。

ダンゴさんの自演でスレの信憑性が一気に高まったな

そもそも団子はハードワイヤードロジックって言葉が
何を指しているかもわからないんだろうけどなw
ハードに関しては素人以下の妄想レベル。

テーブル参照がマイクロコードなしでは実装できないという電波説も新たに披露してくれるのか。
配列やハッシュに相当する機能はハードだけで実現できるのをしらないんだねw

現実問題として、整数DIV/IDIVで複数μOPかかってる。
除算回路がマルチサイクルかけてループ処理する機構になっていることと、
分解の必要有無は別問題なんだよ。
っつーか、PenrynでもSSE浮動小数の除算や平方根は1μOPで済んでる。
ちゃんと資料を読んでればわかること

つまるところ整数に余分にμOPｓがかかるのはなぜか？ってことなんだが。
おそらく浮動小数演算にチューンされて、整数だと余分にオペレーションがかかる構造になったため。
たとえばDIV/IDIVは商をEAXに格納するほかに、【剰余】をEDXレジスタに格納する。
たとえば、除算機から剰余を吐き出す回路が端折られた場合、どうやって剰余を求めると思う？

一番わかりやすいのが、
剰余　＝　被除数−（商×除数）

被除数のシャドウレジスタへの退避＋除数と商の乗算＋被除数からの減算
で3μOPs。8ビット版の除算の内訳としてはちょうど数があう。
ハイこれで一つ解決だね。

32ビットの7μOPｓは単精度の仮数が24ビットしか表現できないから除算の段階でも4μOpsに分解するようにしたんだろ。
この点は4μOPのMeromから劣化してるっぽいが平均的に除算性能が上がったぶん端折ったと思われる
16ビットは実装が内部32ビットで出力時に下位16ビットを書き込むからだと思ってるが。
ホントは最適化すれば8ビットと同じ4μOPｓで済むと思うが、端折ったんだろ
8ビット除算はレガシーとはいえAscii Adjust〜でたまに使うけど16ビットはそんなに使う機会ないからね。
64ビットは倍精度の53ビットにすら収まらない。増えるのは道理。

まあ、「よくわからないフラグ」と「よくわからない例外」なんて珍説よりは辻褄があってると思うが。

除算用のテーブルルックアップ用サブユニットが除算専用化されてて
他の演算に使いまわし出来ないという仮説に至る理由はよくわからんけどな。
もちろん、複数μOPｓかかる事実は、仮説の反証としても成立してないよ。
Penrynでは少なくともやってないのは事実としてあるし。

>>354
そんなこと一言も言ってないけど。
いい加減一人相撲に気づけよ

ちなみに>>346の図には剰余の出力が描かれてないね。

ちゃんばば臭い。

命令としては剰余は必ず求めなければならないので、その回路を削るとは思えないんだが。
削ったほうが、どれくらい回路が節約できるのかな。

まぁ剰余を誰も使っていないのなら計算を省けるか。

除算ロジックから剰余出力を端折る理由：だって浮動小数に必要ないじゃん。
商だけわかれば剰余を汎用のユニットで求められるだろ。

それとも、よくわからないフラグとよくわからない例外処理のほうが説得力あるのか？ｗ

団子も徹夜の学習でまともになってきたせいか>>355の考察はよいが、
団子が自分で広げた大風呂敷を結局回収できてないことは事実だな。
なにしろ除算専用の演算器の存在をCore 2で否定したんだからな。
そしてシャッフルユニットとRadix-16除算器の共用化に関しては
未だに説明がない。これ以上ごまかしと話題そらしをつづけるなら、
除算ネタを今後の煽りネタとしてつかいつづけちゃうぞ。

300 ：,,・´∀｀・,,）っ-●◎○ [↓] ：2008/11/15(土) 20:56:50
専用化（笑）

除算命令をパイプラインのどこでマイクロコードに分解してると思う？
無理にハード語るなよ

296 ：,,・´∀｀・,,）っ-○◎● [↓] ：2008/11/14(金) 21:50:43
pshufbを1サイクルでやるのに必要な回路って4ビット（16Way）のテーブル参照じゃん。
Radix-16も原理的には同じクロスバースイッチによる実装だよ。

さて、>>346の除算器でどうやってシャッフルが可能になるのか。
論文をたんさんよんで、しかも理解しているという団子先生のもう講義が
これからはじまります↓

>>358
すぐ直後にEDXレジスタに上書きしていれば、剰余は計算しなくてよいってわかるね。
つまりEDXレジスタの参照をしたときに剰余の計算が発生する? それじゃパイプライン止まるな。

>>360
お前は頭も悪いし勉強できてないな。
俺の理解を曲解することしか
俺がいつ、シャッフル命令＋αの命令単位に分解するなんて言ったよ？
たとえるなら積和算ユニットの一部を単体の乗算と加算で使えるってレベルの話しかやってない。
複数μOPsに分解される理由を曲解してるからそういう妄想にたどり着くんだろうな。

すぐ下を見れば浮動小数除算が1μOPで処理されてることくらいわかるし

散々ヒント与えたのに相変わらず電波飛ばしてるのはお前だけ

>>362
不正解。
おそらく、剰余を端折れるか判定してさぼるための機構のほうが
まじめに剰余出力するよりコストかかることだろう

回路からは端折ってるがマイクロオペレーションで実装してるだろって話。
（だから1μOPで済んでいない）

複数マイクロオペレーションかかる理由

・わけもわからないフラグ更新
・わけもわからない例外処理
・演算ポートに「フェンス」（←得意のｗｗｗ）


自分が一番わかってないのにいい加減気づけよ

伝搬速度がクリティカルなので回路を使いまわせません!

「勝ち」を確信したダンゴさんのアゲ荒らしは凄惨極まりないな

ダンゴさんの書き込み頻度を見てみると
どうも時々発作が出るみたいだな

団子さんは初めに自分の考えが誤っていることを認めるべきだった。
間違いは直ぐに認めて訂正した方が良い。
だから無駄に書き込みの回数が多くなるんだよ。

293 ：,,・´∀｀・,,）っ-●◎○ [↓] ：2008/11/13(木) 21:23:37
やっぱりそうか
Radix-16 Dividerとシャッフルユニットって回路共有できるんじゃないかと思ってたけど
Penrynではなぜか別々だったんだよな

出だしと最終的な結論が一致してない。

俺の撒いた風呂敷に足を滑らせてフェンスに激突

>>365
おれは、シャッフル演算器と除算器の共用化の話をしているので。
脱線話の1レスに粘着して、自分の汚点を体力勝負の罵倒書き込みで覆い隠そうなんて魂胆、
バレバレだし、はずかしいんでヤメテ欲しいです。

>>369
何も公式な解説が出てないので実際共有してるかしてないかは
Dividerと追加されたシャッフルユニットが同じポートに追加されたのは一つの事実だ。
俺は何一つ断定したことは言ってない。

DIV/IDIVが1μOPではなく複数の内部命令に分解されて実行される事実を提示したら
一人で混乱してた馬鹿がいただけの話

>>371
恥ずかしい馬鹿だな。
脱線してフェンスに激突してるのはお前だけだよ

・わけもわからないフラグ更新
・わけもわからない例外処理
・演算ポートに「フェンス」（←得意のｗｗｗ）

スレタイ読めよ。

中身なんてどうでもいいんだよ。

>DIV/IDIVが1μOPではなく複数の内部命令に分解されて実行される事実を提示したら
>一人で混乱してた馬鹿がいただけの話
何度もいうが、おれは全く1uopのみだと思っていなかったし、1uopしか生成しないなんて
いったことはないが。
団子の書き込みは話の前提がテーブル参照をマイクロコードで云々だったから、
汎用的なユニットにばらまく云々の書き込みは、それを否定したまでだ。

＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw


馬鹿は死ななきゃ直らない

何度もいうが、おれは全く1uopのみだと思っていなかったし、1uopしか生成しないなんて


＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
＞こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

＞何度もいうが、おれは全く1uopのみだと思っていなかったし、1uopしか生成しないなんて
＞いったことはないが。

復唱しましょう
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】

だから、前後の流れをみずに都合の良いように1行だけ引用するな
クズ団子が。

何度もいうが、この馬鹿はこの発言をした時点では、全く1uopのみだと思っていた。

【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】
【こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw】

>>380
前後の流れを見てもお前の勘違いは確実だが

だって、除算の出力に何の意味も無いオペレーションという仮説を3つも4つも出てくるんだもん。
いまさら撤回するなんて言うなよ。

一番理解してなかったのはお前。

普通によめば
除算器をもちいずに汎用的な他の演算ユニットで処理していると読める
団子は鬼の首をとったように持ち上げているが、団子理論では
除算器なんていらないんだもんなw

恥ずかしい発言だね

＞通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?

>>383
お前が曲解してるからそう読めるだけだよ。
だって俺が指摘するまでμOPｓの中身を説明できなかったのが理解できてなかった証拠

>だって、除算の出力に何の意味も無いオペレーションという仮説を3つも4つも出てくるんだもん。
>いまさら撤回するなんて言うなよ。
おれは撤回してもぜんぜん良いが何か?　間違いを訂正できないどっかの物量書き込みの糞野郎と
同じにしないで欲しい。
あと、脱線話の手抜き1レスに粘着して話をごまかそうとするはバレバレだからやめようよw

っていうか、鬼の首をとる？蛆虫を靴で踏み潰すの間違いだろ。

そんなことよりも、Core i7買ったのか? おまえら。

>>386
プライド無いんだね。
コロコロ珍説を撤回されては議論になんないよ。論破じゃなくて論理破綻だよ。

最初から最後まで正しい理屈を述べられるまでお勉強してからまたこいよ
おばかさん

296 ：,,・´∀｀・,,）っ-○◎● [↓] ：2008/11/14(金) 21:50:43
pshufbを1サイクルでやるのに必要な回路って4ビット（16Way）のテーブル参照じゃん。
Radix-16も原理的には同じクロスバースイッチによる実装だよ。

300 ：,,・´∀｀・,,）っ-●◎○ [↓] ：2008/11/15(土) 20:56:50
専用化（笑）

除算命令をパイプラインのどこでマイクロコードに分解してると思う？
無理にハード語るなよ

ログ流そうとしても無駄だよ。定期的に説明つきで張り直してやろうか?w

別に間違ったことは言ってないね

＞通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?

これは間違ったことだね

それでは団子先生、
除算命令をパイプラインのどこでマイクロコードに分解しているのか
という質問の意図はいったい何だったのでしょう?
そして、何故シャッフルユニットと除算器の共用化で高速化が可能になるのでしょう?

>>78
他スレにあった情報によると
AthlonMPはメモリにアクセスしに行く前に、
もう片方のCPUのキャッシュに問い合わせを行うので、
そのためにレイテンシが大幅に増加するらしい。

>>392
間違いだとは残念ながら団子君の根拠だけでは説明しきれてないが何か?

×高速化
○回路の節約

>>395
じゃあ何のフラグなのか説明しろよ。
言ってる本人が理解できてないものを否定するなんて悪魔の証明なみに無意味だ。

あれあれ、そもそも団子先生は、
>>290,>>293でNehalemでシャッフルが速くなった理由として、
共用化の可能性をあげていたのでは?
いつのまにか節約の話に変わっていますね。

それがそもそもの間違いはそこから始まってるようだな。

シャッフルを発行できるポートが2基に増えてるだろ。図を見れば判るとおり。
問題になるのは、いかに低コストで実装出来るかという話。
既存の除算ユニットの一部分と共用化できれば低コストで実装できるわけだ。

しかも、2段階のシャッフルが出来るユニットとして。

　　　　　　　　　　　　　　　　　　-‐ '' " ",.￣''￣｀ ''‐､
　　　　　　　　　　　　　　　 ,.-'　　　 　 ,r''　　_,,.. -　､　 ` ､
　　　　　　　　　　　　 　 ,.r'／／／ ／ 　 ,.-'　　　 　 ｀' ､. ＼
　　　　　　　　　　　　　/　　 　 　 ,r'　　,r'　　　 　　　　　 ＼ '､
　　　　　　 　 　 　 　 / /////　 ,'　　 ,'　　　　　　 　　 　　 ヽ ',
　　　　　　　　　　　　i　　　　　,.ｧ　　 .i　　　　　　　　　 r=ｧ. 　 ',. ',
　 　 　 　 　 　 　 　 |　　,.r '"　 |.　　 {　　r=-　　　　 　 　　 　 ', ',
　　　　　　　　　　　 | .,.r'　　　　|　　　!　　　　　　　　　　　　　　 i .i
　　　　　　　　　　　 |,'　　　　　 ',　　　',　　　　　　.ｰ=‐'　　　 　　| .|
　　　　　　　　　　　 |　　　　　　 ',　 　 `､　　　　　　　　　　　 　 } .}
　 　 　 　 　 　 　 　 ',　　 　 　 　 ',　　　 '､　　　　　　　 　　　　 ! .|
　　　　　　　　　　　　'､　　　　　 　`､　　　＼　　　　　　　　　 　 ,'　!
　　　　　　　　　　　 　`､　　　　　 　 '､　　 　 ' ､　　　　　　　　/ .,'
　　　　　　　　　 　 　 　 '､'-..,,_____　___`､　　　　`''‐-　..,, ,,.. r'　 /
　　　　　　　　　　　　　 　＼　ヾヾヾヾヾ ＼　　　　　　　　　　／
　　　　　　　　　　　　　　　　` ､　 ､､､､､､､､ ` - ..,,,　＿　_,.r'ﾞ
　　　　　　　　　　　　　　　　　　`' - .,,_　　　　　　 _,. - ''"
　　　　　　　　　　　　　　　　　　　　　　｀"'' '' '' ""

そもそも>>292の図はCore 2とかわってないんだが。
Nehalemのブロック図がでたときに一応比較確認したから。
それでおれは>>292はスルーしてたわけ。
http://www.intel.com/design/processor/manuals/248966.pdf
この37ページをみれば、シャッフルユニットはもとから2つあるのさ。

ポートじゃないや実行ユニット。

pshuf* shufp*が発行できるユニットは1基から2基に増えた

まちがいw
実行ユニットじゃなくてポートは2つある。

よくよむと、PenrynのPort0とPort5のQW Shuffleは、ポートは別だけど実行ユニットが共通っていう
変態実装らしいな。Nehalemのはマニュアルが更新されるまで本当のところどうかわからない。
マジで2つに増えたのかも。

> よくよむと、PenrynのPort0とPort5のQW Shuffleは、ポートは別だけど実行ユニットが共通っていう
> 変態実装らしいな。

んぁ？どこに書いてあるんだそんなアホな間違いは
Port0で発行できる？
ならPort 5でしか実行できないスループット1の何からの命令とpshufbでもインターリーブして実行してみろよ。
よくそんな5分で検証可能な間違いを検証もせずに書けるもんだな。

スループットが0.5だと、シャッフル命令を並列発行可能なユニットが少なくとも2基あるのは確定だ。ｊｋ
あとはユニットが倍速って可能性もあるかもな。

> Port 5でしか実行できないスループット1の何からの命令
ま、これでSuper Shuffle Engineが絡まなそうなのはjmp/jccくらいしかないんだけどな。
jmpやjccが演算ポートが重複しない限り他の命令と並列実行できるのは
大原ちゃんだって何度も検証してるくらい、このスレでは常識だし何の問題もないな。

結論から言うとjmp/jccはPort 0/1で発行可能な加算や乗算とは同時実行可能だが
シャッフルが絡む命令だけは絶対に同時実行不可能だ。
ったく、最初から最後まで馬鹿を晒すしか能がないな。

で、だ。

NehalemがCore MAのパイプラインの拡張であることを前提として、
2個目のPacked Shuffleユニットが追加されたのは間違いなく【Dividerと同じく】Port 0。
2回のシャッフルと1回のSADのマイクロオペレーションで構成されるMPSADBWのスループットが1になるには、
Port 0とPort 5の両方でシャッフル命令が発行可能である必要がある。
また、PHADD*/PHSUB*はShuffle×2＋Add×1の計3μOPsだが、AddもPort0とPort5でしか発行出来ないので
スループット1.5。計測と一致するだろ？

これがもしPort0でなくてPort1だとMPSADBWのスループットが1.5、PHADD*が1になる。
もちろん0と1の両方つまり全ALUポートで発行だとshuffle系命令のスループットはほぼ全て0.33になる。

馬鹿だな団子は。
どこまでも馬鹿なやつだ。
すぐしたに書いてあるだろう。
QW shuffleはPort0,5で扱えるが、
処理するのはPort5にぶら下がってる128bit shufflerって。
それで2つ分って意味。
自分のしっていることが全てだと思っているから、
こんな初歩的なところで誤解したまま能書きをたれるだけのクズになってしまう。
それでだまされる連中が多いってのも問題だが。

＞QW shuffleはPort0,5で扱えるが、
無理

> QW shuffleはPort0,5で扱えるが、
ソース出せソースｗｗｗ

せっかくPort 5でしか発行出来ないことを証明する方法提示してやったのに
アホ晒せよ

>>401の34ページにかいてあるよ。

マニュアルではPort1だけどね。
Port1とPort5から受け入れて、実際に処理するのはPort5の128bitのshuffleユニット。
そう書いてある。団子の計測結果の誤解釈ではなくマニュアルにねw

[QW shuffle]


この言い回しがアホ臭いんだよね
そもそもQWは64ビットなのか？128bitなのか？
x86の世界ではWord＝16ビットだが。

34ページじゃなくて37ページだな。

また例によってマニュアルの誤読のようだな。

あほらしい
恥の上塗り

64bitに決まってるだろw
いい加減に間違いを訂正して謝罪しろよw

ああようやく意味がわかった
QW＝汎用レジスタ用≠非SIMD

なにがPort5で処理されるだ？
あほくさ

>>418
3. Uses 128-bit shuffle unit in port 5.

確かにAgnerとIntelの資料だとport1と0が入れ替わってるな
まあ記号でしかないのでどうでもいいが。
FPmul側とFPadd側で通じるし


Packed ShuffleでないInteger ShuffleはBSWAPとかで使われるんだよ。
で、Port5で処理されるなんてどこに書いてあった？脳内？

見事に団子さんが一番脳内アーキテクチャでしかないことが発覚してしまったな。

みたところスケジューラをいじらずに、Super Shuffle Engineを実装するため、
Meromからの使用ポートはそのままで、128bit Unitを使うようにしたっぽい。

>>419
QW Shuffle（笑）を使う唯一？の命令であるBSWAPは
元々2μOps発行でPort5に発行される。
Agnerのp30でも嫁

別に2つのポートから1つのユニットを共有してるわけではない

関係ないけどAgnerだって計測結果からの考察をしているだけで、
予想にすぎないということはお忘れなく。
具体的にどんな実装かはIntelの中の人でなければ正確なところはわからない。

大丈夫、お前の妄想通りのこれだけは絶対ないから

Port 0 　　　　　　　　　Port5
+→ 128-bit Shuffle←+

で、団子はマニュアル読んだことあるのかな?

μOPs数なんてRDPMCでカウント出来るの知ってるよね？
ちなみにIntelのマニュアルは結構誤植多いよ

AVXのリファレンスなんて数カ所間違い指摘してやったよ。

>>426
お前の脳内マニュアルなら無い

ちなみにマニュアルにはPort1とPort5がQW shuffleに割り当てられていて、
Penrynでは注意書きの3でport 5の128bitユニットを使用するとかかれています。
以上

それを曲解してこうなってると勘違いしたのか。馬鹿丸出しだな

Port 0 　　　　　　　　　Port5
　+→ 128-bit Shuffle←+

煽りすぎ荒らしすぎ

自分に自信があるならどんと構えてろよ団子

レスはなるべくまとめろ
レス番つけるのも基本

Agnerをして「嘘が書いてある」と評したIntelの最適化マニュアルがソース
検証無し

仕事になりませんな

いさぎ悪いですよ。黙って今日はねる。
そして明日から別のネタで書け。

CPUのパフォーマンスんカウンターの使い方、どこかに解説ない?
とくにWindowsのユーザーモードから触りたい。

AVXのマニュアルなんてまだ実装した処理系がないのに2回も改訂されてるんだぜ。
マニュアルよりもIntrinsic Guideの間違いのほうが酷かったな。
今のは直ってるが8月くらいに落としたときには平気で、存在しないニーモニックが俺が見つけた限り5つくらいは記述されてた。
その程度の品質だ。察しろよ。

誤植を誤植と見抜ける人でないと（Intelのマニュアルを正しく読むのは）難しい

いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い

フェンス語録に追加だなこれ

IJKKにでも入社すればいいのに。

誤植呼ばわりでごまかしか。
結局団子の語る計測万能論なんて机上の空論の人たちの考えと何も変わってないわけで。
むしろ恣意的にそれっぽいデータを並べてくるあたり、信用できないやつがやると
たちが悪い。

団子さんの脳内アーキテクチャではすごいことになっていることが証明されたな

実験するだけの能力もないフェンス級のｳﾞｧｶ机上論者が論拠として使うには
品質が悪いよ、少なくとも

品質の問題じゃなくて解釈の問題だけどな。
こうなってるなんてどこにも書いてない

Port1 　　　　　　　　　Port5
　+→ 128-bit Shuffle←+

「潔い」で1語

イサギって何だよ。

日本語もできないんだな

実験者の能力が低いと実験してもろくな結果が得られないのは
どこの世界でも同じだな。実験でわかることととわからないことの線引きができてないやつが
計測結果から導き出したと称して、関係のないことまで妄想で語りだすというのが某さんの実態なんです。
まあ、そろそろスレの無駄だからやめようよ。

実験する能力もなくて脳内アーキテクチャを語る
それが「フェンス」くん

イサギ悪いぞ
　

そもそもここは「計測スレ」ですよ
まずIntelのマニュアルに誤植があったり不完全な記述があることから
自分たちで補完しようという意図があって成り立ってます。

計測をせずマニュアルを鵜呑みにするスレではありません。
フェンス君は未来永劫蚊帳の外

自ら本丸乗り込んでやればいいじゃないか。

>>447
その割にはAgnerとかIntelの資料好きだな。
詭弁はよそうぜ。もちろん完璧な計測データを羅列して、
こうこうこうだ、だからIntelの資料は間違っている。
と、説明できれば誰も文句はない。それが本来の計測というものだ。

Agnerは計測してるじゃん
当然ながら俺は自分である程度正当性は検証してるよ。その上で使えるって言ってる。

AgnerがPenrynのDIV/IDIVのスループット欄空白にした理由わかる？
俺はわかった
イサギ悪いお前には死んでもわからないだろうけどな

イサギw

胃詐欺悪い

ダンゴさんのsage連打で分が悪くなったことが証明されたな

じゃあ計測によってbswap等のスカラなシャッフル命令がAgnerさんの示すとおり
Port5を経由した2ポート発行であることの裏付けでもやろうか
命令を繰り返し実行しRDTSCでスループットを計測することでわかる

1. and/or/xorなどの最大3命令同時発行可能な命令のうち1命令とは並列実行できるが
2命令以上だと並列実行できない(スループット低下)。
2μops発行＆2ポート占有は確定。

2.
bswap eax
jmp dmy1
dmy1:
bswap edx
jmp dmy2
dmy2:
：

のようにbswapとjmpを交互に並べたシーケンスを実行し、かかったクロックを数えると
jmp単体/bswap単体のスループットの半分まで落ち込む。
どうやらbswapの使用するポートはjmp命令を発行できるポート(port5)と
競合しているらしいことがわかる。
（逆にaddpsなどはbswapと並列実行できる）

Agnerの資料は矛盾しないし、シャッフルユニットを２つのポートで共有してるという仮説は不成立。

てかIntelの資料自体が悪いんじゃなくて解釈がデムパなだけ。
マイクロオペレーションをport5に発行するって意味で考えてれば良かった。

イサギ悪いフェンス馬鹿は、マニュアルに書いてないことは信用しないらしいから無意味だよ。
たぶん三平方の定理も教科書に書いてあるから正しいんだと思うよｗｗｗｗｗ
円周率も3と書いてあれば3。円周は正六角形の外周さ。

彼の辞書にreductionとかexperimentの文字はない。

よし、俺がジャッジしてやる。

団子と、それと対立している二者、それぞれ計測のためのプログラムを作成せよ。
公平を期するために、パスワード付きのZIPでupし、両者がupした後に、パスワードを公開せよ。

それを実際に実機で実行してみて、判定しようじゃないか。

二人でオープンソースなx86 cpuエミュレータ作成して意見が割れた所だけbranch切ればおk。

イサギ＝フェンス氏はCore2実機どころかAtomすら買えない貧乏人なので勝負以前の問題でし

「こう書いてあるからこうに違いない」
なんら裏付けはありません。
「仕様書にはこう書いてあるから」の一転張りで通します。
解釈の間違いはあっても認めてはいけません。自分の思いこみはあらゆる実験を超越した絶対の真理です。
もし矛盾点を指摘されれば「Intelが公開してない情報なのでわかるはずがない」で逃げる。
これであなたも今日からイサギ君。

団子君、いい加減いざぎ悪いよ。
まだやってんのかよって。

イサギいぇーいいぇーい♪

最近せっかくあるスレで団子が大人しくなったと思ったら
また別のスレに顔出してて正直荒れないかヒヤヒヤしてる。

団子君、いい加減いざぎおいしいよ。

さては子鮒釣り師だな？！

あげて煽る方が悪い
これが俺のジャスティス

×子鮒
○伊佐木

なんだこのスレ
おもしれえ

ダンゴさんの本拠地はゲハ板じゃないのか

ああ、遂にあっちのスレでもウザくなってきた。
人の優位に立った気になって自慢するってどこの厨房だよ。

実際厨房なんだから仕方ない


とは言えウザイけど

馬鹿発言連発で笑えるだけまだ救いがある

笑えるか？アレ

諫木悪いくんは頭の角をフェンス（笑）にぶつけて氏ね

ちょっとスレ違いだけどWindows7発売にするなら64bitを標準にしてくれよー
32bitのメモリ空間じゃもう狭すぎるだろ

Core i7搭載PCはもうDellやショップブランドのBTOで購入できるけどメモリ6GB Vista x64が標準だよ。
でも、一方でミッドレンジはデュアルチャネルで2GB×2で実効3GBでしばらく粘りそうな。

一方ではミッドレンジ以下はNehalemでもデュアルチャンネルだから4GBまで→32ビットで十分
って流れにもってかれそうな気もせんでもない。

問題はBuffaloやIODATAあたりが64ビット用ドライバ開発やる気無いことだ。

特にBuffalo64bit版ドライバ作らないからVistaのロゴ認証受けられない
→勝手にVistaのロゴでっちあげて「Vista対応」をうたう暴挙

いいかげんにしる

個人的にはAVXが境目かなと思ってる

>>475
その手の会社って、社内で開発してないからね。
他所に作らせているので、既存のものを64bit対応させようにも、ドライバのソースコードにアクセスできない。

もう一つ64bit対応したくなり理由が、
64bitアドレッシングに対応していないデバイスにはバウンスバッファが必要なこと。

PCIバス自体は32ビットバスでも、
オプションのDAC(dual address cycleの略だったかな)によって
64bitアドレッシングが可能なのだけれども、デバイスが実装してなかったり。

そんな大それた理由ではなく、単にやる気がないだけの予感。
OEM元のリファレンスドライバには64bit版がきっとあったはず。
海外での64bit普及率を考えれば無い方がおかしい。

今時DAC未サポートのデバイスなんて少ないからね。

32bit版のドライバすら未署名だし。
「警告出るけど飛ばしてください」

Vista x64は未署名のドライバはそもそも弾かれます。
個人開発者ですら年間3万程度でドライバに署名を入れることは可能。
企業にできないわけがないんだけどね。

残念ながら、団子に同意。
マニュアルに「警告を無視しろ」なんて書くのは恥だと思わないもんかねぇ。
まるでVeriSignが期限切れになっている某通販サイトのようだ。

未署名ドライバが必要な売り物ってのはどうかと思うが、未署名ドライバを
強制的に制限しているMSもどうかと思う。俺が買ったOSで俺が書いたドライバを
F8無しでロードできないってふざけるなよ。

MSからよくOSを買えたな
俺は貧乏だから使用権のライセンスくらいしか買えねえや

団子さんの自演でスレに火が灯ったな

エロデータが外注丸投げをしているのは、事実。
Vistaの署名云々は、著作権保護がどうのこうのという理由からのモノだった気がするする。

>>478
64bitに対応しなくても売れるうちは、対応しないと思う。
過去の製品のドライバをアップデートするなんて無償サービスも、やらないっしょ。

競合他社が64bit対応で将来も安心とか差別化をはかってきたら追従するだろうが、
64bit対応しないでどこまで行けるかチキンレースしているような状況。

>>481
ユーザもまた、警告を無視するのに慣れてるから。
セキュリティを外すことに抵抗感ない人が多すぎる。
セキュリティを守ろうとすると、できるのにやろうとしない怠け者扱いされるし。

>>482
>>485
ドライバに電子署名が必要な2つの側面
1つは、ウィルス等の悪意あるプログラムへの対策。ドライバにはセキュリティが及ばないからね。
もう1つは、著作権保護のため。ちゃんと約束を守るドライバにしかデータにアクセスさせたくない。

そのうち、DRMで保護されているコンテンツを再生する場合には、
マイクロソフトがソースレビューしたドライバしかロードできません、
ってことになったりして。

まあ、未署名のドライバを使っているような糞製品は、俺は、買わないのでどうでもいいんだが。

VeriSignみたいな信頼すべきできない外道企業が認証局なのが気に入らない
いつSite Finderみたいな阿呆な事をやるかわかったものではない

VeriSign一択ではないだろ。

Windows上でCPUのCR4レジスタのPCEを1にセットしたら、
ユーザーモードのプログラムでCPUのパフォーマンスカウンタをいじることができるの?

>>490
can NOT.

できないのか、残念。

設定するためのRDMSR & WRMSR に特権モード(リング0)が必要。
カウンタの値を読むだけなら PCE=1 の場合、RDPMC が許可。
カウンタの設定とPCE=1にする、適当なドライバをでっちあげたらいいのか?

----
あー、俺ってバカ。
dd 0fh
dd 31h
とか書いてやんの。
しかも間違いに辿り着くまで1時間も関係ないところを確認してた。

O腹のかいしんのいちげきは無視かよ!
http://journal.mycom.co.jp/special/2008/nehalem02/
ああ、貧乏人はCore i7を買えないんですね?

# 本人乙の予感

イサギ悪いので嫌いです

>>493
そう、あなたは馬鹿です。

>>494
> 実行ユニットが5つから6つに増設された
この一文で、読む価値がないと判断した

あのページ数であの糞重いサイトは苦痛

コレ大原さん？
http://sylphys.ddo.jp/upld2nd/pc3/src/1228734885124.jpg

Oの人は文面からintel嫌いを臭わせる才能だけ褒めてあげたい。

低脳コテの執念深ささえあればあるいは

大原君へ
http://journal.mycom.co.jp/photo/special/2008/nehalem02/images/graph021l.gif
これ小命令でのループ時に誤動作の可能性を考慮した対策結果だろ・・・
その為、Util29.exeも検証用ソフトとしては役に立っていない・・・
http://journal.mycom.co.jp/photo/special/2008/nehalem02/images/graph020l.gif

大原君はもっとちゃんと情報を収集したほうがいいと思うんだよ、妄想が君をダメにしている・・・

>>494
このCore i7のRMMAの結果は変な結果が多いけど、
Turbo Modeのせいで正しく計測できてないんじゃないの？
計測値を24/26倍すると、まともな値になるものが多い。

>>494
大原さんはデタラメなのでスルー。

大原さん、Xeonをファンレスで動かして
熱暴走する
っていう苦言を呈すのは勘弁してください。

なんか、CPUのパフォーマンスカウンタをユーザーモードから使えるようにしよう、っていう動きがあるみたいね。

OSがコンテキストスイッチするときにカウンタの値も退避・復帰させることで、
システム全体ではなくスレッドごとにカウントできるようになるとか。

RDPMCのことだね？

有志開発者が動いてもIntelが動いてないんですが。。。。

ttp://developer.amd.com/cpu/LWP/Pages/default.aspx
これか。

http://openlibsys.org/index-ja.html
逆の発想で任意のアプリから特権モードを使えるようにしてしまえってソフトならある。

＃MSからBAN喰らわないか心配

ttp://crystaldew.info/2008/09/29/digital-sign/
>Windows 7 では動作しないというレポートも受けています

とりあえず落としとくわ

>>509
ドライバ作ってそこでPMCを設定するってなのは既に誰かやってるだろう。
問題は、PMCはシステム全体で1つだってこと。

AMDのCodeAnalyst(無料)を使ってみればわかるけれども、
けっこうエゲツナイ。

codeanalystってoprofileとほぼ同じになったの?ぃぬx版だけ?
スレッド毎って別に既にあるプロファイラはやってる、、、よね?
あとpmcは複数あるシステムもあるらしいよ。

資源としてどう提供されうるかの枠組みは個々あると思うけど、
枠組み自体をcpuが提供してしまおうってのは仮想化の流れかね。

CPUのコアごとにあるな。
スレッドごとに統計を出すのは、えげつない方法で実現している。よろしくない。

そこらへん綺麗にならないかなぁ

どうせx86はマイクロコードを使うのだから、コンテキストの退避・復帰を専用命令で行うようにしたらいいんだよ。
そしたらCPU作るほうは、自由にコンテキストを増減できるっしょ。

だから、それがXSAVE/XRSTORなんだが

しかし、なんでそいつはPMCをやってくれないのだ・・・

MSRとして、実装したから。

ダンゴさんがアゲはじめたな

ハイハイいさぎ悪いいさぎ悪い

きもい

最適化マニュアル更新
ttp://download.intel.com/design/processor/manuals/248966.pdf
NehalemとAtom追加

さーて、久々にイサギことおれの登場ですよ。
>>454君、計測ご苦労。
だが、その計測結果はおれが主張していることと全く矛盾しませんよ。
port1でuopを受け入れport5の128bit shuffle unitで処理する。
Penrynでは65nm Core 2との互換性のため、このような実装になっていると思われる。
内部的にはport1とport5をbusy状態にするため、
プログラマからみるとあたかもuopを2つのportにディスパッチしているのと同じような動作にみえる。
Intelの資料には、Penryn限定で、128bit shuffle unitを使用するとはっきりかかれており、
計測結果と矛盾せず、2portを使用するところまではわかるが、
残念ながらどこにも2uopを発行するとはかかれていません。

RDPMCで噛ませたμOPs数取れるのも知らないらしいなロートルはﾌﾟｯ

伊佐木悪いスレ

脳がいさぎたないコテ

いさぎもい池沼コテのせいで過疎ったな

人生いさぎ過ぎたスレだなぁ

Core i7 920
vender:GenuineIntel CPUID:6A4
x87 SSE SSE2
2.9 2.9 2.9 clk : 正規化数 + 正規化数 = 正規化数
4.8 3.8 4.8 clk : 正規化数 * 正規化数 = 正規化数
21.0 13.3 21.0 clk : 正規化数 / 正規化数 = 正規化数
239.4 2.9 2.9 clk : 非数 + 正規化数 = 非数
241.3 3.8 4.8 clk : 非数 * 正規化数 = 非数
243.2 6.7 6.7 clk : 非数 / 正規化数 = 非数
251.7 2.9 2.9 clk : 非数 + 非数 = 非数
253.6 3.8 4.8 clk : 非数 * 非数 = 非数
256.6 6.7 6.7 clk : 非数 / 非数 = 非数
248.9 161.4 161.2 clk : 正規化数 + 非正規化数 = 正規化数
456.6 161.4 161.4 clk : 非正規化数 + 非正規化数 = 非正規化数
460.2 162.1 163.4 clk : 非正規化数 * 正規化数 = 非正規化数
491.7 171.0 178.6 clk : 非正規化数 / 正規化数 = 非正規化数
234.6 2.9 2.9 clk : +∞ + 正規化数 = +∞
232.6 3.8 4.8 clk : +∞ * 正規化数 = +∞
239.4 6.7 6.7 clk : +∞ / 正規化数 = +∞
234.6 2.9 2.9 clk : +∞ + +∞ = +∞
232.6 3.8 4.8 clk : +∞ * +∞ = +∞

>>520を見て、Atomの結果貼っておくか、と思ってテンプレ見ようと思ったら、
見逃してた>6あたりを見てこれはひどいと思いました。今更だけど見逃してたわ。
わかってる人はわかってることだけど、*((void*)p + x* sizeof(int))なんてｘ86にとっちゃなんでもないです。

sizeof (__m128i)とかになっちゃうと困るんだけど。
AVXの予約ビットいっぱいあるんだから、Scaleフィールドの拡張して欲しいんだよね。
1ビット使えばx16, x32, x64, x128くらいまで使える。

というわけで、軽作業用のN270＠1.6GHz

vender:GenuineIntel CPUID:6C2
x87 SSE SSE2
5.2 5.2 5.2 clk : 正規化数 + 正規化数 = 正規化数
5.3 4.1 5.3 clk : 正規化数 * 正規化数 = 正規化数
60.9 32.5 61.5 clk : 正規化数 / 正規化数 = 正規化数
401.8 5.3 5.2 clk : 非数 + 正規化数 = 非数
391.1 4.0 5.2 clk : 非数 * 正規化数 = 非数
406.4 16.6 17.0 clk : 非数 / 正規化数 = 非数
424.8 5.2 5.1 clk : 非数 + 非数 = 非数
423.5 4.0 5.2 clk : 非数 * 非数 = 非数
436.6 17.1 16.6 clk : 非数 / 非数 = 非数
456.6 245.0 205.4 clk : 正規化数 + 非正規化数 = 正規化数
769.2 199.4 205.4 clk : 非正規化数 + 非正規化数 = 非正規化数
773.3 199.3 205.4 clk : 非正規化数 * 正規化数 = 非正規化数
856.9 281.4 314.6 clk : 非正規化数 / 正規化数 = 非正規化数
404.0 5.2 5.2 clk : +∞ + 正規化数 = +∞
386.1 4.1 5.3 clk : +∞ * 正規化数 = +∞
426.4 17.1 16.8 clk : +∞ / 正規化数 = +∞
408.0 5.2 5.1 clk : +∞ + +∞ = +∞
387.6 4.0 5.3 clk : +∞ * +∞ = +∞

530の間違い

> *((void*)p + x* sizeof(int))なんてｘ86にとっちゃなんでもないです。

この計算毎回やると思うなんてどうかしてる

VCの場合はどっちかというとこんな感じに勝手に展開するわけだが。
今は違うかもしれない。

int i = count
char * base = (char*)p;
int offset = 0;
do {
　　　sum += *((int*)(base + offset);
　　　offset += 4;
} while (--count > 0);

ためしたら以下相当になってた(vs2008,/O2)

int sum1=0; sum2=0; tmp=0;
int i;
int g = count - 1;
for ( i = 0 ; i < g ; i += 2 ) {
　sum1 += p[i*2];　　☆
　sum2 += p[i*2+1];　☆
}
if ( i < count ) {
　tmp = p[i*2];
}
return sum1 + sum2 + tmp;

☆ではleaで*4やってたぞ

関係ないけど、今って途中でpush/popやるんだねえ
あ、こっちのほうがスレ的には関係あるか

そのあたりが、RISCより速い理由?

とりわけメモリロードを繰り返すプログラムは強いと思う。
ベースアドレス＋オフセット＊スケーリング＋32ビットまでの即値、なんて複雑なアドレッシングを1命令でこなせる。

かつてRISCと呼ばれたアーキテクチャなんて今は産廃みたいなもんだよ。
抽象化しにくいハードウェア機能をISAに組み込んでしまったために
モダンな実装方法を適用することが困難になったんだ。
MIPSやSPARCはディレイスロットだのレジスタウィンドウだの、リソースに余裕が出来たときに
性能を引き上げる上で邪魔になるような、アホな機能を組み込んでしまった。
所詮は1個のCPUに何億トランジスタなんて時代がくるなんて思ってなかった時代の産物だ。

x86は命令セット上そんな厄介なものないから内部的にモダンなテクニックを使っても
ソフト側からは透過的に使える。
しかしx86が勝ち残ったのもIntelとしても予定外のこと。
i960とか今で言うItaniumとかに莫大なリソース割いてたのは知ってるだろ。
市場が求めるからx86作ってきただけで、中の人は本音は嫌いだったんだよ。

「俺らのCPUって案外いけてるんじゃね？」と思ってモバイルやGPU市場に殴りこみかけてるのが
今の状態。

> 1命令でこなせる。
今やその1命令が複雑すぎるからAVXが待たれているわけだが。
結局RISCが悪いんじゃなくてIntelの諦めない最適化努力が偉かっただけ。
それも資本にものを言わせて出来たわけだけどな。

その資本は、x86プロセッサを売った利益から得ているわけで、悪いことじゃないよな。

Intelの脱x86は
432
860
Itanium

他にもあったかな?

>>537
960は違うだろ。

は？AVXのメモリアドレッシングってx86そのまんまだけど？命令フォーマットのマニュアル読んだことあるのアンタ？
プリフィクスバイトからOpcodeまでの長さが固定化されるからデコーダにやさしいわけであって
アドレッシングモードは

メモリアドレッシングの整理はMMXの段階で終わってる。
dispを8bitか32bitまで、immは8ビットに仕様を固定化することでデコード負荷がかからないようにした。
AVXがやるのは、プリフィクスバイトの整理と、レジスタオペランドの拡張。
メモリアドレッシングは10年以上前にとっくに終わってる。


ちなみにModRM, SIBがそれぞれ1バイトですむのは8本＝3ビット分のレジスタしか用意しなかったから。
大半のRISCは、命令長が固定で、オペランドサイズの制約で複雑なアドレッシングモードを持つことができなかった。

>>539
確かに960はまあまあ成功したようだね。
後のPentium Proを作ったオレゴンチームである。

AVXってダサくね?
命令が1バイト短くなるかどうか、ちょっとデコードがシンプルになるだけじゃん。
良く使う命令が長ったらしくて、使わない命令が1バイトなのは、どうかしてるぜ。

960は成功したけど、DECからStrongARMを取得したので、いらない子になっちゃった。

UNIXワークステーション向け汎用プロセッサとして860と960がインテル社内で競合して、
860が勝ったというのは、どういうことなんだろうね。960では他のプロセッサに勝てないと
思ったのかな。

>>542
その「使わない命令」（LDS, LES）のOpcode空間を整理したんじゃん。
先頭バイトのC4, C5をスキャンしただけでModRMの位置を推定できる。
もしLDS, LESが現役でバリバリ使われてる命令ならプリデコードのたびにストールしまくるよ。

>>540
ホント人を見下すのが好きだな。
俺はあんたが言っている以上の事は言ってないんだが。

まあ諦めない努力だけで報われるならIA64はあんな惨状になってねーしなぁ
AMDがx86-64を出してこなきゃIntelはPentium シリーズの後継はItaniumにする予定だった。

>>544
それでも長いじゃん。

ぶっちゃけAMDが悪いんだけどさ、
命令の使用頻度に応じた命令長割り当てを、真っ新からやり直すべきだったのよ。
最初のうちはデコーダが2つになってアレだが、長い目でみれば、そのほうが良いのよ。
どうせ、最初は64bitのコードを速く実行する必要なかったんだしさ。

>>546
え?

Pentium4に作り込まれてdisableにされていたYamhil(だっけ?)はIA-64でもない別の64bit拡張だったらしいぞ。

IA64命令セットって全然コンパクトじゃないよ。
3命令分で16byte。Itanium 2は2バンドルだから32byte/clkの命令帯域だ。
その上でNOPだらけという悲しい罠。
片やCore 2は16byte/clkの命令フェッチ帯域で4issueやってるわけで。


＃レジスタ本数なんて性能の本質じゃないことはCellで遊んでみて悟ったよ。

AMDは切り替えたくてたまらなかったろう。
でもアグレッシブな事やるとIntelがついてこないから3D Now!とかAMD64とかSSE5とかで歩み寄る。

そうするとIntelの尻に火が付くからIntelがアグレッシブな事をやって、結果AMDは置いて行かれる。

>>549
そうね。
hello, world
で、100KBくらいあってビビったような記憶が微かにある。

そーか？
IntelはAMDとMSに感謝してもいいぐらいだと思ってる。
使用頻度で最適化とかいっても、
移行し終わったころには陳腐化してるかもしれんし。

>>548
それもAMDのx86-64つぶしのために仕方なく用意したものらしいよ
AMDがx86-64のドラフトを公表した時点ではYamhillなんざ影も形もなくて
当時のアスキーにはIA64 VS AMD x86-64なんてことが書かれてた。

Itanium（Merced）の32ビット(x86)コードの性能が悪くて、64ビットもそんなに性能よくないことは
当のIntelが認識してたから、x86そのものの64ビット拡張が出されるといろいろ都合が悪い。
Yamhillの命令セット仕様を公開してこなかった時点で、IA64を後継と位置づけてたのは明らか。
Yamhillはレジスタ拡張もない素のx86のアドレス拡張そのものだったという話がある。
「EM64T」 という名称にはただのメモリアドレス拡張技術であって、IA64ではない
まがいものの64ビットですよと、自分自身でネガキャンする意味合いがあった。

「Intel 64」に名称変更したあたりで何かしら方針に変化があったに違いない。
eのずれたInteｌの伝統的ロゴマークを刷新したのもこのへんだったよな。

あんまし名前に意味はないと思うなあ。
すぐAdvancedとか付けたがる会社だし、Core (1)とかSSSE3とかもうネーミングが完全にマーケティングの道具でしかない。

単に顧客からしたら「EM64T」ってのが意味不明すぎるのとAMD64って呼ばせたくないだけでしょ。

>>554
Itaniumを「IA-64」ではなくて「IPF」と表記するようになったのもあのへんからだよ。
IntelはもちろんIntelの提灯持ちライターの筆頭の元麻布の記事にも表記の変化が見られる。

だんごサンはIA-64いじってるの?

個人的には、そんなにnop入ってないって印象よ。
もちろん最適化を切ったデバッグ用のビルドは別ね。

HP-UX向けの仕事したことがあったかな。
コンパイラはIntelのもMSも（ともにWindows用）も使ったことがある。

印象としてプレディケートで分岐を減らしてるのはわかるが本物の分岐には弱い感じ。
あと、キャッシュあんだけ積むだけの余裕あるならアウトオブオーダやってもいいだろと

なるほど。

コードによっては、そうなるよね。
というか、そうならないほうが珍しいか。

アウトオブオーダやったら、EPICの自己否定にならないかな?
投機実行はコンパイラのお仕事、なのだから。

パイプラインのステージ数や実行ユニットなどが変ったら、
アウトオブオーダやらないと、古いプロセッサ向けにコンパイルされたものは、スムーズに流れなくなるか。

分岐の少ない直線的なコードならItaniumにも生きる道があるだろ？って思ったんだよね
でもそれこそPentium 4で十分やん的な。

人づての話だけど
大学の研究室にItanium2とPentium 4(Xeonだったかも?)があって
簡単なFFTですら、倍以上のクロックで動くPentium 4のほうが速かっただとか

あと、レジスタが多い分コンテクストスイッチに時間がかかりすぎるとか
（このへんがHyper-Threadingの導入のきっかけにもなった）


今のXeonは1コアで128ビットSIMD算術論理演算を、3命令同時発行とかできるから
最大2バンドル6命令同時発行の威光も、同クロックですら完全に霞んでる。

そしてXeonより上の信頼性が要求される用途でも、
CPU自体のRAS等の機能の充実によるメリットより、
複雑がゆえにバグが出やすいことのデメリットのほうが大きい。

いや、CPUの回路はシンプルかもしれない
(そのわりにはステッピングが異様にあるし、ハングするバグで全部交換なんて話もあった)
でも、それを正しく動作させるためのソフトが複雑怪奇すぎる。

何に向かって吠えてるの？

>>540
誰もメモリアドレッシングに限定した話なんかしてないのでは？

>>549
だれもIA64命令セットがコンパクトなんて話はしてないのでは？

突然関係ないこといってごまかすこと多いよね。この人。

AMD64は命令が長くなる!
AVXを使ってもあまり短くならない!
いったんキレイサッパリ仕切りなおせばいい!
そうやって仕切り直したIA-64は命令が長いぞ!

IA64を作った頃にはAMD64もAVXも無かったと思うんだ。
そしてAVXに関しては>>544の通り、大きな恩恵がある。

>>542
なんというCISC脳！

どうせAVXで仕切り直すならモード切替でもして、命令体系と命令長を抜本的に直しても良かったと思うけどな。

>>564
むしろRISC的アプローチだろ
命令の出現頻度に応じて命令長を決めるのは
定量的アプローチを説いた人は、ネヘパタやパタヘネのパタさんかヘネさんだぞ。

>>566
ははは。おもしろいことを言うね。

こうなったら出現頻度の統計をとってハフマンで

>>561　はぁ？

> > 1命令でこなせる。
> 今やその1命令が複雑すぎるからAVXが待たれているわけだが。

これどう考えてもAVXの技術を勘違いしてるようにしか見えないんだが。
たとえるなら月の表面構造の話の途中に、唐突にスッポンの話が割り込まれた感じ。
呆れるしかない。

複雑なアドレッシングモードとは言ったけど、一定のフォーマットどおりなら、ModRMをスキャンしただけで
SIB+DISPの有無とサイズを特定できるから可変長命令の中ではデコーダの負担が軽いんだよ。

厄介なのは16ビットDISPを含むようなレガシー命令フォーマット。
しかしIntelはレガシー命令のデコードにトランジスタを割いてない（だから古いコードだとLCPストールがおきる）。
そもそも新たに組まれたコードに古い形式の命令なんて基本的には含まれてないんだから
このへんはいまさら解決するに値しない問題。

AVXが解決するのはまったく別の問題だ。

・ModRMまでのサイズの推定をし易くする
・レガシー命令のOpcodeをオーバーライドすることでの新たなOpcode空間の確保
・第3のレジスタオペランドの追加
・256ビット、あるいはそれ以上のワイドベクトル命令の提供

AVXがコンパクトじゃないなんて誰の入れ知恵よ？
たとえばさ、PowerPCでAltiVecの256ビットとか512ビットとかのバージョンを作るにしても
4オペランド命令を廃止するという暴挙にでるか、8バイト命令の空間に割り当てるか
そのくらいしかないんだぜ
それ考えればAVXは充分コンパクトだよ。

新命令の追加は「R」ISCのフィロソフィにそもそもないんだから、破綻するのは当然だよ。
ARMもPowerPCも、もはやRISCでない別の何か。

>>566-568
80:20ルール（あるいは90:10ルール）って知ってる？

統計的に、実行時間の大部分を担う部分は、コード全体の2割にも満たず、
それ以外の部分は別に速くなっても遅くなっても大して影響ないっていう経験則なんだけど
パフォーマンス上重要でないところほど命令を短くするのは全体のコードサイズを小さくするには合理的じゃないの。
実際、ARMのThumb命令もこの経験則にしたがって「80」（あるいは90）の部分での利用が推奨されてる。

でも、逆にパフォーマンス上重要な2割未満のところで使いたい命令が、命令長が長すぎて命令フェッチが
間に合わなくなると困る。そこで、4〜5バイト＋α程度の命令長で3オペランド形式のSIMD命令が使えるように、
将来にわたって使える新たな命令セット空間を定義した、ってのがAVXだよ。
16バイトの命令フェッチ帯域あれば平均的に3命令程度は供給可能。

>>542宛が適切だったな

> AVXが解決するのはまったく別の問題だ。
昨日から引き続き、勝手に別の事を話していると思う辺りが恥ずかしいな。

> 80:20ルール（あるいは90:10ルール）って知ってる？
俺計算屋なんだけどあんまこの法則に当たった事がないんだよな。

効率の悪い書き方は初めからしないというのと
今のご時世、計算は殆どボトルネックにならないという事かも知れない。

＞今のご時世、計算は殆どボトルネックにならないという事かも知れない。
そりゃあんたがそういう計算に縁がないだけだ。

>>572
恥ずかしい子だな。
x86のメモリアドレッシングのボトルネックなんて最初から無いんだよ。
アドレス算出なんてただのシフト＋加算だよ。

俺のボトルネックは口だな。
頭の早さについていけない。

他のやつが言っていたかどうかは知らないが
メモリアドレッシングがボトルネックだなんて俺は言った事無いぞ。
団子と同じ主張しかしていない。

吃音なのか?

>>570
命令キャッシュの大きさも考えてあげてください
3命令よりも多くの命令を実行できるようになったとき16バイトの命令フェッチでは足りないことを心配してください
たとえ単純でも、やはり長くなればなるほどデコードの負荷は高まりますので。

命令キャッシュに大きさは必要ない

L2→L1I$への転送はレイテンシこそ大きいものの、帯域幅は非常に広い。
だから、1キャッシュラインごとにL1I$ミスのL2ヒットなら、さほどのペナルティにはならない。

ひとつのプロセッサに使えるトランジスタリソースが少なかった時代にはRISCはよかったんだよ。
今みたいに何億も使える時代になっちゃうと、リッチなアドレッシングモードも
複雑でもなんでもなくなる。

むしろRISCは、オペレーションの単位が細かすぎて、いくらトランジスタ注ぎ込んで
同時命令発行数を増やしたり、クロックあげたりしても、思ったように性能があげられない事態に陥ってる。
レジスタウィンドウなり遅延スロットなりを命令セットレベルで具体化してしまった
アーキテクチャはもっと悲惨で、高クロックにも高IPCにもパイプラインを抜本的に
作り変えることができなくて、性能競争から取り残された。

結局、ハードワイヤードでほとんどの命令をこなせるリッチな時代にこそ
適応できたのはx86だったという話。
1命令で扱うオペレーションを増やしたり、高級な機能を実装することで
トランジスタを有効利用するってのはVLIWにも通じる概念だが
x86の命令セットにはそういう時代に勝ち抜く素養があったってことだ。

うー、異論を挟みたいが大筋では間違ってないだけに……

今となってはSparcにはなんの存在価値も残ってないもんねぇ。

>>579
＞3命令よりも多くの命令を実行できるようになったとき

AVXの256bit SIMDはうまく考えられてて、実行ユニットは128ビットのまんまで
2つの128ビットSIMD命令を発行する。

これが何を意味するかって、実質的に2命令分を供給できるわけだ。たった4〜5バイトで。
場所に応じて128ビットSIMDと256ビットSIMDを使い分けられる。
MMXとSSE2のときにもあったけど、ポイントは、XMMとYMMの下位は128ビットは同一レジスタなので
データ交換が簡単だということ。
SIMDユニットが256ビットになったときには、今度は512ビットのSIMD演算命令を実装する。
これで延々、命令帯域を確保し続けることができる。

ちなみに、さっさと64ビットに移行すれば0F38グループも0F3Aグループも命令長を4バイトにすることが可能になるから。
AAMとかAASをオーバーライドできる。

＃0F3Aは無理か。imm8があるから6バイト→5バイトだな。

>>581
x86だと1命令でも、RISCだと複数の命令になってしまうので、
それらが依存関係を持つ1つのまとまった処理だというのを、
アウトオブオーダーのエンジンが自分で前後を見て判断しないといけないよね。

x86なら1命令なのだから、そういうことしなくても自明、と。
なんだ、x86はデコーダがネックだとかいうけど、RISCこそデコーダがネックじゃないか。

ﾋﾟｺｰﾝ（AA略）

RISC→CISCにトランスコードして実行するというのを思いついたぞ

特許書くかな

困ったことに、Atom 1.6GHz VS Cell PPE 3.2GHzですら、たいがいの処理でAtomのほうが速いんだ
同じインオーダなのに。

そりゃぁだってAtomは2スレッド×2コアだしょ?

Cell PPEは1コア・・・あれ?2スレッドだ。

だめじゃん!

あれ? PPEでクロック換算したらPen4程度の性能が出た気がしたのはなんだったんだろう。

Pentium4 < Atom ってオチじゃね？

迷走しているな。
PPEが遅いのはRISCのせいじゃないだろう。

Pen4はSIMDが半速だからものによってはそんなもんになるんじゃね？

>>592
知ってる。てかAltiVec除いてほとんどG4 1.4GHz＞PPEだったりするし。

問題はG4＞Atomにならないことだ

なんだ
マカーがあんなに誉め称えていたG4が遅いだけか。

だってモトローラだし。

>>581-582
に対してのSunスレでの反応

679 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/26(月) 22:44:09
因果が逆だな

今となってはSUNにはなんの存在価値も残ってないもんねぇ。 

こういうこと？

2000年くらいにUltraSPARC IIeのエントリマシンとか出したことあったろ？
Javaで同じプログラム動かしたら既に同クロックのCeleronにも圧倒的に負けてたという
笑い話

あれってシンクライアント用だったような。

これだこれ
http://ascii24.com/news/i/hard/article/2001/04/04/624913-000.html

ずいぶん大きいシンクライアントだなｗ

これ応用したA4ファイルサイズノートPC出してたメーカーがあって
100万くらいだったかな

どうみてもぼったくりです。本当にありがとうございました。

>>600
シンクライアントみたいなものじゃん。

どうせ実際はX端末みたいな使い方するんだろう。
ローカルではCPUパワーの必要なことはやらない、と。

「ワークステーション」のラインナップだし
http://jp.sun.com/products/desktop/ws/


なぜかCore 2だけになってしまったな。
パソコンにXeonを採用するメーカー（Apple）もあれば、
Core 2をワークステーションだと言って売るメーカーもあり。

てか、シンクライアント用途だとなおさら高コストなSPARCを選ぶ意味自体ないじゃん。
今ならARMですら十分だね。

まあよそはよそ、うちはうちでx86以外の話は終わりにしよう。

Nanoはどこそこ性能駄目っぽいね。
さすがにAtomより性能良いだろうと思ってたんだけどやっぱりどこまでもVIAだった

そうなのか。
提灯記事では、AtomよりNanoのほうがシングルスレッド性能が格段に良いような話だったが・・・orz

>>602
ワークステーションつってもさ、パワフルとは限らなよ。
データエントリー用の端末だって、ワークステーションだもの。

それにしても、ECCメモリをサポートしないのは、いただけないよ。
いまのIntelのデスクトップ向けのCPUやチップセットは。
メモリのチェックなんか時間すげーかかってやってらんないから、
壊れたら壊れたとわかるほうがいい。

>>570
命令長と命令実行時間を勘違いしているようじゃなぁ。

お前がな

だからさ、80：20ルールの80の部分でいちいちSSEなんか使わないだろ。
スカラ命令（1〜2バイトの命令）で済むならそっちのほうがいいんだよ。

AVXは長いけど長いのに合理的理由があるだろ？
拡張性、3つめのレジスタオペランド、etc・・・

CoreMAは4issueのパイプラインで、3つのSimple Decoderと1つのComplex Decorderで
実効3IPC＋αの並列度を実現してるわけだけど、デコーダに命令を供給する前段階として、
命令の切り出しがネックになる。何並列ものスキャナで血眼になって命令境界を探すわけだ。

単純な命令であれば、1クロックに最大6命令の切り出しが可能だが、
命令セット拡張のためにプリフィクスを次々と増やしていったSSEは一筋縄にはいかない。

命令を並列に供給するには命令の境界をさっさと検出しないといけない
↓
ModRMの位置さえわかればSIB/DISPの長さがわかる。imm8の有無はOpcodeを見ることでわかる。
↓
ModRMの位置はどこだ？／Opcodeの位置はどこだ？

現状のSSEでは、プリフィックスを読み飛ばしながらOpcodeの位置を探っていかないといけない。
別に【命令が長いこと】自体が問題なんじゃなくて、プリフィックスが不規則に多重に付いてて
Opcode/ModRMの位置を検出しづらいのが問題なんだよ。
命令長の問題は二の次。

AVXでは、C4あるいはC5を見ただけでOpcodeとModRMの位置を推定できる。
ペイロード領域やSIB・DISPは命令境界の検出には直接関係ないので読み飛ばして構わない。（デコーダにやらせればいい）


切り出し・プリデコードの終わった命令は別にどうってことはないよ
強引な言い方をすれば、エスケープバイトに合わせたテーブルを参照して対応するμOPに変換するだけ。

>>608
intel的にはx87 FPUは完全にステだから単なるfloat演算でもSSE使えって話だった気がするが。
そのためのSSE2だろ？

そっちか！
浮動小数オペレーションはスタック操作からレジスタ間オペレーションへ、
更に2オペランドから3オペランド、ベクタ長など、x86の変遷の中でも
もっとも1命令の意味が大きく変わってくる演算なので、サイズが
増えただの減っただの言っても一概にコード効率を論じることはできない。

というか、x86の利用シーン全体を100とした場合、浮動小数演算そのものが20側になるわけですが

>>609
> 現状のSSEでは、プリフィックスを読み飛ばしながらOpcodeの位置を探っていかないといけない。

マイクロコードで処理してるとでも? アホか。

回路の入力が増えれば増えるほど、通るゲートの数が増えるので、
トランジスタ数は食うは、遅延は大きいわで、「重い」んだよ。
決して、前からスキャンしているわけではない。

つまり回路的には128ビット(16バイト)を同時に扱うという事?

固定長ならどこからでもスキャン出来るから
完全同時にデコードできるだろうけどな。

命令が左からスキャンしないと解読できないアーキテクチャなんだから
限りなく団子の言うのに近い状態になりうると思うんだけど。

>>613
実装とは違うが、概念的には、デコーダを1つのブラックボックスとして見ると、

入力、128ビット分の命令列(アライメントはキャッシュライン)、クロックのエッジで入力される
出力、デコード結果、クロックに同期して出力確定
内部に状態を保持、あり。

こんな感じ。1クロックでデコードするためには、
出力信号の1本は、入力128ビット×状態の論理演算の組み合わせで行うしかない。

行列の乗算みたいなものよ。

>>612
馬鹿だなお前は
マイクロコードも糞も無くて一種のステートマシン。
前のバイトがプリフィクスかリードバイトかOpcodeかもわからないのに何をもって
後続のバイトを判別するんだよ
前からしか評価できないだろ。

C4, C5を見ればAVXのリードバイトと見なすってのも32ビットモードでは「推定」でしかない。
第2バイトの上位2ビットが11ならAVXとみなすしそれ以外ならLES,LDSとして解釈しないといけない。
分岐を並列処理することはできるが、前後関係を無視した評価はできない。

66 66 66 66 66 66 NOPなんてのが許されるフォーマットだからたちが悪い。

前の命令の境界が判別して間違っていれば破棄すれば良いという観点からすれば投機的な並列スキャンは可能。
ただし、ものすごい負荷になるけど。

Atomの場合はプリデコード専用のステージがなくて愚直にスキャンしてマイクロコードでデコードする。
デコードが完了すると、単純な命令であればプリデコードタグを付けられる。
プリデコードタグには命令長などの情報が含まれる。
2回目以降はプリデコードタグを元に2並列のXLAT/FLによってハードワイヤードでデコードされる。

>>615
ステートマシンだと複数のクロックが必要だろ?

>>615
当該のバイトだけではなく、それより前のバイトも入力として与え、
自分で前のバイトの内容も論理演算に含めるんだよ。

だから、すんごい大変なお。

加算器を思い浮かべればいい
1クロックごとに1つ上の桁にキャリーを伝搬していく → マイクロコードに相当
キャリー先読みによってキャリーの伝搬を排除 → ハードワイヤードに相当

>>620
マイクロコードは、マイクロコードシーケンサーによって各回路に送り出されて
行くもんだと思う。

キャリー先読みしない加算器の、キャリーの伝搬とは違うと思う。

レガシーコード（16ビットDISP/IMMあり）と従来コードでアルゴリズムを切り替えてるんだから
マイクロコードベースなんじゃねーの？

>>618
逆に現実世界の実装が1〜2サイクル程度で済んでると思ってるのか？
加算機の桁上げなんてたかだか1ビットだ。バイト単位だと全然話が違う。

だからAMDはL1命令キャッシュにフェッチする段階でプリデコード処理を行ってタグを付けてしまうし
Atomも省電力性と性能の両立のために>>617のようなことをやってる。

>>622
2つの性格の異なるデコーダーを用意して、
コード種判定回路の出力に、その2つを切り替えるロジックを作れば、
別にマイクロコードで無くてもいいんじゃねーの?

実際どうなってるかは知らんけどさ。

どっちにしろAVXに完全移行してSSE*がレガシーになればプリデコーダの負担も軽くなると
考えてるんだろIntelは。

AVXマニュアルにおいてSSEをOSがトラップしてソフトエミュレーションで実行することについて言及してるのは
SSEのデコードアルゴリズムの排除を前提とした話。

>>624
そんな力技ができるならLCPストールなんておきねーよ。
どれだけペナルティあるのか計算したことあんのか？

CPUの動作速度は熱密度に制約されるからどうしても分散したい事情があるんだよ。

>>623
そういや、AMD厨はNetBurstに対して、
L1命令キャッシュがトレースキャッシュになっているからモッサリだ
とか言ってたような。

AMDが同じことをやっても、キビキビとかいう。

>>627
キビキビとか言ってる手合いはIntel叩ければダブルスタンダードでも平気なんでしょ。
信用するに値しない。

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

パイプラインの構造を考察することはクロックを知る上で重要だ。もっとやれ貴様ら。

そう言えば IEEE Spectrum の i860 の記事に
instruction decoder の state machine を人間が作れなくて
CAD の自動生成を使ったという話が無かったっけ？
ま，それほど大変だという話

関係ないけど、例え人間が作れたとしても自動生成に任せるのは正しいと思った。

人間が設計ツールを使うなんて普通の事なんだけど、それがどうかしたの?
自動配線ツールに与えるパラメーターを考えるのは人間だよ。

>>608

>>542
> 命令が1バイト短くなるかどうか、ちょっとデコードがシンプルになるだけじゃん。
> 良く使う命令が長ったらしくて、使わない命令が1バイトなのは、どうかしてるぜ。

元々命令長の話しかしてない。
にもかかわらず命令実行速度の話を延々としている団子は池沼。

結局は実行速度さえ満足な物なら命令長なんてねぇ…

>>632 >>633
時代が違う
まだ state machine の自動生成なんて最前線では使われてなかった時代

Intelは時代を先取りした、と。

>>634
はぁ？

たかだか3命令＋α程度しか並列デコードできないのに命令長がどうとか
けちくさいこと言って何になんのよ？

1命令で2μOPｓ分生成するなら、うまく使えば実質的に命令長が
減ったのと同じ効果が得られるだろ？
（それが256ビットAVX命令なんだが）

つか、SSEが頻繁に使うとか馬鹿じゃね？
整数スカラ命令を「使わない」とかｗｗｗ
配列の添字どうやって算出すんの？
分岐もやらないのかよ？

SSEなんて現実のコードではそんなに頻繁に使「え」ません。
使えるところが限られるけど

32バイトfetchにすると熱密度が（ｒｙってのはゲルたんが言ってるだろ。
Itanium 2のクロックが上げられないのも、Phenomが爆熱なのも、
みんな32バイト/clkのInst. fetchのせいだそうです。

依存関係ネックでどのみち上げられないケースが多いんだから
むやみに命令帯域増やしても意味ないってのがIntelの判断だよ。
俺に吠えて現実が変わりますか？ぁあ？

実際問題、どんなアルゴリズム使おうと、
たとえSIMDで力業で並列演算やろうがLUT使おうがソフトウェア・ステートマシンやろうが
整数演算は常に使います。

この前提がまずおかしい
> 良く使う命令が長ったらしくて、使わない命令が1バイトなのは、どうかしてるぜ。

BCDなどのレガシー命令に関しては再割り当ての過渡期なんだから
目くじらたててもしょうがないし

>>638
デコーダの回路のコスト・消費電力・局所的な発熱・伝搬遅延のボトルネック

大体に、動画エンコーダなんかに代表されるSSEを積極活用したアプリは
Hyper Threadingで性能が数割上がる、つまり命令間の依存関係や
メモリレイテンシがネックになってる罠。

命令長が長すぎて命令フェッチがネックになるなんて的外れな文句垂れてる奴は
コスト分析もできない無能

>>641
的外れだなぁ
1デコーダで2μOPs分供給できれば稼働率を半分に抑えることができる
妄想論はやめてIntelの論文でも読んでくれ

>>639
Itanium2のクロックが上げられないのは、32バイト/クロックの命令フェッチのせいなのか?
短いパイプラインと、ひたすら投機実行しては結果を捨てまくるアーキテクチャがネックだと思ってた。

乱暴に言って、必要最低限の2倍の命令を実行するっしょ?

>>640
そいや、IBMはPOWERにBCD「演算」命令を追加したな。

>>642
え?

動画エンコーダ等の、拡張命令をしっかり使い倒して
*チューニングする場合は*、Hyper Threadingは使わないほうが性能が良いぞ。

命令間の依存関係が十分な距離になるようにソフトウェアパイプライニングし、
メモリレイテンシがネックにならないように適切にプリフェッチを行う。

ゆえに、Hyper Threadingを使うと、パイプラインが乱れキャッシュが汚染され、
パフォーマンスが低下するのよ。

>>643
Intelの論文は、割り当てを真っ新からやり直すことはできない、というところからスタートしてるんじゃないか?

どこの動画エンコーダでHTが逆効果になるか教えて下さいな

>>646
知らないなら語らなくていいよ。無知蒙昧はなはだしい。
明示的なキャッシュ制御命令は程度スループット改善することはできるけど
レイテンシを埋めるには至らない。

むしろ、ライトスルー制御命令を使わないとキャッシュを取り合って性能出しにくい
逆にね。

知ったかぶりもたいがいにしろ>>646

L1とレジスタ舐め回す程度の小物ツールしか見たこと無いんだろ


ストリーミング処理のレイテンシを1スレッドだけで埋めるのはx86の少ない論理レジスタ数じゃ物理的に不可能

はいはい>>648-651まで、顔真っ赤にして4連投乙

見えない敵と戦う知ったかぶり

>>652
>>648

動画のencode云々は、algorithmにもよるから、何とも言えないね。
軽い物程、CPUの外の影響が大きくなり、このスレの趣旨からハズレる。

フィルタを重ねるほどオンキャッシュ処理の頻度は高くなるね
それでもL1外の読み書きのレイテンシを完全に隠蔽してしまえるような状況は知らない
論理レジスタ32本くらいあっても厳しいのに

マジレスするとメモリの帯域がネックになってSMTが効果ないケースはありうる。
なおさら命令供給ネックと関係ないが。

>>656
フィルタ・・・ねぇ。

フィルタを色々使うとAMDのほうが速いっていう昔の話については、
それらのフィルタの実装が悪かった、ただそれだけのことよ。

ネットでフリーで公開されてる大半のフィルタは、
処理速度を最優先したコーディングをしていない。

とにかくバグらずに目的の映像が得られれば、
ひどい非効率な処理手順でも構わない、
ないよりはマシ
というコンセプト。

それは間違ってはいないが、それをもってしてCPUを評価しちゃいかん。

>>639
>Itanium 2のクロックが上げられないのも、Phenomが爆熱なのも、
>みんな32バイト/clkのInst. fetchのせいだそうです。
現行のItanium 2のクロックが1.6GHzなのはFoxtonが失敗したせい。本来はTDP100Wで2GHzを超える予定だった。
デバッグも人員減らしでまともにされなかったね。その代わりに今のXeonの隆盛があるのだが。
2GHzでもクロックが低いということならそれは大容量かつ低レイテンシなL3キャッシュや短いパイプラインも関係しているのでは？

現実世界に存在してもいない「ぼくの考えた理想のエンコソフト」をもって
HTは遅くなるとか馬鹿なの？死ぬの？

Intel CPUにいち早く対応することを売りにしてるTMPEGEncですらアレですよ。

>>638
だからそういう「ケチ臭いこと」をいっている>>542に

>>564
> >>542
> なんというCISC脳！

とつっこんだわけだが。
意味不明な突っ込みを続けている団子は池沼

なんでAMDのCPUは熱いの?

昔も熱かったから、K8で一時期ちょっと熱くなかったのが例外なのかも。

AMDってL1ヒット時のピーク性能を極端に重視する傾向があるよね。
一方Intelは昔からL2の構成にこだわりがあるようで。

ベンチマーク対策じゃね?

>>663
ターゲットの違い

Intel → サーバーまでカバーしなきゃいけないので、大きなワーキングセットでの性能確保を重視
AMD → パソコンでの性能重視

ということかと。
パソコンのユーザに喜ばれるのは、当然、AMDのほうになるよね。

いま別に喜ばれてないけど。
逆にAMDのほうがサーバでしか生きられてなくね？

極端に一部の性能を重視して熱密度が上がってしまい、逆に平均性能を上げられないというジレンマは
IntelがPentium 4で、AMDは現役で経験している通り。

>>665
Hammerは明らかにXeonのシェア切り崩しを狙ってただろうが・・・
大黒柱はずっとOpteronだよ

AMDは今後2年間はデスクトップCPU市場見捨ててOpteronのコア数増やす方向らしいよ。

Nehalemにほぼダブルスコアで負けてるんだからコア数だけで追随しても無駄な努力
それに基本はコア数競争 = 微細化競争のバーベットゲームだし
AMDはトチ狂ったとしか思えない
最近の不況もあいまってVIAよりヤバイ状況

>>668
方向というかそれしか打つ手がないのが実情
コア改良で後れを取ってることが敗因だ

「PhenomではSSEのために命令フェッチ帯域を2倍に増やした」（AMD談）

これはこれで方針としては正しくて、AMDの場合はロードユニット2つだから
メモリ間オペレーションを同時発行する機会を増やしたほうが性能は引き出せる。
で、メモリ間オペレーションはSIB, DISP32, imm8などをフルに使えば命令長が長くなるから、
安定供給するにはフェッチ帯域を増やさないといけない。

メリット（性能）とデメリット（熱密度・消費電力）のバランスを考えてIntelは先送りしたようだ。
AMDと違ってロードユニットの本数が少ないからそっち方面に振るメリットも相対的に小さいし。
Intelは256ビットSIMD（AVX）導入で実質的な命令サイズを節約する方向に向かってる。

AMDにとっては、SSEを使う多くのアプリケーションがIntel CPU向けに最適化される現状では
どうにもならない。それで、シェア50％を狙えるだけの生産ラインを確保なんていう、
現状を省みないプランを打ち出すにいたってると（笑）

景気が冷え込んで規模縮小しないとやっていけないご時世に
Intelにマーケティング上「勝てる」アーキテクチャと、製造キャパの両方を
求めないといけないなんて大変だな。

>>671
> シェア50％を狙えるだけの生産ラインを確保
これ自体は間違っていなかった(過去形)
ただその後IntelがCoreMAを発売、それを上回る性能のCPUをAMDが用意していなかったことが敗北の要因だ
それから以降はもうグダグダでしかない

Nehalemでは、32μOPsだっけ？長い命令を使っても命令フェッチ帯域制限を掻い潜れる
ループバッファのエントリ数は。

これ結構きついんだよなぁ

>>668
どうやってコアを増やすのだろう。

ダイサイズが巨大になって歩留まりが・・・サーバ向けなら歩留まりが低くても大丈夫なのかな。
まさか、自らがマーケティングのために叩いた、複数ダイのMCMは・・・恥ずかしくて出来ないよな。
いや、恥ずかしいのはAMD厨だけで、ビジネスに徹するAMDは平然とヤルか。

AVXプログラミングリファレンス第5版出た
http://software.intel.com/file/10069

>>674
モノリシック6コアなのでダイサイズは巨大化するようだな。
あとMCMの話は2年前から出ていた。
最近の発表によるとMCMでは12コアと8コアが予定されているらしい。
12コアはそのまま6*2として8コアは (6-2)*2 かな？

もう液浸の時代かぁ。10年前には想像さえできなかったな。

GJだが直リンは遠慮しる

そもそもK8のHTは、MCMのために存在すると言っても過言ではない。
IntelのFSBも、そうだがな。

そんな主張は初めて聞いた
まあ確かにMulti-Agentが前提のFSBでBlackford(Woodcrest)みたいなPoint-to-Pointってのも不自然な気はしたが
どちらもChip-to-Chipの技術に過ぎないと思うが
あ、HyperTransportはバックプレーンとかにも使われているんだっけ

ageんか貴様ら！

死ね

落ちる

VT-xやSVMにおけるGuest-Host間の切り替え時間ってどんくらい？

>>684
vmrun-vmmcallでホストゲストを10往復させて計測してみました。
1往復あたり1000clkくらい@PhenomII
vmmcallのかわりにioインターセプトさせると、1080clkでした。

I/Oパターンによってはエミュレータの方が速そうだな

ディスクフォーマットとかデフラグがアホみたいに速い

その昔、メインメモリが1MBの時代にバンクメモリを10MBくらい使ったディスクのドライバを書いたことがある。
当時はdefragが標準ではなかったから、defrag相当も自作した。
HDDは持ってなかったから、できたバンクメモリディスクで開発していたわけだ。
そうして、電源を切るとバンクメモリは消えてなくなることを身を持って再確認した。

波のシミュレーションを書いたんだけど、
SSE2のコードがC言語比で1.2倍くらいしか速くならず、おかしいと思ったら、
扱うメモリがL2キャッシュを少しはみ出していた。
L2に収まるサイズでやり直したら、一気に3倍近い差になった。

L2に収まらない場合は、プリフェッチやmovnt系など、
まずメモリ関係をやらないと話にならないんだな。
知ってたけど久しぶりだから忘れてた。

>>688
＞当時はdefragが標準ではなかったから、defrag相当も自作した。
＞HDDは持ってなかったから、できたバンクメモリディスクで開発していたわけだ。
ををすごい、
どこがって？

>defrag相当も自作した。
>HDDは持ってなかったから
この部分に感動を覚えた

>>690
どこに感動を覚えたのかよく判らんが。
HDDを持ってないのにdefrag相当を作った辺り?
昔はフロッピーでさえfragmentの解消をしたもんさ。

フロッピーはインターリーブ考慮せんといかんな

このｽﾚ ノネナール臭が凄い……

skip sector & skew
->
track read / write + cache

先人がMMXアセンブラで作った関数のパフォーマンス改善をしています。
一部SSE化したり、アルゴリズム改善でだいたい1/2くらいまで縮まったので
AMD CodeAnalyst(Ver2.76)を使ってチューニングをしようとしているのですが勘所がわかりません。
Pipeline simulationを見ると、ピンク赤枠(SCHED FPU Scheduler ineligible)が貯まっていき
パイプラインの幅が広がってしまいるようです。
一般的な目安として、どのような部分に注目してチューニングすれば良いでしょうか?
とりあえずは、Notesに書かれた「Bank conflict」や「Stlf 31:12」などの部分を何とかしようかと思っています。

一旦Cで書き直してコンパイラに任せた方が早かったりしてね。

整数でMMXの倍出れば充分だよ

開発機のAthron64x2での評価で1/2くらいになったと言っていたんですが
実機のCore2Duoで動かしたら、元のプログラムの実行速度が上がり
相対的に2割くらいしか改善されないという情けない結果になりました。
AthronとCore2Duoの差というより、L2キャッシュの容量が512Kと2Mの差なんだと思います。
その後SSEのみで書き直し、3割改善まで進んだところで今のところギブアップです。
CodeAnalystはAMDのCPUじゃないと動かないので、V-Tune評価版で
試してみる価値があるかどうかという所です。

http://software.intel.com/en-us/articles/intel-architecture-code-analyzer/

Core 2とは特性は若干違うがこれ使ったら？

紹介ありがとうございます
試してみますね

AMD用にチューニングしたコードをIntelに持っていって
果してどのくらい意味があるのだろうか？

Intel用に最適化したのをAMD機で動かすより意味あると思うけど・・・

どっちもない。
Intelは乗算や水平加減算以外の整数命令はほぼレイテンシ1だが　
AMDのはほぼ2だから全然特性が違う。

細かいこと考えて最適化しても、
結局L2に収まるか収まらないかで全てが決まってしまう現実。

面倒だが、L2サイズを基準に処理を分割できれば
かなりのオーバーヘッドがあっても元は取れるはず。

Optimization Reference Manualの間違いなのか事実なのか知らないけど、
なんで一部のプロセッサでandpsがスループット1でとpandが0.33なんだろう。

単精度用にandpsでmmx上がりの整数用にpandってのは
命令フォーマット上は確かに一貫していて扱いやすいんだろうけれど、
たかだかビット演算で速度に違いが出てくるくらいならオペコードを複数用意しちゃいかんと思うのだが。
試してないけどコンパイラオプションでSSE2以上を指定したら
問答無用で_mm_and_ps()をpandにするくらいの責任を取って欲しい。

XMMを使用するので同じ命令に見えるかもしれないが
CPU内部では整数ドメインとFPドメインに分かれていて
それぞれに作用する命令なんだ

異なるドメイン間でデータのやり取りが発生すると
ペナルティーを受けるから、命令は扱うデータに
合わせるべきだね

ちなみにSandy Bridgeでは{and,andn,or,xor}psを発行出来る演算ユニットだけが256ビット化される。
ビット論理演算のスループットはNehalemの1.33倍！

そして、Macro Ops Fusionが熱い！ヤバイ！間違いない！
dec + jccとか and + jccも融合可っだ。ハゲっが。

正確には3オペランドになるぶんMOV*が削減できるので
1.5倍以上かも

295 名前：Socket774[sage] 投稿日：2010/01/22(金) 09:34:39 ID:afQeCPeg
Some instruction latency numbers of Bulldozer?
http://citavia.blog.de/2010/01/21/some-instruction-latency-numbers-of-bulldozer-7850137/

命令レイテンシも出てるみたいだ

296 名前：Socket774[sage] 投稿日：2010/01/22(金) 10:16:42 ID:4TT5t9OB
ttp://svn.open64.net/filedetails.php?repname=Open64&path=%2Ftrunk%2Fosprey%2Fcommon%2Ftarg_info%2Fproc%2Fx8664%2Forochi_si.cxx&rev=2722
Any_Result_Available_Time()がレイテンシ

fp-load 2 -> 5
fadd/fmul 4 -> 6
fmadd 6
fdiv32 18 -> 27
fdiv64 20 -> 30

最適化マニュアルに載ってないAESNIとかPCLMULのレイテンシ

DualCore Intel Core i5 650, 3600 MHz (26 x 138) (Clarkdale)
ttp://www.freeweb.hu/instlatx64/GenuineIntel0020652_Clarkdale_InstLatX64.txt

Pentium4のHyperThreadingは、
片方のコンテキストのメモリアクセスでパイプラインが止まると、
もう片方のコンテキストまで止まってしまうって本当?

そして、AtomやNehalem以降の同名の別モノでは、どうなの?

聞いた所で聞けよ

HyperThreadingはまやかし

Pentium4の偏見で凝り固まった人は案外と多い
HyperThreadingと聞いただけでイラネーヨという

Pentium4がK7 Athlonよりも省電力とかいうと
キチガイを見る目で聞く耳を持たない人とかも

国母のアンチみたいなもん

>>714
俺もその口だが、HyperThreadingっていくつかの条件がついた状況でしか使えないから
結局動画のエンコードぐらいしか役に立たないと思ってる。
また、XPも対応が不十分だったりしたと思ったが最近はそうでもないのか？
XPに固執するほど結果は出ないみたいな。

なんで欲張ってSMTなんかやるんだろ
Itanium2のようにCGMTでいいじゃんか

実装に必要なハードウェアリソースはごくわずかだから

HyperThreadingが狙いとしていたのは動画のエンコードのように、
パイプラインにファイン・チューニングできる(された)コードではなく、
パイプラインがスカスカになるような駄コードを2つまとめて流せば、
実行ユニットが遊ばずに有効活用できて性能が上がりますよ
ということだったと思う

>>719
そんなコンパイラはどこにあるのだ。

ああ、gcc, bcc, java辺りか?
ADDが倍速だったりその他諸々、チューニングされていないようなプログラムが使う命令はスカスカになりにくいと思うんだが。

Pentium4はOOO性能が低いっぽくて、命令の並び順を変えると速度が変ったりするんで、普通のコードはスカスカになるんじゃないかと。

>>711
初期のPentium4 with HTでは、(PentiumProと同じで)
L1Dキャッシュミスを4つまでしか保持できないので、
片方のスレッドで5つのキャッシュミスを起こすとロードユニットが完全停止して、
もう片方のスレッドも実質止まってしまうという事はあると思う。
その後のCPUではキャッシュミス保持数が倍増されている。

NetBurstの設計者が自ら言ってるようにL1Dの容量が絶対的に少ないだろう

ttp://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%97%E3%83%AC%E3%82%A4%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0
L1D$ミスすると両方のコンテキストがストールする

キャッシュミスで全部とまっちゃぁ、DRAMのレイテンシの隠蔽にはならないなぁ。
もしキャッシュミスで止まらなければ、DRAMのレイテンシは数百クロック分にもなるわけで、1000命令くらい実行できる。

で、AtomやCore iはどうなんでしょう?

メモコンをCPUに持ってきた

ということは、それらのHTも相変わらずメモリのレイテンシを隠蔽できない、ってことか。

なんで「ということは」でそういう結論になるのかさっぱり分からん。

アム虫だから

だからお前らFB-DIMMが流行るまで我慢しろって

レイテンシ激増じゃねえか

わかってねえなあ
FB-DIMMはクロック数や容量を上げるのが簡単なんだよ

レイテンシーが増えるという指摘にそういう的外れな返答しかできない辺り
「わかってねえなあ」

消費電力と温度を上げるのも簡単

Pen4の悪夢再び？

FB-DIMMは終わったから悪夢はもう来ない

まだ終わってないけど一般人には関係ない

レイテンシが増えてもFSBを上げればいいじゃない

>>728
え? >>726はどういう意図での発言なんだろう。

>>738
そんなもんもう無い

FB-DIMMはレイテンシは大きいけどランダムアクセスでのバンド幅が大きいんじゃなかったっけ?

普通のDDR2やDDR3は、ちょっとした並列処理はしてくれるけれども、
メモリコントローラとDRAMがピッタリ歩調を合わせて動作しないといけないので、
DIMMを何枚積んでも、容量方向の拡張でしかなかった。

しかしFB-DIMMは、パケットベースでインテリジェントに動作するので、
DIMMを詰めば積むほど、並行してアクセスできるメモリが増えて行く。
また、ライトバックが許される書き込みをキューに入れて後回しにして、
早くデータを返すべき読み込みを先に行うとかも、やれるとか。

それで、
SunのNiagara2っていう1チップで8スレッドSMT×8コアで64スレッドも同時に走るCPUは、
FB-DIMMを大量に積むことでパフォーマンスを確保しているとか。

>>741
そうだよよくわかってるじゃないか
問題はDIMMがあまりにも流行りすぎてFB-DIMMが高価なままって
所にあるんだ
もちろんバッファリングするのでレイテンシは増えるが、動作は安定化
するので電気的にいろいろ無理させやすい

自演してデタラメをまき散らすのってどうなんだろう。

自演じゃねーよ
運営に頼んでホスト教えてもらえ

あ、ageになってた
sageに変えた

上がってると書きこみが余計糞に見えやすいしな

>>739
え？といわれてもなぁ。>726!=>728だし。

「ということは」がなににかかっているにせよ、なんで「レイテンシが隠蔽できない」と結論を出したのか意味不明。

しかしアレだよな
Core2もi7もL2キャッシュにバカでかいメモリを積んでようやく性能を
確保している事を考えると、メインメモリのレイテンシって本当に動作
速度の足を引っ張っているんだな

演算ユニット当たりのバンド幅考えるとGPUのほうが状況は酷いけどね

たとえば3%のキャッシュミスを減らそうとしたら大変よ。
繰り返し実行されるような部分ではない部分がキャッシュミスしやすく、
そういうところは予測が付きにくく十分早期にプリフェッチかけるのも困難。
だから、CGMTで。

>>917
コード希望

wrong pathｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ｯ!!!

x86のようなレジスタ本数が少なく依存関係のチェインを抱えがちな命令セットには
SMTはかなり有効なんだけどな。

IPFがSMTではなくCGMTを採用してるのはは、コンパイル時に依存関係が明示されてるから
リソース競合は起こりえない（けどキャッシュミスは起こる）ってVLIWらしい発想だと思うけどなー。

SMTやるかわりにOOOやらない → あとむ
SMTやるくらいなら実行ユニット減らしてコア増やす → ぶるどーざー
なんだかx86でSMTは贅沢な気がする

IPFがCGMTなのは、シングルスレッド性能追求のアーキテクチャだからだと思う。
マルチスレッドでスループットが出ればいいっていうのなら、投機実行とかゴッソリいらないし。

BulldozerのIntegerクラスタはスレッド毎に持ってるからSMTとは言えないけど
FPクラスタは共有だから部分的にはSMTそのものだろ

そうだね。

IPFはシングルスレッド性能追求という、時代の流れに反するアーキテクチャだが、どーするんだろ。
実際、IPFのシングルスレッド性能っていうのは、どれくらいx86よりも速いんだ?

ベストケースで6オペレーション同時発行だから、はまればクロック当たりでx86を越えるけど
3GHzのCore i7の方が速いという現実。
速さは売りにしちゃ駄目。

あとは信頼性（笑）か。
うに死すは取るに足らない物としてItanium引き上げてXeon MPに枕替えしたけどね。

HP-UX使いたい人向けのプラットフォームだね。

信頼性つっても後づけじゃね?
アーキテクチャ的に信頼性を高めているわけではないよね。

どうせ後づけならXeon・・・は複雑すぎてどーにもならんか。

一応IPFはチップレベルで多数決冗長系が組める

IPFに興味があるならWindowsのWDK(旧名、DDK)に入ってるIA64用のコンパイラで
/FAcsオプション付けてコンパイルして出力される.CODを除いてみると、面白いぞ
x86環境でのクロスコンパイラだから実機なくても動くから

nopが挿入されまくりだから

>>758
それが可能なのはIPFだからではなく、IPFには実装したけどXeonには実装していない、というだけだよね。
同じ機能をXeonにも付けようと思ったら付けられるんじゃね?

前提となるメモリコヒーレントモデルが異なる（従来x86では不向き）ので
仮にできても既存のx86資産捨ててまでやる意味がどこまであるかと言う謎

（その点例の試作品48コアのSCCではある意味禁忌をおかしてるわけだが）

むー、それなりに理由があるのか。

あんまり普遍的ではないコードで申し訳ないが↓をコンパイルしてみた

bool IsStringAllXdigit(const char* pBuf, int len) {
if (0 < len) {

for (int i=0; i<len; i++) {
if (isxdigit(pBuf[i])) {
// ok
} else {
return false ;
}
}

} else {
return false ;
}

// ここに到達するときには全ての文字が isxdigit で true ;
return true ;
}

最適化は/O2で、
x86 → 30命令
IA64 → 10バンドル(=30命令)だがnopを5つ含む

nopが入っても命令数は同じだし、5/30で入りまくりというのも過敏なような

ユーザーモードの互換性は確保するけど
特権モードの互換性は取らない

っていうのもアリじゃない?
ページ単位にコアが占有していればアクセスできるけど、
占有してなければページフォルト発生して特権モードで処理するとかすれば。

各種CPUのパイプラインをシミュレーションするツールが欲しくなるなぁ

TLBキャッシュミスやレジスタウィンドウのオーバーフローをトラップで処理しているCPUがあったが、遅かったぞー

Corei7の動作クロックを取得する方法ってないんですか？
ｒｄｔｓｃを使ってクロック数を取得して、実行時間を掛けても、
設定クロックにしかなりません。
TurboBoostがかかっているかどうか知りたいのですが・・・。

>>766
http://download.intel.com/design/processor/applnots/320354.pdf?iid=tech_tb+paper

>>767
ありがとうございます。
msrの値を読まなければいけないので、特権モードでないとだめですね。
msr-toolsのソースを眺めていたら、
sprintf(msr_file_name, "/dev/cpu/%d/msr", cpu);
fd = open(msr_file_name, O_RDONLY);
pread(fd, &data, sizeof data, reg);
こんな感じで値を読んでいたので、
多少遅延がありそうですが、何とか出来そうです。

perfってツールが便利そうなのでメモ。
Ubuntu Lucid (10.04)でperfを使うにはlinux-toolsを入れれば良い。Linux 2.6.32なので対応CPUはまだ少ない。
http://morihyphen.hp.infoseek.co.jp/txt/perf.html
http://shuns.sblo.jp/article/33050692.html
http://shuns.sblo.jp/article/33068050.html
http://blog.fenrus.org/?p=5

SandyBridgeでSIMDを256bit幅に拡張するというけど、
なぜ128bit幅のまま実行ユニットを倍加する、
という選択肢を取らなかったの?

・同時に実行する命令数が増える=そのハンドリングのための回路で消費電力アップ
・実行ユニットを倍にしても、現状のレイテンシ・スループットに合わせて書かれたコードでは実行ユニットが遊んでしまう
あたり?

>>770
大体そう
スケジューリングをはじめとしたコントロールのコストがデータフローに関わるコストを遙かに上回ってるから。
SIMDユニットそのものの幅を倍に増やす方式だと、データ幅が256ビットに増えても、
内部データバスを256ビットにするだけで、パイプライン構造はCore MAとほぼ同じでいける。

だから消費電力あたりのSIMD演算性能はほぼ倍になる。

128ビットの演算ユニットを倍に増やす方式だと演算ユニットを増やした分だけ制御ブロックが肥大化するので
電力効率的にも美味しくないと思われる。

ありがとう

ちなみにAMDのBulldozerは実行ユニットを256bit幅にせず、128bit幅×2個の構成にしてる・・・どうなんでしょう。

もともとが128ビットSSE5を想定した設計で急遽256ビットAVX対応に作り替えたからでは。
まあ、FMAの実装ではAMDが先行してるし、ゆくゆくはAMDが256ビット化、IntelがFMA対応で
実質的な差が無くなるのではないかと。

なるほど。

BulldozerのFPUは2つのコアで共有されるから、
128ビット×2個といっても、1コアあたりでは1個。

もし、256ビット×1個にすると、1コアあたりでは0.5個
既存の128ビットの命令を使ったコードの速度が遅いのだろう。

新命令の追加タイミングと、演算器の強化タイミングは、一緒とは限らず、
128ビットのSSE2命令が追加された当初は、64ビット×2回で処理してた

せっかく新命令を使って書いたのに速くならない・・・っていう不満があると、
AVXを使ってもらえないので、新命令と同時に演算器強化するのかな

ソフトの互換性という点では、新命令は速くなくていいから早めに実装してほしい

128bitが256bitになると、論理レジスタが倍増したことになる。
だからその分は速くなると思うよ（並列実行できるという意味で）。
スループットが糞悪いPentiumMのSSE2浮動小数点も効果あったし。

YMM上位だけを更新する命令とかあるなら32本のXMMレジスタとしても活用しようがあるんだけど
上ゼロクリアか、上下同じ操作か、しかない。

このへんはMMレジスタとXMMレジスタが独立してたのとちと扱いが違う

全部レジスタに乗るような順番で計算するよりも、
L1D$との間で出し入れをしてでも、依存関係のある命令間の距離を長くしたほうが、
スループットが出たりするんだよねぇ。

>>777
mov(load or reg2reg)命令でdestオペランドを上書きしながら反復処理をアンロールすれば
空いてる物理レジスタに自動的に割り振ってくれるから
ほどほどにやっておけばいいよ。
どのみち同時に読み出せるオペランド数に制限があるからそこで頭打ちになる。

まあ、AVXでdest独立になったのは美味しいな（ほぼ全部の命令がリネーミングのヒントになりうる）

SSE4.1に対応したVIA CNB
http://www.freeweb.hu/instlatx64/CentaurHauls00006F8_CNB_Isaiah_InstLatX64.txt

Intel 最適化マニュアル AESNIとPCLMULQDQ追加
http://www.intel.com/Assets/PDF/manual/248966.pdf

http://wiredvision.jp/news/201009/2010090823.html

L1D$のレイテンシが2→3→4と拡大してるんだが、どーにかならんの?

AMDのCPUID Specificationが更新されました
http://support.amd.com/us/Processor_TechDocs/25481.pdf

BMI(Bit Manipulation Instruction)は未公開の新命令でしょうか?

こんにちのOoOEなCPUにおいてL1キャッシュのレイテンシそのものは本質的な問題なのかね？

現代のCPUはL1ヒットを前提にスケジューリングされる。
アドレス解決さえ先行してできれば、どんどん空いた物理レジスタ（orメモリフォワーディングバッファ）
に先読みしておけるということ。
レイテンシが大きくなればなった分だけそのサイクル数ぶん先読みをしておく必要があるけどね。
Memory DisambiguationとかRAWハザードを回避するためのテクニックがどんどん採用されて
L1のレイテンシが性能に響くケースは少なくなりつつある。

L2以下は別。理由はまったく同じで、L1キャッシュヒットを前提にスケジューリングされてるから。
つまりL2キャッシュのロードレイテンシは隠蔽できない。

お、団子さんひさしぶり

団子さんはどうしてそんなに詳しいのだろうか・・・

アドレス解決が先に行えないケースを反例としてだしておくれ。
暗号化のテーブルルックアップ処理を頻繁に行うものはパフォーマンス総崩れかもね
AESNIを使えということだろうが。

OOOは、
後続の命令で実行できるものをどんどん実行するのではなく、
先方にある命令で実行できるものをどんどん実行するの?

http://www.freeweb.hu/instlatx64/GenuineIntel00206A7_SandyBridge_InstLatX64.txt

VI-MULがFP-MULに統合されたので、整数SIMD乗算のレイテンシが3から5になったようだ
http://pc.watch.impress.co.jp/img/pcw/docs/395/394/html/4.jpg.html
http://pc.watch.impress.co.jp/img/pcw/docs/395/394/html/5.jpg.html

最適化マニュアルにSandy Bridgeの情報が追加された
http://www.intel.com/Assets/PDF/manual/248966.pdf

SSE4が全面的に速くなってる。
AES-NIレイテンシが増えてる。
これによってCBC/CFBなどのブロック依存関係のある暗号化形式が遅くなるが十分速いのでさして問題ないか。
そしてスループット1になったことでECBが倍ほど速くなるわけだが・・・

leaがついに劣化してしまった

Fast-LEA 1-cycle; [r+r], [r+r*n]
Slow-LEA 3-cycle; [r+r+disp], [r+r*n+disp]
[r+disp]はどっち？

ロードはoffsetの値でレイテンシが変わるみたいだけど
0〜2047なのかそれとも-2048〜2047なのか

>>788
SIMD整数加算もFP加算器と共用みたいなことを云われていたが、レイテンシを見る限り従来と変わっておらず、これに関しては別個のSIMD整数加算器のままなんだろうね

ttp://www.freeweb.hu/instlatx64/CentaurHauls00006F8_CNB_Isaiah_InstLatX64.txt
名ばかり実装かと思いきや、nanoは結構まじめにSSE4.1実装してるね

ああ、nanoはメモリの書き込みは速いけど
読み込みが遅い

それが改善されれば、SSE関連ではもっとパフォーマンスあがるはずだ
Padlockはメモリアクセスで頭打ちになってる

SSE4.1の速さをもてはやす理由が分からん。
例えばROUNDPSなんてIntelが手抜きでオペコード作ってなかっただけで、初代SSEに入っていておかしくない基本的な命令だろ。
ソフトウェアで書くとややこしく遅いが原理は簡単。むしろハードウェアで作って他の命令より大幅に遅くなる事なんて考えられん。

別にroundは速くなってないよ。元々スループット1だし。

例えばblendvはプレディケーションちっくな事をやる時に
and-andn-orとやってたのが1命令で済むので、
スループット1になったのは嬉しいと思うけどね。

dppsが速いのは3Dでは結構重要。
なによりmpsadbw/pminposuwが速い。

mpsadbw/pminposuwはスループット変わらず、
レイテンシの分遅くなっているように見えるけど

ああNehalemの時点で速かったんだねこの命令

大きな変化はこのへんか。

Westmere
1197 SSE4.2:PCMPESTRI xmm, xmm, imm8 L: 1.88ns= 6.0c T: 1.88ns= 6.00c
1198 SSE4.2:PCMPESTRM xmm, xmm, imm8 L: 1.88ns= 6.0c T: 1.88ns= 6.00c
1199 SSE4.2:PCMPISTRI xmm, xmm, imm8 L: 0.63ns= 2.0c T: 0.63ns= 2.00c
1200 SSE4.2:PCMPISTRM xmm, xmm, imm8 L: 0.63ns= 2.0c T: 0.63ns= 2.00c
1201 CLMUL :PCLMULQDQ xmm, xmm, imm8 L: 4.71ns= 15.1c T: 3.13ns= 10.00c
1202 AESNI :AESENC xmm, xmm L: 1.88ns= 6.0c T: 0.63ns= 2.00c
1203 AESNI :AESENCLAST xmm, xmm L: 1.88ns= 6.0c T: 0.63ns= 2.00c
1204 AESNI :AESDEC xmm, xmm L: 1.88ns= 6.0c T: 0.63ns= 2.00c
1205 AESNI :AESDECLAST xmm, xmm L: 1.88ns= 6.0c T: 0.63ns= 2.00c
1206 AESNI :AESIMC xmm, xmm L: 1.88ns= 6.0c T: 0.63ns= 2.00c
1207 AESNI :AESKEYGEN xmm, xmm, imm8 L: 1.88ns= 6.0c T: 0.63ns= 2.00c

Sandy Bridge
1197 SSE4.2:PCMPESTRI xmm, xmm, imm8 L: 1.29ns= 4.0c T: 1.29ns= 4.00c
1198 SSE4.2:PCMPESTRM xmm, xmm, imm8 L: 1.29ns= 4.0c T: 1.29ns= 4.00c
1199 SSE4.2:PCMPISTRI xmm, xmm, imm8 L: 0.97ns= 3.0c T: 0.97ns= 3.00c
1200 SSE4.2:PCMPISTRM xmm, xmm, imm8 L: 0.97ns= 3.0c T: 0.97ns= 3.00c
1201 CLMUL :PCLMULQDQ xmm, xmm, imm8 L: 4.39ns= 13.6c T: 2.59ns= 8.00c
1202 AESNI :AESENC xmm, xmm L: 2.59ns= 8.0c T: 0.32ns= 1.00c
1203 AESNI :AESENCLAST xmm, xmm L: 2.59ns= 8.0c T: 0.32ns= 1.00c
1204 AESNI :AESDEC xmm, xmm L: 2.59ns= 8.0c T: 0.32ns= 1.00c
1205 AESNI :AESDECLAST xmm, xmm L: 2.59ns= 8.0c T: 0.32ns= 1.00c
1206 AESNI :AESIMC xmm, xmm L: 4.53ns= 14.0c T: 0.65ns= 2.00c
1207 AESNI :AESKEYGEN xmm, xmm, imm8 L: 3.23ns= 10.0c T: 2.59ns= 8.00c

速くなったり遅くなったりわけわかめ

http://journal.mycom.co.jp/special/2011/sandybridge/002.html
Sandra 2011 Multi-Media Bench
>AVXの拡張にあたって実行ユニットのデータ幅そのものは増やされていないし
FP性能が倍になっている理由がレイテンシだけでは厳しい

http://journal.mycom.co.jp/special/2011/sandybridge/004.html
>命令L1→Fetchの帯域幅も32Bytes/cycleに増量された。
32Bytes/cycleはDecoded ICacheの帯域ではないのか？

まあまあｗ
いつもの大原節です

たしかにWriteだけ速いな
------[ CPU Info ]------
CPU Type : VIA Nano U3100, 1600 MHz (8 x 200)

------[ Memory Bandwidth ]------
CPU Clock : 1596.0 MHz
CPU Multiplier: 8x
CPU FSB : 199.5 MHz (original: 200 MHz)
Memory Bus : 532.0 MHz
DRAM:FSB Ratio: 16:6
Memory Type : Single Channel DDR3-1066 SDRAM
FSB Bandwidth : 6400 MB/s
Mem Bandwidth : 8533 MB/s
Max. NUMA Node: 0
Logical CPUs : 1

------------------------------------------------------------------------------------------------
CPU Mask | Read | Write | Copy | CacheFR | CacheFW | Time |
| Normal| Common| Normal| Normal| Common| Normal| Common| Normal | |
--------------------|-------|-------|-------|-------|-------|-------|-------|---------|--------|
0000000000000001 | 3235 | 3230 | 5814 | 3933 | 3925 | 3659 | 3657 | 0 | 40.2 |
----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------
Typ| Read | Write | Copy | CacheFR | CacheFW |
| MB/s | Time | MB/s | Time | MB/s | Time | MB/s | Time | MB/s | Time |
---|-------|--------|-------|--------|-------|--------|-------|--------|-------|--------|
ST | 3236 | 4.6 | 5826 | 7.4 | 3917 | 2.6 | 3658 | 7.0 | 0 | 2.6 |
MT | 3258 | 2.3 | 5810 | 6.6 | 3949 | 3.4 | 3658 | 7.6 | 0 | 1.8 |
-----------------------------------------------------------------------------------------

Optimization Reference Manualのスループットを見る限り、VDIVPS/PDは128ビットずつ計算してるのか？
そしたらVRCPPS使った方が速くなったりするのだろうか。
実機がないから分からん。

VRCPPSも128ビットずつだよ。
11ビット精度で十分ならそれでいい。

いや十分な精度が欲しい場合にNehalemではDIVPSが速すぎて
RCPPSがいらない子だった、というか正常進化でお役御免だったわけだけど
Sandy BridgeではまたNewton-Raphson使った方が良かったりするの？
旧石器時代に逆戻りなら勘弁してほしいなあ、というお話。

RCPPSが12ビットならNewton-Raphsonでもいいんだけどな。
可能な限り精度が欲しい場合に、2ビットの精度を求めてVDIVPS使うと
ものすごい遅くなるというのが解せない。

その可能な限りってのがどんなケースかによるな。
たとえばA±B/CをやるとしてAとB/Cで絶対値が2ビット以上違う場合は2段のNewton-Raphsonで十分だし。

>>790
ソフトウェア屋としては、
新命令は(従来命令を使った場合と同程度の速度であれば)速くなくてもいいから、とにかく実行できる段階
を経てから
新命令が速く実行できる段階
にシフトするのが良いと思うから、Intelの導入の仕方は歓迎だよ。

>>791
8086の頃から、LEA命令の存在は疑問に思ってた。
実行時にアドレスを計算せずとも、
アセンブル時にアドレスが決まるものはそうすべきだし、
そうでないにしても普通に計算すりゃいいじゃん、と。

LEA を使えば、一度に 3 つ以上の数を足し込める。
アドレス計算のためにたくさん積んでる加算器を有効に使えるわけさ。

そっか、
LEA BX, [BX + SI + imm8/16]
とか、
LEA EDX, [EBX + EAX*4 + imm]
とか、
できるんだ。

CISCすげー

たとえば3n + 1問題を高速に解くとか？
lea eax, [eax + eax*2 + 1]

整数即値の乗算も2倍、3倍、5倍、8倍、9倍あたりならLEA使ったほうが速いです。
さらに言うとsource, dest独立なので命令数も少なくなる

どうりでIA-64が同クロックのx86に勝てないわけだ。
MIPSと比べるとIA-64は強力だけど、x86には及ばないな。

もはや加算器やシフタなんてタダ同然なんだなー。

RISCを擁護する気はないけど、CISCだから凄いってのも違う気がする。
レジスタ数が128本も無くてオペコードに余裕があったら4バイト即値は不可能としても、似たようなのがCell辺りに入っていてもおかしく無さそうだし。

ま、歴史的な経緯とか色々理由はあるだろうけれど
当時需要があって、今でも十分使える遺産って事でしょ。
SSE/AVXのある今となっては16倍や32倍もあれば便利だったねってところ。

> SSE/AVXのある今となっては16倍や32倍もあれば便利だったねってところ。

これはたしかに。64ビット拡張とかのタイミングでscaleをもう1ビット増やして欲しかったな。
もっとも今カウンタ変数の更新にinc/dec使わないからあまり意味無いんだけど。
ただ、8倍まで表現できれば64ビットスカラ整数のオフセット算出を「タダ」でできることになる。

RISCの大半はアドレス計算もALUでやるものが多いからなあ。
Cell SPEはいちいち「積和算」が必要なんだぜ
ARMは論理レジスタを16本に抑えてプレディケートやバレルシフタにコード空間を割いてるから
多少マシという程度。

え?
mov eax, dword ptr[ebx + edx*4]
って、scale値4なの? もったいない。

scaleは2ビットしかなくて4通りしかないんだから、
アクセス幅によらずに1,2,4,8ではなく、
dwordなら4,8,12,16
qwordなら8,16,24,32
ってな具合にしてくれればよかったのにね。

それはそれで困るけど・・・

indexを4の倍数、8の倍数にしとけば良い話だしな。
x64では1バイトOpcode空間から削除されてしまったinc/decをつかおうってんじゃないだろ？

Bobcat
ttp://www.freeweb.hu/instlatx64/AuthenticAMD0500F10_K14_Bobcat_InstLatX64.txt

ItaniumにはClassic Pentiumが丸ごと入っているっていう噂を見かけたのだが、本当?

Intelの資料には、
命令フェッチやデコード、スケジューラやリタイアメント等はIA-32専用だが、
レジスタや実行ユニットはIA-64用と共用されていると書いてあるらしいのだが。

>>820
今頃知ったのか
でも結局使い物にならなかったな

命令の所要クロックを比較すれば、噂が本当かどうか、分かるのかな。

64bit化の時に、
andn, xnor, nand とかの整数命令をもうちょっと強化してもよかった気がするなあ。
回路的には大したことないはずだし。

andnはVEXフォーマット採用で3オペランド形式になりますよ

>>820
ウソだろ

Pentium200MHz前後と同程度の速度しか出ないが、しかし、SSE対応ですぜ。

アウトオブオーダ実行しておきながら800MHzで200MHz相当の速度しかでないって、どんだけ・・・。

>>824
xmmじゃなくて汎用レジスタのだよ。

汎用レジスタはほとんど進歩してない。
3オペランドとか無理だったのかな？

いや、その汎用レジスタ版のandnがVEXフォーマットなのよ。
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01766.html

AMD独自命令かと思いきやBMIのCPUID Feature FlagはIntel側の空間にある。

まぢか？
Haswellとかに載るのか？

でもやっぱり64bitになった時に見直すべきだったと思うな。
途中からじゃほとんど使われないままになってしまう。

AMD64は悪貨ですから。未来に負の遺産を残すことなんか、気にしちゃイネエ。
IA-32からの変更を少なく抑えることで、ローコストに32bitと64bitの両対応とし、
IA-64を叩き割るのが、AMDの取った貧者の核兵器的な戦略ですから。

AMDのくせに生意気だ！
ってことですね。わかりますｗ

どうした? 意味がワカラン。

>>830
まさしく負の遺産。
命令大変更の最後のタイミング、非常に重要なタイミングを、
intelより先に行くという目的のために使ってしまったAMDの罪は重い。

intelにゃ最初からできないだろう。SSEのように後からダラダラ醜い建て増しをしていくのが目に見えてる。

でも結果オーライだったじゃん
OSやコンパイラの大きな変更無しに64bitに移行出来たんだから
かたやItanium2の凋落はどうだ？ひどいもんだろう
いくら最新のVLIWで御座いますって言ってもソフト資産が無い事には
流行らないってはっきりわかってしまったからな

>>834
インテルは実際にやったじゃん、IA-64を。

>>835
> OSやコンパイラの大きな変更無しに64bitに移行出来たんだから

WindowsやLinuxは、AMD64よりも先にIA-64に移植されましたよ。
Windowsに関して言えば、AMD64版はx86版からの移植というよりは、IA-64版からの移植ですよ。

Itaniumはx86命令の実行速度が遅いのが問題だった。
x86の膨大なソフト資産がそのまま走るのに、それが遅いことをさして「互換性がない」とまで言われる始末。

初代Itaniumに関しては、消費電力的にもコスト的にも、Pentium3のダイをMCMする余裕があったのだから、
なりふりかまわず、そうしていればよかったのにね。

市場がIA64についていかなかった時点で、
命令セットそのものではなくAMD64という戦略を叩く>>830,833はお門違い。
スレの趣旨にも反する。

戦略というより実装だな
今後の事なんだからもっとすり合わせても良かった

もしintelがIA64を投入せず代わりにAMD64のような64bit拡張をしていたら、
80286→80386
の時と同じように、intelは散々に叩かれただろうな。

Yamhill拡張よりはamd64拡張の方がよかったとおもうけどね。
レジスタ増やしたし。

IA-64がなければ、Yamhillもなかった・・・また違った64bit拡張になったと思うよ。

AMDがやることは良いこと
Intelがやることは悪いことですから

IA64が売れていたらYamhillはなかった。だろ。

IA64がなかったら・・・・Yamhillとは違う64bit拡張
IA64が売れていたら・・・・Yamhillは出番なし
IA64が売れなかった・・・・簡易64bit拡張のYamhillが作られたが、お蔵入りさせてAMD64を採用

Optimization manuals更新
http://www.agner.org/optimize/
Sandy Bridgeの情報が追加されたようだ

Intel(R) 64 and IA-32 Architectures Optimization Reference Manual
http://www.intel.com/Assets/PDF/manual/248966.pdf
248966-023から248966-023aの変更点がわからない

メモリのゼロフィルに要する時間が気になる。

ゼロフィルするときの動作って、もしかして、

1、あるメモリへの書き込みがキューに入り、キャッシュに送られる
2、キャッシュはキャッシュライン分をDRAMから読む
3、キャッシュライン上で、1の書き込みの処理を行う
4、キャッシュからDRAMに書き込みが行われる

といった具合になっていて、
キャッシュラインが全て塗りつぶされるような場合でも、
DRAMからの読み込みが発生してしまう、ってことなの?

メモリの一部に書き込むと言うことは、その周辺もまとめて書き込まないといけないからどうしても読み込みが発生するのでは?
Intelの講習会ではそう言ってたと思った。

部分的に書き込むときは、読んで・変更して・書き込む、っていう動作になるのは仕方ないにしても、
キャッシュライン丸ごと全部が書き換わるときには、読む必要ないと思うんだけど、読んでるクサイのよね。

嫌ならmovnt*を使えばっていう。

movnt*は、
キャッシュから優先的に追い出して構わないというヒント
ではなく、
キャッシュラインと同じサイズのコンバイン用のバッファを介して、ライトスルーでメモリに書き込め
っていう命令なのね。

キャッシュラインの境界に合わせてシーケンシャルに書き込めば、
メモリへの書き込みはキャッシュラインのサイズでのバースト・ライトになる、と。

んーでも、NTでmovしても、readに対してwriteは8割程度の速度しか出ないんだよなー。

>>24
コンパイラにマルチスレッドの指定はないの？

>>24 のような、
最適化によって実行時間のオーダーが変わってしまうような記述は
現代でも避けるべき。

クリティカルではないコードでは無問題。
このスレの人は古すぎる。

個人でのプログラムでクリティカルでないことがあらかじめわかってるなら
良いんじゃない？

集団でのプログラム、業務でのプログラムなら、
クリティカルにならなくても避けるべき。
そういうコードが残ってると後々悪さをするんだよ。
想定外のところからのコール、移植、ソースの流用、.....などなどで。

計算オーダーの違いは明らかで、
コード量はほぼ同じ。
見やすさもほとんど変わらず。
あえて >>24 のように書く意味がない。

メンテナンスを想定していて、
現状のコードで問題ない部分は修正すべきではないよ。
修正するなら関係者の合意をとってからにすべきだし、
修正したコードの有益性を明確に説明すべき。
勝手に直すのは論外。
オタクプログラマが嫌われる理由を作らないようにしましょう。

新規でそういうコードを作るなって話だよ

strlenしている先がvolatileなポインタだったら、動き変わるからなぁ。
あえて>>24のような書き方をしている可能性もある。

volatileがついてないタダのキャラポじゃんか。
constもなぜかついてないが。
そんなこと言い出したら
strlenが標準ライブラリじゃなく全然関係ない関数かもしれない
とかそういう心配も

#include してないしな。

>>852
あんなコードをマルチスレッド化だと? アホか。

>>856
オーダー違いは、けっこうヤバいんだぜ。

>>858
触っている最中に中身が変更されるような作りは、かなり危険。

いまどきこんなんでやばくなる全体の設計の悪さなんとかしろよw

>>862
2万文字あったら2億回ヌル文字比較が行われるんだぞ
全体の設計の悪さとかじゃない
単純にこの関数の設計が悪い

こういうコードを書くヤツや
こういうコードを肯定するヤツ
と一緒に仕事したくない

まさか二年以上も経ってから突き回される事になるとは思わなかったｗ
単に、x64の方だけ空気読んでいて興味深いなあ位の意味しかなかったのになあ。
処理内容も、ループ自体が最適化で省略されないようにしたかっただけだし。

オーダー違うって言ってるやついるけど、
オーダーは同じだよ。
どのみちbufの長さに対して2乗のループだからな。

>>263
何らかの処理の部分も2億回になるから、遅けりゃわかる。

>>16
のコードを見て実害出るほどに速度差が容易にでると思えるやつはまだまだ素人。

strlen(buf) があると最適化出来ないんじゃないの?

インライン展開できるのにそれを最適化できないっていうのは少し悲しい

>>852-870
スレ違い

多少マナーのあるひとなら
こう書くでしょ

for (int i=strlen(buf1); --i >= 0; ) {
  for (int j=strlen(buf2); --j >= 0; ) {
    何かの処理
  }
}

>>16と>>872を
ベースにしたコードで、
最適化コンパイラを通し、
比較的最近のPCで10秒以上差がつくコードを示せ。

>>872はある種のジョークなんだろ。
全くおもしろくはないが

>>873
10秒の差がつかないといけない理由は？

>>865
x86とx64で生成するコードが違うのは、バグの互換性のためだと思う。

>>866
strlenを毎回やると、ループが3重になるからO(N^3)
strlenを最初だけにすると、ループは2重になるからO(N^2)
オーダー、違いますね。

>>873
Visual Studio 2010 Win32 Releaseのデフォルト設定
CPU core i7 2600

buf1, buf2 とも10000文字の文字列
「何らかの処理」の部分は >>24 と同等

>>16 のまま
389.8秒

strlenをループの外に
0.028秒

>>873みたく、10秒位差がでない限り気にしない人ばかりなら
色々楽だろうなあ、と思った。

>CPU core i7 2600
うわ・・・厨房臭い・・・。

>>879
ツッコミ入れるポイントにセンスがないな、お前。


俺が仕事で書くコードでは、C++で文字列クラスを使うので、strlenを毎回呼ぶようなことにはならない。
それは遅いからではなく、strlenを使うような書き方をしてたらミスが怖いので、やらない。

速度の話だと、毎回strlenを呼ぶような遅いコードを書くのは全然OKというよりも、むしろ推奨。
最初から最短コース的な速度だと、
営業からは、安い1ソケットのサーバで済むのは儲からない、などと嫌味を言われるし、
様々な変更や改修で遅くなっていくとマズい。
だから、簡単に直せる遅いコードを散りばめておいて、必要に応じて速いコードに直すのがいい。

>>880
お前のところには死んでも発注したくない

いや、>>880は正論だろ。
プロとしてもコードオタとしても正しいギミックだよ。
最速のコードは趣味で楽しんどけ。

アホな命令がくるときに備えて、
いざというときに逃げられるギミックを仕込んでおくのは
プロの常識。

ギミックw

>>876
事実だとすると、過去の資産引きずるってのは、
実は命令セットの設計の新旧よりも、コンパイラの最適化と既存資産の互換性の
問題の方が大きそうだね。

>>877

Visual Studio ってやつは strlen が pure 関数になってないのか。

同じ値の引数でも、中身が変ってるかもしれんだろ。

strlenがただのライブラリ内の一関数という扱いであれば
コンパイラがpure関数かどうか知るすべがない。
strlenに対してコンパイラが特別扱いしていれば
最適化されるかも知れないが、
特別扱いするほど良く使われる関数でもない。

>>883
最適化でどうとでも変わってしまうギミックなんかにしないで
どうせ意図的に入れるとしたらもうちょっとマシなギミックにしとけ

pure関数って何?
内部に状態を持たず、引数に対して一意の返り値を返す関数?

だとしたら、strlenはpure関数になるわけがない。

たとえば
n1a = strlen(buf1);
strcpy(buf1, buf2);
n1b = strlen(buf1);

どちらのstrlenもbuf1という同じ値を引数にしているが、返り値の値は同じとは限らない。

スレ違いな上に阿呆がpopしまくっていて酷いね。

volatileへのポインターでなければ、
ポインターの示す先が変わっていないと判断したときは、
勝手にstrlenの結果をキャッシュしても規格上は問題無いと思う。

規格と実装を混同してないか?

おまえらコンパイラ最適化の井戸端会議はどうでもいいので所要クロック(笑)でも数えててください(笑)

strlenをSSE2でチューンしたコードならあるけどｗｗｗｗ
もちろんCじゃあれなんでフルアセンブラで書き直した。

てかさx86-Win32のABIってなんで__fastcallデフォルトにしなかったんだろうって思ったよ。

>>894
デバッグのため、かもね。
引数がスタックに積まれているから、drwtsn32がダンプしたログを見ると、どういう引数で呼ばれたのか分かるし。

>>894
ABI 設計当時は、fastcall でないオブジェクトファイルの再利用がちょくちょくあったのかな？
それとも単純に、register pressure の考慮をしたのかな？

VisualBasicへの配慮だったりして

eax, ecx, edxはどのみちcaller-saveなんだからレジスタ渡しにしてくれたほうがいいんだけどね
10文字以内の文字列で自作strlenを使うとfastcall版とcdecl版でかなり性能が変わってるんで
これはどうしたものかと。

独禁法に違反する恐れがあった、というのは考えすぎかｗ
fastcall、というかレジスタ経由の呼び出しは、
元々コンパイラ依存で各社好き勝手やっていたから、
仕様の決め方によっては他社への嫌がらせと取られかねない、とか。

>>898
わざと性能落として、より高い CPU 買わせようっていう
wintel の謀略だったのかもね。

> これはどうしたものかと。
だんごさんのスーパーなライブラリでもかまして、なんとかしのいでくださいｗｗｗ

8085(Z80)からの移植性を考慮して、だと思うが。

>>892
>>888

呼び出し規約なんて、関数単位で選べるんだから、選べばいいじゃん。

歴史的にお約束のsyscallに合わせたからとか。

64bitだと過去に縛られないからレジスタ渡しだね。
レジスタが多いからってのもあるだろうけど。

VS2010 の浮動小数点の関数を見たら、
コールのたびにSSE2対応かどうかの判断をして呼び分けてた。
sinとかx87 1命令で出来る関数でも、本当にSSE2の方が速いんだろうか.....

>>906
前にどこかのスレで見たんだがSSE2で展開した方が速い場合がある
精度が64bitでいいからだろうね

>>906
デバッグ用ビルドではランタイムライブラリが使われるが、
リリース用ビルドでは組込関数が使われる、
だったりして。

>>907
x87FPUは、レジスタがスタックだし、例外とかの処理の都合上、スーパースカラーやパイプライン実行に向いてないのよ。
SSE2は、その2つのハンデを負ってないので、それだけで高速。

昔はx87FPUの例外処理を端折ることで高速化したサードパーティのFPUとか、あったんだよー。

試しにsin 100000000回で実験したら
xmmが有利な64bitでも
x87の方が倍くらい速かった。

>>909
x87の方は実行時間のほとんどがfsinなので、
スーパースカラーやパイプラインは関係ないかと。

ちなみに、x87を使ったコードは以下
昔の32bitコンパイラならインラインでそのままfsinが使われてたはず

sin_x87 proc
movlpd qword ptr data, xmm0
fld qword ptr data
fsin
fstp qword ptr data
movlpd xmm0, qword ptr data0
ret
sin_x87 endp

Core i7で地味にFPUも改良してる可能性はあるな

あ、ごめんなさい。逆だった。
xmmの方が倍くらい速い。
の間違いでした。
失礼しました。

fsinとかって本当互換性のためだけについてるって感じですかね。

VC++2008 Express EditionとNorthwood、Clarkdaleで試してみた

/fp:fast
/arch:SSE2ではcall ___libm_sse2_sin
/arch無しではcall _sin
SSE2は75%の時間で終了

/fp:precise
/arch:SSE2ではcall __CIsin
/arch無しではcall _sin
速度差ほとんど無し

そっか、いまどきのCPUだと倍も違うのか。

たびたびすまん。
値によってはやっぱりx86の方が倍速いみたい。

SSE2だと条件分岐が多いんで、
いろんな値でsinを行うと分岐予測が外れて遅くなる。

逆にほとんど同じ値ばかりだとSSE2の方が倍速い。

sse2なら、ベクタ化コードとも共存できるね

>>916
テーブルを使ってるみたいだから
同じ速さでのベクタ化は難しそう。

速さじゃなく結果の精度に一貫性持たせる為だと思うよ

結果の一貫性が必要な用途なんてネットゲーくらいしか無いのに...
ほとんどの用途では速度と精度の方が重要だろうに。

この先もっと速い命令や速いアルゴリズムが出ても
一貫性の為に同じ方法を維持する？
そんな.....

VS2010は持ってないけど、VS2010のSSE2 sinってそんなに遅いのか？
インテルコンパイラだとSSE2 sinがx87 fsinに負けることなんてまずないけどな。
例えば次のようなコードだとSSE2 sinの方がx87 fsinより40%速い。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((rand()-RAND_MAX/2)/10.0);
ループが自動ベクトル化されていないことも確認した。

一貫性の為ならx87とSSE2を実行時に使い分けるなんてことはしないはず

VS2010 Release デフォルト設定
コードは>>920

○ SSE2を用いたsin
x86 3.66秒
x64 3.95秒
※標準ライブラリのsin使用
※実行時にSSE2とx87を使い分けているようなのでオーバーヘッドがある

○ x87のfsin使用
x86 5.69秒
x64 4.96秒
※アセンブラ記述の関数をコール

普通の値ならSSE2の方が速い

___libm_sse2_sinのコードを見たが、ほぼ分岐なしで一本道。
しかし、レジスタの依存関係があるので、あまり速くなさそう。
SIMDしないのはモッタイナイし、ソフトウェア・パイプライニングで2セット同時に計算したほうが良さそう。

>>923
VS2010のはテーブルを使ってるけど、
インテルコンパイラでは使ってない？

一周(2π)を64分割した点からの角度差を求め、
そのsin, cosを求めてから、
64点の値と加法定理を用いて結果を出してる模様。
64点の値にテーブルを用いている。
その過程でSSE2による2セットの演算を多様している。

角度が近ければベクタ化できるけど、
ぜんぜん関係のない複数の角度のsinを求めるのだと
条件分岐やテーブルを使わなきゃならないんで
ベクタ化は難しいと思う。

>>924
いや俺が見てる___libm_sse2_sinはVC++2008EEの。
テーブルも使っているし、半分くらいは*pd な演算だが、半分くらいは*sdな演算だったよ。

>>925
条件分岐は1回、それも特殊な値の場合の処理だけだし、
テーブル参照の部分だけ別に分けてやればいいと思う。

良く見たら >>920 のコードはひどいな。
除算は結構時間がかかるんだぞ。
sinに比べて短いとはいえ、無視できる時間でも無い。

>>927
32bitを見てる？64bitを見てる？
VS2010だと32bitと64bitで全然コードが違った。
>>924の処理は32bitの方。
64bitの処理はまだ詳しく見てない。

>>922
VS2010でもSSE2の方が速いじゃん。
x87 fsinの方が速いのってどんな場合？？と思ったら、
こういう引数がでかい場合か。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((rand()-RAND_MAX/2)*1e10);
この場合なら確かにSSE2はx87 fsinより倍以上遅い。

>>924
インテルコンパイラでも64分割してテーブル引いてる。

>>929
32bit

__libm_sse2_sin:
00401234 pextrw eax,xmm0,3
00401239 and ax,7FFFh
0040123D sub ax,3030h
00401241 cmp ax,10C5h
00401245 ja special (401381h)
0040124B movsd xmm1,mmword ptr [PI32INV (40EA20h)]
00401253 mulsd xmm1,xmm0
00401257 movsd xmm2,mmword ptr [SHIFTER (40EA28h)]
0040125F cvtsd2si edx,xmm1
00401263 addsd xmm1,xmm2
00401267 movsd xmm3,mmword ptr [P_1 (40EA10h)]
0040126F subsd xmm1,xmm2
00401273 movapd xmm2,xmmword ptr [P_2 (40EA00h)]
0040127B mulsd xmm3,xmm1
0040127F unpcklpd xmm1,xmm1
00401283 add edx,1C7600h
00401289 movsd xmm4,xmm0
0040128D and edx,3Fh
00401290 movapd xmm5,xmmword ptr [SC_4 (40E9F0h)]
00401298 lea eax,[Ctable (40E1C0h)]
0040129E shl edx,5
004012A1 add eax,edx
004012A3 mulpd xmm2,xmm1
004012A7 subsd xmm0,xmm3
004012AB mulsd xmm1,mmword ptr [P_3 (40EA18h)]
004012B3 subsd xmm4,xmm3

>>927
> テーブル参照の部分だけ別に分けてやればいいと思う。
そうだね。

>>930
そうそう。
私はこんな感じのコードでやった。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((double)i);

実際に良く使うのは±2πの範囲だと思うので、
通常はSSE2の方が速い。

-----
sinとcosを同時に求める必要があるなら、
セットで求めるのが効率的だね。
共通の処理がすごく多いから。
x87にもfsincosとかいうのがあったような気がする。

004012B7 movsd xmm7,mmword ptr [eax+8]
004012BC unpcklpd xmm0,xmm0
004012C0 movsd xmm3,xmm4
004012C4 subsd xmm4,xmm2
004012C8 mulpd xmm5,xmm0
004012CC subpd xmm0,xmm2
004012D0 movapd xmm6,xmmword ptr [SC_2 (40E9D0h)]
004012D8 mulsd xmm7,xmm4
004012DC subsd xmm3,xmm4
004012E0 mulpd xmm5,xmm0
004012E4 mulpd xmm0,xmm0
004012E8 subsd xmm3,xmm2
004012EC movapd xmm2,xmmword ptr [eax]
004012F0 subsd xmm1,xmm3
004012F4 movsd xmm3,mmword ptr [eax+18h]
004012F9 addsd xmm2,xmm3
004012FD subsd xmm7,xmm2
00401301 mulsd xmm2,xmm4
00401305 mulpd xmm6,xmm0
00401309 mulsd xmm3,xmm4
0040130D mulpd xmm2,xmm0
00401311 mulpd xmm0,xmm0

00401315 addpd xmm5,xmmword ptr [SC_3 (40E9E0h)]
0040131D mulsd xmm4,mmword ptr [eax]
00401321 addpd xmm6,xmmword ptr [SC_1 (40E9C0h)]
00401329 mulpd xmm5,xmm0
0040132D movsd xmm0,xmm3
00401331 addsd xmm3,mmword ptr [eax+8]
00401336 mulpd xmm1,xmm7
0040133A movsd xmm7,xmm4
0040133E addsd xmm4,xmm3
00401342 addpd xmm6,xmm5
00401346 movsd xmm5,mmword ptr [eax+8]
0040134B subsd xmm5,xmm3
0040134F subsd xmm3,xmm4
00401353 addsd xmm1,mmword ptr [eax+10h]
00401358 mulpd xmm6,xmm2
0040135C addsd xmm5,xmm0
00401360 addsd xmm3,xmm7
00401364 addsd xmm1,xmm5
00401368 addsd xmm1,xmm3
0040136C addsd xmm1,xmm6
00401370 unpckhpd xmm6,xmm6
00401374 addsd xmm1,xmm6
00401378 addsd xmm4,xmm1
0040137C movapd xmm0,xmm4
00401380 ret

こんな感じ。

>>931
ごめん。間に割り込んじゃった。

中心部分は2010の32bitと同じみたい。
2010だとその前にCPUによる分岐や、stからxmm0へのコピーなんかの処理がある。

00401283 add edx,1C7600h
これの意味がどうしてもわからないんだけど、
わかります？
なくても何も変わらないと思うんだけど......

>>935
デッドコピー対策かもね。

その1行があれば、
誰が書いても同じコードになるんじゃ!
って言い訳ができなくなるから。

そういうことか
他の関数でも探してみようかな

codepadとか使おうyo

そうそう。あとできればThis code is public domain.ってコメントに入れてくれると嬉しい。

つまらない釣りは辞めろ

>589
2スレッドだけど、クロック単位でスレッドを切り替えてるだけだから1スレッドあたりのIPCは...

クロック単位でスレッドを切り換えるだけでも、実効IPCは改善しますぜ。

>>919
お前ってアホだね

どうしたとつぜん

面白そうなページ見つけたんで張っておきますね
既出かな

Software optimization resources

ttp://www.agner.org/optimize/#manuals

>>945
既出過ぎる
俺ここの和訳手伝った事あるわ

>>945
激しく
既出だぞ

和訳ってあるの？

この内容をふつうに理解しているレベルになると、
この程度の英語くらい普通に読めるから訳なんていらない。

テンプレェ・・・

>>948
PDF化する前はあった
今はもうサイトごとないと思う

再配布禁止でなけりゃちとうｐしてもらえんだろか？

そこのnano　CPUID偽装ネタおもしろいな

和訳ってソニーCSLの中の人か

>838
またそれに何年かかかって〜、下手すりゃ先に実装されて〜、とAMD的に美味しい展開にはならないと思われ。
ましちゃIntelはx64に乗り気じゃなかったわけだし。

Intelにすりゃ「AMDにやられた〜」って感じなのかな

むしろMSにやられた。だろ。

浮動小数点演算命令はAMDオリジナルプランは破棄されてIntel SSE*互換だしね。
実質「MS64」だよ

やっぱり普通の整数命令がマズイよな x86, x64は。

AVXで整理したといってもAVXを使わない粒度の細かい命令はそのまま残るわけで

AVXとは何だったのか。

命令(およびprefix)の前に、
prefix長と命令長を示す1バイトを付ける
っていうのは、割りに合わないっていう判断がされたのかな。

AMDはL1I$上でマーカー付けてる。
下手にISAをいじるよりも良いという判断なのだろう。

Pentium 4はトレースキャッシュミスしてL2からのフェッチになると1クロック1命令までスループットが低下したけど
AMDの場合もL1Iキャッシュミスをすればプリデコーダの性能がボトルネックになる。

命令ストリーム＋プリデコードタグで1サイクルに400bit以上もフェッチするくらいなら
全部デコード済みのキャッシュをL1Iとは別に持ったほうがましじゃね？
・・・と思ったらSandy Bridgeがそれをやった。

思うだけじゃ駄目で、使えるトランジスタ数等を考えた定量的な解析が必要だろう

ここは計測スレ

Itaniumもらったんだが、どうやって計測するん?
RDTSCなんて命令ないぞ?

AR44レジスタを見るらしいよ。
レジスタの仕様自体はよく知らないけど。

スレタイ見ろよこの糞虫どもが。

>>968
サンクス・・・レジスタ読むまでの道のりは長そうだ。

今回の災害にまつわる節電のため、Itaniumは電源を入れられなくなりました
エアコンよりも電気食うって、どういうことよ

Software Optimization Guide for AMD Family 15h Processors
http://support.amd.com/us/Processor_TechDocs/47414.pdf

FP/SIMDのポート配分がかなり嫌だな。
使いこなせる変態いたらまじで尊敬するわ。

>>973
いるじゃん。ここに一人。そんｋ

既定に餌を与える奴は既定

何が嫌かって、簡単にいうと、行列積演算でかなり使えそうな、それこそIntelのAVXオリジナルよりリッチな
シャッフル・転置命令が実装されてるけど、FMACをフルに使う場合はその命令は使うなという、罰ゲーム仕様です。

なぜならFMACの1つとXBARユニットがPort1を共有してるから。
Port2, Port3側で実行できるPack/Unpack命令複数で代用してうまくポート競合を回避してくださいってこと。

この点に関してはSandy Bridgeのポート構成の美点を再確認できました。

Pack/UnpackもXBARだけじゃね？

よくみたらそうだった。
なんでこのマニュアルのサンプルVPERMIL2PS使えば命令数減らせるものをUNPACKとかDUPとか使ってるんだろ？

いや、そんなに減らないわ。失礼。

遅くなる理由は異なれ、初期実装においてリッチなのが遅いのはIntelだってSSEの頃からそうだったろ。
初期実装は動く事が大事、まずは周知っていう発想は正直やめてほしいけど。

後から速くなるも知れないから、とかいう理由で今からわざわざ遅くなる選択をするかってのな。
速くなったら速くなったで新旧用にバイナリ2つ用意しなきゃならないし。

連投失礼。

どうせ動くの最優先にするなら、多少無理してでも豊富な命令を用意して、かつ固定しておいてほしかった。
128ビットだけでSSEからSSE4.2、しかも間にSSSE3とか変態ネーミングも絡めて6世代もバリエーションがあるのは多すぎる。

いやべつに遅くは無いと思う。ただポート構成が悪い。

これどういう風に進化するんだろうね？
FMACの256ビット化はいうまでもないけど、Port0, Port1にもMMX_ALUを持たせて
XBARはPort2に移動かな。

最初に（V）PPERM見たときスゲー協力だと思ったけど、1個だとわかった時点で
PSHUFBを2個発行できるSandy Bridgeのほうがいいわと思いました。


というか、どのみちSandy Bridge用とBulldozer用で別々のAVXコードが必要になるよ。

>>982
どのみち別々だって分かっているなら、さらにバリエーションが増えているわけじゃないか。
事態は変わらないんじゃなくて悪化してるぜ。

あとVPCMOVと(V)PBLENDVBがVPERM*と同じポートなのが嫌だね。
32要素を超えるテーブル参照をしたいときにスループットでないいよ。
（Altiveｃではこれに相当する命令を並列実行できました）

>>939
一目'in'が抜けてるよね?
誰も突っ込まないところみると,このスレ英語できる人いないんだろうな

なにかコンプレックスでもあるの？ｗ

This code is in the public domain.

この人はドイツの人っぽいけどこういう一例も
http://www.sqlite.org/cvstrac/wiki?p=SampleCode


公共物ですと言いたいならinは必要だが
いわゆるPDS（著作権を放棄したソフトウェア）ですって意味なら不要かと

>>985 はアスペ

>>985
バカだなお前。あれが未来の英語の姿だぞ？

アルファベットで書かれた言語で英語ほど文法が加減なものは無いな。

>>980
>　初期実装は動く事が大事

それが効力を発揮するのは、そのCPUが世代遅れになった時、だ。
後から速くなるかもしれないから使ってくださいではなく、
後から速くなったときに(古いCPUで動かないという理由で)使うのを躊躇させないために、あるのだと思う。

My private parts are in the public domain :D

a

Lvが足りなくて次スレ立てられなかった
↓たのむ

ほい
x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

>996乙

埋め立て開始

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

何も無理矢理埋めんでも

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