1001コメント376KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2008/05/30(金) 23:18:52

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

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

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

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

0002デフォルトの名無しさん

2008/05/30(金) 23:19:19

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

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

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

0003デフォルトの名無しさん

2008/05/31(土) 00:44:43

以下ダンゴさんの幼稚な喚きをスルーできた奴は勝ち組
ダンゴ先生に構う者は団子

0004デフォルトの名無しさん

2008/05/31(土) 03:28:40

テンプレに入れて欲しい
http://instlatx64.fw.hu/

0005デフォルトの名無しさん

2008/05/31(土) 07:14:14

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

0006デフォルトの名無しさん

2008/05/31(土) 23:28:53

前スレ末からコピペ

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とコンパイラなら大抵は前者が速いか、
悪くとも同等にしかならないと思っていたのだが。

0007デフォルトの名無しさん

2008/05/31(土) 23:32:27

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

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

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

0008デフォルトの名無しさん

2008/05/31(土) 23:35:09

strength reduction でググレカス

0009デフォルトの名無しさん

2008/05/31(土) 23:43:36

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

0010デフォルトの名無しさん

2008/05/31(土) 23:48:18

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

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

0011デフォルトの名無しさん

2008/05/31(土) 23:51:29

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

0012デフォルトの名無しさん

2008/06/01(日) 00:16:14

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

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

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

0013デフォルトの名無しさん

2008/06/01(日) 00:30:36

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

0014デフォルトの名無しさん

2008/06/01(日) 00:34:57

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

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

どちらが本当なの？

0015デフォルトの名無しさん

2008/06/01(日) 00:41:26

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

0016デフォルトの名無しさん

2008/06/01(日) 00:46:52

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

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

もうねアホかと。

0017デフォルトの名無しさん

2008/06/01(日) 00:47:29

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

0018デフォルトの名無しさん

2008/06/01(日) 00:48:55

>>15
ちげーよ。

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

0019デフォルトの名無しさん

2008/06/01(日) 00:52:24

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

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

0020デフォルトの名無しさん

2008/06/01(日) 00:54:47

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

0021デフォルトの名無しさん

2008/06/01(日) 01:18:41

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

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

0022デフォルトの名無しさん

2008/06/01(日) 01:23:31

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

0023デフォルトの名無しさん

2008/06/01(日) 01:29:46

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

0024デフォルトの名無しさん

2008/06/01(日) 01:35:24

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をターゲットにすると一度しか評価しないコードになる所が面白いな。

0025デフォルトの名無しさん

2008/06/01(日) 01:36:11

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

0026デフォルトの名無しさん

2008/06/01(日) 01:51:14

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

0027デフォルトの名無しさん

2008/06/01(日) 01:51:33

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

0028デフォルトの名無しさん

2008/06/01(日) 02:12:17

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

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

0029デフォルトの名無しさん

2008/06/01(日) 02:12:35

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

すごいな。

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

0030デフォルトの名無しさん

2008/06/01(日) 02:14:55

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

0031デフォルトの名無しさん

2008/06/01(日) 02:15:09

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

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

0032デフォルトの名無しさん

2008/06/01(日) 02:20:18

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

0033デフォルトの名無しさん

2008/06/01(日) 02:26:11

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

0034デフォルトの名無しさん

2008/06/01(日) 02:32:29

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

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

0035デフォルトの名無しさん

2008/06/01(日) 02:34:40

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

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

0036デフォルトの名無しさん

2008/06/01(日) 02:46:41

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

0037デフォルトの名無しさん

2008/06/01(日) 03:09:44

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

0038デフォルトの名無しさん

2008/06/01(日) 03:24:54

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

0039デフォルトの名無しさん

2008/06/01(日) 03:55:44

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

0040デフォルトの名無しさん

2008/06/01(日) 10:46:12

MOUDQAでFA

0041デフォルトの名無しさん

2008/06/01(日) 12:11:01

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

0042デフォルトの名無しさん

2008/06/01(日) 14:49:39

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

0043デフォルトの名無しさん

2008/06/01(日) 15:54:08

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

0044デフォルトの名無しさん

2008/06/01(日) 16:13:46

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

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

004542

2008/06/01(日) 16:21:07

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

0046デフォルトの名無しさん

2008/06/01(日) 16:24:32

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

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

0047デフォルトの名無しさん

2008/06/01(日) 17:57:04

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

0048デフォルトの名無しさん

2008/06/01(日) 19:48:18

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

0049デフォルトの名無しさん

2008/06/01(日) 20:44:03

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

0050ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/01(日) 21:15:24

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

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

0051ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/01(日) 21:25:47

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

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

0052デフォルトの名無しさん

2008/06/01(日) 22:56:05

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

0053デフォルトの名無しさん

2008/06/02(月) 00:27:04

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

0054デフォルトの名無しさん

2008/06/03(火) 17:13:29

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

0055ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/03(火) 18:31:02

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

0056デフォルトの名無しさん

2008/06/03(火) 18:47:01

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

0057ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/03(火) 21:31:05

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

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

0058デフォルトの名無しさん

2008/06/03(火) 22:02:12

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

0059デフォルトの名無しさん

2008/06/06(金) 10:44:37

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

0060デフォルトの名無しさん

2008/06/06(金) 23:01:51

こんなんでどうですかね。
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のロス。

0061デフォルトの名無しさん

2008/06/06(金) 23:05:30

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

006260

2008/06/06(金) 23:12:06

>>1ではないけど…

0063デフォルトの名無しさん

2008/06/07(土) 00:17:13

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

0064デフォルトの名無しさん

2008/06/07(土) 07:00:24

>>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クロックということになりませんか?

006564

2008/06/07(土) 07:04:50

ぁぅぁぅぁぅ間違ってた

> 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クロックと言えるし・・・。

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

006660

2008/06/07(土) 07:50:21

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

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

0067デフォルトの名無しさん

2008/06/07(土) 08:07:50

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

006860

2008/06/07(土) 08:21:13

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

00691 ◆.MeromIYCE

2008/06/07(土) 12:10:12

>>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ヒットしてるっぽいが、奇数ラインに収まってるのかな。

00701 ◆.MeromIYCE

2008/06/07(土) 12:10:51

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

キャッシュの構造や働き(上級編) - 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のペナルティだった。

0071デフォルトの名無しさん

2008/06/07(土) 12:41:12

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)

0072デフォルトの名無しさん

2008/06/07(土) 12:45:27

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)

0073ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 13:11:43

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

0074デフォルトの名無しさん

2008/06/07(土) 13:35:40

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

0075デフォルトの名無しさん

2008/06/07(土) 13:42:58

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コアとの比較が気になる

0076デフォルトの名無しさん

2008/06/07(土) 16:32:41

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)

0077デフォルトの名無しさん

2008/06/07(土) 17:56:40

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)

0078デフォルトの名無しさん

2008/06/07(土) 18:54:34

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多くかかってる。

0079デフォルトの名無しさん

2008/06/07(土) 19:07:00

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

0080デフォルトの名無しさん

2008/06/07(土) 19:30:48

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

0081デフォルトの名無しさん

2008/06/07(土) 19:35:41

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

0082ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 20:11:47

お待たせ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)

0083デフォルトの名無しさん

2008/06/07(土) 20:15:52

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

0084ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 20:23:56

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

0085デフォルトの名無しさん

2008/06/07(土) 20:30:47

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で使ってる
結果最悪じゃね？(´・ω・｀)

0086ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 20:36:59

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

0087デフォルトの名無しさん

2008/06/07(土) 20:42:53

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

0088ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 20:52:14

>>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です。

0089デフォルトの名無しさん

2008/06/07(土) 21:13:19

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

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)

009089

2008/06/07(土) 21:15:09

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

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)

0091ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/07(土) 21:23:19

L1無効？

0092デフォルトの名無しさん

2008/06/07(土) 22:17:38

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

0093デフォルトの名無しさん

2008/06/07(土) 23:53:10

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

0094デフォルトの名無しさん

2008/06/07(土) 23:59:17

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

0095デフォルトの名無しさん

2008/06/08(日) 00:25:16

>>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)

0096ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/08(日) 07:21:01

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

0097デフォルトの名無しさん

2008/06/08(日) 09:38:36

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)

0098デフォルトの名無しさん

2008/06/08(日) 10:24:47

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

0099ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/08(日) 13:01:22

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

0100デフォルトの名無しさん

2008/06/08(日) 13:20:00

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

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

0101デフォルトの名無しさん

2008/06/08(日) 13:36:35

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

0102デフォルトの名無しさん

2008/06/08(日) 13:39:58

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

0103デフォルトの名無しさん

2008/06/08(日) 14:12:40

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

0104デフォルトの名無しさん

2008/06/08(日) 14:15:16

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

0105デフォルトの名無しさん

2008/06/08(日) 14:22:55

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

0106デフォルトの名無しさん

2008/06/08(日) 15:56:43

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

0107デフォルトの名無しさん

2008/06/08(日) 16:13:01

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

0108デフォルトの名無しさん

2008/06/08(日) 16:43:39

>>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)

0109デフォルトの名無しさん

2008/06/08(日) 16:48:54

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

0110デフォルトの名無しさん

2008/06/08(日) 16:50:56

>>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)

011189

2008/06/08(日) 23:00:30

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

0112デフォルトの名無しさん

2008/06/10(火) 11:51:49

やっと追いついた。コレクタ向けに貼っておく。
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)

0113デフォルトの名無しさん

2008/06/10(火) 16:46:29

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)

0114デフォルトの名無しさん

2008/06/10(火) 18:08:46

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

0115デフォルトの名無しさん

2008/06/10(火) 19:10:27

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

0116デフォルトの名無しさん

2008/06/10(火) 22:12:08

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

0117デフォルトの名無しさん

2008/06/10(火) 23:44:03

賑やかし。
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)

0118デフォルトの名無しさん

2008/06/12(木) 21:51:17

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)

0119デフォルトの名無しさん

2008/06/12(木) 21:52:23

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

0120デフォルトの名無しさん

2008/06/12(木) 22:50:59

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

0121ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/14(土) 08:41:35

チップセットがいいんだろうな
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)

0122デフォルトの名無しさん

2008/06/14(土) 09:59:59

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

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

0123ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/14(土) 10:16:46

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

0124デフォルトの名無しさん

2008/06/14(土) 10:49:22

> FSBを経由するよ

マジ！？

0125ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/14(土) 12:22:01

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

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

0126デフォルトの名無しさん

2008/06/14(土) 12:30:44

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

0127デフォルトの名無しさん

2008/06/14(土) 19:19:51

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 メモリ用の電源回路の容量をオーバーする
ってことで、その対策なんだろうなぁ。
ベンチマークやプログラムによっては、引っかかるかも?

0128デフォルトの名無しさん

2008/06/14(土) 19:34:30

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

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

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

0129128

2008/06/14(土) 19:34:52

ごめん、
×FGMT
○CGMT

0130デフォルトの名無しさん

2008/06/15(日) 01:52:27

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

0131デフォルトの名無しさん

2008/06/15(日) 01:59:57

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

0132デフォルトの名無しさん

2008/06/15(日) 19:50:45

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

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

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

0133ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/15(日) 20:24:14

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

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

0134デフォルトの名無しさん

2008/06/15(日) 21:11:13

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

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

0135デフォルトの名無しさん

2008/06/15(日) 21:11:57

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

0136デフォルトの名無しさん

2008/06/15(日) 21:45:17

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

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

01371 ◆.MeromIYCE

2008/06/15(日) 22:20:02

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

0138デフォルトの名無しさん

2008/06/15(日) 22:35:20

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

0139デフォルトの名無しさん

2008/06/16(月) 04:10:04

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

0140デフォルトの名無しさん

2008/06/16(月) 04:20:02

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

014178

2008/06/16(月) 07:24:07

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

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

0142デフォルトの名無しさん

2008/06/16(月) 15:13:13

見事に60ns・・・

0143デフォルトの名無しさん

2008/06/16(月) 15:28:43

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の間はプリチャージとか、バンクをアクティブにするとか、そういうことをやってるのかな・・・。

0144デフォルトの名無しさん

2008/06/17(火) 01:57:02

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

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

0145デフォルトの名無しさん

2008/06/17(火) 11:19:14

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

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

0146デフォルトの名無しさん

2008/06/17(火) 11:21:58

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

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

0147デフォルトの名無しさん

2008/06/17(火) 12:14:52

>>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

0148146

2008/06/17(火) 12:59:25

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

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

014978

2008/06/18(水) 01:34:39

>>147
70ns

0150デフォルトの名無しさん

2008/06/18(水) 22:26:08

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

0151150

2008/06/18(水) 22:45:26

ごめん、オオボケだ。

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

直してきます。

0152150

2008/06/18(水) 22:57:29

直しました。
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)

0153デフォルトの名無しさん

2008/06/18(水) 23:35:57

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

0154デフォルトの名無しさん

2008/06/19(木) 00:39:55

150は何を調べたいの?

0155ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/19(木) 02:03:05

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)

0156デフォルトの名無しさん

2008/06/20(金) 00:23:12

>>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)

0157デフォルトの名無しさん

2008/06/20(金) 00:24:02

>>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)

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

0158153

2008/06/21(土) 15:30:33

>>156
ありがとう

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

0159デフォルトの名無しさん

2008/06/24(火) 05:19:55

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

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

0160デフォルトの名無しさん

2008/06/24(火) 07:02:24

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

0161デフォルトの名無しさん

2008/06/24(火) 10:44:33

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

0162デフォルトの名無しさん

2008/06/24(火) 11:15:04

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

以降Intelで組んできた

0163デフォルトの名無しさん

2008/06/24(火) 12:16:29

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

0164ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/24(火) 18:58:37

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

0165デフォルトの名無しさん

2008/06/24(火) 19:55:57

消化器準備ヨシ

0166デフォルトの名無しさん

2008/06/24(火) 19:57:39

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

0167デフォルトの名無しさん

2008/06/24(火) 21:56:42

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

0168デフォルトの名無しさん

2008/06/25(水) 14:34:19

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

0169デフォルトの名無しさん

2008/06/25(水) 21:42:31

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

0170デフォルトの名無しさん

2008/06/25(水) 22:08:45

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

0171デフォルトの名無しさん

2008/06/26(木) 00:26:41

ちょっと場違いな質問かもしれないが、
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秒でした。

0172ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/27(金) 18:24:32

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

とりあえず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>

0173デフォルトの名無しさん

2008/06/27(金) 21:35:36

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

0174デフォルトの名無しさん

2008/06/28(土) 02:54:02

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

0175デフォルトの名無しさん

2008/06/28(土) 15:27:46

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

0176ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/28(土) 20:05:38

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

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

0177デフォルトの名無しさん

2008/06/28(土) 21:48:50

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

0178デフォルトの名無しさん

2008/06/28(土) 22:03:43

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

0179デフォルトの名無しさん

2008/06/28(土) 23:18:09

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

0180⊂二二二（＾ω＾）二⊃

2008/06/29(日) 22:41:25

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

0181デフォルトの名無しさん

2008/06/29(日) 22:56:41

atomってamd64対応だっけ

0182デフォルトの名無しさん

2008/06/29(日) 23:36:49

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

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

0183⊂二二二（＾ω＾）二⊃

2008/06/30(月) 01:08:46

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

0184ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/30(月) 16:55:22

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

0185ヽ・´∀｀・,,）っ━━━━━━┓

2008/06/30(月) 17:00:58

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

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

0186デフォルトの名無しさん

2008/07/05(土) 07:18:12

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

http://instlatx64.fw.hu/

にPenyrnが加わった。

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

0187デフォルトの名無しさん

2008/07/05(土) 07:55:49

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

0188ヽ・´∀｀・,,）っ━━━━━━┓

2008/07/05(土) 15:42:33

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

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

0189デフォルトの名無しさん

2008/07/05(土) 17:57:55

> 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

0190ヽ・´∀｀・,,）っ━━━━━━┓

2008/07/07(月) 01:28:25

>>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

0191デフォルトの名無しさん

2008/07/07(月) 07:11:51

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

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

0192ヽ・´∀｀・,,）っ━━━━━━━┓

2008/07/07(月) 14:08:12

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

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

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

0193デフォルトの名無しさん

2008/07/07(月) 14:21:08

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

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

0194ヽ・´∀｀・,,）っ━━━━━━┓

2008/07/07(月) 20:32:53

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

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

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

0195ヽ・´∀｀・,,）っ━━━━━━┓

2008/07/07(月) 20:33:24

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

0196デフォルトの名無しさん

2008/07/14(月) 19:08:45

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

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

0197デフォルトの名無しさん

2008/07/14(月) 23:57:37

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

0198デフォルトの名無しさん

2008/07/15(火) 00:08:06

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

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

0199デフォルトの名無しさん

2008/07/15(火) 00:12:08

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

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

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

0200デフォルトの名無しさん

2008/07/15(火) 07:44:09

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

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

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

0201デフォルトの名無しさん

2008/07/15(火) 21:12:03

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

0202デフォルトの名無しさん

2008/07/15(火) 21:16:48

割り込みが何か?

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

0203デフォルトの名無しさん

2008/07/15(火) 21:29:23

ダメだこりゃ

0204デフォルトの名無しさん

2008/07/15(火) 21:50:15

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

