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

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

過去ログ
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/

ダンゴ先生のおかげで次スレが立ったな。

前スレ末からコピペ

998 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/31(土) 20:41:21
for (int x=0; x<count; x++) {
sum += p[x] ;
}
これが酷い例だな。
都度p+x*sizeof(int)の計算が必要になる。

while (p<末尾の次) sum += *p++ ;
こう書けば、乗算が削れる

999 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/31(土) 22:43:55
>>998
アセンブラなんて何年も前にちょこっと触った事がある
程度なんで、眉唾ものだと予め断っておくけど。

インデックス付き間接アドレッシングできないCPUとか
それを使わないコンパイラなんて今でもあるの？
今時のCPUとコンパイラなら大抵は前者が速いか、
悪くとも同等にしかならないと思っていたのだが。

for (int x=0; x<count; x++) {
sum += p[x] ;
}
を書いた者です。

ポインタを使うやり方も試しましたが、速度に違いは見られませんでした。

ポインタを使うよりも配列を使ったほうが、わかりやすくて良いと思うのですが、
年寄りの人たちからは馬鹿で浅墓で勉強が足りないから、そんな書き方を
するんだと叱責されたことがあります。

strength reduction でググレカス

その年寄りはポインタと配列が同じ物って知らないんじゃないの？

最適化が期待できないコンパイラならそういう書き方を避ける。
でもここはx86関連のスレなので、最適化するコンパイラが標準的だろう。

CPUやコンパイラによってははっきり解るほどの差が出る事もあるけどな。

このスレいうのもなんだけど、
処理速度がネックにならない箇所以外で
何でもかんでも速度重視(のつもり)でコードを書くのは
有害だよ。趣味世界で仕事をしているのではない。
CPUの高速化と同じで、ネックの部分に投資をすべき。
それ以外はコードの読みや、保守性大事です。
何も考えてないやつに限って自己満足の高速化をしたがる。

Cでstrlenをアホみたいに呼び出すコードをときどき見かけるぞ
負荷になるのか、sambaなんかだと文字列クラス相当品を用意しているがな

かといって既存のものに急に入れ替えるのも難しいから
ダンゴ様のfast_strlenはそれなりに意味があるのだよ

結論：馬鹿とダンゴは使いよう

残念ながら、ここはx86スレなんで
strlenを馬鹿みたいに多用しても、速度的に実害がでるような
クリティカルな状況は殆どない。単なる精神安定上の問題でしかないぞ。
組み込みソフト作るんじゃないからさ。
コードは常識の範囲内で万人に読みやすいのを書く。
オリジナルの関数を持ち出す時点で有害。

>sambaなんかだと文字列クラス相当品を用意している

>strlenを馬鹿みたいに多用しても、速度的に実害がでるような
>クリティカルな状況は殆どない。

どちらが本当なの？

sambaの連中が馬鹿ってことだろ。
あいつら素人だし、所詮オープンソースなんてそんなもの。
そんな有害コードは参考にするべきでない。

for (int i=0 ; i < strlen(buf1) ; i++) {
for (int j=0; j < strlen(buf2) ; j++) {
何かの処理
}
}

こういうのを見ると、ループ中にbuf1やbuf2の内容が変るのか? と思う。
buf1やbuf2を見るとconstがついてない。やっぱり変るのか?
と思ってみても、やっぱり変らない。

もうねアホかと。

いつのまにか、strlenの負荷を減らすために
sambaの文字列クラスが作られたという設定になっている件について。
表現の自由万歳だな。

>>15
ちげーよ。

strlenを頻繁に使うってことは、バッファオーバーランのバグが多くなるってことだ。
だからバッファの長さに関する処理をクラスの中に局在化させて、そこをしっかり品質確保するんだ。

>>17
文字列をコピーしたり加工したりするたびにstrlenが必要になるだろ?
あちこちで頻繁にstrlenを呼ぶので、strlenが消費するCPUサイクルは、無視できない。

あるプロジェクトでは大文字小文字を区別しない文字列比較を頻繁に行っており、
それが1割近くのCPUサイクルを消費してた、なんてことがあったよ。

>こういうのを見ると、ループ中にbuf1やbuf2の内容が変るのか? と思う。
いいたいことはわからんでもないが、ぜんぜん思わんよ。
ループ内でbuf1, buf2の内容が変わらないのなら、
コンパイラが変数で置き換えるだろう思うし気にならん。
そういうのがいちいち気になるのは単なる世代の差
としかいいようがないな。

> コンパイラが変数で置き換えるだろう思うし

そう思ってしまうゆとり世代恐るべし

>>21
そう思うなら自分で書いてコンパイルしてみろよ。
多分、C++以降の世代だからconstの本来の意味もしらないゆとり世代なんだろうけどw

subversionも文字列クラス相当品持ってますな

int func1 (char * buf1, char * buf2) {
　int sum = 0;
　for ( size_t i = 0 ; i < strlen(buf1) ; i++ ) {
　　for ( size_t j = 0 ; j < strlen(buf2) ; j++ ) {
　　　sum += buf2[j];
　　}
　}
　return sum;
}

以上のコードをVisualStudio2008で試してみたが、i,j共に毎回strlenが走っているな。
正確にはコンパイラの吐き出したインラインコードだけど。
ただし、x64をターゲットにすると一度しか評価しないコードになる所が面白いな。

ある程度の規模なら持たないほうが少ないんじゃないか？
>>18の意味で

それみたことか
時代は64bitなんだし、>>20, >>22の正しさが証明されたな
こればかりは世代の違いとしか言いようがない

constとconstではない変数は
書き込み禁止、あるいは書き込みをするつもりがない
という意味にとどまらず、ROMがRAMよりも安かった時代の
記憶対象の指定というクリティカルな意味をもっていた。
その後、ROMとRAMに価格差や性能差がなくなったせいで、
コンピュータの主記憶は組み込みを除いてRAMが主流になった。
で、コンパイラも進歩したおかげで(記憶クラスはコンパイラが判断して決められるようになった)、
特にC++以降の世代では最初の2行のような解釈で柔軟に使用できる修飾子になったわけだ。
strlenをループの条件式に使うのも単なる新しい世代(Javaやスクリプト言語以降の世代)
の発想だと思うし、俺は悪いと思いません。
そもそも今の時代、PC上で動くプログラムで速度がネックになるようなものは
ごく一部のジャンルに限られているんだから。

Javaにはstrlenはない、配列も長さ固定
strlenが必要なメジャーなスクリプト言語は見たことがない＞あったら教えてくれ

一体どこの世界の話なんだろう

>>24
> ただし、x64をターゲットにすると一度しか評価しないコードになる所が面白いな。

すごいな。

マイクロソフトのコンパイラはX64よりも前にIA64サポートやって、
その時にx86と同じエンジンじゃちっとも性能が出ないってことで、
統合しないで中身を個別に持つようになったんだろうな。

Javaやスクリプト言語にstrlenがあるなんて書いてないだろ。
見た目が冗長になるような書き方はLight Weightな言語では
普通やらないって意味でしょ。

>>29
64ビットにすることでのパフォーマンスアップを演出するために、
x86版とX64版で最適化の内容に差を付けたんだろう。

そこらの下手なコードのアプリで一番効くのが、strlenだもの。

>>30
というよりは、
コンピュータの内部アーキテクチャを知らない、処理が一瞬で終わるブラックボックスとして見る人たち
ってことだと思うよ。

なんかここの軟弱高級言語連中は他人の知識や能力を過小評価する傾向にあるようだな。
実はCよりもHDLを書く機会のほうが多いんだけど、コンピュータの内部は多分君らより詳しいぞ。
事務処理用途でスクリプト言語で書くときには速度なんて気にしねぇ。
Cにしても必要な速度がでていればそれまでだ。
仕事上は、ここで実行速度を速くしたらいくらの売り上げにつながるのか?
という考えでやるのがプロ。

> そこらの下手なコードのアプリで一番効くのが、strlenだもの。

もういちどスレの流れ読もうな。

プロなら、わざと遅いコードを書く。
とくに競合相手がいない場合のバージョン1.0では、できるだけ遅くしておくのがいい。

速度向上の余地を設けておくことで、
変更やバグ修正で処理が追加になって遅くなった時や、
あらかたもう改良の余地がなくなって最後のバージョンアップするときに、役に立つ。

>前999
> インデックス付き間接アドレッシングできないCPUとか
RISCをなめるなｗ

>>33
>コンピュータの内部は多分君らより詳しいぞ。
しかし、MicroBlazeやfreeMIPSのソースを眺めたくらいじゃx86の話は出来ないぞ。

C、C++の最適化について語るスレ 2
http://pc11.2ch.net/test/read.cgi/tech/1177808054/l50

メインメモリを最高速で舐める方法に話を戻そうぜ。

MOUDQAでFA

MOVDQAはLCPついてるから一部のCPUではストール発生?

>>16
コンパイラは引数のconstあり/なし両方のコードを生成するようにして使う側のコンパイル時にどっちを使うか選択すれば良いのにと言ってみるテスト。
引数多いと組み合わせ多いから大変そうだけど。

>>42
>>16みたいな例だとconstは何も問題を解決しない。
引数にconstがついていた場合、>>16のループが存在する関数がbuf1,buf2の内容を変更しないというだけで、例えばループの途中でスレッドが切り替わったり別のCPUによる処理でbuf1やbuf2の内容が変更される可能性は全く否定できない。

>>43
> 例えばループの途中でスレッドが切り替わったり別のCPUによる処理でbuf1やbuf2の内容が変更される可能性は全く否定できない。
そういうのが予想される場合は volatile つけないとダメなのでは？

でvolatileな変数をconstな引数を要求する関数には渡せないよね。

>>43
ああ、確かに。ええとD言語のinvariant的なものならおkかな。

つーか、volatileがあるからコンパイラが思い切った最適化をできるんだろ。
volatileは最適化抑制のためではなく、最適化を柔軟に行えるためにあるんだよ。
もしなかったら、コンパイラからどの変数がいつ更新されるかわからないので、
上の例だけでなく、殆どまともな最適化はできなくなる。

で、そろそろ
C、C++の最適化について語るスレ 2
http://pc11.2ch.net/test/read.cgi/tech/1177808054/l50
こっちでやってくれないか?

あの例で呼び出しを省略するのってマズくないか？

いい加減C, C++スレでやれ。

>>41
LCPが付いている命令はストールするみたいな印象を与える記事が多いけど、
実際にストールするLCP付き命令は一部だけだよ。
どんな命令でストールするのかはインテルのOptimization Reference Manualに
書いてある。SSE系の命令はLCPストールは発生しない。

>>12
for (int i = 0; i < s.length(); i++) {}
ってのと同じノリで終了判定にstrlenを使ったクソコードですね。わかります。

＃C++的にはstrlenの返値をconst intにすれば1回で済むのか

>>41
逆だと思う。
どうやら66hプレフィックスがある場合はまずSSE2以降のSIMD命令と予測して動いてる模様。
2バイト目を見てx86命令のサイズ変更の意味だったらストール、みたいな感じかと。

