5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん: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

2 :デフォルトの名無しさん: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


3 :デフォルトの名無しさん:2008/05/31(土) 00:44:43
以下ダンゴさんの幼稚な喚きをスルーできた奴は勝ち組
ダンゴ先生に構う者は団子



4 :デフォルトの名無しさん:2008/05/31(土) 03:28:40
テンプレに入れて欲しい
http://instlatx64.fw.hu/

5 :デフォルトの名無しさん:2008/05/31(土) 07:14:14
ダンゴ先生のおかげで次スレが立ったな。

6 :デフォルトの名無しさん: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とコンパイラなら大抵は前者が速いか、
悪くとも同等にしかならないと思っていたのだが。


7 :デフォルトの名無しさん:2008/05/31(土) 23:32:27
for (int x=0; x<count; x++) {
sum += p[x] ;
}
を書いた者です。

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

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

8 :デフォルトの名無しさん:2008/05/31(土) 23:35:09
strength reduction でググレカス

9 :デフォルトの名無しさん:2008/05/31(土) 23:43:36
その年寄りはポインタと配列が同じ物って知らないんじゃないの?

10 :デフォルトの名無しさん:2008/05/31(土) 23:48:18
最適化が期待できないコンパイラならそういう書き方を避ける。
でもここはx86関連のスレなので、最適化するコンパイラが標準的だろう。

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


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

12 :デフォルトの名無しさん:2008/06/01(日) 00:16:14
Cでstrlenをアホみたいに呼び出すコードをときどき見かけるぞ
負荷になるのか、sambaなんかだと文字列クラス相当品を用意しているがな

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

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

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

14 :デフォルトの名無しさん:2008/06/01(日) 00:34:57
>sambaなんかだと文字列クラス相当品を用意している

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

どちらが本当なの?

15 :デフォルトの名無しさん:2008/06/01(日) 00:41:26
sambaの連中が馬鹿ってことだろ。
あいつら素人だし、所詮オープンソースなんてそんなもの。
そんな有害コードは参考にするべきでない。

16 :デフォルトの名無しさん: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がついてない。やっぱり変るのか?
と思ってみても、やっぱり変らない。

もうねアホかと。

17 :デフォルトの名無しさん:2008/06/01(日) 00:47:29
いつのまにか、strlenの負荷を減らすために
sambaの文字列クラスが作られたという設定になっている件について。
表現の自由万歳だな。

18 :デフォルトの名無しさん:2008/06/01(日) 00:48:55
>>15
ちげーよ。

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

19 :デフォルトの名無しさん:2008/06/01(日) 00:52:24
>>17
文字列をコピーしたり加工したりするたびにstrlenが必要になるだろ?
あちこちで頻繁にstrlenを呼ぶので、strlenが消費するCPUサイクルは、無視できない。

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

20 :デフォルトの名無しさん:2008/06/01(日) 00:54:47
>こういうのを見ると、ループ中にbuf1やbuf2の内容が変るのか? と思う。
いいたいことはわからんでもないが、ぜんぜん思わんよ。
ループ内でbuf1, buf2の内容が変わらないのなら、
コンパイラが変数で置き換えるだろう思うし気にならん。
そういうのがいちいち気になるのは単なる世代の差
としかいいようがないな。

21 :デフォルトの名無しさん:2008/06/01(日) 01:18:41
> コンパイラが変数で置き換えるだろう思うし

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


22 :デフォルトの名無しさん:2008/06/01(日) 01:23:31
>>21
そう思うなら自分で書いてコンパイルしてみろよ。
多分、C++以降の世代だからconstの本来の意味もしらないゆとり世代なんだろうけどw

23 :デフォルトの名無しさん:2008/06/01(日) 01:29:46
subversionも文字列クラス相当品持ってますな

24 :デフォルトの名無しさん: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をターゲットにすると一度しか評価しないコードになる所が面白いな。

25 :デフォルトの名無しさん:2008/06/01(日) 01:36:11
ある程度の規模なら持たないほうが少ないんじゃないか?
>>18の意味で


26 :デフォルトの名無しさん:2008/06/01(日) 01:51:14
それみたことか
時代は64bitなんだし、>>20, >>22の正しさが証明されたな
こればかりは世代の違いとしか言いようがない

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

28 :デフォルトの名無しさん:2008/06/01(日) 02:12:17
Javaにはstrlenはない、配列も長さ固定
strlenが必要なメジャーなスクリプト言語は見たことがない>あったら教えてくれ

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

29 :デフォルトの名無しさん:2008/06/01(日) 02:12:35
>>24
> ただし、x64をターゲットにすると一度しか評価しないコードになる所が面白いな。

すごいな。

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

30 :デフォルトの名無しさん:2008/06/01(日) 02:14:55
Javaやスクリプト言語にstrlenがあるなんて書いてないだろ。
見た目が冗長になるような書き方はLight Weightな言語では
普通やらないって意味でしょ。

31 :デフォルトの名無しさん:2008/06/01(日) 02:15:09
>>29
64ビットにすることでのパフォーマンスアップを演出するために、
x86版とX64版で最適化の内容に差を付けたんだろう。

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

32 :デフォルトの名無しさん:2008/06/01(日) 02:20:18
>>30
というよりは、
コンピュータの内部アーキテクチャを知らない、処理が一瞬で終わるブラックボックスとして見る人たち
ってことだと思うよ。


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

34 :デフォルトの名無しさん:2008/06/01(日) 02:32:29
> そこらの下手なコードのアプリで一番効くのが、strlenだもの。

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

35 :デフォルトの名無しさん:2008/06/01(日) 02:34:40
プロなら、わざと遅いコードを書く。
とくに競合相手がいない場合のバージョン1.0では、できるだけ遅くしておくのがいい。

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

36 :デフォルトの名無しさん:2008/06/01(日) 02:46:41
>前999
> インデックス付き間接アドレッシングできないCPUとか
RISCをなめるなw

37 :デフォルトの名無しさん:2008/06/01(日) 03:09:44
>>33
>コンピュータの内部は多分君らより詳しいぞ。
しかし、MicroBlazeやfreeMIPSのソースを眺めたくらいじゃx86の話は出来ないぞ。

38 :デフォルトの名無しさん:2008/06/01(日) 03:24:54
C、C++の最適化について語るスレ 2
http://pc11.2ch.net/test/read.cgi/tech/1177808054/l50


39 :デフォルトの名無しさん:2008/06/01(日) 03:55:44
メインメモリを最高速で舐める方法に話を戻そうぜ。

40 :デフォルトの名無しさん:2008/06/01(日) 10:46:12
MOUDQAでFA

41 :デフォルトの名無しさん:2008/06/01(日) 12:11:01
MOVDQAはLCPついてるから一部のCPUではストール発生?


42 :デフォルトの名無しさん:2008/06/01(日) 14:49:39
>>16
コンパイラは引数のconstあり/なし両方のコードを生成するようにして使う側のコンパイル時にどっちを使うか選択すれば良いのにと言ってみるテスト。
引数多いと組み合わせ多いから大変そうだけど。

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

44 :デフォルトの名無しさん:2008/06/01(日) 16:13:46
>>43
> 例えばループの途中でスレッドが切り替わったり別のCPUによる処理でbuf1やbuf2の内容が変更される可能性は全く否定できない。
そういうのが予想される場合は volatile つけないとダメなのでは?

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

45 :42:2008/06/01(日) 16:21:07
>>43
ああ、確かに。ええとD言語のinvariant的なものならおkかな。

46 :デフォルトの名無しさん:2008/06/01(日) 16:24:32
つーか、volatileがあるからコンパイラが思い切った最適化をできるんだろ。
volatileは最適化抑制のためではなく、最適化を柔軟に行えるためにあるんだよ。
もしなかったら、コンパイラからどの変数がいつ更新されるかわからないので、
上の例だけでなく、殆どまともな最適化はできなくなる。

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

47 :デフォルトの名無しさん:2008/06/01(日) 17:57:04
あの例で呼び出しを省略するのってマズくないか?

48 :デフォルトの名無しさん:2008/06/01(日) 19:48:18
いい加減C, C++スレでやれ。

49 :デフォルトの名無しさん:2008/06/01(日) 20:44:03
>>41
LCPが付いている命令はストールするみたいな印象を与える記事が多いけど、
実際にストールするLCP付き命令は一部だけだよ。
どんな命令でストールするのかはインテルのOptimization Reference Manualに
書いてある。SSE系の命令はLCPストールは発生しない。

50 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/01(日) 21:15:24
>>12
for (int i = 0; i < s.length(); i++) {}
ってのと同じノリで終了判定にstrlenを使ったクソコードですね。わかります。

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

51 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/01(日) 21:25:47
>>41
逆だと思う。
どうやら66hプレフィックスがある場合はまずSSE2以降のSIMD命令と予測して動いてる模様。
2バイト目を見てx86命令のサイズ変更の意味だったらストール、みたいな感じかと。

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

52 :デフォルトの名無しさん:2008/06/01(日) 22:56:05
だんごさんの見事な回答で、すべての問題が解決したな

53 :デフォルトの名無しさん:2008/06/02(月) 00:27:04
LCPによるストール自体は初代P6から存在するものだよ。

54 :デフォルトの名無しさん:2008/06/03(火) 17:13:29
>>50
length() は毎回数えたりしないだろ。
strlen() の問題はコレに近い↓
http://hiropon.net/cgi-bin/sb/log/20060422164633.html

55 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/03(火) 18:31:02
いや、そういってるじゃん。
constの最適化の扱いもCとC++じゃ違うみたいだが

56 :デフォルトの名無しさん:2008/06/03(火) 18:47:01
信じられるのはだんごさんの話だけだな

57 :ヽ・´∀`・,,)っ━━━━━━┓: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かな?

58 :デフォルトの名無しさん:2008/06/03(火) 22:02:12
>>55
そもそもCとC++のconstって意味違うもん。団子らしくないな。
で、クロック計測と関係のないC, C++の話は終了。

59 :デフォルトの名無しさん:2008/06/06(金) 10:44:37
TLBミスしたときのロードのレイテンシって、測ったことある人いる?

60 :デフォルトの名無しさん: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のロス。

61 :デフォルトの名無しさん:2008/06/06(金) 23:05:30
>>60
前スレの>>1??
>>1なら>>1と名乗れよ。

62 :60:2008/06/06(金) 23:12:06
>>1ではないけど…

63 :デフォルトの名無しさん:2008/06/07(土) 00:17:13
だんごさんに比べると考察が甘いな

64 :デフォルトの名無しさん: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クロックということになりませんか?


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

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


66 :60:2008/06/07(土) 07:50:21
> 256 個 : 3.0clock( 1.0ns)
> 512 個 : 15.1clock( 4.8ns)

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

67 :デフォルトの名無しさん:2008/06/07(土) 08:07:50
L1Dキャッシュのラインのサイズは128バイトもあるのか・・・orz

68 :60:2008/06/07(土) 08:21:13
C2DのL1Dラインサイズは64バイトですが、
L2の兼ね合いもあって、128バイトごとにアクセスしています。
この計測では、キャッシュの奇数ラインにはアクセスしません。

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

70 :1 ◆.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のペナルティだった。

71 :デフォルトの名無しさん: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)

72 :デフォルトの名無しさん: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)


73 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/07(土) 13:11:43
さて、Wolfdaleは出てるからMerom機のVAIO(笑)の出番か?

74 :デフォルトの名無しさん:2008/06/07(土) 13:35:40
ちゃんとだんごさんの出番は残されていたな

75 :デフォルトの名無しさん: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コアとの比較が気になる

76 :デフォルトの名無しさん: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)


77 :デフォルトの名無しさん:2008/06/07(土) 17:56:40
Core 2 Duo E8500@4.2GHzの計測結果

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)

78 :デフォルトの名無しさん: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多くかかってる。

79 :デフォルトの名無しさん:2008/06/07(土) 19:07:00
>>78
K7はTLBがデータキャッシュを使わない仕様だったような。


80 :デフォルトの名無しさん:2008/06/07(土) 19:30:48
http://home.att.ne.jp/wave/shida/mflops3.html

81 :デフォルトの名無しさん:2008/06/07(土) 19:35:41
2chではK7を使わないのは馬鹿っていう風潮があったけど、
どーみても、P6やNetBurstのほうが設計が良く見えてしまう。

82 :ヽ・´∀`・,,)っ━━━━━━┓: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)


83 :デフォルトの名無しさん:2008/06/07(土) 20:15:52
だんごさんのおかげで完璧なデータが揃ったな

84 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/07(土) 20:23:56
Atom機が欲しいところだな。

85 :デフォルトの名無しさん: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で使ってる
結果最悪じゃね?(´・ω・`)

86 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/07(土) 20:36:59
とりあえずK8はK7に比べてダントツに良い設計なんだな。

87 :デフォルトの名無しさん:2008/06/07(土) 20:42:53
Phenomを使ってる猛者はいないかな?
俺そろそろAthlonXPやめようと思うんだけど
データが見てみたい

88 :ヽ・´∀`・,,)っ━━━━━━┓: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です。

89 :デフォルトの名無しさん: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)


90 :89: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)


91 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/07(土) 21:23:19
L1無効?

92 :デフォルトの名無しさん:2008/06/07(土) 22:17:38
K6-2なWin98機で動かそうと思ったら「メモリ不足で(ry」って言われた。
96MBしか積んでないから528MBなんて確保できんわなぁorz

93 :デフォルトの名無しさん:2008/06/07(土) 23:53:10
>>89
IA-32ELとItaniumですか?

94 :デフォルトの名無しさん:2008/06/07(土) 23:59:17
L1キャッシュなんか無効にしたらWindowsの起動に
どれだけかかるようになるかゾッとする

95 :デフォルトの名無しさん: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)