0205デフォルトの名無しさん

2008/07/15(火) 22:00:03

esi,ediの存在も忘れるな

0206デフォルトの名無しさん

2008/07/15(火) 22:09:48

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

0207デフォルトの名無しさん

2008/07/15(火) 22:14:51

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

0208デフォルトの名無しさん

2008/07/15(火) 22:36:40

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

0209デフォルトの名無しさん

2008/07/15(火) 22:56:42

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

もう少し考えてみたら？

0210デフォルトの名無しさん

2008/07/15(火) 23:40:04

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

OS

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

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

> DRxはスルーされるの？

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

0211デフォルトの名無しさん

2008/07/15(火) 23:48:45

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

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

0212デフォルトの名無しさん

2008/07/16(水) 00:28:26

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

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

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

0213デフォルトの名無しさん

2008/07/16(水) 00:37:52

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

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

0214デフォルトの名無しさん

2008/07/16(水) 00:45:18

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

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

0215デフォルトの名無しさん

2008/07/16(水) 01:27:33

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

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

0216デフォルトの名無しさん

2008/07/16(水) 09:39:43

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

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

0217デフォルトの名無しさん

2008/07/16(水) 13:13:01

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

0218デフォルトの名無しさん

2008/07/16(水) 13:53:09

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

0219デフォルトの名無しさん

2008/07/16(水) 13:57:55

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

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

0220デフォルトの名無しさん

2008/07/16(水) 14:15:25

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

0221デフォルトの名無しさん

2008/07/16(水) 22:52:30

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

0222デフォルトの名無しさん

2008/07/18(金) 15:42:31

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

0223デフォルトの名無しさん

2008/07/18(金) 16:33:04

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

0224デフォルトの名無しさん

2008/07/19(土) 15:09:47

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

0225デフォルトの名無しさん

2008/07/19(土) 16:56:33

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

0226デフォルトの名無しさん

2008/07/19(土) 17:31:13

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

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

0227デフォルトの名無しさん

2008/07/20(日) 03:48:24

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

0228ヽ・´∀｀・,,）っ━━━━━┓

2008/07/27(日) 15:12:05

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

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

0229デフォルトの名無しさん

2008/07/27(日) 16:02:52

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

0230ヽ・´∀｀・,,）っ━━━━━┓

2008/07/27(日) 19:12:31

把
握
し
た

0231デフォルトの名無しさん

2008/07/28(月) 01:06:59

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

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

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

0232デフォルトの名無しさん

2008/07/28(月) 02:08:59

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

0233デフォルトの名無しさん

2008/07/28(月) 02:18:19

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

0234デフォルトの名無しさん

2008/07/28(月) 02:21:03

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

ﾌﾟﾌﾟﾌﾟ

0235デフォルトの名無しさん

2008/07/28(月) 02:33:52

〓

0236ヽ・´∀｀・,,）っ━━━━━┓

2008/07/28(月) 06:19:26

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

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

0237デフォルトの名無しさん

2008/07/28(月) 07:08:53

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

0238ヽ・´∀｀・,,）っ━━━━━┓

2008/07/28(月) 08:05:14

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

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

0239デフォルトの名無しさん

2008/07/28(月) 09:21:09

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

0240デフォルトの名無しさん

2008/07/28(月) 11:06:57

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

0241デフォルトの名無しさん

2008/07/28(月) 11:28:14

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

0242デフォルトの名無しさん

2008/07/28(月) 11:30:19

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

0243デフォルトの名無しさん

2008/07/28(月) 11:35:34

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

0244デフォルトの名無しさん

2008/07/28(月) 11:39:06

っていうか団子の本拠地

0245デフォルトの名無しさん

2008/08/06(水) 02:24:49

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

0246デフォルトの名無しさん

2008/08/06(水) 07:23:15

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

0247デフォルトの名無しさん

2008/08/07(木) 14:09:50

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