AMDにこういう問題がないのは、命令をL1に格納する段階で5ビット（FP/SIMDとInteger、命令長）の
タグをつけて振り分けを決めちゃうから。

だんごさんの見事な回答で、すべての問題が解決したな

LCPによるストール自体は初代P6から存在するものだよ。

>>50
length() は毎回数えたりしないだろ。
strlen() の問題はコレに近い↓
http://hiropon.net/cgi-bin/sb/log/20060422164633.html

いや、そういってるじゃん。
constの最適化の扱いもCとC++じゃ違うみたいだが

信じられるのはだんごさんの話だけだな

http://pc.watch.impress.co.jp/docs/2008/0603/msi.htm

Sandra Multimedia Intの数字を見るにATOMのSIMD ALUは128bit×2かな？

>>55
そもそもCとC++のconstって意味違うもん。団子らしくないな。
で、クロック計測と関係のないC, C++の話は終了。

TLBミスしたときのロードのレイテンシって、測ったことある人いる?

こんなんでどうですかね。
http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=tlb2.zip&refer=Upload
128バイトStrideのロードレイテンシと
4224(4096+128)バイトStrideのロードレイテンシを計測。
4224バイトStrideの方は、アクセスの度にTLBを消費することになります。

Core 2 Duo E8500の計測結果
>tlb2.exe
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:10676
CPU動作クロック : 3166.7 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.0ns) 3.0clock( 0.9ns)
8 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
16 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
32 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
64 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
128 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
256 個 : 3.0clock( 1.0ns) 8.3clock( 2.6ns)
512 個 : 15.1clock( 4.8ns) 25.1clock( 7.9ns)
1024 個 : 15.1clock( 4.8ns) 25.3clock( 8.0ns)
2048 個 : 15.1clock( 4.8ns) 25.3clock( 8.0ns)
4096 個 : 15.1clock( 4.8ns) 25.6clock( 8.1ns)
8192 個 : 15.1clock( 4.8ns) 26.2clock( 8.3ns)
16384 個 : 15.5clock( 4.9ns) 26.2clock( 8.3ns)
32768 個 : 15.5clock( 4.9ns) 46.1clock( 14.6ns)
65536 個 : 269.4clock( 85.1ns) 328.1clock(103.6ns)
131072 個 : 294.8clock( 93.1ns) 355.1clock(112.1ns)

16エントリのDTLB0をミスすると2clkのロス（インテルのマニュアル通りの結果）。
256エントリのDTLB1をミスすると10clkのロス。

>>60
前スレの>>1??
>>1なら>>1と名乗れよ。

>>1ではないけど…

だんごさんに比べると考察が甘いな

>>60
> 256 個 : 3.0clock( 1.0ns)
> 512 個 : 15.1clock( 4.8ns)

この部分がよくわからない。

ストライドが128バイトの場合、32回に1回、ページを跨ぐ。
つまり16エントリのDTLB0に収まるのは、16*32=512回の少し手前まで。
だから、
> 256 個 : 3.0clock( 1.0ns)
これは、すべてDTLB0ヒット

> 512 個 : 15.1clock( 4.8ns)
これは、すべてDTLB0ミス、すべてDLTB1ヒットと仮定すると、

DTLB0ミスのペナルティは約12クロックということになりませんか?

ぁぅぁぅぁぅ間違ってた

> 512 個 : 15.1clock( 4.8ns)
これは、31/32がDTLB0ヒット、
残りの1/32がDTLB0ミス、DLTB1ヒットと仮定すると、

15.1*32 - 3.0*31 = 390
DTLB0ミスのペナルティは約390クロックということになりませんか?

あーでも、ストライドが4224バイトのときの
> 16 個 : 3.0clock( 1.0ns)
> 32 個 : 5.0clock( 1.6ns)
からは、2クロックと言えるし・・・。

わけわかんなくなってきた。
たぶん自分の考えに何か大きな間違いがあるっぽい。

> 256 個 : 3.0clock( 1.0ns)
> 512 個 : 15.1clock( 4.8ns)

この部分はL1Dミスによるものです。
256*128=32KB
512*128=64KB

L1Dキャッシュのラインのサイズは128バイトもあるのか・・・orz

C2DのL1Dラインサイズは64バイトですが、
L2の兼ね合いもあって、128バイトごとにアクセスしています。
この計測では、キャッシュの奇数ラインにはアクセスしません。

>>60
PenM（Dothan）の計測結果
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:6D6
CPU動作クロック : 1097.3 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 2.7ns) 3.0clock( 2.7ns)
8 個 : 3.0clock( 2.7ns) 3.0clock( 2.7ns)
16 個 : 3.0clock( 2.7ns) 3.0clock( 2.7ns)
32 個 : 3.0clock( 2.7ns) 3.0clock( 2.7ns)
64 個 : 3.0clock( 2.7ns) 3.0clock( 2.7ns)
128 個 : 3.0clock( 2.7ns) 3.8clock( 3.4ns)
256 個 : 3.0clock( 2.7ns) 9.7clock( 8.8ns)
512 個 : 10.0clock( 9.1ns) 15.2clock( 13.9ns)
1024 個 : 10.0clock( 9.1ns) 152.4clock(138.9ns)
2048 個 : 10.0clock( 9.1ns) 174.4clock(158.9ns)
4096 個 : 10.0clock( 9.1ns) 186.5clock(169.9ns)
8192 個 : 10.2clock( 9.3ns) 193.4clock(176.2ns)
16384 個 : 47.7clock( 43.5ns) 205.3clock(187.1ns)
32768 個 : 151.4clock(138.0ns) 209.7clock(191.1ns)
65536 個 : 151.3clock(137.9ns) 211.6clock(192.8ns)
131072 個 : 152.7clock(139.1ns) 214.3clock(195.3ns)

Core2はTLBのEntry数がPenMの倍になってるから、
stride=4224bytesで128個までクロック数が安定してるね（256個でギリギリ）。

で、PenMの1024個のときが異様に遅い。
L2ヒットで、ページテーブルもL2ヒットくらいはすると思うのだが、
データかページテーブルのどっちかではメインメモリにアクセスしてるようだ。
何なんだろう？
あと、 512個のときにページテーブルがL1ヒットしてるっぽいが、奇数ラインに収まってるのかな。

参考リンクをメモしておきますね。

キャッシュの構造や働き(上級編) - TLB
http://journal.mycom.co.jp/column/architecture/011/index.html
ページング方式
http://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%BC%E3%82%B8%E3%83%B3%E3%82%B0%E6%96%B9%E5%BC%8F


>>59
http://pc11.2ch.net/test/read.cgi/tech/1136527588/44-47
PenMでDTLBミスすると、ページテーブルがL1ヒットのとき5clkのペナルティだった。

Pentium4(Northwood Bステップ)
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:F24
CPU動作クロック : 2400.1 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
8 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
16 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
32 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
64 個 : 2.4clock( 1.0ns) 4.5clock( 1.9ns)
128 個 : 18.3clock( 7.6ns) 56.0clock( 23.3ns)
256 個 : 18.3clock( 7.6ns) 65.2clock( 27.2ns)
512 個 : 18.4clock( 7.7ns) 65.5clock( 27.3ns)
1024 個 : 18.4clock( 7.6ns) 273.7clock(114.0ns)
2048 個 : 19.1clock( 8.0ns) 307.0clock(127.9ns)
4096 個 : 64.9clock( 27.1ns) 327.1clock(136.3ns)
8192 個 : 242.4clock(101.0ns) 353.3clock(147.2ns)
16384 個 : 242.6clock(101.1ns) 363.7clock(151.5ns)
32768 個 : 243.5clock(101.5ns) 368.1clock(153.4ns)
65536 個 : 245.2clock(102.2ns) 368.1clock(153.4ns)
131072 個 : 244.7clock(101.9ns) 368.4clock(153.5ns)

Pentium3(Coppermine ステッピング不明)
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:686
CPU動作クロック : 996.9 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 3.0ns) 3.0clock( 3.0ns)
8 個 : 3.0clock( 3.0ns) 3.0clock( 3.0ns)
16 個 : 3.0clock( 3.0ns) 3.0clock( 3.0ns)
32 個 : 3.0clock( 3.0ns) 3.0clock( 3.0ns)
64 個 : 3.0clock( 3.0ns) 3.8clock( 3.8ns)
128 個 : 3.0clock( 3.0ns) 8.6clock( 8.6ns)
256 個 : 7.0clock( 7.0ns) 16.3clock( 16.3ns)
512 個 : 7.0clock( 7.0ns) 20.3clock( 20.3ns)
1024 個 : 7.0clock( 7.0ns) 99.1clock( 99.4ns)
2048 個 : 23.9clock( 24.0ns) 112.3clock(112.7ns)
4096 個 : 94.1clock( 94.4ns) 127.5clock(127.9ns)
8192 個 : 94.1clock( 94.4ns) 131.5clock(132.0ns)
16384 個 : 94.1clock( 94.4ns) 132.5clock(133.0ns)
32768 個 : 94.2clock( 94.5ns) 132.6clock(133.0ns)
65536 個 : 94.2clock( 94.5ns) 136.5clock(136.9ns)
131072 個 : 94.2clock( 94.5ns) 144.1clock(144.6ns)

さて、Wolfdaleは出てるからMerom機のVAIO（笑）の出番か？

ちゃんとだんごさんの出番は残されていたな

Athlon64X2 5600+ Windsor
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:40F33
CPU動作クロック : 2806.4 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.1ns) 3.0clock( 1.1ns)
8 個 : 3.0clock( 1.1ns) 3.0clock( 1.1ns)
16 個 : 3.0clock( 1.1ns) 3.0clock( 1.1ns)
32 個 : 3.0clock( 1.1ns) 3.0clock( 1.1ns)
64 個 : 3.0clock( 1.1ns) 8.0clock( 2.9ns)
128 個 : 3.0clock( 1.1ns) 8.0clock( 2.9ns)
256 個 : 3.0clock( 1.1ns) 8.0clock( 2.9ns)
512 個 : 3.0clock( 1.1ns) 9.2clock( 3.3ns)
1024 個 : 12.4clock( 4.4ns) 36.2clock( 12.9ns)
2048 個 : 12.4clock( 4.4ns) 39.7clock( 14.2ns)
4096 個 : 12.4clock( 4.4ns) 43.7clock( 15.6ns)
8192 個 : 23.7clock( 8.4ns) 132.7clock( 47.3ns)
16384 個 : 128.8clock( 45.9ns) 193.4clock( 68.9ns)
32768 個 : 129.4clock( 46.1ns) 210.3clock( 74.9ns)
65536 個 : 129.5clock( 46.2ns) 209.8clock( 74.8ns)
131072 個 : 129.5clock( 46.2ns) 218.8clock( 78.0ns)

Brisbaneコアとの比較が気になる

