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

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

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

1 :1 ◆.MeromIYCE :2007/01/10(水) 12:32:46
ゆるゆる〜っと実測していきましょう。

過去ログ
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 :1 ◆.MeromIYCE :2007/01/10(水) 12:33:18
関連サイト(日本語)
コピペで動く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 :デフォルトの名無しさん:2007/01/10(水) 14:51:35
          ヽ / /⌒\
         /ヽヽ|/⌒\ii|\
       / /ヾゞ///\\|
       |/   |;;;;;;|/ハ \|
             |;;;;//⌒ヽ
             |;/( ^ω^) >>1おっおっおっ乙枯ー
.           |{ ∪  ∪
             |;;ヾ.,____,ノ
             |;;; |
             |;;;;;|
             |;;;;;|



4 :デフォルトの名無しさん:2007/01/10(水) 16:41:55
>>1
STARGA乙ERS

5 :1 ◆.MeromIYCE :2007/01/11(木) 13:23:52
前スレ埋まりました。

6 :デフォルトの名無しさん:2007/01/11(木) 21:01:08
GJ!

7 :デフォルトの名無しさん:2007/01/12(金) 16:01:16
2ch閉鎖したらどーすんの?


8 :デフォルトの名無しさん:2007/01/13(土) 00:37:09
大原が入稿してからついに一週間経つのにまだ掲載されてないなんて
サボりすぎってレベルじゃねーぞ

9 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/14(日) 02:32:10
珍しいなム板で500KB制限って

ただでさえ長文とソースコードの多いスレだけど

10 :デフォルトの名無しさん:2007/01/14(日) 21:51:15
第189回 Core MicroArchitectureをもうすこし(13)
http://journal.mycom.co.jp/column/sopinion/189/

やっと5日入稿分が来たよ
相変わらずこのスレ見てるな

11 :デフォルトの名無しさん:2007/01/14(日) 22:00:42
このスレとは関係ないけど

> 例えば昨年のComputexでMobile向け新コアの説明がちょっとあったが、Memory Controllerと
> Hyper Transport Linkのみがモバイルに最適化されたという話で、コアそのものはK8L(というか、
> Revision H世代?)と共通になってゆく模様だ。

そのリンク先を見る限りモバイル向けコアはK8Lとは違うように見えるのだが…

12 :デフォルトの名無しさん:2007/01/14(日) 23:17:12
サーバーを意識した設計だがRASは無い

13 :1 ◆.MeromIYCE :2007/01/14(日) 23:38:58
俺はnopは実行ユニット使ってると思っていた。そこで実験。Dothanで。
結果は大体見えるけど、初心忘るべからずってことで生真面目にやってみますね。

ループ回数は1000回、10000回で測定。場合に応じて回数を変化させて傾向を見る。
lp:
and edx,edx
dec eax
jnz lp
これはキッカリ1.5clk/loop。

lp:
xchg eax,eax ; nopと書くのと同じマシン語になる
dec eax ; ここをecxに変えても所要クロックは全く同じ
jnz lp
これは1.56clk/loop程度。なぜちょっとだけ遅いのだ。
nopが遅いってことではなくて、loopが整数クロックでない複雑さが影響している感じ?
もっとも、2clk未満なのでnopとdec eaxに依存関係がないのはわかった。
(ていうかnopを連続させるベンチを見れば、nop同士にも依存関係がないのは明らか)

たぶん、nop命令は同時使用レジスタ数とかのシバリとかも関係ないだろう。
(普通のxchg命令はレイテンシが2clkと遅いので計測からはよくわからなかった)

14 :1 ◆.MeromIYCE :2007/01/14(日) 23:40:26
lp:
nop
nop
mov eax,[esi]
dec ecx
jnz lp
これは2.0clk/loopで回る。

lp:
nop
nop
and eax,eax
dec ecx
jnz lp
こっちは2.6clk/loop。nopがALU(Dothanでは2個)を使っているのがわかる。
1loopでALUを5回使うので、必ず2.5clk以上かかるのだ。

nopは、命令ポインタであるeipの値を1増やす以外何もしない命令だが、
CPU内での扱いで言うと、レイテンシ1・スループット1の命令としてALUを1個使うが、
その他スケジュールなどでの制限事項には引っかからないタチのいい1byte命令、
という感じで、これは他のCPUでも同じじゃないかな。

クロック計測の観点から言えば、「実行する」と表現した方がわかりやすいと思う。
この辺は言葉の問題なので、適宜使い分け。

15 :1 ◆.MeromIYCE :2007/01/17(水) 18:51:26
IA32 x86 JITアセンブラ Xbyak
http://homepage1.nifty.com/herumi/soft/xbyak.html

動的アセンブル。なかなか使いやすそう。
mov(ecx, n); などと関数にしてしまう実装が面白い。

でも、いざ使おうと思うと、何に使ったらいいかわからないな。
自己書き換えよりは安全でスマートな方法だが、
定数部分の自己書き換えの範疇を超えた使い方があれば面白い。

16 :デフォルトの名無しさん:2007/01/17(水) 20:48:36
計算式や正規表現のようなユーザから来る可変な表現からプログラムを生成。

17 :デフォルトの名無しさん:2007/01/18(木) 03:40:29
Cの関数のような表記のアセンブラといえば、CELLのもそうじゃなかったっけ?
#つーか、あれは関数表記のインラインアセンブラなのかも知らんが。

18 :デフォルトの名無しさん:2007/01/18(木) 03:59:06
そりゃIntrinsicsじゃないのか?
ttp://en.wikipedia.org/wiki/Intrinsic_function

VC++のMMX/SSE対応とか。

19 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/18(木) 06:52:49
あれはもともとIntelコンパイラの組み込み関数

CellのはCode WarriorのAltiVec拡張と同じ構文ルールだが
あちらは「演算子」なんだな。
Cで「関数」のオーバーライドはサポートしてないはずだ。
たとえばvec_addもしくはspu_addはvector int とvector shortでは別の操作になる

20 :1 ◆.MeromIYCE :2007/01/18(木) 23:53:42
>>16
正規表現か。難しそうだな。
結局、定数書き換え以上のことやろうとすると、コンパイラみたいなのを
自作してプログラムに入れないといけないんだよな。

ぶっちゃけ定数埋め込みだけでも意義は大きいと思うし、
最後に0.99をかける処理をする/しないの選択みたいな要素が8個あれば
高速化を考えれば普通なら256通りのコードを用意する必要があるわけだから、
そういうのに使ってもいい。

>>17
べつにmov(ecx, n); でmov ecx, n を実行するわけじゃなくて、
将来実行するコードにmov ecx, n のマシン語を追加しているのだ。
単なる表記法の話とは違う。

21 :デフォルトの名無しさん:2007/01/19(金) 00:23:01
>20
callが並べられれば既に最適化されている一連の関数をどういった順序で、ないし、どういったパラメータで呼ぶかが決められる。
比較処理の削減、BTBの節約程度にしかならんがな。

22 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/19(金) 00:53:26
正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ
(言語処理系だとHaskellとかに使われてるね)

現実には後方参照とか量指定とかのリッチな機能使いたがるから
一意に定まる部分文字列をBoyer-Moore法などを用いて先行して評価し
NFAを評価するほうが主流なんだよな
これは鬼車なんかが使ってる。

自己書き換えでNFAのバックトラッキングを高速に処理するとかできれば
理想だけど、まあ無理だ罠。
とにかくメモリレイテンシが重要。

#投機スレッディングが有効かと思ったり

23 :デフォルトの名無しさん:2007/01/21(日) 01:38:34
第190回 Core MicroArchitectureをもうすこし
http://journal.mycom.co.jp/column/sopinion/190/

24 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 03:07:36
> そうなると、そうすると

もちつけwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
最近仕事が粗いな

つーか、リオーダバッファが96エントリもあれば局所的なユニット不足って
十分解消できると思うんだがね俺の考えでは

ROBを深くしてロード命令を先行して実行してれば
たいがいのコードって

つーか、リオーダバッファが96エントリもあれば局所的なロードユニット不足って
十分解消できると思うんだがね
そのためにMemory disambiguationがある。
ストア命令が一個もないループなんぞ【逸】般的でしかない。

64bitではSSE2までは標準命令セットだから、そのへんの実行効率についても
検証していただきたいところだね。

25 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 03:21:32
俺くどいwwwwwwwwwwwwwwwwwwww

26 :デフォルトの名無しさん:2007/01/21(日) 04:13:03
http://journal.mycom.co.jp/column/sopinion/190/

REV.FのDualCore 2MB L2で227.4Mトランジスタ
1MB L2で、153.8Mトランジスタと言われている。

つまり、227.4-153.8=73.6Mトランジスタが、1MB L2の容量と思われる。
2MBだとx2で147.2
227.4-147.2=80.2がL2を除いたトランジスタ数。
41.1Mが1コアあたりのトランジスタ数となる。
ちなみに、512KBのシングルコアは81.1Mと言われているので
81.1-36.8=44.3ほどDualCoreの数値と比べ、少し多いが、
後述するメモコンなどの共用部分は、1コアでも1つ持つので、割とあってるかもしれない。

ここから大原氏のいうL1キャッシュの容量7Mを差し引いて34.1Mトランジスタ
さらにメモコン部分のL2以外のダイ面積に占める割合からすると14%なので、
単純計算で5.75M、これを両コアで共有するため、半分として2.88Mトランジスタ。
34.1-2.875=31.22Mである。

メモコンのトランジスタ数については、前述の数値で言えば、
DualCoreとSingleCoreでコア辺り3.2Mの差があるので、
あたらずも遠からずかな。




27 :デフォルトの名無しさん:2007/01/21(日) 04:15:27
つづき

http://journal.mycom.co.jp/column/sopinion/190/

これと同じことをCore2でやると
Core2 4MB版が291M
Core2 2MB版が167M
であるから、(291-167)*2で248Mトランジスタ
(291-248)/2=21.5M
過去のP6アーキテクチャのくらべると、両コアの共用部分を差し引いても少ないように思う。

その他Core2のキャッシュ計算法から、過去のCPUのトランジスタ数を推定すると
2MBのCoreDuoが、(151.6-124M)/2=13.8M
2MBのドタン,PentiumMが、140-124M=16M
1MBのバニアス,PentiumMが、77M-62M=15M
256KBのPentium3が、28.1M-15.5=12.6M
L2外付けのPentium3が、95M

Penteium4だと
プレセラで(376-248)/2=64M
プレスコットで125-62=63M
割といい感じと言うか、ほぼぴったり!
しかしトランジスタ数がCore2の3倍に達することになるが。

長々と書いたが、半分大原氏に向けて書いたつもり。
ここをみてる様だから。

参考文献
http://www.sandpile.org/index.htm


28 :デフォルトの名無しさん:2007/01/21(日) 07:39:11
大原なんてどうでも良い
もちっと突っ込んだ話に進めよう

29 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 12:48:50
「モノ書くってレベルじゃねーぞ」

30 :デフォルトの名無しさん:2007/01/21(日) 14:47:40
大原氏の検証が正しいどうかかわからないが、Core2のトランジスタ数が少ないのは事実であろう。いずれにせよ、Core2のトランジスタ効率はかなり良い。
K8の60-70%程度の演算パイプライントランジスタ数で、120%の性能を発揮しているのだから。
遡れば、K7 2200万トランジスタに対して、Pen3 950万トランジスタで、クロック当たり性能がほぼ互角だったのだから、AMDのアーキテクチャーには無駄が多いのかもな。

K8のブロック図を見ても
コンプレックスデコーダー*3
対称型ALU*3
AGU*3
馬鹿正直設計と言えるかもしれない。




31 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 15:12:30
その上整数パイプラインとFP/SIMDパイプラインに分かれてる。

32 :デフォルトの名無しさん:2007/01/21(日) 15:26:22
その代わりK8はスレッド数が増えても急激な性能の低下はないね。
Core2はコア数×2スレッド以上になると急に遅くなる。

33 :デフォルトの名無しさん:2007/01/21(日) 15:29:39
ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、
具体的にどれくらい?


34 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 15:34:56
単純に1スレッドだけだと2MB〜4MBのキャッシュを占有できるからじゃないの?

なにが原因があるのかは知らないが
コンテクストスイッチングに弱点があるとして
HyperThreadingとマルチコア化で同時処理スレッド数を稼ぐ方針だから
差し引きオッケーになるんじゃねーの

35 :デフォルトの名無しさん:2007/01/21(日) 15:52:36
Intelの共有キャッシュ = 再構成可能キャッシュ

36 :デフォルトの名無しさん:2007/01/21(日) 15:59:52
そうだね。
黙っててもマルチコア化は進んでいくわけだから、シングルスレッド強化のほうが、むしろ理にかなってるとも言える。
また、1コア当たりのトランジスタ数を抑える方が、コアを増やす上で、これまた理にかなっているだろう。

K8Lは、さらに1コア当たりのトランジスタ数を増やすようであるが、
面積で言えば、20%ほど増える。単純計算では5000万トランジスタぐらいか。
K8 5000万対Core2 2870万で互角以上なら、多少のマイナスも問題ないだろうし、
さらに5000万対2870万 x2コアって戦い方も出来る。


37 :デフォルトの名無しさん:2007/01/21(日) 16:08:42
何言ってんの?K8といえば今やX2だろう。

38 :1 ◆.MeromIYCE :2007/01/21(日) 23:32:22
>>23
4issueのCPUで演算パイプラインが常時IPC4で回るとかあり得ないのは
当然のことだと思うのだが、意図的に間違えてるのか?
そういう意味じゃCore2もK8もIPC3すら全く達成できてない/する気がない。

それとは別に、パイプラインを3→4に強化すれば高速化するのは間違いない。
その高速化に対して、IPC4+のケースがあることも、そうじゃないことも貢献している。
その他色々な強化を積み重ねて、Core2はあのスピードを手に入れたのだ。
K8だってCore2だって、IPCが1.4のところを1.5にしようと必死に頑張って作ったはず。

あと、俺はむしろK8の演算器((ALU+L/S)*3)が過剰でバランスが悪いと感じる。
もっとも、これがK8のパワーの源だとも思うし、実際にはそう悪くないのだろう。
よく言われることだけど、ALUが過剰とかキャッシュだけ多いとかいうのは
設計思想の違いで、どちらが良い悪いというものではない。
バランスが悪いとダメだけど、K8やCore2がそこまでバランスが悪いとは思わない。

ところで、大原さんは別にCore2を貶してるわけじゃないんだよね。
ただ、「Core2は(x86命令で)IPC4を狙った設計ではない」と主張してるだけで、
4issueは無駄だとか、K8より性能が劣るとか、設計が悪いとかは、言ってない。
なぜそう主張したいのかが、さっぱりわからないんだけど。

今度のK8Lは、「より確実にIPC3を出し続けることを狙ったCPU」だと思う。
このK8Lと、「IPC4を狙ってデコード・スケジュールでつまづく」Core2の戦いは楽しみだ。

39 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/21(日) 23:37:33
K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを
K8Lではディスパッチ後にデコードするようになってる。
このへんってどんな効果あるんだろ

40 :1 ◆.MeromIYCE :2007/01/21(日) 23:51:02
>>39
SIMDの方にディスパッチしてから64bit単位で命令を解釈し、
ある程度トランジスタを割いてうまくスケジュールして、
同じピークSIMD性能のCore2を超える実性能を叩き出す、
というのが俺の希望だが、実際どうだろね。
ディスパッチ前の命令の単位が64bitから128bitに変わったことが
影響していると考えていいと思うけど。

41 :デフォルトの名無しさん:2007/01/21(日) 23:54:41
そそ、Intel processorが特別ピーキーで(絶妙な)設計なだよなー(・∀・)
AMDに限らず、RISC processorでも馬鹿正直といったら失礼だけど、大雑把なつくりのがおおいし。

Intel processorは、伝統的に速くなるところはそれだけ投資するし、速くならないところは細部でも積極的にケチる。
社内で実プログラムの動作が研究し尽くされていて、開発能力に余裕がなければできない芸当。
decode BWみたいに局所計測系benchmarkの単調な命令の羅列ではまったく実力がわからん。
Intel processorは、いつも公開されるarchitecture的なspecから予想されるよりも実性能が高い。
これはcompilerの出来だけの問題ではない。

あと、大原はIPCという言葉の使い方がよろしくない。
IPC xxを狙ったarchitectureという考えをそもそも捨て去らないと…。
実効3IPCや4IPCなんて最初から誰も考えちゃいないのに。

42 :デフォルトの名無しさん:2007/01/22(月) 02:02:48
Intelerお久

43 :デフォルトの名無しさん:2007/01/22(月) 03:57:13
どこが優っていて、どこが劣っているとか、
それは最終的には関係なく、結果叩きだされる性能が指標なわけで…

最近のベンチマーク結果にメモリ帯域とか、レイテンシ計測が出てくる不思議さ。
なんというか、100M決勝で10M加速を比べられているような…
IPCもその意味をなすことが今後は難しいんじゃないですかね?

大原記事はこれから読むw

44 :デフォルトの名無しさん:2007/01/22(月) 04:25:04
読んだ。
AMDのCPUは実行IPC3で常に回っていて(脳内or観測的希望)
intelのCPUはIPC4を謳ってい入るがそんなわけねーよ(AMD比)pgr、ということなのか…

瞬間風速だとしても、それを出せない回路でその数字を謳うのはある種詐欺なわけで、
たとえ一瞬だとしてもそれが出せることは大いに喜ぶべきことなのでは?
(その宣伝を気に入る、気に入らないという話ではないこと前提でw)
それを意識するあまり平均性能が落ちるとかならいざ知らず、
ほとんどのベンチマークで勝っているわけで、without メモリコントローラ。

45 :デフォルトの名無しさん:2007/01/22(月) 10:40:18
おはようございます。
なんだよ、観測的希望ってw
やっぱり眠い時レスしちゃダメなんですね。
大原氏ごめんね。

46 :1 ◆.MeromIYCE :2007/01/22(月) 14:20:45
>>43
論旨には賛同するが、メモリ帯域やレイテンシ計測は是非やって欲しいよ。
もちろん、そういう計測をそのままCPUの性能と思ってしまうのは論外だが、
「自分はこの処理をさせたいが、どのCPUがいいだろう?」と思ったときに
一般アプリの実性能ベンチだけではイマイチ検討のしようがない。

まあ、こういうのは最近の流行りじゃないんだろうねぇ。
確かに俺も、とりあえず帯域ベンチやっときましたみたいな記事を見ると、
色々誤解が広まりそうで嫌な感じはする。

47 :デフォルトの名無しさん:2007/01/22(月) 17:20:36
CPUの性能を調べることと素性を調べることの差って感じか

48 :デフォルトの名無しさん:2007/01/22(月) 17:55:49
周波数特性だけで盲目的に音質を語るな

49 :1 ◆.MeromIYCE :2007/01/22(月) 19:03:17
>>47
そうだね。
あと、ベンチって結果から製品を選ぶのが目的と見せかけて
むしろ好奇心を満たすものという面が大きい。
性能より素性を知りたい人が少ないってのが寂しい。

>>48
そういう意味じゃ、CPUは速いのが正義だから、まだ簡単だ。
MP3とACCの比較とか、ありゃあ泥沼になるわけだ。

50 :デフォルトの名無しさん:2007/01/22(月) 19:32:31
マルチコアはいつから使えるコアになるのか?
http://www.ne.jp/asahi/comp/tarusan/main155.htm

51 :1 ◆.MeromIYCE :2007/01/22(月) 20:12:17
>>50
実際にどっちを買うべきかという話ではなくて、CPUメーカーがシングルコア路線を続けた方が
動画エンコしない一般ユーザーは(今までは)幸せだったんじゃないかという話だね。

結局、俺は使ったことがないからわからないんだよな。
それに、Pen4からCore2Duoに乗り換えた人は、
Coreアーキだから速いのか、デュアルコアだから速いのか、Pen4が遅かっただけなのか、
何が原因だか容易には知ることができないだろう。

俺は前から、体感したYonahの速さからデュアルコアをすすめる人の多くが、
CoreSoloでも同じ速さを感じるのではないかと思っていたが、これも確かめるのが難しい。

一方、Intelとすれば、シングルでも非常に高速なYonahやConroeで
デュアルコアをスタートさせたため、商売としては成功したと言えるだろう。
(いや、ネトバのデュアルはスタート以前というか・・・それでもエンコは強かった)

52 :デフォルトの名無しさん:2007/01/22(月) 20:47:04
>CPUメーカーがシングルコア路線を続けた方が動画エンコしない一般ユーザーは(今までは)幸せだったんじゃないかという話

IntelはメニーコアのマイルストーンとしてAdaptability(適応性)ってのを挙げてる。
シングルコア強化路線「だけ」ではムーアの法則に追随できないから、
まず前提としてシングルスレッド性能の強化があって、
その開発期間の隙間を埋めるのがコアの増加なんだと思う。
例えばDMTなんか65nmに微細化した今でも実装されてないし。

53 :1 ◆.MeromIYCE :2007/01/22(月) 21:27:29
>>52
AdaptabilityやDMTの意味がわからないが、
前提となるコストと熱設計の中で最も性能の高いものを作るだけじゃないの?
開発期間の隙間と言っても、開発が済んだらコアを減らすわけでもないだろうし。

54 :デフォルトの名無しさん:2007/01/23(火) 01:46:26
Speculative MultiThreadingによってILPの壁を突き破れるようになるまで
シングル、マルチを無駄に意識させられるんだと思われ。
ILPを挙げるのに、これ以上トランジスタと電力に投資するのが非効率だから
TLPを意識しましょうっていうのは実際逃げだろうけど、
タイタニックじゃないけど、逃げなきゃいけない状況(それ以上の解が見つからない状況)なのに
意固地に頑張る必要もないはず。
メモリレイテンシの隠蔽の効果が、めいっぱい頑張ったシングルコアを超えずとも
良い勝負かつ、より低消費電力ならそっちが正解だと思う。

そういう点から、例え現状しょうがなく目指したとしても、
むこうに今よりもbetterな解があるならそれで良いジャマイカ派。

55 :デフォルトの名無しさん:2007/01/23(火) 02:29:49
SpMTが高めるのはMLPだ。
"ILPの壁を突き破る"という表現はおかしい。

56 :デフォルトの名無しさん:2007/01/23(火) 04:35:11
ILPという言葉に関しては、一つのスレッドに対して使う言葉なのかな。
並列性の高まるスレッドが別であることに対しては無効であるなら認識不足だった。
勉強になります。

ttp://ja.wikipedia.org/wiki/ILP
これ読む限りじゃ、投機実行もILPを高める手法の一つにはカウントされてる模様。

57 :1 ◆.MeromIYCE :2007/01/23(火) 16:12:57
>>56
> Speculative MultiThreadingによってILPの壁を突き破れるようになる
の「ILPの壁」というのは、「シングルスレッド処理のIPC向上の壁」と言えばいいんじゃない?
ILPと言うと、メモリ以外の命令同士の依存関係を何とかするみたいな感じを受けるから。
#メモリアクセスもI(命令)だと言われればそうだけど。

俺は、メモリ以外のILPの問題の方が本質的だと思うので、ここではILPという言葉は使わない。
手動でプリフェッチすれば同等の性能が出るであろう技術には個人的に萌えない。

しかし、SpMTによって、手動でprefetch命令を入れたのに匹敵する効果が得られるなら、
これこそプログラマに優しい、「逃げない」技術なのかもしれないとも思った。

> 投機実行
それは、文脈からして条件分岐命令に対する投機実行のことだから、
投機的マルチスレッディングとは関係ないと思われる。

>>54
逃げなきゃいけない状況なら逃げないといけないね。
何事もバランス、中庸。
>>53ではああ言ったが、最後の2行は同意。単純に対応ソフトの普及促進にもなるし。

58 :デフォルトの名無しさん:2007/01/23(火) 19:59:29
AMD Rev.F Processor には、RDTSCPという命令が追加されているらしいな
ttp://www.atmarkit.co.jp/flinux/rensai/watch2006/watch07a.html

59 :デフォルトの名無しさん:2007/01/27(土) 19:25:36
>>27
http://journal.mycom.co.jp/articles/2005/07/14/yonah/002.html

Coppermine 1394万
Banias 2038万
Dothan 2676万
Yonah 1918+1918万

60 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/27(土) 21:07:17
大腹自身の記事かよw

61 :デフォルトの名無しさん:2007/01/28(日) 00:54:47
>>59
それは読んだよ。

しかし、大原氏の計算方式だと、、同じコアのキャッシュ容量違いで、コアトランジスタの数が変わる理由が説明できない。

たとえば、X2の512KBと、1MB版は
512KB 15380万個 1MB 22740万個だが
コアトランジスタの数は
512KB 5708万個 1MB 4859万個となり、900万個の差が説明できない。

あと、K8の場合、24KBのプリデコードビットもキャッシュ量として計算すべきじゃないか?とか思ったり

で、整合性を持たせた結果、個人的に”こんなものか”とはじき出した数字がこれくらい。
初代 K7 1360万
初代 K8 1770万
90nm K8 2660万
Rev.F K8 DualCore 2870万
Rev.F K8 SingleCore 2990万
Pentium3  773万
PentiumM (130nm) 1146万
PentiumM (90nm) 1246万
CoreDuo 1326万
Core2 Duo 2096万

過去のCPUの傾向から言うと
1バイトあたりのトランジスタ数はK8が約70個、PentiumMが約60個という傾向も見えてきた。
なかには40個台のもあるが、これでは6トランジスタでは作れないので、(6トランジスタで作るには、最低54個必要)、4トランジスタで作っているか、公式発表の数字がうそか、どちらかだろう。



62 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/28(日) 01:05:20
Pentium Mは4トランジスタじゃなかったっけ

ってソースがこれだったwwww
http://journal.mycom.co.jp/special/2004/dothan/001.html

大原氏は記事書く際はちゃんとウラを取って欲しいな

63 :デフォルトの名無しさん:2007/01/28(日) 16:02:55
まあ大原もここのスレ住人も、ほとんどが確たるウラをとらずに好き
放題発言しているだけだけどな。50歩100歩じゃねーか?

ソースを張っても、そのソースが本当に正しいかウラが取れてるわけ
じゃない場合が多いし。ソースが大原記事なんてのがその典型w

64 :デフォルトの名無しさん:2007/01/28(日) 17:27:01
PenMが4トランジスタSRAMってのは間違い。
大原自身が訂正してたよ。
6トランジスタです。

65 :デフォルトの名無しさん:2007/01/28(日) 17:29:57
そろそろclock計測の話題に戻ろうよ。
ここは実験と実証のスレで、理屈と情報、妄想だけのスレなんて他所にたくさんあるわけだし。

66 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/28(日) 18:13:52
素人が個人ブログや掲示板に自己満足記事投稿するのと
企業から金貰って大衆に読んで貰うための記事をかくのと
全然影響力・説得力が違うがね。

67 :デフォルトの名無しさん:2007/01/28(日) 18:36:11
クロック数計測してもTr数はわからんし。

――大事なのは素材ではなくその精神なのです。

68 :デフォルトの名無しさん:2007/01/28(日) 18:49:20
>>66
大企業メディアの情報の質、正確性、量、速度が
個人サイトの集合を上回っているとはいえなくなりつつある
ネット社会の現代、こういうライター稼業のなんてもう流行らないのかも。

しかし、それにしても国内のハードウエアレビューは質が低い。
AnandTechやTom's, INQなどは個人サイトが反映しても死ぬ気がしないんだけど、
国内ではそのような優良サイトがない。情報も一方的だし、ライターの記事は情報が少なく、遅い。

69 :デフォルトの名無しさん:2007/01/28(日) 22:35:46
この計算はあってるの?

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2915&p=3
If we assume that 288M transistors (6T SRAM) will be used by the 6MB cache,
that leaves 122M transistors for L1 cache and the rest of the core.
Applying the same calculation to Conroe gives us 99M transistors left over,
meaning that there are roughly 23% more core-logic,
control and L1 transistors being used in Penryn than in Conroe.

70 :デフォルトの名無しさん:2007/01/28(日) 23:07:10
第191回 Core MicroArchitectureをもうすこし(15)
http://journal.mycom.co.jp/column/sopinion/191/

71 :デフォルトの名無しさん:2007/01/29(月) 02:38:23
>>70
なんかどうみても、これスレを読んでいて、且つこのスレに対して
言い訳してるようにしか読めないな。

大原氏には悪いけど。

72 :デフォルトの名無しさん:2007/01/29(月) 02:50:03
>>70
話の持っていきかたの無理矢理感が・・・・・

73 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/29(月) 02:59:02
どんな下手な書き方してもIPC=3を出せるハードという意味なら永久に無理に決まってる。
ソフト側も「IPC=3を出せるコード」であることが前提。

74 :デフォルトの名無しさん:2007/01/29(月) 03:14:52
そこでEPIC

75 :・∀・)っ-○◎● ◆DanGorION6 :2007/01/29(月) 03:45:05
4IPCを狙ったアーキじゃないって論は云々はどっちかというと
この人の記事を読んで真に受けただけじゃなかろうか
http://www.ne.jp/asahi/comp/tarusan/main147.htm

別に ALU+Load, ALU, ALU, Store
もしくは ALU, ALU, ALU, Load or Store
でもx86換算4命令になるわけだがな。
インオーダで実行するわけじゃないんだから、3IPC以上出せないというのは
大きな間違いだよね。

従来のアーキテクチャではストア命令が来る度に、格納先が確定するまで
後続のロードとそれに依存する命令を発行できないという縛りがあるわけで、
レジスタが少なくロードストア頻度の高いx86でIPC=3を実現する上で大きな縛りになってる。
Core 2で導入されたMemory Disambiguationはそのへんを解決してる。

大原氏はCore 2で平均IPCを引き上げるためのその辺の機構を正当に見てない希ガス。

安藤壽茂氏なんかの記事はちゃんとそのへんも触れてる。

76 :Store forwarding:2007/01/29(月) 06:45:21
キャッシュラインサイズが256Bというのもその辺考えてるのかもな。


77 :デフォルトの名無しさん:2007/01/29(月) 17:55:37
>>76
キャッシュラインサイズが256Bって何?

78 :デフォルトの名無しさん:2007/01/29(月) 20:47:10
P6,Netburstでは、unknown store-addressがあってもそれ以降の別のストアはアドレス計算できれば発行可能。
またunknown load-addressがあってもそれ以降の(アドレス計算可能な)ロードやストアは発行可能。
唯一できなかったパターンがunknown store-address以降の(アドレス計算可能な)ロード発行で、
これはCore 2で可能になった。

これに対してK7,K8では、unknown store-addresがあるとそれ以降のロードやストアは発行できない。
またunknown load-addressがあってもそれ以降のロードやストアを発行できない。
ロードやストアのAGU命令はインオーダー発行になっているようだ。
K8Lでロードのアウトオブオーダー発行が実装されるが、
どの程度のアウトオブオーダーなのか、またそれによってどの程度性能が向上するのか、
楽しみではある。

計測情報源:http://www.realworldtech.com/forums/index.cfm?action=detail&id=73407&threadid=73407&roomid=11

79 :デフォルトの名無しさん:2007/01/30(火) 05:36:05
今回のは何を言いたいのかさっぱい伝わってこないのだが…
これなら昔の電波の方がよっぽど読み応えがあったw

80 :デフォルトの名無しさん:2007/01/31(水) 20:10:09
http://pc.watch.impress.co.jp/docs/2007/0131/ubiq170.htm
これらのプロセッサでは、Coreマイクロアーキテクチャとしては初めて
Hyper-Threading Technology(HTテクノロジ)をサポートすることになる

81 :デフォルトの名無しさん:2007/01/31(水) 22:45:47
Penryn does not have HT
http://www.theinquirer.net/default.aspx?article=37316

82 :デフォルトの名無しさん:2007/02/01(木) 02:07:56
http://grape.astron.s.u-tokyo.ac.jp/~makino/journal/journal-2007-01.html#30
むーん、オールジャパンってそういう話か、というか、それはそうなん だけど、そんなので計算機作れるのかよ、、、

83 :デフォルトの名無しさん:2007/02/01(木) 04:32:35
Vista 64bit版も出た事だし、そろそろx86-64の話題が欲しいですね。
スレ違いか?

84 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/04(日) 15:21:39
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2915&p=3

Penrynはdual coreだ。そしてquad coreはただそれらを二つパッケージに封入しただけだ。
ただ、あとからシングルダイの製品が登場するかもしれない。
トランジスタ数が4億1000万なので、Penrynが6MBの共有L2 cacheを持つと予想できる。
Penrynのロジック部はConroeの進化形になるだろう。
キャッシュの増量分以上の機能的・性能的追加が期待できる。

2億8800万トランジスタが6T-SRAMの共有L2キャッシュに利用されているとすれば
残り1億2200万トランジスタはL1キャッシュとコアに費やされていることになる。
同じ計算をConroeに適用すると、9千9百万のトランジスタがコアとL1 cacheに割り当てられている。
これらの事実はPenrynではConroeと比較して23%多いトランジスタがL1 cache, 論理, 制御に
使用されるのを意味する。

追加される機能が不明である現時点でさえ、SSE4のサポートがそれらのトランジスタの
かなりの部分を占めると予想するだろう。またIntelが45nmでクロックを上げるので
Penrynが3GHzよりも高いクロックで登場するのを容易に予想できる。
Conroeのオーバークロック耐性を考えると、Penrynのクロックが非常に良いのを見ても
そんなに驚かないだろう。

85 :デフォルトの名無しさん:2007/02/04(日) 22:47:06
第192回 Core MicroArchitectureをもうすこし(16)
http://journal.mycom.co.jp/column/sopinion/192/

86 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/04(日) 22:57:40

  ま た 2 ち ゃ ん ソ ー ス か



87 :デフォルトの名無しさん:2007/02/04(日) 23:13:12
> Penrynの世代でHyper-Threadingが搭載されるという。

( ´д)ヒソ(´д`)ヒソ(д` )ヒソ

88 :デフォルトの名無しさん:2007/02/05(月) 00:31:26
今回のこれは大原を弄るのは酷かもな…
ネタの正確性はともかく言ってること自体は間違ってないというか、同意できる
つーかYorkfieldの中身が変更されたと判明した後もガセネタ流し続けたCharlie Demerjianは死ねw

89 :デフォルトの名無しさん:2007/02/05(月) 01:17:24
409 :名称未設定 :2007/02/02(金) 17:22:28 ID:I0BGTsMO0
http://journal.mycom.co.jp/news/2007/02/02/400.html
http://journal.mycom.co.jp/photo/news/2007/02/02/Photo10l.jpg

生ハムメロンワロスw

90 :デフォルトの名無しさん:2007/02/05(月) 01:42:10
つーか、なんか論点がずれてるというか、大雑把な主張になってきたな。
もともとIPC=3を技術的に細かく検証しているはずだった気がするが、
いつのまにか
「発熱や消費電力が上がる関係でIPC=3は無理です」
になってる。

なら最初からそう言って終わっとけば良かった気がするが…

91 :デフォルトの名無しさん:2007/02/05(月) 01:59:27
このシリーズはいつまで続くんじゃー!

92 :デフォルトの名無しさん:2007/02/05(月) 02:05:06
Core2がIPC=4じゃないとする主張の理由の中に
K8がIPC=3であると思わせる部分がある時点で
大原記事wwwとなるのは明白。

93 :デフォルトの名無しさん:2007/02/05(月) 04:56:57
元々はCoreMAとK8のIPC向上に対するアプローチの違いを言いたかったような気がするが。
細かく突っ込んでいって逆に全体像が見えなくなった感じだな。

94 :1 ◆.MeromIYCE :2007/02/05(月) 19:11:14
>>89
Meromと果物のmelonをかけてるのだろうか?

Penrynに、L2キャッシュ増量とSSE4実装以外の目立った改善があるのか気になるね。
遅くなるプリフィックスと64bitでのマクロフュージョン、シャッフル系SSE命令などが考えられる。
まあ、このうち1つも対応されない可能性も大きいとは思うが。
命令フェッチ幅を32byteにするのはいずれ必要だけど、Penrynの次のアーキ辺りが妥当か。

95 :デフォルトの名無しさん:2007/02/05(月) 19:14:56
Windows生ハム

96 :デフォルトの名無しさん:2007/02/05(月) 22:51:33
AMDの方は L3キャッシュだろ。もうどうなる事やら。

97 :デフォルトの名無しさん:2007/02/06(火) 00:03:52
トランジスタ増やしすぎたらいくら微細化してるとしても
クロック上げるのも難しいと思うのですよねぇ

98 :デフォルトの名無しさん:2007/02/06(火) 02:25:15
そういえばK8LのL3は面積からしてZ-RAMじゃないな
大原妄想乙でした

99 :1 ◆.MeromIYCE :2007/02/06(火) 07:04:51
初代スレの398でやったdivのレイテンシ測定をするプログラムを作ったので、
色々なCPUで試してみてくださいまし。
http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=divclk.zip&refer=Upload

Dothanでの結果は、こんな感じ。
除数大↓ 被除数大→
15 23 39 39 39 - - -
15 15 23 39 39 39 - -
15 15 23 23 39 39 39 -
15 15 23 23 39 39 39 39

>>95
Windows生ハムの遅さを高速なmelonプロセッサがおおまかカバー、
melonプロセッサがWindows生ハムの素晴らしい機能を引き出す、
ってか。
いや、Vistaの話じゃないですよ。

100 :デフォルトの名無しさん:2007/02/06(火) 10:43:10
Opteron146(Socket939 core=Venus)の結果をば。
除数大↓ 被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40

101 :デフォルトの名無しさん:2007/02/06(火) 11:53:40
Pentium 4 630 Prescott 90 nm
CPUID F.4.3

除数大↓ 被除数大→
68 68 67 68 68 - - -
69 71 67 68 69 69 - -
69 69 69 69 70 68 70 -
69 69 70 73 71 71 69 69

102 :デフォルトの名無しさん:2007/02/06(火) 13:10:50
Pentium 4 631 CedarMill 65nm
CPUID F.6.5

除数大↓ 被除数大→
84 88 88 87 87 - - -
88 88 88 88 88 87 - -
87 88 87 87 87 87 88 -
87 87 87 87 88 87 88 88


103 :デフォルトの名無しさん:2007/02/06(火) 13:42:24
Athlon XP-M 1800+ Thoroughbred Low Power
除数大↓ 被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41


K6-2 400MHz Chomper Extended
除数大↓ 被除数大→
19 19 19 19 19 - - -
19 19 19 19 19 19 - -
19 19 19 19 19 19 19 -
19 19 19 19 19 19 19 19


104 :デフォルトの名無しさん:2007/02/06(火) 15:07:00
動かしてみるに吝かではないのだけれど、CPUの情報もプログラムで拾って表示してくれると便利だと思う。
それと、Linux版が欲しいとか贅沢も言ってみる。

ってことで、手元のCeleron 2GHz(という以外判らない)
除数大↓ 被除数大→
51 51 51 51 51 - - -
51 51 51 51 51 51 - -
51 51 51 51 51 51 51 -
51 51 51 51 51 51 51 51


105 :デフォルトの名無しさん:2007/02/06(火) 17:56:32
Celeron 1.7GHz(Willamette-128K)