0248,,・´∀`・,,）っ-○●◎

2008/08/09(土) 00:28:42

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

0249デフォルトの名無しさん

2008/08/09(土) 08:07:35

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

0250デフォルトの名無しさん

2008/08/10(日) 21:50:15

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

0251デフォルトの名無しさん

2008/08/10(日) 22:21:15

(ﾟДﾟ)ﾊｧ?

0252デフォルトの名無しさん

2008/08/11(月) 00:50:29

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

0253デフォルトの名無しさん

2008/08/12(火) 21:10:26

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

0254デフォルトの名無しさん

2008/08/13(水) 05:07:09

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

0255デフォルトの名無しさん

2008/08/13(水) 09:35:41

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

0256デフォルトの名無しさん

2008/08/13(水) 09:52:23

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

0257デフォルトの名無しさん

2008/08/13(水) 10:25:42

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

0258デフォルトの名無しさん

2008/09/05(金) 20:06:29

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

0259デフォルトの名無しさん

2008/10/12(日) 00:03:51

分岐予測について

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

0260デフォルトの名無しさん

2008/10/12(日) 00:50:36

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

0261デフォルトの名無しさん

2008/10/12(日) 01:24:44

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

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

0262デフォルトの名無しさん

2008/10/12(日) 01:29:58

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

0263デフォルトの名無しさん

2008/10/12(日) 01:35:35

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

0264デフォルトの名無しさん

2008/10/12(日) 01:51:07

ちょっと待て

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

0265デフォルトの名無しさん

2008/10/12(日) 06:34:26

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

0266259

2008/10/12(日) 10:16:48

ありがとう。

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

0267デフォルトの名無しさん

2008/10/12(日) 12:41:52

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

0268,,・´∀｀・,,）っ-○◎●

2008/10/12(日) 14:56:49

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

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

0269デフォルトの名無しさん

2008/10/12(日) 15:29:03

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

02701 ◆.MeromIYCE

2008/10/12(日) 23:03:05

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

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

0271デフォルトの名無しさん

2008/10/13(月) 11:41:54

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

0272デフォルトの名無しさん

2008/10/13(月) 14:17:00

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

0273デフォルトの名無しさん

2008/10/13(月) 14:37:16

ありがとう。

0274デフォルトの名無しさん

2008/10/15(水) 01:12:31

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

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

0275,,・´∀｀・,,）っ-○◎●

2008/10/15(水) 01:29:58

ヒント：MESI

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

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

0276デフォルトの名無しさん

2008/10/15(水) 01:53:39

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

0277デフォルトの名無しさん

2008/10/15(水) 03:05:33

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

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

0278,,・´∀｀・,,）っ-○◎○

2008/10/20(月) 22:46:19

お待たせしました

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

02791 ◆.MeromIYCE

2008/10/21(火) 20:01:59

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

0280,,・´∀｀・,,）っ-●◎○

2008/10/22(水) 01:54:49

こんなのも

--- 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

0281,,・´∀｀・,,）っ-●◎○

2008/10/22(水) 02:43:57

他なんかある？

02821 ◆.MeromIYCE

2008/10/22(水) 21:09:41

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

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

0283デフォルトの名無しさん

2008/10/23(木) 01:11:57

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

0284デフォルトの名無しさん

2008/10/23(木) 01:15:43

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

0285デフォルトの名無しさん

2008/10/23(木) 01:55:44

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

0286デフォルトの名無しさん

2008/10/23(木) 01:57:30

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

0287デフォルトの名無しさん

2008/10/23(木) 07:44:54

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

0288デフォルトの名無しさん

2008/11/13(木) 19:36:02

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

0289,,・´∀｀・,,）っ-●◎○

2008/11/13(木) 20:32:44

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

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

0290,,・´∀｀・,,）っ-●◎○

2008/11/13(木) 20:40:54

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

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

0291デフォルトの名無しさん

2008/11/13(木) 20:52:53

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

0292デフォルトの名無しさん

2008/11/13(木) 21:20:09

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

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

0293,,・´∀｀・,,）っ-●◎○

2008/11/13(木) 21:23:37

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

0294デフォルトの名無しさん

2008/11/14(金) 21:04:03

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

0295デフォルトの名無しさん

2008/11/14(金) 21:46:14

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

0296,,・´∀｀・,,）っ-○◎●

2008/11/14(金) 21:50:43

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

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

0297デフォルトの名無しさん

2008/11/15(土) 20:10:49

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

0298,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 20:17:30

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

0299デフォルトの名無しさん

2008/11/15(土) 20:25:21

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

0300,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 20:56:50

専用化（笑）

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

0301デフォルトの名無しさん

2008/11/15(土) 21:11:53

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

0302デフォルトの名無しさん

2008/11/15(土) 21:26:16

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

0303,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:13:14

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

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

0304,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:14:50

>>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

0305デフォルトの名無しさん

2008/11/15(土) 22:35:46

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

0306,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:38:12

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

0307,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:43:50

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

0308デフォルトの名無しさん

2008/11/15(土) 22:44:23

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

0309デフォルトの名無しさん

2008/11/15(土) 22:46:14

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

0310,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:46:16

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

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

0311デフォルトの名無しさん

2008/11/15(土) 22:48:50

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

0312,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:51:57

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

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

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

0313,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:53:55

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

0314,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 22:57:17

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

0315デフォルトの名無しさん

2008/11/15(土) 23:24:34

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

0316,,・´∀｀・,,）っ-●◎○

2008/11/15(土) 23:50:22

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の内訳はなんだろうね？

はい、これ宿題ね。

0317,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:06:38

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

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

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

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

馬鹿丸出しだな

0318デフォルトの名無しさん

2008/11/16(日) 00:12:33

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

0319,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:18:32

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

0320デフォルトの名無しさん

2008/11/16(日) 00:21:43

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

0321,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:22:41

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

0322,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:25:16

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

0323,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:26:24

【7μOpsの内訳】

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

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

恥ずかしくないですか？

0324デフォルトの名無しさん

2008/11/16(日) 00:27:12

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

0325,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:30:10

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

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

0326デフォルトの名無しさん

2008/11/16(日) 00:30:19

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

0327,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:33:17

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

0328,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:34:42

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

0329デフォルトの名無しさん

2008/11/16(日) 00:35:35

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

0330デフォルトの名無しさん

2008/11/16(日) 00:37:18

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

0331,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:37:36

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

　答　　え　　て　　み　　ろ　　よ

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

0332,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:38:32

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

0333,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:39:38

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

0334デフォルトの名無しさん

2008/11/16(日) 00:46:48

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

0335,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:47:22

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

0336デフォルトの名無しさん

2008/11/16(日) 00:49:15

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

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

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

0337,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:50:28

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

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

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

0338,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:50:48

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

0339デフォルトの名無しさん

2008/11/16(日) 00:56:52

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

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

0340,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:58:28

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

0341,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 00:59:55

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

0342デフォルトの名無しさん

2008/11/16(日) 01:01:30

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

0343,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 01:05:43

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

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

0344デフォルトの名無しさん

2008/11/16(日) 01:07:09

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

0345デフォルトの名無しさん

2008/11/16(日) 01:08:12

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

0346,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 01:16:03

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

それが大間違いだよ

0347デフォルトの名無しさん

2008/11/16(日) 01:21:07

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

0348デフォルトの名無しさん

2008/11/16(日) 07:21:03

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

0349,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 11:03:27

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

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

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

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

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

0350デフォルトの名無しさん

2008/11/16(日) 11:31:33

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

0351348

2008/11/16(日) 11:33:34

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

0352デフォルトの名無しさん

2008/11/16(日) 12:25:40

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

0353デフォルトの名無しさん

2008/11/16(日) 12:33:30

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

0354デフォルトの名無しさん

2008/11/16(日) 12:36:29

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

0355,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 13:34:34

現実問題として、整数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では少なくともやってないのは事実としてあるし。

0356,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 13:35:54

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

0357,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 13:38:30

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

0358デフォルトの名無しさん

2008/11/16(日) 13:40:34

ちゃんばば臭い。

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

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

0359,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 13:45:55

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

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

0360デフォルトの名無しさん

2008/11/16(日) 13:57:30

団子も徹夜の学習でまともになってきたせいか>>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も原理的には同じクロスバースイッチによる実装だよ。

0361デフォルトの名無しさん

2008/11/16(日) 14:00:42

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

0362デフォルトの名無しさん

2008/11/16(日) 14:17:26

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

0363,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 15:08:28

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

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

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

0364,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 15:12:10

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

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

0365,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 15:15:08

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

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

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

0366デフォルトの名無しさん

2008/11/16(日) 15:44:07

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

0367デフォルトの名無しさん

2008/11/16(日) 16:11:13

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

0368デフォルトの名無しさん

2008/11/16(日) 16:21:27

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

0369デフォルトの名無しさん

2008/11/16(日) 16:24:49

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

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

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

0370,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:27:15

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

0371デフォルトの名無しさん

2008/11/16(日) 16:30:45

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

0372,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:31:17

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

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

0373,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:31:51

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

0374,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:32:38

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

0375デフォルトの名無しさん

2008/11/16(日) 16:33:37

スレタイ読めよ。

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

0376デフォルトの名無しさん

2008/11/16(日) 16:33:41

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

0377,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:33:44

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

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

0378,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:34:12

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

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

0379,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:35:02

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

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

0380デフォルトの名無しさん

2008/11/16(日) 16:35:14

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

0381,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:36:17

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

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

0382,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:37:29

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

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

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

0383デフォルトの名無しさん

2008/11/16(日) 16:37:38

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

0384,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:38:58

恥ずかしい発言だね

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

0385,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:39:53

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

0386デフォルトの名無しさん

2008/11/16(日) 16:41:14

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

0387,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:41:17

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

0388デフォルトの名無しさん

2008/11/16(日) 16:41:54

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

0389,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:43:12

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

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

0390デフォルトの名無しさん

2008/11/16(日) 16:43:26

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

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

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

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

0391,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:45:04

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

0392,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:46:32

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

これは間違ったことだね

0393デフォルトの名無しさん

2008/11/16(日) 16:47:48

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

0394デフォルトの名無しさん

2008/11/16(日) 16:47:53

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

0395デフォルトの名無しさん

2008/11/16(日) 16:48:23

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

0396,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:49:52

×高速化
○回路の節約

0397,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:51:22

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

0398デフォルトの名無しさん

2008/11/16(日) 16:53:33

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

0399,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 16:56:39

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

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

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

0400デフォルトの名無しさん

2008/11/16(日) 17:07:34

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

0401デフォルトの名無しさん

2008/11/16(日) 17:11:25

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

0402デフォルトの名無しさん

2008/11/16(日) 17:16:54

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

0403,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 17:17:25

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

0404デフォルトの名無しさん

2008/11/16(日) 17:17:58

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

0405デフォルトの名無しさん

2008/11/16(日) 17:20:08

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

0406,,・´∀｀・,,）っ-●◎○

2008/11/16(日) 22:22:16

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

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

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

0407,,・´∀｀・,,）っ-○◎●

2008/11/16(日) 23:47:24

> 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になる。

0408デフォルトの名無しさん

2008/11/17(月) 00:05:45

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

0409,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:06:24

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

0410,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:06:54

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

0411,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:07:45

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

0412デフォルトの名無しさん

2008/11/17(月) 00:08:54

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

0413デフォルトの名無しさん

2008/11/17(月) 00:10:00

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

0414,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:10:11

[QW shuffle]

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

0415デフォルトの名無しさん

2008/11/17(月) 00:11:08

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

0416,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:12:58

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

あほらしい
恥の上塗り

0417デフォルトの名無しさん

2008/11/17(月) 00:13:04

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

0418,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:17:49

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

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

0419デフォルトの名無しさん

2008/11/17(月) 00:22:20

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

0420,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:22:44

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

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

0421デフォルトの名無しさん

2008/11/17(月) 00:23:43

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

0422デフォルトの名無しさん

2008/11/17(月) 00:27:34

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

0423,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:28:03

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

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

0424デフォルトの名無しさん

2008/11/17(月) 00:30:56

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

0425,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:33:28

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

Port 0 　　　　　　　　　Port5
+→ 128-bit Shuffle←+

0426デフォルトの名無しさん

2008/11/17(月) 00:34:43

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

0427,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:35:16

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

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

0428,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:35:56

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

0429デフォルトの名無しさん

2008/11/17(月) 00:36:22

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

0430,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:41:09

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

Port 0 　　　　　　　　　Port5
　+→ 128-bit Shuffle←+

0431デフォルトの名無しさん

2008/11/17(月) 00:41:57

煽りすぎ荒らしすぎ

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

0432デフォルトの名無しさん

2008/11/17(月) 00:42:50

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

0433,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 00:54:45

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

仕事になりませんな

0434デフォルトの名無しさん

2008/11/17(月) 01:08:09

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

0435デフォルトの名無しさん

2008/11/17(月) 01:08:34

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

0436,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:11:08

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

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

0437,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:12:19

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

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

0438デフォルトの名無しさん

2008/11/17(月) 01:15:29

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

0439デフォルトの名無しさん

2008/11/17(月) 01:18:56

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

0440デフォルトの名無しさん

2008/11/17(月) 01:21:49

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

0441,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:22:25

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

0442,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:23:34

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

Port1 　　　　　　　　　Port5
　+→ 128-bit Shuffle←+

0443,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:24:53

「潔い」で1語

イサギって何だよ。

日本語もできないんだな

0444デフォルトの名無しさん

2008/11/17(月) 01:25:48

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

0445,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:26:38

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

0446,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:29:01

イサギ悪いぞ
　

0447,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:32:19

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

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

0448デフォルトの名無しさん

2008/11/17(月) 01:34:39

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

0449デフォルトの名無しさん

2008/11/17(月) 01:37:20

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

0450,,・´∀｀・,,）っ-○◎●

2008/11/17(月) 01:42:02

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

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

0451,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/11/17(月) 01:57:49

イサギw

0452デフォルトの名無しさん

2008/11/17(月) 08:43:42

胃詐欺悪い

0453デフォルトの名無しさん

2008/11/17(月) 09:36:03

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

0454デフォルトの名無しさん

2008/11/17(月) 11:20:42

じゃあ計測によって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に発行するって意味で考えてれば良かった。

0455,,・´∀｀・,,）っ-□△○

2008/11/17(月) 11:45:36

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

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

0456デフォルトの名無しさん

2008/11/17(月) 18:15:45

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

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

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

0457デフォルトの名無しさん

2008/11/17(月) 18:32:32

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

0458,,・´∀｀・,,）っ

2008/11/17(月) 19:17:00

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

0459,,・´∀｀・,,）っ[うんこ]

2008/11/17(月) 19:28:41

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

0460デフォルトの名無しさん

2008/11/17(月) 19:37:17

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

0461,,・´∀｀・,,）っ

2008/11/17(月) 19:44:57

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

0462デフォルトの名無しさん

2008/11/17(月) 19:52:43

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

0463デフォルトの名無しさん

2008/11/17(月) 20:02:42

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

0464,,・´∀｀・,,）っ[だんごないよ]

2008/11/17(月) 20:10:12

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

0465デフォルトの名無しさん

2008/11/17(月) 20:16:48

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

0466デフォルトの名無しさん

2008/11/17(月) 20:21:32

×子鮒
○伊佐木

0467デフォルトの名無しさん

2008/11/17(月) 22:34:03

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

0468デフォルトの名無しさん

2008/11/18(火) 00:09:59

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

0469デフォルトの名無しさん

2008/11/19(水) 01:31:13

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

0470デフォルトの名無しさん

2008/11/19(水) 02:15:26

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

とは言えウザイけど

0471デフォルトの名無しさん

2008/11/21(金) 16:24:48

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

0472デフォルトの名無しさん

2008/11/21(金) 16:49:12

笑えるか？アレ

0473,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/11/26(水) 19:40:24

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

0474デフォルトの名無しさん

2008/11/26(水) 21:26:54

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

0475,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/11/26(水) 22:23:01

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

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

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

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

いいかげんにしる

0476デフォルトの名無しさん

2008/11/27(木) 00:13:35

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

0477デフォルトの名無しさん

2008/11/27(木) 14:22:04

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

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

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

0478デフォルトの名無しさん

2008/11/27(木) 22:47:08

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

0479デフォルトの名無しさん

2008/11/27(木) 22:52:50

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

0480,,・´∀｀・,,）っ-●◎○

2008/11/27(木) 23:07:05

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

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

0481デフォルトの名無しさん

2008/11/27(木) 23:09:59

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

0482デフォルトの名無しさん

2008/11/27(木) 23:27:49

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

0483デフォルトの名無しさん

2008/11/28(金) 00:23:31

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

0484デフォルトの名無しさん

2008/11/28(金) 00:51:06

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

0485 ◆0uxK91AxII

2008/11/28(金) 03:25:58

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

0486デフォルトの名無しさん

2008/11/28(金) 04:47:42

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

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

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

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

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

0487デフォルトの名無しさん

2008/11/28(金) 04:58:18

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

0488デフォルトの名無しさん

2008/11/28(金) 08:07:19

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

0489デフォルトの名無しさん

2008/11/28(金) 12:41:55

VeriSign一択ではないだろ。

0490デフォルトの名無しさん

2008/12/06(土) 23:48:43

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

0491 ◆0uxK91AxII

2008/12/07(日) 07:27:12

>>490
can NOT.

0492デフォルトの名無しさん

2008/12/07(日) 10:38:23

できないのか、残念。

0493デフォルトの名無しさん

2008/12/07(日) 21:58:23

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

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

0494デフォルトの名無しさん

2008/12/26(金) 14:10:02

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

# 本人乙の予感

0495,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/12/26(金) 19:13:40

イサギ悪いので嫌いです

0496デフォルトの名無しさん

2008/12/26(金) 20:11:23

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

0497デフォルトの名無しさん

2008/12/27(土) 00:39:48

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

0498デフォルトの名無しさん

2008/12/27(土) 00:42:22

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

0499,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/12/27(土) 03:27:05

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

0500デフォルトの名無しさん

2008/12/27(土) 04:09:09

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

0501デフォルトの名無しさん

2008/12/27(土) 15:25:35

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

0502デフォルトの名無しさん

2008/12/27(土) 18:21:40

大原君へ
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

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

0503デフォルトの名無しさん

2008/12/27(土) 18:36:36

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

0504デフォルトの名無しさん

2008/12/28(日) 04:54:09

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

0505デフォルトの名無しさん

2008/12/28(日) 04:57:01

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

0506デフォルトの名無しさん

2008/12/28(日) 14:03:11

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

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

0507,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/12/28(日) 16:51:20

RDPMCのことだね？

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

0508デフォルトの名無しさん

2008/12/28(日) 17:06:51

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

0509,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/12/28(日) 17:32:54

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

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

0510デフォルトの名無しさん

2008/12/28(日) 17:47:25

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

0511デフォルトの名無しさん

2008/12/28(日) 17:58:42

とりあえず落としとくわ

0512デフォルトの名無しさん

2008/12/29(月) 02:51:00

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

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

0513デフォルトの名無しさん

2008/12/30(火) 06:12:31

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

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

0514デフォルトの名無しさん

2008/12/30(火) 09:02:11

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

0515デフォルトの名無しさん

2008/12/30(火) 09:38:18

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

0516デフォルトの名無しさん

2008/12/30(火) 10:00:35

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

0517,,・´∀｀・,,）っ-●◎○

2008/12/30(火) 10:08:02

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

0518デフォルトの名無しさん

2008/12/30(火) 11:05:50

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

0519 ◆0uxK91AxII

2008/12/30(火) 12:26:02

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

0520デフォルトの名無しさん

2008/12/30(火) 15:55:04

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

0521,,・´∀｀・,,）っ-○◎● ◆ISAGIW0/wI

2008/12/30(火) 16:07:18

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

0522デフォルトの名無しさん

2008/12/30(火) 18:41:54

きもい

0523デフォルトの名無しさん

2009/01/06(火) 20:44:27

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

0524イサギ

2009/01/06(火) 22:51:00

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

0525,,・´∀｀・,,）っ-●◎○

2009/01/07(水) 01:12:45

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

0526デフォルトの名無しさん

2009/01/07(水) 18:34:15

伊佐木悪いスレ

0527デフォルトの名無しさん

2009/01/10(土) 12:46:35

脳がいさぎたないコテ

0528デフォルトの名無しさん

2009/01/22(木) 19:26:16

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

0529デフォルトの名無しさん

2009/01/22(木) 19:58:57

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

0530デフォルトの名無しさん

2009/01/24(土) 02:15:42

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 : +∞ * +∞ = +∞

0531,,・´∀｀・,,）っ-●◎○

2009/01/24(土) 04:30:32

>>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 : +∞ * +∞ = +∞

0532,,・´∀｀・,,）っ-●◎○

2009/01/24(土) 04:31:06

530の間違い

0533デフォルトの名無しさん

2009/01/24(土) 09:28:43

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

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

0534,,・´∀｀・,,）っ-●◎○

2009/01/24(土) 09:46:13

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

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

0535デフォルトの名無しさん

2009/01/24(土) 10:35:57

ためしたら以下相当になってた(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やるんだねえ
あ、こっちのほうがスレ的には関係あるか

0536デフォルトの名無しさん

2009/01/25(日) 23:05:49

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

0537,,・´∀｀・,,）っ-●◎○

2009/01/25(日) 23:40:49

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

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

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

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

0538デフォルトの名無しさん

2009/01/25(日) 23:47:26

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

0539デフォルトの名無しさん

2009/01/26(月) 00:02:56

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

Intelの脱x86は
432
860
Itanium

他にもあったかな?

>>537
960は違うだろ。

0540,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:03:36

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

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

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

0541,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:05:11

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

0542デフォルトの名無しさん

2009/01/26(月) 00:05:32

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

0543デフォルトの名無しさん

2009/01/26(月) 00:10:46

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

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

0544,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:17:15

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

0545デフォルトの名無しさん

2009/01/26(月) 00:21:14

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

0546,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:36:08

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

0547デフォルトの名無しさん

2009/01/26(月) 00:36:20

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

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

0548デフォルトの名無しさん

2009/01/26(月) 00:37:15

>>546
え?

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

0549,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:43:10

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

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

0550デフォルトの名無しさん

2009/01/26(月) 00:43:43

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

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

0551デフォルトの名無しさん

2009/01/26(月) 00:52:01

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

0552デフォルトの名無しさん

2009/01/26(月) 00:53:41

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

0553,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 00:59:21

>>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ｌの伝統的ロゴマークを刷新したのもこのへんだったよな。

0554デフォルトの名無しさん

2009/01/26(月) 01:03:05

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

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

0555,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 01:12:37

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

0556デフォルトの名無しさん

2009/01/26(月) 02:09:19

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

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

0557,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 02:22:22

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

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

0558デフォルトの名無しさん

2009/01/26(月) 02:28:53

なるほど。

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

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

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

0559,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 02:43:39

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

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

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

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

0560デフォルトの名無しさん

2009/01/26(月) 10:54:49

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

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

0561デフォルトの名無しさん

2009/01/26(月) 13:58:10

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

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

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

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

0562デフォルトの名無しさん

2009/01/26(月) 14:28:48

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

0563デフォルトの名無しさん

2009/01/26(月) 14:35:05

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

0564デフォルトの名無しさん

2009/01/26(月) 14:40:33

>>542
なんというCISC脳！

0565デフォルトの名無しさん

2009/01/26(月) 14:42:37

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

0566デフォルトの名無しさん

2009/01/26(月) 14:54:49

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

0567デフォルトの名無しさん

2009/01/26(月) 16:41:52

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

0568デフォルトの名無しさん

2009/01/26(月) 17:14:25

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

0569,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 17:35:15

>>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でない別の何か。

0570,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 18:29:00

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

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

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

0571,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 18:31:40

>>542宛が適切だったな

0572デフォルトの名無しさん

2009/01/26(月) 20:51:57

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

0573561=572

2009/01/26(月) 20:58:26

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

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

0574デフォルトの名無しさん

2009/01/26(月) 21:12:28

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

0575,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 21:16:49

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

0576デフォルトの名無しさん

2009/01/26(月) 21:30:21

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

0577デフォルトの名無しさん

2009/01/26(月) 21:32:12

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

0578デフォルトの名無しさん

2009/01/26(月) 21:32:25

吃音なのか?

0579デフォルトの名無しさん

2009/01/26(月) 21:35:01

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

0580デフォルトの名無しさん

2009/01/26(月) 21:37:46

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

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

0581,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 21:41:29

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

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

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

0582デフォルトの名無しさん

2009/01/26(月) 21:44:20

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

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

0583,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 21:50:04

>>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演算命令を実装する。
これで延々、命令帯域を確保し続けることができる。

0584,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 22:08:13

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

0585,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 22:09:02

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

0586デフォルトの名無しさん

2009/01/26(月) 22:18:17

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

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

0587デフォルトの名無しさん

2009/01/26(月) 22:23:13

ﾋﾟｺｰﾝ（AA略）

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

特許書くかな

0588,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 22:26:20

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

0589デフォルトの名無しさん

2009/01/26(月) 22:36:38

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

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

だめじゃん!

0590デフォルトの名無しさん

2009/01/26(月) 22:38:35

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

0591デフォルトの名無しさん

2009/01/26(月) 22:56:23

Pentium4 < Atom ってオチじゃね？

0592デフォルトの名無しさん

2009/01/26(月) 23:01:43

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

0593,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 23:07:13

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

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

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

0594デフォルトの名無しさん

2009/01/26(月) 23:24:41

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

0595デフォルトの名無しさん

2009/01/26(月) 23:25:31

だってモトローラだし。

0596デフォルトの名無しさん

2009/01/26(月) 23:25:47

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

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

0597デフォルトの名無しさん

2009/01/26(月) 23:27:25

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

こういうこと？

0598,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 23:38:34

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

0599デフォルトの名無しさん

2009/01/26(月) 23:41:50

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

0600,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 23:46:42

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

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

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

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

0601デフォルトの名無しさん

2009/01/26(月) 23:51:41

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

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

0602,,・´∀｀・,,）っ-●◎○

2009/01/26(月) 23:55:34

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

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

0603,,・´∀｀・,,）っ-●◎○

2009/01/27(火) 00:00:29

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

0604デフォルトの名無しさん

2009/01/27(火) 00:01:35

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

0605,,・´∀｀・,,）っ-●◎○

2009/01/27(火) 00:05:39

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

0606デフォルトの名無しさん

2009/01/27(火) 00:42:26

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

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

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

0607デフォルトの名無しさん

2009/01/27(火) 02:19:39

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

0608,,・´∀｀・,,）っ-●◎○

2009/01/27(火) 02:45:33

お前がな

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

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

0609,,・´∀｀・,,）っ-●◎○

2009/01/27(火) 03:41:13

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に変換するだけ。

0610デフォルトの名無しさん

2009/01/27(火) 07:48:02

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

0611,,・´∀｀・,,）っ-●◎○

2009/01/27(火) 08:07:22

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

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

0612デフォルトの名無しさん

2009/01/27(火) 11:18:59

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

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

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

0613デフォルトの名無しさん

2009/01/27(火) 12:19:46

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

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

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

0614デフォルトの名無しさん

2009/01/27(火) 13:26:01

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

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

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

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

0615デフォルトの名無しさん

2009/01/27(火) 14:18:26

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

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

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

0616デフォルトの名無しさん

2009/01/27(火) 14:28:16

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

0617デフォルトの名無しさん

2009/01/27(火) 14:37:22

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

0618デフォルトの名無しさん

2009/01/27(火) 14:55:10

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

0619デフォルトの名無しさん

2009/01/27(火) 14:56:36

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

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

0620デフォルトの名無しさん

2009/01/27(火) 15:00:40

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

0621デフォルトの名無しさん

2009/01/27(火) 15:07:35

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

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

0622デフォルトの名無しさん

2009/01/27(火) 15:19:42

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

0623デフォルトの名無しさん

2009/01/27(火) 15:27:43

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

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

0624デフォルトの名無しさん

2009/01/27(火) 15:41:09

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

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

0625デフォルトの名無しさん

2009/01/27(火) 15:44:46

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

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

0626デフォルトの名無しさん

2009/01/27(火) 16:07:20

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

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

0627デフォルトの名無しさん

2009/01/27(火) 16:52:13

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

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

0628デフォルトの名無しさん

2009/01/27(火) 17:07:13

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

0629デフォルトの名無しさん

2009/01/28(水) 00:22:27

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

0630,,・´∀｀・,,）っ-●◎○

2009/01/28(水) 00:23:33

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

0631デフォルトの名無しさん

2009/01/28(水) 03:40:42

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

0632デフォルトの名無しさん

2009/01/28(水) 20:07:39

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

0633デフォルトの名無しさん

2009/01/28(水) 20:34:58

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

0634デフォルトの名無しさん

2009/01/29(木) 02:21:17

>>608

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

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

0635デフォルトの名無しさん

2009/01/29(木) 02:27:06

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

0636デフォルトの名無しさん

2009/01/29(木) 03:07:28

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

0637 ◆0uxK91AxII

2009/01/29(木) 05:43:46

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

0638,,・´∀｀・,,）っ-●◎○

2009/01/29(木) 09:59:47

>>634
はぁ？

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

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

0639,,・´∀｀・,,）っ-●◎○

2009/01/29(木) 10:06:31

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

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

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

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

0640,,・´∀｀・,,）っ-●◎○

2009/01/29(木) 10:29:29

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

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

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

0641デフォルトの名無しさん

2009/01/29(木) 11:34:23

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

0642デフォルトの名無しさん

2009/01/29(木) 11:50:38

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

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

0643デフォルトの名無しさん

2009/01/29(木) 11:55:47

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

0644デフォルトの名無しさん

2009/01/29(木) 11:58:52

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

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

0645デフォルトの名無しさん

2009/01/29(木) 12:00:00

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

0646デフォルトの名無しさん

2009/01/29(木) 12:03:04

>>642
え?

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

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

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

0647デフォルトの名無しさん

2009/01/29(木) 12:04:55

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

0648デフォルトの名無しさん

2009/01/29(木) 12:05:52

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

0649デフォルトの名無しさん

2009/01/29(木) 12:14:11

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

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

0650デフォルトの名無しさん

2009/01/29(木) 12:22:18

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

0651デフォルトの名無しさん

2009/01/29(木) 12:36:06

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

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

0652デフォルトの名無しさん

2009/01/29(木) 12:39:27

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

0653デフォルトの名無しさん

2009/01/29(木) 12:42:20

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

0654デフォルトの名無しさん

2009/01/29(木) 12:44:12

>>652
>>648

0655 ◆0uxK91AxII

2009/01/29(木) 12:44:29

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

0656デフォルトの名無しさん

2009/01/29(木) 12:53:30

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

0657デフォルトの名無しさん

2009/01/29(木) 13:22:20

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

0658デフォルトの名無しさん

2009/01/29(木) 15:23:51

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

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

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

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

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

0659デフォルトの名無しさん

2009/01/29(木) 17:43:16

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

0660,,・´∀｀・,,）っ-○◎●

2009/01/29(木) 17:47:47

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

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

0661デフォルトの名無しさん

2009/01/30(金) 01:29:45

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

>>564
> >>542
> なんというCISC脳！

とつっこんだわけだが。
意味不明な突っ込みを続けている団子は池沼

0662デフォルトの名無しさん

2009/01/30(金) 20:55:57

なんでAMDのCPUは熱いの?

昔も熱かったから、K8で一時期ちょっと熱くなかったのが例外なのかも。

0663,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 00:26:04

AMDってL1ヒット時のピーク性能を極端に重視する傾向があるよね。
一方Intelは昔からL2の構成にこだわりがあるようで。

0664デフォルトの名無しさん

2009/01/31(土) 00:47:45

ベンチマーク対策じゃね?

0665デフォルトの名無しさん

2009/01/31(土) 01:47:28

>>663
ターゲットの違い

Intel → サーバーまでカバーしなきゃいけないので、大きなワーキングセットでの性能確保を重視
AMD → パソコンでの性能重視

ということかと。
パソコンのユーザに喜ばれるのは、当然、AMDのほうになるよね。

0666,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 01:51:09

いま別に喜ばれてないけど。
逆にAMDのほうがサーバでしか生きられてなくね？

極端に一部の性能を重視して熱密度が上がってしまい、逆に平均性能を上げられないというジレンマは
IntelがPentium 4で、AMDは現役で経験している通り。

0667デフォルトの名無しさん

2009/01/31(土) 01:59:24

>>665
Hammerは明らかにXeonのシェア切り崩しを狙ってただろうが・・・
大黒柱はずっとOpteronだよ

0668,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 02:12:09

AMDは今後2年間はデスクトップCPU市場見捨ててOpteronのコア数増やす方向らしいよ。

0669デフォルトの名無しさん

2009/01/31(土) 02:18:48

Nehalemにほぼダブルスコアで負けてるんだからコア数だけで追随しても無駄な努力
それに基本はコア数競争 = 微細化競争のバーベットゲームだし
AMDはトチ狂ったとしか思えない
最近の不況もあいまってVIAよりヤバイ状況

0670デフォルトの名無しさん

2009/01/31(土) 02:40:22

>>668
方向というかそれしか打つ手がないのが実情
コア改良で後れを取ってることが敗因だ

0671,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 03:01:31

「PhenomではSSEのために命令フェッチ帯域を2倍に増やした」（AMD談）

これはこれで方針としては正しくて、AMDの場合はロードユニット2つだから
メモリ間オペレーションを同時発行する機会を増やしたほうが性能は引き出せる。
で、メモリ間オペレーションはSIB, DISP32, imm8などをフルに使えば命令長が長くなるから、
安定供給するにはフェッチ帯域を増やさないといけない。

メリット（性能）とデメリット（熱密度・消費電力）のバランスを考えてIntelは先送りしたようだ。
AMDと違ってロードユニットの本数が少ないからそっち方面に振るメリットも相対的に小さいし。
Intelは256ビットSIMD（AVX）導入で実質的な命令サイズを節約する方向に向かってる。

AMDにとっては、SSEを使う多くのアプリケーションがIntel CPU向けに最適化される現状では
どうにもならない。それで、シェア50％を狙えるだけの生産ラインを確保なんていう、
現状を省みないプランを打ち出すにいたってると（笑）

景気が冷え込んで規模縮小しないとやっていけないご時世に
Intelにマーケティング上「勝てる」アーキテクチャと、製造キャパの両方を
求めないといけないなんて大変だな。

0672デフォルトの名無しさん

2009/01/31(土) 03:17:28

>>671
> シェア50％を狙えるだけの生産ラインを確保
これ自体は間違っていなかった(過去形)
ただその後IntelがCoreMAを発売、それを上回る性能のCPUをAMDが用意していなかったことが敗北の要因だ
それから以降はもうグダグダでしかない

0673,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 03:18:06

Nehalemでは、32μOPsだっけ？長い命令を使っても命令フェッチ帯域制限を掻い潜れる
ループバッファのエントリ数は。

これ結構きついんだよなぁ

0674デフォルトの名無しさん

2009/01/31(土) 04:19:30

>>668
どうやってコアを増やすのだろう。

ダイサイズが巨大になって歩留まりが・・・サーバ向けなら歩留まりが低くても大丈夫なのかな。
まさか、自らがマーケティングのために叩いた、複数ダイのMCMは・・・恥ずかしくて出来ないよな。
いや、恥ずかしいのはAMD厨だけで、ビジネスに徹するAMDは平然とヤルか。

0675,,・´∀｀・,,）っ-○◎●

2009/01/31(土) 05:17:28

AVXプログラミングリファレンス第5版出た
http://software.intel.com/file/10069

0676デフォルトの名無しさん

2009/01/31(土) 07:53:52

>>674
モノリシック6コアなのでダイサイズは巨大化するようだな。
あとMCMの話は2年前から出ていた。
最近の発表によるとMCMでは12コアと8コアが予定されているらしい。
12コアはそのまま6*2として8コアは (6-2)*2 かな？

0677デフォルトの名無しさん

2009/01/31(土) 10:09:36

もう液浸の時代かぁ。10年前には想像さえできなかったな。

0678デフォルトの名無しさん

2009/01/31(土) 16:19:15

GJだが直リンは遠慮しる

0679デフォルトの名無しさん

2009/01/31(土) 22:10:32

そもそもK8のHTは、MCMのために存在すると言っても過言ではない。
IntelのFSBも、そうだがな。

0680デフォルトの名無しさん

2009/02/01(日) 16:16:32

そんな主張は初めて聞いた
まあ確かにMulti-Agentが前提のFSBでBlackford(Woodcrest)みたいなPoint-to-Pointってのも不自然な気はしたが
どちらもChip-to-Chipの技術に過ぎないと思うが
あ、HyperTransportはバックプレーンとかにも使われているんだっけ

0681,,・´∀｀・,,）っ-○◎●

2009/03/13(金) 17:37:38

ageんか貴様ら！

0682デフォルトの名無しさん

2009/03/15(日) 16:23:42

死ね

0683デフォルトの名無しさん

2009/05/13(水) 05:33:40

落ちる

0684デフォルトの名無しさん

2009/05/31(日) 20:04:44

VT-xやSVMにおけるGuest-Host間の切り替え時間ってどんくらい？

0685デフォルトの名無しさん

2009/06/02(火) 11:23:55

>>684
vmrun-vmmcallでホストゲストを10往復させて計測してみました。
1往復あたり1000clkくらい@PhenomII
vmmcallのかわりにioインターセプトさせると、1080clkでした。

0686デフォルトの名無しさん

2009/06/02(火) 11:28:31

I/Oパターンによってはエミュレータの方が速そうだな

0687,,・´∀｀・,,）っ-○○○

2009/06/02(火) 20:34:34

ディスクフォーマットとかデフラグがアホみたいに速い

0688デフォルトの名無しさん

2009/06/03(水) 11:23:52

その昔、メインメモリが1MBの時代にバンクメモリを10MBくらい使ったディスクのドライバを書いたことがある。
当時はdefragが標準ではなかったから、defrag相当も自作した。
HDDは持ってなかったから、できたバンクメモリディスクで開発していたわけだ。
そうして、電源を切るとバンクメモリは消えてなくなることを身を持って再確認した。

06891 ◆.MeromIYCE

2009/06/10(水) 18:55:25

波のシミュレーションを書いたんだけど、
SSE2のコードがC言語比で1.2倍くらいしか速くならず、おかしいと思ったら、
扱うメモリがL2キャッシュを少しはみ出していた。
L2に収まるサイズでやり直したら、一気に3倍近い差になった。

L2に収まらない場合は、プリフェッチやmovnt系など、
まずメモリ関係をやらないと話にならないんだな。
知ってたけど久しぶりだから忘れてた。

0690デフォルトの名無しさん

2009/07/05(日) 22:13:17

>>688
＞当時はdefragが標準ではなかったから、defrag相当も自作した。
＞HDDは持ってなかったから、できたバンクメモリディスクで開発していたわけだ。
ををすごい、
どこがって？

>defrag相当も自作した。
>HDDは持ってなかったから
この部分に感動を覚えた

0691デフォルトの名無しさん

2009/07/07(火) 09:10:11

>>690
どこに感動を覚えたのかよく判らんが。
HDDを持ってないのにdefrag相当を作った辺り?
昔はフロッピーでさえfragmentの解消をしたもんさ。

0692デフォルトの名無しさん

2009/07/07(火) 15:34:31

フロッピーはインターリーブ考慮せんといかんな

0693デフォルトの名無しさん

2009/08/10(月) 20:15:17

このｽﾚノネナール臭が凄い……

0694デフォルトの名無しさん

2009/08/10(月) 22:46:09

skip sector & skew
->
track read / write + cache

0695名無し募集中。。。

2009/09/30(水) 00:32:04

先人がMMXアセンブラで作った関数のパフォーマンス改善をしています。
一部SSE化したり、アルゴリズム改善でだいたい1/2くらいまで縮まったので
AMD CodeAnalyst(Ver2.76)を使ってチューニングをしようとしているのですが勘所がわかりません。
Pipeline simulationを見ると、ピンク赤枠(SCHED FPU Scheduler ineligible)が貯まっていき
パイプラインの幅が広がってしまいるようです。
一般的な目安として、どのような部分に注目してチューニングすれば良いでしょうか?
とりあえずは、Notesに書かれた「Bank conflict」や「Stlf 31:12」などの部分を何とかしようかと思っています。

0696デフォルトの名無しさん

2009/09/30(水) 09:42:24

一旦Cで書き直してコンパイラに任せた方が早かったりしてね。

0697,,・´∀｀・,,）っ-○○○

2009/10/11(日) 02:52:16

整数でMMXの倍出れば充分だよ

0698名無し募集中。。。

2009/10/11(日) 03:16:03

開発機のAthron64x2での評価で1/2くらいになったと言っていたんですが
実機のCore2Duoで動かしたら、元のプログラムの実行速度が上がり
相対的に2割くらいしか改善されないという情けない結果になりました。
AthronとCore2Duoの差というより、L2キャッシュの容量が512Kと2Mの差なんだと思います。
その後SSEのみで書き直し、3割改善まで進んだところで今のところギブアップです。
CodeAnalystはAMDのCPUじゃないと動かないので、V-Tune評価版で
試してみる価値があるかどうかという所です。

0699,,・´∀｀・,,）っ-○○○

2009/10/11(日) 04:07:48

http://software.intel.com/en-us/articles/intel-architecture-code-analyzer/

Core 2とは特性は若干違うがこれ使ったら？

0700名無し募集中。。。

2009/10/11(日) 04:17:30

紹介ありがとうございます
試してみますね

0701デフォルトの名無しさん

2009/10/11(日) 04:30:29

AMD用にチューニングしたコードをIntelに持っていって
果してどのくらい意味があるのだろうか？

0702デフォルトの名無しさん

2009/10/11(日) 09:35:15

Intel用に最適化したのをAMD機で動かすより意味あると思うけど・・・

0703,,・´∀｀・,,）っ-○○○

2009/10/11(日) 10:27:37

どっちもない。
Intelは乗算や水平加減算以外の整数命令はほぼレイテンシ1だが　
AMDのはほぼ2だから全然特性が違う。

07041 ◆.MeromIYCE

2009/10/11(日) 11:38:24

細かいこと考えて最適化しても、
結局L2に収まるか収まらないかで全てが決まってしまう現実。

面倒だが、L2サイズを基準に処理を分割できれば
かなりのオーバーヘッドがあっても元は取れるはず。

0705デフォルトの名無しさん

2009/11/17(火) 08:17:58

Optimization Reference Manualの間違いなのか事実なのか知らないけど、
なんで一部のプロセッサでandpsがスループット1でとpandが0.33なんだろう。

単精度用にandpsでmmx上がりの整数用にpandってのは
命令フォーマット上は確かに一貫していて扱いやすいんだろうけれど、
たかだかビット演算で速度に違いが出てくるくらいならオペコードを複数用意しちゃいかんと思うのだが。
試してないけどコンパイラオプションでSSE2以上を指定したら
問答無用で_mm_and_ps()をpandにするくらいの責任を取って欲しい。

0706デフォルトの名無しさん

2009/11/17(火) 10:08:49

XMMを使用するので同じ命令に見えるかもしれないが
CPU内部では整数ドメインとFPドメインに分かれていて
それぞれに作用する命令なんだ

異なるドメイン間でデータのやり取りが発生すると
ペナルティーを受けるから、命令は扱うデータに
合わせるべきだね

0707,,・´∀｀・,,）っ-○○○

2009/11/18(水) 00:06:35

ちなみにSandy Bridgeでは{and,andn,or,xor}psを発行出来る演算ユニットだけが256ビット化される。
ビット論理演算のスループットはNehalemの1.33倍！

そして、Macro Ops Fusionが熱い！ヤバイ！間違いない！
dec + jccとか and + jccも融合可っだ。ハゲっが。

0708,,・´∀｀・,,）っ-○○○

2009/11/18(水) 00:39:12

正確には3オペランドになるぶんMOV*が削減できるので
1.5倍以上かも

0709デフォルトの名無しさん

2010/01/22(金) 10:53:07

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

0710デフォルトの名無しさん

2010/03/04(木) 12:42:56

最適化マニュアルに載ってないAESNIとかPCLMULのレイテンシ

DualCore Intel Core i5 650, 3600 MHz (26 x 138) (Clarkdale)
ttp://www.freeweb.hu/instlatx64/GenuineIntel0020652_Clarkdale_InstLatX64.txt

0711デフォルトの名無しさん

2010/03/14(日) 03:45:01

Pentium4のHyperThreadingは、
片方のコンテキストのメモリアクセスでパイプラインが止まると、
もう片方のコンテキストまで止まってしまうって本当?

そして、AtomやNehalem以降の同名の別モノでは、どうなの?

0712デフォルトの名無しさん

2010/03/14(日) 20:25:07

聞いた所で聞けよ

0713デフォルトの名無しさん

2010/03/14(日) 21:33:46

HyperThreadingはまやかし

0714デフォルトの名無しさん

2010/03/14(日) 21:42:27

Pentium4の偏見で凝り固まった人は案外と多い
HyperThreadingと聞いただけでイラネーヨという

Pentium4がK7 Athlonよりも省電力とかいうと
キチガイを見る目で聞く耳を持たない人とかも

0715デフォルトの名無しさん

2010/03/14(日) 23:14:53

国母のアンチみたいなもん

0716デフォルトの名無しさん

2010/03/14(日) 23:21:11

>>714
俺もその口だが、HyperThreadingっていくつかの条件がついた状況でしか使えないから
結局動画のエンコードぐらいしか役に立たないと思ってる。
また、XPも対応が不十分だったりしたと思ったが最近はそうでもないのか？
XPに固執するほど結果は出ないみたいな。

0717デフォルトの名無しさん

2010/03/14(日) 23:22:52

なんで欲張ってSMTなんかやるんだろ
Itanium2のようにCGMTでいいじゃんか

0718デフォルトの名無しさん

2010/03/14(日) 23:24:21

実装に必要なハードウェアリソースはごくわずかだから

0719デフォルトの名無しさん

2010/03/14(日) 23:26:26

HyperThreadingが狙いとしていたのは動画のエンコードのように、
パイプラインにファイン・チューニングできる(された)コードではなく、
パイプラインがスカスカになるような駄コードを2つまとめて流せば、
実行ユニットが遊ばずに有効活用できて性能が上がりますよ
ということだったと思う

0720デフォルトの名無しさん

2010/03/15(月) 00:10:30

>>719
そんなコンパイラはどこにあるのだ。

ああ、gcc, bcc, java辺りか?
ADDが倍速だったりその他諸々、チューニングされていないようなプログラムが使う命令はスカスカになりにくいと思うんだが。

0721デフォルトの名無しさん

2010/03/15(月) 00:31:05

Pentium4はOOO性能が低いっぽくて、命令の並び順を変えると速度が変ったりするんで、普通のコードはスカスカになるんじゃないかと。

0722デフォルトの名無しさん

2010/03/15(月) 14:29:20

>>711
初期のPentium4 with HTでは、(PentiumProと同じで)
L1Dキャッシュミスを4つまでしか保持できないので、
片方のスレッドで5つのキャッシュミスを起こすとロードユニットが完全停止して、
もう片方のスレッドも実質止まってしまうという事はあると思う。
その後のCPUではキャッシュミス保持数が倍増されている。

0723,,・´∀｀・,,）っ-○○○

2010/03/16(火) 12:58:55

NetBurstの設計者が自ら言ってるようにL1Dの容量が絶対的に少ないだろう

0724デフォルトの名無しさん

2010/03/16(火) 15:02:19

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$ミスすると両方のコンテキストがストールする

0725デフォルトの名無しさん

2010/03/16(火) 15:05:43

キャッシュミスで全部とまっちゃぁ、DRAMのレイテンシの隠蔽にはならないなぁ。
もしキャッシュミスで止まらなければ、DRAMのレイテンシは数百クロック分にもなるわけで、1000命令くらい実行できる。

で、AtomやCore iはどうなんでしょう?

0726デフォルトの名無しさん

2010/03/16(火) 19:02:58

メモコンをCPUに持ってきた

0727デフォルトの名無しさん

2010/03/16(火) 22:10:52

ということは、それらのHTも相変わらずメモリのレイテンシを隠蔽できない、ってことか。

0728デフォルトの名無しさん

2010/03/16(火) 23:09:23

なんで「ということは」でそういう結論になるのかさっぱり分からん。

0729デフォルトの名無しさん

2010/03/16(火) 23:18:22

アム虫だから

0730デフォルトの名無しさん

2010/03/16(火) 23:20:29

だからお前らFB-DIMMが流行るまで我慢しろって

0731デフォルトの名無しさん

2010/03/16(火) 23:24:52

レイテンシ激増じゃねえか

0732デフォルトの名無しさん

2010/03/16(火) 23:33:50

わかってねえなあ
FB-DIMMはクロック数や容量を上げるのが簡単なんだよ

0733デフォルトの名無しさん

2010/03/16(火) 23:36:25

レイテンシーが増えるという指摘にそういう的外れな返答しかできない辺り
「わかってねえなあ」

0734デフォルトの名無しさん

2010/03/16(火) 23:39:24

消費電力と温度を上げるのも簡単

0735デフォルトの名無しさん

2010/03/16(火) 23:41:44

Pen4の悪夢再び？

0736デフォルトの名無しさん

2010/03/16(火) 23:43:33

FB-DIMMは終わったから悪夢はもう来ない

0737デフォルトの名無しさん

2010/03/16(火) 23:46:19

まだ終わってないけど一般人には関係ない

0738デフォルトの名無しさん

2010/03/16(火) 23:47:05

レイテンシが増えてもFSBを上げればいいじゃない

0739デフォルトの名無しさん

2010/03/16(火) 23:47:53

>>728
え? >>726はどういう意図での発言なんだろう。

0740デフォルトの名無しさん

2010/03/16(火) 23:49:09

>>738
そんなもんもう無い

0741デフォルトの名無しさん

2010/03/17(水) 00:09:33

FB-DIMMはレイテンシは大きいけどランダムアクセスでのバンド幅が大きいんじゃなかったっけ?

普通のDDR2やDDR3は、ちょっとした並列処理はしてくれるけれども、
メモリコントローラとDRAMがピッタリ歩調を合わせて動作しないといけないので、
DIMMを何枚積んでも、容量方向の拡張でしかなかった。

しかしFB-DIMMは、パケットベースでインテリジェントに動作するので、
DIMMを詰めば積むほど、並行してアクセスできるメモリが増えて行く。
また、ライトバックが許される書き込みをキューに入れて後回しにして、
早くデータを返すべき読み込みを先に行うとかも、やれるとか。

それで、
SunのNiagara2っていう1チップで8スレッドSMT×8コアで64スレッドも同時に走るCPUは、
FB-DIMMを大量に積むことでパフォーマンスを確保しているとか。

0742デフォルトの名無しさん

2010/03/17(水) 00:21:21

>>741
そうだよよくわかってるじゃないか
問題はDIMMがあまりにも流行りすぎてFB-DIMMが高価なままって
所にあるんだ
もちろんバッファリングするのでレイテンシは増えるが、動作は安定化
するので電気的にいろいろ無理させやすい

0743デフォルトの名無しさん

2010/03/17(水) 00:25:26

自演してデタラメをまき散らすのってどうなんだろう。

0744デフォルトの名無しさん

2010/03/17(水) 00:25:59

自演じゃねーよ
運営に頼んでホスト教えてもらえ

0745デフォルトの名無しさん

2010/03/17(水) 00:27:15

あ、ageになってた
sageに変えた

上がってると書きこみが余計糞に見えやすいしな

0746デフォルトの名無しさん

2010/03/17(水) 00:54:30

>>739
え？といわれてもなぁ。>726!=>728だし。

「ということは」がなににかかっているにせよ、なんで「レイテンシが隠蔽できない」と結論を出したのか意味不明。

0747デフォルトの名無しさん

2010/03/17(水) 01:53:00

しかしアレだよな
Core2もi7もL2キャッシュにバカでかいメモリを積んでようやく性能を
確保している事を考えると、メインメモリのレイテンシって本当に動作
速度の足を引っ張っているんだな

0748,,・´∀｀・,,）っ-○○○

2010/03/17(水) 03:14:59

演算ユニット当たりのバンド幅考えるとGPUのほうが状況は酷いけどね

0749デフォルトの名無しさん

2010/03/17(水) 03:25:31

たとえば3%のキャッシュミスを減らそうとしたら大変よ。
繰り返し実行されるような部分ではない部分がキャッシュミスしやすく、
そういうところは予測が付きにくく十分早期にプリフェッチかけるのも困難。
だから、CGMTで。

0750,,・´∀｀・,,）っ-○○○

2010/03/17(水) 03:29:40

>>917
コード希望

0751デフォルトの名無しさん

2010/03/17(水) 04:07:32

wrong pathｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ｯ!!!

0752,,・´∀｀・,,）っ-○○○

2010/03/17(水) 23:55:23

x86のようなレジスタ本数が少なく依存関係のチェインを抱えがちな命令セットには
SMTはかなり有効なんだけどな。

IPFがSMTではなくCGMTを採用してるのはは、コンパイル時に依存関係が明示されてるから
リソース競合は起こりえない（けどキャッシュミスは起こる）ってVLIWらしい発想だと思うけどなー。

0753デフォルトの名無しさん

2010/03/18(木) 00:36:32

SMTやるかわりにOOOやらない → あとむ
SMTやるくらいなら実行ユニット減らしてコア増やす → ぶるどーざー
なんだかx86でSMTは贅沢な気がする

IPFがCGMTなのは、シングルスレッド性能追求のアーキテクチャだからだと思う。
マルチスレッドでスループットが出ればいいっていうのなら、投機実行とかゴッソリいらないし。

0754,,・´∀｀・,,）っ-○○○

2010/03/18(木) 02:23:02

BulldozerのIntegerクラスタはスレッド毎に持ってるからSMTとは言えないけど
FPクラスタは共有だから部分的にはSMTそのものだろ

0755デフォルトの名無しさん

2010/03/18(木) 02:29:59

そうだね。

IPFはシングルスレッド性能追求という、時代の流れに反するアーキテクチャだが、どーするんだろ。
実際、IPFのシングルスレッド性能っていうのは、どれくらいx86よりも速いんだ?

0756,,・´∀｀・,,）っ-○○○

2010/03/18(木) 02:36:09

ベストケースで6オペレーション同時発行だから、はまればクロック当たりでx86を越えるけど
3GHzのCore i7の方が速いという現実。
速さは売りにしちゃ駄目。

あとは信頼性（笑）か。
うに死すは取るに足らない物としてItanium引き上げてXeon MPに枕替えしたけどね。

HP-UX使いたい人向けのプラットフォームだね。

0757デフォルトの名無しさん

2010/03/18(木) 02:58:03

信頼性つっても後づけじゃね?
アーキテクチャ的に信頼性を高めているわけではないよね。

どうせ後づけならXeon・・・は複雑すぎてどーにもならんか。

0758,,・´∀｀・,,）っ-○○○

2010/03/18(木) 03:03:33

一応IPFはチップレベルで多数決冗長系が組める

0759デフォルトの名無しさん

2010/03/18(木) 03:10:55

IPFに興味があるならWindowsのWDK(旧名、DDK)に入ってるIA64用のコンパイラで
/FAcsオプション付けてコンパイルして出力される.CODを除いてみると、面白いぞ
x86環境でのクロスコンパイラだから実機なくても動くから

nopが挿入されまくりだから

0760デフォルトの名無しさん

2010/03/18(木) 03:12:17

>>758
それが可能なのはIPFだからではなく、IPFには実装したけどXeonには実装していない、というだけだよね。
同じ機能をXeonにも付けようと思ったら付けられるんじゃね?

0761,,・´∀｀・,,）っ-○○○

2010/03/18(木) 03:27:08

前提となるメモリコヒーレントモデルが異なる（従来x86では不向き）ので
仮にできても既存のx86資産捨ててまでやる意味がどこまであるかと言う謎

（その点例の試作品48コアのSCCではある意味禁忌をおかしてるわけだが）

0762デフォルトの名無しさん

2010/03/18(木) 04:01:24

むー、それなりに理由があるのか。

あんまり普遍的ではないコードで申し訳ないが↓をコンパイルしてみた

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で入りまくりというのも過敏なような

0763デフォルトの名無しさん

2010/03/19(金) 02:00:53

ユーザーモードの互換性は確保するけど
特権モードの互換性は取らない

っていうのもアリじゃない?
ページ単位にコアが占有していればアクセスできるけど、
占有してなければページフォルト発生して特権モードで処理するとかすれば。

0764デフォルトの名無しさん

2010/03/20(土) 02:43:36

各種CPUのパイプラインをシミュレーションするツールが欲しくなるなぁ

0765デフォルトの名無しさん

2010/03/23(火) 03:38:22

TLBキャッシュミスやレジスタウィンドウのオーバーフローをトラップで処理しているCPUがあったが、遅かったぞー

0766デフォルトの名無しさん

2010/04/01(木) 06:56:11

Corei7の動作クロックを取得する方法ってないんですか？
ｒｄｔｓｃを使ってクロック数を取得して、実行時間を掛けても、
設定クロックにしかなりません。
TurboBoostがかかっているかどうか知りたいのですが・・・。

0767デフォルトの名無しさん

2010/04/01(木) 08:28:44

>>766
http://download.intel.com/design/processor/applnots/320354.pdf?iid=tech_tb+paper

0768デフォルトの名無しさん

2010/04/02(金) 03:39:48

>>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);
こんな感じで値を読んでいたので、
多少遅延がありそうですが、何とか出来そうです。

0769デフォルトの名無しさん

2010/04/23(金) 08:29:45

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

0770デフォルトの名無しさん

2010/08/26(木) 01:40:22

SandyBridgeでSIMDを256bit幅に拡張するというけど、
なぜ128bit幅のまま実行ユニットを倍加する、
という選択肢を取らなかったの?

・同時に実行する命令数が増える=そのハンドリングのための回路で消費電力アップ
・実行ユニットを倍にしても、現状のレイテンシ・スループットに合わせて書かれたコードでは実行ユニットが遊んでしまう
あたり?

0771デフォルトの名無しさん

2010/08/27(金) 12:03:26

>>770
大体そう
スケジューリングをはじめとしたコントロールのコストがデータフローに関わるコストを遙かに上回ってるから。
SIMDユニットそのものの幅を倍に増やす方式だと、データ幅が256ビットに増えても、
内部データバスを256ビットにするだけで、パイプライン構造はCore MAとほぼ同じでいける。

だから消費電力あたりのSIMD演算性能はほぼ倍になる。

128ビットの演算ユニットを倍に増やす方式だと演算ユニットを増やした分だけ制御ブロックが肥大化するので
電力効率的にも美味しくないと思われる。

0772デフォルトの名無しさん

2010/08/28(土) 10:20:10

ありがとう

ちなみにAMDのBulldozerは実行ユニットを256bit幅にせず、128bit幅×2個の構成にしてる・・・どうなんでしょう。

0773デフォルトの名無しさん

2010/08/28(土) 16:08:35

もともとが128ビットSSE5を想定した設計で急遽256ビットAVX対応に作り替えたからでは。
まあ、FMAの実装ではAMDが先行してるし、ゆくゆくはAMDが256ビット化、IntelがFMA対応で
実質的な差が無くなるのではないかと。

0774デフォルトの名無しさん

2010/08/29(日) 06:08:06

なるほど。

BulldozerのFPUは2つのコアで共有されるから、
128ビット×2個といっても、1コアあたりでは1個。

もし、256ビット×1個にすると、1コアあたりでは0.5個
既存の128ビットの命令を使ったコードの速度が遅いのだろう。

新命令の追加タイミングと、演算器の強化タイミングは、一緒とは限らず、
128ビットのSSE2命令が追加された当初は、64ビット×2回で処理してた

せっかく新命令を使って書いたのに速くならない・・・っていう不満があると、
AVXを使ってもらえないので、新命令と同時に演算器強化するのかな

ソフトの互換性という点では、新命令は速くなくていいから早めに実装してほしい

07751 ◆.MeromIYCE

2010/08/29(日) 09:11:19

128bitが256bitになると、論理レジスタが倍増したことになる。
だからその分は速くなると思うよ（並列実行できるという意味で）。
スループットが糞悪いPentiumMのSSE2浮動小数点も効果あったし。

0776,,・´∀｀・,,）っ-○○○

2010/08/31(火) 00:19:05

YMM上位だけを更新する命令とかあるなら32本のXMMレジスタとしても活用しようがあるんだけど
上ゼロクリアか、上下同じ操作か、しかない。

このへんはMMレジスタとXMMレジスタが独立してたのとちと扱いが違う

0777デフォルトの名無しさん

2010/08/31(火) 03:30:24

全部レジスタに乗るような順番で計算するよりも、
L1D$との間で出し入れをしてでも、依存関係のある命令間の距離を長くしたほうが、
スループットが出たりするんだよねぇ。

0778デフォルトの名無しさん

2010/08/31(火) 10:41:36

>>777
mov(load or reg2reg)命令でdestオペランドを上書きしながら反復処理をアンロールすれば
空いてる物理レジスタに自動的に割り振ってくれるから
ほどほどにやっておけばいいよ。
どのみち同時に読み出せるオペランド数に制限があるからそこで頭打ちになる。

まあ、AVXでdest独立になったのは美味しいな（ほぼ全部の命令がリネーミングのヒントになりうる）

0779710

2010/09/08(水) 15:31:49

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

0780デフォルトの名無しさん

2010/09/11(土) 23:20:30

http://wiredvision.jp/news/201009/2010090823.html

0781デフォルトの名無しさん

2010/09/13(月) 09:37:39

L1D$のレイテンシが2→3→4と拡大してるんだが、どーにかならんの?

0782デフォルトの名無しさん

2010/09/18(土) 14:28:35

AMDのCPUID Specificationが更新されました
http://support.amd.com/us/Processor_TechDocs/25481.pdf

BMI(Bit Manipulation Instruction)は未公開の新命令でしょうか?

0783,,・´∀｀・,,）っ-○○○

2010/11/03(水) 16:50:07

こんにちのOoOEなCPUにおいてL1キャッシュのレイテンシそのものは本質的な問題なのかね？

現代のCPUはL1ヒットを前提にスケジューリングされる。
アドレス解決さえ先行してできれば、どんどん空いた物理レジスタ（orメモリフォワーディングバッファ）
に先読みしておけるということ。
レイテンシが大きくなればなった分だけそのサイクル数ぶん先読みをしておく必要があるけどね。
Memory DisambiguationとかRAWハザードを回避するためのテクニックがどんどん採用されて
L1のレイテンシが性能に響くケースは少なくなりつつある。

L2以下は別。理由はまったく同じで、L1キャッシュヒットを前提にスケジューリングされてるから。
つまりL2キャッシュのロードレイテンシは隠蔽できない。

0784デフォルトの名無しさん

2010/11/03(水) 21:24:27

お、団子さんひさしぶり

0785デフォルトの名無しさん

2010/11/04(木) 14:47:31

団子さんはどうしてそんなに詳しいのだろうか・・・

0786,,・´∀｀・,,）っ-○○○

2010/11/07(日) 08:13:17

アドレス解決が先に行えないケースを反例としてだしておくれ。
暗号化のテーブルルックアップ処理を頻繁に行うものはパフォーマンス総崩れかもね
AESNIを使えということだろうが。

0787デフォルトの名無しさん

2010/11/08(月) 02:15:08

OOOは、
後続の命令で実行できるものをどんどん実行するのではなく、
先方にある命令で実行できるものをどんどん実行するの?

0788デフォルトの名無しさん

2011/01/07(金) 08:06:53

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

0789デフォルトの名無しさん

2011/01/07(金) 11:15:31

最適化マニュアルにSandy Bridgeの情報が追加された
http://www.intel.com/Assets/PDF/manual/248966.pdf

0790,,・´∀｀・,,）っ-○○○

2011/01/07(金) 14:27:08

SSE4が全面的に速くなってる。
AES-NIレイテンシが増えてる。
これによってCBC/CFBなどのブロック依存関係のある暗号化形式が遅くなるが十分速いのでさして問題ないか。
そしてスループット1になったことでECBが倍ほど速くなるわけだが・・・

0791|ω・`)