Intel(R) Core(TM)2 CPU T5600 @ 1.83 GHz (Merom)
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:6F6
CPU動作クロック : 1828.8 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.6ns) 3.0clock( 1.7ns)
8 個 : 3.0clock( 1.7ns) 3.0clock( 1.6ns)
16 個 : 3.0clock( 1.7ns) 3.0clock( 1.7ns)
32 個 : 3.0clock( 1.7ns) 5.1clock( 2.8ns)
64 個 : 3.0clock( 1.7ns) 5.0clock( 2.7ns)
128 個 : 3.0clock( 1.7ns) 5.1clock( 2.8ns)
256 個 : 3.0clock( 1.7ns) 8.2clock( 4.5ns)
512 個 : 14.1clock( 7.7ns) 24.3clock( 13.3ns)
1024 個 : 14.3clock( 7.8ns) 24.9clock( 13.6ns)
2048 個 : 14.2clock( 7.8ns) 27.3clock( 14.9ns)
4096 個 : 14.4clock( 7.9ns) 36.6clock( 20.0ns)
8192 個 : 14.3clock( 7.8ns) 53.5clock( 29.2ns)
16384 個 : 91.2clock( 49.9ns) 171.5clock( 93.8ns)
32768 個 : 176.4clock( 96.4ns) 216.3clock(118.3ns)
65536 個 : 177.3clock( 96.9ns) 215.2clock(117.7ns)
131072 個 : 176.1clock( 96.3ns) 217.7clock(119.1ns)

Core 2 Duo [email protected]の計測結果

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:10676
CPU動作クロック : 4227.6 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.2clock( 0.7ns) 3.2clock( 0.7ns)
8 個 : 3.2clock( 0.7ns) 3.2clock( 0.7ns)
16 個 : 3.2clock( 0.8ns) 3.2clock( 0.7ns)
32 個 : 3.2clock( 0.8ns) 5.3clock( 1.2ns)
64 個 : 3.2clock( 0.7ns) 5.3clock( 1.2ns)
128 個 : 3.2clock( 0.8ns) 5.3clock( 1.2ns)
256 個 : 3.2clock( 0.7ns) 8.9clock( 2.1ns)
512 個 : 15.9clock( 3.8ns) 26.6clock( 6.3ns)
1024 個 : 16.1clock( 3.8ns) 26.7clock( 6.3ns)
2048 個 : 16.0clock( 3.8ns) 26.9clock( 6.4ns)
4096 個 : 16.0clock( 3.8ns) 27.1clock( 6.4ns)
8192 個 : 15.9clock( 3.8ns) 27.6clock( 6.5ns)
16384 個 : 16.3clock( 3.9ns) 27.5clock( 6.5ns)
32768 個 : 16.3clock( 3.8ns) 46.0clock( 10.9ns)
65536 個 : 116.0clock( 27.4ns) 245.3clock( 58.0ns)
131072 個 : 113.0clock( 26.7ns) 280.7clock( 66.4ns)

AthlonMP(Palomino A2ステップ)

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:661
CPU動作クロック : 1194.4 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns)
8 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns)
16 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns)
32 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns)
64 個 : 3.0clock( 2.5ns) 8.0clock( 6.7ns)
128 個 : 3.0clock( 2.5ns) 8.0clock( 6.7ns)
256 個 : 3.0clock( 2.5ns) 9.9clock( 8.3ns)
512 個 : 3.0clock( 2.5ns) 32.5clock( 27.2ns)
1024 個 : 20.0clock( 16.8ns) 63.6clock( 53.3ns)
2048 個 : 20.0clock( 16.8ns) 131.8clock(110.4ns)
4096 個 : 237.2clock(198.6ns) 206.9clock(173.2ns)
8192 個 : 237.4clock(198.8ns) 281.0clock(235.3ns)
16384 個 : 237.8clock(199.1ns) 281.0clock(235.2ns)
32768 個 : 238.0clock(199.3ns) 281.1clock(235.3ns)
65536 個 : 238.1clock(199.3ns) 286.1clock(239.5ns)
131072 個 : 238.1clock(199.3ns) 289.0clock(242.0ns)

>>72と比べると、悲惨だなぁ。
ハードウェア・プリフェッチがお馬鹿なのか、キャッシュミスすると100ns多くかかってる。

>>78
K7はTLBがデータキャッシュを使わない仕様だったような。

http://home.att.ne.jp/wave/shida/mflops3.html

2chではK7を使わないのは馬鹿っていう風潮があったけど、
どーみても、P6やNetBurstのほうが設計が良く見えてしまう。

お待たせVAIO（笑）type F＠T5500

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:6F2
CPU動作クロック : 1662.5 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.8ns) 3.0clock( 1.8ns)
8 個 : 3.0clock( 1.8ns) 3.0clock( 1.8ns)
16 個 : 3.0clock( 1.8ns) 3.0clock( 1.8ns)
32 個 : 3.0clock( 1.8ns) 5.1clock( 3.0ns)
64 個 : 3.0clock( 1.8ns) 5.1clock( 3.0ns)
128 個 : 3.0clock( 1.8ns) 5.1clock( 3.0ns)
256 個 : 3.0clock( 1.8ns) 8.1clock( 4.9ns)
512 個 : 14.3clock( 8.6ns) 24.5clock( 14.7ns)
1024 個 : 14.4clock( 8.6ns) 24.7clock( 14.8ns)
2048 個 : 14.3clock( 8.6ns) 27.6clock( 16.6ns)
4096 個 : 14.4clock( 8.6ns) 34.4clock( 20.7ns)
8192 個 : 14.3clock( 8.6ns) 49.4clock( 29.7ns)
16384 個 : 86.3clock( 51.9ns) 152.9clock( 92.0ns)
32768 個 : 161.5clock( 97.1ns) 193.9clock(116.6ns)
65536 個 : 169.0clock(101.7ns) 196.5clock(118.2ns)
131072 個 : 170.2clock(102.4ns) 196.4clock(118.2ns)

だんごさんのおかげで完璧なデータが揃ったな

Atom機が欲しいところだな。

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:6A0
CPU動作クロック : 2249.7 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
8 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
16 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
32 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
64 個 : 3.0clock( 1.3ns) 8.1clock( 3.6ns)
128 個 : 3.0clock( 1.3ns) 8.1clock( 3.6ns)
256 個 : 3.0clock( 1.3ns) 9.7clock( 4.3ns)
512 個 : 3.0clock( 1.3ns) 29.5clock( 13.1ns)
1024 個 : 20.2clock( 9.0ns) 68.8clock( 30.6ns)
2048 個 : 20.2clock( 9.0ns) 163.6clock( 72.7ns)
4096 個 : 20.2clock( 9.0ns) 188.5clock( 83.8ns)
8192 個 : 277.7clock(123.4ns) 301.9clock(134.2ns)
16384 個 : 277.8clock(123.5ns) 377.1clock(167.6ns)
32768 個 : 278.1clock(123.6ns) 378.6clock(168.3ns)
65536 個 : 278.0clock(123.6ns) 378.7clock(168.3ns)
131072 個 : 278.0clock(123.6ns) 384.5clock(170.9ns)

AthlonXP2500+(Barton)を×13.5で使ってる
結果最悪じゃね？(´・ω・｀)

とりあえずK8はK7に比べてダントツに良い設計なんだな。

Phenomを使ってる猛者はいないかな？
俺そろそろAthlonXPやめようと思うんだけど
データが見てみたい

>>60のと被るけどE8500で計測

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:10676
CPU動作クロック : 3170.2 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
8 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
16 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
32 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
64 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
128 個 : 3.0clock( 1.0ns) 5.0clock( 1.6ns)
256 個 : 3.0clock( 1.0ns) 8.4clock( 2.7ns)
512 個 : 15.2clock( 4.8ns) 25.3clock( 8.0ns)
1024 個 : 15.3clock( 4.8ns) 25.6clock( 8.1ns)
2048 個 : 15.3clock( 4.8ns) 25.4clock( 8.0ns)
4096 個 : 15.3clock( 4.8ns) 25.7clock( 8.1ns)
8192 個 : 15.2clock( 4.8ns) 26.4clock( 8.3ns)
16384 個 : 15.6clock( 4.9ns) 26.3clock( 8.3ns)
32768 個 : 15.7clock( 4.9ns) 106.6clock( 33.6ns)
65536 個 : 200.2clock( 63.2ns) 254.1clock( 80.1ns)
131072 個 : 218.2clock( 68.8ns) 286.4clock( 90.3ns)

65536超えたあたりからはうちのがレイテンシ短いけどたぶんメモリが良いんだろう。
愛国者（笑）のPC6400 2GB×4です。

ちょいとイレギュラーだが

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:200F65
CPU動作クロック : 800.2 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 3.8ns) 3.0clock( 3.8ns)
8 個 : 3.0clock( 3.8ns) 3.0clock( 3.8ns)
16 個 : 3.0clock( 3.8ns) 3.0clock( 3.8ns)
32 個 : 3.0clock( 3.8ns) 3.0clock( 3.8ns)
64 個 : 3.0clock( 3.8ns) 6.4clock( 8.1ns)
128 個 : 3.0clock( 3.8ns) 14.0clock( 17.5ns)
256 個 : 8.1clock( 10.1ns) 28.6clock( 35.7ns)
512 個 : 8.5clock( 10.7ns) 27.2clock( 34.0ns)
1024 個 : 21.9clock( 27.4ns) 41.3clock( 51.6ns)
2048 個 : 23.5clock( 29.4ns) 40.9clock( 51.1ns)
4096 個 : 23.3clock( 29.1ns) 40.5clock( 50.7ns)
8192 個 : 23.7clock( 29.6ns) 44.1clock( 55.1ns)
16384 個 : 23.7clock( 29.7ns) 137.9clock(172.3ns)
32768 個 : 99.1clock(123.9ns) 154.8clock(193.4ns)
65536 個 : 192.1clock(240.1ns) 203.8clock(254.7ns)
131072 個 : 195.6clock(244.4ns) 214.1clock(267.6ns)

ちょびっとレジストリをいじると、こうなる

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:706
CPU動作クロック : 800.1 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 14.0clock( 17.5ns) 14.0clock( 17.5ns)
8 個 : 14.0clock( 17.5ns) 14.0clock( 17.5ns)
16 個 : 14.0clock( 17.5ns) 14.0clock( 17.5ns)
32 個 : 14.0clock( 17.5ns) 14.0clock( 17.5ns)
64 個 : 14.0clock( 17.5ns) 28.2clock( 35.3ns)
128 個 : 14.0clock( 17.5ns) 27.9clock( 34.9ns)
256 個 : 14.0clock( 17.5ns) 37.7clock( 47.1ns)
512 個 : 14.0clock( 17.5ns) 34.7clock( 43.4ns)
1024 個 : 34.0clock( 42.5ns) 58.5clock( 73.1ns)
2048 個 : 34.6clock( 43.2ns) 57.8clock( 72.2ns)
4096 個 : 34.6clock( 43.3ns) 57.2clock( 71.5ns)
8192 個 : 34.9clock( 43.7ns) 70.6clock( 88.2ns)
16384 個 : 34.9clock( 43.6ns) 192.6clock(240.7ns)
32768 個 : 111.3clock(139.1ns) 225.4clock(281.7ns)
65536 個 : 209.9clock(262.4ns) 233.7clock(292.1ns)
131072 個 : 213.4clock(266.7ns) 235.2clock(293.9ns)