96 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/08(日) 07:21:01
なるのど>>89-90はMercedか

97 :デフォルトの名無しさん: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)


98 :デフォルトの名無しさん:2008/06/08(日) 10:24:47
またAMDはRDTSCの実装を手抜きしたのか。

99 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/08(日) 13:01:22
だな
クロックに1.2かけた値が正解だな

100 :デフォルトの名無しさん:2008/06/08(日) 13:20:00
え?
2.5GHzで起動して、動作中に3.0GHzに変更したから、>>97のような結果になるんでしょ。
TSCの周波数は動作中には変らないのが仕様であり、途中でコアのクロック変更したら
TSCとコアの周波数が一致しなくなるのは、正しい挙動だと思う。

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


101 :デフォルトの名無しさん: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


102 :デフォルトの名無しさん:2008/06/08(日) 13:39:58
実測ではDPIが8なのに、シミュレーションでは9となってる。


103 :デフォルトの名無しさん: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


104 :デフォルトの名無しさん: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

105 :デフォルトの名無しさん:2008/06/08(日) 14:22:55
>>104を見ると、K7のL2DTLBがL2D$を使わずに都度メインメモリに読みに行くってのはガセっぽいな。


106 :デフォルトの名無しさん:2008/06/08(日) 15:56:43
TLBミス5回って何やってんのかな。


107 :デフォルトの名無しさん:2008/06/08(日) 16:13:01
phenomはL3キャッシュ積んだから少しはマシになると思ってたけど
X2と大差ないじゃん
やっぱりCore2にすっかな〜悩む

108 :デフォルトの名無しさん: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)


109 :デフォルトの名無しさん:2008/06/08(日) 16:48:54
うおっ本当だゴメソ
かなり速くなるんだな

110 :デフォルトの名無しさん: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)


111 :89:2008/06/08(日) 23:00:30
すみません、遅くなりました。
>>93さんの予想どおりです。
ちゃんと最初からCPU名を書くべきでした。ごめんなさい。


112 :デフォルトの名無しさん: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)

113 :デフォルトの名無しさん: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)


114 :デフォルトの名無しさん:2008/06/10(火) 18:08:46
>>113
ほとんど変ってないように見えるけど。

115 :デフォルトの名無しさん:2008/06/10(火) 19:10:27
所要クロック数は変ってるけど、所要時間は変ってない。

116 :デフォルトの名無しさん:2008/06/10(火) 22:12:08
>>114
>>115
たしかに変わらないですね、すみません


117 :デフォルトの名無しさん: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)

118 :デフォルトの名無しさん: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)

119 :デフォルトの名無しさん:2008/06/12(木) 21:52:23
>>118
何これ馬鹿みたいに速いな

120 :デフォルトの名無しさん:2008/06/12(木) 22:50:59
そりゃ速いのが売りの超ハイエンドだもん。

121 :ヽ・´∀`・,,)っ━━━━━━┓: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)


122 :デフォルトの名無しさん:2008/06/14(土) 09:59:59
12MBもの大きさのL2キャッシュが乗ってるCPUだから、
131072個でさえも、かなりの割合でL2キャッシュにヒットしていると思う。
ソースの定数定義を書き換えてもっと大きくしてみるといいと思う。

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

123 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/14(土) 10:16:46
12MBって言っても6MB+6MBで反対側のダイのデータアクセスするのにFSBを経由するよ

124 :デフォルトの名無しさん:2008/06/14(土) 10:49:22
> FSBを経由するよ

マジ!?

125 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/14(土) 12:22:01
ん?クロスバー接続か何かだと思ったの?
Pentium Dと同じ方式でWolfdaleコアを2個積めて共有バス線に繋いだだけのもの。
反対側のL2は直接管理できないよ。

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

126 :デフォルトの名無しさん:2008/06/14(土) 12:30:44
だとすると、
反対側のダイのキャッシュにdirtyフラグが立ってるデータを
アクセスしようとしたときって、
通常メモリ読み込むのとあんまりかわらんということかな
さすがにレイテンシは違うか

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


128 :デフォルトの名無しさん:2008/06/14(土) 19:34:30
メインメモリにアクセスしに行ったときのレイテンシは、
メモリコントローラをプロセッサに直結しても50nsはかかるのだから、
FGMTをやればいいと思うんだけど、なんでAMDはやらないんだ?

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

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


129 :128:2008/06/14(土) 19:34:52
ごめん、
×FGMT
○CGMT

130 :デフォルトの名無しさん:2008/06/15(日) 01:52:27
そこまで手が回ってないのが正直なところじゃね?
K8なんか立ち上げるだけで精一杯だったろうし。
K8改のK10もチャレンジしてる余裕は無かっただろう。
Bulldozerになれば何らかのマルチスレッディングは入るのではないかと。

131 :デフォルトの名無しさん:2008/06/15(日) 01:59:57
その暁にはかつて似非デュアルだとか、疑似デュアルなどと
頑張って吹聴していた某社信者がまたもやもやするわけですね、わかります。

132 :デフォルトの名無しさん:2008/06/15(日) 19:50:45
x86はパイプラインが長くて複雑だから、
SPARCにFGMTを導入したNiagaraのようには簡単にいかないのだろう。

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

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

133 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/15(日) 20:24:14
ただでさえ製造プロセスルールと生産力で遅れを取ってるんだしAMDも何かしらIntelの先を行く要素がないとね。
Nehalemでメモコン・HyperTransportの強みすらなくなるし。

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

134 :デフォルトの名無しさん:2008/06/15(日) 21:11:13
VIA(というか、元IDTのCT)が、シングルコア、シングルスレッドのローエンドにフォーカスしているのがモッタイナイ。

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


135 :デフォルトの名無しさん:2008/06/15(日) 21:11:57
非スーパースケーラならSMTは無理でしょ

136 :デフォルトの名無しさん:2008/06/15(日) 21:45:17
>>133
SIMDはパフォーマンスに敏感な一部のコードだけの話だから、
各種CPUに合わせてチューニングした別コードを用意できるから、
次々に新命令を追加していっても構わないけど、

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

137 :1 ◆.MeromIYCE :2008/06/15(日) 22:20:02
>>134
Core2が片肺の代わりに、そういう小コアが8個載ってるとかいいね。
まあ、技術的に不可能でなくても、まだ時代が十分に進んでいないから無理かな。
動画エンコでもCore2Quadでいいだろうし、買うのは俺たちくらいだろう。

138 :デフォルトの名無しさん:2008/06/15(日) 22:35:20
>>134
そういうCPUは、膨大なメモリチャネルがないと、結局はストールするのよ。

139 :デフォルトの名無しさん: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


140 :デフォルトの名無しさん:2008/06/16(月) 04:20:02
さすが自作PC板は専門家が多いな

141 :78:2008/06/16(月) 07:24:07
ストライドを小さくしてみた

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


142 :デフォルトの名無しさん:2008/06/16(月) 15:13:13
見事に60ns・・・

143 :デフォルトの名無しさん: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の間はプリチャージとか、バンクをアクティブにするとか、そういうことをやってるのかな・・・。


144 :デフォルトの名無しさん:2008/06/17(火) 01:57:02
Athlon(K7)が、ページディスクリプタをキャッシュできない
(TLBへの読み込みのみ対応、L1・L2へは読まない)
という仕様な上に、ワンセット16バイトで充分なのを128バイト単位じゃないと読み込めない。

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

145 :デフォルトの名無しさん:2008/06/17(火) 11:19:14
K7が設計された時点の想定アプリケーションでは、
小さなTLBでも十分だったし、
データキャッシュを汚染しないことのほうが大切だったのだろう。

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

146 :デフォルトの名無しさん:2008/06/17(火) 11:21:58
複雑なストリーム検出機能を持つ代わりにバグっていて機能を止められていたP4のプリフェッチよりも、
強制的に次を読込むという単純なプリフェッチのほうが、実装が簡単でなおかつ効果的だったのだろう。

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

147 :デフォルトの名無しさん: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

148 :146:2008/06/17(火) 12:59:25
K6とK8のMSRのEFERの資料はあったが、K7はないな・・・。

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


149 :78:2008/06/18(水) 01:34:39
>>147
70ns

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

151 :150:2008/06/18(水) 22:45:26
ごめん、オオボケだ。

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

直してきます。

152 :150: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)


153 :デフォルトの名無しさん:2008/06/18(水) 23:35:57
>>141
VirtualAllocにPAGE_NOCACHEを付けて比較してみてもらえませんか?

154 :デフォルトの名無しさん:2008/06/19(木) 00:39:55
150は何を調べたいの?

155 :ヽ・´∀`・,,)っ━━━━━━┓: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)

156 :デフォルトの名無しさん: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)


157 :デフォルトの名無しさん: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)

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


158 :153:2008/06/21(土) 15:30:33
>>156
ありがとう

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

159 :デフォルトの名無しさん:2008/06/24(火) 05:19:55
いまさらK7の話なんかしてる人って、何なの?

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

160 :デフォルトの名無しさん:2008/06/24(火) 07:02:24
今日のお前がいうなスレはここですか?

161 :デフォルトの名無しさん:2008/06/24(火) 10:44:33
K6-2の結果を貼りたいけどメモリが足りなくて実行できない俺ガイル

162 :デフォルトの名無しさん:2008/06/24(火) 11:15:04
K5、K6、K6-2を持っていたが既に破棄処分にした俺がいる
K6-3を買おうと思った頃に丁度Celeron300Aが出たので
これを当然のごとく450Aにして使って超速いと感じた

以降Intelで組んできた

163 :デフォルトの名無しさん:2008/06/24(火) 12:16:29
>>161
ちょっとソースの定数を書き換えてコンパイルし直すだけだぞ。
おまえこのスレ向いてない。やめな。

164 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/24(火) 18:58:37
俺のMMX Pentiumが火を噴くときがきた?


165 :デフォルトの名無しさん:2008/06/24(火) 19:55:57
消化器準備ヨシ

166 :デフォルトの名無しさん:2008/06/24(火) 19:57:39
あんまり古いCPUは、TSCがなかったりして。

167 :デフォルトの名無しさん:2008/06/24(火) 21:56:42
>>163
ソースは読めてもソースの意図が読めない子はこのスレ向いてないよ。

168 :デフォルトの名無しさん:2008/06/25(水) 14:34:19
critical word firstって、いまどきのCPUでもやってるの?
キャッシュラインの先頭4バイトと末尾4バイトでレイテンシ同じっぽいのだが。

169 :デフォルトの名無しさん:2008/06/25(水) 21:42:31
リニアバーストじゃないとRAMが対応してないんじゃない?

170 :デフォルトの名無しさん:2008/06/25(水) 22:08:45
たとえばバースト長4のとき、
DRAMのカラム・アドレスの下位2ビットが、
00なら、0→1→2→3とアドレスが進む
11なら、3→0→1→2とアドレスが進む
のよ。

171 :デフォルトの名無しさん: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秒でした。

172 :ヽ・´∀`・,,)っ━━━━━━┓: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>

173 :デフォルトの名無しさん:2008/06/27(金) 21:35:36
ありがとう
やっぱり0.028秒って変なんですね。

174 :デフォルトの名無しさん:2008/06/28(土) 02:54:02
>>172
自作enumでインクリメントを使いたければ、operator ++を定義すればいいのさ。

175 :デフォルトの名無しさん:2008/06/28(土) 15:27:46
PPCとかCellとかだったりするのかな

176 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/28(土) 20:05:38
>>175
確かにPPCMacのVPC環境でWin32プログラム動かすと異常にスコアがいいことがあるが
(L1キャッシュのレイテンシ1clkだけは断じてない)
TSCのエミュがおかしいだけでしょ

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

177 :デフォルトの名無しさん:2008/06/28(土) 21:48:50
だんごさんのおかげでCellの欠点が明らかになったな

178 :デフォルトの名無しさん:2008/06/28(土) 22:03:43
DANGOさんがCellを語りだすととまらないな

179 :デフォルトの名無しさん:2008/06/28(土) 23:18:09
ここまで貢献してるんだから
もうダンゴさん専用スレ立てようぜ


180 :⊂二二二( ^ω^)二⊃:2008/06/29(日) 22:41:25
Atom買ってきたお
Fedoraの32か64入れるお
gccが通る.cか.sここに貼ってくれたら試すお

181 :デフォルトの名無しさん:2008/06/29(日) 22:56:41
atomってamd64対応だっけ

182 :デフォルトの名無しさん:2008/06/29(日) 23:36:49
対応してる。
230以外では殺されてるけど<EM64T

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

183 :⊂二二二( ^ω^)二⊃:2008/06/30(月) 01:08:46
BIOSセットアップの画面で
EM64T Capableとなっていたお

184 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/30(月) 16:55:22
暇があったらARM7とCell(いずれもゲーム機)で試すわ

185 :ヽ・´∀`・,,)っ━━━━━━┓:2008/06/30(月) 17:00:58
>>180
John the Ripperを32bit(SSE)と64bitでビルドしてみて

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

186 :デフォルトの名無しさん: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が加わった。

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


187 :デフォルトの名無しさん:2008/07/05(土) 07:55:49
>>187
http://www.agner.org/optimize/
じゃね?