除数大↓ 被除数大→
50 50 50 50 50 - - - 
50 50 50 50 50 50 - - 
50 50 50 50 50 50 50 - 
50 50 50 50 50 50 50 50 

106 :デフォルトの名無しさん:2007/02/06(火) 18:00:28
Opteron144(Venus)だけど>>100と同じ結果

107 :デフォルトの名無しさん:2007/02/06(火) 18:19:44
Pentium II

除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39


108 :デフォルトの名無しさん:2007/02/06(火) 18:23:44
Conroe

除数大↓ 被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41


109 :1 ◆.MeromIYCE :2007/02/06(火) 22:02:53
みなさんありがとう。
小さい数の割り算だと速くなるのはPenM〜Core2だけみたいだね。
Pen4はステッピングが進むにつれて遅くなってくなあ。これがネトバだよな。好きだ。
K7/K8が、PenMの遅いところと同等程度。意外と速くないが、整数はこんなものか。
K6-2は低クロックとはいえさすが。今にして思えば味のある石だった。
PenIIがPenMと似た数字なのが面白い。PenMも地味にいい改良してるよなあ。

>>104
↓こういうのを表示できるようにして、後でアップします。
GenuineIntel Family:6 Model:D Stepping:6

Linuxは誰かにコンパイルしてもらいたいが、それにしてもVC++のインラインアセンブラはまずい。
アセンブラ部をNASM用にすることは可能だと思うので、ちょっと挑戦してみる。

>>108
あれ!?ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。
PenMの改善点を洗練させた感じだ。
基本的に被除数が32bitに収まる場合を高速化してるみたいだな。

Yonahのときに、割り算が速くなるという話があったが、Core2も同じか?
持ってる人Yonahの測定お願いします。

110 :デフォルトの名無しさん:2007/02/06(火) 22:05:10
YonahとBaniasの計測がほしいね。それで完璧。

111 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/06(火) 22:41:06
GCCなら-masm=intelオプションでほぼそのまんま移植できた希ガス


112 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/06(火) 22:42:54
ほれPentium M(Banias)

除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

113 :1 ◆.MeromIYCE :2007/02/06(火) 22:50:46
>>112
マジで!!!??

114 :デフォルトの名無しさん:2007/02/06(火) 22:52:44
今までの計測結果を見ると、
Banias->Dothanで大きな除算の改良が入ったように見える。
除数によって大きくlatencyが変化しているのはConroeのみなので、
もしかすると、Yonahから除数側の改良が入ったのかも知れず。
Yonahの計測結果マダー??

115 :デフォルトの名無しさん:2007/02/06(火) 23:13:16
いや、除数側の改良もDothanからか。
Yonahでの発表は厳密にはウソってことでFA?

116 :デフォルトの名無しさん:2007/02/06(火) 23:19:49
AMDFAM10について考察希望
http://pc9.2ch.net/test/read.cgi/jisaku/1167003467/557,558,606-609,644-646

最新版はsvnで
svn co svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i386


117 :1 ◆.MeromIYCE :2007/02/06(火) 23:26:08
>>99の測定は、下のコードと、そこからdiv ebxを抜かしたコードとの
差をdiv命令のレイテンシとしている。
lp:
add eax,xa ; xa,xdはメモリ
mov edx,xd ; 被除数は毎回破壊されるので毎回読み込む
div ebx
mov esi,eax ; レジスタをクリアして、かつ依存関係を保たせるあがき
neg eax
add eax,esi
dec ecx
jnz lp

いちおうPenMでは正しい結果を出してると思うけど(以前の測定でも散々追試してるし)、
ループ処理がそれなりに重いのでCPUによっては微妙かもしれないと不安になってきた。
もう少しいい処理・わかりやすいループのアイデアある?
まず、ループをアンロールというのはやろうと思う。

118 :1 ◆.MeromIYCE :2007/02/06(火) 23:50:27
>>115
いや、Yonahの発表からすると、Yonahの時点でCore2の速さだったんじゃない?
どうも新しいCPUはレイテンシが微増する傾向があるみたいなので、
Yonah(PenMと同じ世代)がCore2(新しい)より速いということも考えられる。
>>108を見ると、PenMを改良したものからピッタリ2clk遅くなっている感じだ。

>>116
コンパイラの対応からK8Lの特徴を読み取ろうというのか。
costを見ればいいのかな。コンパイラに必要な情報というのはいい情報かも。。

119 :デフォルトの名無しさん:2007/02/07(水) 01:43:41
Merom T5600
除数大↓ 被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41

Pentium M 1.40GHz
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Athlon 64 X2 4800
除数大↓ 被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40

Sempron 3000+(Socket A)
除数大↓ 被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41


120 :デフォルトの名無しさん:2007/02/07(水) 06:02:45
>>109
> あれ!?ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。

C1E等でクロック倍率が下がっている時でも
FSB1カウントにつきTSCは最高クロック倍率(
E6600なら9)ずつカウントアップする仕様みたい。
どんな時でもrdtscを2回実行すると、その差は必ず
(E6600の場合)9の倍数になる。

2コアでほぼ同時にrdtscを実行すると2コアともほぼ近い値が返ってきたが、
MBのBIOSをアップデートしたら、2コアで全く異なる値が返るようになってしまった。
その後、WinXPのデュアルコアパッチを入れたら2コアでほぼ近い値が返るようになった。

121 :1 ◆.MeromIYCE :2007/02/07(水) 08:09:24
>>120
なるほど!数字としては今までと同じで、精度がコアの倍率分だけ悪くなっているのか。
2コアで同じ時計を持てるのは嬉しいが、やはりクロック単位の測定にはちょっと痛いな。

カウンタはどこにあるのだろう?
マザーボードのBIOSで影響するということはCPUの外だとも思えるが、
それだと2コアで異なる値が返ることがあるという現象に説明がつかない。
カウンタはコア毎にあって、CPUが起動するときに合わせるのかな?

>>99
CPUIDを表示するのと、>>117で言ったアンロール(2回)をやったのをアップし直した。
アドレスは同じ。

122 :デフォルトの名無しさん:2007/02/07(水) 08:39:01
Core Duo T2400 1.83GHz
除数大↓ 被除数大→
14 22 30 38 38 - - -
7 14 22 30 38 38 - -
7 7 14 22 38 38 38 -
7 7 7 14 38 38 38 38


123 :122:2007/02/07(水) 08:45:22
更新されてたの気づかなかった
同じ環境

GenuineIntel Family:8 Model:E Stepping:6
除数大↓ 被除数大→
15 23 31 39 39 - - -
8 15 23 31 39 39 - -
8 8 15 23 39 39 39 -
8 8 8 15 39 39 39 39


124 :デフォルトの名無しさん:2007/02/07(水) 11:35:52
>>100を本日アップ分で再計測

AuthenticAMD Family:1 Model:7 Stepping:F
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

125 :・∀・)っ-{}@{}@{}@ ◆DanGorION6 :2007/02/07(水) 13:10:10
ソース読んだ
FamilyとStepping逆じゃね?

126 :デフォルトの名無しさん:2007/02/07(水) 13:18:45
Core 2 Duo E6300

GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
20 30 39 48 48 - - -
12 20 30 39 48 48 - -
12 12 20 30 48 48 48 -
12 12 12 20 48 48 48 48


127 :デフォルトの名無しさん:2007/02/07(水) 15:33:54
>>126 この結果ってCPUのクロック倍率が落ちた状態じゃないかな?
EISTやC1Eで自動的にクロック倍率が落ちるので、
FSB同期のrdtscでクロック数を計測するのはいろいろと面倒かも。

128 :デフォルトの名無しさん:2007/02/07(水) 17:56:51
Merom T5600
GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
18 26 34 42 42 - - -
11 18 26 34 42 42 - -
11 11 18 26 42 42 42 -
11 11 11 18 42 42 42 42

PentiumM 1.4GHz
GenuineIntel Family:5 Model:9 Stepping:6
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Athlon 64 X2 4800
AuthenticAMD Family:2 Model:3 Stepping:F
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

Sempron 3000+
AuthenticAMD Family:0 Model:A Stepping:6
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39


129 :デフォルトの名無しさん:2007/02/07(水) 21:51:56
>>103再計測。やっぱFamilyとStepping逆だね。
AuthenticAMD Family:6 Model:8 Stepping:1
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

AuthenticAMD Family:5 Model:8 Stepping:C
除数大↓ 被除数大→
18 18 18 18 18 - - -
18 18 18 18 18 18 - -
18 18 18 18 18 18 18 -
18 18 18 18 18 18 18 18

130 :デフォルトの名無しさん:2007/02/07(水) 22:33:58
GenuineIntel Family:6 Model:8 Stepping:6
除数大↓ 被除数大→
38 38 38 38 38 - - -
38 38 38 38 38 38 - -
38 38 38 38 38 38 38 -
38 38 38 38 38 38 38 38


131 :1 ◆.MeromIYCE :2007/02/08(木) 00:02:01
>>123
二度手間ごめん。しかも結果違うorz
おそらく>123の方が正解。
これで、Core2のdivはYonahを2clk遅くしたものだとわかった。
Banias→荒削りのDothan→完成形のYonah→Meromの変化が面白い。

>>124>>129
これも結果が異なるのか。やはり測定法に問題ありだな。
>>123>>130とは逆にクロック数が減っているが、ALUパワーの差、かな。
K6-2も(当時としては)ALUが強い。対してP6系は総合的に速い割にALUは弱い。
2つのループの差からクロック数を求めているため、div以外の特徴も混ざってしまう。。

>>125
うあ〜!俺のDothanはFamilyとSteppingが同じだから気がつかなかったよ。
指摘サンクス。後でこっそり修正しておきます。

>>127
確かに>126は2割、>128は1割だけクロック数が増えているな。
CPUのクロックが落ちても(今までのCPUと違って)rdtscのクロックは変わらないということか。
ただ、誤差が1〜2割というのはSpeedStepにしては少ない感じがする。
ある程度のタイミングで補正はしてくるのか?

測定した人たちへ:毎度ヘボプログラムでごめんなさい。

132 :1 ◆.MeromIYCE :2007/02/08(木) 00:40:35
>>128のMeromってよく見たら>>108の1clk増しじゃん。。

ここ見たらCore2のレイテンシは18〜42clk(>>128と同じ)と書いてあるのだが、
http://www.agner.org/optimize/
こっちを見ると17clk(>>108と同じ)と書いてあり、
http://aceshardware.com/forums/read_post.jsp?id=120057200&forumid=1
マジでどっちが正しいのかわからない。

133 :デフォルトの名無しさん:2007/02/08(木) 02:58:10
>>126-127 >>131
EIST と C1E を切って測定してみました。

GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
18 26 34 42 42 - - -
11 18 26 34 42 42 - -
11 11 18 26 42 42 42 -
11 11 11 18 42 42 42 42


134 :1 ◆.MeromIYCE :2007/02/08(木) 20:40:15
>>133
順当な結果ですね。

単純にedx=0, eax=1, ebx=1としてdiv ebxを連続実行すれば
1÷1のレイテンシが求まるから、それを基準にすればいいかな。
でも、大体結果は出ているし、またバグ出すと嫌なので
ここらで手を引きます。


後藤弘茂によると、ノート用Core 2 ExtremeはIDAナシのようだ。
こういうところからIDAの思想が若干見えるか?

135 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/08(木) 21:32:04
YorkfieldでHTが有効ってことになると、Nehalemがトレースキャッシュ型
アーキテクチャであるという仮説の有力性は揺らぐね。
トレースキャッシュはHTの必須条件だと思ってたが違うってことになるわけだし。

フェッチ・プリデコード帯域を倍にして交互にデコードすれば従来アーキでもいける?

136 :デフォルトの名無しさん:2007/02/09(金) 01:18:43
SMTの実装にトレースキャッシュが必須ってこたないでしょ。
Power5なんかはx86と比べるとデコーダ負荷が低いとはいえ、普通のキャッシュのままSMTやってるし。

137 :デフォルトの名無しさん:2007/02/09(金) 01:55:15
>>135
命令の切り出しの方がネックじゃなかったっけ?

138 :デフォルトの名無しさん:2007/02/09(金) 01:59:28
>>134
多分 HTT有効だと一部のアプリの性能が低下する ってのと同じ問題が起きるよなあ
厳密には IDAがあるのに上手く活かされずシングルスレッド性能が向上しない だけど

至極真っ当且つナイスな技術なのにソフトウェアが台無しにするという。。。
ユーザーがHALT命令を制御できればなあー
将来的にはハイエンドサーバーみたいにCPUパーティションの動的な変更もできる様になると尚良し

139 :デフォルトの名無しさん:2007/02/10(土) 13:49:18
>>138
HLTをユーザモードに解放するメリットは何?
計測目的ならDOSとかRING0で計測すればいいだけだし、
OSスケジューラの都合ならHLTでコアを止めるよりもsleepしてOSに任せたほうがいいし。

140 :デフォルトの名無しさん:2007/02/12(月) 04:32:58
ttp://journal.mycom.co.jp/column/sopinion/193/


141 :デフォルトの名無しさん:2007/02/12(月) 07:17:18
PentiumってOutOfOrderだったっけ?

142 :デフォルトの名無しさん:2007/02/12(月) 19:30:56
P5はインオーダー

143 :デフォルトの名無しさん:2007/02/12(月) 20:51:15
http://pc.watch.impress.co.jp/docs/2005/1130/kaigai228.htm
>P5では、5ステージのパイプラインで、最大2命令を並列実行していた。
>次のP6では、最大3個のx86命令をuOPsに変換し、アウトオブオーダ実行。
P5でスーパースカラを初実装。
P6でアウトオブオーダを初実装。
だな。

つーかそもそもスーパースカラとアウトオブオーダは別系統の技術だった
と思うけど(まあセットで実装されることが多いが)、大原は混同してないか?

>筆者のテクニカルライターとしての鼎の軽重を問われかねない。
駄目じゃんw

144 :デフォルトの名無しさん:2007/02/13(火) 00:53:54
in-order発行のtypoだと信じておこうw

つか、out-of-order発行(in-order完了)じゃ
いわゆるふつーのout-of-orderじゃん

145 :デフォルトの名無しさん:2007/02/13(火) 06:08:15
out-of-order終了w
カチャカチャな動作をする予想w

146 :デフォルトの名無しさん:2007/02/13(火) 06:41:12
>鼎の軽重
怪電波を飛ばすのが生業のような方々にそんな物問いませんからwww

147 :デフォルトの名無しさん:2007/02/17(土) 23:33:25
連載オワタよ

148 :デフォルトの名無しさん:2007/02/17(土) 23:41:28
第194回 Core MicroArchitectureをもうすこし(18)
http://journal.mycom.co.jp/column/sopinion/194/

長かったな…

149 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/18(日) 00:06:52
↓次のネタ大胆予想


150 :・∀・)っ-○◎● ◆DanGorION6 :2007/02/18(日) 00:14:42
「Core Microarchitectureをさらにもう少し」



addの例はおかしいだろ。
ニーモニックからバイトコードへの変換はアセンブラがやるもので
この辺のデコードだけなら楽にこなせるはずだ。
プレフィックスも少ないし。
このへんだけ見ればx86ってコンパクトだなと思う。


むしろ2〜3バイトopcodeまわりがテラカオス

151 :デフォルトの名無しさん:2007/02/18(日) 00:30:46
>>149
今回のことで懲りたので、たぶん非PCの話題とか、誰にも突っ込まれ
ない(というか誰も興味ない)話題でお茶を濁すと見た。

152 :デフォルトの名無しさん:2007/02/18(日) 00:33:28
> Pentium Proの世代は、命令の発行とその実行まではOut-of-Orderながら、
> 命令の完了(実行結果の書き戻し)はIn-Orderという構成で、
> これが完全にOut-of-OrderになるのはNetBurst Architecture(や、
> P6をベースにアーキテクチャを作り直したBanias Architecture)からになるのだが、

NetBurstやBaniasがOut-of-Order完了な訳ないじゃん。

153 :デフォルトの名無しさん:2007/02/18(日) 00:37:57
ハイパースレッディングは考え様によってはOut-of-Order完了だな

154 :デフォルトの名無しさん:2007/02/18(日) 00:42:44
Out-Of-Order完了www

155 :デフォルトの名無しさん:2007/02/18(日) 14:54:15
>>153
NetBurstはそれでもいいけど、Baniasは違うよなあ

156 :デフォルトの名無しさん:2007/02/18(日) 15:18:22
もうなんか大原って中途半端な知識で言い切るんだよね。だから色々
突っ込まれる。IPC=3だって、「他の可能性もあるが俺はこう思う」と
最初から言えばそこまで突っ込まれないのに、言い切ってしまう。
で、後から「実は他の可能性もあるし、俺はそれも知っていた」と言い訳
するんだよなw

一度初心に戻って勉強しなおせよ。

157 :デフォルトの名無しさん:2007/02/18(日) 16:39:17
初心に戻ろうと思い、裸になって学校へ行こうと電車に乗ったら捕まりました。

158 :デフォルトの名無しさん:2007/02/18(日) 20:28:54
>>156
それがライターの仕事
後藤や本田や(中略)安藤だって(以下略
ブログとセカンドオピニオンで補足するだけマシじゃね

159 :デフォルトの名無しさん:2007/02/18(日) 20:35:53
http://www.amd.com/jp-ja/Processors/TechnicalResources/0,,30_182_861_1036~1667,00.html

> Q: What are some of the advanced features of the AMD-K5 Microprocessor?
>
> A: ・4-issue core with full out-of-order execution and completion

この辺を見て「Out-of-Order完了」という言葉を使っているのかな。
AMDは、内部RISC命令の実行結果をROBに書き込んだ時点で
内部RISC命令の実行完了 という意味で書いているのだろうが、
そういう意味だったらPentium ProもOut-of-Order完了だし。

160 :デフォルトの名無しさん:2007/02/18(日) 20:57:34
>>158
それでも後藤と大原じゃ、大きく違うがな。

二人が同じに見えるなら、それはそれで見る目が無いよ。

161 :158:2007/02/19(月) 00:48:00
何だか、何を書いても叩かれそうだからライターの格付けはしないが。
素人にわかるように説明するのに「〜かも知れない」ばっか使うわけにはいかないよねって話。
でも、あの特集記事が叩かれるのもわかるんだよね。
「K8はそんなに悪くない。むしろよく見える。」な結論ありき丸出しの記事だったもん。
IPCなんて言葉は使わずに>>38 >>41 >>43-44みたいなことを適当に書いておけば良かった。

162 :デフォルトの名無しさん:2007/02/20(火) 00:26:13
まぁ、でもネタを提供してくれる分にはとてもありがたく思ってるよ。

163 :デフォルトの名無しさん:2007/02/20(火) 00:47:19
>> 162
それ大原のこのスレに対する台詞でしょ??

164 :1 ◆.MeromIYCE :2007/02/20(火) 17:19:34
>>148
結局、Core2のIPCが3だという主張以外はまっとうで普通な内容だったな。
本来ならば、この記事を肴にしてSSE4やそれ以降の命令の実装についてとか
32byteフェッチ3命令パイプのK8Lと16byteフェッチ4命令パイプのCore2の比較とか
色々このスレで議論できたはずなのに、ちょっと惜しい感じだ。
プロならちゃんとやれとも思うが、色々事情があってこういう格好になってしまったのだろう。

数年前と比べて、CPUの話題が減ってきてるような気がするんだよなあ・・・。
時代の流れか、それとも単に俺が手持ちのPentiumMに飽きてきただけか。

165 :デフォルトの名無しさん:2007/02/20(火) 18:41:07
みっなおそう、みなおそう、CPUを見直そう
Core2Duo機に買い替えろ
みっつもりっだみつもりだ

166 :デフォルトの名無しさん:2007/02/20(火) 19:49:18
4gamerの第5回目以降の下書きメモ帳代わりにmycomを利用した大原たん

さっさと4亀連載の続き書けや(゚ロ゚)モルァ!!・・・・・書いてくださいお願いしますm(_ _)m

167 :デフォルトの名無しさん:2007/02/21(水) 00:31:05
4gamerの記事は比較的よくできているね。
あれでゲームはやってもCPUに詳しくなかった層が入るのにはちょうどよいだろう。

168 :デフォルトの名無しさん:2007/02/21(水) 09:27:01
【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でw)」と言われて嬉しい
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らないのは当然だ
□派遣先社員より自分の生涯収入が低いのは当然だ
□派遣先とに尻尾を振り、いつまでも派遣を続けることが大切だ


169 :デフォルトの名無しさん:2007/02/24(土) 00:32:24


170 :デフォルトの名無しさん:2007/02/26(月) 00:22:15
セカンド・オピニオン、新シリーズ来ました。
第195回 OS小論:OSの構造をもう少し考えてみる(1)
http://journal.mycom.co.jp/column/sopinion/195/

「もう少し」とついているのが不安をかきたてる…

171 :デフォルトの名無しさん:2007/02/26(月) 00:31:44
「もうすこし」ではないから安心しろ。

172 :デフォルトの名無しさん:2007/02/26(月) 05:16:52
>誰を恨むわけにもいかないんですが
このスレの住人恨む気満々だなwww
ここの住人はサイレントマジョリティーではないはずだが、考慮されている様子。

173 :デフォルトの名無しさん:2007/02/26(月) 09:26:09
大原先生ごめんなさいw

174 :デフォルトの名無しさん:2007/02/26(月) 12:33:04
全部>>173が悪いんです!!

175 :デフォルトの名無しさん:2007/02/26(月) 21:27:43
ぬこ成分だけで全て許してしまえる

いや記事にも期待してるけどスレ違いだな

176 :デフォルトの名無しさん:2007/02/26(月) 22:34:09
iいろんな意味で役に立ってるから今度ファンレター送るね。
つかHansと知り合いつのが改めて驚き。

177 :デフォルトの名無しさん:2007/03/01(木) 22:15:13
Barcelona Architecture: AMD on the Counterattack
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939&p=4

178 :デフォルトの名無しさん:2007/03/02(金) 21:38:33
Hammer-Infoで紹介されていたリンクをメモ

レジスタ間接分岐の高速化手法 (PDF)
http://www.mtl.t.u-tokyo.ac.jp/publications/paper/2005/J05-thesis-toyoshim.pdf

179 :デフォルトの名無しさん:2007/03/02(金) 23:53:07
生活支援てw


180 :デフォルトの名無しさん:2007/03/06(火) 02:27:17
> 他所様の出版社から出ている内容をここで引用するわけにもいきませんので

著作権 (著作者が云々、文化が云々という建前で出版社やレコード会社の利益を最大化するための道具であり既得権益)
を、本音の方の意味で遵守すると正当な引用すらできなくなっちゃうのか

181 :デフォルトの名無しさん:2007/03/07(水) 01:24:37
439 :デフォルトの名無しさん :2007/03/07(水) 01:18:11
狂ったようにx86命令の所要クロックを計測するスレ Part3
http://pc11.2ch.net/test/read.cgi/tech/1168399966/

と紹介されたが、スレタイに「狂ったように」が付いてなくて失望した

182 :デフォルトの名無しさん:2007/03/07(水) 16:07:02
そこは絶望しないと

183 :デフォルトの名無しさん:2007/03/07(水) 22:01:10
これか

【激遅】AppleGCC【絶望】
http://pc11.2ch.net/test/read.cgi/tech/1173267844/l10

184 :デフォルトの名無しさん:2007/03/08(木) 01:05:22
>Intelは80386以降で、4レベルのProtection Ringという概念を導入した(Photo01)。
80286以降だろ。大丈夫か?

185 :デフォルトの名無しさん:2007/03/08(木) 01:18:51
相変わらずツッコミきっつー

186 :デフォルトの名無しさん:2007/03/08(木) 07:56:57
VAX/VMS が仮想記憶をインプリメントした初めてのOSだとか [1]、
4 level ring が VAX 由来だとか [2]、ほかにも色々間違っとるぞ。

[1] Wikipedia によると商用では 1961年の Burroughs B5000 が最初らしい。
研究用だと、さらに数年さかのぼる。
IBM の汎用機も VAX/VMS よりずっと以前に仮想記憶をサポートしてるはず。
VAX は 1970年代終りなので、ずっとずっと新しい。
[2] よく知らんが、たぶん MULTICS 由来。


187 :デフォルトの名無しさん:2007/03/08(木) 12:59:43
80386の仮想記憶ってほとんどMULTICSそのままだよな。

188 :デフォルトの名無しさん:2007/03/08(木) 19:08:02
80386は仮想記憶やページングのアーキテクチャだけは割と新しいからな

189 :デフォルトの名無しさん:2007/03/10(土) 02:37:09
>>188
話の流れを分かってない。
MULTICS由来ってのは286から導入されたセグメンテーション機構の話。

386から入ったページング機構はインテルにしては(?)素直で作りで良い
んだが、TLBにASIDがないのがちと古い感じ。

190 :デフォルトの名無しさん:2007/03/12(月) 01:03:57
流れ断ち切るようでスマソ。質問。

VCExpressコンパイラでローカル変数として配列等大量にオブジェクトを定義している関数内部で

関数入口:sub esp, ローカル変数のサイズ分
関数出口:add esp, ローカル変数のサイズ分

と展開されたコードがあります。
このコードが有る場合、パフォーマンス大幅に落ちるから気をつけてくださいな、と上司から言われたんですが、
何処に根拠があるのかサッパリで悩んでます。
パフォーマンスは落ちるものなのでしょうか

自分なりの答え:
スタック領域使うからレジスタで演算するよりも速度が落ちる?

191 :デフォルトの名無しさん:2007/03/12(月) 01:25:39
>>190
まずは実測してくれまいか?

192 :デフォルトの名無しさん:2007/03/12(月) 01:42:35
スタックの先頭は通常キャッシュにのってるから速いが
沢山スタックを消費すると追いやられる
そのことを言ってるんだと思う

メモリ沢山使う&アクセス頻度が低い
ならば、メモリはヒープからとったほうがいいかもしれない。

あ、ちゃんと実測してね。思い込みはダンゴの元。

193 :・∀・)っ-○◎● ◆DanGorION6 :2007/03/12(月) 01:48:04
スタックを大量に使うこと自体はそんなに問題じゃないと思う
push. pop大量にするわけじゃあるまいし。

194 :・∀・)っ-○◎●:2007/03/12(月) 01:50:13
>>192
ヒープに載っけても結局同じだけメモリ食うんだがw

まだ直線的に並んでたほうがassociativityの制約に引っかかりにくいw
机上論だがw

195 :デフォルトの名無しさん:2007/03/12(月) 02:01:11
call by value -> call by reference

196 :デフォルトの名無しさん:2007/03/12(月) 02:05:51
ここは計測スレなのに最近自作○C板のCPUスレと同種の話ばっかりじゃない?
自作○C板は自作○C板で同種のスレがたくさんある。もっと独自路線を出してほしい。
つか、どこでも読める理論話のぼり返しはほどほどにしてひたすら計測しろよと。

197 :・∀・)っ-○◎●:2007/03/12(月) 02:18:37
しかしAgner氏の計測を覆すような発見もそうそう無いんだよな

命令レベルじゃなくて何かのプログラムコードレベルで
ボトルネックを分析するとか?

198 :デフォルトの名無しさん:2007/03/12(月) 02:25:27
マジでダンゴ来た・・・もうオワリだ・・・

199 :・∀・)っ-○◎●:2007/03/12(月) 02:44:07
最初からいるだろ
x86じゃないけどCellのスループット計測結果なら出せるよ


200 :デフォルトの名無しさん:2007/03/12(月) 03:06:29
早く貼れ

201 :デフォルトの名無しさん:2007/03/12(月) 03:07:19
いや、やっぱり貼るな
CELLネタは荒れる

202 :・∀・)っ-○◎●:2007/03/12(月) 03:08:55
>>1が許可したら貼る。
てかCellスレあるし

203 :デフォルトの名無しさん:2007/03/12(月) 14:43:18
トリップ外すな、ハゲ。

204 :デフォルトの名無しさん:2007/03/12(月) 14:55:40
○◎●であぼーんは基本だろ?

205 :デフォルトの名無しさん:2007/03/12(月) 19:38:51
http://homepage1.nifty.com/herumi/diary/0703.html#6

206 :デフォルトの名無しさん:2007/03/12(月) 20:50:00
いつもの
http://journal.mycom.co.jp/column/sopinion/197/

と、65nmAthlonのL2キャッシュレイテンシについての考察
http://journal.mycom.co.jp/special/2007/x2-65nm/

207 :1 ◆.MeromIYCE :2007/03/13(火) 12:23:41
>>181
実際狂ったように測定していなくてゴメン。

>>190
アセンブラレベルでは、sub esp, ローカル変数のサイズ分 は ただの引き算だから、
1clkで終わってしまう簡単な処理だ。
でも、マルチタスクOSで動かす以上、Windows側のメモリ管理で時間がかかるとか?
今時間ないので後で実測したい。

>>202
256KBのLSのレイテンシとピーク帯域、FP_SIMDのレイテンシ・スループットを希望。
x86じゃないけど、自分で実測したデータなら誰も文句言わんでしょ。

>>206
レイテンシ測定はここ。
http://journal.mycom.co.jp/special/2007/x2-65nm/013.html

何で生データを載せてくれないだ。くそっ。意味わからんグラフばっか載せやがって・・・。
キャッシュラインサイズの64byte以下のstrideで速くなるのは当然として、
それ以上のstrideで変化しているのは単にCPUの機嫌が悪かっただけと予想。
内部構造が変わったかどうかはわからないが、レイテンシが増えたのは確実だ。

208 :1 ◆.MeromIYCE :2007/03/13(火) 12:51:01
コンパイラの出力を見て初めて知ったこと。
or ecx, -1 (83 c9 ff) という3byteでecxに32bitの-1を入れることができる。
1byteの-1は32bitに符号拡張される。
まあ、xor ecx,-1 はnot ecx でいいし、高速化に使う機会はないかな。

>>196
ネタ切れ、というのが主な原因なんだけど、
実際クロック測定は、何を測定するか考えて、実際に測定して、考察して書き込む、
という手順を踏まなければならない。
そして、そのそれぞれが、思った以上にめんどくさい/難しい。

そこで、何を測定するかだけでも思いついたら書いてくれ、って前から言ってるけど。。
あと、cpu-zのレイテンシ測定の全CPU分を集結させたいと思っている。
このスレでも何度か上がってるけど、いざ90nmK8のデータが欲しいと思っても、
どこにあったかわからなかったので。

http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=cpuz.zip&refer=Upload
とりあえずここに、手元にあった分だけ固めてアップしておく。
あとでちゃんと整形して上げます。

209 :・∀・)っ-○◎●:2007/03/13(火) 19:32:13
スループットなら倍精度以外はほとんど1だよ。

SPEのLSはレイテンシ6だよ。Coppermineがレイテンシ6だったから
今のCore 2も、独立キャッシュにしてL2のエントリ数削れば
それくらいいけるんじゃないのって思うと萎える。
んなわけで、レジスタが128本もあるから、必要なデータは展開して
しまった方がいいわけだ。

AltiVecでVSIUパス命令に相当する整数演算命令はレイテンシ2、
あとの命令(VCIU、VPERM相当)は大体レイテンシ4。
あと、浮動小数はfma(積和算)で6、faddで4。

逆数を求めるfrestなんかも4で処理出来、fmaと組み合わせれば
レイテンシ10・スループット2で除算ができてしまうんだけど、
estimate(推定値)というぐらいだから精度は絶望的に低いと
思ってくださいな。
それなりに精度の高い除算をやろうと思えばソフトでやるしかない。
平方根も同じく。

210 :・∀・)っ-○◎●:2007/03/13(火) 19:48:30
LS間の「ピーク帯域」に関しては、ロード・ストアはoddパイプで処理されるから
1クロックに1命令。

ロードかストアを発行×3.2GHzだから51.2GB/secでしょう
DMA転送中はどうだかまだ調べてない


SPE-SPEのDMA転送帯域とかならこのへん
http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

211 :・∀・)っ-○◎●:2007/03/13(火) 19:56:22
てか、IBMの図におもっきし51.2GBって書いてあるじゃんww

212 :・∀・)っ-○◎●:2007/03/13(火) 20:01:29
レジスタが128本だから1レジスタ指定に7ビット。
4オペランド命令で28ビットも使ってるからOpcodeは4ビット。
(上1ビットはopcodeサイズの区別に使うから実質3ビット)

そういえばPentium 4もμOPsレベルではレジスタ数は128だか256だかでしたな。

213 :デフォルトの名無しさん:2007/03/13(火) 20:01:51
80286の間違いは訂正なしか。だめだなこりゃ。

214 :デフォルトの名無しさん:2007/03/13(火) 20:45:51
精度の高い除算のやり方はは3DNow/SSEと同じ。
doubleも命令の組み合わせで一通り出来るけどスループットとレイテンシを考えると…。

それでもこれだけ割り切ったプロセッサでdoubleが扱えるだけ幸せ。

215 :・∀・)っ-○◎●:2007/03/13(火) 23:09:18
なんつーか、普通のプロセッサ用に書いたコードがことごとく使えない
エントリポイントのmain型さえ置き換えればどうにかなると思ってたら
1から書き直しなんだよね。

それでもprintfなどがそのまま使える分マシ
(PPEで動くヘルパースレッド向けにDMA転送して処理してる?)

216 :デフォルトの名無しさん:2007/03/14(水) 01:37:23
spe_printf()は遅い悪寒。
#って、スレ違いだがね。

217 :・∀・)っ-○◎●:2007/03/16(金) 23:26:50
ネタがないな

218 :デフォルトの名無しさん:2007/03/16(金) 23:48:45
暇ならXLATの所要クロックについて語ってくれ。
とか適当な事を言ってみる。

219 :デフォルトの名無しさん:2007/03/17(土) 04:43:37
x86_64命令の所要クロック計測まだー

220 :・∀・)っ-○◎●:2007/03/17(土) 05:08:51
同じじゃねーかwwww(NetBurst以外

221 :1 ◆.MeromIYCE :2007/03/18(日) 21:50:08
>>209
レスが遅れてすまん。
まあ、大体素直な感じだな。

x86のキャッシュはマルチタスクに対応するための複雑なメモリ管理や
L1L2(ものによってはL3も)の多重階層で、かなりレイテンシが増えているよな。
それを考えればCellのLSは順当な性能だ。

x86にLSを載せたらどうだろう。
256KBでレイテンシ6、128bit/clkという性能で、更にL1L2キャッシュは今まで通りとする。
LSは新SSE命令で明示的に使う必要があるが、使えば効果は大きいと思う。
(L1とLSの両方に高速な配線をつなぐのは技術的に困難か?)

レジスタは128bit*128で2KBか。
こんなにあると、コーディングにまた別の感覚が必要になるなあ。


>>219
実際問題、普通にパソコン買うと32bitのWindowsVistaになっちゃうんだよね。
64bitの計測ができるのは、だいぶ先の話になりそうだ・・・。

222 :・∀・)っ-○◎●:2007/03/18(日) 22:06:52
帯域がもう少し広ければトレースキャッシュくらいに使えるんじゃないかなと思ったり。

223 :・∀・)っ-○◎●:2007/03/19(月) 02:01:23
ロード・ストア命令が16バイト単位でしか読めないから、多段階ルックアップテーブル
作ろうと思ったら各要素16バイトでパディングしないといけない。
ストアがさらに厄介で、含まれる16バイト領域をロードしてからマスクして値を重ね合わせ
格納する。
16バイト境界をまたがってた日なんか目も当てられませんな。

スカラなプロセッサ由来でスカラ−ベクタの交換も柔軟にこなせるx86+SSEの
使いやすさを認識するためにも使ってみるべきプロセッサですな。

224 :デフォルトの名無しさん:2007/03/19(月) 02:57:39
スレ違いだし今更気づくような内容でもないだろう。
本当にAltiVec使った事あるのか?
手順が若干簡略化されてるだけでAltiVecもやるべき事は同じじゃないか。

225 :・∀・)っ-○◎●:2007/03/19(月) 03:37:14
スカラプロセッサの補助としてベクトル演算器があるのと、
スカラ演算までベクトル演算器でやらなりゃならないのとは根本的に違うだろ。
AltiVecではアドレス演算はスカラ演算器で行い、ベクトル演算はデータの
処理のみに専念できる。このへんはx86と同じ。
AltiVecはせいぜいベクトル-スカラ間の値直接交換がないくらいで、
いったんL1に書き出して読み出すだけでいい。


SPUにはスカラデータを扱う命令そのものがない。
1バイト単位はおろか4バイト単位のロードすらない。
(そのくせアドレス生成や条件分岐ではベクトルの第一ワードでしか使えない)
16バイト単位で読み出して適宜シフトしなきゃいけない。
このへんがスカラ演算が圧倒的に遅いと言われる要因。

226 :デフォルトの名無しさん:2007/03/19(月) 04:22:02
>>221
> x86にLSを載せたらどうだろう
レジスタ同様にタスクスイッチ時にデータを退避するのか?
それともロックして占有するのか?


227 :1 ◆.MeromIYCE :2007/03/19(月) 10:12:27
>>226
仮にやるとしたら、ロックするのがいいかな。
オーバーレイなんかも同時に2アプリで使えないことだし、
エンコやゲーム専用と考えれば。

でもやっぱりマルチタスクできないのは不便だよな。
OS側でも工夫のしようはあると思うが、
そうまでして使う価値があるかは正直疑問だし。

228 :・∀・)っ-○◎●:2007/03/19(月) 21:00:40
L1キャッシュよりレイテンシの大きいローカルストアよりも
拡張XMMレジスタファイル256本のほうがまだありがたいような。
imm8を使って各レジスタを指定。

229 :デフォルトの名無しさん:2007/03/19(月) 23:40:14
スケジューラが詰まらないならその方がありがたいです。
レイテンシ分くらい依存命令を離しているつもりなのにストールすると悔しい。

230 :デフォルトの名無しさん:2007/03/24(土) 00:59:06
リアルモードの割り込みベクタのことIDTなんていう呼び方してたっけ?

231 :・∀・)っ-○◎●:2007/03/24(土) 01:10:07
Interrupt Descriptor Table

そのまんまの意味だな

232 :デフォルトの名無しさん:2007/03/24(土) 01:12:47
いや、だからリアルモードの割り込みベクタテーブルとプロテクトモードのIDTはちょっと違うもんだろ、って話じゃ?

233 :デフォルトの名無しさん:2007/03/24(土) 03:18:03
英語が理解できないのはつらそうだな。

234 :デフォルトの名無しさん:2007/03/28(水) 15:47:10
どうして団子リオンはトリップつけてないのか。

235 :デフォルトの名無しさん:2007/03/28(水) 16:08:32
>>230
intelの文書ではリアルモードの割り込みベクタテーブルを実アドレスモードIDTとよんでいる

236 :・∀・)っ-○◎●:2007/03/29(木) 00:41:01
>>234
漏れてるから

237 :デフォルトの名無しさん:2007/03/29(木) 03:14:36
ありゃ、お漏らししちゃってたのか。

238 :デフォルトの名無しさん:2007/03/29(木) 09:03:33
Intel Penryn and Nehalem 45nm Processor Update
http://www.legitreviews.com/article/480/3/
The New Technologies and Features

Super Shuffle Engine キター