L1無効？

K6-2なWin98機で動かそうと思ったら「メモリ不足で（ｒｙ」って言われた。
96MBしか積んでないから528MBなんて確保できんわなぁorz

>>89
IA-32ELとItaniumですか？

L1キャッシュなんか無効にしたらWindowsの起動に
どれだけかかるようになるかゾッとする

>>75
X2 3600+
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:60FB1
CPU動作クロック : 2374.2 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
8 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
16 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
32 個 : 3.0clock( 1.3ns) 3.0clock( 1.3ns)
64 個 : 3.0clock( 1.3ns) 8.0clock( 3.4ns)
128 個 : 3.0clock( 1.3ns) 8.0clock( 3.4ns)
256 個 : 3.0clock( 1.3ns) 8.0clock( 3.4ns)
512 個 : 3.0clock( 1.3ns) 9.4clock( 3.9ns)
1024 個 : 20.2clock( 8.5ns) 42.1clock( 17.7ns)
2048 個 : 20.2clock( 8.5ns) 45.7clock( 19.2ns)
4096 個 : 20.3clock( 8.5ns) 139.3clock( 58.7ns)
8192 個 : 123.7clock( 52.1ns) 210.3clock( 88.6ns)
16384 個 : 123.8clock( 52.1ns) 227.1clock( 95.7ns)
32768 個 : 124.6clock( 52.5ns) 226.6clock( 95.4ns)
65536 個 : 125.0clock( 52.6ns) 227.2clock( 95.7ns)
131072 個 : 124.8clock( 52.6ns) 228.0clock( 96.0ns)

なるのど>>89-90はMercedか

Phenom X4 9850 BE @3Ghz

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:100F23
CPU動作クロック : 2507.6 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 2.5clock( 1.0ns) 2.5clock( 1.0ns)
8 個 : 2.5clock( 1.0ns) 2.5clock( 1.0ns)
16 個 : 2.5clock( 1.0ns) 2.5clock( 1.0ns)
32 個 : 2.5clock( 1.0ns) 2.5clock( 1.0ns)
64 個 : 2.5clock( 1.0ns) 6.7clock( 2.7ns)
128 個 : 2.5clock( 1.0ns) 6.7clock( 2.7ns)
256 個 : 2.5clock( 1.0ns) 6.7clock( 2.7ns)
512 個 : 2.5clock( 1.0ns) 8.1clock( 3.2ns)
1024 個 : 12.8clock( 5.1ns) 38.0clock( 15.2ns)
2048 個 : 12.8clock( 5.1ns) 44.9clock( 17.9ns)
4096 個 : 12.8clock( 5.1ns) 67.4clock( 26.9ns)
8192 個 : 44.5clock( 17.8ns) 81.2clock( 32.4ns)
16384 個 : 44.6clock( 17.8ns) 138.0clock( 55.0ns)
32768 個 : 121.2clock( 48.3ns) 226.4clock( 90.3ns)
65536 個 : 121.9clock( 48.6ns) 236.5clock( 94.3ns)
131072 個 : 123.3clock( 49.2ns) 240.3clock( 95.8ns)

またAMDはRDTSCの実装を手抜きしたのか。

だな
クロックに1.2かけた値が正解だな

え?
2.5GHzで起動して、動作中に3.0GHzに変更したから、>>97のような結果になるんでしょ。
TSCの周波数は動作中には変らないのが仕様であり、途中でコアのクロック変更したら
TSCとコアの周波数が一致しなくなるのは、正しい挙動だと思う。

ま、AMDには、コアの周波数を変えたらTSCの周波数まで変ってしまうというバグの前科があるがね。

AMDのCodeAnalystでシミュレーションしてみた。
K7とK8どちらでも結果は同じでしたよ。

TLBヒット時
DPI=3
IDEC Dispatch×多数
SCHED Scheduling
EXEC Ls Probing
ADDGEN Address generating
DACC Cache and TLB hit
RESP Ls response
Waiting to retire×数回
Retired

TLBミス時
DPI=9
IDEC Dispatch×多数
SCHED Scheduling
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss
DACC TLB miss
DACC TLB miss
SCHED Ls Reprobing
EXEC Ls Probing
ADDGEN Address generating
DACC Cache and TLB hit
RESP Ls Response
Waiting to retire×数回
Retired

実測ではDPIが8なのに、シミュレーションでは9となってる。

TLBヒットだがL1Dキャッシュミス時 (stride=128bytesで、1024 個 : 20.0clock)

DPI=20
IDEC Dispatch
SCHED Scheduling
EXEC Ls Probing
ADDGEN Address generating
DACC TLB hit but DCache miss×14
L2 read data hit×8
Waiting to retire×22
L2 read data miss×8 ← プリフェッチか？
Waiting to retire×多数
Retired

TLBミス(L2DTLBもミス?)時(stride=4224bytesで、512個)
DPI=16,21,46のミックスで、大半は46

DPI=46の場合
IDEC Dispatch
SCHED Scheduling
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss×2
SCHED Ls Reprobing
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss×3
SCHED Ls Reprobing
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss×3SCHED Ls Reprobing
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss×2
L2 read data hit×8
EXEC Ls Probing
ADDGEN Address generating
DACC TLB miss×3SCHED Ls Reprobing
EXEC Ls Probing
ADDGEN Address generating
DACC TLB hit but DCache miss×5
L2 read data hit×8
Waiting to retire×多数
L2 read data miss×8
Waiting to retire×多数
Retired

>>104を見ると、K7のL2DTLBがL2D$を使わずに都度メインメモリに読みに行くってのはガセっぽいな。

TLBミス5回って何やってんのかな。

phenomはL3キャッシュ積んだから少しはマシになると思ってたけど
X2と大差ないじゃん
やっぱりCore2にすっかな〜悩む

>>107
いやいやL3キャッシュの分はハッキリと差が出てるじゃん

X2 3600+
4096 個 : 20.3clock( 8.5ns) 139.3clock( 58.7ns)
8192 個 : 123.7clock( 52.1ns) 210.3clock( 88.6ns)
16384 個 : 123.8clock( 52.1ns) 227.1clock( 95.7ns)

Phenom X4 9850 BE @3Ghz
4096 個 : 12.8clock( 5.1ns) 67.4clock( 26.9ns)
8192 個 : 44.5clock( 17.8ns) 81.2clock( 32.4ns)
16384 個 : 44.6clock( 17.8ns) 138.0clock( 55.0ns)

うおっ本当だゴメソ
かなり速くなるんだな

>>75と比べるべし
4096 個 : 12.4clock( 4.4ns) 43.7clock( 15.6ns)
8192 個 : 23.7clock( 8.4ns) 132.7clock( 47.3ns)
16384 個 : 128.8clock( 45.9ns) 193.4clock( 68.9ns)

すみません、遅くなりました。
>>93さんの予想どおりです。
ちゃんと最初からCPU名を書くべきでした。ごめんなさい。

やっと追いついた。コレクタ向けに貼っておく。
Pentium 4 CPU 2.26GHz
--
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:F24
CPU動作クロック : 2266.3 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 2.0clock( 0.9ns) 2.0clock( 0.9ns)
8 個 : 2.0clock( 0.9ns) 2.0clock( 0.9ns)
16 個 : 2.0clock( 0.9ns) 2.0clock( 0.9ns)
32 個 : 2.0clock( 0.9ns) 2.0clock( 0.9ns)
64 個 : 2.9clock( 1.3ns) 5.5clock( 2.4ns)
128 個 : 18.3clock( 8.1ns) 56.0clock( 24.7ns)
256 個 : 18.3clock( 8.1ns) 56.0clock( 24.7ns)
512 個 : 18.4clock( 8.1ns) 66.6clock( 29.4ns)
1024 個 : 18.3clock( 8.1ns) 317.4clock(140.1ns)
2048 個 : 19.0clock( 8.4ns) 357.8clock(157.9ns)
4096 個 : 72.4clock( 31.9ns) 381.0clock(168.1ns)
8192 個 : 278.7clock(123.0ns) 412.4clock(182.0ns)
16384 個 : 281.6clock(124.2ns) 425.1clock(187.6ns)
32768 個 : 280.0clock(123.6ns) 427.8clock(188.8ns)
65536 個 : 279.6clock(123.4ns) 413.7clock(182.6ns)
131072 個 : 279.5clock(123.3ns) 418.5clock(184.7ns)

K10STATからではなくBIOSからOCしました。
何故か微妙に遅くなっている気がする・・・

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:AuthenticAMD CPUID:100F23
CPU動作クロック : 3009.1 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
8 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
16 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
32 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
64 個 : 3.0clock( 1.0ns) 8.0clock( 2.7ns)
128 個 : 3.0clock( 1.0ns) 8.0clock( 2.7ns)
256 個 : 3.0clock( 1.0ns) 8.0clock( 2.7ns)
512 個 : 3.0clock( 1.0ns) 9.7clock( 3.2ns)
1024 個 : 15.3clock( 5.1ns) 45.7clock( 15.2ns)
2048 個 : 15.4clock( 5.1ns) 54.2clock( 18.0ns)
4096 個 : 15.4clock( 5.1ns) 80.5clock( 26.8ns)
8192 個 : 52.8clock( 17.5ns) 102.2clock( 34.0ns)
16384 個 : 53.1clock( 17.6ns) 180.6clock( 60.0ns)
32768 個 : 146.3clock( 48.6ns) 260.0clock( 86.4ns)
65536 個 : 146.7clock( 48.7ns) 286.6clock( 95.2ns)
131072 個 : 149.2clock( 49.6ns) 291.1clock( 96.8ns)

>>113
ほとんど変ってないように見えるけど。

所要クロック数は変ってるけど、所要時間は変ってない。

>>114
>>115
たしかに変わらないですね、すみません

賑やかし。
E6320
--
load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:6F6
CPU動作クロック : 1866.7 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock( 1.6ns) 3.0clock( 1.6ns)
8 個 : 3.0clock( 1.6ns) 3.0clock( 1.6ns)
16 個 : 3.0clock( 1.6ns) 3.0clock( 1.6ns)
32 個 : 3.0clock( 1.6ns) 5.0clock( 2.7ns)
64 個 : 3.0clock( 1.6ns) 5.0clock( 2.7ns)
128 個 : 3.0clock( 1.6ns) 5.0clock( 2.7ns)
256 個 : 3.0clock( 1.6ns) 7.9clock( 4.2ns)
512 個 : 14.2clock( 7.6ns) 23.7clock( 12.7ns)
1024 個 : 14.4clock( 7.7ns) 23.8clock( 12.8ns)
2048 個 : 14.1clock( 7.6ns) 24.0clock( 12.9ns)
4096 個 : 14.5clock( 7.8ns) 24.2clock( 13.0ns)
8192 個 : 14.3clock( 7.7ns) 25.2clock( 13.5ns)
16384 個 : 14.7clock( 7.9ns) 51.7clock( 27.7ns)
32768 個 : 115.3clock( 61.8ns) 167.6clock( 89.8ns)
65536 個 : 184.8clock( 99.0ns) 215.4clock(115.4ns)
131072 個 : 167.3clock( 89.6ns) 196.4clock(105.2ns)