2011/01/07(金) 17:13:45

leaがついに劣化してしまった

0792デフォルトの名無しさん

2011/01/07(金) 17:43:48

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なのか

0793デフォルトの名無しさん

2011/01/08(土) 02:14:31

>>788
SIMD整数加算もFP加算器と共用みたいなことを云われていたが、レイテンシを見る限り従来と変わっておらず、これに関しては別個のSIMD整数加算器のままなんだろうね

0794デフォルトの名無しさん

2011/01/08(土) 07:24:03

ttp://www.freeweb.hu/instlatx64/CentaurHauls00006F8_CNB_Isaiah_InstLatX64.txt
名ばかり実装かと思いきや、nanoは結構まじめにSSE4.1実装してるね

0795デフォルトの名無しさん

2011/01/08(土) 07:27:29

ああ、nanoはメモリの書き込みは速いけど
読み込みが遅い

それが改善されれば、SSE関連ではもっとパフォーマンスあがるはずだ
Padlockはメモリアクセスで頭打ちになってる

0796デフォルトの名無しさん

2011/01/08(土) 10:29:22

SSE4.1の速さをもてはやす理由が分からん。
例えばROUNDPSなんてIntelが手抜きでオペコード作ってなかっただけで、初代SSEに入っていておかしくない基本的な命令だろ。
ソフトウェアで書くとややこしく遅いが原理は簡単。むしろハードウェアで作って他の命令より大幅に遅くなる事なんて考えられん。