239 :デフォルトの名無しさん:2007/03/29(木) 09:57:21
Emulatorの友

240 :・∀・)っ-○◎●:2007/03/30(金) 01:40:45
> Super Shuffle Engine

128ビットシャッフルのスループット改善ですか

241 :デフォルトの名無しさん:2007/03/30(金) 01:45:33
>>240
団子ちゃん、こっちのスレでお呼びがかかってるよ。
http://pc11.2ch.net/test/read.cgi/tech/1137540671/

242 :デフォルトの名無しさん:2007/03/31(土) 01:47:05
>>235
どの文書?

243 :デフォルトの名無しさん:2007/04/01(日) 10:32:22
スレ違いならごめん。

C言語で以下のようなソースがあったとして、
if( a < b ){
 min=a;
 max=b;
}else{
 min=b;
 max=a;
}

if( a < b )のかわりにif( a <= b )としても問題ないけど、この2つで出力
されるアセンブラソースや所要クロックに差は出るかな?
intなら同じだけどfloatでは差が出るとか有り得る?

244 :デフォルトの名無しさん:2007/04/01(日) 11:05:39
>>243
コードの差は出るかもしれないし出ないかもしれない。
その周辺のコードによっても変わるし、勿論コンパイラによっても変わる。

245 :・∀・)っ-○◎●:2007/04/01(日) 11:23:10
別スレ逝った方がいいよ。
「うちの使ってるコンパイラでASMコードの出力の仕方が解らないので教えてください」







SSE使えば比較文自体排除できる罠。floatだとこんだけ。

__m128 xa = _mm_set_ss(a);
__m128 xb = _mm_set_ss(b);
_mm_store_ss(&max, _mm_max_ss(xa. xb));
_mm_store_ss(&min, _mm_min_ss(xa. xb));

246 :デフォルトの名無しさん:2007/04/01(日) 11:27:17
>>243
速度を気にするなら条件分岐を排除
同確率の二択はほぼどちらかが失敗する

247 :デフォルトの名無しさん:2007/04/01(日) 11:34:00
どうも有難うございました。

248 :デフォルトの名無しさん:2007/04/01(日) 11:55:50
まぁ、そんな細かいことが気になるならc++で
min = std::min(a, b);
max = std::max(a, b);
とでもすればいいだろうよ。


249 :・∀・)っ-○◎●:2007/04/01(日) 12:05:11
細かいことが気になるならmin/max関数なんて使わない

250 :デフォルトの名無しさん:2007/04/01(日) 12:53:36
なるほど、団子には皮肉が通じないわけだ。

251 :デフォルトの名無しさん:2007/04/01(日) 13:15:01
つーかそれ、素で間違ったのに皮肉と言い訳してるのと見分けが
つかないから、皮肉なら皮肉でちゃんと分かるようにしないとw

252 :デフォルトの名無しさん:2007/04/01(日) 13:19:50
明らかに皮肉とわかるのに
団子がいるスレは一段と引き締まるな

253 :デフォルトの名無しさん:2007/04/01(日) 13:23:45
>>248みたいなことを言う馬鹿や初心者は結構いるぞ。
つまりそういう人間と君みたいな天才は区別が付かないんだよw
せっかく天才なんだから周りに勘違いされないようにした方が
幸せだと思っただけさ。気に障ったら許してくれw

254 :デフォルトの名無しさん:2007/04/01(日) 13:38:16
( ゚д゚)ノ ドゾー
http://pc11.2ch.net/test/read.cgi/tech/1084676298/411

255 :デフォルトの名無しさん:2007/04/01(日) 14:20:42
どうもごめんなさいでした。

256 :・∀・)っ-○◎●:2007/04/01(日) 14:21:23
>>253
基本的に同意
でも多分std::maxとかって書いておけば最適な命令に置き換えてくれると勘違いしてる
初心者なんじゃないだろうか。
皮肉だ皮肉だとと必死に自己弁護してることからも明らか

>>254
Hacker's Delight日本語訳発行以降、
半端な知識で「MSBをシフトすれば分岐が排除できる=速い」と思いこんで
改悪コード書く厨が増えたよな。

257 :デフォルトの名無しさん:2007/04/01(日) 14:43:29






            半  端  な  知  識        







258 :・∀・)っ-○◎●:2007/04/01(日) 15:06:04
皮肉だ皮肉だと自己弁護してるのが特にそうだね

259 :デフォルトの名無しさん:2007/04/01(日) 16:07:16
いくら初心者でもmin,maxが最適な命令に置き換わるなんて発想はありえない。
ちょっとひねくれすぎ。

260 :デフォルトの名無しさん:2007/04/01(日) 16:08:54
団子が昔そうだったとか?

261 :デフォルトの名無しさん:2007/04/01(日) 16:32:03
ダンゴの言うことはホント正しいよね
歯向かうのは馬鹿

262 :デフォルトの名無しさん:2007/04/01(日) 16:34:42
どう考えてもmin,maxが最適な命令に置き換わるなんてありえないな。
誰に吹き込まれたか知らないが、勝手な妄想はよしたほうがいい。

263 :・∀・)っ-○◎●:2007/04/01(日) 16:35:02
>>243がかかるクロック数を短くしたいという目的があって質問したのは
明らかなわけだが

細かいこととは、かかる処理時間を少しでも短くすることなわけで
min/max関数が最適な命令に置き換わるという勘違いでもしてないかぎり
出来ないレスだと思うけどねこれは


248 :デフォルトの名無しさん :2007/04/01(日) 11:55:50
まぁ、そんな細かいことが気になるならc++で
min = std::min(a, b);
max = std::max(a, b);
とでもすればいいだろうよ。


>>259-260 ←見苦しい弁解だな

264 :デフォルトの名無しさん:2007/04/01(日) 16:40:20
言葉遣いや性格には問題ありだが。。。

265 :・∀・)っ-○◎●:2007/04/01(日) 16:41:07
>>262
組み込み関数として最適化ができるアーキテクチャ・処理系はあるよ。
x86では、知る限りでは無いけど(マクロ版ならまだ最適化される余地あるかも)

266 :デフォルトの名無しさん:2007/04/01(日) 16:41:52
>>264
まず団子が正しいことを認めろよ。
言い訳がましい。

267 :デフォルトの名無しさん:2007/04/01(日) 16:45:34
>>262
あるだろう

268 :248:2007/04/01(日) 17:07:41
ここで真相を明かしますよ。今日の日付けを考えてみろ、と。

という冗談はさておいて。
そもそも元質がCでって書いているんだから、C++で書いてある時点で>248はネタだって判るでしょうに。

269 :・∀・)っ-○◎●:2007/04/01(日) 17:10:04
>>268を翻訳

「max/minが関数名と重なってるからstd::ネームスペース指定してみたけど
二重に誤爆しちゃったみたい。俺ってお馬鹿♪」

270 :デフォルトの名無しさん:2007/04/01(日) 17:56:56
条件付movとか、フラグ→マスクみたいな一般的な方法ではなく
SSE2が最初に出てくるようなミーハーイッテル馬鹿は初心者を笑えないだろ…

271 :デフォルトの名無しさん:2007/04/01(日) 18:23:00
>>270
見苦しい。

272 :デフォルトの名無しさん:2007/04/01(日) 18:28:49
>>271
団子よ、IDが出ないからといって見苦しい自演するな。

273 :デフォルトの名無しさん:2007/04/01(日) 18:41:39
無意味な喧嘩すんなよ。
匿名掲示板上で自分のアイデンティティ探ししてると、
(自作板に2名ほどいるけど)本物の精神疾患になるぞ。

274 :デフォルトの名無しさん:2007/04/01(日) 18:51:22
おまえ自作板見てないだろ?

275 :デフォルトの名無しさん:2007/04/01(日) 18:56:01
>>243-275
スレ違い

276 :デフォルトの名無しさん:2007/04/01(日) 19:03:28
O原ネタ振れよww

277 :・∀・)っ-○◎●:2007/04/01(日) 19:35:46
>>272
アホすwww

>>270
SSE2じゃなくてSSEまでのサポートで使えるけど。
CMOVならPentium Pro以上が要求される。
Pentium/PMMXは切り捨ててよくてPPro/P2は切り捨てちゃだめって基準は理解できない。
CMOVは対応する組み込み関数あったっけ?コンパイルオプションやインライン
ASMくらいしか使う手段なかったと思うが。

どうせSSE未サポートのx86互換チップなんて今後発売される見込み無いんだし
x64ではSSE2までは標準ISAに入ってるんだから覚えておいていいと思うけど。

ハードウェアの投機実行機構に任せるより下手すりゃ遅くなるような
ビットマスク生成とかの厨コーディングより、いま市場に出回ってるCPUの
大半で使える最速の方法を知ってたほうがよっぽど役に立つだろ。

278 :デフォルトの名無しさん:2007/04/01(日) 19:53:13
この粘着力は酉付いてなくても真性だとわかる

279 :デフォルトの名無しさん:2007/04/01(日) 20:33:12
MACヲタもそうだが酉なしで粘着する奴はもう一線越えてるからな

280 :デフォルトの名無しさん:2007/04/01(日) 20:38:45
無能よかまし
無能は情報として価値が無い

281 :デフォルトの名無しさん:2007/04/01(日) 20:42:30
>>270が言ってるのはset命令だろ。
そこでSSEとかCMOVとか言ってる時点で話が見えてない。

CMOVの組み込み関数はVCの64bitモードになかったっけ。
32bitで使えないならあんま意味ないけどな。

282 :デフォルトの名無しさん:2007/04/01(日) 21:15:58
無能は価値がないけど嘘吐きは有害

283 :デフォルトの名無しさん:2007/04/01(日) 21:27:04
>>280
>>282
なんかヤなことでもあったのか?

284 :・∀・)っ-○◎●:2007/04/01(日) 21:34:37
>>281の脳内では「条件付きMOV」と「CMOV」は別モノらしい

set命令って何?
_mm_set_ssならmovssに展開されるだけだよ。
むろんemmintrin.hなんて要求されない

285 :・∀・)っ-○◎●:2007/04/01(日) 21:37:20
>>282
だよね。SSEしか要求しないのに生成コードすら読まずに
SSE2だなんていう嘘つきは要らない子だね。

286 :デフォルトの名無しさん:2007/04/01(日) 21:46:07
今日付いたレスは全部嘘

287 :・∀・)っ-○◎●:2007/04/01(日) 21:55:15
インラインASM的にはこうか?

__asm {
movss xmm0, DWORD PTR [a]
movss xmm1, DWORD PTR [b]
movss xmm2, xmm0
maxss xmm0, xmm1
minss xmm2, xmm1
movss DWORD PTR [min], xmm0
movss DWORD PTR [max], xmm2
}

x87スタック←→XMMレジスタは普通の方法使えばメモリに書き出して読み直すので
その分オーバーヘッドが生じるが、
arch=sseでコンパイルしてれば浮動小数演算はほとんどXMMレジスタ上で行うことができる。

んで、SSE2命令なんてどこに必要なの?ねぇ、教えて?


>>286
だよね。「SSE2が必要」ってのはどーみても綿貫ネタだよね。

288 :デフォルトの名無しさん:2007/04/01(日) 22:01:37
>>284
SETcc r/m8

289 :・∀・)っ-○◎●:2007/04/01(日) 22:24:59
mov eax, [a]
mov edx, [b]
sub eax edx
setg(以下まんどくせ。movsxって結構オーバーヘッドなかったっけ?


MMXまんせー(uint32のとき
Core2とかならXMMレジスタ使った方がいいかもよEMMSのオーバーヘッド省けるし

movd mm0, [a]
movd mm1, [b]
movd mm2, mm0
pcmpgtd mm0, mm1
pand mm2, mm0
pandn mm0, mm1
movd [max], mm2
movd [min], mm0
emms

290 :デフォルトの名無しさん:2007/04/01(日) 22:37:26
このグラフの目盛は13クロック前後かな?
http://pc.watch.impress.co.jp/docs/2007/0329/intel_8.jpg

291 :デフォルトの名無しさん:2007/04/02(月) 00:46:40
相当な粘着だな

292 :デフォルトの名無しさん:2007/04/02(月) 01:30:13
うちの団子が粘着でごめんなさいm(_)m

293 :デフォルトの名無しさん:2007/04/02(月) 01:33:03
粘りけのない団子なんて食えたもんじゃない

294 :デフォルトの名無しさん:2007/04/02(月) 01:35:07
と背景雑音どもが申しております

295 :デフォルトの名無しさん:2007/04/02(月) 01:38:50
    _, ._
  ( ゚ Д゚)
  ( つ旦O
  と_)_)

296 :デフォルトの名無しさん:2007/04/02(月) 10:24:01
SET命令やビット命令を最後に使ったのは何時だったか

297 :デフォルトの名無しさん:2007/04/02(月) 16:21:18
つまらん事で荒れたのを久々に見たなぁ・・・

スレ違いだ他池ボケで済むだけなのに。

298 :デフォルトの名無しさん:2007/04/02(月) 17:31:52
スレ違いな質問にも答えずにはいられないのが教えたがり君クオリティ

299 :デフォルトの名無しさん:2007/04/03(火) 00:09:42
おまえらがつまらんことやってるからWolfdaleのESベンチの結果が違うスレに貼られたじゃないか

300 :デフォルトの名無しさん:2007/04/03(火) 00:24:54
速w
http://pc11.2ch.net/test/read.cgi/mac/1159817811/608

301 :1 ◆.MeromIYCE :2007/04/03(火) 12:45:37
>>238
これは嬉しい!

>>300
速すぎて、クロック測定ルーチンがポシャってないか不安なくらい。


Intel、45nmプロセスの次期CPU「Penryn」の詳細を公開
http://pc.watch.impress.co.jp/docs/2007/0329/intel.htm
とりあえずMeromとの比較まとめ。

L2キャッシュは1.5倍の6MB、12MB版もあり。ダイサイズは25%縮小。新たにSSE4が載る。
SSEのShuffle系の命令の遅さが改善される。
整数/FP共に除算の性能が上がる。FPUの平方根も高速化。
FSBクロックが上がり、プリフェッチにも手が入る。
省電力機能のDPD、シングルスレッド性能のためのEDA。

Yonahの消費電力はなぜ少ないのか
http://pc.watch.impress.co.jp/docs/2005/0831/kaigai208.htm
Deep Power Downは、YonahのEnhanced Deeper Sleepと何が違うんだ?
まさか、YonahのDC4ステートがMeromになかったのか。
Enhanced Dynamic Accelerationは、IDAの改良版だろうか。

"Radix 16"の16は何だろう。>>300を見ると相変わらず8bit単位でクロック数が変わっている。
命令のデコードが速くなるという記述もあるが、divのuOP数も減るのか?
今までは ちまちまやっていたのを、16bitいっぺんにやるから速いということかね。

引きずってる弱点もあるだろうけど、十分に洗練されてきたと感じる。

302 :デフォルトの名無しさん:2007/04/03(火) 13:41:42
>>301
>"Radix 16"の16は何だろう。
見えてきたPenryuとNehalemの「革新性」 (1/2)
http://plusd.itmedia.co.jp/pcuser/articles/0704/02/news067.html
で元麻布の言ってる事が確かなら、「基数を16にした除算器(Radix-16 divider)」

しかし予想外に新要素が多いね。
シュリンク+SSE4ぐらいかと思ってたんだが。
こらAMDきつくなりそう…

303 :1 ◆.MeromIYCE :2007/04/03(火) 14:40:04
>>302
基数が16ってのは16進法で筆算するような感じなのかな。
クロック数の変動から、256進法と思っていたが、単に商を8bitで区切って
その区切りごとに演算を早目に終わるという感じか。

Nehalemは、単純にIPCで見て素直な上がり方をするのかなあ。
P6と違う味のするコアでPenrynを完全に超えてくれたら嬉しい。

304 :デフォルトの名無しさん:2007/04/03(火) 16:31:14
つまりは4ビット単位の部分商を一気に計算してるんだろ

305 :デフォルトの名無しさん:2007/04/03(火) 20:13:26
>>301
>速すぎて、クロック測定ルーチンがポシャってないか不安なくらい。
>>128のMeromの半分だし妥当では?

>Deep Power Downは、YonahのEnhanced Deeper Sleepと何が違うんだ?
>まさか、YonahのDC4ステートがMeromになかったのか。

>Yonahの消費電力はなぜ少ないのか
>http://pc.watch.impress.co.jp/docs/2005/0831/kaigai208.htm
>その段階に入ると、Yonahは、新たに設けられたEnhanced Deeper Sleep「DC4」と呼ばれるステイトに入る。
>これは、Deeper Sleepよりさらに電圧を下げるステイトだ。
>Enhanced Deeper Sleepでは、CPUコアを再起動しないですむ、コア保持(Core retention)レベルに最低限必要な電圧にまで下げる。

スライドを見る限りではこのコア保持レベルより更に電圧を下げるという話みたいね。

306 :・∀・)っ-○◎●:2007/04/03(火) 21:49:44
自習で暇だったからランダムなfloat値1億個の入った配列を読み出して
最大値と最小値を求めるプログラム書いて時間潰してた。

案の定だが、SSEベクトル>SSEスカラ>>>>>>x87
fcmov*って大して速くないんだな

307 :デフォルトの名無しさん:2007/04/03(火) 22:54:19
こいつは半端に知識ある癖してどこまで理解出来てるのかさっぱりだな。
CMOVは速いんじゃなくて最悪の状態でも遅くなりにくいんだぞ。
原理くらい知ってるだろうに。

308 :・∀・)っ-○◎●:2007/04/04(水) 05:09:26
うん、それで?

309 :デフォルトの名無しさん:2007/04/04(水) 06:49:23
>>307
稚拙な煽りだな。

310 :デフォルトの名無しさん:2007/04/04(水) 07:39:57
落ち着け。つくづく痛い子だな。
306は内容が無いだろ。チラシの裏にでも書くんでなければせめて分り切った事でも考察入れろと。

311 :・∀・)っ-○◎●:2007/04/04(水) 07:51:45
こんなもんで
せろり2GHz

x87+CMOV 1100msec
SSE(スカラ) 320msec
SSE(ベクタ) 230msec

312 :デフォルトの名無しさん:2007/04/04(水) 21:21:14
80/32(bit)より遅いね。
doubleの場合と分岐を使う場合はどうだろう。

313 :1 ◆.MeromIYCE :2007/04/06(金) 23:39:33
>>190のを試すのと、fsqrtとfdivのレイテンシ測定をやりたいんだが、
何かやる気出ないなあ・・・。

NehalemにはSMTが載るらしいが、数年後なら4〜16スレッドに
備える意味があると踏んだのだろうか。
まあ、サーバー用途とかだろうけど。

SMTの効果だが、NetBurstと同等くらいはあるのではないだろうか。
ネトバは元々スカスカだから、SMTで資源を有効利用できる。
とはいえ、SSEのレイテンシで見ると、実はCore2よりもネトバの方が
スループットに対してレイテンシが短い(パイプライン充填率が高い)。
Nehalemでは、きっちり4命令/clkをコンスタントに供給してくるだろうし。

これはつまり、Core2の効率が悪いと言っていることになるが、
実際にあれだけ強化したCore2がK8の20%増ししか速くないのだから、
発揮できていない潜在パワーはかなりあるはずだ。
(これは別にCore2の設計が悪いという意味ではない)

314 :・∀・)っ-○◎●:2007/04/06(金) 23:48:21
命令フェッチ帯域が狭いからそれを拡充しないことにはね(Penrynでは改良してくるはず)

315 :1 ◆.MeromIYCE :2007/04/07(土) 00:09:44
>>305
え、コア保持しないん!?

>>311
float1億個といったら400MBじゃんか。
それでもメモリネックにならないのか。
cmovは1個に20clk以上かかってるぞ。
比較-フラグ-移動のレイテンシが長いんだろうなあ。

いずれしても、これからの時代はFPUを使う意味がないね。

316 :・∀・)っ-○◎●:2007/04/07(土) 01:05:52
ちなみにCで書いてコンパイルしただけ。(SSEだけIntrinsicsを利用)
っていうかISAがスタックベースだからどうしても命令が多くなるのでしょう
一方SSEだとこんだけ。

movss xmm2, [ecx+Offset]
maxss xmm0, xmm2
minss xmm1, xmm2


ちなみに手動でアンロールしたら同じ環境でスカラ280ms, ベクタ200msくらいになった。
キャッシュは128KBだしFSBは400MHz、メモリはよくわからん。
プリフェッチは使ってない(てかあんま意味なさそう)

317 :デフォルトの名無しさん:2007/04/07(土) 05:48:00
ソース希望。

って、SSE版は掲載済みか。

318 :・∀・)っ-○◎●:2007/04/07(土) 09:08:29
ループの内側はこんだけ。

//FP版
if (a[i] > fMax) fMax = a[i];
else if (a[i] < fMin) fMin = a[i];

//SSEスカラ版
__m128 sa = _mm_load_ss(&a[i])
xmax = _mm_max_ss(xmax, sa);
xmin = _mm_max_ss(xmin, sa);

//SSEベクタ版
__m128 pa = _mm_load_ps(&a[i])
xmax = _mm_max_ps(xmax, pa);
xmin = _mm_max_ps(xmin, pa);

319 :317:2007/04/07(土) 09:29:14
お、THX!

それはいいけど、いい加減そのメルアドはやめなさいよ。

320 :・∀・)っ-○◎●:2007/04/07(土) 10:04:21
どうでもいいけど_mm_min*だな

321 :デフォルトの名無しさん:2007/04/09(月) 13:16:33
折角だから実測してみた。
>Intel(R) Xeon(TM) CPU 3.40GHz [fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl est tm2 cid xtpr]
>gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)

>gcc -O3 -std=c99
if (p[ic] > vMax) vMax = p[ic];
if (p[ic] < vMin) vMin = p[ic];
0.61 sec #fucomして普通にjne/jmpで分岐
if (p[ic] > vMax) vMax = p[ic];
else if (p[ic] < vMin) vMin = p[ic];
0.64 sec #fucomしてあっちこっちにjmp
>gcc -msse2 -O3 -std=c99
if (p[ic] > vMax) vMax = p[ic];
if (p[ic] < vMin) vMin = p[ic];
0.91 sec #fucomiしてfcmovnbe
if (p[ic] > vMax) vMax = p[ic];
else if (p[ic] < vMin) vMin = p[ic];
0.90 sec #maxはfucomiして普通に分岐、minはfucomiしてfcmovnbe
__m128 tmp = _mm_load_ss(& p[ic]);
xMax = _mm_max_ss(xMax, tmp);
xMin = _mm_min_ss(xMin, tmp);
0.18 sec #movss, maxss, minss
__m128 tmp = _mm_load_ps(& p[ic]);
xMax = _mm_max_ps(xMax, tmp);
xMin = _mm_min_ps(xMin, tmp);
0.13 sec #movaps, maxps, minps

SSEの方はどっちも>311とは綺麗にクロック比になっている辺り。
それから察すると、>311はホントにfcmov使ってたんだろか。
つーか、fcmov遅過ぎ。

322 :デフォルトの名無しさん:2007/04/09(月) 13:24:06
わかりにくいから数字だけ書き直しとこ。

0.61sec fpu分岐版
0.64sec fpu分岐版(else if)
0.91sec fpu fcmov版
0.90sec fpu fcmov版(else if)
0.18sec sse scalar版
0.13sec sse vector版
つーか、sse vector > sse scalar >>>> fpu分岐 >> fpu fcmov ってか?

323 :・∀・)っ-○◎●:2007/04/11(水) 00:36:28
16bit整数×1億個で計測(10回回してるので10倍になってます)
gcc 3.3 i686-cygwin Celeron 2GHz(Northwood) FSB400MHz

非SIMD
3078ms -O3
1890ms -O3 -funloll-all-loops
3860ms -O3 -funloll-all-loops -msse
3892ms -O3 -funloll-all-loops -march=pentium4

-msse以上のオプションを指定すると無条件でCMOV使う感じ?


あと、参考までに
SSE(64bit SIMD)
2172ms -O3 -msse
1812ms -O3 -funloll-all-loops -msse
1750ms -O3 -funloll-all-loops -march=pentium4

SSE2(128bit SIMD)
1422ms -O3 -msse2
1407ms -O3 -funloll-all-loops -msse2
1313ms -O3 -funloll-all-loops -march=pentium4


Pentium4って倍速ALUだから非SIMDでもそこそこ速い?

324 :デフォルトの名無しさん:2007/04/11(水) 10:11:53
VTune9キター
ところでこのスレで使ってる人います・・?

325 :デフォルトの名無しさん:2007/04/11(水) 10:25:48
団子先生なら買う!!!

326 :デフォルトの名無しさん:2007/04/11(水) 12:37:18
VTune使いこなせてない漏れもいますよ。

処で>321だけど、流石にiccだとintrinsic使わないソースでもでもmaxps使ってくれるのね。
尤も、ループ回数が4の倍数じゃないときのロジックがおまけについてくるけど。
それと、詳細の数値忘れたけど(出先の)2coreXeon(3GHz)だとicc -fastで0.12secは掛かってた。
クロック差を考えると速いんだけど、-parallelにしたら却って遅くなってやんの。

>>323
ふむ、cmovも遅いのね。

327 :デフォルトの名無しさん:2007/04/14(土) 09:06:21
確か予測分岐はランダムな入力に対して学習しない、つまり予測を変えないから1/2の確率で的中するんだよな。
対してcmovは予測が無いから投棄が無い代わりに速くならない。

という事はフラグが余裕を持って決まっていればいいんじゃないかと思うんだが。
ただフラグレジスタが一つしかないから有効に使える場面が少なそうだ。

328 :デフォルトの名無しさん:2007/04/14(土) 09:22:54
あと予測をことごとく裏切る、つまり短いスパンで規則性のある入力に対してはcmovが有効だろう。
cmovは分岐テーブルも汚さないだろうから、ベンチマークではなく実際のプログラムではこれも効いてくるかも知れない。

329 :・∀・)っ-○◎●:2007/04/16(月) 23:46:01
そーいや、最大最小の問題は回数重ねると分岐パターンが収束してくわな。
NetBurstで32bit整数だと完全に汎用ALU>SIMDだね。
PMAXSD/PMAXUDまだ使えないから余計に不利。

330 :・∀・)っ-○◎●:2007/04/18(水) 01:28:48
CellのSPEの分岐ヒント命令っていいね
ある程度のコードの長さがあって分岐の十数クロック前に
ヒントを与えていれば、ミスを完全に防げる。

x86でフラグを更新しないのってleaとかSIMD演算命令くらいだが、
どうせSIMD使うならいっそ分岐先を両方実行してしまえばいいというジレンマ。
Penrynは拡販命令のスループットが大分よくなってるみたいなので
使い甲斐はありそう。

331 :デフォルトの名無しさん:2007/04/20(金) 21:21:15
沖縄県の方へ(命に関わる注意事項です)

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度(※)ですが、一度「一国二制度 沖縄 三千万」で検索をお願いします。
この際、民主党のHPで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
 簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
 (つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。)
 さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
 3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
 そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

332 :デフォルトの名無しさん:2007/04/21(土) 03:40:43
民主党といえば、民主党の公認候補が毎日のように22時過ぎまで駅前で名前を連呼しているんだが
あれは問題ないんだろうか。

333 :デフォルトの名無しさん:2007/04/21(土) 16:25:49
>332
通勤路では公明党と共産党がやってた。
調べたわけじゃないけど、拡声器を使わなければいいんじゃないかな。

使ってたら…シラネ。
(禁止行為にも地域差があるかもしれない)

334 :・∀・)っ-○◎●:2007/04/21(土) 19:32:21
スレ違いだろうが
アレだ、香港・澳門が厨国に返還されて、東アジアにおける資本主義諸国と共産主義大国間の
物流の橋渡しをする地域が無くなってしまった(台湾-厨国間の貿易拠点もなくなってしまった)。

沖縄を香港・澳門に変わる貿易拠点として解放すればいいという主張は以前からある。

335 :デフォルトの名無しさん:2007/04/22(日) 05:24:07
負け癖は抜けませんがみんすです

336 :デフォルトの名無しさん:2007/04/22(日) 12:18:18
仮に開放するにしても、下手なやり方だと日本にはいいことなさそうだな。

337 :デフォルトの名無しさん:2007/04/22(日) 13:12:20
Intelの最適化マニュアル
http://www.intel.com/design/processor/manuals/248966.pdf
によると
Meromでのpaddq/psubqの スループット-レイテンシ は 1-2 になっている

http://download.intel.com/technology/architecture/new-instructions-paper.pdf
の SSE4 Vectorizing Compiler and Media Accelerators から
64bit比較命令のpcmpgtqだけがPenrynに実装されない

Penrynでpaddq/psubqの改善はないと考えていいのだろうか?

338 :1 ◆.MeromIYCE :2007/04/24(火) 10:27:24
>>337
64bitCPUなのに64bit加算が苦手なのか?
add reg64,reg64 は、さすがにレイテンシ1でできると思うけど、
内部的には32bit*2段パイプで実現しているのかもね。

PenMでpaddqは3-2とのことだが、測定してみたら2-2に見える。
padddやporと混ぜてもレイテンシが3にはならなかった。
(ただ、混ぜたときのクロック数は不規則で、素直な命令ではない様子)
Meromでも、普通の命令の中では実質レイテンシ1で使えるんじゃないかな。
pcmpgtqが実装されないなら、paddqの改善はしてない方が自然だ。

339 :デフォルトの名無しさん:2007/04/26(木) 21:06:20
http://www.watch.impress.co.jp/akiba/hotline/20070421/image/ssc24.html

340 :デフォルトの名無しさん:2007/05/05(土) 14:59:09
AMD Family 10h Processors 最適化ガイドが公開された
http://developer.amd.com/devguides.jsp
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf

341 :・∀・)っ-○◎●:2007/05/05(土) 18:11:16
movapsにもレイテンシ2クロックかかんのかよ

342 :デフォルトの名無しさん:2007/05/05(土) 18:38:13
> 64bitCPUなのに64bit加算が苦手なのか?
AMD64の仕様自体が64bit苦手仕様だろw

343 :デフォルトの名無しさん:2007/05/06(日) 07:11:07
しょぼw

344 :デフォルトの名無しさん:2007/05/06(日) 13:28:51
コアが増えるなら別にいいんじゃね。

345 :デフォルトの名無しさん:2007/05/06(日) 18:36:40
ダンゴさんが書き込むとスレが引き締まるな

346 :デフォルトの名無しさん:2007/05/07(月) 20:31:45
L2レイテンシ9だって?

347 :デフォルトの名無しさん:2007/05/07(月) 21:12:45
なんかブロック図が想像してたのと違う。

Core−SRQ,XBar−HT,MC
       |
      L3

と思ってたのに

Core−L3−SRQ,XBar−HT,MC

に見える。
盛大な勘違いだったのだろうか。

348 :デフォルトの名無しさん:2007/05/07(月) 21:34:21
>>346
3(L1) + 9(L2) = 12
ではなくて?
これだとWindsorと変わらない気がするが。
Brisbaneから改良されたんかな。


347はやっぱ盛大な勘違いだった模様。
http://journal.mycom.co.jp/articles/2006/06/20/computex01/001.html
と「L3とメモリは同時にアクセス出来る」という話を聞いて勝手に予想してたんだけど、
この図のCBってMCとかHTが繋がってるXBARとは別なんだね。
http://journal.mycom.co.jp/special/2007/x2-65nm/015.html
こっちで大原もちゃんと言ってた…。

349 :デフォルトの名無しさん:2007/05/09(水) 15:30:34
適当なスレがないのでスレ違いを覚悟で質問します。
AMD64のアドレッシングモードのうち、レジスタオフセットに変位が付く形
はIA32と同じ32ビットまでしかできません。

これを64ビットの変位にまで拡張しなかったのは、必要ないからと判断
されたからなのでしょうか?レガシーx86の時のような問題は起きてこな
いのでしょうか?

350 :デフォルトの名無しさん:2007/05/09(水) 15:34:26
例えば分かりやすい例を挙げてみます。

2Gバイト超の配列を宣言したとして、その添え字に2GBを超える値を指定
してアクセスしたとします。すると、レジスタオフセットは32ビットまでしか使えま
せんので、2つのレジスタを使って

MOV RAX, 配列のベースアドレス
MOV RBX, 変位
MOV RCX, [RAX + RBX * n]

のような形になると思います。冗長になりませんか?

351 :デフォルトの名無しさん:2007/05/09(水) 16:37:18
MOV RCX,[RAX+imm64]みたいな命令がほしいってこと?
本当にいると思う?

352 :デフォルトの名無しさん:2007/05/09(水) 16:44:52
>>351
そうそうそんな奴があればいいなと思ってました。
まあ無くてもコンパイラが>>350みたいなコードに展開してくれるし
レジスタは多めなので問題はないと思うのですが、あってもいいような
気がします。

というのは私はよくCやC++のコンパイラでコンパイルしたコードをデバッグ
モードで眺めるのが好きなのですが、BSSやDATA領域の変数を
アクセスするコードが結構頻繁に出てくるのです。そういうのが>>351
ように書けたらすっきりすると思うのです。

まあいろいろ解析して不要と判断したのでしょうけどね。

353 :デフォルトの名無しさん:2007/05/09(水) 16:50:23
とくにAMD64やEM64Tは広大なメモリ領域を自由にアクセスできるように
なるわけじゃないですか。

まあこんな事にはそうそうならないと思うけどスタック領域に2GB超の配列を確保
する事もあるかもしれません。そういう場合に便利だと思うのです。

まあ配列と言えば大抵添え字でアクセスするので決め打ちの添え字で
ハードコーディングする機会は少ないと言えば少ないのでしょうけど。

354 :デフォルトの名無しさん:2007/05/09(水) 17:10:44
>スタック領域に2GB超
エエエエ ゜Д゜

355 :デフォルトの名無しさん:2007/05/09(水) 18:48:11
>>353
いや、だからイミディエイトで±2GB以上のオフセットが必要なシーンがどれだけあるのよ?
使うかどうかも分からん命令を命令マップのどこにアサインするのよ?
命令マップに座席を用意したとしても、64bitのイミディエイトを命令に
組み込めば、命令が8バイト伸びるってのも忘れちゃならんよ。
#ISAの設計の世界には「アイは高くつく」という格言があってだね...。

356 :デフォルトの名無しさん:2007/05/09(水) 19:26:49
個人的にはイミディエイト値の扱いなんて POWER 並みで十分だと思う。
アセンブラは読みにくくなるけど。

357 :1 ◆.MeromIYCE :2007/05/10(木) 00:14:29
http://pc.watch.impress.co.jp/docs/2007/0509/tawada103.htm
以前の予想通り200MHzのアップだったな。IDA。
現実的な線だった。

しかし、MeromなどモバイルCPUの涙ぐましい省電力機能を見るにつけ、
Vista憎いという心が強まる。
実際、切れるサービス切ったら非使用時のCPU使用率はXP程度とかに落ちないのかね。

358 :デフォルトの名無しさん:2007/05/10(木) 00:31:39
ユーザーが操作してない間は自由に動いてて構わないと思うけど。
ノートとかはプロフィールで軽くしてるだろうし、
ユーザーから見える情報が増えて心配の種が増えているだけでは。

まあどちらにしてもWINの不明瞭部分が多いだけだろ。

359 :138:2007/05/10(木) 01:46:57
やっぱりIDAショボーンだった…
kernel 2.6.25あたりで対応きぼんぬ

360 :デフォルトの名無しさん:2007/05/10(木) 03:10:39
地雷の965でしか動かさせないとなると怖いなぁ・・・

361 :デフォルトの名無しさん:2007/05/10(木) 16:39:46
>>347
(Core0-3 + L3)が独立小島でDRAMアクセスを含めた外の領域はL3を通して接続って形に見えるね。
スケーラビリティーを考えると妥当なやりかたにも思える。
コア領域とノースブリッジ領域の分離を明確にしたというか。

362 :デフォルトの名無しさん:2007/05/12(土) 22:02:04
>>361
しかしクロックや電圧供給ってCore0-3とL3+NBで分かれてたと思うんだけどねえ。
L3の位置もコアに挟まれてるんじゃなくてダイの端だし、一番遠いコアだとアクセス効率悪すぎる気もするのだが。

363 :デフォルトの名無しさん:2007/05/27(日) 23:56:38
IntelのCPUはNaN(非数)に対する演算が遅いという事なので、
加算、乗算、除算命令のクロック数を計測するプログラムを作成してみました。
ついでに非正規化数(デノーマル数)や∞の場合も調べてます。

http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=nan2.zip&refer=Upload

NaNの演算がかなり遅いというのはx87の場合だけで、
SSE,SSE2は遅くならないみたいですね。
プログラムを作成しない人にとってはNaNなんてどうでもいいことですが、
プログラムを作成する人にとっては、
プログラムを組んでみて、実行したら異常に時間がかかり、
やっと結果が出たと思ったら、途中で桁落ちしててNaNや∞だったなんて事は
ある事だと思います。

364 :デフォルトの名無しさん:2007/05/27(日) 23:58:00
●Core2Duoの結果
vender:GenuineIntel CPUID:6F6
x87 SSE SSE2
3.0 3.0 3.0 clk : 正規化数 + 正規化数 = 正規化数
5.0 4.0 5.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 18.0 32.0 clk : 正規化数 / 正規化数 = 正規化数
182.2 3.0 3.0 clk : 非数 + 正規化数 = 非数
184.2 4.0 5.0 clk : 非数 * 正規化数 = 非数
185.2 6.0 6.0 clk : 非数 / 正規化数 = 非数
193.2 3.0 3.0 clk : 非数 + 非数 = 非数
195.2 4.0 5.0 clk : 非数 * 非数 = 非数
196.2 6.0 6.0 clk : 非数 / 非数 = 非数
205.2 152.2 152.2 clk : 正規化数 + 非正規化数 = 正規化数
393.5 152.2 152.2 clk : 非正規化数 + 非正規化数 = 非正規化数
397.5 151.2 152.2 clk : 非正規化数 * 正規化数 = 非正規化数
438.3 162.2 175.2 clk : 非正規化数 / 正規化数 = 非正規化数
182.2 3.0 3.0 clk : +∞ + 正規化数 = +∞
181.2 4.0 5.0 clk : +∞ * 正規化数 = +∞
185.2 6.0 6.0 clk : +∞ / 正規化数 = +∞
181.2 3.0 3.0 clk : +∞ + +∞ = +∞
181.2 4.0 5.0 clk : +∞ * +∞ = +∞