Core2 Extreme Qx9650

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:10676
CPU動作クロック : 2999.7 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 3.0clock(1.0ns) 3.0clock(1.0ns)
8 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
16 個 : 3.0clock( 1.0ns) 3.0clock( 1.0ns)
32 個 : 3.0clock(1.0ns) 5.0clock( 1.7ns)
64 個 : 3.0clock( 1.0ns) 5.0clock( 1.7ns)
128 個 : 3.0clock( 1.0ns) 5.0clock( 1.7ns)
256 個 : 3.0clock( 1.0ns) 8.3clock( 2.8ns)
512 個 : 15.0clock( 5.0ns) 24.9clock( 8.3ns)
1024 個 : 15.1clock( 5.0ns) 25.3clock(8.4ns)
2048 個 : 15.1clock( 5.0ns) 25.2clock(8.4ns)
4096 個 : 15.1clock( 5.0ns) 25.4clock(8.5ns)
8192 個 : 15.1clock( 5.1ns) 26.1clock(8.7ns)
16384 個 : 15.1clock( 5.1ns) 26.1clock(8.6ns)
32768 個 : 15.4clock(5.0ns) 40.2clock(13.4ns)
65536 個 : 108.0clock(36.0ns) 223.0clock(74.3ns)
131072 個 : 100.9clock(33.6ns) 259.3clock(86.4ns)

>>118
何これ馬鹿みたいに速いな

そりゃ速いのが売りの超ハイエンドだもん。

チップセットがいいんだろうな
P35ごときじゃ敵うまいて

モバイルCeleron 2.4GHzなノートPC

load レイテンシ 計測ツール v0.2改 4224byte stride
vender:GenuineIntel CPUID:F29
CPU動作クロック : 2392.5 MHz

ｱｸｾｽﾃﾞｰﾀ数 stride=128bytes stride=4224bytes
4 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
8 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
16 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
32 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns)
64 個 : 2.1clock( 0.9ns) 2.3clock( 1.0ns)
128 個 : 18.4clock( 7.7ns) 57.4clock( 24.0ns)
256 個 : 18.4clock( 7.7ns) 813.0clock(339.8ns)
512 個 : 18.4clock( 7.7ns) 818.2clock(342.0ns)
1024 個 : 18.4clock( 7.7ns) 788.5clock(329.6ns)
2048 個 : 108.6clock( 45.4ns) 779.7clock(325.9ns)
4096 個 : 801.1clock(334.9ns) 796.4clock(332.9ns)
8192 個 : 799.8clock(334.3ns) 820.9clock(343.1ns)
16384 個 : 800.6clock(334.7ns) 845.8clock(353.5ns)
32768 個 : 802.0clock(335.2ns) 848.0clock(354.4ns)
65536 個 : 801.6clock(335.1ns) 847.8clock(354.4ns)
131072 個 : 801.6clock(335.0ns) 848.0clock(354.4ns)

12MBもの大きさのL2キャッシュが乗ってるCPUだから、
131072個でさえも、かなりの割合でL2キャッシュにヒットしていると思う。
ソースの定数定義を書き換えてもっと大きくしてみるといいと思う。

L1キャッシュにヒットした場合のレイテンシだけは、
>>121は>>77に次いで速いんだけどね・・・

12MBって言っても6MB＋6MBで反対側のダイのデータアクセスするのにFSBを経由するよ

> FSBを経由するよ

マジ！？

ん？クロスバー接続か何かだと思ったの？
Pentium Dと同じ方式でWolfdaleコアを2個積めて共有バス線に繋いだだけのもの。
反対側のL2は直接管理できないよ。

マルチコアとしては最も汚い実装ですな。
だからって某社のネイティブクアッドコアが速いかっていうとそうでもないのがね。

だとすると、
反対側のダイのキャッシュにdirtyフラグが立ってるデータを
アクセスしようとしたときって、
通常メモリ読み込むのとあんまりかわらんということかな
さすがにレイテンシは違うか

128バイト・ストライドは、キャッシュに読むのが128バイト単位だと、
隙間ゼロのベッタリなシーケンシャルアクセスになるわけで、
プロセッサのプリフェッチや、チップセットのメモリコントローラの先読みによって、
ただの「TLBヒット時のレイテンシ」とは言えない小さな値になるのだと思う。

The redesigned IntelR X38 Express Chipset Memory Controller Hub (MCH) architecture
(中略)
reduction of memory access latency with Intel Fast Memory Access.
とかいうし。
同じチップセットで65nm世代のCore2を動かした時の値と比較してみたいね。

ちなみにX38チップセットのデータシートを見ていたら、
ttp://download.intel.com/design/chipsets/datashts/31761001.pdf
> Supports a memory thermal management scheme to selectively manage reads
> and/or writes. Memory thermal management can be triggered either by on-die
> thermal sensor, or by preset limits. Management limits are determined by weighted
> sum of various commands that are scheduled on the memory interface.
というのを見つけた。
メモリを連続でフル稼働させると温度が上がりすぎる or メモリ用の電源回路の容量をオーバーする
ってことで、その対策なんだろうなぁ。
ベンチマークやプログラムによっては、引っかかるかも?

メインメモリにアクセスしに行ったときのレイテンシは、
メモリコントローラをプロセッサに直結しても50nsはかかるのだから、
FGMTをやればいいと思うんだけど、なんでAMDはやらないんだ?

Intelが欲張ってSMTやって評価が微妙だったから?

処理量の多いアプリはキャッシュにヒットするように気をつけて作られているため、
FGMTを導入すると性能半分のコアが倍の数あるような感じになってしまうから?

ごめん、
×FGMT
○CGMT

そこまで手が回ってないのが正直なところじゃね？
K8なんか立ち上げるだけで精一杯だったろうし。
K8改のK10もチャレンジしてる余裕は無かっただろう。
Bulldozerになれば何らかのマルチスレッディングは入るのではないかと。

その暁にはかつて似非デュアルだとか、疑似デュアルなどと
頑張って吹聴していた某社信者がまたもやもやするわけですね、わかります。

x86はパイプラインが長くて複雑だから、
SPARCにFGMTを導入したNiagaraのようには簡単にいかないのだろう。

とはいえ、
1コアならCGMTで2つのコンテキストの進行具合が偏ることが大きな問題にもなったろうが、
4コアなら偏りによる問題がかなり軽減されるのではないか、と。

問題はおそらく演算ユニット等の稼働率が上がることでの消費電力の増大だろう。
同じTDP130Wなら、2スレッド2コアよりも、1スレッド4コアのほうが良いという判断かと。
IntelだけでなくAMDも、大量生産によるスケールメリットでの力押しが可能だから。

ただでさえ製造プロセスルールと生産力で遅れを取ってるんだしAMDも何かしらIntelの先を行く要素がないとね。
Nehalemでメモコン・HyperTransportの強みすらなくなるし。

AVXにインスパイヤされて非SIMDでも3オペランド導入する？

VIA(というか、元IDTのCT)が、シングルコア、シングルスレッドのローエンドにフォーカスしているのがモッタイナイ。

インオーダー、非スーパースケーラのコアで、
その代わりSMTあるいはFGMTあるいはCGMTを装備し、
それを16コアくらい積んでくれたら面白いのになぁ。

非スーパースケーラならSMTは無理でしょ

>>133
SIMDはパフォーマンスに敏感な一部のコードだけの話だから、
各種CPUに合わせてチューニングした別コードを用意できるから、
次々に新命令を追加していっても構わないけど、

一般の命令をAMD64とは別に新しく追加するとなると、
AMD64を強力に支援したマイクロソフトもブチ切れるかも。
3オペランドやるならIA64命令セットを使えとか言い出したり。

>>134
Core2が片肺の代わりに、そういう小コアが8個載ってるとかいいね。
まあ、技術的に不可能でなくても、まだ時代が十分に進んでいないから無理かな。
動画エンコでもCore2Quadでいいだろうし、買うのは俺たちくらいだろう。

>>134
そういうCPUは、膨大なメモリチャネルがないと、結局はストールするのよ。

ttp://pc11.2ch.net/test/read.cgi/jisaku/1200490923/412
って見解が出てたけど、どうなんだろ。
前後の流れは、
ttp://pc11.2ch.net/test/read.cgi/jisaku/1200490923/409-412

さすが自作PC板は専門家が多いな

ストライドを小さくしてみた

ストライド128バイト→199ns
ストライド64バイト→139ns

見事に60ns・・・

CAS Latency 2.5clock + レジスタードによる1clock
バースト長8で4clock
CAS Latencyが2.5クロックだったので後ろに埋め合わせで0.5クロック
合計8クロック×7.5ns=60ns

計算これで合ってるかな?


もし合ってるとして、
ストライド128バイトの199ns は 79ns + 60ns + 60ns
ストライド64バイトの139ns は 79ns + 60ns
79nsの間はプリチャージとか、バンクをアクティブにするとか、そういうことをやってるのかな・・・。

Athlon（K7）が、ページディスクリプタをキャッシュできない
(TLBへの読み込みのみ対応、L1・L2へは読まない)
という仕様な上に、ワンセット16バイトで充分なのを128バイト単位じゃないと読み込めない。

という推測が本当なら、このテストでペナルティが大きすぎるのも理解できる感じか。

K7が設計された時点の想定アプリケーションでは、
小さなTLBでも十分だったし、
データキャッシュを汚染しないことのほうが大切だったのだろう。

Duronでは、
L1D$が64KB
L2$が64KB
これしかないとはいえ、
L2TLBの256エントリ×16バイト=4KBくらい
構わないと思うんだけどなぁ。

複雑なストリーム検出機能を持つ代わりにバグっていて機能を止められていたP4のプリフェッチよりも、
強制的に次を読込むという単純なプリフェッチのほうが、実装が簡単でなおかつ効果的だったのだろう。

CPUの設定レジスタをいじるとハードウェアプリフェッチをOFFにできるのかな。
ちょっとAthlonのデータシート見てみるわ。

>>143
ベンチマークのレイテンシの値は、あくまでも、平均値。

K7のハードウェア・プリフェッチは、
命令によってメモリをreadした際にキャッシュミスした時に行われ、
当該のキャッシュラインのfillの次に、次のキャッシュラインをfillする
というものらしい。

stride=128bytesのとき、
load命令 → 64バイトread + 64バイトprefetch
load命令 → 64バイトread + 64バイトprefetch
load命令 → 64バイトread + 64バイトprefetch
load命令 → 64バイトread + 64バイトprefetch
という繰り返しで、その平均が199ns

stride=64bytesのとき、
load命令 → 64バイトread + 64バイトprefetch
load命令 → キャッシュにヒットしているのでメモリアクセスなし
load命令 → 64バイトread + 64バイトprefetch
load命令 → キャッシュにヒットしているのでメモリアクセスなし
という繰り返しで、その平均が139ns

むむ、おかしいね。値は半分になるはずなのに。