188 :ヽ・´∀`・,,)っ━━━━━━┓:2008/07/05(土) 15:42:33
そこは前スレあたりで実機で検証済みだがAgner氏は今回ずいぶん仕事遅かったな。

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

189 :デフォルトの名無しさん: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

190 :ヽ・´∀`・,,)っ━━━━━━┓: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

191 :デフォルトの名無しさん:2008/07/07(月) 07:11:51
ぶっちゃけ
新命令は遅くてもいいから実行できることが重要、だと思う。

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


192 :ヽ・´∀`・,,)っ━━━━━━━┓:2008/07/07(月) 14:08:12
正味、65nmのCore2出たときは新命令よりは既存128ビットSIMD命令が
従来の倍速で使えるメリットのほうが大きかったし、
SSSE3自体は大々的に宣伝されたような記憶がない。

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

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

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

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

194 :ヽ・´∀`・,,)っ━━━━━━┓:2008/07/07(月) 20:32:53
> 水平加算なんか、隣との和ならシフトなりシャッフルなりして足せばいいじゃん。

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

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


195 :ヽ・´∀`・,,)っ━━━━━━┓:2008/07/07(月) 20:33:24
ごめん、shufps×2+padddです。


196 :デフォルトの名無しさん:2008/07/14(月) 19:08:45
ふと思ったんだが、
rep movsd
が遅いのはどうして?

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

197 :デフォルトの名無しさん:2008/07/14(月) 23:57:37
マイクロプログラムで動かしてるから

198 :デフォルトの名無しさん:2008/07/15(火) 00:08:06
メモリの帯域幅が6.4GB/secとしてだ、
それは、
メモリからの(キャッシュを汚染しない)でXMMレジスタに
ロード200M回/secとストア200M回/secに相当ですよ。

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

199 :デフォルトの名無しさん:2008/07/15(火) 00:12:08
マイクロコードで処理するならレジスタを介さず、
メモリからL2キャッシュにバーストでフィルして、
バーストで書き出せばいいんじゃね?

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

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

200 :デフォルトの名無しさん:2008/07/15(火) 07:44:09
そう簡単に済むのなら実装されてるだろ。
されてないってことは、済まないってことだろ。

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

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


201 :デフォルトの名無しさん:2008/07/15(火) 21:12:03
割り込みとか考えなくて良い連中はお気楽だな。

202 :デフォルトの名無しさん:2008/07/15(火) 21:16:48
割り込みが何か?

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

203 :デフォルトの名無しさん:2008/07/15(火) 21:29:23
ダメだこりゃ

204 :デフォルトの名無しさん:2008/07/15(火) 21:50:15
>>196
ecxへの影響があるから

205 :デフォルトの名無しさん:2008/07/15(火) 22:00:03
esi,ediの存在も忘れるな

206 :デフォルトの名無しさん:2008/07/15(火) 22:09:48
代替ルーチンからリターンした時に辻褄が合ってればいいんでしょ?

207 :デフォルトの名無しさん:2008/07/15(火) 22:14:51
代替ルーチンはどこに置くんだよ。SMIみたいな事する気?

208 :デフォルトの名無しさん:2008/07/15(火) 22:36:40
>>207
適当な物理アドレスに置くという約束でいいじゃないか。

209 :デフォルトの名無しさん:2008/07/15(火) 22:56:42
その適当な物理アドレスは誰が確保するの?
代替ルーチンは仮想アドレスでどうやって表現するの?
DRxはスルーされるの?
等々

もう少し考えてみたら?

210 :デフォルトの名無しさん:2008/07/15(火) 23:40:04
> その適当な物理アドレスは誰が確保するの?

OS

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

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

> DRxはスルーされるの?

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


211 :デフォルトの名無しさん:2008/07/15(火) 23:48:45
> ユーザーのコードと区別する必要はあるまい。
何を言いたいのか…

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

212 :デフォルトの名無しさん:2008/07/16(水) 00:28:26
俺はわかってるけどあえて答えないよ。

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

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

213 :デフォルトの名無しさん:2008/07/16(水) 00:37:52
実際はOSの勉強なんて必要ないはずなんだよ。

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

214 :デフォルトの名無しさん:2008/07/16(水) 00:45:18
やっぱりプロセッサを作ったことがなきゃね…

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

215 :デフォルトの名無しさん:2008/07/16(水) 01:27:33
>>205
それもあったな
それとflagもか

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

216 :デフォルトの名無しさん:2008/07/16(水) 09:39:43
OSのサポートが必要な仕組みなんだから、OSに対して透過的である必要はないだろ。

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


217 :デフォルトの名無しさん:2008/07/16(水) 13:13:01
そんなモノに価値があると思うことが足りない証拠。

218 :デフォルトの名無しさん:2008/07/16(水) 13:53:09
OSが関与していいなら、OSがバイナリを動的に書き換えたらいいんよ。

219 :デフォルトの名無しさん:2008/07/16(水) 13:57:55
特定のCPUに合わせて、
既存のバイナリの命令の並びを変えたり置き換えたりするってのは、
以前に試みているところがあったが、結局、日の目を見なかったな。

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


220 :デフォルトの名無しさん:2008/07/16(水) 14:15:25
rep movs*を特権命令にしろと?

221 :デフォルトの名無しさん:2008/07/16(水) 22:52:30
インテルのAtomのレイテンシ&スループットって、インテルからは公開されてる?

222 :デフォルトの名無しさん:2008/07/18(金) 15:42:31
そもそも rep movsd はメモリに対しては別に遅くないんだが
というより movnt 系以外はどのレジスタ使おうがどんなループの細工をしようがほぼ変わらん

223 :デフォルトの名無しさん:2008/07/18(金) 16:33:04
rep movsdとmovntdqでは倍くらい速度が違ったような。


224 :デフォルトの名無しさん:2008/07/19(土) 15:09:47
ecxがL2キャッシュサイズを越えていれば、non-temporalで扱うべきだよな。

225 :デフォルトの名無しさん:2008/07/19(土) 16:56:33
rep movsd って必ずキャッシュに乗るのか

226 :デフォルトの名無しさん:2008/07/19(土) 17:31:13
プログラムによるが、rep movsdは、
数百バイトのコピーに頻繁に使われ、
コピー元は既にキャッシュ上にあることが多く、
コピー先もすぐに使われることが多い。

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

227 :デフォルトの名無しさん:2008/07/20(日) 03:48:24
かわりにmovpdつかえないの?

228 :ヽ・´∀`・,,)っ━━━━━┓:2008/07/27(日) 15:12:05
誰か>>196からの流れを産業でヨロ


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

229 :デフォルトの名無しさん:2008/07/27(日) 16:02:52
だんご
うぜぇな
とっとと消えろ

230 :ヽ・´∀`・,,)っ━━━━━┓:2008/07/27(日) 19:12:31





231 :デフォルトの名無しさん:2008/07/28(月) 01:06:59
自分の経験の範囲だとrep movsdを生成するのは
MSのVCで、
memcpyを組込み関数として展開した場合かな。

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

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

232 :デフォルトの名無しさん:2008/07/28(月) 02:08:59
当然その分のディスクスペースっても数百KBだろうが、まあそれと
複数の環境への開発コスト、何より金のかかるテストのコストはユーザが支払ってくれるんだろうな。

233 :デフォルトの名無しさん:2008/07/28(月) 02:18:19
>>232
そのためのOSだと思うんだが。

234 :デフォルトの名無しさん:2008/07/28(月) 02:21:03
>>232
>そのためのOSだと思うんだが。

プププ

235 :デフォルトの名無しさん:2008/07/28(月) 02:33:52


236 :ヽ・´∀`・,,)っ━━━━━┓:2008/07/28(月) 06:19:26
>>VC
長さが定数で十分小さいなら
mov DWORD PTRほんにゃら
の繰り返しに展開してたな

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

237 :デフォルトの名無しさん:2008/07/28(月) 07:08:53
VCの最適化についてはダンゴさんは一言ありそうだな

238 :ヽ・´∀`・,,)っ━━━━━┓:2008/07/28(月) 08:05:14
ひょっとして「一家言」とでも言おうとした?

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

239 :デフォルトの名無しさん:2008/07/28(月) 09:21:09
一言でもおかしくないのでは?

240 :デフォルトの名無しさん:2008/07/28(月) 11:06:57
日本語的に正しいかどうかはともかく
「ひとことある」という表現はとても一般的だな。

241 :デフォルトの名無しさん:2008/07/28(月) 11:28:14
それほどおかしくないが、文脈的に見たら、一言あるだと大した意見もってねーって
馬鹿にしてる感があるけどw

242 :デフォルトの名無しさん:2008/07/28(月) 11:30:19
既に一言を言ってるのに一言あるはおかしいだろ

243 :デフォルトの名無しさん:2008/07/28(月) 11:35:34
このスレも団子に荒らされるのか


244 :デフォルトの名無しさん:2008/07/28(月) 11:39:06
っていうか団子の本拠地

245 :デフォルトの名無しさん:2008/08/06(水) 02:24:49
CPU が入力待ちなどで仕事をしていない時には、
SystemIdleProcessをグルグルまわしながらHALT 命令を発行して、
CPUを一時的に休止させてるんですよね?
でもなんで、リアルタイムに取得しているクロック数が変化しないんですか?

246 :デフォルトの名無しさん:2008/08/06(水) 07:23:15
休止つっても部分的なものだし

247 :デフォルトの名無しさん:2008/08/07(木) 14:09:50
>>245
HALTで低消費電力状態に移行しても、
タイムスタンプカウンタは回り続けている
ということだと思うよ。

248 :,,・´∀`・,,)っ-○●◎:2008/08/09(土) 00:28:42
っていうかTSCってFSBから取得だし

249 :デフォルトの名無しさん:2008/08/09(土) 08:07:35
AMDはクロック周波数変えると・・・orz

250 :デフォルトの名無しさん:2008/08/10(日) 21:50:15
>っていうかTSCってFSBから取得だし
これ、まじですか?
じゃ、FSBを上げてオーバークロックやってる人の時計ってめちゃくちゃなんですか?

251 :デフォルトの名無しさん:2008/08/10(日) 22:21:15
(゚Д゚)ハァ?

252 :デフォルトの名無しさん:2008/08/11(月) 00:50:29
すんません。勘違いです・・・

253 :デフォルトの名無しさん:2008/08/12(火) 21:10:26
E8000&E7000 Specification Update 8月
ttp://download.intel.com/design/processor/specupdt/318733.pdf
P.13
E0ステッピングでAW51は修正されていないようだ

254 :デフォルトの名無しさん:2008/08/13(水) 05:07:09
E0には間に合わなかったのか

255 :デフォルトの名無しさん:2008/08/13(水) 09:35:41
X 印は修正が適用されているということでは?

256 :デフォルトの名無しさん:2008/08/13(水) 09:52:23
修正完了しているのだと、X印ついてなくて、Fixedってついてるんだから、
Plan FixなAW51はまだ修正されてないよ。

257 :デフォルトの名無しさん:2008/08/13(水) 10:25:42
すんません、ちゃんと記号説明を理解していなかったようです;-)


258 :デフォルトの名無しさん: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

259 :デフォルトの名無しさん:2008/10/12(日) 00:03:51
分岐予測について

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

260 :デフォルトの名無しさん:2008/10/12(日) 00:50:36
条件付き分岐の場合のみ使えるプレフィックスがあって、
2E : not taken
3E : taken
となる。プレフィックスがない場合はシラネ。

261 :デフォルトの名無しさん:2008/10/12(日) 01:24:44
普通に考えればnot takenだろう

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


262 :デフォルトの名無しさん:2008/10/12(日) 01:29:58
一般論だと
前方→NotTaken
後方→Taken
を優先するもんだけどな。

263 :デフォルトの名無しさん:2008/10/12(日) 01:35:35
なに? 分岐予測のペナルティを計測しろだと・・・これまた面倒な。

264 :デフォルトの名無しさん:2008/10/12(日) 01:51:07
ちょっと待て

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

265 :デフォルトの名無しさん:2008/10/12(日) 06:34:26
>>259
プロセッサによって違う。
>>2のリンク先
http://www.agner.org/optimize/microarchitecture.pdf のP.27
"3.9 Static prediction" に各プロセッサの説明が書いてある。

266 :259:2008/10/12(日) 10:16:48
ありがとう。

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

267 :デフォルトの名無しさん:2008/10/12(日) 12:41:52
P4まで使っていた静的予測をCore2でやめたのは、どうしてだろう。

268 :,,・´∀`・,,)っ-○◎●:2008/10/12(日) 14:56:49
別に辞めた訳じゃないですぜ。そもそもPentium 4の系譜じゃなくて
P6→Pentium M→Coreの系譜だし。
強いて言えばNetBurstアーキテクチャを辞めた。

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

269 :デフォルトの名無しさん:2008/10/12(日) 15:29:03
P6→Pentium Mのときに静的予測をやめたのかな。
履歴をたくさん持てば十分、ということなのだろうか。

270 :1 ◆.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がどのくらい響くかが見物だ。

271 :デフォルトの名無しさん:2008/10/13(月) 11:41:54
複数のコアで、同一のキャッシュラインに対して読み書きすると、酷いことになるのはわかる。
では、
同一のキャッシュラインの命令を複数のコアで実行すると、どうなるの?

272 :デフォルトの名無しさん:2008/10/13(月) 14:17:00
>>271
1度命令キャッシュに取り込めばヒットする限りシングルコアと同じ。
読むだけならデータも命令も同時にアクセスした数だけ待たされるだけだからそこまで酷くはならない。

273 :デフォルトの名無しさん:2008/10/13(月) 14:37:16
ありがとう。


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

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

275 :,,・´∀`・,,)っ-○◎●:2008/10/15(水) 01:29:58
ヒント:MESI

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




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