365 :デフォルトの名無しさん:2007/05/28(月) 00:10:44
Opteron146でやってみた。
vender:AuthenticAMD CPUID:F71
x87 SSE SSE2
4.0 4.0 4.0 clk : 正規化数 + 正規化数 = 正規化数
4.0 4.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
20.0 16.0 20.0 clk : 正規化数 / 正規化数 = 正規化数
4.0 4.0 4.0 clk : 非数 + 正規化数 = 非数
4.0 4.0 4.0 clk : 非数 * 正規化数 = 非数
20.0 16.0 20.0 clk : 非数 / 正規化数 = 非数
4.0 4.0 4.0 clk : 非数 + 非数 = 非数
4.0 4.0 4.0 clk : 非数 * 非数 = 非数
20.0 16.0 20.0 clk : 非数 / 非数 = 非数
4.0 4.0 4.0 clk : 正規化数 + 非正規化数 = 正規化数
147.0 141.9 141.9 clk : 非正規化数 + 非正規化数 = 非正規化数
147.0 141.9 141.9 clk : 非正規化数 * 正規化数 = 非正規化数
163.0 153.9 157.9 clk : 非正規化数 / 正規化数 = 非正規化数
4.0 4.0 4.0 clk : +∞ + 正規化数 = +∞
4.0 4.0 4.0 clk : +∞ * 正規化数 = +∞
20.0 16.0 20.0 clk : +∞ / 正規化数 = +∞
4.0 4.0 4.0 clk : +∞ + +∞ = +∞
4.0 4.0 4.0 clk : +∞ * +∞ = +∞


366 :363:2007/05/28(月) 00:21:12
>>365
さすがOpteronはx87で非数、∞を使っても遅くならないですね。

367 :363:2007/05/28(月) 00:55:04
よく見るとOpteronは正規化数 + 非正規化数 = 正規化数でも遅くならないんですね。

368 :1 ◆.MeromIYCE :2007/05/28(月) 18:29:18
>>363
「現在、大変混み合っております。」ぐみゅう。

俺もレジスタを初期化せずにaddpsのレイテンシ測定とかやって、
「妙に遅いな」とか思ってたことがあったなあ。

マンデルブロ集合をSSEで計算するときも、
計算済みの場所はクリアしないとオーバーフローして遅くなる、
と思ってたが、SSEの∞加算・乗算はCore2でOKなのか。
今、PenMで測ってみても大丈夫っぽい。
上で書いたaddpsで遅くなったケースはCoppermineなので、
P6→PenMで改善されたのかもしれんね。

369 :363:2007/05/28(月) 20:19:35
>>363はずっと混雑しているみたいなので、
こちらにもアップロードさせてもらいました。
よかったら計測してみて下さい。
http://sakuratan.ddo.jp/uploader/source/date41109.zip

370 :デフォルトの名無しさん:2007/05/28(月) 20:37:55
Opteronじゃなくても結構いける
Athlon3500+
vender:AuthenticAMD CPUID:FF0
x87 SSE SSE2
4.0 4.0 4.0 clk : 正規化数 + 正規化数 = 正規化数
4.0 4.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
20.0 16.0 20.0 clk : 正規化数 / 正規化数 = 正規化数
4.0 4.0 4.0 clk : 非数 + 正規化数 = 非数
4.0 4.0 4.0 clk : 非数 * 正規化数 = 非数
20.0 16.0 20.0 clk : 非数 / 正規化数 = 非数
4.0 4.0 4.0 clk : 非数 + 非数 = 非数
4.0 4.0 4.0 clk : 非数 * 非数 = 非数
20.0 16.0 20.0 clk : 非数 / 非数 = 非数
4.0 4.0 4.0 clk : 正規化数 + 非正規化数 = 正規化数
147.0 141.9 141.9 clk : 非正規化数 + 非正規化数 = 非正規化数
147.0 141.9 141.9 clk : 非正規化数 * 正規化数 = 非正規化数
163.0 153.9 157.9 clk : 非正規化数 / 正規化数 = 非正規化数
4.0 4.0 4.0 clk : +∞ + 正規化数 = +∞
4.0 4.0 4.0 clk : +∞ * 正規化数 = +∞
20.0 16.0 20.0 clk : +∞ / 正規化数 = +∞
4.0 4.0 4.0 clk : +∞ + +∞ = +∞
4.0 4.0 4.0 clk : +∞ * +∞ = +∞


371 :デフォルトの名無しさん:2007/05/28(月) 20:54:11
>>370
AthlonXP3200+だとSSE2はないけどx87とSSEはほぼ同じ結果。

372 :1 ◆.MeromIYCE :2007/05/28(月) 20:59:27
>>369
肝心なときに役に立たないまとめサイトであった。

・PentiumM(Dothan-ULV 1.1GHz)
vender:GenuineIntel CPUID:6D6
x87 SSE SSE2
3.1 3.1 3.1 clk : 正規化数 + 正規化数 = 正規化数
5.0 4.0 5.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 18.0 32.0 clk : 正規化数 / 正規化数 = 正規化数
145.5 3.1 3.0 clk : 非数 + 正規化数 = 非数
147.4 4.0 5.0 clk : 非数 * 正規化数 = 非数
151.4 9.0 9.0 clk : 非数 / 正規化数 = 非数
155.5 3.0 3.1 clk : 非数 + 非数 = 非数
157.4 4.0 5.0 clk : 非数 * 非数 = 非数
161.4 9.0 9.0 clk : 非数 / 非数 = 非数
151.5 98.0 98.0 clk : 正規化数 + 非正規化数 = 正規化数
302.8 183.4 183.4 clk : 非正規化数 + 非正規化数 = 非正規化数
302.7 185.4 187.4 clk : 非正規化数 * 正規化数 = 非正規化数
343.7 204.4 218.4 clk : 非正規化数 / 正規化数 = 非正規化数
143.5 3.1 3.1 clk : +∞ + 正規化数 = +∞
139.4 4.0 5.0 clk : +∞ * 正規化数 = +∞
150.4 9.0 9.0 clk : +∞ / 正規化数 = +∞
143.5 3.0 3.1 clk : +∞ + +∞ = +∞
139.4 4.0 5.0 clk : +∞ * +∞ = +∞

実際にこの数字が性能に影響を与えるケースはほとんどないだろうけど、
Core2の、x87はいいからSSEを高速化したいという気持ちが見えるかな。

しかし、PenM→Core2で、レイテンシは全く変わってないな(除算以外)。
#お、無負荷なのにファンが回り始めた。さっきSpeedStep切ったからだ。
FPだと、1.0001をかけ続けても全然オーバーフローしないのね。

373 :デフォルトの名無しさん:2007/05/28(月) 22:51:35
ちょっと泣けるCeleron2GHz
vender:GenuineIntel CPUID:F27
x87 SSE SSE2
5.1 4.2 4.2 clk : 正規化数 + 正規化数 = 正規化数
7.1 6.1 6.2 clk : 正規化数 * 正規化数 = 正規化数
38.1 23.2 38.2 clk : 正規化数 / 正規化数 = 正規化数
906.4 4.1 4.1 clk : 非数 + 正規化数 = 非数
883.3 6.1 6.1 clk : 非数 * 正規化数 = 非数
904.0 23.1 38.1 clk : 非数 / 正規化数 = 非数
940.7 4.1 4.1 clk : 非数 + 非数 = 非数
941.4 6.1 6.1 clk : 非数 * 非数 = 非数
994.7 23.1 38.1 clk : 非数 / 非数 = 非数
960.7 858.4 989.6 clk : 正規化数 + 非正規化数 = 正規化数
1774.2 962.5 1037.5 clk : 非正規化数 + 非正規化数 = 非正規化数
1769.8 979.7 1022.4 clk : 非正規化数 * 正規化数 = 非正規化数
1849.3 1042.8 1093.6 clk : 非正規化数 / 正規化数 = 非正規化数
845.1 4.1 4.1 clk : +∞ + 正規化数 = +∞
868.7 6.1 6.1 clk : +∞ * 正規化数 = +∞
926.4 23.1 38.1 clk : +∞ / 正規化数 = +∞
869.0 4.1 4.1 clk : +∞ + +∞ = +∞
876.8 6.1 6.1 clk : +∞ * +∞ = +∞

374 :デフォルトの名無しさん:2007/05/28(月) 23:12:08
AthlonXP2400 です。

vender:AuthenticAMD CPUID:681
x87 SSE
4.0 4.0 clk : 正規化数 + 正規化数 = 正規化数
4.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
20.0 16.0 clk : 正規化数 / 正規化数 = 正規化数
4.0 4.0 clk : 非数 + 正規化数 = 非数
4.0 4.0 clk : 非数 * 正規化数 = 非数
20.0 16.0 clk : 非数 / 正規化数 = 非数
4.0 4.0 clk : 非数 + 非数 = 非数
4.0 4.0 clk : 非数 * 非数 = 非数
20.0 16.0 clk : 非数 / 非数 = 非数
4.0 4.0 clk : 正規化数 + 非正規化数 = 正規化数
142.9 135.8 clk : 非正規化数 + 非正規化数 = 非正規化数
142.9 135.8 clk : 非正規化数 * 正規化数 = 非正規化数
158.9 147.8 clk : 非正規化数 / 正規化数 = 非正規化数
4.0 4.0 clk : +∞ + 正規化数 = +∞
4.0 4.0 clk : +∞ * 正規化数 = +∞
20.0 16.0 clk : +∞ / 正規化数 = +∞
4.0 4.0 clk : +∞ + +∞ = +∞
4.0 4.0 clk : +∞ * +∞ = +∞

375 :デフォルトの名無しさん:2007/05/28(月) 23:55:02
AthlonXP-M 1800+でも>>374と同様

そしてまた空気を読まずにK6-2 400MHz

vender:AuthenticAMD CPUID:58C
x87
2.0 clk : 正規化数 + 正規化数 = 正規化数
2.0 clk : 正規化数 * 正規化数 = 正規化数
34.0 clk : 正規化数 / 正規化数 = 正規化数
4.0 clk : 非数 + 正規化数 = 非数
4.0 clk : 非数 * 正規化数 = 非数
4.0 clk : 非数 / 正規化数 = 非数
7.0 clk : 非数 + 非数 = 非数
7.0 clk : 非数 * 非数 = 非数
7.0 clk : 非数 / 非数 = 非数
3.0 clk : 正規化数 + 非正規化数 = 正規化数
20.0 clk : 非正規化数 + 非正規化数 = 非正規化数
19.0 clk : 非正規化数 * 正規化数 = 非正規化数
50.0 clk : 非正規化数 / 正規化数 = 非正規化数
4.0 clk : +∞ + 正規化数 = +∞
5.0 clk : +∞ * 正規化数 = +∞
7.0 clk : +∞ / 正規化数 = +∞
6.0 clk : +∞ + +∞ = +∞
5.0 clk : +∞ * +∞ = +∞

376 :デフォルトの名無しさん:2007/05/29(火) 07:26:21
http://pc11.2ch.net/test/read.cgi/jisaku/1179911252/
上記スレで強制NaNの計算でインテル不利にするベンチが論争を呼んでますが
しかえしに極端にAMD不利にする方法を探しています。
では。



377 :デフォルトの名無しさん:2007/05/29(火) 09:08:20
使われないx87が遅くても欠点ではないと思うけど、
SSEには無い命令などで、今でもx87は軽視できない、とな?

378 :デフォルトの名無しさん:2007/05/29(火) 09:32:18
Pentium2 です

vender:GenuineIntel CPUID:633
x87
3.0 clk : 正規化数 + 正規化数 = 正規化数
5.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 clk : 正規化数 / 正規化数 = 正規化数
104.6 clk : 非数 + 正規化数 = 非数
106.6 clk : 非数 * 正規化数 = 非数
110.6 clk : 非数 / 正規化数 = 非数
114.6 clk : 非数 + 非数 = 非数
116.6 clk : 非数 * 非数 = 非数
120.6 clk : 非数 / 非数 = 非数
113.6 clk : 正規化数 + 非正規化数 = 正規化数
216.6 clk : 非正規化数 + 非正規化数 = 非正規化数
217.6 clk : 非正規化数 * 正規化数 = 非正規化数
258.7 clk : 非正規化数 / 正規化数 = 非正規化数
103.6 clk : +∞ + 正規化数 = +∞
101.6 clk : +∞ * 正規化数 = +∞
111.6 clk : +∞ / 正規化数 = +∞
103.6 clk : +∞ + +∞ = +∞
101.6 clk : +∞ * +∞ = +∞


379 :デフォルトの名無しさん:2007/05/29(火) 11:04:27
くそ、お前らのせいでMMX Pentiumを探したくなって、
しかも見つけてしまったではないか。


ちょっとママン探してくるノシ

380 :363:2007/05/29(火) 20:51:43
たくさんの計測結果ありがとう。
AMDのCPUは昔からNaN,∞に強いんですね。
特にK6-2は非正規化数もかなり速いですね。
Netburstは強烈に遅くなりますね…(汗)
ただNetburstでもSSE,SSE2を使えばNaN,∞は問題ないですね。

381 :デフォルトの名無しさん:2007/05/29(火) 21:22:56
Athlon64X2 3800+@939だと>>370と同じだった
vender:AuthenticAMD CPUID:FB1
x87 SSE SSE2

382 :デフォルトの名無しさん:2007/05/30(水) 02:17:48
>>379
ワクテカ


383 :デフォルトの名無しさん:2007/05/30(水) 23:09:59
河童800

vender:GenuineIntel CPUID:686
x87 SSE
3.0 3.0 clk : 正規化数 + 正規化数 = 正規化数
5.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 18.0 clk : 正規化数 / 正規化数 = 正規化数
107.5 3.0 clk : 非数 + 正規化数 = 非数
109.4 4.0 clk : 非数 * 正規化数 = 非数
113.6 9.0 clk : 非数 / 正規化数 = 非数
115.5 3.0 clk : 非数 + 非数 = 非数
117.5 4.0 clk : 非数 * 非数 = 非数
121.6 9.0 clk : 非数 / 非数 = 非数
115.4 78.5 clk : 正規化数 + 非正規化数 = 正規化数
220.6 136.4 clk : 非正規化数 + 非正規化数 = 非正規化数
221.9 138.5 clk : 非正規化数 * 正規化数 = 非正規化数
263.6 158.6 clk : 非正規化数 / 正規化数 = 非正規化数
106.5 3.0 clk : +∞ + 正規化数 = +∞
105.5 4.0 clk : +∞ * 正規化数 = +∞
113.4 9.0 clk : +∞ / 正規化数 = +∞
106.5 3.0 clk : +∞ + +∞ = +∞
105.4 4.0 clk : +∞ * +∞ = +∞


384 :デフォルトの名無しさん:2007/05/31(木) 09:21:01
やべ、ママン見っける前にこっちに持って行きたくなっちまったw
ttp://www.faith-go.co.jp/sale/20th_cpu.asp

385 :363:2007/05/31(木) 20:38:14
>>383
あれ?CoppermineでもSSEはNaN,∞で問題ないですね…。

386 :デフォルトの名無しさん:2007/05/31(木) 22:53:54
Tualatin(P3-s)の1.13GHz
vender:GenuineIntel CPUID:6B1
x87 SSE
3.0 3.0 clk : 正規化数 + 正規化数 = 正規化数
5.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 18.0 clk : 正規化数 / 正規化数 = 正規化数
105.2 3.0 clk : 非数 + 正規化数 = 非数
107.2 4.0 clk : 非数 * 正規化数 = 非数
111.2 9.0 clk : 非数 / 正規化数 = 非数
115.2 3.0 clk : 非数 + 非数 = 非数
117.2 4.0 clk : 非数 * 非数 = 非数
121.3 9.0 clk : 非数 / 非数 = 非数
114.2 77.6 clk : 正規化数 + 非正規化数 = 正規化数
221.4 134.2 clk : 非正規化数 + 非正規化数 = 非正規化数
222.4 136.2 clk : 非正規化数 * 正規化数 = 非正規化数
263.4 155.2 clk : 非正規化数 / 正規化数 = 非正規化数
104.2 3.0 clk : +∞ + 正規化数 = +∞
102.2 4.0 clk : +∞ * 正規化数 = +∞
112.2 9.0 clk : +∞ / 正規化数 = +∞
103.6 3.0 clk : +∞ + +∞ = +∞
102.2 4.0 clk : +∞ * +∞ = +∞

387 :デフォルトの名無しさん:2007/06/03(日) 09:03:50
> AMDのCPUは昔からNaN,∞に強いんですね。
幾ら強くても普通にそれ使わないからムダw

388 :デフォルトの名無しさん:2007/06/03(日) 09:17:01
つかなんでNANとINF食うとストールするんだろ


389 :デフォルトの名無しさん:2007/06/03(日) 11:37:56
>388
どこかで場合わけして、該当したらマイクロコードに飛ぶんじゃない?

390 :デフォルトの名無しさん:2007/06/03(日) 16:02:44
MMX Pentium 166MHz

vender:GenuineIntel CPUID:543
x87
3.0 clk : 正規化数 + 正規化数 = 正規化数
3.0 clk : 正規化数 * 正規化数 = 正規化数
33.0 clk : 正規化数 / 正規化数 = 正規化数
70.1 clk : 非数 + 正規化数 = 非数
70.1 clk : 非数 * 正規化数 = 非数
71.1 clk : 非数 / 正規化数 = 非数
102.1 clk : 非数 + 非数 = 非数
102.1 clk : 非数 * 非数 = 非数
104.1 clk : 非数 / 非数 = 非数
76.0 clk : 正規化数 + 非正規化数 = 正規化数
184.1 clk : 非正規化数 + 非正規化数 = 非正規化数
181.1 clk : 非正規化数 * 正規化数 = 非正規化数
214.1 clk : 非正規化数 / 正規化数 = 非正規化数
66.1 clk : +∞ + 正規化数 = +∞
75.1 clk : +∞ * 正規化数 = +∞
83.1 clk : +∞ / 正規化数 = +∞
75.1 clk : +∞ + +∞ = +∞
70.1 clk : +∞ * +∞ = +∞

391 :デフォルトの名無しさん:2007/06/10(日) 10:14:59
>>389
そういえばそんな物あったね、もうね、すっかり失念。


392 :1 ◆.MeromIYCE :2007/06/11(月) 11:41:04
Coppermine-128K Celeron-400MHz
vender:GenuineIntel CPUID:681
x87 SSE
3.0 3.0 clk : 正規化数 + 正規化数 = 正規化数
5.0 4.0 clk : 正規化数 * 正規化数 = 正規化数
32.0 18.0 clk : 正規化数 / 正規化数 = 正規化数
104.6 3.0 clk : 非数 + 正規化数 = 非数
106.6 4.0 clk : 非数 * 正規化数 = 非数
110.6 9.0 clk : 非数 / 正規化数 = 非数
115.6 3.0 clk : 非数 + 非数 = 非数
117.6 4.0 clk : 非数 * 非数 = 非数
121.6 9.0 clk : 非数 / 非数 = 非数
113.6 77.6 clk : 正規化数 + 非正規化数 = 正規化数
215.6 133.6 clk : 非正規化数 + 非正規化数 = 非正規化数
216.6 135.6 clk : 非正規化数 * 正規化数 = 非正規化数
257.6 154.6 clk : 非正規化数 / 正規化数 = 非正規化数
103.6 3.0 clk : +∞ + 正規化数 = +∞
101.6 4.0 clk : +∞ * 正規化数 = +∞
111.6 9.0 clk : +∞ / 正規化数 = +∞
103.6 3.0 clk : +∞ + +∞ = +∞
101.6 4.0 clk : +∞ * +∞ = +∞

>>368は、たまたま非正規化数で測ってしまって勘違いしたのかな。
>>383とほぼ同じだ。こちらが少し速いのは、クロックの差か、ステッピングか、測定誤差か。
むしろ>>378に近い数字だ。

>>390
性格はP6と同じっぽいね。やはり古いだけあってクロック当たりの性能はいいけど。
小数点以下の数字が、みんな1なのが面白い。

393 :1 ◆.MeromIYCE :2007/06/11(月) 14:01:42
>>376
テーマとしては面白いね。
K8に対して、Northwoodが勝つにはadd eax,eaxを繰り返せばクロック当たりで倍の性能になる。
K8に対してPentiumMが勝つには、paddd mm0,mm0を繰り返せばこれも倍。
あとは排他キャッシュの弱点をえぐり出すことかな。

Prescottが勝つのはどうするんだろ。
別にadd eax,eaxでもクロック当たりで互角だから、高クロック型のPrescottが勝ちと言えるけど、
どうせならクロック当たりの性能でも勝つのを考えたいよな。
単にL2帯域で比べてもいいが、それじゃ面白くない。K8は弱点少ないから攻めにくいねえ。

394 :デフォルトの名無しさん:2007/06/11(月) 14:29:43
俺はAMDユーザーだからIntelに負けて欲しいな。

395 :・∀・)っ-○◎●:2007/06/11(月) 21:51:03
ららびー

396 :デフォルトの名無しさん:2007/06/12(火) 00:10:28
そういえば団子のサイトのRSSっておかしくね?

397 :デフォルトの名無しさん:2007/06/12(火) 00:12:00
団子ちゃんのサイトなんてあったの!?
ちょー見てー! アドレス教えて!

398 :・∀・)っ-○◎●:2007/06/12(火) 00:14:29
SPAMトラックバック掃除したときに消したまんまだ

なんか記事更新すれば再生成されるからマットれ


ネタは>>395

399 :デフォルトの名無しさん:2007/06/12(火) 00:35:24
ぐぐったら http://www.sourcream.jp/archives/2007/03/00081.php
これがトップにきたんだけど、団子ちゃんってこんなにめんこかったのか! (*´Д`*)

400 :・∀・)っ-○◎●:2007/06/12(火) 07:35:36
掃除前の記事はRSSに出ないみたいだね。

401 :デフォルトの名無しさん:2007/06/15(金) 00:20:45
http://pc11.2ch.net/test/read.cgi/mac/1159817811/794
Page31
Gesherの 7 DP Flop/cycle/core の内訳を予想してみた

FPADD: 2 DP(4 SP)
FPMUL: 2 DP(4 SP)
Dot Product@SSE4.1: 3 DP(7 SP)

402 :401:2007/06/15(金) 01:43:25
Dot Product(内積)命令については以下の資料を参照
Page18
https://intel.wingateweb.com/published/BMAS005/BMAS005_100Eng.pdf
Page65-70
http://softwarecommunity.intel.com/isn/Downloads/Intel%20SSE4%20Programming%20Reference.pdf

403 :・∀・)っ-○◎●:2007/06/21(木) 23:39:39
P35マザーで組んだけどなんか人柱依頼ある?

#E6420を2.66GHzで動かしてたりするんだがwwww

404 :1 ◆.MeromIYCE :2007/06/22(金) 00:01:08
>>403
こういうときのために平素から測定プログラムを作っておくんだったと後悔しきり。
とはいえ最近、自分で高速化する需要が減ってたりする。

やはり自分で何か作って、それを高速化したいとなって初めて
クロック測定の意欲が出てくるんだなあと、このごろ思うのです。
#ららびーでマンデルブロ集合描かせるくらいしか夢がない。

405 :・∀・)っ-○◎●:2007/06/22(金) 00:19:46
ちょうどVista x64動かしてるから命令長ネックの検証でもしてみるのも手だと思うけど


406 :1 ◆.MeromIYCE :2007/06/22(金) 00:38:27
うお!64bitOSかよ。それを先に言え。
つっても俺は環境なしにコード書けるほど器用じゃない。すまん。

407 :デフォルトの名無しさん:2007/06/23(土) 16:49:54
そこでVMwareに64bitLinuxですよ


408 :・∀・)っ-○◎●:2007/06/23(土) 18:29:39
アレってx64非対応の石でも使えたっけ?
QEMUならx64エミュレータあるね

409 :デフォルトの名無しさん:2007/06/24(日) 11:02:21
>>408
今時amd64非対応の石なんて使ってないだろ。

32bitOSの上でも64bitOS動かせるからそうしろってこと。

410 :デフォルトの名無しさん:2007/06/24(日) 16:29:52
動かせないよ

411 :・∀・)っ-○◎●:2007/06/24(日) 16:46:56
GeodeやCore (2じゃないほう) Duo/Soloは非対応だよ。
モバイル用途ではまだまだ現役。

てか1の中の人のPCはLV Dothanじゃなかったっけ

412 :デフォルトの名無しさん:2007/06/24(日) 17:50:13
>>410
VMwareなら動かせるよ。

413 :デフォルトの名無しさん:2007/06/24(日) 19:53:29
VMWareはx64が使えれば動かせるな

414 :デフォルトの名無しさん:2007/06/24(日) 23:28:14
C2DだけどXP(32bit)の上ではx64版の犬がインストールできなかった

415 :デフォルトの名無しさん:2007/06/24(日) 23:43:40
>>414
ちゃんとVTをオンにしているんだろうな。

416 :デフォルトの名無しさん:2007/06/25(月) 00:11:55
え、VMware使ったら32bitのホストOSの上で64bitのゲストOS動かせんの?
今までホストも64bitじゃないと無理だと思ってたんだが。

417 :デフォルトの名無しさん:2007/06/25(月) 00:21:11
お前の思いこみを吐露しろなんて誰もいってないぞ。

418 :410 = 414:2007/06/25(月) 00:34:19
>>415
うっ、、、してなかった;;

419 :デフォルトの名無しさん:2007/06/27(水) 19:19:27
531 :Socket774:2007/06/27(水) 17:29:08 ID:7g9GfI7V
・・・Barcelonaの値段出てるみたいだけど、そんなに高くないか。
ただ、上位は消費電力も性能も値段もウンコだな。

2340 1.9GHz 95W $320
2350 2.0GHz 95W $390
2352 2.1GHz 95W $450
2354 2.2GHz 95W $610
2356 2.3GHz 95W $795
2358 2.4GHz 120W $1180
2360 2.5GHz 120W TBA

537 :Socket774:2007/06/27(水) 18:11:48 ID:V0//xVyS
>>531
登場時期も書いてやれ。

9月10日
2340 1.9GHz 95W $320
2350 2.0GHz 95W $390
10月
2352 2.1GHz 95W $450
2354 2.2GHz 95W $610
たぶん年内
2356 2.3GHz 95W $795
2358 2.4GHz 120W $1180
すぐには出ない
2360 2.5GHz 120W TBA

420 :・∀・)っ-○◎●:2007/06/29(金) 02:25:42
強気すぎるだろwwwwww
Q6600ですら95Wで266ドルになるのに。

AMDのTDPはK10からIntelと共通化したとか。

421 :デフォルトの名無しさん:2007/06/29(金) 03:37:55
何で1PのQ6600が出てくるのか

422 :・∀・)っ-○◎●:2007/06/29(金) 03:41:32
ああ2Way Opteronか。

と思ってXeonの改定価格みてきた。
Conroe/Kentsfieldと大して変わらんじゃないか

AMDの中の人正気?

423 :デフォルトの名無しさん:2007/06/29(金) 20:42:38
596 :MACオタ:2007/06/29(金) 19:11:00 ID:hM78bIG1
最近の書き込みを読む限り、やっとこのスレも現実を直視できる普通のヒトが増えてきたすね。
アム虫と呼ばれた連中が出て行ってくれたのわ結構な話す。
さてBarcelona搭載予定のSUNの"Constellation System"のニュースわ周知のことと思うす。
http://japan.cnet.com/news/ent/story/0,2000056022,20351637,00.htm
TACC (Texas Advanced Computing Center)のサイトで仕様の詳細を読むと、
http://www.tacc.utexas.edu/resources/hpcsystems/#ranger
 ・13,152プロセッサ
 ・クアドコアアップグレード版で予想ピーク性能: 421TFlops
これから動作クロックを計算すると、Barcelonaわコアあたり4-flopsすから、
 420 x 10^3 [GFlops] / ( 13,152 [processors] x 4 [core] * 4 [flops/core] ) 〜 2.0 [GHz]
となるす。
今年いっぱいわ、最重要顧客向ですら提供できるのが2GHzということが判るす。

424 :デフォルトの名無しさん:2007/06/30(土) 02:55:43
http://techreport.com/onearticle.x/12777

xeonに信頼性なんて無いんですかねぇ…

425 :デフォルトの名無しさん:2007/06/30(土) 08:30:27
Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu.
信頼性が無いのはお前の頭だと思う...

426 :デフォルトの名無しさん:2007/06/30(土) 12:07:39
>>425
テオ様が痛い人なのは同意だけど、技術的な嘘を付くような人ではないと思うぞ。
OS作成者から見て嫌なバグとアプリケーション開発者からみて嫌なバグは違うし。

427 :MACオタ>426 さん:2007/06/30(土) 14:46:11
>>426
  ----------------
  OS作成者から見て嫌なバグとアプリケーション開発者からみて嫌なバグ
  ----------------
そういった問題ですら無いみたいすけど。。。
http://www.geocities.jp/andosprocinfo/wadai07/20070630.htm
  =================
  まあ,ハードのバグと言えばバグですが,リザーブの値を書き込んでいるBIOSだってバグ
  だよねという感じのバグです。
  =================

428 :デフォルトの名無しさん:2007/06/30(土) 16:42:14
NHK「本日未明、ド田舎村で不発弾が発見されそれを自衛隊が処理しました。」
>>424「日本って超危険な国家だったんだ。国外に脱出せねば。」

429 :デフォルトの名無しさん:2007/07/02(月) 20:18:34
このスレで話題になってたと思うけどBarcelonaのL3接続図
ttp://opentechpress.jp/enterprise/article.pl?sid=07/07/02/0831208&from=rss
これ、なんの資料から取り出したのかわからんけど全部L3経由になってんの。
真実はどこにー。

430 :デフォルトの名無しさん:2007/07/02(月) 20:25:06
見つけた。これだわ。
ttp://multicore.amd.com/us-en/AMD-Multi-Core/Products/Barcelona.aspx
オフィシャル画像だからそうなんだろーなー。
マルチコア且つマルチチップを念頭に置いたらこうなったって感じなのかなあ。
個人的には4コアで十分だからあとはメモリバス幅を広げるためだけの
ブリッジコアみたいなのが出て欲しい。

431 :デフォルトの名無しさん:2007/07/02(月) 22:39:47
>>429
IntelもL$2経由で接続するし、HT経由より速いんじゃないか?

432 :デフォルトの名無しさん:2007/07/06(金) 02:54:28
>>430
こう考えるんだ。

各種I/OもCPU内蔵キャッシュの恩恵にあずかれると。


433 :デフォルトの名無しさん:2007/07/06(金) 04:14:58
ライトバックだったらイヤだな

434 :デフォルトの名無しさん:2007/07/06(金) 06:44:48
>>432
バカ?

435 :デフォルトの名無しさん:2007/07/07(土) 03:14:12
>>434
ネタにマジレスかこわるい

436 :デフォルトの名無しさん:2007/07/18(水) 20:56:33
532 :名無しさん@5周年:2007/07/16(月) 06:50:45
NVIDIA、G80ベースのHPC向けGPU「Tesla」 〜PCI Expressカードタイプから1Uラックまで
http://pc.watch.impress.co.jp/docs/2007/0621/nvidia.htm


535 :名無しさん@5周年:2007/07/16(月) 16:37:16
>>532
1,499ドルか
日本円にすると18万円くらいか
これってコストパフォーマンスいい方?

536 :名無しさん@5周年:2007/07/16(月) 17:31:25
単精度もろくに実装してないゴミに18万も払ってどうするの

537 :名無しさん@5周年:2007/07/17(火) 14:09:58
>>536 倍精度の間違いだろ

どのへんが導入するんだろうねコレ

539 :名無しさん@5周年:2007/07/18(水) 13:55:41
>>537
http://developer.download.nvidia.com/compute/cuda/1_0/NVIDIA_CUDA_Programming_Guide_1.0.pdf
For addition and multiplication, only round-to-nearest-even and round-towards-zero are supported via static rounding modes
directed rounding towards +/- infinity is not supported

437 :デフォルトの名無しさん:2007/07/19(木) 00:27:25
vtuneの話はここでいいですかね

438 :・∀・)っ-○◎●:2007/07/20(金) 01:19:22
同じ18万ならAmiga最上位版買うな

439 :デフォルトの名無しさん:2007/07/20(金) 01:33:38
同じ18万なら8800GTX搭載Core2Duo搭載のPC一台組むな。

440 :デフォルトの名無しさん:2007/08/08(水) 10:58:52
age

441 :デフォルトの名無しさん:2007/08/18(土) 18:37:56
AMD K10 Micro-Architecture
http://www.xbitlabs.com/articles/cpu/display/amd-k10.html

442 :1 ◆.MeromIYCE :2007/08/19(日) 09:50:31
>>441
ピークIPCこそ3のままだが、32byteフェッチとSSEがDirectPathになるのが大きい。
SSEのロードも高速化されるし、命令の流れは相当スムースになると思う。

シャッフル系SSEの性能が気になるところ。
スタックエンジンに当たるものは、Intelと少し違うように見えるが、
そもそもIntelのやつも、どの程度スタックのオーバーヘッドが残るのか知らないしな。

サーバー向け4コアをターゲットに最適化してるっぽいから、
最初の一般向けデュアルコアの勝負では微妙な感じもする。
まあ、そのうち4コアが主流になるだろうから長期的にはむしろ有利か。
#てかクロックがもうちょっと上がらないときつい気が・・・

443 :MACオタ>1 さん:2007/08/19(日) 12:50:50
>>442
以前から疑問だったすけど、立ち寄ったついでに質問させていただくす。
  ---------------------
  ピークIPCこそ3のままだが、
  ---------------------
AMDのプロセッサの場合issue queue(x86的にわROBすか?)にわロードと演算命令が
マージされたMacro-Opsとして格納され、実行時に2つのMicro-Opsに分解されるす。
これってIPC的にわ6命令と数えないすか?


444 :デフォルトの名無しさん:2007/08/19(日) 14:30:03
それはインテル流に言えばUPC(micro-ops per cycle)。

445 :デフォルトの名無しさん:2007/08/19(日) 14:38:03
MACオタがマイクロアーキテクチャをよく理解していないということがわかるな。
>>1のいっているピークIPCとはプロセッサのパイプラインにおいて
理論的に持続可能な命令レートを指しているので、IPC=3にほかならない。

446 :デフォルトの名無しさん:2007/08/19(日) 15:26:10
あんま関係ないけど最近IPCって言葉が乱用されすぎだよね。
大原氏が発端だと思うけど、プロセッサの内部の話でIPCという言葉は不適切だと思う。
○○並列とか○○issueみたいにハード的な見地の用語で統一してほしい。
IPCはソフトを走らせたときの話でよくでてくる用語だからなあ。
特に内部ステージで局所的に命令がいくら流れようがIPC(=ソフトから見える)には影響しないわけで。

447 :デフォルトの名無しさん:2007/08/19(日) 15:29:03
○○並列というのはないか。
○○wayというも今時のプロセッサにはアレだし。
retire/cycleとか使っているのは最近みた。

448 :デフォルトの名無しさん:2007/08/19(日) 17:48:42
リタイアメントuOPs数で比較する?

449 :1 ◆.MeromIYCE :2007/08/19(日) 19:59:46
>>443
俺が言ったのは、1clkにつきx86命令を(持続的に)3つを超えては処理できないということ。
ところで、最近自作板でも面白い話題が少ないねー。

まあ、>>446みたいなことは俺も思う。
命令の単位が、x86命令か、Macro-Opsか、Micro-Opsか、スタックエンジン等は含めるのか、
好きな命令か、与えられた命令か、持続できる性能か、瞬間的な性能か、平均的な性能か、
単にIPCと書いたときは、これらのことを省略して書いたことになるわけですな。

>>442では、このスレなら(言葉が適切かどうかはともかく)言いたいことが簡単に伝わると思って使った。
ニュアンスとしては、K8のデコード・発行・ALU・リタイヤのユニットがきれいに3つずつであるように
今度のAMDが出す新CPUも「3つずつ」という構造は同じっぽいなあ、という感じ。
わかりにくいならすまんかった。

450 :MACオタ>1 さん:2007/08/19(日) 20:45:04
>>449
かなり初期からMicro-ops fusion相当の機能を持つ命令処理ユニットを備えていたAMDのアーキテクチャわ、
比較的小さな進歩でx86命令換算でのIPCを上げる潜在能力を持つと思うという話だったすけど。K8Lのレベル
でわ望み薄すか。。。
  --------------------------
  単にIPCと書いたときは、これらのことを省略して書いたことになるわけですな。
  --------------------------
ベンチマークとして広く使われるDhrystoneだと、結果の単位わMIPSでも異なるアーキテクチャを比較するために
標準システムでの結果との比を取っているだけすから、深く考える必要も無いかと思うす。

451 :1 ◆.MeromIYCE :2007/08/19(日) 21:23:57
>>450
いや平均IPCは上がるでしょ。
Core2みたいなマクロフュージョンがないならピークIPCを上げることは無理だけど。
でも、ピークIPCを上げる目的は、平均IPCを上げることだから無問題。

> 深く考える必要も無いかと思うす。
Dhrystoneの話とわかっていてそのベンチ内容も知っている読み手ならいいが、
そうでないときの乱用が最近目立つから困ると言っているのだ。

452 :・∀・)っ-○◎●:2007/08/19(日) 21:27:52
白い変人ことだんごです。
賞味期限切れてることは内緒です。

453 :デフォルトの名無しさん:2007/08/21(火) 14:53:32
>>451

454 :デフォルトの名無しさん:2007/08/21(火) 15:14:50



455 :デフォルトの名無しさん:2007/08/22(水) 21:27:19
これと
xchg edx, [eax]
これ
mov ecx, [eax]
mov [eax], edx
mov edx, ecx
どっちが早い

456 :デフォルトの名無しさん:2007/08/22(水) 21:32:55
なんか、デジャヴが

457 :デフォルトの名無しさん:2007/08/22(水) 21:37:00
319 名前:名無したん(;´Д`)ハァハァ[sage] 投稿日:2007/08/22(水) 16:08:34 ID:aEA9W/2t
ttp://kissho2.xii.jp/20/src/2yoshi2512.7z.html 目欄
344 名前:名無したん(;´Д`)ハァハァ[sage] 投稿日:2007/08/22(水) 18:55:20 ID:YevU/rPG
>>319はウイルス。拡張子が怪しすぐる

らき☆すた 27
http://sakura03.bbspink.com/test/read.cgi/ascii2d/1187586266/

458 :・∀・)っ-○◎●:2007/08/23(木) 00:16:27
>>455
んなもんCPUによる
少なくともP6系アーキでは前者はストールしまくりんぐ

ところで計測くらい自分でできるよな?

459 :1 ◆.MeromIYCE :2007/08/23(木) 10:13:19
xchg edx, [eax] は19clkとかかかって、何でこんなに遅いんだと思ったら、
LOCKがかかるのね(詳しい動作は知らんけど)。

早くデュアルコア欲しいなあ。

460 :デフォルトの名無しさん:2007/08/25(土) 22:12:01
These improvements should help K10 execute programs written in high-level object-oriented code much faster.
Unfortunately, it is very hard to objectively estimate the efficiency of the K10 branch prediction unit, but according to some data, it may be lower in some cases than by Intel processors.

他にもあるが全体的にK8Lは劣化版Coreって感じだな。
あ、プロセサコアの話ね。念のため。

461 :・∀・)っ-○◎●:2007/08/25(土) 22:23:17
Pentium Mで導入された間接分岐の予測器をようやく採用したのか



462 :デフォルトの名無しさん:2007/08/25(土) 22:28:38
間接分岐の予測自体は以前からあるけどな
前回と同じ場所に分岐するという簡素なものだけど

463 :・∀・)っ-○◎●:2007/08/25(土) 22:37:33
Quick and Dirty Quad-Core "Penryn" Benchmarks
http://www.dailytech.com/article.aspx?newsid=8585

SSE4とか除算とか使わない限り速さは実感できないかなこれ。

ICC10のsmmintrin.hとnmmintrin.hでSSE4利用可能っぽい。

464 :デフォルトの名無しさん:2007/08/25(土) 23:18:13
ICL10ちゃうの?

465 :デフォルトの名無しさん:2007/08/25(土) 23:26:40
>>464
ICLってなに?
IntelCompilerのことなら、通常iccというと思うのだけれど。

466 :デフォルトの名無しさん:2007/08/25(土) 23:29:12
コマンド名っしょ。
LinuxがccをもじってiccでWindowsがVisual C++のコマンド名clをもじってicl。

467 :・∀・)っ-○◎●:2007/08/25(土) 23:29:27
EXEの名前がicl.exe
Visual C++の略称がclだと思ってるんだよきっと。

468 :・∀・)っ-○◎●:2007/08/25(土) 23:30:16
>>466
ICCはIntel C/C++ Compilerの頭文字とったものだと思ってたが


469 :デフォルトの名無しさん:2007/08/25(土) 23:34:35
ccがc compilerなんだからモジってようがモジってまいが
Intel C/C++ Compilerで間違っちゃいないでしょ。

470 :デフォルトの名無しさん:2007/08/28(火) 01:54:00
Linux/ICC,Win/ICLで使い分けることはあるにしろどっちでも通じると思ってた
まぁどうでもいいじゃん

471 :デフォルトの名無しさん:2007/08/28(火) 14:36:41
確かにどっちでもいいが





コマンド名的にはどう考えてもiccのが美しい

472 :デフォルトの名無しさん:2007/08/28(火) 19:56:45
oic

473 :デフォルトの名無しさん:2007/08/29(水) 23:49:38
コンピュータアーキテクチャの話
(91) シフト回路(シフター)
http://journal.mycom.co.jp/column/architecture/091/index.html
> 例えば、IntelのCore 2プロセサのデータシートでは、ADD/SUBは
> 1サイクル(短い場合は0.5サイクルの命令もある)で終わるのであ
> るが、シフト命令は4サイクルを必要としている。

正確には、Core 2のデータが書かれている
"Intel(R) 64 and IA-32 ArchitecturesOptimization Reference Manual"
http://developer.intel.com/products/processor/manuals/index.htm
のWillamette/Northwood(Family_Model:0F_02H)のデータだと思われる
少し紛らわしい

474 :デフォルトの名無しさん:2007/08/30(木) 10:08:44
>少し紛らわしい
どころじゃないんじゃね?

475 :デフォルトの名無しさん:2007/08/30(木) 16:09:22
実際のところはダンゴさんにピシっと語っていただこう

476 :デフォルトの名無しさん:2007/08/30(木) 16:51:24
ttp://pc.watch.impress.co.jp/docs/2007/0830/amd2.htm
AMD、新たなx86拡張命令セット「SSE5」〜「Bulldozer」コアに搭載予定

まったクソややこしいことしくさるな、AMDは。

477 :デフォルトの名無しさん:2007/08/30(木) 18:20:22
オペランドが増えているのにソースの一つにメモリを指定出来るのが面白いな。

478 :デフォルトの名無しさん:2007/08/30(木) 20:04:45
PCMOVはMMXのころから欲しかった機能だ

479 :・∀・)っ-○◎●:2007/09/02(日) 08:22:23
Intelは放置する

480 :デフォルトの名無しさん:2007/09/02(日) 09:05:51
CMOVPS/PDがないな

481 :・∀・)っ-○◎●:2007/09/02(日) 10:32:14
CPUID EAX:80000001に定義ビットがあるようなものをIntelが採用するわけがない。
(唯一の例外はx64回り)


482 :デフォルトの名無しさん:2007/09/02(日) 17:37:18
>>481
期待して自分が傷つきたくないだけでしょ。

483 :・∀・)っ-○◎●:2007/09/02(日) 17:58:06
本質的にはこうなんだよ

Intel: SSSE3+SSE4.1+SSE4.2
AMD: SSE4A+SSE5A

というかどうみてもAMDが無断で使った名前です。本当にありがとうございました。
「3DNow! 128」にしてくれ。


484 :デフォルトの名無しさん:2007/09/02(日) 18:32:26
いや、むしろIntelのと比較するとDSPNow!だな。

485 :・∀・)っ-○◎●:2007/09/02(日) 18:35:38
確かに内積演算なんかはIntelのがリッチに見える。
AMDのはIBMがかんでるせいかAltiVecっぽいオペレーションが統合されてる。

486 :デフォルトの名無しさん:2007/09/02(日) 18:45:10
ダンゴさんが語るとスレが引き締まるな

487 :・∀・)っ[486]:2007/09/02(日) 18:51:17
なにこいつ

488 :デフォルトの名無しさん:2007/09/03(月) 20:01:32
Intel64に続いてSSE5の登場か・・・言ったもん勝ちだな

489 :デフォルトの名無しさん:2007/09/06(木) 00:38:03
x64をAMD64と呼び
SIMD拡張をSSE5と呼ぶ






こういう挑発ばっかしてないでさっさとK10出せ

490 :デフォルトの名無しさん:2007/09/06(木) 12:18:22
>>489
x64ってめちゃくちゃダサいっていうか意味不明だろ。
xってなんだ?

491 :デフォルトの名無しさん:2007/09/06(木) 12:32:09
x86-64と書くのが自分のお気に入り。

492 :デフォルトの名無しさん:2007/09/06(木) 16:48:16
ちょwwwそれお気に入りでもなんでもないだろ

493 :デフォルトの名無しさん:2007/09/07(金) 22:29:34
いっそx68にすべきだったな

494 :デフォルトの名無しさん:2007/09/08(土) 01:57:37
リトルエンディアンのアーキテクチャに68と付けるな!

495 :デフォルトの名無しさん:2007/09/08(土) 12:04:53
Intel Core2 Duo E6800

496 :デフォルトの名無しさん:2007/09/10(月) 22:54:10
http://techreport.com/articles.x/13176
http://www.anandtech.com/IT/showdoc.aspx?i=3091
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3092
http://www.tecchannel.de/server/prozessoren/1729224/

497 :1 ◆.MeromIYCE :2007/09/17(月) 11:16:06
いよいよベールを脱ぐIntelの次期CPU「Nehalem」
http://pc.watch.impress.co.jp/docs/2007/0916/kaigai386.htm

Nehalemについて。
ネイティブクアッドコアということで、ノート用のデュアルコアをうまく作れるかに注目したい。
まあ、ノートは当面Core2一本で行くような気がするけど。
キャッシュは共有8MB。今のCore2は65nmで4MB、45nmのPenrynで6MBなので、
45nmから始まるNehalemでは妥当なところだろう。

拡張命令は、MeromのSSSE3、PenrynのSSE4に続いて、ATAという特定用途向けを載せる。
下の記事では、CRCチェックをすると言われている。
http://pc.watch.impress.co.jp/docs/2006/1004/kaigai307.htm

各コアにSMTを載せているというのが驚きだ。
4コア*2で8スレッドを並列実行できることになる。
これは、Core2の弱点であった命令フェッチをかなり強化していると思っていいだろう。

「Turbo Mode」については不明ということだが、IDAの改良版だろう。
Vistaでも働くようになるかなあ。この辺りは、OSの協力も欲しいところではある。

TDPは最大のもので130W。今とあまり変わらない感じだ。

そして、ついにメモリコントローラが統合された。3チャネルのDDR3となる。
その他の入出力はIntel QuickPath interconnectというシリアルインターフェイスになる。
よくわからんが、最近のボトルネックらしいので、かなり強化される模様。

個人的には、コア数のバリエーションとキャッシュ構造が一番気になるところだ。
#最近こういう記事がなかったんで、既出情報も多いのに全然覚えてなかった。。

498 :デフォルトの名無しさん:2007/09/17(月) 11:44:20
Intel uPs Info 2 落ちたにょ

499 :デフォルトの名無しさん:2007/09/17(月) 12:41:27
> ついにメモリコントローラが統合された

大爆笑

500 :デフォルトの名無しさん:2007/09/17(月) 18:41:56
を? 今までは非同期SRAMすら直付け出来なかったとか?


501 :1 ◆.MeromIYCE :2007/09/21(金) 10:24:48
チックとタック。あなたの好みはどちら
http://pc.watch.impress.co.jp/docs/2007/0921/mobile393.htm

俺はやっぱりPenryn萌えだなあ。今使ってるのも「チック」のDothanだ。
確かにNehalemも燃えるんだけどね。しみじみとした情緒が欲しい。

502 :デフォルトの名無しさん:2007/09/21(金) 20:49:59
Silverthron@0.55W未満 の実働デモに萌えた
http://pc.watch.impress.co.jp/docs/2007/0921/idf06.htm

503 :・∀・)っ-○◎●:2007/09/25(火) 07:19:44
Yorkfieldは買うじぇ

こいつは既出?
http://softwarecommunity.intel.com/articles/eng/1193.htm

SDK for 45nm Next Generation IntelR Core?2 Processor Family and IntelR SSE4 (Penryn SDK)

をDLして味噌。



SSE4開発のためのPDF一式とか、SSSE3とSSE4のMASM用のマクロ定義とか。
あと、SSE4までのインストラクションをトラップしてエミュレーションで実行するDLLが入ってる。
実クロックの計測は無理だけど一応動作は確認できる。


504 :デフォルトの名無しさん:2007/10/09(火) 18:02:17
 

505 :デフォルトの名無しさん:2007/10/11(木) 20:20:32
Harpertown Instruction Latency Dump
http://aceshardware.freeforums.org/viewtopic.php?t=210&sid=5dc2a71551abd0673579ba2b1f61c522
> I hope you will find this interesting: http://www.freeweb.hu/instlatx64/InstLatX64_GenuineIntel0010674_Core_Harpertown_2660MHz.txt
> SSE4.1 instructions included. :)
>
> For comparison use this collection: http://instlatx64.fw.hu/

Barcelona(Rev.B1?)もあるみたい
ttp://www.freeweb.hu/instlatx64/InstLatX64_AuthenticAMD0100F21_K10_Barcelona_1900MHz.txt

506 :1 ◆.MeromIYCE :2007/10/12(金) 18:53:53
>>505
これはスゲエ。
Barcelonaは相変わらずSIMD論理演算のレイテンシが2だな。
addssとかのスループットも1clkに1命令を超えるのは無理か。
Crusoeの変態モーフィングも面白いなあ。

さて、これを全部まとめてExcelの表にするにはどうしたらいいかな・・・。

507 :デフォルトの名無しさん:2007/10/13(土) 00:04:41
へたくそだけど

s/=/:/g
s/¥s+[LT]:/:/g
s/^(¥s+¥d+)¥s+(¥S+)¥s+:([^:]+):/¥1:¥2:"¥3":/g
s/(¥d+¥.¥d+)¥w+/¥1/g
s/:/,/g
s/¥[(no true dep¥.|memory dep¥.)¥]/,/g

508 :・∀・)っ-○◎●:2007/10/13(土) 00:13:50
シャッフル演算のレイテンシが1ってとこに注目

509 :デフォルトの名無しさん:2007/10/13(土) 01:00:45
SSE2のPMAX/MINのスループットは0.5だが
SSE4.1のPMAX/MINのスループットは1

510 :・∀・)っ-○◎●:2007/10/13(土) 01:05:39
命令長が長くなるから自重

511 :・∀・)っ-○◎●:2007/10/13(土) 20:28:33
なにげにAMDのmovntss/dが速いな

512 :デフォルトの名無しさん:2007/10/13(土) 20:51:30
ダンゴさんが連投すると盛り上がるな

513 :デフォルトの名無しさん:2007/10/13(土) 20:57:36
盛大に盛り上がってるね。

514 :・∀・)っ-○◎●:2007/10/13(土) 21:02:27
うるしぁバールのようなものぶつけんぞ

515 :デフォルトの名無しさん:2007/10/13(土) 21:08:41
すごい盛り上がりだね。

516 :デフォルトの名無しさん:2007/10/13(土) 21:56:56
じゃあ上げとくか

517 :デフォルトの名無しさん:2007/10/14(日) 00:25:28
気がついたら 同じ言い訳ばかりしてる
そしていつも純損失を計上
あきらめずにIntelのプロセスに挑戦するけど
すぐ微細化するよ

シェアがあれば らくに研究費確保できるけど
何回やっても 何回やっても
Intelがたおせないよ

あのプラットフォーム何回やっても崩せない
イベント開いて FUDしつづけても
いずれはベンチが晒される

ペーパーローンチも試してみたけど
次世代相手じゃ意味が無い!

だから次は絶対勝つために
僕はファブだけは最後までとっておく

518 :デフォルトの名無しさん:2007/10/14(日) 00:27:12
気が付いたら 振り子が揺れてる
そしていつも周回遅れ
諦めずにアーキを全面刷新するけど
すぐにメッキはがれる

K8でいけば らくにPrescottたおせるけど
何回やっても 何回やっても
Baniasがたおせないよ

PenM系のトランジスタ効率破れない
アーキの方向まねしてみても
インプリメントで差がつく

高価な製造技術試してみたけど
Intel相手じゃ意味がない!

だから次は絶対勝つために
僕は裁判費用だけは最後までとっておく

519 :デフォルトの名無しさん:2007/10/14(日) 00:59:45
こういうのって本当におもろいと思って書いてるのかなぁ。

520 :デフォルトの名無しさん:2007/10/14(日) 16:39:33
酒が入っていれば何でも楽しい

521 :デフォルトの名無しさん:2007/10/14(日) 21:28:09
酒が入ったときは「うんこ」でも爆笑するやつは居る。

522 :デフォルトの名無しさん:2007/10/23(火) 21:41:38
Opteron 2360 SE + PGI Compiler + SmartHeap Library
http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20070908-01997.html
[-fast] SSEを含めたさまざまな最適化を行う。
[-Mipa=inline] 関数のインライン化を行い呼び出しのオーバーヘッドを削減する。
[barcelona] K10アーキテクチャをターゲットにしたコード生成を行う。
[-Mipa] プロシージャ間のグローバルな最適化のために解析を行う。
[-Bstatic_pgi] ランタイムライブラリとスタティックにリンクさせる。
[-fb] プロセッサ内部のパフォーマンスカウンタからサンプリングしたデータを基に最適化を行う。

Xeon X5355 + GCC Compiler
http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20070913-02007.html
[-O3] さまざまな最適化を行う。SSEは利用しない。
[-fno-inline-functions] 関数のインライン化を行わない。

*Opteron + GCC CompilerとXeon + PGI Compiler + SmartHeap Libraryの成績は現在提供しておりません。

Sponsorrd by 独占企業逝っtelと戦う正義のAMD

523 :デフォルトの名無しさん:2007/11/04(日) 11:01:01
( ´ー`) ?