0797デフォルトの名無しさん

2011/01/08(土) 14:29:43

別にroundは速くなってないよ。元々スループット1だし。

例えばblendvはプレディケーションちっくな事をやる時に
and-andn-orとやってたのが1命令で済むので、
スループット1になったのは嬉しいと思うけどね。

0798,,・´∀｀・,,）っ-○○○

2011/01/08(土) 18:11:56

dppsが速いのは3Dでは結構重要。
なによりmpsadbw/pminposuwが速い。

0799デフォルトの名無しさん

2011/01/08(土) 18:22:59

mpsadbw/pminposuwはスループット変わらず、
レイテンシの分遅くなっているように見えるけど

0800,,・´∀｀・,,）っ-○○○

2011/01/08(土) 18:36:02

ああ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

速くなったり遅くなったりわけわかめ

0801デフォルトの名無しさん

2011/01/08(土) 21:43:14

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の帯域ではないのか？

0802デフォルトの名無しさん

2011/01/08(土) 21:47:31

まあまあｗ
いつもの大原節です

0803デフォルトの名無しさん

2011/01/09(日) 23:35:02

たしかに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 |
-----------------------------------------------------------------------------------------

0804デフォルトの名無しさん

2011/01/13(木) 02:08:15

Optimization Reference Manualのスループットを見る限り、VDIVPS/PDは128ビットずつ計算してるのか？
そしたらVRCPPS使った方が速くなったりするのだろうか。
実機がないから分からん。