276 :デフォルトの名無しさん:2008/10/15(水) 01:53:39
マンデルブロがSSE2を使ってくれないのだが

277 :デフォルトの名無しさん:2008/10/15(水) 03:05:33
排他ロックをかけずに済ませるアルゴリズムもあるし、
同一キャッシュラインに複数の変数が乗るので、それぞれロックを別のスレッドが取得すると、同時に読み書きするし、
そもそもロックの排他制御が、まさに、同一のキャッシュラインを読み書きする処理だし。

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

278 :,,・´∀`・,,)っ-○◎○: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


279 :1 ◆.MeromIYCE :2008/10/21(火) 20:01:59
>>278
SSEでPenM-1.1GHzと同レベルか。
PenMもSSE2は得意じゃないと思ってたけど、
Atomは本当にSSE2(倍精度FP)が苦手なんだな。

280 :,,・´∀`・,,)っ-●◎○: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

281 :,,・´∀`・,,)っ-●◎○:2008/10/22(水) 02:43:57
他なんかある?

282 :1 ◆.MeromIYCE :2008/10/22(水) 21:09:41
>>280
SSEでPenM-1.1GHzに近い性能なのはいいとして、
FPUでもあんまり遅くなってないね。

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

283 :デフォルトの名無しさん:2008/10/23(木) 01:11:57
FXCHについてはHT前提だからじゃないの?
最適化の感覚的には1clkの見積もりでいいっしょ。

284 :デフォルトの名無しさん:2008/10/23(木) 01:15:43
確かにAthlon64ではFXCH命令は速くならんな

285 :デフォルトの名無しさん:2008/10/23(木) 01:55:44
もうx87FPUは使うな! っていうことかと。

286 :デフォルトの名無しさん:2008/10/23(木) 01:57:30
HTで、どれくらいパイプライン効率を上げられるのか、どうやったら調べられるかな。


287 :デフォルトの名無しさん:2008/10/23(木) 07:44:54
スループットが2clkなのか。スマン。

288 :デフォルトの名無しさん: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

289 :,,・´∀`・,,)っ-●◎○:2008/11/13(木) 20:32:44
Penrynとあんま変わってないじゃないか。
良くも悪くも

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

290 :,,・´∀`・,,)っ-●◎○: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

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

291 :デフォルトの名無しさん: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

292 :デフォルトの名無しさん: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レジスタ版を除き)倍になっている

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

294 :デフォルトの名無しさん:2008/11/14(金) 21:04:03
PADDQのスループットレイテンシが良くなってるな。


295 :デフォルトの名無しさん:2008/11/14(金) 21:46:14
>Radix-16 Dividerとシャッフルユニットって回路共有できるんじゃないかと思ってたけど
できねーよw

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

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




297 :デフォルトの名無しさん:2008/11/15(土) 20:10:49
団子はプログラムだけかたってりゃいい。
無理に回路の話するな。

298 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 20:17:30
どっちも4ビットのテーブル参照ユニットだよ。
radix-16の実装についての論文は嗜んでおります。多分君らよりはモノ読んでるから。

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

300 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 20:56:50
専用化(笑)

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

301 :デフォルトの名無しさん:2008/11/15(土) 21:11:53
ダンコ″さんが饒舌になるとスレが湧き上がるな

302 :デフォルトの名無しさん:2008/11/15(土) 21:26:16
>除算命令をパイプラインのどこでマイクロコードに分解してると思う?
>無理にハード語るなよ
団子ワラタ
こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

303 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:13:14
http://www.agner.org/optimize/instruction_tables.pdf

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

304 :,,・´∀`・,,)っ-●◎○: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


305 :デフォルトの名無しさん:2008/11/15(土) 22:35:46
おいおい、団子よ、誤魔化そうとするなよ。
おれはシングルuopとはいってない。
だが、団子は、uopに細かくばらすことで回路を共用にできると思ってるんだろw

306 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:38:12
はいはい、恥ずかしいから帰っていいよ。



307 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:43:50
次来るときは共用してない根拠を示してね
その逆の説明は、多くのx86アーキテクチャで除算命令とシャッフル命令の発行ポートが同一な
理由の説明にもなってしまう

308 :デフォルトの名無しさん:2008/11/15(土) 22:44:23
>除算命令をパイプラインのどこでマイクロコードに分解してると思う?
この答えは猿でもわかるデコーダだが、団子はこの先何を言いたいのでしょう?
無知をさらしたくないならレスをしない方が身のためかもよ。

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

310 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:46:16
もう恥ずかしいから出てくるなよ。
マイクロオペレーション数とかかってるクロック数数えてみな。
馬鹿にはわからない真実がある。

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

311 :デフォルトの名無しさん:2008/11/15(土) 22:48:50
>マイクロオペレーション数とかかってるクロック数数えてみな。
自分で自分の間違いに気づいたのか、単なる電波なのか。
お団子くんの必死の弁解ショーがこれから始まります。

312 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:51:57
別ユニットであると自信を持って言える根拠ってなんだろうね

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

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

313 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:53:55
つーかpshufbが辞書引きでなくてなんだって話になるけどな。
辞書引きする値の供給元が定数ROMかレジスタかって違いか


314 :,,・´∀`・,,)っ-●◎○:2008/11/15(土) 22:57:17
とりあえずSSE4.2のテキストサーチが汎用のシャッフルユニットの組み合わせで実装されてる程度には
除算命令も汎用ユニットに対するマイクロオペレーションの組み合わせで実装されてるよ



315 :デフォルトの名無しさん:2008/11/15(土) 23:24:34
タ″ンゴさんの連投れスレが猛烈にヒートアップしたな

316 :,,・´∀`・,,)っ-●◎○: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の内訳はなんだろうね?

はい、これ宿題ね。

317 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:06:38
7μOpsの内訳、資料に書いてあるわ

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

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

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


馬鹿丸出しだな

318 :デフォルトの名無しさん:2008/11/16(日) 00:12:33
↓↓↓ダンゴ先生(NGワード)の勝利宣言が続きます↓↓↓







319 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:18:32
ヲーーーーーーーーーーーーーウィWWWWWWWWW
「除算は除算専用ユニットで処理される」とか恥ずかしい事言ってたフェンス君出てコーーーーーーーーーウィWWWWWWWW
ああどうしてフェンス君はこんなにも脳内がお花畑なんだWWWWWWWW
チクショオオオオオオオオオオオオオオオオWWWWWWWWW

320 :デフォルトの名無しさん:2008/11/16(日) 00:21:43
おれはフェンス君じゃないよw
団子の脳内CPUにはユニット未満の回路構成単位はないみたいでワラタ。
複数サイクルかかるのはなんでもuopに分解されてるからとでもおもってんのか、こいつはw

321 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:22:41
事実複数μOPsに分解されてるジャン。
言い訳になってないよ。

322 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:25:16
レイテンシチェインがあり複数命令をインターリーブできない場合はスループットも内部OPs数以上になることはあるね。
P5までのx87命令が代表例。

323 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:26:24
【7μOpsの内訳】

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

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

恥ずかしくないですか?

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

325 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:30:10
>お前の頭には1uopで動く一般的な"除算器"(もちろん実行ユニットやポートと1対1とは限らない)という概念がないのね。

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

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

327 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:33:17
Penrynには【除算専用ユニット】が全ALUポートに2:3:2で存在するのか
すげーな


328 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:34:42
>>326
じゃあ何の命令を発行してるの?
除算ユニットは何番ポートにあるの?

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

330 :デフォルトの名無しさん:2008/11/16(日) 00:37:18
ちゃんと読み返せばわかるとおり、
おれは2つ以上のuopに除算命令が分解されることはない
なんて一切かいてない。適当な団子よりも言葉を選んでいるし、あと百回読んでからレスしろよ。

331 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:37:36
馬鹿はお前だ。
除算専用ユニットでの1μOPで完結してるとして残りの6μOPsは何のために何の命令を発行してるんだ

 答  え  て  み  ろ  よ

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

332 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:38:32
「おれ」を漢字で書かないのはフェンス症候群


333 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:39:38
言っておくけど、NOPは、発行せずにリタイヤだよ。

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

335 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:47:22
パイプライン化されてない命令が複数サイクルかかるのは一つの事実だけど
除算命令が複数μOPsに分解される事実を否定するものでは無いな

336 :デフォルトの名無しさん:2008/11/16(日) 00:49:15
だから複数uopを生成しないなんておれは書いてないだろ。

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

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

337 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:50:28
>通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?

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

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

338 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:50:48
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw

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

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

340 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:58:28
逃げてるのはお前だろ。
自分では具体的な証拠も示さないくせに
無根拠な主張だけは延々やるんだな

341 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 00:59:55
負け犬よ。ごたくはいいからμOPsの内訳を答えろよ。
答えられないなら赤い顔に水でもかぶってさっさと寝ろ

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

343 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 01:05:43
整数除算で起きる特殊例外なんてせいぜいdivide by zeroくらいだぞ?
フラグ更新なんて分岐条件フラグを更新するaddやandが1μOPで済んでる程度に低コスト。

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

344 :デフォルトの名無しさん:2008/11/16(日) 01:07:09
他にもスケジューリング単純化の都合で使わないALUを麻痺るとか?

345 :デフォルトの名無しさん:2008/11/16(日) 01:08:12
Fused uopな故に、実際にはuopなんて生成していないが、
ポートが使えずに、uopが生成されたかのように見えるとか?

346 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 01:16:03
結局これがすべて最初から最後までハードワイヤードロジックで実装されてると思ってるんだろ
http://pc.watch.impress.co.jp/docs/2007/0524/mpf01_04.jpg

それが大間違いだよ



347 :デフォルトの名無しさん:2008/11/16(日) 01:21:07
風呂敷あと何枚ひろげたら気が済むんだ?
そろそろたたまないとエヴァ●ゲリオンの二の舞だよ。

348 :デフォルトの名無しさん:2008/11/16(日) 07:21:03
>>341
人に答えさせようとするよりも、自分からビシッと示して、話をスパッと終わらせたほうがいいと思う。

349 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 11:03:27
俺がやる必要ないし
すべてハードワイヤードロジックで実装されてるっていう思い込みありきだから
現実世界の事実と照合したときに矛盾ばかりが浮上する。それだけ。

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

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

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

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

350 :デフォルトの名無しさん:2008/11/16(日) 11:31:33
ダンゴさんのエスプリの効いたレスでスレがあふれ返っているな

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

352 :デフォルトの名無しさん:2008/11/16(日) 12:25:40
ダンゴさんの自演でスレの信憑性が一気に高まったな

353 :デフォルトの名無しさん:2008/11/16(日) 12:33:30
そもそも団子はハードワイヤードロジックって言葉が
何を指しているかもわからないんだろうけどなw
ハードに関しては素人以下の妄想レベル。

354 :デフォルトの名無しさん:2008/11/16(日) 12:36:29
テーブル参照がマイクロコードなしでは実装できないという電波説も新たに披露してくれるのか。
配列やハッシュに相当する機能はハードだけで実現できるのをしらないんだねw

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

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

一番わかりやすいのが、
剰余 = 被除数−(商×除数)

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

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

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

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

356 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 13:35:54
>>354
そんなこと一言も言ってないけど。
いい加減一人相撲に気づけよ


357 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 13:38:30
ちなみに>>346の図には剰余の出力が描かれてないね。


358 :デフォルトの名無しさん:2008/11/16(日) 13:40:34
ちゃんばば臭い。

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

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

359 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 13:45:55
除算ロジックから剰余出力を端折る理由:だって浮動小数に必要ないじゃん。
商だけわかれば剰余を汎用のユニットで求められるだろ。

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

360 :デフォルトの名無しさん: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も原理的には同じクロスバースイッチによる実装だよ。

361 :デフォルトの名無しさん:2008/11/16(日) 14:00:42
さて、>>346の除算器でどうやってシャッフルが可能になるのか。
論文をたんさんよんで、しかも理解しているという団子先生のもう講義が
これからはじまります↓

362 :デフォルトの名無しさん:2008/11/16(日) 14:17:26
>>358
すぐ直後にEDXレジスタに上書きしていれば、剰余は計算しなくてよいってわかるね。
つまりEDXレジスタの参照をしたときに剰余の計算が発生する? それじゃパイプライン止まるな。

363 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 15:08:28
>>360
お前は頭も悪いし勉強できてないな。
俺の理解を曲解することしか
俺がいつ、シャッフル命令+αの命令単位に分解するなんて言ったよ?
たとえるなら積和算ユニットの一部を単体の乗算と加算で使えるってレベルの話しかやってない。
複数μOPsに分解される理由を曲解してるからそういう妄想にたどり着くんだろうな。

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

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

364 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 15:12:10
>>362
不正解。
おそらく、剰余を端折れるか判定してさぼるための機構のほうが
まじめに剰余出力するよりコストかかることだろう

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

365 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 15:15:08
複数マイクロオペレーションかかる理由

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


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

366 :デフォルトの名無しさん:2008/11/16(日) 15:44:07
伝搬速度がクリティカルなので回路を使いまわせません!

367 :デフォルトの名無しさん:2008/11/16(日) 16:11:13
「勝ち」を確信したダンゴさんのアゲ荒らしは凄惨極まりないな