stride=32bytesのとき、いくつになるの? >>78

K6とK8のMSRのEFERの資料はあったが、K7はないな・・・。

K6と互換かもしれないので読んでみたが、ゼロだった。
試しにビットを建ててみても、なんの変化もなし。

>>147
70ns

tlb2にランダムなページを読むテストを追加してみました。
ttp://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=tlb2r.zip&refer=Upload

load レイテンシ 計測ツール v0.2改R 4224byte stride
vender:GenuineIntel CPUID:F24
CPU動作クロック : 2400.1 MHz

ｱｸｾｽﾃﾞｰﾀ数 Seq.stride=128bytes Seq.stride=4224bytes Rnd.stride=4096bytes
4 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 2.0clock( 0.8ns)
8 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 19.6clock( 8.2ns)
16 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 20.0clock( 8.3ns)
32 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 21.6clock( 9.0ns)
64 個 : 2.4clock( 1.0ns) 4.0clock( 1.7ns) 21.8clock( 9.1ns)
128 個 : 18.3clock( 7.6ns) 55.0clock( 22.9ns) 93.3clock( 38.9ns)
256 個 : 18.3clock( 7.6ns) 55.5clock( 23.1ns) 358.6clock(149.4ns)
512 個 : 18.3clock( 7.6ns) 60.5clock( 25.2ns) 358.3clock(149.3ns)
1024 個 : 18.4clock( 7.6ns) 197.5clock( 82.3ns) 359.4clock(149.8ns)
2048 個 : 18.6clock( 7.8ns) 285.4clock(118.9ns) 360.5clock(150.2ns)
4096 個 : 50.0clock( 20.8ns) 325.8clock(135.8ns) 364.7clock(151.9ns)
8192 個 : 243.4clock(101.4ns) 354.4clock(147.7ns) 369.2clock(153.8ns)
16384 個 : 241.5clock(100.6ns) 365.4clock(152.3ns) 377.5clock(157.3ns)
32768 個 : 244.0clock(101.6ns) 368.1clock(153.4ns) 384.4clock(160.2ns)
65536 個 : 243.5clock(101.5ns) 368.2clock(153.4ns) 389.7clock(162.4ns)
131072 個 : 244.4clock(101.8ns) 368.3clock(153.5ns) 404.3clock(168.4ns)

TLBミスのペナルティを調べようという元の目的から逸脱してしまったかも。
ついでに、メモリの空き容量を見てデータ数を変えるようにしました。

ごめん、オオボケだ。

ランダムにしたからって4096バイト境界の先頭ばかりアクセスしたら、
キャッシュの一部しか使わないから、シーケンシャルの4224バイトと
比較できないじゃないか。

直してきます。

直しました。
tlb2r → tlb2r2 です。
ttp://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=tlb2r2.zip&refer=Upload

load レイテンシ 計測ツール v0.2改R 4224byte stride
vender:GenuineIntel CPUID:F24
CPU動作クロック : 2400.1 MHz

ｱｸｾｽﾃﾞｰﾀ数 Seq.stride=128bytes Seq.stride=4224bytes Rnd.stride=4224bytes
4 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 2.0clock( 0.8ns)
8 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 2.0clock( 0.8ns)
16 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 2.0clock( 0.8ns)
32 個 : 2.0clock( 0.8ns) 2.0clock( 0.8ns) 2.0clock( 0.8ns)
64 個 : 3.0clock( 1.2ns) 4.6clock( 1.9ns) 3.8clock( 1.6ns)
128 個 : 18.3clock( 7.6ns) 55.0clock( 22.9ns) 53.1clock( 22.1ns)
256 個 : 18.3clock( 7.6ns) 55.6clock( 23.2ns) 55.7clock( 23.2ns)
512 個 : 18.3clock( 7.6ns) 358.1clock(149.2ns) 359.1clock(149.6ns)
1024 個 : 18.4clock( 7.7ns) 343.5clock(143.1ns) 345.0clock(143.8ns)
2048 個 : 18.5clock( 7.7ns) 339.2clock(141.3ns) 340.2clock(141.7ns)
4096 個 : 67.3clock( 28.0ns) 340.2clock(141.8ns) 340.6clock(141.9ns)
8192 個 : 243.9clock(101.6ns) 352.6clock(146.9ns) 355.0clock(147.9ns)
16384 個 : 242.8clock(101.2ns) 361.2clock(150.5ns) 372.6clock(155.3ns)
32768 個 : 244.0clock(101.7ns) 368.0clock(153.3ns) 402.2clock(167.6ns)
65536 個 : 245.2clock(102.2ns) 368.3clock(153.5ns) 465.6clock(194.0ns)
131072 個 : 243.3clock(101.4ns) 368.2clock(153.4ns) 543.4clock(226.4ns)

>>141
VirtualAllocにPAGE_NOCACHEを付けて比較してみてもらえませんか?

150は何を調べたいの?

VPC2004 ＠Power PC G4 1.4GHz, MacOS 10.4


load レイテンシ 計測ツール v0.2改R 4224byte stride
vender:Virtual CPU CPUID:684
CPU動作クロック : 1391.9 MHz

ｱｸｾｽﾃﾞｰﾀ数 Seq.stride=128bytes Seq.stride=4224bytes Rnd.stride=4224bytes
4 個 : 1.4clock( 1.0ns) 1.4clock( 1.0ns) 1.4clock( 1.0ns)
8 個 : 1.4clock( 1.0ns) 1.4clock( 1.0ns) 1.4clock( 1.0ns)
16 個 : 1.4clock( 1.0ns) 1.4clock( 1.0ns) 1.4clock( 1.0ns)
32 個 : 1.4clock( 1.0ns) 1.4clock( 1.0ns) 1.4clock( 1.0ns)
64 個 : 1.4clock( 1.0ns) 1.4clock( 1.0ns) 1.4clock( 1.0ns)
128 個 : 1.4clock( 1.0ns) 1.8clock( 1.3ns) 1.8clock( 1.3ns)
256 個 : 1.4clock( 1.0ns) 14.5clock( 10.4ns) 14.6clock( 10.5ns)
512 個 : 5.0clock( 3.6ns) 14.6clock( 10.5ns) 14.6clock( 10.5ns)
1024 個 : 5.0clock( 3.6ns) 15.7clock( 11.2ns) 16.8clock( 12.0ns)
2048 個 : 7.2clock( 5.2ns) 38.0clock( 27.3ns) 33.0clock( 23.7ns)
4096 個 : 31.3clock( 22.5ns) 106.8clock( 76.8ns) 112.3clock( 80.7ns)
8192 個 : 59.0clock( 42.4ns) 6187.4clock(4445.5ns) 6530.5clock(4691.9ns)
16384 個 : 70.4clock( 50.6ns) 6386.1clock(4588.2ns) 8775.7clock(6305.1ns)

>>153
PAGE_NOCACHEなし

load レイテンシ 計測ツール v0.2改R 4224byte stride
vender:AuthenticAMD CPUID:661
CPU動作クロック : 1194.4 MHz

ｱｸｾｽﾃﾞｰﾀ数 Seq.stride=128bytes Seq.stride=4224bytes Rnd.stride=4224bytes
4 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns) 3.0clock( 2.5ns)
8 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns) 3.0clock( 2.5ns)
16 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns) 3.0clock( 2.5ns)
32 個 : 3.0clock( 2.5ns) 3.0clock( 2.5ns) 3.0clock( 2.5ns)
64 個 : 3.0clock( 2.5ns) 8.0clock( 6.7ns) 8.0clock( 6.7ns)
128 個 : 3.0clock( 2.5ns) 8.0clock( 6.7ns) 8.0clock( 6.7ns)
256 個 : 3.0clock( 2.5ns) 8.9clock( 7.5ns) 9.0clock( 7.5ns)
512 個 : 3.0clock( 2.5ns) 31.5clock( 26.4ns) 32.7clock( 27.4ns)
1024 個 : 20.0clock( 16.8ns) 69.4clock( 58.1ns) 62.3clock( 52.2ns)
2048 個 : 20.0clock( 16.8ns) 159.7clock(133.7ns) 243.4clock(203.8ns)
4096 個 : 237.1clock(198.5ns) 225.9clock(189.1ns) 267.2clock(223.7ns)
8192 個 : 237.4clock(198.7ns) 280.9clock(235.2ns) 298.6clock(250.0ns)
16384 個 : 237.8clock(199.1ns) 281.0clock(235.3ns) 326.1clock(273.0ns)
32768 個 : 238.0clock(199.2ns) 281.0clock(235.3ns) 359.2clock(300.7ns)
65536 個 : 238.1clock(199.3ns) 285.8clock(239.3ns) 398.4clock(333.5ns)
131072 個 : 238.0clock(199.3ns) 288.9clock(241.9ns) 457.5clock(383.1ns)

>>153
PAGE_NOCACHEあり

load レイテンシ 計測ツール v0.2改R 4224byte stride
vender:AuthenticAMD CPUID:661
CPU動作クロック : 1194.4 MHz

ｱｸｾｽﾃﾞｰﾀ数 Seq.stride=128bytes Seq.stride=4224bytes Rnd.stride=4224bytes
4 個 : 255.0clock(213.5ns) 255.1clock(213.6ns) 255.1clock(213.6ns)
8 個 : 255.1clock(213.6ns) 254.3clock(212.9ns) 254.3clock(212.9ns)
16 個 : 255.1clock(213.6ns) 254.6clock(213.1ns) 254.3clock(212.9ns)
32 個 : 255.1clock(213.6ns) 254.7clock(213.2ns) 254.9clock(213.4ns)
64 個 : 255.0clock(213.5ns) 254.6clock(213.2ns) 254.8clock(213.3ns)
128 個 : 255.0clock(213.5ns) 254.5clock(213.1ns) 254.7clock(213.3ns)
256 個 : 254.8clock(213.4ns) 255.8clock(214.1ns) 256.1clock(214.4ns)
512 個 : 254.7clock(213.3ns) 269.9clock(226.0ns) 270.1clock(226.2ns)
1024 個 : 254.7clock(213.2ns) 272.3clock(227.9ns) 272.6clock(228.2ns)
2048 個 : 254.6clock(213.1ns) 272.9clock(228.5ns) 272.9clock(228.4ns)
4096 個 : 254.5clock(213.1ns) 273.0clock(228.6ns) 279.1clock(233.6ns)
8192 個 : 254.7clock(213.2ns) 273.1clock(228.6ns) 300.7clock(251.8ns)
16384 個 : 255.7clock(214.1ns) 273.0clock(228.5ns) 314.0clock(262.9ns)
32768 個 : 255.9clock(214.3ns) 272.9clock(228.5ns) 320.3clock(268.1ns)
65536 個 : 255.9clock(214.3ns) 283.0clock(236.9ns) 352.8clock(295.4ns)
131072 個 : 256.0clock(214.3ns) 289.3clock(242.2ns) 451.0clock(377.6ns)

これで何かわかりました?

>>156
ありがとう

プリフェッチが逆効果になっていると思ったので、
キャッシュ無効なら速くなるかと思ったのですが、
そうでもないようですね。
一部は微妙に速くなってますが・・・。