524 :デフォルトの名無しさん:2007/11/12(月) 17:17:10
Yorkfield買った猛者は現れるかな。

525 :デフォルトの名無しさん:2007/11/14(水) 17:22:00
IntelのIntelR 64 and IA-32 Architectures Optimization Reference Manual

が、更新されてPenrynも載ってる。


526 :デフォルトの名無しさん:2007/11/15(木) 14:34:47
徹底研究"Penryn" - Yorkfieldで探る45nm世代Intel Architectureの真実
http://journal.mycom.co.jp/special/2007/penryn/index.html

シリーズ化してくれるのはうれしいね。

527 :1 ◆.MeromIYCE :2007/11/15(木) 15:28:04
>>526
ストアの改良だけをえぐり出すベンチは作るのが大変そうだな。

良く言えば完成度が高い、悪く言えば無難。
>>525のレイテンシとスループットの表を見てもそうだ。
Comroeで「遅い」と感じた命令が遅くなくなっている(糞のように速い命令はない)。

それにしてもL2は24wayか。
どこに欲しいデータがあるのか探すのに24回もアドレス比較が必要だからな。
データ位置によってレイテンシが変わったりするんだろうか。

528 :デフォルトの名無しさん:2007/11/16(金) 07:09:55
tetsuya komuroかと思った

529 :デフォルトの名無しさん:2007/11/19(月) 02:49:34
>データ位置によってレイテンシが変わったりするんだろうか。
そんな危険なことはしない

530 :デフォルトの名無しさん:2007/11/22(木) 15:02:16
Phenom買ってきたからこのスレ的な計測を色々しようかと思ったけど手持ちのマザーで動かんかった。
無念…

531 :デフォルトの名無しさん:2007/11/22(木) 20:40:31
マザーも買うしかないな。
というか、同時に買えばいいのに。

532 :デフォルトの名無しさん:2007/11/22(木) 21:16:38
BIOSは?

533 :デフォルトの名無しさん:2007/11/23(金) 01:31:32
>>531
UNKNOWNでも動くかと思ったんだが。
BIOS画面すら拝めなかったよ。
AM2+マザーはSB700が出るまで待ちたいんだがなあ。
なんか買ってしまいそうだ。

>>532
今のところ対応BIOSは無し。
AM2+マザーでも微妙に不具合あるみたいだから出るとしても一ヶ月くらいは待たされそうだ。
ASUSのAMD690G板じゃ動いたらしいが。

534 :デフォルトの名無しさん:2007/11/23(金) 03:25:45
イヨッ良い漢。

535 :デフォルトの名無しさん:2007/11/23(金) 16:20:48
S3Hで動かないかなぁ

536 :デフォルトの名無しさん:2007/11/24(土) 23:03:52
さて、マザーを買ってきたわけだが。

537 :1 ◆.MeromIYCE :2007/11/24(土) 23:22:46
ドキドキ…(゚Д゚;)

538 :デフォルトの名無しさん:2007/11/25(日) 00:05:25
規制食らったのでしばらく書き込めねー。
なんか知りたいことがあれば書き込みよろ。
自分でもやろうとは思うが何やればいいかよく分からん。

539 :1 ◆.MeromIYCE :2007/11/25(日) 00:33:59
>>538
cpu-z付属のlatency.exeの結果をお願いします。

http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=mandel.zip&refer=Upload
あと、古いので申し訳ない(VB5だから表示が崩れるかも)けど、マンデルブロ集合でFP性能測定。
メニューの「描写」から「ベンチマーク」をお願いします。

PCサイトでもメジャーどころの総合ベンチ(CPU・メモリ系含む)ばっかりで
なかなか特定性能を知る機会がないのですよ。


それにしても、3年前に買ったPenM-1.1GHzは本当にいい仕事をしている。
3年経っても性能に大きな不満がない。
そして、1,2年後に次のPC(おそらくPenryn)を迎えるのが楽しみでたまらない。

540 :デフォルトの名無しさん:2007/11/25(日) 02:23:36
規制解除って長いのかな。
今やってる作業終わるまでに解除されなかったら携帯からやることにしよう。

541 :デフォルトの名無しさん:2007/11/25(日) 05:03:53
キャッシュやメモリの設定を変えてやってみた。
GangedとUngangedはメモリへのアクセス法。
Cache=DisableはBIOSに「External Cache」の項目があったのでDisableにしてみた。
他に「CPU Internal Cache」の項目もあったしExternalはL3のOn/Offかと思ったけどCPU-Z見る限りL2のOn/Offっぽい。

マンデルブロ集合
Ganged
FPU 2.407sec 4.011sec 5.508sec
SSE 0.563sec 1.148sec 1.462sec
SSE2 1.083sec 2.218sec 2.820sec

Unganged
FPU 2.406sec 4.011sec 5.506sec
SSE 0.563sec 1.148sec 1.462sec
SSE2 1.083sec 2.218sec 2.819sec

Ganged Cache=Disable
FPU 2.417sec 4.019sec 5.510sec
SSE 0.569sec 1.153sec 1.467sec
SSE2 1.089sec 2.224sec 2.826sec

Unganged Cache=Disable
FPU 2.411sec 4.020sec 5.513sec
SSE 0.566sec 1.151sec 1.466sec
SSE2 1.086sec 2.221sec 2.826sec

542 :デフォルトの名無しさん:2007/11/25(日) 05:11:17
latency.exe
Ganged
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1824.jpg

Unganged
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1825.jpg

Ganged Cache=Disable
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1826.jpg

Unganged Cache=Disable
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1827.jpg

Rev.Gと比べるとL2はマシになってるけどメモリレイテンシはちょっと大きいか。


543 :デフォルトの名無しさん:2007/11/25(日) 05:21:32
本当は同一条件でRev.Gのコアとの比較もしたいところなんだけど、さすがに時間かかるので断念。
TXとかπ焼きとかはしてるけど他に何かやることないかなあ。

544 :デフォルトの名無しさん:2007/11/25(日) 06:24:40
見ると試してみたくなる。
--
model name : Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz
--
FPU 2.453sec 4.560sec 6.148sec
SSE 0.553sec 1.124sec 1.467sec
SSE2 1.276sec 2.431sec 2.999sec


545 :ヽ・´∀`・,,)っ━━━━━━┓:2007/11/25(日) 06:32:16
>>543
年内にx64版用意しようかと思ってたけど急いだほうがいい?

VS2008のPGO試してみたいから俺も実機買うしかないか

546 :デフォルトの名無しさん:2007/11/25(日) 07:16:16
>>545
64bit環境無いし…。
でもどれくらい速度上がるのかは調べてみたい。
環境揃えようかなあ。

ちなみにPhenomとK8じゃSSE2利用でPhenomの方が1.5倍くらい速かった。
1〜4スレッドまで綺麗にスケールしたし。
C2Qには同クロックで10%くらいは劣る模様。
K8とC2Qのデータはそんなに正確じゃないけどね。

547 :デフォルトの名無しさん:2007/11/25(日) 08:13:37
>541と>544もクロック差を考慮するとFPU以外はCore2Duoの方が速いな。

548 :デフォルトの名無しさん:2007/11/25(日) 09:06:41
>>538
このテストお願いしたいです。
x86 Memory disambiguition test ( with resource codes)
http://www.realworldtech.com/forums/index.cfm?action=detail&id=73407&threadid=73407&roomid=2


549 :デフォルトの名無しさん:2007/11/25(日) 09:19:23
>>548
残念ながら俺はマウスをクリックすることしか出来んのだよ。
自作板からの出張者なのでプログラムに関しては何も…。


550 :548:2007/11/25(日) 09:56:08
>>549
コンパイルしてみました。こちらをお願いします。
http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=MemoryDisambiguitionTest.zip&refer=Upload


551 :デフォルトの名無しさん:2007/11/25(日) 10:18:07
Test 1 -- Loading before unknown load address:
Loading before unknown load address: 10 cycles
Loading before known load address:   10 cycles
Loading before unknown load address: Yes!

Test 2 -- Loading before unknown store address:
Loading before unknown store address: 20 cycles
Loading before known store address:   10 cycles
Loading before unknown store address: No!

Test 3 -- Storeing before unknown load address:
Storeing before unknown load address: 25 cycles
Storeing before known load address:   12 cycles
Storeing before unknown load address: No!

Test 4 -- Storeing before unknown store address:
Storeing before unknown store address: 25 cycles
Storeing before known store address:   10 cycles
Storeing before unknown store address: No!

これでいいかな。

552 :548:2007/11/25(日) 10:32:13
>>551
ありがとう御座います。
Out-of-Orderになったのはload before loadのケースだけみたいですね。

553 :デフォルトの名無しさん:2007/11/25(日) 11:17:38
http://journal.mycom.co.jp/special/2006/conroe/
これを真似てRMMAのデータを全部取ってみたが中々興味深い。
K8と見比べるとちょっとだけ違う点がいくつかある。
取得した数字を処理する能力が俺にあればグラフをうp出来るんだが、表計算ソフトは10年以上触ってないのであった…。

554 :544:2007/11/25(日) 11:45:00
くどい?
--
Test 1 -- Loading before unknown load address:
Loading before unknown load address: 11 cycles
Loading before known load address: 11 cycles
Loading before unknown load address: Yes!

Test 2 -- Loading before unknown store address:
Loading before unknown store address: 11 cycles
Loading before known store address: 11 cycles
Loading before unknown store address: Yes!

Test 3 -- Storeing before unknown load address:
Storeing before unknown load address: 11 cycles
Storeing before known load address: 11 cycles
Storeing before unknown load address: Yes!

Test 4 -- Storeing before unknown store address:
Storeing before unknown store address: 11 cycles
Storeing before known store address: 12 cycles
Storeing before unknown store address: Yes!
Finished.
--
>>553
数字と比較したいポイントが判ればグラフにするのは請け負いますよ。

555 :デフォルトの名無しさん:2007/11/25(日) 12:24:06
>>554
うーんお願いしようかな。
OOo入れてみたけどすぐには使いこなせそうにない。

http://journal.mycom.co.jp/special/2007/penryn/index.html
さっき特集はソフトが古くてデータの整合性がとれないのでこっちの特集がよさげです。
もっかい特集と見比べてどのデータを渡すか選びますね。
全部渡しても大変でしょうから。

556 :デフォルトの名無しさん:2007/11/25(日) 13:18:46
>>554
上でごちゃごちゃ言いましたが、結局特集に出てたデータ全部纏めました。
どのデータをグラフ化するかはお任せします。
CSV吐いてくれたので慣れた人がやればグラフ化は簡単だと思います。
だるかったらやっぱやめてもおkです。

http://www-2ch.net:8080/up/download/1195964178823974.MbX2GM?dl

そしてせっかく纏めたので他の人にも提供。(パスは"phenom")
何かの参考資料としてどうぞ。
グラフ化歓迎w
そのうちまた大原特集が組まれると思いますけど。
RMMAで取ったデータは他にもありますので、項目調べて欲しいと言ってくれれば用意するかもしれません。
うpしたのはGangedのデータですが、Ungangedのデータも一応あります。

個人的にCacheの帯域にちょっとびっくり。

557 :1 ◆.MeromIYCE :2007/11/25(日) 17:34:06
>>541
貴重なデータをありがとう。
マンデルブロ集合は、PenMでチューンしたので相性があるかもしれないが、
やはりSSE性能は、PenM<Phenom<Core2。FPU性能は大差なし。
Phenomは、実行ユニットはK8の倍あるから、コードを変えればもう少し伸びると思う。

キャッシュレイテンシは意外と素直だね。
L3のレイテンシは長いから、メモリベンチでは平凡な結果になると思うけど、
共有のデータ置き場があってコア間通信もK8以上なら、実性能は期待できる。

>>553
生データだけでもすごく嬉しいのですよ。
それにしても、>>556。L1は本当に32byte/clk近く出るのだね。

558 :544:2007/11/25(日) 18:56:59
試しに「D-Cache RAM Bandwidth SSE2」をアップロードしてみました。
性懲りもなく、Core2Duoの結果もついてますがw
http://www-2ch.net:8080/up/download/1195984374904107.xGtrct?dl
# パスは>556と同じ
OpenOfficeでxls吐くとレイアウト崩れるしでかくなるのでパス。
グラフだけ、絵でアップロードした方がよかった?

559 :デフォルトの名無しさん:2007/11/26(月) 01:14:06
>>558
サンクス。
しかし改めて並べて見るとCoreに全然引けを取ってないから凄いな。
むしろ上回る部分も多いし。
L1 hit時なんかK8の4倍だけど、これはSSE Unaligned Load-Executeってのが効いてるのかな。
K8でも64bitの2ロードではあったから。
L3も役に立ってはいるけど量が少ないのが惜しい。Shanghaiは期待出来るだろうか。

560 :デフォルトの名無しさん:2007/11/26(月) 04:01:14
PhenomのD-CACHE LATENCY 見てたら、特性が、なんかCore2に似てきた感じだね。

キャッシュの範囲では早くなってるが、メモリの範囲ではRANDAM、PSEUDO-RANDOMでK8より遅くなってる。

561 :デフォルトの名無しさん:2007/11/26(月) 13:14:50
あとはどれだけ各種コンパイラが頑張ってくれるかですかねぇ・・・

562 :デフォルトの名無しさん:2007/11/26(月) 17:13:39
SandraのCache & Memory Benchmark見る限りK10よりCoreMAの方がスコア高いけどRMMAの結果と矛盾しない?
K10は2ロードだから良いとしても、CoreMAはRMMAだと16byte/cycle止まりだけどSandraはもっと行ってる気がするんだが。

563 :デフォルトの名無しさん:2007/11/26(月) 18:52:26
>>559
> L1 hit時なんかK8の4倍だけど、これはSSE Unaligned Load-Executeってのが効いてるのかな。
> K8でも64bitの2ロードではあったから。

前スレでも話題に上ったけど、
K8ではmovdqa xmm,memはFMISCでしか実行できないという制限があり、
RMMAはmovdqa xmm,memを羅列して帯域計測しているので、
K8本来のL1速度(16byte/clk)の半分8byte/clkという結果になっている。
K10では理論値(32byte/clk)に近い結果が出ているので、
おそらくK10ではmovdqa xmm,memをFMISCだけでなくFADDやFMULでも
実行可能になったと考えられる。

>>562
RMMAはロードのみを行った場合の帯域。
Sandraはロードとストアをミックスした場合の、リードとライトの帯域の合計。

564 :デフォルトの名無しさん:2007/11/26(月) 19:30:51
>>563
K8ではXMM(128bit)へのロードはFMISCのみへのDouble Issueだったものが
K10では3ユニットいずれかへのSingle Issueになっているね。
K8でもMMX(64bit)へのロードは3ユニットで処理可能だった。
実際にはL/S Unitが2基しかないけどね。
この場合はロード帯域がカタログスペック通りになるね。

K10改良点としてXMM to XMMコピーがFMISCでも処理可能に
なったことがあるけど、性能向上にどれくらい寄与するんだろう?

565 :デフォルトの名無しさん:2007/11/27(火) 00:23:01
>>563
ロードストアの合計だったのか。納得。
CoreMAは128bitロードストア同時に出来るもんな。

566 :デフォルトの名無しさん:2007/11/27(火) 02:37:14
>>563
命令処理の差でしたか。

>>564
そこら辺の改良の効果も測ってみたいですねえ。


メモリのGangedとUngangedの差を調べてたみた。
けどいい加減スレ違いかな。
ここってCPUコアの話がメインっぽいし。

567 :デフォルトの名無しさん:2007/11/28(水) 18:44:18
Phenom実機で追試。

MOVDQA xmm,mem128 (LOAD)は、Bank conflict のない限りIPC=2
MOVDQA mem128,xmm (STORE)は、IPC=1

ちなみにK8ではLOADが1/4に、STOREが1/2に性能が落ちる。

肝心のLOAD/STORE混在のケースなのだけど、

LOAD,STOREの連続実行では平均IPC=1
LOAD,LOAD,STORE,STOREにするとIPC=4/3 (.5+.5+1+1 ??)

この例だとLOAD/STOREはin-order実行のもよう。

同じアドレスへの連続STOREはストールするので注意。

568 :デフォルトの名無しさん:2007/11/28(水) 21:03:10
>>567
Nontempral Storeの測定もお願いします

569 :デフォルトの名無しさん:2007/11/28(水) 21:32:17
>>567
これは興味深い結果だね。
独立したロード・ストアでも並べ方に注意って事か。

570 :デフォルトの名無しさん:2007/11/28(水) 21:34:59
>>568
個人的にメモリストリーミングにあまり興味がないので
調べた事がなかった

MOVNT ってキャッシュ迂回するんだっけ?
訳あってシステムがDual Channel構成じゃないので
ここで回しても有意な結果が得られないかもしれん。

571 :1 ◆.MeromIYCE :2007/11/29(木) 00:57:19
マンデルブロ集合ベンチをもう少し。
以下はすべてクロック当たりの性能の話です。

前スレでK7で測ってもらったものと>>541を比較すると、FPUはK7が0.5%遅い程度。
>>541でキャッシュ設定を変えると微差が出たが、それと同じ種類の差だろう。
つまりFPUコアは全く変わっていない。
IntelのCPUと比べると遅いが、これはP6向けのコードだから当然の結果。

PenMとCore2のFPU比較では少し様子が違う。
z^2+cの計算では2%ほど速くなっているが、z^3はほぼ同じ、z^4では6%遅くなっている。
FPUの実行ユニットは同じ性能で、スケジューラが強化されたのが影響したのだろう。
強化されれば速くなるはずだが、P6向けにチューンされたコードだから相性が出たのだと思う。
#1%単位で語っても、CPUの周波数の誤差が0.5%くらいはあるんだが。

SSEでは、元々K7(皿)とPenMが、性格は違うが大体同じ性能だった。
それがPhenomでは、また性格が違うけど10%程度性能アップした感じだ。
また、SSE2の結果が、SSEのちょうど倍よりほんの少し速いのもPhenomの特徴だ。
つまり、4並列のaddpsと2並列のaddpdの負荷が全く同じということだろう。
微妙な差は、分岐予測かメモリ関係が原因と思われる。

逆にCore2は、SSE2の結果が、SSEのちょうど倍より少し遅い。
それも、Phenomと違ってバラつきがある。
もしやと思って命令リファレンス調べたら、addpsはaddpdより命令長が1byte短い!
巷でデコードが弱いと言われるだけのことはあるねえ。
Core2のSSEはPenMと性格が全く違い(レイテンシ据え置きなので)、10〜40%の高速化。

このコードでは、レイテンシの効果が大きい。
SSE2のスループットがSSEより悪いPenMでも、SSE2はSSEの半分に近い性能を出している。
16個のxmmレジスタを使ったり、SMTを使ったりすると、新しいCPUは更に速くなるはずだ。
#マルチコアの性能を測る目的ではないベンチなので、コアは1つしか使いません。

572 :デフォルトの名無しさん:2007/11/29(木) 16:08:12
AMD CodeAnalystにはまだ、K10のPipeline simulationが実装されていない…!!

573 :デフォルトの名無しさん:2007/11/29(木) 18:31:57
AMDの資料に MMX MOVQ reg,regの実行ユニットが FADD/FMUL と書いてあるので
確かめてみたらその通り。
今さらMMXが速くなってもうれしくないだろうが、一貫性ないな。
XMM MOVDQAなどはFADD/FMUL/FSTOREだった。

574 :デフォルトの名無しさん:2007/11/29(木) 23:31:12
libpngはいまだにMMX版が主流じゃなかったっけ?

575 :デフォルトの名無しさん:2007/11/30(金) 00:06:11
誤爆?

576 :○〆・´∀`・)○っ━━━━━━┓:2007/11/30(金) 12:42:25
AMDのMMXはまずレイテンシがネックぢゃん

レイテンシ2が3Wayてことはつまり性能を引き出すにはコードシーケンスを6並列化しないといけない。
で、論理レジスタ8本の縛りの中でfadd/fmulが休まないようにスケジューリングすれば
ロード・ストアに空きができることなんてないと思うが・・・

ということはfstoreのレジスタ間movdqaはXMMレジスタ16本の64ビットモードでこそ意味があるんでね?

577 :デフォルトの名無しさん:2007/12/03(月) 07:41:43
分ってきてるじゃん。
以前はインターリブすりゃいいとか闇雲に言って、8本でできるかよって突っ込みたかったものだが。

578 :デフォルトの名無しさん:2007/12/03(月) 08:14:32
頭のおかしい人に勘違いで油を注ぐなよ・・・・・

579 :デフォルトの名無しさん:2007/12/03(月) 09:25:27
空気を読まずにPhenomのネタ投下。
π焼きを同時に1〜4個までやってみた結果。
それぞれ5回計測したうちの真ん中3つのデータを平均した時間です。
だから計測誤差は小さいと思うけど、それでもGangedだとかなりばらついた。

Super PI mod 1.5 - 8M
Unganged
1 : 6m37.781s 100.0%
2 : 6m49.003s 102.8%
3 : 7m02.712s 106.3%
4 : 7m20.039s 110.6%

Ganged
1 : 6m40.912s 100.0%
2 : 6m56.842s 104.0%
3 : 7m17.154s 109.0%
4 : 7m41.908s 115.2%

http://journal.mycom.co.jp/photo/articles/2007/09/15/barcelona/images/Photo02l.jpg
ここによるとUngangedになれば10%は性能向上するらしいが、今回は良くて5%くらい。
以前Phenomスレで1Mのデータを投下したけどあのときは4個同時でも3%くらいの向上だった。
サーバのようにもっと大きな仕事をさせれば10%くらいはいくのかもしれん。

580 :デフォルトの名無しさん:2007/12/08(土) 13:04:04
EM64T より AMD64 の方が
CPUID とか RDTSC のレイテンシが小さい気がするんだけど
何で?

581 :デフォルトの名無しさん:2007/12/08(土) 19:18:14
具体的な数字を出してください

582 :デフォルトの名無しさん:2007/12/08(土) 22:11:50
CPUID + RDTSC の発行で
EM64T だと 300 クロック以上掛かるけど
AMD64 だと 70 クロック弱

583 : ◆0uxK91AxII :2007/12/08(土) 23:14:38
>>580
ia32_arh_dev_man_vol2a_i.pdfより抜粋。
>CPUID命令はどの特権レベルでも実行でき、命令の実行をシリアル化することができ
>る。命令の実行をシリアル化することにより、前の命令においてフラグ、レジスタ、
>メモリに対して修正が行われた場合、それらの修正がすべて完了してから、次の命令
>がフェッチされて実行されることが保証される。

そういう事。

584 :デフォルトの名無しさん:2007/12/08(土) 23:50:07
>>583
AMD64 でも CPUID は非特権のシリアル化命令じゃないの?

585 :デフォルトの名無しさん:2007/12/09(日) 13:05:08
CPUIDは知らんが
RDTSCはエミュになってるんじゃない?

C2D発売直後にLinuxでRDTSCやってみたら
コアクロックじゃなくバスクロックでカウントしてた。
後日Vistaでやったときはコアクロックに準じた値になってたけど
恐ろしく実行時間がかかるようになった。

誰か、素のDOSでRDTSC追試きぼん。

586 :デフォルトの名無しさん:2007/12/09(日) 14:29:20
よく分からん
アセンブリで書いても Linux とか Vista とか OS の影響を受けるのか
あとコアクロックとバスクロックってどうやって区別する?

587 :デフォルトの名無しさん:2007/12/09(日) 18:07:53
バスクロックじゃなくてコアクロックがダイナミックに下がっているだけじゃねーの?

588 : ◆0uxK91AxII :2007/12/09(日) 19:57:09
>>586
OSの作り方によっては、影響を出せる。
>保護モード例外
>#GP(0) CR4 レジスタのTSD フラグがセットされていて、CPL が0 より大きい場合。
>実アドレスモード例外
>なし。
>仮想8086 モード例外
>#GP(0) CR4 レジスタのTSD フラグがセットされた場合。

589 :デフォルトの名無しさん:2007/12/10(月) 01:22:43
で、わざわざ CR4 の TSD フラグをセットして一般保護例外を発生させて
その OS は何がしたいわけ?
例外ハンドラで RDTSC をトラップして訳の分からん時間を掛けて
edx:eax に変な値を返すのか?

RDTSC の挙動を変えることの実現可能性の話をしてるんじゃないぜ
実際に Linux と Vista の違いで RDTSC が違う挙動を示すのかどうかを確認している

590 :デフォルトの名無しさん:2007/12/11(火) 00:44:30
>>585
>>120

591 :デフォルトの名無しさん:2007/12/11(火) 11:41:37
つまりC2D RDTSCの挙動はBIOS,OSによって変わるということだな?