368 :デフォルトの名無しさん:2008/11/16(日) 16:21:27
ダンゴさんの書き込み頻度を見てみると
どうも時々発作が出るみたいだな


369 :デフォルトの名無しさん:2008/11/16(日) 16:24:49
団子さんは初めに自分の考えが誤っていることを認めるべきだった。
間違いは直ぐに認めて訂正した方が良い。
だから無駄に書き込みの回数が多くなるんだよ。

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

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

370 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:27:15
俺の撒いた風呂敷に足を滑らせてフェンスに激突


371 :デフォルトの名無しさん:2008/11/16(日) 16:30:45
>>365
おれは、シャッフル演算器と除算器の共用化の話をしているので。
脱線話の1レスに粘着して、自分の汚点を体力勝負の罵倒書き込みで覆い隠そうなんて魂胆、
バレバレだし、はずかしいんでヤメテ欲しいです。

372 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:31:17
>>369
何も公式な解説が出てないので実際共有してるかしてないかは
Dividerと追加されたシャッフルユニットが同じポートに追加されたのは一つの事実だ。
俺は何一つ断定したことは言ってない。

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

373 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:31:51
>>371
恥ずかしい馬鹿だな。
脱線してフェンスに激突してるのはお前だけだよ

374 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:32:38
・わけもわからないフラグ更新
・わけもわからない例外処理
・演算ポートに「フェンス」(←得意のwww)



375 :デフォルトの名無しさん:2008/11/16(日) 16:33:37
スレタイ読めよ。

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

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

377 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:33:44
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw
>こいつは除算命令をuopに分解して、汎用的なユニットにバラまいてると思ってるらしいぞw


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

378 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:34:12
何度もいうが、おれは全く1uopのみだと思っていなかったし、1uopしか生成しないなんて


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


379 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:35:02
>何度もいうが、おれは全く1uopのみだと思っていなかったし、1uopしか生成しないなんて
>いったことはないが。

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



380 :デフォルトの名無しさん:2008/11/16(日) 16:35:14
だから、前後の流れをみずに都合の良いように1行だけ引用するな
クズ団子が。

381 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:36:17
何度もいうが、この馬鹿はこの発言をした時点では、全く1uopのみだと思っていた。

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


382 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:37:29
>>380
前後の流れを見てもお前の勘違いは確実だが

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

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

383 :デフォルトの名無しさん:2008/11/16(日) 16:37:38
普通によめば
除算器をもちいずに汎用的な他の演算ユニットで処理していると読める
団子は鬼の首をとったように持ち上げているが、団子理論では
除算器なんていらないんだもんなw

384 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:38:58
恥ずかしい発言だね

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


385 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:39:53
>>383
お前が曲解してるからそう読めるだけだよ。
だって俺が指摘するまでμOPsの中身を説明できなかったのが理解できてなかった証拠

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

387 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:41:17
っていうか、鬼の首をとる?蛆虫を靴で踏み潰すの間違いだろ。


388 :デフォルトの名無しさん:2008/11/16(日) 16:41:54
そんなことよりも、Core i7買ったのか? おまえら。

389 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:43:12
>>386
プライド無いんだね。
コロコロ珍説を撤回されては議論になんないよ。論破じゃなくて論理破綻だよ。

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

390 :デフォルトの名無しさん: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

391 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:45:04
別に間違ったことは言ってないね

392 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:46:32
>通常プログラマから見えない内部フラグとか例外検出のための処理とかじゃね?

これは間違ったことだね

393 :デフォルトの名無しさん:2008/11/16(日) 16:47:48
それでは団子先生、
除算命令をパイプラインのどこでマイクロコードに分解しているのか
という質問の意図はいったい何だったのでしょう?
そして、何故シャッフルユニットと除算器の共用化で高速化が可能になるのでしょう?

394 :デフォルトの名無しさん:2008/11/16(日) 16:47:53
>>78
他スレにあった情報によると
AthlonMPはメモリにアクセスしに行く前に、
もう片方のCPUのキャッシュに問い合わせを行うので、
そのためにレイテンシが大幅に増加するらしい。

395 :デフォルトの名無しさん:2008/11/16(日) 16:48:23
>>392
間違いだとは残念ながら団子君の根拠だけでは説明しきれてないが何か?

396 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:49:52
×高速化
○回路の節約

397 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:51:22
>>395
じゃあ何のフラグなのか説明しろよ。
言ってる本人が理解できてないものを否定するなんて悪魔の証明なみに無意味だ。


398 :デフォルトの名無しさん:2008/11/16(日) 16:53:33
あれあれ、そもそも団子先生は、
>>290,>>293でNehalemでシャッフルが速くなった理由として、
共用化の可能性をあげていたのでは?
いつのまにか節約の話に変わっていますね。

399 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 16:56:39
それがそもそもの間違いはそこから始まってるようだな。

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

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



400 :デフォルトの名無しさん:2008/11/16(日) 17:07:34
                  -‐ '' " ",. ̄'' ̄` ''‐、
                ,.-'      ,r''  _,,.. - 、  ` 、
               ,.r'/// /   ,.-'      `' 、. \
             /       ,r'  ,r'          \ '、
               / /////  ,'   ,'             ヽ ',
            i     ,.ァ   .i          r=ァ.   ',. ',
                |  ,.r '"  |.   {  r=-            ', ',
            | .,.r'    |   !               i .i
            |,'      ',   ',      .ー=‐'      | .|
            |       ',    `、              } .}
                ',         ',    '、             ! .|
            '、       `、   \            ,' !
             `、        '、     ' 、        / .,'
                '、'-..,,_____ ___`、    `''‐- ..,, ,,.. r'  /
               \ ヾヾヾヾヾ \          /
                ` 、  、、、、、、、、 ` - ..,,, _ _,.r'゙
                  `' - .,,_       _,. - ''"
                      `"'' '' '' ""


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

402 :デフォルトの名無しさん:2008/11/16(日) 17:16:54
ポートじゃないや実行ユニット。

403 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 17:17:25
pshuf* shufp*が発行できるユニットは1基から2基に増えた

404 :デフォルトの名無しさん:2008/11/16(日) 17:17:58
まちがいw
実行ユニットじゃなくてポートは2つある。

405 :デフォルトの名無しさん:2008/11/16(日) 17:20:08
よくよむと、PenrynのPort0とPort5のQW Shuffleは、ポートは別だけど実行ユニットが共通っていう
変態実装らしいな。Nehalemのはマニュアルが更新されるまで本当のところどうかわからない。
マジで2つに増えたのかも。

406 :,,・´∀`・,,)っ-●◎○:2008/11/16(日) 22:22:16
> よくよむと、PenrynのPort0とPort5のQW Shuffleは、ポートは別だけど実行ユニットが共通っていう
> 変態実装らしいな。

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

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

407 :,,・´∀`・,,)っ-○◎●: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になる。

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

409 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:06:24
>QW shuffleはPort0,5で扱えるが、
無理

410 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:06:54
> QW shuffleはPort0,5で扱えるが、
ソース出せソースwww


411 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:07:45
せっかくPort 5でしか発行出来ないことを証明する方法提示してやったのに
アホ晒せよ


412 :デフォルトの名無しさん:2008/11/17(月) 00:08:54
>>401の34ページにかいてあるよ。

413 :デフォルトの名無しさん:2008/11/17(月) 00:10:00
マニュアルではPort1だけどね。
Port1とPort5から受け入れて、実際に処理するのはPort5の128bitのshuffleユニット。
そう書いてある。団子の計測結果の誤解釈ではなくマニュアルにねw

414 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:10:11
[QW shuffle]


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

415 :デフォルトの名無しさん:2008/11/17(月) 00:11:08
34ページじゃなくて37ページだな。

416 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:12:58
また例によってマニュアルの誤読のようだな。

あほらしい
恥の上塗り

417 :デフォルトの名無しさん:2008/11/17(月) 00:13:04
64bitに決まってるだろw
いい加減に間違いを訂正して謝罪しろよw

418 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:17:49
ああようやく意味がわかった
QW=汎用レジスタ用≠非SIMD

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


419 :デフォルトの名無しさん:2008/11/17(月) 00:22:20
>>418
3. Uses 128-bit shuffle unit in port 5.

420 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:22:44
確かにAgnerとIntelの資料だとport1と0が入れ替わってるな
まあ記号でしかないのでどうでもいいが。
FPmul側とFPadd側で通じるし


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

421 :デフォルトの名無しさん:2008/11/17(月) 00:23:43
見事に団子さんが一番脳内アーキテクチャでしかないことが発覚してしまったな。

422 :デフォルトの名無しさん:2008/11/17(月) 00:27:34
みたところスケジューラをいじらずに、Super Shuffle Engineを実装するため、
Meromからの使用ポートはそのままで、128bit Unitを使うようにしたっぽい。

423 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:28:03
>>419
QW Shuffle(笑)を使う唯一?の命令であるBSWAPは
元々2μOps発行でPort5に発行される。
Agnerのp30でも嫁

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

424 :デフォルトの名無しさん:2008/11/17(月) 00:30:56
関係ないけどAgnerだって計測結果からの考察をしているだけで、
予想にすぎないということはお忘れなく。
具体的にどんな実装かはIntelの中の人でなければ正確なところはわからない。

425 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:33:28
大丈夫、お前の妄想通りのこれだけは絶対ないから

Port 0          Port5
+→ 128-bit Shuffle←+

426 :デフォルトの名無しさん:2008/11/17(月) 00:34:43
で、団子はマニュアル読んだことあるのかな?

427 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:35:16
μOPs数なんてRDPMCでカウント出来るの知ってるよね?
ちなみにIntelのマニュアルは結構誤植多いよ

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

428 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:35:56
>>426
お前の脳内マニュアルなら無い

429 :デフォルトの名無しさん:2008/11/17(月) 00:36:22
ちなみにマニュアルにはPort1とPort5がQW shuffleに割り当てられていて、
Penrynでは注意書きの3でport 5の128bitユニットを使用するとかかれています。
以上

430 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:41:09
それを曲解してこうなってると勘違いしたのか。馬鹿丸出しだな

Port 0          Port5
 +→ 128-bit Shuffle←+

431 :デフォルトの名無しさん:2008/11/17(月) 00:41:57
煽りすぎ荒らしすぎ

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

432 :デフォルトの名無しさん:2008/11/17(月) 00:42:50
レスはなるべくまとめろ
レス番つけるのも基本

433 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 00:54:45
Agnerをして「嘘が書いてある」と評したIntelの最適化マニュアルがソース
検証無し

仕事になりませんな


434 :デフォルトの名無しさん:2008/11/17(月) 01:08:09
いさぎ悪いですよ。黙って今日はねる。
そして明日から別のネタで書け。

435 :デフォルトの名無しさん:2008/11/17(月) 01:08:34
CPUのパフォーマンスんカウンターの使い方、どこかに解説ない?
とくにWindowsのユーザーモードから触りたい。


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

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



437 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:12:19
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い
いさぎ悪い

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


438 :デフォルトの名無しさん:2008/11/17(月) 01:15:29
IJKKにでも入社すればいいのに。

439 :デフォルトの名無しさん:2008/11/17(月) 01:18:56
誤植呼ばわりでごまかしか。
結局団子の語る計測万能論なんて机上の空論の人たちの考えと何も変わってないわけで。
むしろ恣意的にそれっぽいデータを並べてくるあたり、信用できないやつがやると
たちが悪い。

440 :デフォルトの名無しさん:2008/11/17(月) 01:21:49
団子さんの脳内アーキテクチャではすごいことになっていることが証明されたな

441 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:22:25
実験するだけの能力もないフェンス級のヴァカ机上論者が論拠として使うには
品質が悪いよ、少なくとも

442 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:23:34
品質の問題じゃなくて解釈の問題だけどな。
こうなってるなんてどこにも書いてない

Port1          Port5
 +→ 128-bit Shuffle←+

443 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:24:53
「潔い」で1語

イサギって何だよ。

日本語もできないんだな


444 :デフォルトの名無しさん:2008/11/17(月) 01:25:48
実験者の能力が低いと実験してもろくな結果が得られないのは
どこの世界でも同じだな。実験でわかることととわからないことの線引きができてないやつが
計測結果から導き出したと称して、関係のないことまで妄想で語りだすというのが某さんの実態なんです。
まあ、そろそろスレの無駄だからやめようよ。

445 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:26:38
実験する能力もなくて脳内アーキテクチャを語る
それが「フェンス」くん


446 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:29:01
イサギ悪いぞ
 

447 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:32:19
そもそもここは「計測スレ」ですよ
まずIntelのマニュアルに誤植があったり不完全な記述があることから
自分たちで補完しようという意図があって成り立ってます。

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

448 :デフォルトの名無しさん:2008/11/17(月) 01:34:39
自ら本丸乗り込んでやればいいじゃないか。


449 :デフォルトの名無しさん:2008/11/17(月) 01:37:20
>>447
その割にはAgnerとかIntelの資料好きだな。
詭弁はよそうぜ。もちろん完璧な計測データを羅列して、
こうこうこうだ、だからIntelの資料は間違っている。
と、説明できれば誰も文句はない。それが本来の計測というものだ。

450 :,,・´∀`・,,)っ-○◎●:2008/11/17(月) 01:42:02
Agnerは計測してるじゃん
当然ながら俺は自分である程度正当性は検証してるよ。その上で使えるって言ってる。

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

451 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/11/17(月) 01:57:49
イサギw

452 :デフォルトの名無しさん:2008/11/17(月) 08:43:42
胃詐欺悪い