0805,,・´∀｀・,,）っ-○○○

2011/01/13(木) 03:13:10

VRCPPSも128ビットずつだよ。
11ビット精度で十分ならそれでいい。

0806デフォルトの名無しさん

2011/01/13(木) 07:36:04

いや十分な精度が欲しい場合にNehalemではDIVPSが速すぎて
RCPPSがいらない子だった、というか正常進化でお役御免だったわけだけど
Sandy BridgeではまたNewton-Raphson使った方が良かったりするの？
旧石器時代に逆戻りなら勘弁してほしいなあ、というお話。

0807デフォルトの名無しさん

2011/01/13(木) 07:48:55

RCPPSが12ビットならNewton-Raphsonでもいいんだけどな。
可能な限り精度が欲しい場合に、2ビットの精度を求めてVDIVPS使うと
ものすごい遅くなるというのが解せない。

0808,,・´∀｀・,,）っ-○○○

2011/01/14(金) 17:00:10

その可能な限りってのがどんなケースかによるな。
たとえばA±B/CをやるとしてAとB/Cで絶対値が2ビット以上違う場合は2段のNewton-Raphsonで十分だし。

0809デフォルトの名無しさん

2011/01/16(日) 15:18:31

>>790
ソフトウェア屋としては、
新命令は(従来命令を使った場合と同程度の速度であれば)速くなくてもいいから、とにかく実行できる段階
を経てから
新命令が速く実行できる段階
にシフトするのが良いと思うから、Intelの導入の仕方は歓迎だよ。

0810デフォルトの名無しさん

2011/01/16(日) 15:20:55

>>791
8086の頃から、LEA命令の存在は疑問に思ってた。
実行時にアドレスを計算せずとも、
アセンブル時にアドレスが決まるものはそうすべきだし、
そうでないにしても普通に計算すりゃいいじゃん、と。

0811デフォルトの名無しさん

2011/01/16(日) 15:25:03

LEA を使えば、一度に 3 つ以上の数を足し込める。
アドレス計算のためにたくさん積んでる加算器を有効に使えるわけさ。

0812デフォルトの名無しさん

2011/01/16(日) 17:04:38

そっか、
LEA BX, [BX + SI + imm8/16]
とか、
LEA EDX, [EBX + EAX*4 + imm]
とか、
できるんだ。

CISCすげー

0813,,・´∀｀・,,）っ-○○○

2011/01/16(日) 19:32:01

たとえば3n + 1問題を高速に解くとか？
lea eax, [eax + eax*2 + 1]

整数即値の乗算も2倍、3倍、5倍、8倍、9倍あたりならLEA使ったほうが速いです。
さらに言うとsource, dest独立なので命令数も少なくなる

0814デフォルトの名無しさん

2011/01/16(日) 21:45:27

どうりでIA-64が同クロックのx86に勝てないわけだ。
MIPSと比べるとIA-64は強力だけど、x86には及ばないな。

もはや加算器やシフタなんてタダ同然なんだなー。

0815デフォルトの名無しさん

2011/01/16(日) 23:50:34

RISCを擁護する気はないけど、CISCだから凄いってのも違う気がする。
レジスタ数が128本も無くてオペコードに余裕があったら4バイト即値は不可能としても、似たようなのがCell辺りに入っていてもおかしく無さそうだし。

ま、歴史的な経緯とか色々理由はあるだろうけれど
当時需要があって、今でも十分使える遺産って事でしょ。
SSE/AVXのある今となっては16倍や32倍もあれば便利だったねってところ。

0816,,・´∀｀・,,）っ-○○○

2011/01/17(月) 00:39:13

> SSE/AVXのある今となっては16倍や32倍もあれば便利だったねってところ。

これはたしかに。64ビット拡張とかのタイミングでscaleをもう1ビット増やして欲しかったな。
もっとも今カウンタ変数の更新にinc/dec使わないからあまり意味無いんだけど。
ただ、8倍まで表現できれば64ビットスカラ整数のオフセット算出を「タダ」でできることになる。

RISCの大半はアドレス計算もALUでやるものが多いからなあ。
Cell SPEはいちいち「積和算」が必要なんだぜ
ARMは論理レジスタを16本に抑えてプレディケートやバレルシフタにコード空間を割いてるから
多少マシという程度。

0817デフォルトの名無しさん

2011/01/17(月) 14:32:58

え?
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
ってな具合にしてくれればよかったのにね。

0818,,・´∀｀・,,）っ-○○○

2011/01/17(月) 17:31:52

それはそれで困るけど・・・

indexを4の倍数、8の倍数にしとけば良い話だしな。
x64では1バイトOpcode空間から削除されてしまったinc/decをつかおうってんじゃないだろ？

0819デフォルトの名無しさん

2011/01/19(水) 23:49:56

Bobcat
ttp://www.freeweb.hu/instlatx64/AuthenticAMD0500F10_K14_Bobcat_InstLatX64.txt

0820デフォルトの名無しさん

2011/01/27(木) 00:28:28

ItaniumにはClassic Pentiumが丸ごと入っているっていう噂を見かけたのだが、本当?

Intelの資料には、
命令フェッチやデコード、スケジューラやリタイアメント等はIA-32専用だが、
レジスタや実行ユニットはIA-64用と共用されていると書いてあるらしいのだが。

0821デフォルトの名無しさん

2011/01/27(木) 21:54:57

>>820
今頃知ったのか
でも結局使い物にならなかったな

0822デフォルトの名無しさん

2011/01/27(木) 23:05:16

命令の所要クロックを比較すれば、噂が本当かどうか、分かるのかな。

0823デフォルトの名無しさん

2011/01/27(木) 23:21:05

64bit化の時に、
andn, xnor, nand とかの整数命令をもうちょっと強化してもよかった気がするなあ。
回路的には大したことないはずだし。

0824,,・´∀｀・,,）っ-○○○

2011/01/28(金) 00:06:50

andnはVEXフォーマット採用で3オペランド形式になりますよ

0825デフォルトの名無しさん

2011/01/28(金) 04:12:34

>>820
ウソだろ

Pentium200MHz前後と同程度の速度しか出ないが、しかし、SSE対応ですぜ。

0826デフォルトの名無しさん

2011/01/28(金) 05:04:50

アウトオブオーダ実行しておきながら800MHzで200MHz相当の速度しかでないって、どんだけ・・・。

0827デフォルトの名無しさん

2011/01/28(金) 07:38:04

>>824
xmmじゃなくて汎用レジスタのだよ。

汎用レジスタはほとんど進歩してない。
3オペランドとか無理だったのかな？

0828,,・´∀｀・,,）っ-○○○

2011/01/28(金) 07:50:02

いや、その汎用レジスタ版のandnがVEXフォーマットなのよ。
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01766.html

AMD独自命令かと思いきやBMIのCPUID Feature FlagはIntel側の空間にある。

0829デフォルトの名無しさん

2011/01/28(金) 21:00:16

まぢか？
Haswellとかに載るのか？

でもやっぱり64bitになった時に見直すべきだったと思うな。
途中からじゃほとんど使われないままになってしまう。

0830デフォルトの名無しさん

2011/01/28(金) 23:47:56

AMD64は悪貨ですから。未来に負の遺産を残すことなんか、気にしちゃイネエ。
IA-32からの変更を少なく抑えることで、ローコストに32bitと64bitの両対応とし、
IA-64を叩き割るのが、AMDの取った貧者の核兵器的な戦略ですから。

0831デフォルトの名無しさん

2011/01/29(土) 03:07:21

AMDのくせに生意気だ！
ってことですね。わかりますｗ

0832デフォルトの名無しさん

2011/01/29(土) 04:51:10

どうした? 意味がワカラン。

0833デフォルトの名無しさん

2011/01/29(土) 07:52:38

>>830
まさしく負の遺産。
命令大変更の最後のタイミング、非常に重要なタイミングを、
intelより先に行くという目的のために使ってしまったAMDの罪は重い。

0834デフォルトの名無しさん

2011/01/29(土) 10:43:26

intelにゃ最初からできないだろう。SSEのように後からダラダラ醜い建て増しをしていくのが目に見えてる。

0835デフォルトの名無しさん

2011/01/29(土) 15:12:08

でも結果オーライだったじゃん
OSやコンパイラの大きな変更無しに64bitに移行出来たんだから
かたやItanium2の凋落はどうだ？ひどいもんだろう
いくら最新のVLIWで御座いますって言ってもソフト資産が無い事には
流行らないってはっきりわかってしまったからな

0836デフォルトの名無しさん

2011/01/29(土) 16:54:57

>>834
インテルは実際にやったじゃん、IA-64を。

>>835
> OSやコンパイラの大きな変更無しに64bitに移行出来たんだから

WindowsやLinuxは、AMD64よりも先にIA-64に移植されましたよ。
Windowsに関して言えば、AMD64版はx86版からの移植というよりは、IA-64版からの移植ですよ。

Itaniumはx86命令の実行速度が遅いのが問題だった。
x86の膨大なソフト資産がそのまま走るのに、それが遅いことをさして「互換性がない」とまで言われる始末。

初代Itaniumに関しては、消費電力的にもコスト的にも、Pentium3のダイをMCMする余裕があったのだから、
なりふりかまわず、そうしていればよかったのにね。

0837デフォルトの名無しさん

2011/01/29(土) 17:23:01

市場がIA64についていかなかった時点で、
命令セットそのものではなくAMD64という戦略を叩く>>830,833はお門違い。
スレの趣旨にも反する。

0838デフォルトの名無しさん

2011/01/29(土) 17:28:43

戦略というより実装だな
今後の事なんだからもっとすり合わせても良かった

0839デフォルトの名無しさん

2011/01/29(土) 18:31:23

もしintelがIA64を投入せず代わりにAMD64のような64bit拡張をしていたら、
80286→80386
の時と同じように、intelは散々に叩かれただろうな。

0840デフォルトの名無しさん

2011/01/29(土) 19:18:25

Yamhill拡張よりはamd64拡張の方がよかったとおもうけどね。
レジスタ増やしたし。

0841デフォルトの名無しさん

2011/01/29(土) 19:49:25

IA-64がなければ、Yamhillもなかった・・・また違った64bit拡張になったと思うよ。

0842デフォルトの名無しさん

2011/01/29(土) 22:07:02

AMDがやることは良いこと
Intelがやることは悪いことですから

0843デフォルトの名無しさん

2011/01/30(日) 00:05:56

IA64が売れていたらYamhillはなかった。だろ。

0844デフォルトの名無しさん

2011/01/30(日) 00:14:11

IA64がなかったら・・・・Yamhillとは違う64bit拡張
IA64が売れていたら・・・・Yamhillは出番なし
IA64が売れなかった・・・・簡易64bit拡張のYamhillが作られたが、お蔵入りさせてAMD64を採用

0845デフォルトの名無しさん

2011/01/31(月) 19:10:07

Optimization manuals更新
http://www.agner.org/optimize/
Sandy Bridgeの情報が追加されたようだ

Intel(R) 64 and IA-32 Architectures Optimization Reference Manual
http://www.intel.com/Assets/PDF/manual/248966.pdf
248966-023から248966-023aの変更点がわからない

0846デフォルトの名無しさん

2011/02/08(火) 08:33:22

メモリのゼロフィルに要する時間が気になる。

ゼロフィルするときの動作って、もしかして、

1、あるメモリへの書き込みがキューに入り、キャッシュに送られる
2、キャッシュはキャッシュライン分をDRAMから読む
3、キャッシュライン上で、1の書き込みの処理を行う
4、キャッシュからDRAMに書き込みが行われる

といった具合になっていて、
キャッシュラインが全て塗りつぶされるような場合でも、
DRAMからの読み込みが発生してしまう、ってことなの?

0847デフォルトの名無しさん

2011/02/08(火) 08:59:32

メモリの一部に書き込むと言うことは、その周辺もまとめて書き込まないといけないからどうしても読み込みが発生するのでは?
Intelの講習会ではそう言ってたと思った。

0848デフォルトの名無しさん

2011/02/08(火) 09:31:00

部分的に書き込むときは、読んで・変更して・書き込む、っていう動作になるのは仕方ないにしても、
キャッシュライン丸ごと全部が書き換わるときには、読む必要ないと思うんだけど、読んでるクサイのよね。

0849 ◆0uxK91AxII

2011/02/08(火) 13:07:30

嫌ならmovnt*を使えばっていう。

0850デフォルトの名無しさん

2011/02/08(火) 16:19:42

movnt*は、
キャッシュから優先的に追い出して構わないというヒント
ではなく、
キャッシュラインと同じサイズのコンバイン用のバッファを介して、ライトスルーでメモリに書き込め
っていう命令なのね。

キャッシュラインの境界に合わせてシーケンシャルに書き込めば、
メモリへの書き込みはキャッシュラインのサイズでのバースト・ライトになる、と。

0851デフォルトの名無しさん

2011/02/08(火) 16:26:35

んーでも、NTでmovしても、readに対してwriteは8割程度の速度しか出ないんだよなー。

0852デフォルトの名無しさん

2011/02/11(金) 16:19:28

>>24
コンパイラにマルチスレッドの指定はないの？

0853デフォルトの名無しさん

2011/02/11(金) 20:18:43

>>24 のような、
最適化によって実行時間のオーダーが変わってしまうような記述は
現代でも避けるべき。

0854デフォルトの名無しさん

2011/02/11(金) 20:26:24

クリティカルではないコードでは無問題。
このスレの人は古すぎる。

0855デフォルトの名無しさん

2011/02/11(金) 20:58:17

個人でのプログラムでクリティカルでないことがあらかじめわかってるなら
良いんじゃない？

集団でのプログラム、業務でのプログラムなら、
クリティカルにならなくても避けるべき。
そういうコードが残ってると後々悪さをするんだよ。
想定外のところからのコール、移植、ソースの流用、.....などなどで。

計算オーダーの違いは明らかで、
コード量はほぼ同じ。
見やすさもほとんど変わらず。
あえて >>24 のように書く意味がない。

0856デフォルトの名無しさん

2011/02/11(金) 21:06:11

メンテナンスを想定していて、
現状のコードで問題ない部分は修正すべきではないよ。
修正するなら関係者の合意をとってからにすべきだし、
修正したコードの有益性を明確に説明すべき。
勝手に直すのは論外。
オタクプログラマが嫌われる理由を作らないようにしましょう。

0857デフォルトの名無しさん

2011/02/11(金) 21:24:46