いまさらK7の話なんかしてる人って、何なの?

>>150
おまえプログラミング向いてない。やめな。

今日のお前がいうなスレはここですか？

K6-2の結果を貼りたいけどメモリが足りなくて実行できない俺ガイル

K5、K6、K6-2を持っていたが既に破棄処分にした俺がいる
K6-3を買おうと思った頃に丁度Celeron300Aが出たので
これを当然のごとく450Aにして使って超速いと感じた

以降Intelで組んできた

>>161
ちょっとソースの定数を書き換えてコンパイルし直すだけだぞ。
おまえこのスレ向いてない。やめな。

俺のMMX Pentiumが火を噴くときがきた？

消化器準備ヨシ

あんまり古いCPUは、TSCがなかったりして。

>>163
ソースは読めてもソースの意図が読めない子はこのスレ向いてないよ。

critical word firstって、いまどきのCPUでもやってるの?
キャッシュラインの先頭4バイトと末尾4バイトでレイテンシ同じっぽいのだが。

リニアバーストじゃないとRAMが対応してないんじゃない?

たとえばバースト長4のとき、
DRAMのカラム・アドレスの下位2ビットが、
00なら、0→1→2→3とアドレスが進む
11なら、3→0→1→2とアドレスが進む
のよ。

ちょっと場違いな質問かもしれないが、
C/C++の宿題を片付けます　110代目
http://pc11.2ch.net/test/read.cgi/tech/1213796455/394
http://pc11.2ch.net/test/read.cgi/tech/1213796455/398

とかって何のCPUを使ったかわかる？

プログラムは
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/7016.cpp
で、家でPen4/2.8Gの結果は2.2秒でした。

さて、スレ違いには全力で回答せよ、と。

とりあえずVC++とかGCCなら -O3 あるいは -Ox オプション使ってみ？

ちなみにうちはCore 2 E8500定格

で0.728秒
【盤のサイズ5x5で再コンパイルしたら】0.221秒だった

えーと、↑の【】内をよく読んでね


<div class="愚痴">
あと標準CライブラリのC++ラッパーヘッダは標準は time ではなく ctime な
あと、「新仕様ではenum値のインクリメントは違反だ」っつってエラー出た。
VC2008 SP1βだけどこれが例のTR1の仕様？
intにキャストして+1してまたenum値に戻して対処した。
あとdoubleにキャストしないと小数点以下切り捨てで0秒になるぞ
</div>

ありがとう
やっぱり0.028秒って変なんですね。

>>172
自作enumでインクリメントを使いたければ、operator ++を定義すればいいのさ。

PPCとかCellとかだったりするのかな

>>175
確かにPPCMacのVPC環境でWin32プログラム動かすと異常にスコアがいいことがあるが
（L1キャッシュのレイテンシ1clkだけは断じてない）
TSCのエミュがおかしいだけでしょ

Cellはこういう問題向きじゃない。

だんごさんのおかげでCellの欠点が明らかになったな

ＤＡＮＧＯさんがCellを語りだすととまらないな

ここまで貢献してるんだから
もうダンゴさん専用スレ立てようぜ

Atom買ってきたお
Fedoraの32か64入れるお
gccが通る.cか.sここに貼ってくれたら試すお

atomってamd64対応だっけ

対応してる。
230以外では殺されてるけど＜EM64T

NetBSD/amd64は普通に動いていたよ。

BIOSセットアップの画面で
EM64T Capableとなっていたお

暇があったらARM7とCell（いずれもゲーム機）で試すわ

>>180
John the Ripperを32bit(SSE)と64bitでビルドしてみて

./john --test
の結果きぼん

4. Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel and AMD CPU's

http://instlatx64.fw.hu/

にPenyrnが加わった。

シャッフルユニットを使う命令の分割が抑えられているみたいね。

>>187
http://www.agner.org/optimize/
じゃね？

そこは前スレあたりで実機で検証済みだがAgner氏は今回ずいぶん仕事遅かったな。

AtomもPenryn同様にSuperShuffleEngine搭載してるようだ。
へんに分割実行するよりダイレクト実行のほうが省電力とでも判断したのか。

> AtomもPenryn同様にSuperShuffleEngine搭載してるようだ。

128bitのPSHUFBは遅いようだ
ttp://www.freeweb.hu/instlatx64/InstLatX64_GenuineIntel00106c2_Atom_Silverthorne_1600MHz.txt
> 776 SSSE3 :PSHUFB mm, mm L: 0.63ns= 1.0c T: 0.63ns= 1.00c
> 1135 SSSE3 :PSHUFB xmm, xmm L: 3.76ns= 6.0c T: 3.76ns= 6.00c

>>189
たしかにそれだけは不可解なんだな。
64bit版は1-1なのに。

このへん見る限り128bitのシャッフルが可能なユニット積んでるのは間違いないんだが。

808 SSE :SHUFPS xmm, xmm, imm8 L: 0.63ns= 1.0c T: 0.63ns= 1.00c
899 SSE2 :SHUFPD xmm, xmm, imm8 L: 0.63ns= 1.0c T: 0.63ns= 1.00c
1136 SSE2 :PSHUFLW xmm, xmm, im8 L: 0.63ns= 1.0c T: 0.63ns= 1.00c
1137 SSE2 :PSHUFHW xmm, xmm, im8 L: 0.63ns= 1.0c T: 0.63ns= 1.00c
1138 SSE2 :PSHUFD xmm, xmm, im8 L: 0.63ns= 1.0c T: 0.63ns= 1.00c

ぶっちゃけ
新命令は遅くてもいいから実行できることが重要、だと思う。

新命令を使えば速くなります、新命令に対応したので速くなりました
ってのは訴求力あるし、最新CPUへの需要を引っ張るんだろうけどさ。

正味、65nmのCore2出たときは新命令よりは既存128ビットSIMD命令が
従来の倍速で使えるメリットのほうが大きかったし、
SSSE3自体は大々的に宣伝されたような記憶がない。

水平加減算なんか、それ用にわざわざ新たにパス作るのが馬鹿らしいほど
性能でなかったしね。
ただMMXのコードを全面的にSSE2に書き直すきっかけにはなった。
Pen4スルー組にはそれまでMMXで十分だったし。

1年単位で新命令追加するからCPU世代ごとに最適化するのもしんどい。
どうせSandyBridgeで総取替になるならSSE4.2とかCLMULとか最初からAVX版使わせてよと思うが。

今に始まった事じゃないが、MMXを2つ繋げたようなユニットにしてるせいで命令が変態。
水平加算なんか、隣との和ならシフトなりシャッフルなりして足せばいいじゃん。
加算回数が1/2になるだけ。
全要素を串刺しで足す事に意義があると思うんだが。

AVXもXMMを2つ繋げるみたいだし、後の苦労を考えずに楽な実装してるよな。

> 水平加算なんか、隣との和ならシフトなりシャッフルなりして足せばいいじゃん。

ちなみに45nm Core 2ではphadddをまさに内部的にpshufd × 2＋padddやってる。
65nmではpshufdすら1μOPでこなせないので（ｒｙ

だからCore 2用にパスを分ける意味がないわけ。
まあpshufbは便利だと思うけどXMM版が実用になるのは45nmからだな。

ごめん、shufps×2＋padddです。

ふと思ったんだが、
rep movsd
が遅いのはどうして?

少なくない既存のプログラムがrep movsdがボトルネックよ。

マイクロプログラムで動かしてるから

メモリの帯域幅が6.4GB/secとしてだ、
それは、
メモリからの(キャッシュを汚染しない)でXMMレジスタに
ロード200M回/secとストア200M回/secに相当ですよ。

2GHzで動いているCPUなら、
5クロックに1回ロードもしくはストアすればいいのよ。
マイクロコードだと、それもできないの?

マイクロコードで処理するならレジスタを介さず、
メモリからL2キャッシュにバーストでフィルして、
バーストで書き出せばいいんじゃね?

キャッシュラインが64バイトだから、
リード、ライトそれぞれ50M回/sec。

どうせストリーム検出付きのプリフェッチの
エンジンが付いているんだから、
そいつに指示を出すだけじゃん。

そう簡単に済むのなら実装されてるだろ。
されてないってことは、済まないってことだろ。

とはいえ、どうせマイクロコードが関与するんだから、
一定以上のecxでrep movsXを実行したらトラップする
なんていう機能はあっても良かったかもな。

いちいちOSに制御を渡していたらオーバーヘッドが大きいので、
特定の物理アドレスに代替ルーチンを置いておくようにしてさ。

割り込みとか考えなくて良い連中はお気楽だな。

割り込みが何か?

代替ルーチンをcallしたことにしてスタックに適切に積んでおけば、
代替ルーチンの中で割り込みが入っても、そのままOSの割り込みルーチンに制御が移ってOKだろ。

ダメだこりゃ

>>196
ecxへの影響があるから

esi,ediの存在も忘れるな

代替ルーチンからリターンした時に辻褄が合ってればいいんでしょ?

代替ルーチンはどこに置くんだよ。SMIみたいな事する気？

>>207
適当な物理アドレスに置くという約束でいいじゃないか。

その適当な物理アドレスは誰が確保するの？
代替ルーチンは仮想アドレスでどうやって表現するの？
DRxはスルーされるの？
等々

もう少し考えてみたら？

> その適当な物理アドレスは誰が確保するの？

OS

> 代替ルーチンは仮想アドレスでどうやって表現するの？

常に同一の仮想アドレスになるようにOSが面倒を見る

> DRxはスルーされるの？

ユーザーのコードと区別する必要はあるまい。

> ユーザーのコードと区別する必要はあるまい。
何を言いたいのか…

とりあえずユーザ空間の事しか考えていないのね。
だったらmemcpyを提供して終わりだな。

俺はわかってるけどあえて答えないよ。

お前らのためにならないからね…

ヒントとしては、OSの勉強をしてみようね。

実際はOSの勉強なんて必要ないはずなんだよ。

仕様に従った動きをさせるってのがどれだけ難しいか
仕様に従わない場合にどんな問題が発生するか
これを理解できていないだけだよ。

やっぱりプロセッサを作ったことがなきゃね…

素人は口出ししないのが賢明だよ。

>>205
それもあったな
それとflagもか

転送中にこのへんのレジスタの値を変えたときを考慮すると難しいってハナシだろ

OSのサポートが必要な仕組みなんだから、OSに対して透過的である必要はないだろ。

昔はFPUがないときにFPU命令の無効命令割り込みでFPUエミュレーションしてたろ?
仮想化なんかも同じだろ。特権命令を実行しようとしたのをハネて割り込みハンドラで処理してる。

そんなモノに価値があると思うことが足りない証拠。

OSが関与していいなら、OSがバイナリを動的に書き換えたらいいんよ。

特定のCPUに合わせて、
既存のバイナリの命令の並びを変えたり置き換えたりするってのは、
以前に試みているところがあったが、結局、日の目を見なかったな。

もし、
それに何の問題もなく、大きなパフォーマンス向上が得られるなら、
いまどきx86なんて使われてないだろう。