453 :デフォルトの名無しさん:2008/11/17(月) 09:36:03
ダンゴさんのsage連打で分が悪くなったことが証明されたな

454 :デフォルトの名無しさん: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の資料は矛盾しないし、シャッフルユニットを2つのポートで共有してるという仮説は不成立。

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

455 :,,・´∀`・,,)っ-□△○:2008/11/17(月) 11:45:36
イサギ悪いフェンス馬鹿は、マニュアルに書いてないことは信用しないらしいから無意味だよ。
たぶん三平方の定理も教科書に書いてあるから正しいんだと思うよwwwww
円周率も3と書いてあれば3。円周は正六角形の外周さ。

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

456 :デフォルトの名無しさん:2008/11/17(月) 18:15:45
よし、俺がジャッジしてやる。

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

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

457 :デフォルトの名無しさん:2008/11/17(月) 18:32:32
二人でオープンソースなx86 cpuエミュレータ作成して意見が割れた所だけbranch切ればおk。

458 :,,・´∀`・,,)っ:2008/11/17(月) 19:17:00
イサギ=フェンス氏はCore2実機どころかAtomすら買えない貧乏人なので勝負以前の問題でし

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

460 :デフォルトの名無しさん:2008/11/17(月) 19:37:17
団子君、いい加減いざぎ悪いよ。
まだやってんのかよって。

461 :,,・´∀`・,,)っ:2008/11/17(月) 19:44:57
イサギいぇーいいぇーい♪

462 :デフォルトの名無しさん:2008/11/17(月) 19:52:43
最近せっかくあるスレで団子が大人しくなったと思ったら
また別のスレに顔出してて正直荒れないかヒヤヒヤしてる。

463 :デフォルトの名無しさん:2008/11/17(月) 20:02:42
団子君、いい加減いざぎおいしいよ。

464 :,,・´∀`・,,)っ[だんごないよ]:2008/11/17(月) 20:10:12
さては子鮒釣り師だな?!

465 :デフォルトの名無しさん:2008/11/17(月) 20:16:48
あげて煽る方が悪い
これが俺のジャスティス

466 :デフォルトの名無しさん:2008/11/17(月) 20:21:32
×子鮒
○伊佐木

467 :デフォルトの名無しさん:2008/11/17(月) 22:34:03
なんだこのスレ
おもしれえ

468 :デフォルトの名無しさん:2008/11/18(火) 00:09:59
ダンゴさんの本拠地はゲハ板じゃないのか

469 :デフォルトの名無しさん:2008/11/19(水) 01:31:13
ああ、遂にあっちのスレでもウザくなってきた。
人の優位に立った気になって自慢するってどこの厨房だよ。

470 :デフォルトの名無しさん:2008/11/19(水) 02:15:26
実際厨房なんだから仕方ない


とは言えウザイけど

471 :デフォルトの名無しさん:2008/11/21(金) 16:24:48
馬鹿発言連発で笑えるだけまだ救いがある

472 :デフォルトの名無しさん:2008/11/21(金) 16:49:12
笑えるか?アレ

473 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/11/26(水) 19:40:24
諫木悪いくんは頭の角をフェンス(笑)にぶつけて氏ね


474 :デフォルトの名無しさん:2008/11/26(水) 21:26:54
ちょっとスレ違いだけどWindows7発売にするなら64bitを標準にしてくれよー
32bitのメモリ空間じゃもう狭すぎるだろ

475 :,,・´∀`・,,)っ-○◎● ◆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対応」をうたう暴挙

いいかげんにしる


476 :デフォルトの名無しさん:2008/11/27(木) 00:13:35
個人的にはAVXが境目かなと思ってる

477 :デフォルトの名無しさん:2008/11/27(木) 14:22:04
>>475
その手の会社って、社内で開発してないからね。
他所に作らせているので、既存のものを64bit対応させようにも、ドライバのソースコードにアクセスできない。

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

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

478 :デフォルトの名無しさん:2008/11/27(木) 22:47:08
そんな大それた理由ではなく、単にやる気がないだけの予感。
OEM元のリファレンスドライバには64bit版がきっとあったはず。
海外での64bit普及率を考えれば無い方がおかしい。

479 :デフォルトの名無しさん:2008/11/27(木) 22:52:50
今時DAC未サポートのデバイスなんて少ないからね。

480 :,,・´∀`・,,)っ-●◎○:2008/11/27(木) 23:07:05
32bit版のドライバすら未署名だし。
「警告出るけど飛ばしてください」

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

481 :デフォルトの名無しさん:2008/11/27(木) 23:09:59
残念ながら、団子に同意。
マニュアルに「警告を無視しろ」なんて書くのは恥だと思わないもんかねぇ。
まるでVeriSignが期限切れになっている某通販サイトのようだ。

482 :デフォルトの名無しさん:2008/11/27(木) 23:27:49
未署名ドライバが必要な売り物ってのはどうかと思うが、未署名ドライバを
強制的に制限しているMSもどうかと思う。俺が買ったOSで俺が書いたドライバを
F8無しでロードできないってふざけるなよ。


483 :デフォルトの名無しさん:2008/11/28(金) 00:23:31
MSからよくOSを買えたな
俺は貧乏だから使用権のライセンスくらいしか買えねえや

484 :デフォルトの名無しさん:2008/11/28(金) 00:51:06
団子さんの自演でスレに火が灯ったな

485 : ◆0uxK91AxII :2008/11/28(金) 03:25:58
エロデータが外注丸投げをしているのは、事実。
Vistaの署名云々は、著作権保護がどうのこうのという理由からのモノだった気がするする。

486 :デフォルトの名無しさん:2008/11/28(金) 04:47:42
>>478
64bitに対応しなくても売れるうちは、対応しないと思う。
過去の製品のドライバをアップデートするなんて無償サービスも、やらないっしょ。

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

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

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

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


487 :デフォルトの名無しさん:2008/11/28(金) 04:58:18
まあ、未署名のドライバを使っているような糞製品は、俺は、買わないのでどうでもいいんだが。




488 :デフォルトの名無しさん:2008/11/28(金) 08:07:19
VeriSignみたいな信頼すべきできない外道企業が認証局なのが気に入らない
いつSite Finderみたいな阿呆な事をやるかわかったものではない

489 :デフォルトの名無しさん:2008/11/28(金) 12:41:55
VeriSign一択ではないだろ。

490 :デフォルトの名無しさん:2008/12/06(土) 23:48:43
Windows上でCPUのCR4レジスタのPCEを1にセットしたら、
ユーザーモードのプログラムでCPUのパフォーマンスカウンタをいじることができるの?

491 : ◆0uxK91AxII :2008/12/07(日) 07:27:12
>>490
can NOT.

492 :デフォルトの名無しさん:2008/12/07(日) 10:38:23
できないのか、残念。

493 :デフォルトの名無しさん:2008/12/07(日) 21:58:23
設定するためのRDMSR & WRMSR に特権モード(リング0)が必要。
カウンタの値を読むだけなら PCE=1 の場合、RDPMC が許可。
カウンタの設定とPCE=1にする、適当なドライバをでっちあげたらいいのか?

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

494 :デフォルトの名無しさん:2008/12/26(金) 14:10:02
O腹のかいしんのいちげきは無視かよ!
http://journal.mycom.co.jp/special/2008/nehalem02/
ああ、貧乏人はCore i7を買えないんですね?

# 本人乙の予感

495 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/12/26(金) 19:13:40
イサギ悪いので嫌いです

496 :デフォルトの名無しさん:2008/12/26(金) 20:11:23
>>493
そう、あなたは馬鹿です。

497 :デフォルトの名無しさん:2008/12/27(土) 00:39:48
>>494
> 実行ユニットが5つから6つに増設された
この一文で、読む価値がないと判断した

498 :デフォルトの名無しさん:2008/12/27(土) 00:42:22
あのページ数であの糞重いサイトは苦痛

499 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/12/27(土) 03:27:05
コレ大原さん?
http://sylphys.ddo.jp/upld2nd/pc3/src/1228734885124.jpg


500 :デフォルトの名無しさん:2008/12/27(土) 04:09:09
Oの人は文面からintel嫌いを臭わせる才能だけ褒めてあげたい。

501 :デフォルトの名無しさん:2008/12/27(土) 15:25:35
低脳コテの執念深ささえあればあるいは

502 :デフォルトの名無しさん: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

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

503 :デフォルトの名無しさん:2008/12/27(土) 18:36:36
>>494
このCore i7のRMMAの結果は変な結果が多いけど、
Turbo Modeのせいで正しく計測できてないんじゃないの?
計測値を24/26倍すると、まともな値になるものが多い。

504 :デフォルトの名無しさん:2008/12/28(日) 04:54:09
>>494
大原さんはデタラメなのでスルー。

505 :デフォルトの名無しさん:2008/12/28(日) 04:57:01
大原さん、Xeonをファンレスで動かして
熱暴走する
っていう苦言を呈すのは勘弁してください。

506 :デフォルトの名無しさん:2008/12/28(日) 14:03:11
なんか、CPUのパフォーマンスカウンタをユーザーモードから使えるようにしよう、っていう動きがあるみたいね。

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

507 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/12/28(日) 16:51:20
RDPMCのことだね?

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

508 :デフォルトの名無しさん:2008/12/28(日) 17:06:51
ttp://developer.amd.com/cpu/LWP/Pages/default.aspx
これか。


509 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/12/28(日) 17:32:54
http://openlibsys.org/index-ja.html
逆の発想で任意のアプリから特権モードを使えるようにしてしまえってソフトならある。

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

510 :デフォルトの名無しさん:2008/12/28(日) 17:47:25
ttp://crystaldew.info/2008/09/29/digital-sign/
>Windows 7 では動作しないというレポートも受けています

511 :デフォルトの名無しさん:2008/12/28(日) 17:58:42
とりあえず落としとくわ

512 :デフォルトの名無しさん:2008/12/29(月) 02:51:00
>>509
ドライバ作ってそこでPMCを設定するってなのは既に誰かやってるだろう。
問題は、PMCはシステム全体で1つだってこと。

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

513 :デフォルトの名無しさん:2008/12/30(火) 06:12:31
codeanalystってoprofileとほぼ同じになったの?ぃぬx版だけ?
スレッド毎って別に既にあるプロファイラはやってる、、、よね?
あとpmcは複数あるシステムもあるらしいよ。

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

514 :デフォルトの名無しさん:2008/12/30(火) 09:02:11
CPUのコアごとにあるな。
スレッドごとに統計を出すのは、えげつない方法で実現している。よろしくない。

515 :デフォルトの名無しさん:2008/12/30(火) 09:38:18
そこらへん綺麗にならないかなぁ

516 :デフォルトの名無しさん:2008/12/30(火) 10:00:35
どうせx86はマイクロコードを使うのだから、コンテキストの退避・復帰を専用命令で行うようにしたらいいんだよ。
そしたらCPU作るほうは、自由にコンテキストを増減できるっしょ。


517 :,,・´∀`・,,)っ-●◎○:2008/12/30(火) 10:08:02
だから、それがXSAVE/XRSTORなんだが

518 :デフォルトの名無しさん:2008/12/30(火) 11:05:50
しかし、なんでそいつはPMCをやってくれないのだ・・・

519 : ◆0uxK91AxII :2008/12/30(火) 12:26:02
MSRとして、実装したから。

520 :デフォルトの名無しさん:2008/12/30(火) 15:55:04
ダンゴさんがアゲはじめたな

521 :,,・´∀`・,,)っ-○◎● ◆ISAGIW0/wI :2008/12/30(火) 16:07:18
ハイハイいさぎ悪いいさぎ悪い

522 :デフォルトの名無しさん:2008/12/30(火) 18:41:54
きもい

523 :デフォルトの名無しさん:2009/01/06(火) 20:44:27
最適化マニュアル更新
ttp://download.intel.com/design/processor/manuals/248966.pdf
NehalemとAtom追加

524 :イサギ: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を発行するとはかかれていません。

525 :,,・´∀`・,,)っ-●◎○:2009/01/07(水) 01:12:45
RDPMCで噛ませたμOPs数取れるのも知らないらしいなロートルはプッ

526 :デフォルトの名無しさん:2009/01/07(水) 18:34:15
伊佐木悪いスレ

527 :デフォルトの名無しさん:2009/01/10(土) 12:46:35
脳がいさぎたないコテ

528 :デフォルトの名無しさん:2009/01/22(木) 19:26:16
いさぎもい池沼コテのせいで過疎ったな

529 :デフォルトの名無しさん:2009/01/22(木) 19:58:57
人生いさぎ過ぎたスレだなぁ

530 :デフォルトの名無しさん: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 : +∞ * +∞ = +∞

531 :,,・´∀`・,,)っ-●◎○:2009/01/24(土) 04:30:32
>>520を見て、Atomの結果貼っておくか、と思ってテンプレ見ようと思ったら、
見逃してた>6あたりを見てこれはひどいと思いました。今更だけど見逃してたわ。
わかってる人はわかってることだけど、*((void*)p + x* sizeof(int))なんてx86にとっちゃなんでもないです。

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 : +∞ * +∞ = +∞


532 :,,・´∀`・,,)っ-●◎○:2009/01/24(土) 04:31:06
530の間違い

533 :デフォルトの名無しさん:2009/01/24(土) 09:28:43
> *((void*)p + x* sizeof(int))なんてx86にとっちゃなんでもないです。

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

534 :,,・´∀`・,,)っ-●◎○: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);



535 :デフォルトの名無しさん: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やるんだねえ
あ、こっちのほうがスレ的には関係あるか