592 :デフォルトの名無しさん:2007/12/11(火) 20:32:09
BIOSでも変わるだろうし、マイクロコード書き換えでも変わるだろうし、
OSがトラップしてゲームのパフォーマンスのために昔通りの値にすることもあろうだろう。

593 :582:2007/12/12(水) 00:36:40
とりあえずもう少し詳しく調べてきたよ

Xeon 5140 (2.33 GHz)
rdtsc : 70 クロック
"movl %eax, %cr2" + rdtsc: 112 クロック
cpuid + rdtsc : 308 クロック

Athlon 64 3000+ (2 GHz)
rdtsc : 8 クロック
cpuid + rdtsc : 65 クロック

cr2 〜 ってのは特権命令使い放題な環境でも試せたから
特権シリアル化命令として CR2 へ書き込んでみた

http://journal.mycom.co.jp/special/2007/penryn/
EM64T の RDTSC の遅さはこの記事の "Faster OS Primitive Support" ってので改善されるのかねえ

594 :582:2007/12/12(水) 00:42:41
>>590
おおトン
とりあえず Xeon 5140 (2.33 GHz) では RDTSC は 7 クロック刻みだったわ
333 MHz * 7 = 2.33 GHz ってことかな

Pentium 4 (Prescott 2M) 3.40GHz でも 17 クロック刻みだった
これも 200 MHz * 17 GHz ってことかも

595 :デフォルトの名無しさん:2007/12/12(水) 03:20:43
>>505のサイトより
RDTSCのスループット
K6:7.67
K7: 11.00
K8: 6.50
Barcelona: 65.00

Coppermine: 31.00
Banias: 40.00
Dothan: 42.00
Yonah: 98.42
Merom: 64.17
Yorkfield: 28.00

596 :デフォルトの名無しさん:2007/12/14(金) 21:15:16
この質問がスレに相応しいか判りませんが、
Core2のL2キャッシュの登録・削除・検索アルゴリズムって
どんなのか判りますか?

597 :デフォルトの名無しさん:2007/12/14(金) 22:04:03
>>596
Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
ttp://www.intel.com/design/processor/manuals/253668.pdf
10.2 CACHING TERMINOLOGY
> IA-32 & Intel 64 processors use the MESI cache protocol

読んでないけどこんな資料もあった
Intel(R) 64 Architecture Memory Ordering White Paper
ttp://www.intel.com/products/processor/manuals/318147.pdf

598 :デフォルトの名無しさん:2007/12/15(土) 12:17:57
Intel 64 と Intel Architecture 64 ってぱっと見分かりにくいな

599 :デフォルトの名無しさん:2007/12/15(土) 12:49:17
IA-64はIntelAMD-64の略

600 :ヽ・´∀`・,,)っ━━━━━━┓:2007/12/16(日) 05:45:42
IntelはIA-64よりもIPFって言ってるな。

601 :デフォルトの名無しさん:2007/12/19(水) 03:51:27
来年は順調にいけば

・Silverthorne
・Nehalem
・Shanghai

が出てくるんだよな。
全種手に入れてやんよ。

602 :ヽ・´∀`・,,)っ━━━━━━┓:2007/12/19(水) 21:54:07
Larrabeeも思い出してあげて



上海ってただのシュリンクだからFusionの一端を担うBulldozerのほうこそ注目

603 :デフォルトの名無しさん:2007/12/19(水) 23:13:19
Larrabeeって来年に出たっけ?
来年に出て一般人が手に入れられるようなら入手。


ShanghaiかMontrealでキャッシュの構造が変わるんじゃないかと期待してる。
IPC Enhancementsってのも気になるし。

Bulldozerは……2009年中に出るんかなあ。

604 :ヽ・´∀`・,,)っ━━━━━━┓:2007/12/19(水) 23:31:34
知らんけどIntelはこのテラスケールプロセッサはより高度なWiiライクなゲームを将来実現するために重要だとか言ってますよ。
×箱で懲りたんじゃなかったのか


605 :デフォルトの名無しさん:2007/12/20(木) 01:25:35
>>340のマニュアルでは, 128 bitのシャッフル/パック/アンパック等の
レイテンシは2 cycleだけど, >>505の測定結果だと3 cycleになっている.
追加されているRev.B2の測定結果でも3 cycleだし、エラッタにも該当する
ものがないから仕様なのか?
45nmのShanghaiで改善されたりするのだろうか?

606 :デフォルトの名無しさん:2007/12/22(土) 16:05:06
×箱に関わってるのか,Intel?

607 :ヽ・´∀`・,,)っ━━━━━━┓:2007/12/22(土) 23:42:03
初代×箱のCPUはCoppermine-128Kの733MHzだよ。


608 :デフォルトの名無しさん:2007/12/23(日) 17:35:16
ぉ,確かに, thanks
ってことは失敗から学んだんじゃまいか

609 :デフォルトの名無しさん:2007/12/29(土) 03:56:03
書くことないから4gamerの記事でも貼っておこう。

Phenom徹底分析(前):ネイティブクアッドコアに意味はないのか?
http://www.4gamer.net/games/039/G003983/20071223001/
Phenom徹底分析(中):B2ステッピングのエラッタで何が起こるのか
http://www.4gamer.net/games/039/G003983/20071223002/
Phenom徹底分析(後):動作クロックはなぜ上がらないのか
http://www.4gamer.net/games/039/G003983/20071227020/

こういう記事がもっと増えてくれば良いんだが、大原か米田くらいしか書きそうにないのがなあ。
他はベンチ回すだけだし。
このスレに来る人くらいしかアーキテクチャの詳細には興味は無いんだろうか…。

610 :ヽ・´∀`・,,)っ━━━━━━┓:2007/12/29(土) 04:45:58
今更だけどSSE5の16ビット浮動小数→単精度相互変換命令についてAMD-ATiの今後について妄想してみるのもありかと。
それにしてもNehalemは凄すぎるな。


611 :デフォルトの名無しさん:2007/12/29(土) 10:17:57
暇だったので>>558のデータを1つのグラフに纏めてみた。
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1886.jpg

612 :デフォルトの名無しさん:2007/12/30(日) 02:30:06
さらに暇だったので>>556のデータをグラフ化してみた。
PASSはRMMA。
http://www-2ch.net:8080/up/download/1198948333164525.BRq4Rf

K8に比べてL2帯域が微妙によくなってる。
L1も強化した分しっかり帯域は増えてる。
だがI-Cache RAM Latencyじゃキャッシュの範囲内でBackwardがえらく遅い。
なんでだろ〜。

それにしてもCoreMAのL2は大容量かつ高速で優秀ですな。

613 :デフォルトの名無しさん:2007/12/31(月) 06:01:55
お邪魔します。別スレから誘導されてまいりました。
Pen4のリアルモードでの動作速度についてお聞きしたいことがあります。
Pen4をリアルモードで動作させた時の浮動小数点演算速度とプロテクトモードでの
浮動小数点演算速度は大きく違うのでしょうか。
因みにPen3(1GHz)の場合、リアルでもプロテクトでも大差ないことは確認しており、
AthlonXPでは  リアルでの速度(Pen2,100M程度) << プロテクトでの速度 です。
浮動小数点演算を多用するDOSプログラムをなるべく速く実行させるために
Pen4マシンの購入を検討しています。
どなたかご教示をいたたけるとありがたいのですが。
よろしくお願いします。

614 :デフォルトの名無しさん:2007/12/31(月) 08:43:36
>>613
> 因みにPen3(1GHz)の場合、リアルでもプロテクトでも大差ないことは確認しており、
> AthlonXPでは  リアルでの速度(Pen2,100M程度) << プロテクトでの速度 です。

これはどうやって検証したの?
検証用のコードがあるのなら、アップしてPen4を持っている人に実行してもらって
結果を報告してもらえばいいのでは?

615 :デフォルトの名無しさん:2007/12/31(月) 08:45:27
Pen4で頑張って動かすより、Xeonで力任せに動かす方が余程速いんだが。
つーか、今時なんでDOSプログラムなんぞを使うのかが理解できん。

616 :デフォルトの名無しさん:2007/12/31(月) 16:29:55
>>613
検証プログラムをUpすればこのスレの暇なPen4ユーザが計測してくれるぞ。
過去にもいろいろ計測人柱が計測しているのがこのスレ。
漏れはあいにくNetBurstな環境は持ってないから計測できないが。

617 : 【大吉】 【1561円】 :2008/01/01(火) 19:14:07
>>615
世の中いろんな人がいるんだからそれを言うのは無粋。

618 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/04(金) 17:55:09
Core 2じゃ駄目な理由が聞きたい。
Pentium 4なんか32bitで動かしてもx87は理論値でクロック当たりPentium 3の半速だぜ

619 :デフォルトの名無しさん:2008/01/05(土) 01:32:36
団子がうぜーからじゃね?

620 :デフォルトの名無しさん:2008/01/05(土) 01:42:29
ワロス

Pen4マシンってまだ売ってるんかな

621 :デフォルトの名無しさん:2008/01/05(土) 19:32:46
>620
売ってる。
HPの格安WSとか。

622 :デフォルトの名無しさん:2008/01/05(土) 20:05:25
PenDはまだまだしぶとく残ってるな
あれってもう生産中止じゃなかったっけ

623 :デフォルトの名無しさん:2008/01/05(土) 21:05:38
Core2は64Bit専用レジスタを持っていないので、32Bitでも64Bitでも消費電力も発熱量も変わらないと思われるが、Phenomは64Bit専用レジスタを持っており、これには32Bitでは動いていない物がある。
このレジスタが動き出し、発熱量が増加したとすれば、限界が下がる事は十分にあり得る。

ついでに64Bit環境でPhenomが健闘している事が、32Bitより64Bitの方が向いているという証にはなるわけだが、同周波数で同程度であっても、周波数の差で負けているのが何とも…
2008/01/05(土) 17:20 | URL | LGA774 #-

624 :デフォルトの名無しさん:2008/01/05(土) 22:06:34
>>623
ひどいバカがいた物だな。どこの掲示板?

625 :デフォルトの名無しさん:2008/01/06(日) 00:57:18
>ついでに64Bit環境でPhenomが健闘している
事実を受け入れられないのはかわいそうです

626 :デフォルトの名無しさん:2008/01/06(日) 01:00:44
http://northwood.blog60.fc2.com/blog-entry-1555.html#more

Core2は64Bit専用レジスタを持っていないので、32Bitでも64Bitでも消費電力も発熱量も変わらないと思われるが、Phenomは64Bit専用レジスタを持っており、これには32Bitでは動いていない物がある。
このレジスタが動き出し、発熱量が増加したとすれば、限界が下がる事は十分にあり得る。

ついでに64Bit環境でPhenomが健闘している事が、32Bitより64Bitの方が向いているという証にはなるわけだが、同周波数で同程度であっても、周波数の差で負けているのが何とも…


627 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/06(日) 01:34:52
64ビット専用レジスタwwwwwwww
Core 2で64bitが遅いのってホントはレジスタのビット数がどうのこうのじゃないのにね。


628 :デフォルトの名無しさん:2008/01/06(日) 03:38:38
ttp://itl.jisakuita.net/core2_mossari/1162381694.html

ダンゴさんの執着心には頭が下がる

629 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/06(日) 03:48:13
馬鹿が気が触れてますな

630 :デフォルトの名無しさん:2008/01/06(日) 09:29:13
>馬鹿が気が触れてますな


631 :デフォルトの名無しさん:2008/01/06(日) 12:30:51
気が触れた馬鹿は最悪だ

632 :デフォルトの名無しさん:2008/01/06(日) 12:34:27
気が触れない馬鹿はただの馬鹿だ。

633 :デフォルトの名無しさん:2008/01/08(火) 17:03:53
>>1

QX9650の結果です。
ただ定格ではなく、333*7@2.33GHzの結果。

FPU 1.917sec 3.611sec 4.825sec
SSE 0.437sec 0.912sec 1.161sec
SSE2 1.015sec 1.923sec 2.377sec


634 :1 ◆.MeromIYCE :2008/01/09(水) 16:33:48
>>633
多少ブレはあるけど、おそらくこのベンチに関しては65nmの>>544から変わってないね。
デコーダの改良もない感じで、予想された通りの結果だ。

635 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/11(金) 00:16:47
Q9450を買うか

636 :デフォルトの名無しさん:2008/01/11(金) 13:56:39
購入宣言age

637 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/11(金) 21:07:27
ばーるのようなものやさんのPCはWolfdale/Yorkfield Readyになりますた。


638 :デフォルトの名無しさん:2008/01/12(土) 16:33:14
これからこのスレは
ばーるのようなものやさん専用になりますた。


639 :ヽ・´∀`・,,)っ¬:2008/01/20(日) 10:55:53
E8500買いました
PCケースをバールのようなものでこじ開ける作業が始まります

640 :デフォルトの名無しさん:2008/01/20(日) 12:23:38
買ったんかよ

641 :デフォルトの名無しさん:2008/01/20(日) 16:06:27
それからそれから?


642 :デフォルトの名無しさん:2008/01/20(日) 18:03:11
>PCケースをバールのようなものでこじ開ける
CPUケースかと思た

643 :デフォルトの名無しさん:2008/01/20(日) 19:40:43
ttp://pc11.2ch.net/test/read.cgi/jisaku/1198229279/l50
こっちで待機中

644 :デフォルトの名無しさん:2008/01/20(日) 22:17:12
さぁさぁ、遠慮せずお続けになって。
ここはあなたのスレですよ。


645 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/20(日) 23:17:17
プログラミングする人には重要な情報

CPUIDをとると
Family 6 Model 【7】 Stepping 6

になってますが、これだけだとPentium III(Katmai)と誤認します。

Extend Model値は17になってるのでこっちをチェックしませう。
まあSSExフラグ見て決めるのもOKだと思うけど。

646 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/20(日) 23:18:45
>>643
構造上LGA775でスッポンはないと思うが。
いっぺん負荷かけてから外すと簡単に外れる。

647 :デフォルトの名無しさん:2008/01/20(日) 23:57:00
スレ主降臨age


648 :デフォルトの名無しさん:2008/01/21(月) 00:05:03
ダンゴさんの連投でスレが一気に加熱したな

649 :デフォルトの名無しさん:2008/01/21(月) 00:13:27
誉め殺し乙

650 :デフォルトの名無しさん:2008/01/21(月) 00:15:09
とりあえず割り算ベンチやってよ。

651 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/21(月) 03:23:45
>>650
GenuineIntel Family:6 Model:7 Stepping:6
除数大↓ 被除数大→
14 19 20 22 24 - - -
14 14 19 20 22 24 - -
14 14 14 19 20 22 24 -
14 14 14 14 19 20 22 24

ずいぶん高性能なKatmaiだな(棒)




652 :デフォルトの名無しさん:2008/01/21(月) 03:49:46
SSE4の66hを取ったら未定義オぺコード例外が発生するのかな?

653 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/21(月) 04:02:18
さあ、間違ってもMMレジスタに作用することはなさそうだが。
ネモい

654 :1 ◆.MeromIYCE :2008/01/21(月) 12:28:03
>>651
これが、Radix-16 dividerの実力ですか。
>>108とかと比べると、32bit境界が見えなくなっていて、一つ64bitっぽくなったな。
2倍は言いすぎにしても、本当にそれに近いくらいの力はありそうだ。

655 :デフォルトの名無しさん:2008/01/21(月) 22:00:00
>>300は何だったんだ?

656 :ヽ・´∀`・,,)っ¬:2008/01/21(月) 22:51:26
マザー謹製ツールが軒並み問題だらけなんでもっと人集めた方がいいかもね

657 :デフォルトの名無しさん:2008/01/21(月) 23:03:59
>>655
単なるエイプリルフールねたのつもりよ(・∀・)

658 :デフォルトの名無しさん:2008/01/21(月) 23:39:28
誰もやってないので

Phenom 9500
AuthenticAMD Family:F Model:2 Stepping:2
除数大↓ 被除数大→
19 24 32 40 47 - - -
19 24 32 40 47 47 - -
19 24 32 40 47 47 47 -
19 24 32 40 47 47 47 47

Athlon X2 BE-2400
AuthenticAMD Family:F Model:B Stepping:2
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39

659 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/22(火) 02:09:36
--- GogoBench 3.13a (May 25 2004) ---
[DLL] ver. 3.13 ( May. 20 2004 )
[O S] Microsoft Windows Series SP1
[CPU] Intel Pentium 3 (Katmai) Dual / 3170.3 MHz   ←ありえねぇwwww
GenuineIntel ID : 0/0/6/7/6 SPEC : 0xBFEBFBFF

[速度] 57.64倍速 [設定] Q=0 FPU
[速度] 70.44倍速 [設定] Q=0 FPU MMX
[速度] 82.40倍速 [設定] Q=0 FPU SSE MMX
[速度] 82.94倍速 [設定] Q=0 FPU SSE2 SSE MMX
[速度] 132.32倍速 [設定] Q=5 FPU
[速度] 137.55倍速 [設定] Q=5 FPU MMX
[速度] 279.73倍速 [設定] Q=5 FPU SSE MMX
[速度] 287.93倍速 [設定] Q=5 FPU SSE2 SSE MMX
[速度] 167.31倍速 [設定] Q=8 FPU
[速度] 169.25倍速 [設定] Q=8 FPU MMX
[速度] 409.86倍速 [設定] Q=8 FPU SSE MMX
[速度] 425.69倍速 [設定] Q=8 FPU SSE2 SSE MMX

Lameに移植されてるFFTの部分だけでもSSEで書き直す価値はありそうだけど。

660 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/22(火) 02:10:56
○SSE4で


661 :デフォルトの名無しさん:2008/01/22(火) 12:46:46
katmai Dual / 3Ghzで鼻からトマトジュースが出てくるところだったw

662 :1 ◆.MeromIYCE :2008/01/22(火) 13:13:05
>>658
お、IntelCPUと計算方法が違うみたいですな。

商の桁数が多い場合でも早く終わるのか、
それとも、商の桁数が少ない場合でも時間がかかるのか。
どちらにしても、最遅で47clkというのは、むしろIntelっぽいクロック数だ。

さて、各社Penrynモデルが出揃って来ましたね〜。

663 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/24(木) 04:46:23
pi_fftc6のpi_cs_thread.exe を64ビットで最適化ビルド。

Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2af.memsave
length of FFT =?
1000000
initializing...
nfft= 1048576
radix= 10000
error_margin= 0.0306172
mem_alloc_size= 37748856
calculating 4194304 digits of PI...
AGM iteration, time= 0, chksum= ffffff33
precision= 48, time= 1, chksum= ffffd1ae
precision= 80, time= 1, chksum= ffffff70
precision= 176, time= 2, chksum= fffff533
precision= 352, time= 2, chksum= ffffc76c
precision= 688, time= 3, chksum= ffffce67
precision= 1392, time= 3, chksum= ffffddbb
precision= 2784, time= 4, chksum= ffffe933
precision= 5584, time= 4, chksum= ffffd40c
precision= 11168, time= 5, chksum= ffffcd14
precision= 22336, time= 5, chksum= ffffc636
precision= 44688, time= 6, chksum= ffffcdf2
precision= 89408, time= 6, chksum= ffffdb95
precision= 178816, time= 6, chksum= ffffdb87
precision= 357648, time= 7, chksum= fffffc04
precision= 715312, time= 7, chksum= ffffce01
precision= 1430640, time= 8, chksum= ffffcf18
precision= 2861280, time= 8, chksum= ffffda53
precision= 5722592, time= 9, chksum= fffff737
writing pi.dat...
Total 9 sec. (real time), chksum= 14fa

664 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/24(木) 05:04:37
↑これほとんどスカラだった。
明示的にSIMD化したら恐ろしいことになるんじゃないのか?


665 :デフォルトの名無しさん:2008/01/24(木) 20:02:47
VIA's New Centaur Designed Isaiah CPU Architecture
ttp://enthusiast.hardocp.com/article.html?art=MTQ1MCwxLCxoZW50aHVzaWFzdA==

VIA、新設計アーキテクチャCPU「Isaiah」を2008年前半に製品投入
ttp://pc.watch.impress.co.jp/docs/2008/0124/ubiq208.htm

666 :1 ◆.MeromIYCE :2008/01/24(木) 20:49:08
>>665
128bit精度の浮動小数点演算というのは書き間違い?
FPのレイテンシが3というのは大したもんだ(単精度の加算だけとか言うなよ)。
L1が64KB+64KBでL2が1MBだが、これだと排他制御が無駄に見える。
仕様が豪華になった分、ダイサイズが増えているのは残念。
性能的にはクロック当たりでCeleronMくらいだろうか。

温度に余裕があるときは、クロックを上げるのではなく
電圧を下げるというのがナイス。
容量を捨てて寿命を延ばしたエネループと同じような思想だね。

667 :665:2008/01/24(木) 21:07:02
> 単精度の加算だけとか言うなよ
[H]Enthusiastに載ってるスライドのp.9-10

全ての浮動小数点加算のレイテンシは2サイクル
単精度の浮動小数点乗算のレイテンシは3サイクル
倍精度と拡張倍精度のスループットは2サイクル、レイテンシは4サイクル

スライドがテキスト化されてるのでこっちのほうがいいかな?
The VIA Isaiah Architecture
ttp://www.extremetech.com/article2/0,1697,2252201,00.asp

668 :1 ◆.MeromIYCE :2008/01/24(木) 22:48:31
>>667
書いてあったのか。ありがとう。
倍精度のスループットは仕方ないけど、加算のレイテンシ2はすごいな。

> world-record
確かK6のfaddがレイテンシ2、スループット2だったと思うけどw
それにしても、この短いレイテンシで2GHzとか出るとしたらすごいな。

個人的にはIn-Orderのままでデュアルコアとかやってほしかったけどな。
(まあ、正直それはバランス悪いんだけど)
これからもVIAらしい萌える石を作っていってほしいです。

669 :デフォルトの名無しさん:2008/01/25(金) 00:56:21
すっかりCNのこと忘れてた。
発表が2004年だったしなあ。
去年中に出るとか言う話をちらっと聞いたりしたが。

中々最先端だな。
Silverthorneといいコイツハオモシロクナッテキタ。

670 :デフォルトの名無しさん:2008/01/25(金) 01:35:09
Latency 4 の 2GHz より 5 の 3GHz の方が速いんだけど...
最初から 2GHz 辺りをターゲットに設計してるんじゃね?

671 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/25(金) 03:40:51
倍精度遅いんか。。。


パイをソニー製のクロいブッタイに移植してみようかと思ったけどめんどくさくて投げた。

672 :デフォルトの名無しさん:2008/01/25(金) 15:24:47
日記あげ


673 :デフォルトの名無しさん:2008/01/26(土) 10:32:22
ダンゴさんがCELLの話題をはじめると盛り上がるな

674 :デフォルトの名無しさん:2008/01/26(土) 16:06:47
>>671
何が面倒臭かったんだ?

675 :デフォルトの名無しさん:2008/01/26(土) 16:07:58
スレチだから返事はこっちに
ttp://pc11.2ch.net/test/read.cgi/tech/1183091522/

676 :デフォルトの名無しさん:2008/01/26(土) 20:39:39
ところでなんで団子さんは職業プログラミンガーから
趣味プロミンガーになったのさ


677 :デフォルトの名無しさん:2008/01/26(土) 22:59:59
X2のG2ってL2レイテンシとか変わってるんだろうかとふと思った

678 :デフォルトの名無しさん:2008/01/27(日) 00:16:57
latency.exeだと20cyclesの判定

679 :ヽ・´∀`・,,)っ━━━━━━┓:2008/01/27(日) 03:04:12
Penrynって64ビットもMeromのときに言われたほど遅くない。むしろ速い。


QPI-QuickPi v4.5 for x64, (c) 2000-2008 S. Pagliarulo
Freely distributable, email: s_pagliarulo@hotmail.com

o Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz detected
o Processor speed measured at 3.17 GHz
o Single processor with dual cores
o 850.9 MB of memory available
o Using default training data

Computation of Pi to 1,048,576 digits
Method used : Chudnovsky
Started : Sun Jan 27 01:52:57 2008

Series size : 73940 (1,048,591 digits)
Computing series, time : 0.70
Computing final value, time : 0.13

Total time : 0.92 seconds
Total memory used : 12,921,033 (12.32 MB)

Processor utilization : 86.43%

680 :デフォルトの名無しさん:2008/01/27(日) 10:35:31
遅いとか騒いだ連中は猫基地外の記事を希望含む視点で読んでしまったアホだけだから。
その遅いCPUよりさらに遅い対抗馬の出来は棚に上げ、
Fusionが効かない効かないと盛んに喚いた基地外もアレだが。

681 :デフォルトの名無しさん:2008/01/28(月) 21:50:11
先月のWinPCの記事はひどかったなぁ

682 :デフォルトの名無しさん:2008/02/05(火) 12:10:19
Phenomで探る、AMD新世代プロセッサの真実 - アーキテクチャ研究編
http://journal.mycom.co.jp/special/2008/phenom01/index.html

大原特集やっときた。
K8とK10で割り算レイテンシが違う(>>658)ことに関してもちょろっと触れられてる。

683 :デフォルトの名無しさん:2008/02/05(火) 23:34:17
毎度の事だが、この手の基本スペックは優れているなK8、K10。
性能はパッとしないけど。リソースの掛け方が間違ってるのかね?
その辺は後編で触れるかな。


684 :デフォルトの名無しさん:2008/02/06(水) 01:17:37
K8は元々のコンセプトが直線ばっか速いIntelより峠だぜ!って感じを受けるよな。
IntelはPenMのチームに軌道修正されて相当救われたと思う。

ただSIMDが既に直線用だったのに、ここのところマルチコア路線になってきて
更にインオーダでSMTにしたらPen4時代以上にスカラでシングルスレッドなアプリがしわ寄せ食うよな。

SMTにする事で全体の効率は上がるわけだが、単体で見れば愕然と遅くなるわけで
高クロック化に限界が見えてる今、ロジック上どうしようもないスカラ部分の足をまた引っ張ろうというのは危険な気がする。

685 :デフォルトの名無しさん:2008/02/06(水) 09:07:37
>単体で見れば愕然と遅くなるわけで
それは過去のバグ付きPen4だけでねーの?
OoOがInOrderになるならそれは確かに当てはまるけど、
SMTになるだけなら性能劣化は誤差程度だべ。

686 :デフォルトの名無しさん:2008/02/06(水) 18:58:54
2スレッド分負荷かけると、全体で120%になるけど単体は60%でしょ、と言いたいのでは
まあ、今回は4コアあるしこれが問題になることは少なそうだけど。

687 :デフォルトの名無しさん:2008/02/06(水) 19:32:09
日本語でおk

688 :デフォルトの名無しさん:2008/02/06(水) 20:16:27
>>685
686さんの説明の通りだけど、P4はOoOじゃなかったっけ?
今後IntelはSMT+InOrderにするっつー話じゃなかった?
不確かな情報ばかりでスマン。

689 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/07(木) 00:33:23
>今後IntelはSMT+InOrderにするっつー話じゃなかった?

そういうのもラインナップに加えるだけで路線を変更するわけじゃない


690 :デフォルトの名無しさん:2008/02/07(木) 12:03:13
>>682
http://pc.watch.impress.co.jp/docs/2006/1016/kaigai312.htm
この辺のL3が半共有キャッシュ的な動きする付近の追試をやって貰いたいなぁ・・・

691 :デフォルトの名無しさん:2008/02/07(木) 12:32:08
http://pc.watch.impress.co.jp/docs/2007/1215/tawada122.htm
キャッシュで思い出したけどなんでメモリアクセスって上のグラフ5みたいに遅いの?
HTの帯域が16GB/secなら素人考えでPC2-6400x2が完全に引き出せてもいい気がしちゃうんだけど。

692 :デフォルトの名無しさん:2008/02/07(木) 14:16:20
SDRAMの最大帯域って理論上の値だから


693 :デフォルトの名無しさん:2008/02/07(木) 14:23:16
その理論値の出ない理由が知りたい。
例えばL1やL2、それに命令のパイプライン実行にかかるクロック数は机上で計算した値と実際は同じになるでしょ。
真の帯域を理論上で算出する事は出来ないの?

694 :デフォルトの名無しさん:2008/02/07(木) 14:53:19
車がどれだけ速くなっても、ドア開けて乗り込んでエンジンかけてシートベルト締めて…なんて時間はたいして変わらない。

695 :デフォルトの名無しさん:2008/02/07(木) 14:58:31
DRAMだから。
DRAMは読み書きにコマンドがいるし、定期的にリフレッシュコマンドも入れなきゃいけない。
PC2-6400 の6.4GB/sって値は上の事を考えないで、データが読み書きできるとしたらという仮定の値。


696 :デフォルトの名無しさん:2008/02/07(木) 15:09:09
DRAMコマンドとかバスプロトコルの問題じゃなく構造の問題でしょ。
レイテンシが低減できないのは。
マルチバンク構成になってるから連続読み書きはある程度理論値に近づく。

697 :デフォルトの名無しさん:2008/02/07(木) 21:04:12
レイテンシ考えた1サイクルあたりの速度だとDDR1やSDRのCL2のものが今でも最速だからね。

698 :デフォルトの名無しさん:2008/02/07(木) 21:06:09
帯域の話でレイテンシの話はしてないだろ。

699 :デフォルトの名無しさん:2008/02/07(木) 21:46:30
君はバースト転送一回分だけというまったく意味のない帯域の話をしたいのか?

700 :デフォルトの名無しさん:2008/02/07(木) 21:55:15
1GB転送するベンチマークでレイテンシも糞もなくね?

701 :ヽ・´∀`・,,)っ¬:2008/02/07(木) 22:04:05
そもそもHTとメモコンは別個だろ

702 :デフォルトの名無しさん:2008/02/07(木) 23:06:11
>>700
もしかしてコマンド一発出したら1GB送られてくる、と思ってる?

703 :デフォルトの名無しさん:2008/02/07(木) 23:11:49
>>702
逆に1GB転送してもバースト転送一回分なの?

どんな事情であれ、プログラマとしてはあんな6.4GBx2/secなんて詐欺ではなくて
正確にクロックとか帯域を計算する方法は無いのかって話なんだが。

理論的に何処まで出せるか、どうしたら出せるかって議論は重要。

704 :ヽ・´∀`・,,)っ¬:2008/02/07(木) 23:16:22
CPUが一度に取り込むのはキャッシュライン単位に決まってるだろう。

705 :ヽ・´∀`・,,)っ¬:2008/02/07(木) 23:24:39
あと、Ring0で実行して計測云々ならまだしも、どうせユーザーモードで触って計ってるんだろ

706 :デフォルトの名無しさん:2008/02/07(木) 23:30:31
Ring0(笑)

707 :デフォルトの名無しさん:2008/02/07(木) 23:40:32
DRAM の仕組みをお勉強してね(はぁと

708 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/07(木) 23:47:54
ばーか

実メモリにダイレクトにアクセスするのですら特権が必要なんだよ。
1GB連続した領域をアロケートしたとして、そこが実メモリなのか仮想メモリなのかはアプリ上からは判別できません


709 :デフォルトの名無しさん:2008/02/07(木) 23:57:34
>キャッシュライン単位に決まってるだろう。
んなこた分ってるよ。で?

>実メモリなのか仮想メモリなのかはアプリ上からは判別できません
そうだけど、マッピングがそんな細切れになるとも思えないし。
つーかバースト転送ってどれくらいのサイズならいいのさ。
仮にマッピングがぐちゃぐちゃだったとしても、1ページは連続してるわけだから多少は効いてくるんじゃないの?

710 :デフォルトの名無しさん:2008/02/08(金) 00:18:46
MEM_PHYSICAL

711 :デフォルトの名無しさん:2008/02/08(金) 00:35:07
最大バースト長が8だから
8x64bit=64Byteより大きくならないのかな?

712 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/08(金) 00:44:11
>>710
AWEサポートしてない環境は無視って素敵だね

713 :デフォルトの名無しさん:2008/02/08(金) 00:46:56
Ring0(笑)

714 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/08(金) 00:49:00
黙れスイーツ(笑)


715 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/08(金) 00:53:21
わざわざ鯖OS入れるくらいならDOSなり自作OSなりで特権命令触ったほうが楽でしょ

716 :デフォルトの名無しさん:2008/02/08(金) 07:04:09
そんなもの誰が使うの

717 :デフォルトの名無しさん:2008/02/08(金) 09:07:32
本当にDOSや自作OS(wが楽だと思ってんのかw

718 :デフォルトの名無しさん:2008/02/08(金) 09:19:50
自作OSの本を読んでみたが、うぎゃーって感じだった。
言っていることぐらいはわかるんだが、とにかく面倒くさくて泥臭くて。

719 :デフォルトの名無しさん:2008/02/08(金) 16:43:45
はいはい団子あげ団子あげ


720 :デフォルトの名無しさん:2008/02/08(金) 17:17:06
サーバOSを入れるほうがよほど「楽」だと思うがなぁ。

721 :1 ◆.MeromIYCE :2008/02/08(金) 18:03:39
俺のPCだと、Dothan-1.1GHzとPC2100で1700MB/secくらいが限界かな。
>>693に同意なのだが、DRAMはプリチャージとか複雑で小難しくて、
最近は、原理は妥協して振る舞いを完全に知ろうというスタンスだ。
情けない状況だ。

>>703
確かに詐欺だね。
どっかで、インターネットが100Mbpsと宣伝しているのにレンタルのモデムだかが
ボトルネックになるから絶対に100Mbpsが出ないということで
宣伝の仕方がおかしいという話を見たことがあるが、それと似てる。

722 :デフォルトの名無しさん:2008/02/08(金) 18:14:36
それを言ったら SATA だってそうだし.P2P の転送路を持つデバイスは皆アウトじゃない?

723 :デフォルトの名無しさん:2008/02/08(金) 18:19:32
Hardware ってのはそういうもの,あるいはそういう約束,で FA.

724 :デフォルトの名無しさん:2008/02/08(金) 19:58:56
ディスクデバイスは帯域がいくら上がったところでディスクの性能が追いつかないっしょ。
殆どはキャッシュの性能と言っていいんじゃないだろうか。

ISPが詐欺なのは人災だから置いとくとしても、
LANはノイズが入るから転送効率何%とかちゃんと数値があるっしょ。
メモリは6.4GBxDual Channel/sec=12.8GB/sec出ると言っておきながら
Phenom9900でさえ4.5GB/secしか出てないわけで、35%しか出てない。
転送効率とかって次元じゃない気がする。

725 :デフォルトの名無しさん:2008/02/08(金) 20:03:14
>>724
> LANはノイズが入るから転送効率何%とかちゃんと数値があるっしょ。
ないよ。少なくともノイズがどうこういうだけで転送効率は定まらない。

> Phenom9900でさえ4.5GB/secしか出てないわけで、35%しか出てない。
CPUはDRAMにとって好ましい最適な転送パターンを行わない。
#HDDでランダムシークばかりして「スピードでねー」とほざくのと同じ。

理想的パターンで読むデバイスをFPGAかなにかで作ればそれなりの速度で
読み出せると思うよ。

726 :デフォルトの名無しさん:2008/02/08(金) 20:12:27
その為のバースト転送なんじゃないの?

727 :デフォルトの名無しさん:2008/02/08(金) 20:28:10
>>724
バスプロトコルから算出した理論的な数字は理想的な特性のメモリを用いた場合等で
算出できるだろうけど、実際にはそんなメモリ無いしあまり意味ないような・・・

実運用での効率を掛けた数字なら、実効帯域とかいう言葉が昔からあるし。

728 :デフォルトの名無しさん:2008/02/08(金) 20:57:01
DRAM の動作をきちんと理解しろ.話はそれからだ.

729 :1 ◆.MeromIYCE :2008/02/08(金) 21:05:30
>>728
理解できないから困ってるんだよヽ(`Д´)ノ

730 :デフォルトの名無しさん:2008/02/08(金) 21:39:18
スレ違い気味だな

ユーザーズマニュアル、テクニカルノート
ttp://www.elpida.com/ja/products/documents.html

DDR3 SDRAM、DDR2 SDRAM、DDR SDRAMの比較
ttp://www.elpida.com/ja/products/ddr3.html

731 :デフォルトの名無しさん:2008/02/08(金) 23:28:39
>>728
お前、理解してないだろ。
なぜならDRAMの動作だけを理解しても>>1の疑問は解決しないからな。
それよりバスの通信の基本を学び、12.8GB/secのデータが常に流れ続けるというのが
ありえることなのか、考え直してみれば普通にわかる。実際はピークでは帯域がでている。
SATAにしろUSBにしろ実効値が遅いというのは帯域という言葉の指し示す範囲が
理解されていないからだ。

732 :デフォルトの名無しさん:2008/02/08(金) 23:33:24
CPUとメモリのやりとりと言っても、通信というのは結局、ある記憶域(ラッチやキャパシタの集まり)か
らある記憶域へと情報がコピーされているだけなのよ。12.8GB/sec流れ続けるというイメージを
持っている人は送り先がの構造を記憶域(CPUでいえばラッチ/レジスタ)だということが頭にイメージできて
ないだけ。それ以外にもプロトコル上で帯域というのがどこを指しているのかという問題があるが、
>>1の疑問の範疇からは多分外れていると思う。

733 :デフォルトの名無しさん:2008/02/08(金) 23:36:54
メモリからメモリへコピーする場合はかなり理想の帯域に近い数字がだせるだろう。
しかし、CPUの記憶域はメモリにくらべてらごくわずかでしょ?それが大部分の原因なんだよ。

734 :デフォルトの名無しさん:2008/02/09(土) 00:09:06
>>731->>733
には大嘘が3割含まれている。これは自分で考え、学習して、
真の理解へ至らせるためのトリックだ。

735 :デフォルトの名無しさん:2008/02/09(土) 00:09:47
>>731
ヘッダ長は大した長さじゃないだろうし、同期に時間がかかるってことかな?
それにしても35%は酷過ぎやしない?

>>732
ニホンゴムズカシイネ。でもここが肝な気がする。

>>733
L3の話ではないよね。
HTが16GB/secだってのは決まってるわけだし、仮に64KBしか無かったとしても
ループバッファみたいにどんどん上書きしていけば連続して読み出すだけなら出来るし。
CPUの記憶域というのは、何かバッファがあるって事?


736 :デフォルトの名無しさん:2008/02/09(土) 00:22:19
俺は DRAM の cycle time がボトルネックなんじゃないかと思ってるんだが
どうだろ?

737 :デフォルトの名無しさん:2008/02/09(土) 00:27:59
理想モデルと実物モデルを比較されても困るという話・・・

738 :デフォルトの名無しさん:2008/02/09(土) 00:37:24
>>724
Streamベンチマークで、10GB/s出たよ。
スレッド数増やしてコア同士で帯域食い合いさせると、
トータルの帯域は上がる。Phenomは特にそんな気がする。
storeはmovntpdにすると速くなる。
環境は9500にDDR2-1066。