rep movs*を特権命令にしろと?

インテルのAtomのレイテンシ&スループットって、インテルからは公開されてる?

そもそも rep movsd はメモリに対しては別に遅くないんだが
というより movnt 系以外はどのレジスタ使おうがどんなループの細工をしようがほぼ変わらん

rep movsdとmovntdqでは倍くらい速度が違ったような。

ecxがL2キャッシュサイズを越えていれば、non-temporalで扱うべきだよな。

rep movsd って必ずキャッシュに乗るのか

プログラムによるが、rep movsdは、
数百バイトのコピーに頻繁に使われ、
コピー元は既にキャッシュ上にあることが多く、
コピー先もすぐに使われることが多い。

昔のコンパイラはrep movsdを使わずにループに展開するとか、
rep movsbをrep movsdに置き換えるとか、そういった最適化をしていたが、
今では逆にrep movsbやmovsdをそのまま使うようになっている。
なぜなら、そのほうが速くなったから。

かわりにmovpdつかえないの？

誰か>>196からの流れを産業でヨロ


つーかREPプレフィクスなんて既にSSE*用だと思っていた。

だんご
うぜぇな
とっとと消えろ

把
握
し
た

自分の経験の範囲だとrep movsdを生成するのは
MSのVCで、
memcpyを組込み関数として展開した場合かな。

WindowsにはCopyMemoryというAPIがあるのだけど、
PlatformSDKはこれをmemcpyに#defineしている。

OSのDLLを使うようにし、それが
CPUを判定して最適なルーチンに切り換わるように
なっていればいいだけの話だね。

当然その分のディスクスペースっても数百KBだろうが、まあそれと
複数の環境への開発コスト、何より金のかかるテストのコストはユーザが支払ってくれるんだろうな。

>>232
そのためのOSだと思うんだが。

>>232
>そのためのOSだと思うんだが。

ﾌﾟﾌﾟﾌﾟ

〓

>>VC
長さが定数で十分小さいなら
mov DWORD PTRほんにゃら
の繰り返しに展開してたな

それに比べて「ええー」っていうケースで_intel_fast_memcpyを呼び出したがる
かのコンパイラは賢いのか馬鹿なのか。

VCの最適化についてはダンゴさんは一言ありそうだな

ひょっとして「一家言」とでも言おうとした？

学がねーな金魚の糞くんは
恥ずかしいから100年ROMれ

一言でもおかしくないのでは？

日本語的に正しいかどうかはともかく
「ひとことある」という表現はとても一般的だな。

それほどおかしくないが、文脈的に見たら、一言あるだと大した意見もってねーって
馬鹿にしてる感があるけどｗ

既に一言を言ってるのに一言あるはおかしいだろ

このスレも団子に荒らされるのか

っていうか団子の本拠地

CPU が入力待ちなどで仕事をしていない時には、
SystemIdleProcessをグルグルまわしながらHALT 命令を発行して、
CPUを一時的に休止させてるんですよね？
でもなんで、リアルタイムに取得しているクロック数が変化しないんですか？

休止つっても部分的なものだし

>>245
HALTで低消費電力状態に移行しても、
タイムスタンプカウンタは回り続けている
ということだと思うよ。

っていうかTSCってFSBから取得だし

AMDはクロック周波数変えると・・・orz

>っていうかTSCってFSBから取得だし
これ、まじですか？
じゃ、FSBを上げてオーバークロックやってる人の時計ってめちゃくちゃなんですか？

(ﾟДﾟ)ﾊｧ?

すんません。勘違いです・・・

E8000&E7000 Specification Update 8月
ttp://download.intel.com/design/processor/specupdt/318733.pdf
P.13
E0ステッピングでAW51は修正されていないようだ

E0には間に合わなかったのか

X 印は修正が適用されているということでは？

修正完了しているのだと、X印ついてなくて、Fixedってついてるんだから、
Plan FixなAW51はまだ修正されてないよ。

すんません、ちゃんと記号説明を理解していなかったようです;-)

2008.09.02.
* Via Nano 06F2 InstLat Dump + CPUID + Memory Latency Matrix

00006F2 VIA Nano (CN, Isaiah)
ttp://www.freeweb.hu/instlatx64/InstLat_CentaurHauls00006f2_VIA_CN_Isaiah_1800MHz.txt

Memory Latency Matrix
ttp://www.freeweb.hu/instlatx64/LatMatrix_CentaurHauls00006f2_VIA_CN_Isaiah_1800MHz.txt

分岐予測について

BTBに履歴がない場合、jeとjneは、takenとnot takenどっちと見なされるの?

条件付き分岐の場合のみ使えるプレフィックスがあって、
2E : not taken
3E : taken
となる。プレフィックスがない場合はシラネ。

普通に考えればnot takenだろう

たとえ分岐予測がヒットしたとしても、takenよりもnot takenのほうが速い。
だから、履歴がない場合はnot takenと予測するのが妥当。

一般論だと
前方→NotTaken
後方→Taken
を優先するもんだけどな。

なに? 分岐予測のペナルティを計測しろだと・・・これまた面倒な。

ちょっと待て

>>259は「分岐履歴がない場合」ではなく「BTBに履歴がない場合」と言ってるぞ。
えーっと、どういうことだ?

>>259
プロセッサによって違う。
>>2のリンク先
http://www.agner.org/optimize/microarchitecture.pdf のP.27
"3.9 Static prediction" に各プロセッサの説明が書いてある。

ありがとう。

良く調べなかった自分が恥ずかしいです。

P4まで使っていた静的予測をCore2でやめたのは、どうしてだろう。

別に辞めた訳じゃないですぜ。そもそもPentium 4の系譜じゃなくて
P6→Pentium M→Coreの系譜だし。
強いて言えばNetBurstアーキテクチャを辞めた。

ところでどーやらだんごやさんは個人用のAtomマシンをゲットしたらしいんだけど
何かしら動かしたいコードある？

P6→Pentium Mのときに静的予測をやめたのかな。
履歴をたくさん持てば十分、ということなのだろうか。

>>268
http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=mandel.zip&refer=Upload
前のP6最適化のままだけど、マンデルブロ集合のベンチをお願いします。

スピードはそれなりにあるみたいだけど、In-Orderがどのくらい響くかが見物だ。

複数のコアで、同一のキャッシュラインに対して読み書きすると、酷いことになるのはわかる。
では、
同一のキャッシュラインの命令を複数のコアで実行すると、どうなるの?

>>271
1度命令キャッシュに取り込めばヒットする限りシングルコアと同じ。
読むだけならデータも命令も同時にアクセスした数だけ待たされるだけだからそこまで酷くはならない。

ありがとう。

>271
酷いことの内容
1.CPU-Bが、Aのデータキャッシュ内に書き換え済みデータが入ったエリアの読み込みを行う
2.CPU-Aが「ちょっと待て、ソレは古い内容だ。正しいのを渡すから待て。」と伝え、
キャッシュラインの書き込みを行う
3.Bが読み込む
(この後のことはよく知らない)

この間、バスクロックで数十〜100クロック程度の待ち時間があるのかな。
コアクロックに換算したら、数百クロックってとこか。
だが、「この後」の部分では、さらに複雑な状態になるんだろ?

ヒント：MESI

つーか、複数スレッドで共有データにアクセスする場合、実用上は
どのみちInterlockなりMutexかけて排他アクセスする羽目になるし。




＃Atom環境は準備中だからちょっと待ってね。たぶん1週間以内には何とかなるとｵﾓ
＃つか、マンデルブローをSSE3/SSE4で最適化してみたくなった

マンデルブロがSSE2を使ってくれないのだが

排他ロックをかけずに済ませるアルゴリズムもあるし、
同一キャッシュラインに複数の変数が乗るので、それぞれロックを別のスレッドが取得すると、同時に読み書きするし、
そもそもロックの排他制御が、まさに、同一のキャッシュラインを読み書きする処理だし。

粒度が細かすぎるマルチスレッド処理は、大変ね。

お待たせしました

EeePC 901＠Atom N270


GenuineIntel Family:6 Model:C Stepping:2
除数大↓　被除数大→
49 49 49 49 49 - - -
49 49 49 49 49 49 - -
49 49 49 49 49 49 49 -
49 49 49 49 49 49 49 49

マンデルブロー
FPU 7.300sec 11.944sec 16.124sec
SSE 1.449sec 2.093sec 2.945sec
SSE2 7.288sec 11.351sec 15.108sec

>>278
SSEでPenM-1.1GHzと同レベルか。
PenMもSSE2は得意じゃないと思ってたけど、
Atomは本当にSSE2（倍精度FP）が苦手なんだな。

こんなのも

--- GogoBench 3.13a (May 25 2004) ---
[DLL] ver. 3.13 ( May. 20 2004 )
[O S] Microsoft Windows XP SP3
[CPU] Intel Pentium Pro/2/3/Celeron Dual / 1600.0 MHz
GenuineIntel ID : 0/0/6/C/2 SPEC : 0xBFE9FBFF

[速度] 8.31倍速 [設定] Q=0 FPU
[速度] 8.81倍速 [設定] Q=0 FPU MMX
[速度] 12.75倍速 [設定] Q=0 FPU SSE MMX
[速度] 12.69倍速 [設定] Q=0 FPU SSE2 SSE MMX
[速度] 14.54倍速 [設定] Q=5 FPU
[速度] 14.76倍速 [設定] Q=5 FPU MMX
[速度] 38.85倍速 [設定] Q=5 FPU SSE MMX
[速度] 39.66倍速 [設定] Q=5 FPU SSE2 SSE MMX
[速度] 17.63倍速 [設定] Q=8 FPU
[速度] 17.67倍速 [設定] Q=8 FPU MMX
[速度] 58.33倍速 [設定] Q=8 FPU SSE MMX
[速度] 58.51倍速 [設定] Q=8 FPU SSE2 SSE MMX

他なんかある？

>>280
SSEでPenM-1.1GHｚに近い性能なのはいいとして、
FPUでもあんまり遅くなってないね。

http://instlatx64.fw.hu/
ここで見るとAtomは、P6最適化に重要なFXCH st(i) に2clkもかかる。
SSE2も、SISDは普通だけどSIMDは酷い。
当たり前だけどソフトを選びそうなCPUだね。

FXCHについてはHT前提だからじゃないの？
最適化の感覚的には1clkの見積もりでいいっしょ。

確かにAthlon64ではFXCH命令は速くならんな

もうx87FPUは使うな! っていうことかと。

HTで、どれくらいパイプライン効率を上げられるのか、どうやったら調べられるかな。

スループットが2clkなのか。スマン。

NehalemのInstruction Latency Dump

ttp://www.freeweb.hu/instlatx64

Intel Gainestown ES 106A2 x86, x64 InstLat Dump
ttp://www.freeweb.hu/instlatx64/InstLat_GenuineIntel00106A2_GainestownES_2666MHz.txt
ttp://www.freeweb.hu/instlatx64/InstLatX64_GenuineIntel00106A2_GainestownES_2666MHz.txt

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する余裕があったのだから、
なりふりかまわず、そうしていればよかったのにね。