新規でそういうコードを作るなって話だよ

0858デフォルトの名無しさん

2011/02/11(金) 22:24:54

strlenしている先がvolatileなポインタだったら、動き変わるからなぁ。
あえて>>24のような書き方をしている可能性もある。

0859デフォルトの名無しさん

2011/02/11(金) 22:40:44

volatileがついてないタダのキャラポじゃんか。
constもなぜかついてないが。
そんなこと言い出したら
strlenが標準ライブラリじゃなく全然関係ない関数かもしれない
とかそういう心配も

0860デフォルトの名無しさん

2011/02/12(土) 01:10:57

#include してないしな。

0861デフォルトの名無しさん

2011/02/12(土) 10:30:13

>>852
あんなコードをマルチスレッド化だと? アホか。

>>856
オーダー違いは、けっこうヤバいんだぜ。

>>858
触っている最中に中身が変更されるような作りは、かなり危険。

0862デフォルトの名無しさん

2011/02/12(土) 10:39:31

いまどきこんなんでやばくなる全体の設計の悪さなんとかしろよw

0863デフォルトの名無しさん

2011/02/12(土) 22:37:04

>>862
2万文字あったら2億回ヌル文字比較が行われるんだぞ
全体の設計の悪さとかじゃない
単純にこの関数の設計が悪い

0864デフォルトの名無しさん

2011/02/12(土) 22:39:13

こういうコードを書くヤツや
こういうコードを肯定するヤツ
と一緒に仕事したくない

086524

2011/02/12(土) 23:06:04

まさか二年以上も経ってから突き回される事になるとは思わなかったｗ
単に、x64の方だけ空気読んでいて興味深いなあ位の意味しかなかったのになあ。
処理内容も、ループ自体が最適化で省略されないようにしたかっただけだし。

0866デフォルトの名無しさん

2011/02/12(土) 23:31:52

オーダー違うって言ってるやついるけど、
オーダーは同じだよ。
どのみちbufの長さに対して2乗のループだからな。

0867デフォルトの名無しさん

2011/02/12(土) 23:33:08

>>263
何らかの処理の部分も2億回になるから、遅けりゃわかる。

0868デフォルトの名無しさん

2011/02/13(日) 00:39:17

>>16
のコードを見て実害出るほどに速度差が容易にでると思えるやつはまだまだ素人。

0869デフォルトの名無しさん

2011/02/13(日) 01:21:40

strlen(buf) があると最適化出来ないんじゃないの?

0870デフォルトの名無しさん

2011/02/13(日) 01:40:57

インライン展開できるのにそれを最適化できないっていうのは少し悲しい

0871デフォルトの名無しさん

2011/02/13(日) 02:19:01

>>852-870
スレ違い

0872デフォルトの名無しさん

2011/02/13(日) 02:20:49

多少マナーのあるひとなら
こう書くでしょ

for (int i=strlen(buf1); --i >= 0; ) {
  for (int j=strlen(buf2); --j >= 0; ) {
    何かの処理
  }
}

0873デフォルトの名無しさん

2011/02/13(日) 09:56:44

>>16と>>872を
ベースにしたコードで、
最適化コンパイラを通し、
比較的最近のPCで10秒以上差がつくコードを示せ。

0874デフォルトの名無しさん

2011/02/13(日) 10:38:13

>>872はある種のジョークなんだろ。
全くおもしろくはないが

0875デフォルトの名無しさん

2011/02/13(日) 10:41:10

>>873
10秒の差がつかないといけない理由は？

0876デフォルトの名無しさん

2011/02/13(日) 10:50:13

>>865
x86とx64で生成するコードが違うのは、バグの互換性のためだと思う。

>>866
strlenを毎回やると、ループが3重になるからO(N^3)
strlenを最初だけにすると、ループは2重になるからO(N^2)
オーダー、違いますね。

0877デフォルトの名無しさん

2011/02/13(日) 10:50:36

>>873
Visual Studio 2010 Win32 Releaseのデフォルト設定
CPU core i7 2600

buf1, buf2 とも10000文字の文字列
「何らかの処理」の部分は >>24 と同等

>>16 のまま
389.8秒

strlenをループの外に
0.028秒

0878デフォルトの名無しさん

2011/02/13(日) 10:52:44

>>873みたく、10秒位差がでない限り気にしない人ばかりなら
色々楽だろうなあ、と思った。

0879デフォルトの名無しさん

2011/02/13(日) 10:54:44

>CPU core i7 2600
うわ・・・厨房臭い・・・。

0880デフォルトの名無しさん

2011/02/13(日) 11:11:13

>>879
ツッコミ入れるポイントにセンスがないな、お前。

俺が仕事で書くコードでは、C++で文字列クラスを使うので、strlenを毎回呼ぶようなことにはならない。
それは遅いからではなく、strlenを使うような書き方をしてたらミスが怖いので、やらない。

速度の話だと、毎回strlenを呼ぶような遅いコードを書くのは全然OKというよりも、むしろ推奨。
最初から最短コース的な速度だと、
営業からは、安い1ソケットのサーバで済むのは儲からない、などと嫌味を言われるし、
様々な変更や改修で遅くなっていくとマズい。
だから、簡単に直せる遅いコードを散りばめておいて、必要に応じて速いコードに直すのがいい。

0881デフォルトの名無しさん

2011/02/13(日) 11:15:17

>>880
お前のところには死んでも発注したくない

0882デフォルトの名無しさん

2011/02/13(日) 11:39:06

いや、>>880は正論だろ。
プロとしてもコードオタとしても正しいギミックだよ。
最速のコードは趣味で楽しんどけ。

0883デフォルトの名無しさん

2011/02/13(日) 11:40:25

アホな命令がくるときに備えて、
いざというときに逃げられるギミックを仕込んでおくのは
プロの常識。

0884デフォルトの名無しさん

2011/02/13(日) 11:45:55

ギミックw

0885デフォルトの名無しさん

2011/02/13(日) 11:50:34

>>876
事実だとすると、過去の資産引きずるってのは、
実は命令セットの設計の新旧よりも、コンパイラの最適化と既存資産の互換性の
問題の方が大きそうだね。

0886デフォルトの名無しさん

2011/02/13(日) 13:42:11

>>877

Visual Studio ってやつは strlen が pure 関数になってないのか。

0887デフォルトの名無しさん

2011/02/13(日) 14:20:26

同じ値の引数でも、中身が変ってるかもしれんだろ。

0888デフォルトの名無しさん

2011/02/14(月) 01:05:06

strlenがただのライブラリ内の一関数という扱いであれば
コンパイラがpure関数かどうか知るすべがない。
strlenに対してコンパイラが特別扱いしていれば
最適化されるかも知れないが、
特別扱いするほど良く使われる関数でもない。

0889デフォルトの名無しさん

2011/02/14(月) 01:08:30

>>883
最適化でどうとでも変わってしまうギミックなんかにしないで
どうせ意図的に入れるとしたらもうちょっとマシなギミックにしとけ

0890デフォルトの名無しさん

2011/02/14(月) 01:11:06

pure関数って何?
内部に状態を持たず、引数に対して一意の返り値を返す関数?

だとしたら、strlenはpure関数になるわけがない。

たとえば
n1a = strlen(buf1);
strcpy(buf1, buf2);
n1b = strlen(buf1);

どちらのstrlenもbuf1という同じ値を引数にしているが、返り値の値は同じとは限らない。

0891 ◆0uxK91AxII

2011/02/14(月) 08:07:31

スレ違いな上に阿呆がpopしまくっていて酷いね。

0892デフォルトの名無しさん

2011/02/14(月) 12:45:12

volatileへのポインターでなければ、
ポインターの示す先が変わっていないと判断したときは、
勝手にstrlenの結果をキャッシュしても規格上は問題無いと思う。

規格と実装を混同してないか?

0893デフォルトの名無しさん

2011/02/14(月) 13:25:30

おまえらコンパイラ最適化の井戸端会議はどうでもいいので所要クロック(笑)でも数えててください(笑)

0894,,・´∀｀・,,）っ-○○○

2011/02/14(月) 19:47:27

strlenをSSE2でチューンしたコードならあるけどｗｗｗｗ
もちろんCじゃあれなんでフルアセンブラで書き直した。

てかさx86-Win32のABIってなんで__fastcallデフォルトにしなかったんだろうって思ったよ。

0895デフォルトの名無しさん

2011/02/14(月) 20:11:01

>>894
デバッグのため、かもね。
引数がスタックに積まれているから、drwtsn32がダンプしたログを見ると、どういう引数で呼ばれたのか分かるし。

0896デフォルトの名無しさん

2011/02/14(月) 20:20:56

>>894
ABI 設計当時は、fastcall でないオブジェクトファイルの再利用がちょくちょくあったのかな？
それとも単純に、register pressure の考慮をしたのかな？

0897デフォルトの名無しさん

2011/02/14(月) 20:25:17

VisualBasicへの配慮だったりして

0898,,・´∀｀・,,）っ-○○○

2011/02/14(月) 20:35:27

eax, ecx, edxはどのみちcaller-saveなんだからレジスタ渡しにしてくれたほうがいいんだけどね
10文字以内の文字列で自作strlenを使うとfastcall版とcdecl版でかなり性能が変わってるんで
これはどうしたものかと。

0899デフォルトの名無しさん

2011/02/14(月) 21:14:09

独禁法に違反する恐れがあった、というのは考えすぎかｗ
fastcall、というかレジスタ経由の呼び出しは、
元々コンパイラ依存で各社好き勝手やっていたから、
仕様の決め方によっては他社への嫌がらせと取られかねない、とか。

0900デフォルトの名無しさん

2011/02/14(月) 21:20:49

>>898
わざと性能落として、より高い CPU 買わせようっていう
wintel の謀略だったのかもね。

> これはどうしたものかと。
だんごさんのスーパーなライブラリでもかまして、なんとかしのいでくださいｗｗｗ

0901デフォルトの名無しさん

2011/02/14(月) 21:21:21

8085(Z80)からの移植性を考慮して、だと思うが。

0902デフォルトの名無しさん

2011/02/14(月) 21:50:48

>>892
>>888

0903デフォルトの名無しさん

2011/02/14(月) 22:06:54

呼び出し規約なんて、関数単位で選べるんだから、選べばいいじゃん。

0904 ◆0uxK91AxII

2011/02/14(月) 22:07:42

歴史的にお約束のsyscallに合わせたからとか。

0905デフォルトの名無しさん

2011/02/14(月) 22:54:12

64bitだと過去に縛られないからレジスタ渡しだね。
レジスタが多いからってのもあるだろうけど。

0906デフォルトの名無しさん

2011/02/14(月) 22:57:13

VS2010 の浮動小数点の関数を見たら、
コールのたびにSSE2対応かどうかの判断をして呼び分けてた。
sinとかx87 1命令で出来る関数でも、本当にSSE2の方が速いんだろうか.....

0907デフォルトの名無しさん

2011/02/14(月) 23:14:21

>>906
前にどこかのスレで見たんだがSSE2で展開した方が速い場合がある
精度が64bitでいいからだろうね

0908デフォルトの名無しさん

2011/02/14(月) 23:39:37

>>906
デバッグ用ビルドではランタイムライブラリが使われるが、
リリース用ビルドでは組込関数が使われる、
だったりして。

0909デフォルトの名無しさん

2011/02/14(月) 23:43:01

>>907
x87FPUは、レジスタがスタックだし、例外とかの処理の都合上、スーパースカラーやパイプライン実行に向いてないのよ。
SSE2は、その2つのハンデを負ってないので、それだけで高速。

昔はx87FPUの例外処理を端折ることで高速化したサードパーティのFPUとか、あったんだよー。

0910デフォルトの名無しさん

2011/02/15(火) 00:09:07

試しにsin 100000000回で実験したら
xmmが有利な64bitでも
x87の方が倍くらい速かった。

>>909
x87の方は実行時間のほとんどがfsinなので、
スーパースカラーやパイプラインは関係ないかと。

0911デフォルトの名無しさん

2011/02/15(火) 00:12:16

ちなみに、x87を使ったコードは以下
昔の32bitコンパイラならインラインでそのままfsinが使われてたはず

sin_x87 proc
movlpd qword ptr data, xmm0
fld qword ptr data
fsin
fstp qword ptr data
movlpd xmm0, qword ptr data0
ret
sin_x87 endp

0912デフォルトの名無しさん

2011/02/15(火) 00:14:12

Core i7で地味にFPUも改良してる可能性はあるな

0913デフォルトの名無しさん

2011/02/15(火) 00:49:44

あ、ごめんなさい。逆だった。
xmmの方が倍くらい速い。
の間違いでした。
失礼しました。

fsinとかって本当互換性のためだけについてるって感じですかね。

0914デフォルトの名無しさん

2011/02/15(火) 01:19:27

VC++2008 Express EditionとNorthwood、Clarkdaleで試してみた

/fp:fast
/arch:SSE2ではcall ___libm_sse2_sin
/arch無しではcall _sin
SSE2は75%の時間で終了

/fp:precise
/arch:SSE2ではcall __CIsin
/arch無しではcall _sin
速度差ほとんど無し

そっか、いまどきのCPUだと倍も違うのか。

0915デフォルトの名無しさん

2011/02/15(火) 01:45:54

たびたびすまん。
値によってはやっぱりx86の方が倍速いみたい。

SSE2だと条件分岐が多いんで、
いろんな値でsinを行うと分岐予測が外れて遅くなる。

逆にほとんど同じ値ばかりだとSSE2の方が倍速い。

0916デフォルトの名無しさん

2011/02/15(火) 10:01:13

sse2なら、ベクタ化コードとも共存できるね

0917デフォルトの名無しさん

2011/02/15(火) 18:25:25

>>916
テーブルを使ってるみたいだから
同じ速さでのベクタ化は難しそう。

0918デフォルトの名無しさん

2011/02/15(火) 21:44:54

速さじゃなく結果の精度に一貫性持たせる為だと思うよ

0919デフォルトの名無しさん

2011/02/15(火) 21:58:57

結果の一貫性が必要な用途なんてネットゲーくらいしか無いのに...
ほとんどの用途では速度と精度の方が重要だろうに。

この先もっと速い命令や速いアルゴリズムが出ても
一貫性の為に同じ方法を維持する？
そんな.....

0920デフォルトの名無しさん

2011/02/15(火) 22:06:25

VS2010は持ってないけど、VS2010のSSE2 sinってそんなに遅いのか？
インテルコンパイラだとSSE2 sinがx87 fsinに負けることなんてまずないけどな。
例えば次のようなコードだとSSE2 sinの方がx87 fsinより40%速い。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((rand()-RAND_MAX/2)/10.0);
ループが自動ベクトル化されていないことも確認した。

0921デフォルトの名無しさん

2011/02/15(火) 22:17:55

一貫性の為ならx87とSSE2を実行時に使い分けるなんてことはしないはず

0922デフォルトの名無しさん

2011/02/15(火) 22:37:01

VS2010 Release デフォルト設定
コードは>>920

○ SSE2を用いたsin
x86 3.66秒
x64 3.95秒
※標準ライブラリのsin使用
※実行時にSSE2とx87を使い分けているようなのでオーバーヘッドがある

○ x87のfsin使用
x86 5.69秒
x64 4.96秒
※アセンブラ記述の関数をコール

普通の値ならSSE2の方が速い

0923デフォルトの名無しさん

2011/02/15(火) 22:37:02

___libm_sse2_sinのコードを見たが、ほぼ分岐なしで一本道。
しかし、レジスタの依存関係があるので、あまり速くなさそう。
SIMDしないのはモッタイナイし、ソフトウェア・パイプライニングで2セット同時に計算したほうが良さそう。

0924デフォルトの名無しさん

2011/02/15(火) 22:42:12

>>923
VS2010のはテーブルを使ってるけど、
インテルコンパイラでは使ってない？

一周(2π)を64分割した点からの角度差を求め、
そのsin, cosを求めてから、
64点の値と加法定理を用いて結果を出してる模様。
64点の値にテーブルを用いている。
その過程でSSE2による2セットの演算を多様している。

0925デフォルトの名無しさん

2011/02/15(火) 23:07:12

角度が近ければベクタ化できるけど、
ぜんぜん関係のない複数の角度のsinを求めるのだと
条件分岐やテーブルを使わなきゃならないんで
ベクタ化は難しいと思う。

0926デフォルトの名無しさん

2011/02/15(火) 23:15:47

>>924
いや俺が見てる___libm_sse2_sinはVC++2008EEの。
テーブルも使っているし、半分くらいは*pd な演算だが、半分くらいは*sdな演算だったよ。

0927デフォルトの名無しさん

2011/02/15(火) 23:18:29

>>925
条件分岐は1回、それも特殊な値の場合の処理だけだし、
テーブル参照の部分だけ別に分けてやればいいと思う。

0928デフォルトの名無しさん

2011/02/15(火) 23:19:12

良く見たら >>920 のコードはひどいな。
除算は結構時間がかかるんだぞ。
sinに比べて短いとはいえ、無視できる時間でも無い。

0929デフォルトの名無しさん

2011/02/15(火) 23:24:19