536 :デフォルトの名無しさん:2009/01/25(日) 23:05:49
そのあたりが、RISCより速い理由?

537 :,,・´∀`・,,)っ-●◎○:2009/01/25(日) 23:40:49
とりわけメモリロードを繰り返すプログラムは強いと思う。
ベースアドレス+オフセット*スケーリング+32ビットまでの即値、なんて複雑なアドレッシングを1命令でこなせる。

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

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

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

538 :デフォルトの名無しさん:2009/01/25(日) 23:47:26
> 1命令でこなせる。
今やその1命令が複雑すぎるからAVXが待たれているわけだが。
結局RISCが悪いんじゃなくてIntelの諦めない最適化努力が偉かっただけ。
それも資本にものを言わせて出来たわけだけどな。

539 :デフォルトの名無しさん:2009/01/26(月) 00:02:56
その資本は、x86プロセッサを売った利益から得ているわけで、悪いことじゃないよな。

Intelの脱x86は
432
860
Itanium

他にもあったかな?

>>537
960は違うだろ。

540 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 00:03:36
は?AVXのメモリアドレッシングってx86そのまんまだけど?命令フォーマットのマニュアル読んだことあるのアンタ?
プリフィクスバイトからOpcodeまでの長さが固定化されるからデコーダにやさしいわけであって
アドレッシングモードは

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


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

541 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 00:05:11
>>539
確かに960はまあまあ成功したようだね。
後のPentium Proを作ったオレゴンチームである。

542 :デフォルトの名無しさん:2009/01/26(月) 00:05:32
AVXってダサくね?
命令が1バイト短くなるかどうか、ちょっとデコードがシンプルになるだけじゃん。
良く使う命令が長ったらしくて、使わない命令が1バイトなのは、どうかしてるぜ。

543 :デフォルトの名無しさん:2009/01/26(月) 00:10:46
960は成功したけど、DECからStrongARMを取得したので、いらない子になっちゃった。

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

544 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 00:17:15
>>542
その「使わない命令」(LDS, LES)のOpcode空間を整理したんじゃん。
先頭バイトのC4, C5をスキャンしただけでModRMの位置を推定できる。
もしLDS, LESが現役でバリバリ使われてる命令ならプリデコードのたびにストールしまくるよ。

545 :デフォルトの名無しさん:2009/01/26(月) 00:21:14
>>540
ホント人を見下すのが好きだな。
俺はあんたが言っている以上の事は言ってないんだが。

546 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 00:36:08
まあ諦めない努力だけで報われるならIA64はあんな惨状になってねーしなぁ
AMDがx86-64を出してこなきゃIntelはPentium シリーズの後継はItaniumにする予定だった。

547 :デフォルトの名無しさん:2009/01/26(月) 00:36:20
>>544
それでも長いじゃん。

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

548 :デフォルトの名無しさん:2009/01/26(月) 00:37:15
>>546
え?

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

549 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 00:43:10
IA64命令セットって全然コンパクトじゃないよ。
3命令分で16byte。Itanium 2は2バンドルだから32byte/clkの命令帯域だ。
その上でNOPだらけという悲しい罠。
片やCore 2は16byte/clkの命令フェッチ帯域で4issueやってるわけで。


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

550 :デフォルトの名無しさん:2009/01/26(月) 00:43:43
AMDは切り替えたくてたまらなかったろう。
でもアグレッシブな事やるとIntelがついてこないから3D Now!とかAMD64とかSSE5とかで歩み寄る。

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

551 :デフォルトの名無しさん:2009/01/26(月) 00:52:01
>>549
そうね。
hello, world
で、100KBくらいあってビビったような記憶が微かにある。


552 :デフォルトの名無しさん:2009/01/26(月) 00:53:41
そーか?
IntelはAMDとMSに感謝してもいいぐらいだと思ってる。
使用頻度で最適化とかいっても、
移行し終わったころには陳腐化してるかもしれんし。




553 :,,・´∀`・,,)っ-●◎○: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のずれたIntelの伝統的ロゴマークを刷新したのもこのへんだったよな。

554 :デフォルトの名無しさん:2009/01/26(月) 01:03:05
あんまし名前に意味はないと思うなあ。
すぐAdvancedとか付けたがる会社だし、Core (1)とかSSSE3とかもうネーミングが完全にマーケティングの道具でしかない。

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

555 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 01:12:37
>>554
Itaniumを「IA-64」ではなくて「IPF」と表記するようになったのもあのへんからだよ。
IntelはもちろんIntelの提灯持ちライターの筆頭の元麻布の記事にも表記の変化が見られる。


556 :デフォルトの名無しさん:2009/01/26(月) 02:09:19
だんごサンはIA-64いじってるの?

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

557 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 02:22:22
HP-UX向けの仕事したことがあったかな。
コンパイラはIntelのもMSも(ともにWindows用)も使ったことがある。

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

558 :デフォルトの名無しさん:2009/01/26(月) 02:28:53
なるほど。

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

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

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




559 :,,・´∀`・,,)っ-●◎○: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命令同時発行の威光も、同クロックですら完全に霞んでる。

560 :デフォルトの名無しさん:2009/01/26(月) 10:54:49
そしてXeonより上の信頼性が要求される用途でも、
CPU自体のRAS等の機能の充実によるメリットより、
複雑がゆえにバグが出やすいことのデメリットのほうが大きい。

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

561 :デフォルトの名無しさん:2009/01/26(月) 13:58:10
何に向かって吠えてるの?

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

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

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

562 :デフォルトの名無しさん:2009/01/26(月) 14:28:48
AMD64は命令が長くなる!
AVXを使ってもあまり短くならない!
いったんキレイサッパリ仕切りなおせばいい!
そうやって仕切り直したIA-64は命令が長いぞ!


563 :デフォルトの名無しさん:2009/01/26(月) 14:35:05
IA64を作った頃にはAMD64もAVXも無かったと思うんだ。
そしてAVXに関しては>>544の通り、大きな恩恵がある。

564 :デフォルトの名無しさん:2009/01/26(月) 14:40:33
>>542
なんというCISC脳!

565 :デフォルトの名無しさん:2009/01/26(月) 14:42:37
どうせAVXで仕切り直すならモード切替でもして、命令体系と命令長を抜本的に直しても良かったと思うけどな。

566 :デフォルトの名無しさん:2009/01/26(月) 14:54:49
>>564
むしろRISC的アプローチだろ
命令の出現頻度に応じて命令長を決めるのは
定量的アプローチを説いた人は、ネヘパタやパタヘネのパタさんかヘネさんだぞ。

567 :デフォルトの名無しさん:2009/01/26(月) 16:41:52
>>566
ははは。おもしろいことを言うね。


568 :デフォルトの名無しさん:2009/01/26(月) 17:14:25
こうなったら出現頻度の統計をとってハフマンで

569 :,,・´∀`・,,)っ-●◎○: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でない別の何か。

570 :,,・´∀`・,,)っ-●◎○: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命令程度は供給可能。

571 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 18:31:40
>>542宛が適切だったな

572 :デフォルトの名無しさん:2009/01/26(月) 20:51:57
> AVXが解決するのはまったく別の問題だ。
昨日から引き続き、勝手に別の事を話していると思う辺りが恥ずかしいな。

573 :561=572:2009/01/26(月) 20:58:26
> 80:20ルール(あるいは90:10ルール)って知ってる?
俺計算屋なんだけどあんまこの法則に当たった事がないんだよな。

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

574 :デフォルトの名無しさん:2009/01/26(月) 21:12:28
>今のご時世、計算は殆どボトルネックにならないという事かも知れない。
そりゃあんたがそういう計算に縁がないだけだ。

575 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 21:16:49
>>572
恥ずかしい子だな。
x86のメモリアドレッシングのボトルネックなんて最初から無いんだよ。
アドレス算出なんてただのシフト+加算だよ。


576 :デフォルトの名無しさん:2009/01/26(月) 21:30:21
俺のボトルネックは口だな。
頭の早さについていけない。

577 :デフォルトの名無しさん:2009/01/26(月) 21:32:12
他のやつが言っていたかどうかは知らないが
メモリアドレッシングがボトルネックだなんて俺は言った事無いぞ。
団子と同じ主張しかしていない。

578 :デフォルトの名無しさん:2009/01/26(月) 21:32:25
吃音なのか?

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

580 :デフォルトの名無しさん:2009/01/26(月) 21:37:46
命令キャッシュに大きさは必要ない

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

581 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 21:41:29
ひとつのプロセッサに使えるトランジスタリソースが少なかった時代にはRISCはよかったんだよ。
今みたいに何億も使える時代になっちゃうと、リッチなアドレッシングモードも
複雑でもなんでもなくなる。

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

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

582 :デフォルトの名無しさん:2009/01/26(月) 21:44:20
うー、異論を挟みたいが大筋では間違ってないだけに……

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

583 :,,・´∀`・,,)っ-●◎○: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演算命令を実装する。
これで延々、命令帯域を確保し続けることができる。



584 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 22:08:13
ちなみに、さっさと64ビットに移行すれば0F38グループも0F3Aグループも命令長を4バイトにすることが可能になるから。
AAMとかAASをオーバーライドできる。

585 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 22:09:02
#0F3Aは無理か。imm8があるから6バイト→5バイトだな。


586 :デフォルトの名無しさん:2009/01/26(月) 22:18:17
>>581
x86だと1命令でも、RISCだと複数の命令になってしまうので、
それらが依存関係を持つ1つのまとまった処理だというのを、
アウトオブオーダーのエンジンが自分で前後を見て判断しないといけないよね。

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

587 :デフォルトの名無しさん:2009/01/26(月) 22:23:13
ピコーン(AA略)

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

特許書くかな

588 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 22:26:20
困ったことに、Atom 1.6GHz VS Cell PPE 3.2GHzですら、たいがいの処理でAtomのほうが速いんだ
同じインオーダなのに。

589 :デフォルトの名無しさん:2009/01/26(月) 22:36:38
そりゃぁだってAtomは2スレッド×2コアだしょ?

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

だめじゃん!

590 :デフォルトの名無しさん:2009/01/26(月) 22:38:35
あれ? PPEでクロック換算したらPen4程度の性能が出た気がしたのはなんだったんだろう。

591 :デフォルトの名無しさん:2009/01/26(月) 22:56:23
Pentium4 < Atom ってオチじゃね?

592 :デフォルトの名無しさん:2009/01/26(月) 23:01:43
迷走しているな。
PPEが遅いのはRISCのせいじゃないだろう。

593 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 23:07:13
Pen4はSIMDが半速だからものによってはそんなもんになるんじゃね?

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

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

594 :デフォルトの名無しさん:2009/01/26(月) 23:24:41
なんだ
マカーがあんなに誉め称えていたG4が遅いだけか。


595 :デフォルトの名無しさん:2009/01/26(月) 23:25:31
だってモトローラだし。

596 :デフォルトの名無しさん:2009/01/26(月) 23:25:47
>>581-582
に対してのSunスレでの反応

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


597 :デフォルトの名無しさん:2009/01/26(月) 23:27:25
今となってはSUNにはなんの存在価値も残ってないもんねぇ。 

こういうこと?

598 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 23:38:34
2000年くらいにUltraSPARC IIeのエントリマシンとか出したことあったろ?
Javaで同じプログラム動かしたら既に同クロックのCeleronにも圧倒的に負けてたという
笑い話

599 :デフォルトの名無しさん:2009/01/26(月) 23:41:50
あれってシンクライアント用だったような。

600 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 23:46:42
これだこれ
http://ascii24.com/news/i/hard/article/2001/04/04/624913-000.html

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

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

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

601 :デフォルトの名無しさん:2009/01/26(月) 23:51:41
>>600
シンクライアントみたいなものじゃん。

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

602 :,,・´∀`・,,)っ-●◎○:2009/01/26(月) 23:55:34
「ワークステーション」のラインナップだし
http://jp.sun.com/products/desktop/ws/


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

603 :,,・´∀`・,,)っ-●◎○:2009/01/27(火) 00:00:29
てか、シンクライアント用途だとなおさら高コストなSPARCを選ぶ意味自体ないじゃん。
今ならARMですら十分だね。

604 :デフォルトの名無しさん:2009/01/27(火) 00:01:35
まあよそはよそ、うちはうちでx86以外の話は終わりにしよう。

605 :,,・´∀`・,,)っ-●◎○:2009/01/27(火) 00:05:39
Nanoはどこそこ性能駄目っぽいね。
さすがにAtomより性能良いだろうと思ってたんだけどやっぱりどこまでもVIAだった

606 :デフォルトの名無しさん:2009/01/27(火) 00:42:26
そうなのか。
提灯記事では、AtomよりNanoのほうがシングルスレッド性能が格段に良いような話だったが・・・orz

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

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

607 :デフォルトの名無しさん:2009/01/27(火) 02:19:39
>>570
命令長と命令実行時間を勘違いしているようじゃなぁ。


608 :,,・´∀`・,,)っ-●◎○:2009/01/27(火) 02:45:33
お前がな

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

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

609 :,,・´∀`・,,)っ-●◎○: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に変換するだけ。

610 :デフォルトの名無しさん:2009/01/27(火) 07:48:02
>>608
intel的にはx87 FPUは完全にステだから単なるfloat演算でもSSE使えって話だった気がするが。
そのためのSSE2だろ?

611 :,,・´∀`・,,)っ-●◎○:2009/01/27(火) 08:07:22
そっちか!
浮動小数オペレーションはスタック操作からレジスタ間オペレーションへ、
更に2オペランドから3オペランド、ベクタ長など、x86の変遷の中でも
もっとも1命令の意味が大きく変わってくる演算なので、サイズが
増えただの減っただの言っても一概にコード効率を論じることはできない。

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