739 :ヽ・´∀`・,,)っ¬:2008/02/09(土) 00:48:02
金銀バール
プレゼント

740 :デフォルトの名無しさん:2008/02/09(土) 07:43:14
>>736 Phenomはきちんとしたサイクルでアクセス出来るって書いてあったような。
>>737 ノイズが激しすぎるって事?
>>738 kwsk。Sandraだって複数コアでアクセスするんだがなあ。
>>739 カスラックから来ました

741 :1 ◆.MeromIYCE :2008/02/09(土) 09:27:34
例えば、普通にmovqでシーケンシャルアクセスすると、64byteのロードに47clk、
ちょっと命令を並べ替えると44clk、プリフェッチ命令を使うと39clk。
デコードや実行ユニット関係の、「メモリ以前」の問題もある(微差とは思うが)。
これは古いノートPCだから大して差がないけど、Phenomレベルだとどうなんだろう。

あと、もう一つの「メモリ以前」の問題として、ベンチマークはアテにならないというのがある。
変に実用コードっぽくなってたり、帯域を引き出す工夫が微妙だったりするかもしれない。

>>737
理想の通りに動くのがコンピュータだろうが!
・・・すみません。自分の立ち位置を言っただけです。


ベンチマークは実性能を反映するように求められてるし、
PC側は機能を肥大化させて実性能を少しでも上げようとしている。
クロック測定を通じてアーキテクチャを知るには辛い時代だ。

742 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/09(土) 09:36:02
WinRing0はどうかね?
MSRに変な操作するとすぐカーネル死ぬから注意。


743 : ◆0uxK91AxII :2008/02/09(土) 11:56:09
DRAM - chipset - CPU
ok?

744 :デフォルトの名無しさん:2008/02/09(土) 13:42:14
>>742
お前の大好きな「自作OS」を紹介してやれよw

745 :デフォルトの名無しさん:2008/02/09(土) 14:13:55
>>741
結果を見ると、どうしてもMulti-Media Int x4の成績に行ってしまうが、
これはSandraの問題。Core 2 QuadはSSE3 Moduleで、
Athlon 64 X2やPhenomではSSE Moduleでテストを行うためで、これはイーブンな条件とは言えない。

みたいな事が大原記事でようやく言われましたからねぇ…

とりあえず本当にメモリの帯域調べたいなら
DRAMのスループット以上が出せる設計の上で自分でFPGAなりいじるしか無いのではないでしょうか。
まぁx86の枠外れて完全にスレチになっちゃいますが。

746 :デフォルトの名無しさん:2008/02/09(土) 15:49:23
ダンゴさんのインテリジェンスあふれるレスが望まれるところだ

747 :デフォルトの名無しさん:2008/02/09(土) 16:27:28
だから、メモリアクセスってのは断続的で、ソフトでいくら帯域志向なコードを書いても
送受信している時間とそうでない時間があるの。ピークでは帯域はでているが、
ベンチマークで計測される実効値はこれらの時間の平均。
OSのCPU使用率のように本質的な帯域ではないのだ。帯域と遅延の双方でものを考えないとだめなのは
コンピュータやネットワーク全般の常識。パイプライン化されている命令の実行だってそうだろう。
メモリ側の問題ではなく、ソフトやコントローラ側の問題だよ。
メモリを直でつないでコピーするだけの最小ハードを造れば理想な帯域に近い値だでるだろう。

748 :デフォルトの名無しさん:2008/02/09(土) 16:28:24
OSのCPU使用率がCPUリソースの本質的な使用率を表しているのではないように

749 :デフォルトの名無しさん:2008/02/09(土) 17:01:15
>>745
FPGAで頑張るまでしなくてもピークで帯域が出ているか確認するだけなら、
高価なオシロやロジアナつなげば直ぐにわかることだが。結論からいうと出ているんだけど。

750 :デフォルトの名無しさん:2008/02/09(土) 17:41:07
団子屋さんの団子さんによる団子屋さんのための自作OS「DANGOS」近日公開予定

751 :デフォルトの名無しさん:2008/02/09(土) 17:48:29
団子屋さんに特化したOSってどんなだろう

752 :デフォルトの名無しさん:2008/02/09(土) 18:10:10
今の SDRAM 系の cycle time ってどの位? まだ 50ns 切ってない?

753 :デフォルトの名無しさん:2008/02/09(土) 18:19:41
cycle timeはおまいの脳内でどうやって定義しているの?
データシート見れば、おおよその値はわかるはず。
色んなタイミングの規定があるので、自分の都合上、最も気になる値を抽出すれば傾向は分かるはず。
内部構造と各種タイミングなどの規定に関しての理由を考えるのはスレ違い(もしかしたら板レベルで)
なので、自分で少々勉強した後で考えるヨロシ。

754 :デフォルトの名無しさん:2008/02/09(土) 18:53:38
どうやったr理想的な実効値が出せるんだろうというのを考えてみたりするのがこのスレだったような

755 :デフォルトの名無しさん:2008/02/09(土) 19:24:19
>>751
ベンチマーク測定用OSだな


756 :1 ◆.MeromIYCE :2008/02/09(土) 20:53:31
USB2.0みたいに480Mbpsのうち一部が制御信号に使われるとかはあるのか?
DRAMのアクセスの並列化数に限界があってレイテンシが隠蔽できないのか?
メモリコントローラがネックで並列化数が増やせないのか?
>>747送受信している時間とそうでない時間があるのは何の性能が低いためか?
>>749の言うようにフルな性能は原理的に出せるものなのか?

>>754
原理を知らないと、どうしても最適化アイデアに抜けがでちゃうからさ。
まあ、本当に極限まで最適化をできた人は原理を知っているのと同等だとも思う。

>>755
32bitWindows使いながら64bitコードを実行できるような仮想OSキボンヌ。

757 :デフォルトの名無しさん:2008/02/09(土) 21:21:04
>>756
> 32bitWindows使いながら64bitコードを実行できるような仮想OSキボンヌ。

32bitWindowsに仮想マシン乗せてその上で64bitWindowsを動かして64bitコードを動かせば解決。


758 :デフォルトの名無しさん:2008/02/09(土) 21:23:40
Win64s出せばおk。

Win32sは、16ビット32ビットの壁が薄かったからできた芸当だったけどね。

759 :デフォルトの名無しさん:2008/02/09(土) 21:34:11
64bitWindowsに32bitWindowsってラベルを貼って>>1に渡せばいいんじゃないかな?

760 :738:2008/02/09(土) 22:30:21
>>740
ベンチマークは、ここ
http://www.cs.virginia.edu/stream/
から。いわゆるHPCのメモリバンドのベンチマーク。
Linuxで、gccの4.1以降で、-fopenmpつけて
コンパイルすればマルチスレッドなコードになる。

あとはSSE2とnovntpdなコードにするチューニングは
やったけど、晒すべきなのかね?

761 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/09(土) 22:32:46
3連休の1つがつぶれるのは毎度のことだが
おいらはmovntdqaの性能でも検証してみるかな



762 :デフォルトの名無しさん:2008/02/09(土) 23:05:09
>>756
>USB2.0みたいに480Mbpsのうち一部が制御信号に使われるとかはあるのか?
No。
アドレス線とデータ線は別系統。 
ただし、read/writeでデータがかち合わないようにするためのwaitクロックは入れる必要がある。
(SDRAM以降)
>DRAMのアクセスの並列化数に限界があってレイテンシが隠蔽できないのか?
並列化はかなり多くする事も可能。 Muuti-bank-DRAMなんて物も10年以上前から提唱されてもいる。
>メモリコントローラがネックで並列化数が増やせないのか?
メモリコントローラ・DRAMチップの双方に、コストの壁がある。
バンク数を増やす=ビットコスト(コントローラコスト)の増大と考えて良い。
コストが上がると、ビット単価が安いDRAMを使っている意義に関る。

>>>749の言うようにフルな性能は原理的に出せるものなのか?
>まあ、本当に極限まで最適化をできた人は原理を知っているのと同等だとも思う。
プログラムの中で、同一バンクアクセス回避とか全てを前提として考えられるならある程度は
良くなる。
ただし、バンク切り替え後のアクセスタイムはある程度かかるので、x86命令に存在しない
データプリフェッチとかが必要になると思われる。(あ、それはIA64か?)


763 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/09(土) 23:09:39
いちおうx86にもprefetch*はあるけどね

最近の最適化マニュアルには馬鹿は使うなって書いてあるけど。

764 :760:2008/02/09(土) 23:22:41
ぅぅぅ
×novntpd
○movntpd
Linuxとかcygwinとか、VC持ってる人は暇つぶしにStreamどうぞ。
こういう主記憶シーケンシャルアプリでは、prefetchはほとんど意味が
ないみたい(あくまでもintel, AMDの場合だけど)。
L1のバンクとかは、ほんの少しだけ気を使う。

765 :デフォルトの名無しさん:2008/02/09(土) 23:27:01
ぬーそくから久しぶりに思い出して富んできました。

【IT】「Core 2 Duo」は特許侵害…米大学、インテルを提訴[2/8]
http://mamono.2ch.net/test/read.cgi/newsplus/1202481381/

バースト転送以上に効率的なのはないだろうし、時間のオーダーが違うから本当に中の人じゃないと難しい話題だな。
その辺のロードの事前化をさらに推し進めたのがコアとこのヌース回りなのか?

766 :デフォルトの名無しさん:2008/02/09(土) 23:27:48
流れを読まずに書いてみる。

SDRAMのカタログ性能が最大瞬間風速なんだよ。
そうだな、バースト長8ワードで、8ワード転送するくらいの間の。
もちろんCASレイテンシーぶんのクロック送ったあとね。

767 :デフォルトの名無しさん:2008/02/09(土) 23:34:23
とりあえずデータシートでも読んでみたら?
つ http://www.elpida.com/pdfs/E1128E20.pdf


768 :デフォルトの名無しさん:2008/02/09(土) 23:52:37
>>763
>最近の最適化マニュアルには馬鹿は使うなって書いてあるけど。

w。あ、それじゃ、アフォが大部分を占めるプログラマには使えない命令だな。www
使っても、使った事により効率の落ちる素晴らしい命令。wwwwwwww

αの時代に、既に実装されていたインストラクションだが、50%以上のヒットを
命令実行後のある一定期間に行わないと逆にスピードが落ちるという諸刃の刃だったような。
(大昔のことなので、実装が異なる可能性もあるけどね。)

769 :デフォルトの名無しさん:2008/02/09(土) 23:55:23
だから賢いコンパイラ様に吐き出してもらうのでは。
バカなコンパイラは吐くなってことで。

770 :デフォルトの名無しさん:2008/02/10(日) 00:23:36
ハードウェア・プリフェッチがあるからじゃね?

771 :デフォルトの名無しさん:2008/02/10(日) 02:05:07
レイテンシの隠蔽って考え方自体がおかしい。
隠蔽が成り立つのはマルチタスクかつCPUフルロード状態である場合のみ。
完全にランダムでやけくそに粒度の小さいデータが必要とされる演算を考えてみるんだ。
この場合は上でも何人か書いてるけどセルの最小単位であるSDR-SDRAMの速度しか出ない。
DDR1-SDRAMもDDR2-SDRAMもDDR3-SDRAMも端っこはSDR-SDRAMのままで、
それをいくつかのブロックにまとめて擬似的に拡張・増速した(ようにみえる)だけだから。
技術的にはパラレルバスをどこまで高速化できるかの挑戦ってだけで
メモリコア自体はずーっと変わってない。

772 :デフォルトの名無しさん:2008/02/10(日) 02:30:19
>>771
いいからクソして早く寝ろ

773 :1 ◆.MeromIYCE :2008/02/10(日) 12:03:52
>>762
> ただし、read/writeでデータがかち合わないようにするためのwaitクロックは入れる必要がある。
普通のライト(ライトアロケートあり)がやたら遅いのはこのためかな。

> メモリコントローラ・DRAMチップの双方に、コストの壁がある。
意外とコストに跳ね返るのだね。むむむ。

774 :デフォルトの名無しさん:2008/02/10(日) 15:26:04
http://pc11.2ch.net/test/read.cgi/jisaku/1201341634/909
これはちょっと面白くなってきたかも・・・

775 :デフォルトの名無しさん:2008/02/10(日) 15:29:43
それは普通にHT3.0になったからってだけだろ
CPUの性能とは関わりない
スレ違い

776 :デフォルトの名無しさん:2008/02/10(日) 18:07:16
HT3.0になってそんなに変わったのか知りたい

777 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/10(日) 19:27:45
むしろ最近のマシンじゃエクスペリエンスインデックスは5以上が当たり前かと思ってた。


778 :デフォルトの名無しさん:2008/02/11(月) 01:26:16
本題に戻ろう

779 :デフォルトの名無しさん:2008/02/11(月) 02:04:08
本題とはダンゴ先生のことだが?

780 :デフォルトの名無しさん:2008/02/11(月) 03:00:19
ここはダンゴ劇場


781 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/11(月) 03:20:21
バールのようなものだよ

782 :デフォルトの名無しさん:2008/02/11(月) 04:29:51
じゃあバールのようなもの劇場w


783 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/11(月) 04:38:50
バルバルにしてやんよ

784 :デフォルトの名無しさん:2008/02/11(月) 07:47:00
  オイシスw                ?
 ゥ (⌒─⌒) ムシャムシャ        ∧_∧  ムシャムシャ
 ゥ'`((´^ω^))              (・ω・` )
  '` / つ┗━━━━━━    / つ┗━━━━━━
    しー-J               しー-J

  (⌒─⌒):             ∧,,∧ :
  ((;゙゚'ω゚')):             :(;゙゚'ω゚'):
 : ./ つとl :             :/ つとl : 
 : しー-J              :しー-J :

 (⌒/ヽ-、___           <⌒/ヽ-、___
/(_/____/        /<_/____/

785 :デフォルトの名無しさん:2008/02/12(火) 14:31:12
それバールだったんかw

786 :デフォルトの名無しさん:2008/02/12(火) 16:38:27
「バールのようなもの」だ。

787 :デフォルトの名無しさん:2008/02/12(火) 19:52:18
さあ盛り上がってまいりました

788 :デフォルトの名無しさん:2008/02/13(水) 04:50:29
指定範囲のWORDをひたすらOR取りたいんだけど思いのほか処理が重い
・DWORDでor取って最後にWORDでor
・or eax,[edi];をmovとorに分解してレジスタをたらいまわしにしてペアリング
しか方法が無いのかな?

789 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/13(水) 06:46:52
こう?
for (i = range_begin; i < range_end; i ++) sum |= array[i];


しかし今時ペアリングとかPentium1ですか?


もっとモダンなアーキテクチャならMMX/SSE*が使えるでしょ
por xmm0, [edi]で8並列だ。
16バイト境界にあってる部分だけね


790 :デフォルトの名無しさん:2008/02/13(水) 06:56:36
宿題丸投げスレはここじゃないよ

791 :デフォルトの名無しさん:2008/02/13(水) 08:56:07
それこそ prefetch が使えるんじゃない? SSE で十分かな

792 :デフォルトの名無しさん:2008/02/13(水) 14:59:43
>>788
思いのほか重いってのは、どの程度の帯域を期待してて実測はどの程度ってこと?

動画のフィルタとか書いてて、そういうごく単純なシーケンシャルなメモリ
アクセスを伴う処理ではとても良い性能が出るのにびっくりした記憶があるな。
DDR2 って速いんだな、と。

793 :デフォルトの名無しさん:2008/02/13(水) 15:57:37
>>789
残念なことに使用しているインラインアセンブラがMMX非対応なんですよ

将来的には対応させたいってのがあって、MMXも調べてはいたんですが
mov xmm0,[edi];ができないって聞いていたんでかえって遅くなると
思い込んでいたんですが、por xmm0,[edi];なら問題無いのですね
納得しました

>>792
自分はV30,V33時代にしかx86を触っていなかったんで、最近のCPUなら
超強力なストリングス命令が豊富だと思い込んでいたんです
それこそmovesdのor版とか・・・
仕方なしにor r,mで回すとクロック通りの帯域しか出ていなくって
ペアリングするとPentiumらしい速度になって目から鱗。
MMX,SSEもメモリから直接読み込めないんじゃ机上の空論だな・・・
とこれ以上の高速化を諦めていたんです。

MMXも触ってみたいんで開発環境を見直して見ます
長文失礼しました

794 :デフォルトの名無しさん:2008/02/13(水) 16:17:11
>>793
「インラインアセンブラが」非対応ってよく分からんな。
アセンブラが非対応なら手でバイナリを直接書けばいいんじゃね?

> 自分はV30,V33時代にしかx86を触っていなかったんで、最近のCPUなら
> 超強力なストリングス命令が豊富だと思い込んでいたんです

ストリング命令なんていまどきはやらねぇっすよ。
内部でマイクロコードがシコシコ動くからかえって遅くなることもあるぐらい。

795 :デフォルトの名無しさん:2008/02/13(水) 16:52:27
機械語は高級命令で、CPUの中にコンパイラがあるような現在では
ストリングス命令みたいのを使って抽象化した方が最適になる時代が来るかも知れない。
GPUが既にそんな感じか。

796 :1 ◆.MeromIYCE :2008/02/13(水) 21:15:38
>>793
MMXPentiumとかならまだしも、
SSEが使える最近のCPUならペアリングとか考えなくても大差ないよ。
add r1,mも、mov r2,m/add r1,r2も、速度的に大きな違いがないのが最近のCPU。

> mov xmm0,[edi];ができない
できなくはない。
movdqa xmm0,[edi] とできるが、アドレス値が16の倍数でないと使えない。
movdquならいつでも使えるが、遅い。

> por xmm0,[edi];なら問題無いのですね
porも、movdqaと同じで16byte境界に合ってないと使えないから注意。

> ペアリングするとPentiumらしい速度になって目から鱗。
MMXやSSEを使わずに、or r,mより大幅に高速化できるの?
具体的な方法とCPU名を教えてくださいまし。

lp:
or eax,[edi]
or eax,[edi+4]
or eax,[edi+8]
or eax,[edi+12]
add edi,16
dec ecx
jnz lp

このコードが、PentiumMのL1ヒットで5clk/loopくらい。
L2ミスで完全にメインメモリと思われる16MBの範囲では18.5clk/loop程度。
メモリのピーク帯域の半分以上は出ている。
単にSSE2を使うと17.6clkくらいになる。プリフェッチを使うと16.0clkになった。

797 :デフォルトの名無しさん:2008/02/13(水) 22:09:57
漏れはこういうときって

or eax,[edi]
or ebx,[edi+4]
or eax,[edi+8]
or ebx,[edi+12]

てな感じで依存関係を遠ざけたコード書いてるけど、
最近の CPU だと意味あるのかなぁ。

798 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/13(水) 22:17:41
インラインアセンブラの問題か。
emit文が使えればどうにでもなるんでない?

あるいは
rep por mm0, [edi]

で頭に 66hがついたり。

799 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/13(水) 22:20:39
>>797
LUが2基あるAMDアーキならスループット1クロックに2命令ずつ処理できる。

Intelは1load/clkなんで無意味。


800 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/13(水) 22:23:27
無料開発環境で済ますならVisual C++2008 Expressでいいんでないの。
64ビットもSSE4も使えます。

最近のVCはANSI以前の関数引数形式が使えなくなってるので注意。

801 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/13(水) 22:26:48
あと、movdquでのロードだけど、Core 2以降についてはそんなに遅くない。

連続した領域に対するロードは内部的にpalignrを使って補正してる。


802 :1 ◆.MeromIYCE :2008/02/13(水) 22:32:01
>>797
ああ、忘れてた。orを取る順番は関係ないからそうするべきだね。
ちょっと測定してみたが、クロック数は変わらないようだ。
or処理はレイテンシが1で軽いからだろう。

>>799
まあ、気持ち気持ち。
できるだけ軽くしておくと、いいことあるよ。

803 :デフォルトの名無しさん:2008/02/14(木) 07:38:19
>>793です

>具体的な方法とCPU名を教えてくださいまし。
開発環境はAthlonXPとAthlon64 X2です

>>797
私が実際に使用しているコードもそれと同じです。
一応の最適解と考えて良いのかな?

>>799
P5以降はV,U2基だと思っていたんですが、P5だけなのかな?

804 :デフォルトの名無しさん:2008/02/14(木) 09:53:20
>>803
LU = Load Unit

805 :デフォルトの名無しさん:2008/02/14(木) 10:15:06
>>803
P5はVパイプとUパイプで同時にload可能だったが、
P6以降はloadは専用パイプ1本のみに退化した。

806 :デフォルトの名無しさん:2008/02/14(木) 10:40:02
逆にP5までは命令の並べ替えができないから、利用頻度の高いロードを
両方に持つことで効率低下を防いでる感じかな。
P6以降はLoad+Storeは同時実行できるので特別困らん。

P5までの知識ってのはAgnerの翻訳記事かな?
できれば最近の原本も読まれることをお勧めする。

IntelはP6以降は結構ドラスティックに変化してる。
逆にAMDはK7以降はゆっくり変化してる印象。


807 :1 ◆.MeromIYCE :2008/02/14(木) 19:43:32
>>803
なんだ、Pentiumって言うからIntelだと思ってしまったよ。ごめん。

808 :デフォルトの名無しさん:2008/02/15(金) 21:26:30
最近のCPUでは特にブランチペナルティが大きい。
バラバラな値があるという前提だが、(branch予測効かず)

case-a)
int hex2bin2( char *src )
{
int s1, s2 ;
char tv ;

tv= src[0] ; s1= (tv<='9') ? (tv-'0'):(tv-'a'+10) ;
tv= src[1] ; s2= (tv<='9') ? (tv-'0'):(tv-'a'+10) ;
return (s2<<4|s1):
}

case-b)
int hex2bin2( char *src )
{
int fv ;
int s1, s2 ;
char tv ;

tv= src[0] ; fv= (tv<='9')?-1:0 ; s1= (fv&(tv-'0'))|((~fv)&(tv-'a'+10)) ;
tv= src[1] ; fv= (tv<='9')?-1:0 ; s2= (fv&(tv-'0'))|((~fv)&(tv-'a'+10)) ;
return (s2<<4|s1):
}

では、bが早い。(gccの場合、fvの演算がsetccになるため)



809 :デフォルトの名無しさん:2008/02/16(土) 15:28:10
>>808
ごめん、何がいいたいのかよくわからない。
コンパイラがCPUの特性を踏まえた最適なコードをはかないことがあるから、
コーディングする時は気をつけましょうってこと?

ブランチペナルティが大きいのはパイプラインの段数が多くなったからでしょ?
それを補うためのブランチプレディクションは各社力を入れてる所だと思うけど。

810 :デフォルトの名無しさん:2008/02/16(土) 18:35:47
分岐に偏りがある場合は、分岐予測に任せても問題無いし、むしろ速い。
だが、無い場合はsetxxなりcmov系が使われるコードを書きましょう、って事じゃねえの?

811 :デフォルトの名無しさん:2008/02/16(土) 19:01:40
>>809
分岐が完全にランダムでパターンすらない場合は分岐予測は機能しないので、
分岐後の処理を代入 1 回 (setcc が使われる) に限定されるコードにすれば
最適化が弱いコンパイラでも生成バイナリの速度が速くなるってことでしょ。

808の上と下でコード眺めて a ? b : c の三項演算子部分を比較しただけの
傍観者の意見だけど。

812 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/16(土) 20:25:22
流石にpmaxubで並列化とか使わないんだな。


813 :デフォルトの名無しさん:2008/02/16(土) 20:53:34
808のコードで pmaxub 使える箇所あるかな?
速度を求めるなら

int r;
unsigned char table[256] = {/* 中身は省略 */};

r = table[src[0]] << 4;
r |= table[src[1]];

の方が速そうだとは思うけど。

814 :デフォルトの名無しさん:2008/02/16(土) 20:58:42
半端だなぁ。どうせやるなら。

unsigned int tbl[65536] = {/* (ry */};

unsigned int *p = src;

return tbl[*p];

ここまでいえんのか。

815 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/16(土) 20:59:33
int hex2bin2( char *src )


srcがchar8個とかなら、あるいは・・・・

816 :ヽ・´∀`・,,)っ━━━━━━┓:2008/02/16(土) 21:01:19
>>814
L1キャッシュに収まらない規模のテーブルのランダムルックアップ1回より
小さいテーブル2・3回+論理演算のほうが速いこともある

817 :デフォルトの名無しさん:2008/02/16(土) 21:07:22
そう、おれもこういうコード書くとき>>813のようにメモリ使うのと、
>>808のようにレジスタで済ますのどちらが速いかで迷う。

昔は条件分岐によるパイプラインストールが気になって
>>813のようなコード書いてたけど、今はキャッシュミスの方が
気になって>>808のように書いてる。
prefetch使えばいいのかもしれないけど。

あと、すでに知ってる人は無視してもらいたいけどgccには
builtin_expect()があって、コンパイラに静的なヒントを与えられます。

818 :デフォルトの名無しさん:2008/03/07(金) 02:00:37
http://etd.lsu.edu/docs/available/etd-06122007-093459/unrestricted/Prakash_thesis.pdf
マイコミジャーナルのIntel Core 2の特集でCoreMAはx86命令換算で4命令/Cycleのデコーダ能力を
持っているが実質的には3命令/Cycleを狙ったアーキテクチャだと書かれていますが上のpdfを見ると
Spec CPU2006のIntegerに限って見るとperlbenchの1.6命令/Cycleが最高で全然3命令とか4命令/Cycleに
届いていません。これはどういう事なのでしょうか。

819 :1 ◆.MeromIYCE :2008/03/07(金) 10:28:59
>>818
そういうものです。

CoreMAがピークで4命令/Cycleなのは本当(Fusionでそれ以上も狙えるけど)。
実際のコードでは確かに1.6命令/Cycle出ればいい方。
「3命令/Cycleを狙った」というのは単に個人の考え方だと思われる。

そもそも、IPC3という数字は狙って出せるような半端なものではない。
手でアセンブラを書いて部分的にでも出せればすごいというくらいの領域。

また、1.6命令/Cycleのコードでも、部分的には0.5命令/Cycleだったり、
あるいは4命令/Cycleだったりして、その総合が1.6命令ということだから、
ピーク能力に意味がないわけではない。

820 :デフォルトの名無しさん:2008/03/07(金) 11:29:27
あいつの頭の中はX2は常にIPC3でぶん回ってるらしいから
あまりその辺突っ込んでやらない方がいい。
Phoenomのレビューでも怪しい事書いてたしな。
http://journal.mycom.co.jp/special/2008/phenom02/036.html
の中間あたり。
真正なんだろう。

821 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/07(金) 12:21:30
大原氏への朝鮮状だお
http://tripper.kousaku.in/20080307.html


822 :●テヘ権田●:2008/03/07(金) 12:34:27
>>820
大原君はアム厨っスからね♪

823 :デフォルトの名無しさん:2008/03/07(金) 12:49:46
勘違い糞コテがきたことに絶望した

824 :デフォルトの名無しさん:2008/03/07(金) 13:51:52
糞が糞を呼ぶってか
肥溜めだなここわ

825 :デフォルトの名無しさん:2008/03/07(金) 23:45:36
このスレもついにクソってきたか…。
時代のながれやね…。

826 :●テヘ権田●:2008/03/07(金) 23:52:22
というか糞化さしてるのは>823-824なのだが・・・w

827 :デフォルトの名無しさん:2008/03/08(土) 00:33:43
大原記事のまとめはAMD信者には飴に見えてたりするんだろうか?

828 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 00:54:30
で、>>821の自作popcntの性能だけどさ

C:\Users\ばーるのようなもの\Document\test>popcnt-penryn.exe -32k
32768 B: 7676 clk (4.269B/clk)

ちなみにクロックは素のrdtscで計測。

ちなみに、本物のpopcntは32bitモードじゃいくらあがいても4byte/clkを超えることはないわけでしょ。
誰かPhenomユーザーの人いたら本物のpopcntの性能計測してくれ

ちなみに、まだ命令並べ替えたりすれば微増の可能性あり。


829 :デフォルトの名無しさん:2008/03/08(土) 02:14:01
>>828
Phenomはあるけどコードが書けない。
バイナリくれたらいくらでもテストには協力出来る。
64bit環境も用意しようと思えば出来る。


830 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 02:41:01
ノドイテェ

そのうち作ってみます。まあ32bitで理想状態で4byte/clkってわかってるんだけど。


831 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 02:54:11
続き。

ここまで来るとただのメモリ帯域ベンチなんだが128MBの配列のpopcountしてみた
134217728 Byte: 85154893 clk (1.576 Byte/clk)

ついでだからmovntdqaを使ってみたんだが
134217728 Byte: 91154239 clk (1.472 Byte/clk)

駄目すぎ。シーケンシャルに読み込む分にはキャッシュをバイパスする命令って意味無いね。

832 :デフォルトの名無しさん:2008/03/08(土) 09:54:33
>817
命令を2分割以上にするSSEとかだとデコーダのスループットは1.5命令/cycleだろ。
いくら実行ユニットが3命令/Cycleでも、デコーダのスループットを超える事は出来ん。
ま、K8のSSEユニットのスループットだとそれでもデコードは間に合ってるのかもしれないが。

833 :デフォルトの名無しさん:2008/03/08(土) 12:38:04
ダンゴさんのメモリベンチマークの素晴らしさに誰も口が挟めないな

834 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 13:30:03
>>832
勘違いしてない?
SIMDユニットが64bitだから128bitの操作をする命令が1.5命令/cycleなだけで
MMXや3D Now!, SSEのスカラ命令のデコーダスループットは最大3命令/clk


835 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 17:28:47
あぼーん推奨ワード:ダンゴさんの


836 :デフォルトの名無しさん:2008/03/08(土) 20:19:32
レス番飛びまくりだと思ったらだんごきてるのかよ...。


837 :デフォルトの名無しさん:2008/03/08(土) 20:23:38
スレ主に向かってなんということを

838 :デフォルトの名無しさん:2008/03/08(土) 20:41:51
ハァ?

839 :デフォルトの名無しさん:2008/03/08(土) 21:01:59
>>836
おまえ来なくていいよ

840 :デフォルトの名無しさん:2008/03/08(土) 21:07:43
団子の駄レスでスレが伸びるくらいだったら閑古鳥の方がまし

841 :デフォルトの名無しさん:2008/03/08(土) 21:24:27
↑こんな駄レスしてないで計測でも貼ってみろよカス


842 :デフォルトの名無しさん:2008/03/08(土) 21:26:55
>>840
はっきり言っておまえが邪魔

団子あぼーんしてるのは勝手だがそれ以下のレスしかできない屑に価値は無いな

843 :デフォルトの名無しさん:2008/03/08(土) 21:29:21
>>830
> 理想状態で4byte/clk
サイクル毎にpopcnt r32,m32とadd r32, r32しか
使わないからデコーダに1命令分の余裕がある

空いてるリソースでx86やSSE2で実装したpopcntを
実行できないかな?

844 :デフォルトの名無しさん:2008/03/08(土) 21:35:04
お前ら団子に釣られすぎ
スルーすることを覚えろよいいかげん

845 :デフォルトの名無しさん:2008/03/08(土) 21:39:36
>>844
レスの価値の分別もできないお前が要らない子

クソコテだろうとパフォーマンス計測に有用なレスはOK
ただの煽りは無視だろ

846 :デフォルトの名無しさん:2008/03/08(土) 21:43:36
愉快なインターネッツだここわ

847 :デフォルトの名無しさん:2008/03/08(土) 21:45:38
>>839
>>841
>>842
>>845
ダンゴさんが顔真っ赤にして書き込んでいると言うことでよろしいか?

848 :デフォルトの名無しさん:2008/03/08(土) 21:57:04
俺団子じゃないけど俺も顔真っ赤
別の意味で

849 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 22:23:23
>>843
確かにそのへんは試してみたい。問題は命令実行の比率だな。
2並列に動かせばレイテンシは隠蔽できるかな。
Nehalemなら2スレッド動かすだけでOKっぽいんだけど

計算してみるにSSSE3でのIPCは2.5命令/clk弱で、うまく詰めてやれば、ユニット数の3近くまでは
引き出せるとは思ってるんだが・・・

SSE2版はこいつね
http://coding.derkeiler.com/Archive/Assembler/comp.lang.asm.x86/2006-04/msg00194.html

そもそも1クロック1命令程度しか余り命令帯域使えないならパフォーマンス的にも微妙なので
数ビット単位でテーブルルックアップしたほうが速いかもしれん。
ロードユニットも毎クロック1つ余るからね。
ALUとFP/SIMD並列動作で最高6IPCだ!とか言ってた人がいたけど、デコードとリタイアが
3命令/clk縛りなので現実としては無理れす。

850 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 22:28:42
まあ、ただの荒らしには無視していただいたほうが都合がいいんだけど
約5時間の間にすらプログラムとは関係ない話の割合が9割超えるって凄いスレだな

851 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/08(土) 22:32:47
とりあえずは
・popcntのみ
・SSE2のみ
・popcnt版とSSE2版を2命令:1命令の比率くらいで混ぜたもの

くらいのを作ってみるかな。



852 :デフォルトの名無しさん:2008/03/08(土) 22:43:43
化石しか持ってないから話題についていけない

853 :デフォルトの名無しさん:2008/03/08(土) 22:50:09
むしろ化石みたいなx86の所要クロックネタの方が貴重かもよw

854 :●テヘ権田●:2008/03/09(日) 00:32:52
> ALUとFP/SIMD並列動作で最高6IPCだ!とか言ってた人がいたけど
それ大原じゃんw
確かC2Dが5IPCならX2は6IPCとか騒いで恥をかいてたな。

855 :デフォルトの名無しさん:2008/03/09(日) 00:39:11
ダンゴさんによる自演に見せかけた荒らしも
ダンゴさんがビシっとしめてくれたな

856 :デフォルトの名無しさん:2008/03/09(日) 00:52:04
一番恥ずかしいコテがきたよ…
団子はこのスレには貢献してるから全然問題ないがこいつは…

857 :デフォルトの名無しさん:2008/03/09(日) 01:01:42
団子の貢献っぷりには同意だ
稀有な存在だと思う

858 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/09(日) 01:02:27
権田の下のレスが飛んでる。

SSSE3版popcountを2スレッド起こしてループしたらさ・・・みるみる温度上がるわけよ
ストレステスト(笑)用途にはそこそこ効率のコードならなんでもいいんじゃないの?

859 :デフォルトの名無しさん:2008/03/09(日) 01:21:23
団子さんのベンチマークソフトはCPU泣かせだな

860 :デフォルトの名無しさん:2008/03/09(日) 06:50:19
あぼーん推奨ワード:ダンゴ, 団子

861 :デフォルトの名無しさん:2008/03/09(日) 09:08:20
だんごっ、だんごっ

862 :デフォルトの名無しさん:2008/03/09(日) 11:28:23
さっきからDANGOをあぼーんにしろってレスが多いが、
これはバールって呼んで欲しくてDANGOが自演してるという理解でよろしいか

863 :デフォルトの名無しさん:2008/03/16(日) 16:02:28
バールのようなダンゴ

864 :デフォルトの名無しさん:2008/03/16(日) 16:10:42
バールもアボーンしとけ。

865 :デフォルトの名無しさん:2008/03/16(日) 18:27:13
ミリバール


866 :デフォルトの名無しさん:2008/03/17(月) 06:57:15
ヘクトパスカル使え

867 :デフォルトの名無しさん:2008/03/20(木) 16:10:52
金銀バールプレゼント

868 :デフォルトの名無しさん:2008/03/20(木) 17:05:25
「金銀バールのようなもので…」

869 :デフォルトの名無しさん:2008/03/20(木) 21:00:52
他の板でもバカよばわりされててワロタw


870 :デフォルトの名無しさん:2008/03/20(木) 21:10:35
バカ呼ばわりだなんて。
まるでバカじゃないみたいじゃないですか。

871 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/20(木) 22:32:08
ばーかばーか

872 :デフォルトの名無しさん:2008/03/20(木) 22:42:30
ばかキターwww


873 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/20(木) 23:04:00
ばかのようなものだよ

874 :デフォルトの名無しさん:2008/03/20(木) 23:19:05
ばかのようなものだなんて。
ほんとうはばかじゃないとでも言うんですか?

875 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/21(金) 01:17:48
バッルバッルにしてやんよ

876 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/21(金) 06:46:47
バールのようなものだよ

877 :デフォルトの名無しさん:2008/03/23(日) 12:29:02
2ちゃんねるで所有権も糞も無いが
団子はもうすこし>>1のスレを荒している自覚を持って欲しい。

878 :デフォルトの名無しさん:2008/03/23(日) 14:48:32
ダンゴさんを見かけるスレはことごとく活気があるな

879 :デフォルトの名無しさん:2008/03/23(日) 19:51:27
>>877
数年に渡って何度言っても無駄なんだから
あきらめも必要だよ

普通の対応で対処できると思っちゃだめ


880 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/23(日) 20:43:20
はいはい荒らし乙
クロック計測結果貼らない奴は荒らしですよね

881 :デフォルトの名無しさん:2008/03/23(日) 21:22:29
そうだぞ。クロック貼ってるダンゴさんは何をしても許されるのダ!


882 :デフォルトの名無しさん:2008/03/23(日) 22:10:38
こいつ救えないね

883 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/23(日) 22:13:04
>>882←こいつ役に立たないくせに巣食ってるね

俺以降計測結果誰も貼ってないよね

884 :デフォルトの名無しさん:2008/03/23(日) 22:35:08
そうだそうだ!
ここは団子さん以外書いちゃダメだゾ!


885 :ヽ・´∀`・,,)っ━━━━━━┓:2008/03/23(日) 22:40:49
さて、言い出しっぺが何とやらなんで

http://www.geocities.co.jp/SiliconValley-Oakland/8071/loadbench.html

のWin版で movdqa と movntdqaに対応したやつの結果でも貼っておくか
なるべく正確に計るためにSetProcessAffinityMaskでコアを片方に固定。

load 帯域 計測ツール v0.4+ (だんごやさんがいじったやつ)
CPU動作クロック : 3170.2 MHz

アクセス範囲 Int32bit Float64bit MMX64bit SSE128bit SSE2-128bit SSE4.1-128bit
1KB : 11927 MB/S 22428 MB/S 23780 MB/S 47684 MB/S 47516 MB/S 47726 MB/S
2KB : 11910 MB/S 22396 MB/S 23821 MB/S 47676 MB/S 47608 MB/S 47585 MB/S
4KB : 11924 MB/S 22472 MB/S 23806 MB/S 47637 MB/S 47600 MB/S 47645 MB/S
8KB : 11904 MB/S 22430 MB/S 23819 MB/S 47613 MB/S 47661 MB/S 47725 MB/S
16KB : 11893 MB/S 22392 MB/S 23849 MB/S 47528 MB/S 47734 MB/S 47616 MB/S
32KB : 11826 MB/S 22388 MB/S 23317 MB/S 44868 MB/S 44864 MB/S 44900 MB/S
64KB : 9718 MB/S 16897 MB/S 16897 MB/S 22475 MB/S 22481 MB/S 22465 MB/S
128KB : 9723 MB/S 16862 MB/S 16878 MB/S 22402 MB/S 22420 MB/S 22450 MB/S
256KB : 9731 MB/S 16940 MB/S 16936 MB/S 22409 MB/S 22393 MB/S 22370 MB/S
512KB : 9695 MB/S 16938 MB/S 16929 MB/S 22346 MB/S 22368 MB/S 22373 MB/S
1024KB : 9746 MB/S 16883 MB/S 16901 MB/S 22394 MB/S 22374 MB/S 22340 MB/S
2048KB : 9499 MB/S 16788 MB/S 16798 MB/S 22632 MB/S 22639 MB/S 22626 MB/S
4096KB : 9476 MB/S 16483 MB/S 16610 MB/S 22257 MB/S 22492 MB/S 22593 MB/S
8192KB : 5385 MB/S 6156 MB/S 6131 MB/S 6502 MB/S 6553 MB/S 6582 MB/S
16384KB : 5310 MB/S 5844 MB/S 5905 MB/S 6145 MB/S 6134 MB/S 6140 MB/S
32768KB : 5354 MB/S 5865 MB/S 5912 MB/S 6136 MB/S 6158 MB/S 6163 MB/S