>>927
32bitを見てる？64bitを見てる？
VS2010だと32bitと64bitで全然コードが違った。
>>924の処理は32bitの方。
64bitの処理はまだ詳しく見てない。

0930920

2011/02/15(火) 23:28:47

>>922
VS2010でもSSE2の方が速いじゃん。
x87 fsinの方が速いのってどんな場合？？と思ったら、
こういう引数がでかい場合か。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((rand()-RAND_MAX/2)*1e10);
この場合なら確かにSSE2はx87 fsinより倍以上遅い。

>>924
インテルコンパイラでも64分割してテーブル引いてる。

0931927

2011/02/15(火) 23:35:30

>>929
32bit

__libm_sse2_sin:
00401234 pextrw eax,xmm0,3
00401239 and ax,7FFFh
0040123D sub ax,3030h
00401241 cmp ax,10C5h
00401245 ja special (401381h)
0040124B movsd xmm1,mmword ptr [PI32INV (40EA20h)]
00401253 mulsd xmm1,xmm0
00401257 movsd xmm2,mmword ptr [SHIFTER (40EA28h)]
0040125F cvtsd2si edx,xmm1
00401263 addsd xmm1,xmm2
00401267 movsd xmm3,mmword ptr [P_1 (40EA10h)]
0040126F subsd xmm1,xmm2
00401273 movapd xmm2,xmmword ptr [P_2 (40EA00h)]
0040127B mulsd xmm3,xmm1
0040127F unpcklpd xmm1,xmm1
00401283 add edx,1C7600h
00401289 movsd xmm4,xmm0
0040128D and edx,3Fh
00401290 movapd xmm5,xmmword ptr [SC_4 (40E9F0h)]
00401298 lea eax,[Ctable (40E1C0h)]
0040129E shl edx,5
004012A1 add eax,edx
004012A3 mulpd xmm2,xmm1
004012A7 subsd xmm0,xmm3
004012AB mulsd xmm1,mmword ptr [P_3 (40EA18h)]
004012B3 subsd xmm4,xmm3

0932デフォルトの名無しさん

2011/02/15(火) 23:35:36

>>927
> テーブル参照の部分だけ別に分けてやればいいと思う。
そうだね。

>>930
そうそう。
私はこんな感じのコードでやった。
double sum=0.0; srand(1);
for(int i=0;i<100000000;i++) sum+=sin((double)i);

実際に良く使うのは±2πの範囲だと思うので、
通常はSSE2の方が速い。

-----
sinとcosを同時に求める必要があるなら、
セットで求めるのが効率的だね。
共通の処理がすごく多いから。
x87にもfsincosとかいうのがあったような気がする。

0933デフォルトの名無しさん

2011/02/15(火) 23:38:03

004012B7 movsd xmm7,mmword ptr [eax+8]
004012BC unpcklpd xmm0,xmm0
004012C0 movsd xmm3,xmm4
004012C4 subsd xmm4,xmm2
004012C8 mulpd xmm5,xmm0
004012CC subpd xmm0,xmm2
004012D0 movapd xmm6,xmmword ptr [SC_2 (40E9D0h)]
004012D8 mulsd xmm7,xmm4
004012DC subsd xmm3,xmm4
004012E0 mulpd xmm5,xmm0
004012E4 mulpd xmm0,xmm0
004012E8 subsd xmm3,xmm2
004012EC movapd xmm2,xmmword ptr [eax]
004012F0 subsd xmm1,xmm3
004012F4 movsd xmm3,mmword ptr [eax+18h]
004012F9 addsd xmm2,xmm3
004012FD subsd xmm7,xmm2
00401301 mulsd xmm2,xmm4
00401305 mulpd xmm6,xmm0
00401309 mulsd xmm3,xmm4
0040130D mulpd xmm2,xmm0
00401311 mulpd xmm0,xmm0

0934デフォルトの名無しさん

2011/02/15(火) 23:39:56

00401315 addpd xmm5,xmmword ptr [SC_3 (40E9E0h)]
0040131D mulsd xmm4,mmword ptr [eax]
00401321 addpd xmm6,xmmword ptr [SC_1 (40E9C0h)]
00401329 mulpd xmm5,xmm0
0040132D movsd xmm0,xmm3
00401331 addsd xmm3,mmword ptr [eax+8]
00401336 mulpd xmm1,xmm7
0040133A movsd xmm7,xmm4
0040133E addsd xmm4,xmm3
00401342 addpd xmm6,xmm5
00401346 movsd xmm5,mmword ptr [eax+8]
0040134B subsd xmm5,xmm3
0040134F subsd xmm3,xmm4
00401353 addsd xmm1,mmword ptr [eax+10h]
00401358 mulpd xmm6,xmm2
0040135C addsd xmm5,xmm0
00401360 addsd xmm3,xmm7
00401364 addsd xmm1,xmm5
00401368 addsd xmm1,xmm3
0040136C addsd xmm1,xmm6
00401370 unpckhpd xmm6,xmm6
00401374 addsd xmm1,xmm6
00401378 addsd xmm4,xmm1
0040137C movapd xmm0,xmm4
00401380 ret

こんな感じ。

0935デフォルトの名無しさん

2011/02/15(火) 23:44:48

>>931
ごめん。間に割り込んじゃった。

中心部分は2010の32bitと同じみたい。
2010だとその前にCPUによる分岐や、stからxmm0へのコピーなんかの処理がある。

00401283 add edx,1C7600h
これの意味がどうしてもわからないんだけど、
わかります？
なくても何も変わらないと思うんだけど......

0936デフォルトの名無しさん

2011/02/15(火) 23:57:37

>>935
デッドコピー対策かもね。

その1行があれば、
誰が書いても同じコードになるんじゃ!
って言い訳ができなくなるから。

0937デフォルトの名無しさん

2011/02/16(水) 00:04:08

そういうことか
他の関数でも探してみようかな

0938デフォルトの名無しさん

2011/02/16(水) 05:50:51

codepadとか使おうyo

0939デフォルトの名無しさん

2011/02/16(水) 13:07:38

そうそう。あとできればThis code is public domain.ってコメントに入れてくれると嬉しい。

0940デフォルトの名無しさん

2011/02/16(水) 13:22:00

つまらない釣りは辞めろ

0941デフォルトの名無しさん

2011/02/17(木) 02:23:26

>589
2スレッドだけど、クロック単位でスレッドを切り替えてるだけだから1スレッドあたりのIPCは...

0942デフォルトの名無しさん

2011/02/17(木) 19:32:47

クロック単位でスレッドを切り換えるだけでも、実効IPCは改善しますぜ。

0943デフォルトの名無しさん

2011/02/17(木) 20:33:25

>>919
お前ってアホだね

0944デフォルトの名無しさん

2011/02/17(木) 22:40:23

どうしたとつぜん

0945デフォルトの名無しさん

2011/03/03(木) 21:40:49.98

面白そうなページ見つけたんで張っておきますね
既出かな

Software optimization resources

ttp://www.agner.org/optimize/#manuals

0946デフォルトの名無しさん

2011/03/03(木) 21:57:03.56

>>945
既出過ぎる
俺ここの和訳手伝った事あるわ

0947デフォルトの名無しさん

2011/03/03(木) 21:59:51.36

>>945
激しく
既出だぞ

0948デフォルトの名無しさん

2011/03/03(木) 22:06:50.35

和訳ってあるの？

0949デフォルトの名無しさん

2011/03/03(木) 22:11:59.02

この内容をふつうに理解しているレベルになると、
この程度の英語くらい普通に読めるから訳なんていらない。

0950デフォルトの名無しさん

2011/03/03(木) 23:03:45.56

テンプレェ・・・

0951デフォルトの名無しさん

2011/03/04(金) 02:09:10.18

>>948
PDF化する前はあった
今はもうサイトごとないと思う

0952デフォルトの名無しさん

2011/03/04(金) 04:54:58.57

再配布禁止でなけりゃちとうｐしてもらえんだろか？

0953デフォルトの名無しさん

2011/03/04(金) 07:13:31.43

そこのnano　CPUID偽装ネタおもしろいな

0954,,・´∀｀・,,）っ-○○○

2011/03/04(金) 16:57:46.17

和訳ってソニーCSLの中の人か

0955デフォルトの名無しさん

2011/03/05(土) 13:23:29.70

>838
またそれに何年かかかって～、下手すりゃ先に実装されて～、とAMD的に美味しい展開にはならないと思われ。
ましちゃIntelはx64に乗り気じゃなかったわけだし。

0956デフォルトの名無しさん

2011/03/05(土) 14:07:32.02

Intelにすりゃ「AMDにやられた～」って感じなのかな

0957デフォルトの名無しさん

2011/03/05(土) 16:28:52.02

むしろMSにやられた。だろ。

0958,,・´∀｀・,,）っ-○○○

2011/03/05(土) 22:38:17.49

浮動小数点演算命令はAMDオリジナルプランは破棄されてIntel SSE*互換だしね。
実質「MS64」だよ

0959デフォルトの名無しさん

2011/03/05(土) 23:10:21.88

やっぱり普通の整数命令がマズイよな x86, x64は。

0960デフォルトの名無しさん

2011/03/06(日) 01:13:12.26

AVXで整理したといってもAVXを使わない粒度の細かい命令はそのまま残るわけで

0961 ◆0uxK91AxII

2011/03/06(日) 13:09:26.41

AVXとは何だったのか。

0962デフォルトの名無しさん

2011/03/08(火) 16:13:29.36

命令(およびprefix)の前に、
prefix長と命令長を示す1バイトを付ける
っていうのは、割りに合わないっていう判断がされたのかな。

0963デフォルトの名無しさん

2011/03/10(木) 17:52:04.28

AMDはL1I$上でマーカー付けてる。
下手にISAをいじるよりも良いという判断なのだろう。

0964,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/03/11(金) 14:29:39.13

Pentium 4はトレースキャッシュミスしてL2からのフェッチになると1クロック1命令までスループットが低下したけど
AMDの場合もL1Iキャッシュミスをすればプリデコーダの性能がボトルネックになる。

命令ストリーム＋プリデコードタグで1サイクルに400bit以上もフェッチするくらいなら
全部デコード済みのキャッシュをL1Iとは別に持ったほうがましじゃね？
・・・と思ったらSandy Bridgeがそれをやった。

0965デフォルトの名無しさん

2011/03/14(月) 00:37:40.36

思うだけじゃ駄目で、使えるトランジスタ数等を考えた定量的な解析が必要だろう

0966デフォルトの名無しさん

2011/03/14(月) 01:12:27.42

ここは計測スレ

0967デフォルトの名無しさん

2011/03/14(月) 16:52:23.37

Itaniumもらったんだが、どうやって計測するん?
RDTSCなんて命令ないぞ?

0968デフォルトの名無しさん

2011/03/14(月) 19:32:31.99

AR44レジスタを見るらしいよ。
レジスタの仕様自体はよく知らないけど。

0969デフォルトの名無しさん

2011/03/14(月) 22:21:58.71

スレタイ見ろよこの糞虫どもが。

0970デフォルトの名無しさん

2011/03/15(火) 20:06:21.27

>>968
サンクス・・・レジスタ読むまでの道のりは長そうだ。

0971デフォルトの名無しさん

2011/03/25(金) 23:39:40.29

今回の災害にまつわる節電のため、Itaniumは電源を入れられなくなりました
エアコンよりも電気食うって、どういうことよ

0972デフォルトの名無しさん

2011/04/07(木) 21:38:03.74

Software Optimization Guide for AMD Family 15h Processors
http://support.amd.com/us/Processor_TechDocs/47414.pdf

0973,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/07(木) 23:21:37.04

FP/SIMDのポート配分がかなり嫌だな。
使いこなせる変態いたらまじで尊敬するわ。

0974デフォルトの名無しさん

2011/04/08(金) 00:13:39.28

>>973
いるじゃん。ここに一人。そんｋ

0975デフォルトの名無しさん

2011/04/08(金) 00:23:14.37

既定に餌を与える奴は既定

0976,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 00:43:28.63

何が嫌かって、簡単にいうと、行列積演算でかなり使えそうな、それこそIntelのAVXオリジナルよりリッチな
シャッフル・転置命令が実装されてるけど、FMACをフルに使う場合はその命令は使うなという、罰ゲーム仕様です。

なぜならFMACの1つとXBARユニットがPort1を共有してるから。
Port2, Port3側で実行できるPack/Unpack命令複数で代用してうまくポート競合を回避してくださいってこと。

この点に関してはSandy Bridgeのポート構成の美点を再確認できました。

0977デフォルトの名無しさん

2011/04/08(金) 00:49:21.44

Pack/UnpackもXBARだけじゃね？

0978,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 00:54:34.17

よくみたらそうだった。
なんでこのマニュアルのサンプルVPERMIL2PS使えば命令数減らせるものをUNPACKとかDUPとか使ってるんだろ？

0979,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 01:04:14.99

いや、そんなに減らないわ。失礼。

0980デフォルトの名無しさん

2011/04/08(金) 01:38:34.38

遅くなる理由は異なれ、初期実装においてリッチなのが遅いのはIntelだってSSEの頃からそうだったろ。
初期実装は動く事が大事、まずは周知っていう発想は正直やめてほしいけど。

後から速くなるも知れないから、とかいう理由で今からわざわざ遅くなる選択をするかってのな。
速くなったら速くなったで新旧用にバイナリ2つ用意しなきゃならないし。

0981デフォルトの名無しさん

2011/04/08(金) 01:52:18.91

連投失礼。

どうせ動くの最優先にするなら、多少無理してでも豊富な命令を用意して、かつ固定しておいてほしかった。
128ビットだけでSSEからSSE4.2、しかも間にSSSE3とか変態ネーミングも絡めて6世代もバリエーションがあるのは多すぎる。

0982,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 01:58:14.01

いやべつに遅くは無いと思う。ただポート構成が悪い。

これどういう風に進化するんだろうね？
FMACの256ビット化はいうまでもないけど、Port0, Port1にもMMX_ALUを持たせて
XBARはPort2に移動かな。

最初に（V）PPERM見たときスゲー協力だと思ったけど、1個だとわかった時点で
PSHUFBを2個発行できるSandy Bridgeのほうがいいわと思いました。

というか、どのみちSandy Bridge用とBulldozer用で別々のAVXコードが必要になるよ。

0983デフォルトの名無しさん

2011/04/08(金) 02:09:18.62

>>982
どのみち別々だって分かっているなら、さらにバリエーションが増えているわけじゃないか。
事態は変わらないんじゃなくて悪化してるぜ。

0984,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 02:10:01.79

あとVPCMOVと(V)PBLENDVBがVPERM*と同じポートなのが嫌だね。
32要素を超えるテーブル参照をしたいときにスループットでないいよ。
（Altiveｃではこれに相当する命令を並列実行できました）

0985デフォルトの名無しさん

2011/04/08(金) 15:44:05.74

>>939
一目'in'が抜けてるよね?
誰も突っ込まないところみると,このスレ英語できる人いないんだろうな

0986デフォルトの名無しさん

2011/04/08(金) 16:01:26.31

なにかコンプレックスでもあるの？ｗ

0987デフォルトの名無しさん

2011/04/08(金) 16:25:24.61

This code is in the public domain.

0988,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/08(金) 17:12:48.75

この人はドイツの人っぽいけどこういう一例も
http://www.sqlite.org/cvstrac/wiki?p=SampleCode

公共物ですと言いたいならinは必要だが
いわゆるPDS（著作権を放棄したソフトウェア）ですって意味なら不要かと

0989デフォルトの名無しさん

2011/04/09(土) 01:45:08.48

>>985 はアスペ

0990デフォルトの名無しさん

2011/04/09(土) 02:52:25.02

>>985
バカだなお前。あれが未来の英語の姿だぞ？

0991,,・´∀｀・,,）＜一番良い -○○○ を頼む

2011/04/09(土) 03:42:17.06

アルファベットで書かれた言語で英語ほど文法が加減なものは無いな。

0992デフォルトの名無しさん

2011/04/09(土) 04:57:31.29

>>980
>　初期実装は動く事が大事

それが効力を発揮するのは、そのCPUが世代遅れになった時、だ。
後から速くなるかもしれないから使ってくださいではなく、
後から速くなったときに(古いCPUで動かないという理由で)使うのを躊躇させないために、あるのだと思う。

0993デフォルトの名無しさん

2011/04/09(土) 05:17:16.68

My private parts are in the public domain :D

0994デフォルトの名無しさん

2011/04/09(土) 12:19:50.18

0995デフォルトの名無しさん

2011/04/09(土) 16:12:55.30

Lvが足りなくて次スレ立てられなかった
↓たのむ

0996デフォルトの名無しさん

2011/04/09(土) 16:45:23.50

ほい
x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

0997デフォルトの名無しさん

2011/04/09(土) 17:27:51.46

>996乙

埋め立て開始

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

0998デフォルトの名無しさん

2011/04/09(土) 17:44:30.87

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

0999デフォルトの名無しさん

2011/04/09(土) 17:52:08.33

x86命令の所要クロック計測スレPart5
http://hibari.2ch.net/test/read.cgi/tech/1302334991/

1000デフォルトの名無しさん

2011/04/09(土) 18:02:40.02

何も無理矢理埋めんでも

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。