612 :デフォルトの名無しさん:2009/01/27(火) 11:18:59
>>609
> 現状のSSEでは、プリフィックスを読み飛ばしながらOpcodeの位置を探っていかないといけない。

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

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

613 :デフォルトの名無しさん:2009/01/27(火) 12:19:46
つまり回路的には128ビット(16バイト)を同時に扱うという事?

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

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

614 :デフォルトの名無しさん:2009/01/27(火) 13:26:01
>>613
実装とは違うが、概念的には、デコーダを1つのブラックボックスとして見ると、

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

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

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

615 :デフォルトの名無しさん: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なんてのが許されるフォーマットだからたちが悪い。

616 :デフォルトの名無しさん:2009/01/27(火) 14:28:16
前の命令の境界が判別して間違っていれば破棄すれば良いという観点からすれば投機的な並列スキャンは可能。
ただし、ものすごい負荷になるけど。



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

618 :デフォルトの名無しさん:2009/01/27(火) 14:55:10
>>615
ステートマシンだと複数のクロックが必要だろ?


619 :デフォルトの名無しさん:2009/01/27(火) 14:56:36
>>615
当該のバイトだけではなく、それより前のバイトも入力として与え、
自分で前のバイトの内容も論理演算に含めるんだよ。

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

620 :デフォルトの名無しさん:2009/01/27(火) 15:00:40
加算器を思い浮かべればいい
1クロックごとに1つ上の桁にキャリーを伝搬していく → マイクロコードに相当
キャリー先読みによってキャリーの伝搬を排除 → ハードワイヤードに相当

621 :デフォルトの名無しさん:2009/01/27(火) 15:07:35
>>620
マイクロコードは、マイクロコードシーケンサーによって各回路に送り出されて
行くもんだと思う。

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

622 :デフォルトの名無しさん:2009/01/27(火) 15:19:42
レガシーコード(16ビットDISP/IMMあり)と従来コードでアルゴリズムを切り替えてるんだから
マイクロコードベースなんじゃねーの?



623 :デフォルトの名無しさん:2009/01/27(火) 15:27:43
>>618
逆に現実世界の実装が1〜2サイクル程度で済んでると思ってるのか?
加算機の桁上げなんてたかだか1ビットだ。バイト単位だと全然話が違う。

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

624 :デフォルトの名無しさん:2009/01/27(火) 15:41:09
>>622
2つの性格の異なるデコーダーを用意して、
コード種判定回路の出力に、その2つを切り替えるロジックを作れば、
別にマイクロコードで無くてもいいんじゃねーの?

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

625 :デフォルトの名無しさん:2009/01/27(火) 15:44:46
どっちにしろAVXに完全移行してSSE*がレガシーになればプリデコーダの負担も軽くなると
考えてるんだろIntelは。

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

626 :デフォルトの名無しさん:2009/01/27(火) 16:07:20
>>624
そんな力技ができるならLCPストールなんておきねーよ。
どれだけペナルティあるのか計算したことあんのか?

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

627 :デフォルトの名無しさん:2009/01/27(火) 16:52:13
>>623
そういや、AMD厨はNetBurstに対して、
L1命令キャッシュがトレースキャッシュになっているからモッサリだ
とか言ってたような。

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

628 :デフォルトの名無しさん:2009/01/27(火) 17:07:13
>>627
キビキビとか言ってる手合いはIntel叩ければダブルスタンダードでも平気なんでしょ。
信用するに値しない。

629 :デフォルトの名無しさん:2009/01/28(水) 00:22:27
x86命令の所要クロック計測スレ

630 :,,・´∀`・,,)っ-●◎○:2009/01/28(水) 00:23:33
パイプラインの構造を考察することはクロックを知る上で重要だ。もっとやれ貴様ら。

631 :デフォルトの名無しさん:2009/01/28(水) 03:40:42
そう言えば IEEE Spectrum の i860 の記事に
instruction decoder の state machine を人間が作れなくて
CAD の自動生成を使ったという話が無かったっけ?
ま,それほど大変だという話

632 :デフォルトの名無しさん:2009/01/28(水) 20:07:39
関係ないけど、例え人間が作れたとしても自動生成に任せるのは正しいと思った。

633 :デフォルトの名無しさん:2009/01/28(水) 20:34:58
人間が設計ツールを使うなんて普通の事なんだけど、それがどうかしたの?
自動配線ツールに与えるパラメーターを考えるのは人間だよ。

634 :デフォルトの名無しさん:2009/01/29(木) 02:21:17
>>608

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

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

635 :デフォルトの名無しさん:2009/01/29(木) 02:27:06
結局は実行速度さえ満足な物なら命令長なんてねぇ…

636 :デフォルトの名無しさん:2009/01/29(木) 03:07:28
>>632 >>633
時代が違う
まだ state machine の自動生成なんて最前線では使われてなかった時代

637 : ◆0uxK91AxII :2009/01/29(木) 05:43:46
Intelは時代を先取りした、と。

638 :,,・´∀`・,,)っ-●◎○:2009/01/29(木) 09:59:47
>>634
はぁ?

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

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

639 :,,・´∀`・,,)っ-●◎○:2009/01/29(木) 10:06:31
つか、SSEが頻繁に使うとか馬鹿じゃね?
整数スカラ命令を「使わない」とかwww
配列の添字どうやって算出すんの?
分岐もやらないのかよ?

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

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

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

640 :,,・´∀`・,,)っ-●◎○:2009/01/29(木) 10:29:29
実際問題、どんなアルゴリズム使おうと、
たとえSIMDで力業で並列演算やろうがLUT使おうがソフトウェア・ステートマシンやろうが
整数演算は常に使います。

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

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

641 :デフォルトの名無しさん:2009/01/29(木) 11:34:23
>>638
デコーダの回路のコスト・消費電力・局所的な発熱・伝搬遅延のボトルネック

642 :デフォルトの名無しさん:2009/01/29(木) 11:50:38
大体に、動画エンコーダなんかに代表されるSSEを積極活用したアプリは
Hyper Threadingで性能が数割上がる、つまり命令間の依存関係や
メモリレイテンシがネックになってる罠。

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

643 :デフォルトの名無しさん:2009/01/29(木) 11:55:47
>>641
的外れだなぁ
1デコーダで2μOPs分供給できれば稼働率を半分に抑えることができる
妄想論はやめてIntelの論文でも読んでくれ

644 :デフォルトの名無しさん:2009/01/29(木) 11:58:52
>>639
Itanium2のクロックが上げられないのは、32バイト/クロックの命令フェッチのせいなのか?
短いパイプラインと、ひたすら投機実行しては結果を捨てまくるアーキテクチャがネックだと思ってた。

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

645 :デフォルトの名無しさん:2009/01/29(木) 12:00:00
>>640
そいや、IBMはPOWERにBCD「演算」命令を追加したな。

646 :デフォルトの名無しさん:2009/01/29(木) 12:03:04
>>642
え?

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

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

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

647 :デフォルトの名無しさん:2009/01/29(木) 12:04:55
>>643
Intelの論文は、割り当てを真っ新からやり直すことはできない、というところからスタートしてるんじゃないか?

648 :デフォルトの名無しさん:2009/01/29(木) 12:05:52
どこの動画エンコーダでHTが逆効果になるか教えて下さいな

649 :デフォルトの名無しさん:2009/01/29(木) 12:14:11
>>646
知らないなら語らなくていいよ。無知蒙昧はなはだしい。
明示的なキャッシュ制御命令は程度スループット改善することはできるけど
レイテンシを埋めるには至らない。

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

650 :デフォルトの名無しさん:2009/01/29(木) 12:22:18
知ったかぶりもたいがいにしろ>>646

651 :デフォルトの名無しさん:2009/01/29(木) 12:36:06
L1とレジスタ舐め回す程度の小物ツールしか見たこと無いんだろ


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

652 :デフォルトの名無しさん:2009/01/29(木) 12:39:27
はいはい>>648-651まで、顔真っ赤にして4連投乙

653 :デフォルトの名無しさん:2009/01/29(木) 12:42:20
見えない敵と戦う知ったかぶり

654 :デフォルトの名無しさん:2009/01/29(木) 12:44:12
>>652
>>648

655 : ◆0uxK91AxII :2009/01/29(木) 12:44:29
動画のencode云々は、algorithmにもよるから、何とも言えないね。
軽い物程、CPUの外の影響が大きくなり、このスレの趣旨からハズレる。

656 :デフォルトの名無しさん:2009/01/29(木) 12:53:30
フィルタを重ねるほどオンキャッシュ処理の頻度は高くなるね
それでもL1外の読み書きのレイテンシを完全に隠蔽してしまえるような状況は知らない
論理レジスタ32本くらいあっても厳しいのに

657 :デフォルトの名無しさん:2009/01/29(木) 13:22:20
マジレスするとメモリの帯域がネックになってSMTが効果ないケースはありうる。
なおさら命令供給ネックと関係ないが。

658 :デフォルトの名無しさん:2009/01/29(木) 15:23:51
>>656
フィルタ・・・ねぇ。

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

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

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

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

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

660 :,,・´∀`・,,)っ-○◎●:2009/01/29(木) 17:47:47
現実世界に存在してもいない「ぼくの考えた理想のエンコソフト」をもって
HTは遅くなるとか馬鹿なの?死ぬの?

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

661 :デフォルトの名無しさん:2009/01/30(金) 01:29:45
>>638
だからそういう「ケチ臭いこと」をいっている>>542

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

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

662 :デフォルトの名無しさん:2009/01/30(金) 20:55:57
なんでAMDのCPUは熱いの?

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

663 :,,・´∀`・,,)っ-○◎●:2009/01/31(土) 00:26:04
AMDってL1ヒット時のピーク性能を極端に重視する傾向があるよね。
一方Intelは昔からL2の構成にこだわりがあるようで。



664 :デフォルトの名無しさん:2009/01/31(土) 00:47:45
ベンチマーク対策じゃね?

665 :デフォルトの名無しさん:2009/01/31(土) 01:47:28
>>663
ターゲットの違い

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

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

666 :,,・´∀`・,,)っ-○◎●:2009/01/31(土) 01:51:09
いま別に喜ばれてないけど。
逆にAMDのほうがサーバでしか生きられてなくね?

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

667 :デフォルトの名無しさん:2009/01/31(土) 01:59:24
>>665
Hammerは明らかにXeonのシェア切り崩しを狙ってただろうが・・・
大黒柱はずっとOpteronだよ

668 :,,・´∀`・,,)っ-○◎●:2009/01/31(土) 02:12:09
AMDは今後2年間はデスクトップCPU市場見捨ててOpteronのコア数増やす方向らしいよ。


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

670 :デフォルトの名無しさん:2009/01/31(土) 02:40:22
>>668
方向というかそれしか打つ手がないのが実情
コア改良で後れを取ってることが敗因だ

671 :,,・´∀`・,,)っ-○◎●: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にマーケティング上「勝てる」アーキテクチャと、製造キャパの両方を
求めないといけないなんて大変だな。

672 :デフォルトの名無しさん:2009/01/31(土) 03:17:28
>>671
> シェア50%を狙えるだけの生産ラインを確保
これ自体は間違っていなかった(過去形)
ただその後IntelがCoreMAを発売、それを上回る性能のCPUをAMDが用意していなかったことが敗北の要因だ
それから以降はもうグダグダでしかない

673 :,,・´∀`・,,)っ-○◎●:2009/01/31(土) 03:18:06
Nehalemでは、32μOPsだっけ?長い命令を使っても命令フェッチ帯域制限を掻い潜れる
ループバッファのエントリ数は。

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

674 :デフォルトの名無しさん:2009/01/31(土) 04:19:30
>>668
どうやってコアを増やすのだろう。

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

675 :,,・´∀`・,,)っ-○◎●:2009/01/31(土) 05:17:28
AVXプログラミングリファレンス第5版出た
http://software.intel.com/file/10069

676 :デフォルトの名無しさん:2009/01/31(土) 07:53:52
>>674
モノリシック6コアなのでダイサイズは巨大化するようだな。
あとMCMの話は2年前から出ていた。
最近の発表によるとMCMでは12コアと8コアが予定されているらしい。
12コアはそのまま6*2として8コアは (6-2)*2 かな?

677 :デフォルトの名無しさん:2009/01/31(土) 10:09:36
もう液浸の時代かぁ。10年前には想像さえできなかったな。

678 :デフォルトの名無しさん:2009/01/31(土) 16:19:15
GJだが直リンは遠慮しる

679 :デフォルトの名無しさん:2009/01/31(土) 22:10:32
そもそもK8のHTは、MCMのために存在すると言っても過言ではない。
IntelのFSBも、そうだがな。

680 :デフォルトの名無しさん:2009/02/01(日) 16:16:32
そんな主張は初めて聞いた
まあ確かにMulti-Agentが前提のFSBでBlackford(Woodcrest)みたいなPoint-to-Pointってのも不自然な気はしたが
どちらもChip-to-Chipの技術に過ぎないと思うが
あ、HyperTransportはバックプレーンとかにも使われているんだっけ

681 :,,・´∀`・,,)っ-○◎●:2009/03/13(金) 17:37:38
ageんか貴様ら!

682 :デフォルトの名無しさん:2009/03/15(日) 16:23:42
死ね

212 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)