このへんはあんまり面白みのない結果だ
もう一個のレイテンシ計測ツールの改造版が面白いことになりそうだな

886 :デフォルトの名無しさん:2008/03/24(月) 09:56:41
クロック数が乗ってないレスは全部あぼーんすればいんじゃね?

887 :デフォルトの名無しさん:2008/03/24(月) 10:14:28
だんご本人の書き込みよりも本文に「だんご」の文字がある方がうざい(コレもな〜)


888 :デフォルトの名無しさん:2008/03/24(月) 16:11:30
じゃあバールにしよう


889 :デフォルトの名無しさん:2008/03/25(火) 07:30:32
金銀バール

890 :デフォルトの名無しさん:2008/03/25(火) 07:34:25
ポケットモンスター
ダイヤモンド&ヽ・´∀`・,,)っ━━━━━━┓

891 :デフォルトの名無しさん:2008/03/25(火) 10:34:55
今日もダンゴさんがスレを活性化させてるな


892 :デフォルトの名無しさん:2008/03/25(火) 20:44:17
あなたが落としたのは、この金のバールのようなものですか?
それとも、この銀のバールのようなものですか?

893 :デフォルトの名無しさん:2008/03/26(水) 08:44:31
すっかりクソスレになったな

894 :デフォルトの名無しさん:2008/03/26(水) 14:59:30
話題が無い。
Nehalemはやくこいや。

895 :デフォルトの名無しさん:2008/04/02(水) 21:50:32
ttp://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf

896 :デフォルトの名無しさん:2008/04/03(木) 08:57:06
>>505のサイトに追加されていた
00106C2 Intel Atom 230 (Silverthorne)
ttp://www.freeweb.hu/instlatx64/InstLat_GenuineIntel00106c2_Atom_Silverthorne_1600MHz.txt

発見元
ttp://aceshardware.freeforums.org/silverthorne-details-t380-15.html#5822

後藤氏の記事とも一致する

Intel、IDFでAtomプロセッサを正式発表
ttp://pc.watch.impress.co.jp/docs/2008/0402/kaigai432.htm
> 整数SIMD演算では128bitsのSIMD演算を実行できる、2つのSIMD ALUと
> 1つのシャッフルユニットを備える。浮動小数点SIMD演算では、乗算
> ユニットは64bitsだが、加算ユニットは128bitsになっているという。

897 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/03(木) 18:21:55
AVX ktkr

898 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/03(木) 18:28:01
YMMかよwwwww

LarrabeeのSIMD拡張はZMMでつか?

899 :デフォルトの名無しさん:2008/04/03(木) 18:33:35
それは思った

900 :896:2008/04/03(木) 20:10:30
後藤氏の記事微妙に違ってた
ttp://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3276&p=5
128bit fp加算は単精度だけ。それ以外は64bitらしい

Nehalemの記事でも勘違いしてる

IDFで公開された「Nehalem」の内部アーキテクチャ
ttp://pc.watch.impress.co.jp/docs/2008/0403/kaigai433.htm
> 命令発行ポートは5から6へと増加
Meromから6ポートなんだが

Nehalemの記事中で使っているスライドはこれと同じものかな?
Inside Intel(R) Next Generation Nehalem Microarchitecture
ttps://intel.wingateweb.com/SHchina/published/NGMS001/SP08_NGMS001_100r_eng.pdf

901 :デフォルトの名無しさん:2008/04/03(木) 20:16:23
VEXプレフィックスの追加でx86のOPCODEマップがますます複雑になるな
よっぽどAMDが策定したREXを使うのが嫌だったんだな

902 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/03(木) 20:53:29
さっそくXbyakを改造してる俺様
しかし早くてあと2年か・・・

903 :1 ◆.MeromIYCE :2008/04/03(木) 21:11:02
>>900
addpdが6サイクル、mulpdが9サイクルかかってるね。
faddのスループットが2なのもちょっと気になるか。

それにしてもAtomいいな。Atom向け最適化をしてみたい。
パワーのあるメインマシンが手に入ったら、
二台目として是非欲しい。

904 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/04(金) 07:07:02
>>901
SSE5のDREX+OCも十分変態

905 :デフォルトの名無しさん:2008/04/04(金) 10:33:54
binutils-2.18.50.0.6が出た。
Add Intel AES, CLMUL, AVX/FMA support.
だそうな
hjl毎度オツカレー

906 :1 ◆.MeromIYCE :2008/04/10(木) 23:24:29
定数除算(符号なし)を考えてみた。
動機は、16bitとかのSIMDで、定数除算ができるようにしたかったから。
速度うんぬんというより、SIMDには整数除算の命令自体がないから不便だった。

http://pc11.2ch.net/test/read.cgi/tech/1103609337/400
↑ここの、819で割るのと同じ方法でいけるようだ(除数は2以上なら何でもいい)。


変数は全てk bitの符号なし整数とする。整数しか代入しないことに注意。
「計算方法」とあるのは、kが32で、x86命令を使う場合のやり方。
「^」はベキ乗、「=」は等号または代入。
「/」は整数除算ではない。例えば、5/2=2 ではなく、5/2=2.5 である。
しかし、以下の計算では、除算の結果が全て整数になるように仕組んである。


1 < A < 2^k を満たすAを、除数とする。

2^m < A <= 2^(m+1) を満たすようにmを定める。
E := 2^(m+1) - A とする。
すると、0 <= E < 2^m < A <= 2^(m+1), 0 <= m < k が成り立つ。

(2^k)*EをAで割り、小数点以下を切り上げたものをBとする。
F := A*B - (2^k)*E とする(余りみたいなもの)。
すると、0 <= B < 2^k, 0 <= F < A が成り立つ。
#計算方法:edx = (2^k)*E、eax = A-1とし、div Aを実行、F = (a-1) - edx、B = eax とする。

ここまでで、除数Aによる定数除算の準備が完了。
ここで求めたBとmを使って定数除算ができる。
(Fは後で説明に使うだけで、求める必要はない)

907 :1 ◆.MeromIYCE :2008/04/10(木) 23:27:06
0 < P < 2^k を満たすPを、被除数とする。
商をQ、剰余をRとおくと、P = Q*A + R, 0 <= R < A を満たす。

次のようにC,tを定める。
C := (B*P) mod (2^k) (求める必要はない)
t := (B*P - C) / (2^k)
#計算方法:eax = Bとし、mul P を実行、t = edx、C = eax とする。
0 <= C < 2^k, 0 <= t < P < 2^k が成立する。

u := (P - t) mod 2 (求める必要はない)
D := (P - t - u) / 2 + t
すると、0 <= u <= 1。
#計算方法:P - t を求めて右に1bitシフトすれば、uを引いて2で割ったのと同じことになる。

ここで、Dをm bit右シフトすると、商のQになる。
今までと同じように言えば、d = D mod (2^m) として、
Q := (D - d)/(2^m) とする。


Qが求まったので、計算方法についてはここまでで終わり。
ここからは、この方法でQが正しく求まることを、証明する。

908 :1 ◆.MeromIYCE :2008/04/10(木) 23:44:27
Dについて計算していくのだが、少し注意点を。
変数F,C,uを導入することで、計算の過程で出てくる数値が全て整数になるよう配慮してきた。
よって、適切に整数命令を使えば、CPUは厳密な答えを出すことができる。
そればかりか、証明の過程においては、整数でない数値が出てきても、何の問題もない。

D = P/2 + t/2 - u/2
= P/2 + t/2 - u/2
= P/2 + (B*P - C) / ((2^k)*2) - u/2 (t = (B*P - C) / (2^k) より)
= P/2 + (2^m)*P/A - P/2 + P/((2^k)*2) * F/A - C/((2^k)*2) - u/2 (注1)
= (2^m)*P/A + ( P/(2^k) * F/A - u - C/(2^k) ) / 2
= (2^m)*Q + (2^m)*R/A + ( P/(2^k) * F/A - u - C/(2^k) ) / 2

(注1)
F = A*B - (2^k)*E から、B = (2^k)*E/A + F/A。
E = 2^(m+1) - A なので、B = (2^(k+m+1))/A - (2^k) + F/A。
よって、B*P/((2^k)*2) = (2^m)*P/A - P/2 + P/((2^k)*2) * F/A。

さて、D を2^m で割って小数点以下を切り捨てたらQになると言えるか?
(2^m)*Q <= D < (2^m)*(Q + 1) が条件だから、
0 <= (2^m)*R/A + ( P/(2^k) * F/A - u - C/(2^k) ) / 2 < 2^m であればいいわけだ。
ちなみに、D - (2^m)*Q = (2^m)*R/A + ( P/(2^k) * F/A - u - C/(2^k) ) / 2 である。

その与えられた余裕の2^m に対して、(2^m)*R/A のインパクトはどれくらいかというと、
A <= 2^(m+1) であることを使って、
(2^m) - (2^m)*R/A = (2^m)*(1 - R/A) >= (2^m)*(1/A) >= (2^m)*(1/(2^(m+1))) = 1/2
つまり、残された(上への)余裕は1/2だ(1/2未満ならよくて、1/2だとダメかもしれない)。

対して、(2^m)*R/A の最小値は0で、このとき下への余裕はゼロになる。
しかし、Dは整数であることが保証されているので、
(2^m)*Q が整数だから、D - (2^m)*Q も整数であることがわかる。
つまり、-1 < D - (2^m)*Q であることさえ言えれば、0 <= D - (2^m)*Q が言える。
#ある実数が-1以下ではない整数なら、その数が0以上なのは当然である。

909 :デフォルトの名無しさん:2008/04/10(木) 23:55:06
http://hp.vector.co.jp/authors/VA003988/pentopt.htm#SPECIAL-10

910 :1 ◆.MeromIYCE :2008/04/10(木) 23:58:51
Dの式の中に出てきた、P/(2^k) * F/A - u - C/(2^k) について評価する。

P/(2^k) * F/A - u - C/(2^k) < (2^k)/(2^k) * A/A - 0 - 0/(2^k) = 1
P/(2^k) * F/A - u - C/(2^k) > 0/(2^k) * 0/A - 1 - (2^k)/(2^k) = -2

よって、-1 < D - (2^m)*Q < ((2^m) - 1/2) + 1/2 = 2^m
0 <= D - (2^m)*Q < 2^m を満たせばよかったので、これでOKだ。
#上で述べたように、-1 < D - (2^m)*Q であれば0以上が言える。

証明終わり。


計算疲れた。間違ってたらと思うとぞっとする。
変数名のセンス悪くてすまん。

911 :デフォルトの名無しさん:2008/04/11(金) 13:17:06
突然落書きが始まったので驚いた。

912 :デフォルトの名無しさん:2008/04/11(金) 13:23:30
元々>>1の勉強スレ

913 :デフォルトの名無しさん:2008/04/11(金) 13:39:46
それがどうした。

914 :デフォルトの名無しさん:2008/04/11(金) 13:41:53
確かに>911が驚くのは勝手だな。別に「落書きするな」と指摘したわけでもないし。
だがそれと同様に、>912の指摘も勝手だ。だから、>913の指摘は余りに無意味だ。

勿論、このレス自体も殆ど意味がないな。

915 :デフォルトの名無しさん:2008/04/11(金) 14:06:53
分かってるなら書くなよ。

916 :デフォルトの名無しさん:2008/04/11(金) 14:10:05
>>914
>912の指摘もあまりに無意味だな。
実態もスレタイも「>>1の勉強スレ」ではないのだから。
それが分かってるから>912も「元々」と頭につけざる得なかったわけだし。

そんないまさらな昔話に対しての指摘として>913は的確なものだろう。

917 :デフォルトの名無しさん:2008/04/11(金) 19:09:27
分かってないのに書くなよ。

918 :デフォルトの名無しさん:2008/04/12(土) 01:10:22
あの除算の効率についてコメントできるのはダンゴさんぐらいだろうな

919 :1 ◆.MeromIYCE :2008/04/12(土) 08:40:42
>>918
除数に対するBとmをあらかじめ計算しておいて次のコードを実行するだけだから、
効率については特に難しくないよ。単にクロックを計算すれば、9clk前後か。

//esiに被除数、eaxにB、ecxにmが入っているとする
mul esi
sub esi, edx
shr esi, 1
add esi, edx
shr esi, cl

>>909の方法を検証しているが、計算疲れたよ('A`)

920 :デフォルトの名無しさん:2008/04/12(土) 13:52:23
AMDが最適化についてのビデオを作ったようです
ttp://developer.amd.com/documentation/videos/pages/SoftwareOptimizationVideoSeries.aspx

921 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/12(土) 17:57:23
SIMD的には、 65536/非除数 を計算しておいて pmulhwかな?

922 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/12(土) 17:57:51
×非除数
○除数

923 :1 ◆.MeromIYCE :2008/04/12(土) 18:37:33
>>921
SIMDの場合、被除数の範囲が狭いだろうから、ある程度簡単にできそうだね。

>>909も大体証明が終わった。
あとは、四捨五入用のやり方を考えて、
MMXで、255で割るコードを作るぐらいできればいいかな。

924 :1 ◆.MeromIYCE :2008/04/16(水) 22:10:44
>>909の証明完了。
四捨五入は、除数の1/2倍(小数点以下は切捨て)を被除数に足してから処理すればいい。
除数の1/2倍を足すと、除数や被除数の制限が出てくるが、
SIMDなら問題にならないことが多いだろう。

>>909の方法だと、被除数が2^k-1のときに分岐が必要になるのだが、
それが問題だというなら、>>919の方法を使えばいいし、
問題でないなら>>909の方法がいい。

まあ、Penrynだと、32bitの除算は14〜22clkだからなあ。
うまく並列化できないと、そんなに速くはならないね。

925 :ヽ・´∀`・,,)っ━━━━━━┓:2008/04/23(水) 21:34:36
Meromノートでpopcnt-sse3(>>828)を実行したら1.634byte/clkだった。
Super Shuffle Engineは偉大だな。

926 :デフォルトの名無しさん:2008/05/10(土) 01:26:24
3

927 :デフォルトの名無しさん:2008/05/14(水) 18:11:02
Intelがやってくれた。
Core 2 Duo E8500(CPUID=10676)だけど、
新しいマイクロコードパッチID=60Bを入れると、
LSDループ内でマクロフュージョンが効かなくなるっぽい。

WinXP SP3を入れたらマクロフュージョンが効かなくなったので、
おかしいと思い、update.sysだけ古いバージョンに書き換えてみたら、
マクロフュージョンが効くようになった。
使っているMBのBIOSは古いままでパッチID=606が適用されている。

以前、このスレで話題に挙げた1clk/loopで回る5命令のループだが、
パッチID:60Bを適用すると、2clk/loopに落ちてしまう。

align 16
lp:
add eax,[esi]
mov [esi+16],ecx
inc ecx
cmp ecx,ebx
jb lp

928 :デフォルトの名無しさん:2008/05/14(水) 18:11:16
このループをPMCで詳しい内訳を調べてみると、

パッチID:606の時は1ループ当たり
 リタイヤμOP=4(その内、マクロFusedμOP=1)
 ディスパッチμOP=6

パッチID:60Bの時は1ループ当たり
 リタイヤμOP=5(その内、マクロFusedμOP=0)
 ディスパッチμOP=7

となった。

パッチID:60Bの時でも、
ループ内にnop命令を15個挿入して1ループ20命令にすると
マクロフュージョンが効くようになる。
nop命令10個の1ループ15命令だと
マクロフュージョンが効かない。
LSDが効くループ内でマクロフュージョンが効かなくなったと思われる。

929 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/14(水) 20:22:18
俺もE8500だけどVista SP1で検証してみるかな。

案外μcodeアップデートでx64でもフージョン効くようになるんじゃないのか

930 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/14(水) 20:28:05
http://journal.mycom.co.jp/column/sopinion/188/

を使ったけど効いてるみたいだ。

931 :927:2008/05/14(水) 21:15:54
>>930
CrystalCPUIDで表示されるCPUのMicrocode IDはいくつですか?

うちの32bitWindowsXP SP3 + E8500だと、そのページのプログラム
http://journal.mycom.co.jp/column/sopinion/188/Util29.exe
の"Util29 100000"の実行結果は以下のようになります。

 Microcode ID : 606
Test1 100776
Test2 200203
Test3 200203
Test4 200174
Test5 300114
Test6 400102

 Microcode ID : 60B
Test1 200222
Test2 200298
Test3 200317
Test4 200146
Test5 300143
Test6 400102

932 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/14(水) 21:36:50
606だった。
OSはVista Ultimate SP1 x64

C:\Downloads>Util29.exe 100000
Test1 158498
Test2 316825
Test3 345933
Test4 316863
Test5 475190
Test6 633498


なんじゃこりゃと思ったがどうやらEISTが有効だったらしいので電源プラン変更して再計測

C:\Downloads>Util29.exe 100000
Test1 108063
Test2 200099
Test3 200156
Test4 200108
Test5 313053
Test6 440229

933 :927:2008/05/14(水) 22:55:10
>>932
606ということは、VistaSP1には新マイクロコードは入ってないんですね。

934 :デフォルトの名無しさん:2008/05/16(金) 01:08:25
PenrynにXP SP3入れるとSP2よりパフォーマンスが落ちるってことか?
Vistaへ移行させるためのMSの罠?

935 :デフォルトの名無しさん:2008/05/16(金) 01:17:44
ここはプログラム板なんだから、そんなアホなこと書くなよ。お里が知れるぞ。


936 :デフォルトの名無しさん:2008/05/16(金) 05:31:53
エラッタリストに関係ありそうな記述を見つけた。

http://download.intel.com/design/processor/specupdt/318733.pdf
> AW51. Short Nested Loops That Span Multiple 16-Byte Boundaries May
>      Cause a Machine Check Exception or a System Hang

小さい多重ループでシステムハングを引き起こすものがあり、BIOSで対処可能との事。
LSDが効くような小さいループで多重ループをするとやばいケースがあるので、
LSDループ内ではマクロフュージョンを無効にして対処したってことかなぁ?

エラッタAW51がこの文書に追加された日は2008年2月1日と書かれており、
マイクロコードパッチID:60Bの作成日は2008年1月19日なので
時期的にも近い。

937 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/16(金) 08:00:27
さて、もういっこパフォーマンスに関係しそうなエラッタとして
movntdqaと通常のロードで同時に同じキャッシュラインをアクセスすると
ハングるのがあった気がしたがどう修正してるのか

938 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/16(金) 08:29:29
マザボの最新BIOS更新されてる。これ適用すると60Bになるんだろうな。

939 :デフォルトの名無しさん:2008/05/23(金) 20:28:01
>>936
2月
http://download.intel.com/design/processor/specupdt/31873303.pdf

5月
http://download.intel.com/design/processor/specupdt/318733.pdf

2月 page.12と5月 page.13を比較
AW51がNo FixからPlan Fixになっている

ステッピング変更を待ったほうがいいかな?

940 :デフォルトの名無しさん:2008/05/25(日) 07:48:51
E0ステッピングが6/27に出荷らしいな

941 :デフォルトの名無しさん:2008/05/26(月) 01:13:54
下記のような下手なプログラムでメモリを舐めると
いまどきのプロセッサだとメモリ帯域幅に近い速度が出るの?

↑とても古い
x86ではない某では約200MB/secで、メモリバスの約9%
Coppermine 1GHzでは約300MB/secで、メモリバスの約28%
Northwood 2.4GHzでは約1700MB/secで、メモリバスの約65%
↓古い

int ReadTest(void* pMem, size_t size) {

int* p = (int*)pMem ;
int count = size/sizeof(int) ;

int sum = 0 ;
for (int x=0; x<count; x++) {
sum += p[x] ;
}

return sum ;
}


942 :デフォルトの名無しさん:2008/05/26(月) 09:28:56
>>941
>>691以降参照。
マルチプロセッサを使って全てのバスを使い、
尚かつシーケンシャルに何百GBもかかりっきりでアクセスすると速くなるが
そんな特化したベンチマークでもスペック通りの数字は出せない。

以前Quad-ChannelをSandraで計った時は理論値の50%くらいった希ガス。
ま、現実はベンチマークじゃないんだからもっともっと遅い。

943 :デフォルトの名無しさん:2008/05/26(月) 10:54:26
>>941
Northwoodには自動プリフェッチ機能があって、
メモリをシーケンシャルにアクセスしているストリームを検出すると、256バイト先をプリフェッチしてくれる。
インテルの資料によると、8つまでのストリームを検出できるそうなので、
あいだに別のメモリアクセスが入っても、あるいは、交互にアクセスするなどの場合でも機能するらしい。

一方、同時期の対抗馬だったAthlonXPのハードウェアプリフェッチについては・・・AMD大好きな人に譲る。

944 :941:2008/05/27(火) 01:26:01
>>942
ありがとう。

>>943
prefetchnta命令を使ってみたところ、
Coppermine 1GHzでは約880MB/secで、メモリバスの約87%
Northwood 2.4GHzでは約2000MB/secで、メモリバスの約79%
K7 Palomino 1.2GHzでは約780MB/secで、メモリバスの約38%
になりました。
これだけ出ていれば、ほぼメモリバスは100%稼働なのだと思います。

ちなみにprefetchntaなしでは
K7 Palomino 1.2GHzでは約450MB/secで、メモリバスの約22%
でした。

ついでに2CPUで同時に行った場合(prefetchntaあり)
Coppermine 1GHzでは約440MB/sec×2=880MB/secで、メモリバスの約87%
K7 Palomino 1.2GHzでは約650MB/sec×2=1300MB/secで、メモリバスの約64%
でした。


945 :デフォルトの名無しさん:2008/05/27(火) 02:00:53
K7ダメダメだな。

946 :デフォルトの名無しさん:2008/05/27(火) 12:18:52
K7もなんだかんだで中身三四回変わったよな

947 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/27(火) 18:34:32
Slot A
焼鳥&排他キャッシュ採用
QuantiSpeed(笑)

確かにK7間でえらく改良されてるな。

948 :デフォルトの名無しさん:2008/05/27(火) 19:12:09
> K7 Palomino 1.2GHzでは約650MB/sec×2=1300MB/secで、メモリバスの約64%

何かオカシイんじゃないか?

インテルの糞共有FSBと違ってポイントtoポイント接続だから
780MB/sec×2=1560MB/secでバスの74%くらいになるはず。

そもそも1Pでの780MB/secというのも遅すぎる。
1GB/secしかないインテルの糞FSBに負けるなんてありえない。

949 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/27(火) 20:29:39
2ソケット以上なら各CPUのキャッシュ間のスヌープ制御が必要になるからそのまんまスケールするわけがないじゃん。
んで、相当タコなんだろう。

950 :デフォルトの名無しさん:2008/05/27(火) 21:55:09
>>939
本当だ。Plan Fixに変わってる。
No Fixだったから、Intelはちゃんと直すつもりがないのかと思ってたが、
やっぱりちゃんと直したCPUを出すつもりなんだね。

951 :デフォルトの名無しさん:2008/05/28(水) 05:44:56
>>949
AMD厨は幻想多いよな。

幻想→インテルはFSBが133MHzだがAMDは266MHzだ! 2倍速い。
現実→どちらも133MHzでAMDはバースト転送部分がDDR化されている。つまりオーバーヘッド部分の速度は同じ。

幻想→インテルはFSBが共有だがAMDはポイントtoポイントだ! 帯域を奪い合いしない
現実→メモリを共有するのは一緒だし、キャッシュ同期も必要。

AMD厨は
> Northwood 2.4GHzでは約2000MB/secで、メモリバスの約79%
> K7 Palomino 1.2GHzでは約650MB/sec×2=1300MB/secで、メモリバスの約64%
この現実を見るべきだ。

ちなみにOpteronもSMPでメモリアクセス性能の低下は大きい。
他のソケットの配下にあるメモリにアクセスした場合にレイテンシ増加するだけでなく、
自分のソケットの配下にあるメモリにアクセスする場合でも他のソケットと
キャッシュ同期のために通信するので、それなりに遅くなる。


952 :デフォルトの名無しさん:2008/05/28(水) 06:14:28
夢見がちだから"真の"とか言うマーケティングで踊れるんだろう?
かえってかわいいと思うが。
本当に厄介なのは確信犯的な、その煽り役の方で。

ところでPhotoshopCS4がCUDA対応するようだけど、
AMD的にはSSE5(Fusion)までどうにもならないの?
AtiのCUDAみたいな奴なかったっけ?
これはSSEでやられたみたいに、後々かなり厄介なことになりそうな気がするんだけど。

953 :デフォルトの名無しさん:2008/05/28(水) 07:50:34
命令セット・演算器を拡張するのもいいけどさ、
GPUに色々やらせるのもいいけどさ、
何か別のアプローチも欲しいな。

AMDはHT接続で何かに特化したプロセッサを
混在させることを考えているようだが、
そんなことでは手ぬるいと思う。

メモリへのランダムアクセスの性能を向上させるために、
アドレスとデータをマルチプレクスしてDIOのビット数を増やし、
さらに、通常よりもバンク数を増やしたDRAMを、
バス接続せずに1個ずつ別々のメモリコントローラに接続したものが欲しい。

メモリモジュールのピン数が増えすぎてしまうので、
メモリコントローラと同一基板に直に実装するしかないので、
メインのプロセッサ用のメモリとしてマザーボードに積むわけにはいかない。

したがって、用途に特化したプロセッサのソケットを4つくらい持った
PCI-Express x16のフルサイズのアドオンカードとして出す。

GPUのスケールメリットに勝てそうも無いな。

954 :デフォルトの名無しさん:2008/05/28(水) 08:44:41
意味わかって書いてるのかなぁ。

955 :デフォルトの名無しさん:2008/05/28(水) 13:27:39
>>953
AMD(元ATi)のGPUは、すでにそういう代物になってる。
DRAMコントローラが8個、それぞれに32ビット幅のDRAMを1個だけ繋ぐ仕様。
それでもランダムアクセス時のスループットは100MB/secくらいだと思う。

本当にランダムアクセスの性能が欲しければ、
ttp://www.hitachi.co.jp/New/cnews/040115c.html
のようなキャッシュ向けの製品を使うしか。容量が18MBと少ないけどね。
(昔でいう擬似SRAMで、扱いとしてはDRAMではなくSRAM)

すでに製品としては、
ttp://www.soliton.co.jp/products/expresso_fpga/index.html
こういうのがある。


956 :デフォルトの名無しさん:2008/05/28(水) 17:36:23
>>955
サンプル価格2.5万円か。

メモリ上のバイト列の並びを任意に並び替えてくれるボードがあると面白いかも。

CPUのキャッシュには入りきらないほど大きなデータを、
CPUのキャッシュより大きな高速SRAMを使って、
CPUがアクセスする順序に並び替えてやることで、
いまのCPUが苦手としている処理のうちの、いくらかで、
CPUのキャッシュのヒット率を格段に改善できるかも。

957 :デフォルトの名無しさん:2008/05/28(水) 19:16:13
こういうやつを必要な数だけならべちゃうえば?
http://documentation.renesas.com/jpn/products/memory/rej03c0271_r_hm64ygb36100.pdf

958 :デフォルトの名無しさん:2008/05/28(水) 19:47:24
>>955
ランダムアクセスでサイクルタイムが8.0ns、I/O幅が128bit or 256bitってすごいな。
つまり、32バイト単位でのランダムアクセスで4GB/secのスループットが出るのか。

959 :デフォルトの名無しさん:2008/05/28(水) 19:52:33
>>956
その高速SRAMをキャッシュとして使えば、
ソフトウェアの変更は、
事前にシーケンシャルにメモリを舐めておく
というだけで済むし、
他の部分でも高速化に寄与するだろう。


960 :デフォルトの名無しさん:2008/05/29(木) 10:15:35
その高速SRAMはどこのバスにぶら下げるつもりなの?

961 :デフォルトの名無しさん:2008/05/29(木) 12:17:51
メモリコントローラだろうな。

962 :デフォルトの名無しさん:2008/05/29(木) 13:07:39
…はぁ。
そのメモリコントローラはどこのバスにぶら下がってるの?

963 :デフォルトの名無しさん:2008/05/29(木) 13:12:57
脱線しすぎだゴルァ

>>941のネタをすこし弄ろうか。
メインメモリの速度の話ばかりしているが、
たとえL2キャッシュに100%ヒットしていても、
そんなに速度が出ないプログラムだぞ?

プリフェッチ有での結果のMB/secを ループ回数に換算すると
Coppermine 1GHz → 880MB/sec → 220M loops/sec → 4.55 clocks/loop
Northwood 2.4GHz → 2000MB/sec → 500M loops/sec → 4.80 clocks/loop
K7 Palomino 1.2GHz → 780MB/sec → 195M loops/sec → 6.15 clocks/loop

コンパイラが何か不明だが、Cのコード上での1ループでは、
・アドレスの加算 reg1 = p + x
・ロード reg2 = [reg1]
・レジスタへ加算 sum += reg2
・アドレスの加算 x++
・比較 x < count
・条件ジャンプ
これだけのことをやるわけで。
メモリ帯域をみているのかコアの性能を見ているのか、いまいち不明瞭。
メモリ帯域を見たいなら、SIMD命令でロード & オフセットを即値にしてループ展開 すべき。

ちなみに
1Pと2Pで合計のスループットがまったく同じCoppermine 1GHzは、ある意味すばらしいな。

964 :デフォルトの名無しさん:2008/05/29(木) 13:29:17
>>962
FSB以外にどこがあるよ?

シーケンシャルなアクセスのレイテンシは削減できないどころか、
キャッシュのために増えるかもしれない。

ランダムなアクセスのレイテンシは削減できるだろう。

965 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/29(木) 13:30:07
全ソースどっかにplz
うちの環境でも実験してみたい


#ASMスレの高速strlenの話題もこっちに引っ越したほうがよさそうな

966 :デフォルトの名無しさん:2008/05/29(木) 13:43:13
>>964
あー。>961のメモリコントローラってメインメモリの
メモリコントローラのことなのか。FSBの先の。紛らわしいなぁ。

で、IntelプロセッサのFSBってバースト前提のバスプロトコルだと思ったが、
その先にぶら下げて意味あるの?



967 :デフォルトの名無しさん:2008/05/29(木) 14:32:02
一昔前のオンボードキャッシュとの違いが分からん。

968 :デフォルトの名無しさん:2008/05/29(木) 14:37:40
>>967
そのものだろ。

オンボードキャッシュが廃れた理由を知らないのかもな。

969 :デフォルトの名無しさん:2008/05/29(木) 14:44:18
hpのmx2のような例もあるが、あれはFSB帯域幅が足りなくなるのを補うためのものだしな。

970 :デフォルトの名無しさん:2008/05/30(金) 00:06:43
>>965
短いのでスレに貼っちゃいます

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <xmmintrin.h>

int ReadTest(LPVOID pMem, int size) {

int* p = (int*)pMem ;
int count = size/sizeof(int) ;

int sum = 0 ;
int prefetchBytes = 512 ;
int countA = count - prefetchBytes/sizeof(int) ;

for (int x=0; x<countA;) {
_mm_prefetch((const char*)(&p[x + prefetchBytes/sizeof(int)]), _MM_HINT_NTA) ;
for (int y=0; y<32/sizeof(int); y++) {
sum += p[x] ;
x++ ;
}
}
for (; x<count; x++) {
sum += p[x] ;
}

return sum ;
}

971 :デフォルトの名無しさん:2008/05/30(金) 00:07:44
void test(void) {
int size = 1024*1024*256 ;

LPVOID pMem = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE) ;
if (pMem) {

printf("ReadTest pre. (sum=%d)\n", ReadTest(pMem, size)) ;

LARGE_INTEGER liPerfCountStart ;
QueryPerformanceCounter(&liPerfCountStart) ;

int sum = 0 ;
int testloop = 60 ; /* 適当に大きく*/
for (int j=0; j<testloop; j++) {
sum += ReadTest(pMem, size) ;
}

LARGE_INTEGER liPerfCountEnd ;
QueryPerformanceCounter(&liPerfCountEnd) ;

LARGE_INTEGER liPerfCountFreq ;
QueryPerformanceFrequency(&liPerfCountFreq) ;



972 :デフォルトの名無しさん:2008/05/30(金) 00:08:13
LONGLONG llSpan = liPerfCountEnd.QuadPart - liPerfCountStart.QuadPart ;
LONGLONG llSize = (LONGLONG)size * testloop ;

double speed = (double)llSize / ((double)llSpan/liPerfCountFreq.QuadPart) ;
int speedMB = speed/(1024*1024) ; /* 適宜1000*1000に変更*/

printf("ReadSpeed = %dMB/sec (sum=%d)\n", speedMB, sum) ;

VirtualFree(pMem, 0, MEM_RELEASE) ;
}
}

int main(int argc, char* argv[])
{
test() ;
return 0;
}

以上です

973 :デフォルトの名無しさん:2008/05/30(金) 00:13:38
あーすみません。

Windows用です。
windows.hはPlatformSDKあるいはWindowsSDK
xmmintrin.hおよび_mm_prefetchはVC固有だと思います。


974 :デフォルトの名無しさん:2008/05/30(金) 00:33:37
こりゃまた酷いプログラムだな。

975 :デフォルトの名無しさん:2008/05/30(金) 09:03:13
>>941から>>970への変更は中途半端だな。
SIMDを使ってやるべきだろう。

976 :ヽ・´∀`・,,)っ━━━━━━┓:2008/05/30(金) 21:27:47
さて、Intel謹製のAtomのMini-itxマザーが来週あたりから出るらしいのだが
これ試してみたいのだが

チップセットが旧世代でファンが付いてるとかなかなか本末転倒な代物だそうで。

977 :デフォルトの名無しさん:2008/05/30(金) 22:13:19
CPUとチップセットの写真を見てわらったよ。

たしかにCPUはダイが小さい。とても小さい。
それに比べて、チップセットのダイの巨大さ。

チップセットは、
古い製造設備やプロセスの再利用だろうが、
それにしたって、そりゃぁないでしょう、と。

CPUに全部統合するのは過去の失敗が多いから避けるとして、
せめてチップセットも小さくしてMCMしてくれよ、と。

978 :デフォルトの名無しさん:2008/05/30(金) 22:55:07
チップセットを統合するのは来年だから、今年は既存のやつでお茶を濁すってところだろ。
ULPC用に新規にチップセット開発する気がないだけかもしれないが。

979 :デフォルトの名無しさん:2008/05/30(金) 22:59:21
ULPC用には新規コンパニオンチップが用意されてるだろ。
ネットトップ向け(Diamondville)に用意されているのが945GC(やSiS761)なだけで。

980 :デフォルトの名無しさん:2008/05/30(金) 23:17:50
SMT面白そうだな。

アメリカの政府機関がインテルに発注して、
チップセット統合版にInfinibandを内蔵させてだな、
すんごい高密度のスパコン作ったら面白そうだ。

981 :980:2008/05/30(金) 23:18:25
いけね980踏んだので次スレ立ててくる

982 :デフォルトの名無しさん:2008/05/30(金) 23:20:19
次スレ

x86命令の所要クロック計測スレPart4
http://pc11.2ch.net/test/read.cgi/tech/1212157132/

983 :デフォルトの名無しさん:2008/05/30(金) 23:27:12
>>974
酷いプログラムでも高速なコードにコンパイルするのがコンパイラのお仕事だし、
それを高速に実行するのがプロセッサのお仕事でしょう。
だからといって酷いプログラムを書いていいってことにはならないけどさ。

俺様のためにバッチリ最適化されたコードでないと、ちっともやる気がでないっていう
困ったプロセッサもあるみたいですけどね、あれとか。

984 :デフォルトの名無しさん:2008/05/31(土) 06:46:26
>酷いプログラムでも高速なコードにコンパイルするのがコンパイラのお仕事だし
そうか?

985 :デフォルトの名無しさん:2008/05/31(土) 06:53:17
強引に最適化してくれるオプション付ければそうするのがお仕事ではある
が、セマンティクス変えてまで最適化するのは普通はやめていただきたい挙動

986 :デフォルトの名無しさん:2008/05/31(土) 08:52:24
インテルのコンパイラは勝手にSIMD演算してくれちゃったりするぞ。

987 :デフォルトの名無しさん:2008/05/31(土) 10:35:46
それでSSEオンよりオフのほうが速いプログラムができたんですね。わかります。

988 :デフォルトの名無しさん:2008/05/31(土) 14:37:30
>>985
コンパイラの最適化は普通セマンティクス保存しないぞ。



989 :デフォルトの名無しさん:2008/05/31(土) 16:40:07
>>988
結果的には保存されるだろ
つかされないと困る

990 :デフォルトの名無しさん:2008/05/31(土) 16:57:13
セマンティクスをどういう意味で使っているのか気になる。

991 :デフォルトの名無しさん:2008/05/31(土) 18:09:49
「意味ワカンネーっすよ」っていうときの「意味」かも

992 :デフォルトの名無しさん:2008/05/31(土) 18:32:52
>酷いプログラムでも高速なコードにコンパイルするのがコンパイラのお仕事だし
これをよんで違和感を感じないやつはおかしいだろう。

コンパイラの仕事はコンパイルであって最適化ではない。
オプティマイザによる最適化はオマケみたいなものである。
速度を重視しない場合ももある。
ひどいプログラムはコンパイラどうこう以前にひどい。

993 :デフォルトの名無しさん:2008/05/31(土) 18:39:54
>>985
判る判る

for(i=0;i<8*1024*1024;i++){ ; } // 少し待つ

の行が最適化で削除されるとセマンティクスが変わっちまうよな。

このケースはコードの方がカスだと思うけど。

994 :デフォルトの名無しさん:2008/05/31(土) 18:43:51
A = 10 + 2 * 2;
で律儀に加算乗算されても困るし、
A = C * 10;
を A = (C<<1) + (C<<3); にされても困らないよね。


995 :デフォルトの名無しさん:2008/05/31(土) 18:45:18
>>992
> コンパイラの仕事はコンパイルであって最適化ではない。
> オプティマイザによる最適化はオマケみたいなものである。

コンパイラとオプティマイザを厳密に分ける意味ってあるの?

996 :デフォルトの名無しさん:2008/05/31(土) 18:47:56
>>993
でも、コーディングする時はコンパイラの最適化を意識しないとダメだよね

volatile int i;
for(i=0;i<8*1024*1024;i++){ ; } // 少し待つ

997 :デフォルトの名無しさん:2008/05/31(土) 18:57:52
volatile最強杉

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

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

1000 :デフォルトの名無しさん:2008/05/31(土) 22:45:21
1000get!

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

298 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)