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

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

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

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

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

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

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

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

　　　　　　　　　　ヽ　/ /⌒＼
　　　　　　　　 ／ヽヽ|/⌒＼ii|＼
　　　　　　　／ ／ヾゞ//／＼＼|
　　　　　　　|／　　 |;;;;;;|/ハ　＼|
　　　　　　　　 　 　 |;;;;/／⌒ヽ
　　　　　　　　 　 　 |;/（　＾ω＾） >>1おっおっおっ乙枯ー
.　　　　　　　　　　　|｛　∪　　∪
　　　　　　　　 　 　 |;;ヾ.,____,ノ
　　　　　　　　 　 　 |;;; |
　　　　　　　　 　 　 |;;;;;|
　　　　　　　　 　 　 |;;;;;|

>>1
STARGA乙ERS

前スレ埋まりました。

GJ!

2ch閉鎖したらどーすんの？

大原が入稿してからついに一週間経つのにまだ掲載されてないなんて
サボりすぎってレベルじゃねーぞ

珍しいなム板で500KB制限って

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

第189回 Core MicroArchitectureをもうすこし(13)
http://journal.mycom.co.jp/column/sopinion/189/

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

このスレとは関係ないけど

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

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

サーバーを意識した設計だがRASは無い

俺は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と遅いので計測からはよくわからなかった）

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でも同じじゃないかな。

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

IA32 x86 JITアセンブラ Xbyak
http://homepage1.nifty.com/herumi/soft/xbyak.html

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

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

計算式や正規表現のようなユーザから来る可変な表現からプログラムを生成。

Cの関数のような表記のアセンブラといえば、CELLのもそうじゃなかったっけ?
#つーか、あれは関数表記のインラインアセンブラなのかも知らんが。

そりゃIntrinsicsじゃないのか？
ttp://en.wikipedia.org/wiki/Intrinsic_function

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

あれはもともとIntelコンパイラの組み込み関数

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

>>16
正規表現か。難しそうだな。
結局、定数書き換え以上のことやろうとすると、コンパイラみたいなのを
自作してプログラムに入れないといけないんだよな。

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

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

>20
callが並べられれば既に最適化されている一連の関数をどういった順序で、ないし、どういったパラメータで呼ぶかが決められる。
比較処理の削減、BTBの節約程度にしかならんがな。

正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ
（言語処理系だとHaskellとかに使われてるね）

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

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

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

第190回 Core MicroArchitectureをもうすこし
http://journal.mycom.co.jp/column/sopinion/190/

> そうなると、そうすると

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

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

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

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

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

俺くどいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

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だとｘ2で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の差があるので、
あたらずも遠からずかな。

つづき

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

大原なんてどうでも良い
もちっと突っ込んだ話に進めよう

「モノ書くってレベルじゃねーぞ」

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

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

その上整数パイプラインとFP/SIMDパイプラインに分かれてる。

その代わりK8はスレッド数が増えても急激な性能の低下はないね。
Core2はコア数×2スレッド以上になると急に遅くなる。

ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、
具体的にどれくらい?

単純に1スレッドだけだと2MB〜4MBのキャッシュを占有できるからじゃないの？

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

Intelの共有キャッシュ = 再構成可能キャッシュ

そうだね。
黙っててもマルチコア化は進んでいくわけだから、シングルスレッド強化のほうが、むしろ理にかなってるとも言える。
また、1コア当たりのトランジスタ数を抑える方が、コアを増やす上で、これまた理にかなっているだろう。

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

何言ってんの？K8といえば今やX2だろう。

>>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の戦いは楽しみだ。

K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを
K8Lではディスパッチ後にデコードするようになってる。
このへんってどんな効果あるんだろ

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

そそ、Intel processorが特別ピーキーで(絶妙な)設計なだよなー（・∀・）
AMDに限らず、RISC processorでも馬鹿正直といったら失礼だけど、大雑把なつくりのがおおいし。

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

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

Intelerお久

どこが優っていて、どこが劣っているとか、
それは最終的には関係なく、結果叩きだされる性能が指標なわけで…

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

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

読んだ。
AMDのCPUは実行IPC3で常に回っていて(脳内or観測的希望)
intelのCPUはIPC4を謳ってい入るがそんなわけねーよ(AMD比)pgr、ということなのか…

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

おはようございます。
なんだよ、観測的希望ってw
やっぱり眠い時レスしちゃダメなんですね。
大原氏ごめんね。

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

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

CPUの性能を調べることと素性を調べることの差って感じか

周波数特性だけで盲目的に音質を語るな

>>47
そうだね。
あと、ベンチって結果から製品を選ぶのが目的と見せかけて
むしろ好奇心を満たすものという面が大きい。
性能より素性を知りたい人が少ないってのが寂しい。

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

マルチコアはいつから使えるコアになるのか？
http://www.ne.jp/asahi/comp/tarusan/main155.htm

>>50
実際にどっちを買うべきかという話ではなくて、CPUメーカーがシングルコア路線を続けた方が
動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話だね。

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

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

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

>CPUメーカーがシングルコア路線を続けた方が動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話

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

>>52
AdaptabilityやDMTの意味がわからないが、
前提となるコストと熱設計の中で最も性能の高いものを作るだけじゃないの？
開発期間の隙間と言っても、開発が済んだらコアを減らすわけでもないだろうし。

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

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

SpMTが高めるのはMLPだ。
"ILPの壁を突き破る"という表現はおかしい。

ILPという言葉に関しては、一つのスレッドに対して使う言葉なのかな。
並列性の高まるスレッドが別であることに対しては無効であるなら認識不足だった。
勉強になります。

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

>>56
> Speculative MultiThreadingによってILPの壁を突き破れるようになる
の「ILPの壁」というのは、「シングルスレッド処理のIPC向上の壁」と言えばいいんじゃない？
ILPと言うと、メモリ以外の命令同士の依存関係を何とかするみたいな感じを受けるから。
＃メモリアクセスもI（命令）だと言われればそうだけど。

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

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

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

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

AMD Rev.F Processor には、RDTSCPという命令が追加されているらしいな
ttp://www.atmarkit.co.jp/flinux/rensai/watch2006/watch07a.html

>>27
http://journal.mycom.co.jp/articles/2005/07/14/yonah/002.html

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

大腹自身の記事かよｗ

>>59
それは読んだよ。

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

たとえば、X2の512KBと、１MB版は
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トランジスタで作っているか、公式発表の数字がうそか、どちらかだろう。

Pentium Mは4トランジスタじゃなかったっけ

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

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

まあ大原もここのスレ住人も、ほとんどが確たるウラをとらずに好き
放題発言しているだけだけどな。５０歩１００歩じゃねーか？

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

PenMが4トランジスタSRAMってのは間違い。
大原自身が訂正してたよ。
6トランジスタです。

そろそろclock計測の話題に戻ろうよ。
ここは実験と実証のスレで、理屈と情報、妄想だけのスレなんて他所にたくさんあるわけだし。

素人が個人ブログや掲示板に自己満足記事投稿するのと
企業から金貰って大衆に読んで貰うための記事をかくのと
全然影響力・説得力が違うがね。

クロック数計測してもTr数はわからんし。

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

>>66
大企業メディアの情報の質、正確性、量、速度が
個人サイトの集合を上回っているとはいえなくなりつつある
ネット社会の現代、こういうライター稼業のなんてもう流行らないのかも。

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

この計算はあってるの？

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.

第191回 Core MicroArchitectureをもうすこし(15)
http://journal.mycom.co.jp/column/sopinion/191/

>>70
なんかどうみても、これスレを読んでいて、且つこのスレに対して
言い訳してるようにしか読めないな。

大原氏には悪いけど。

>>70
話の持っていきかたの無理矢理感が・・・・・

どんな下手な書き方してもIPC=3を出せるハードという意味なら永久に無理に決まってる。
ソフト側も「IPC=3を出せるコード」であることが前提。

そこでEPIC

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を引き上げるためのその辺の機構を正当に見てない希ガス。

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

キャッシュラインサイズが256Bというのもその辺考えてるのかもな。

>>76
キャッシュラインサイズが256Bって何？

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

今回のは何を言いたいのかさっぱい伝わってこないのだが…
これなら昔の電波の方がよっぽど読み応えがあったｗ

http://pc.watch.impress.co.jp/docs/2007/0131/ubiq170.htm
これらのプロセッサでは、Coreマイクロアーキテクチャとしては初めて
Hyper-Threading Technology(HTテクノロジ)をサポートすることになる

Penryn does not have HT
http://www.theinquirer.net/default.aspx?article=37316

http://grape.astron.s.u-tokyo.ac.jp/~makino/journal/journal-2007-01.html#30
むーん、オールジャパンってそういう話か、というか、それはそうなん だけど、そんなので計算機作れるのかよ、、、

Vista 64bit版も出た事だし、そろそろx86-64の話題が欲しいですね。
スレ違いか？

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のクロックが非常に良いのを見ても
そんなに驚かないだろう。

第192回 Core MicroArchitectureをもうすこし(16)
http://journal.mycom.co.jp/column/sopinion/192/

　　ま　た　2　ち　ゃ　ん　ソ　ー　ス　か

> Penrynの世代でHyper-Threadingが搭載されるという。

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

今回のこれは大原を弄るのは酷かもな…
ネタの正確性はともかく言ってること自体は間違ってないというか、同意できる
つーかYorkfieldの中身が変更されたと判明した後もガセネタ流し続けたCharlie Demerjianは死ねｗ

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

生ハムメロンワロスｗ

つーか、なんか論点がずれてるというか、大雑把な主張になってきたな。
もともとIPC=3を技術的に細かく検証しているはずだった気がするが、
いつのまにか
「発熱や消費電力が上がる関係でIPC=3は無理です」
になってる。

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

このシリーズはいつまで続くんじゃー！

Core2がIPC=4じゃないとする主張の理由の中に
K8がIPC=3であると思わせる部分がある時点で
大原記事wwwとなるのは明白。

元々はCoreMAとK8のIPC向上に対するアプローチの違いを言いたかったような気がするが。
細かく突っ込んでいって逆に全体像が見えなくなった感じだな。

>>89
Meromと果物のmelonをかけてるのだろうか？

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

Windows生ハム

AMDの方は L3キャッシュだろ。もうどうなる事やら。

トランジスタ増やしすぎたらいくら微細化してるとしても
クロック上げるのも難しいと思うのですよねぇ

そういえばK8LのL3は面積からしてZ-RAMじゃないな
大原妄想乙でした

初代スレの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の話じゃないですよ。

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

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

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

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

動かしてみるに吝かではないのだけれど、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

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 

Opteron144(Venus)だけど>>100と同じ結果

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

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

みなさんありがとう。
小さい数の割り算だと速くなるのは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の測定お願いします。

YonahとBaniasの計測がほしいね。それで完璧。

GCCなら-masm=intelオプションでほぼそのまんま移植できた希ガス

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

>>112
マジで！！！？？

今までの計測結果を見ると、
Banias->Dothanで大きな除算の改良が入ったように見える。
除数によって大きくlatencyが変化しているのはConroeのみなので、
もしかすると、Yonahから除数側の改良が入ったのかも知れず。
Yonahの計測結果ﾏﾀﾞｰ??

いや、除数側の改良もDothanからか。
Yonahでの発表は厳密にはウソってことでFA?

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

>>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によっては微妙かもしれないと不安になってきた。
もう少しいい処理・わかりやすいループのアイデアある？
まず、ループをアンロールというのはやろうと思う。

>>115
いや、Yonahの発表からすると、Yonahの時点でCore2の速さだったんじゃない？
どうも新しいCPUはレイテンシが微増する傾向があるみたいなので、
Yonah（PenMと同じ世代）がCore2（新しい）より速いということも考えられる。
>>108を見ると、PenMを改良したものからピッタリ2clk遅くなっている感じだ。

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

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

>>109
> あれ！？ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。

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

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

>>120
なるほど！数字としては今までと同じで、精度がコアの倍率分だけ悪くなっているのか。
2コアで同じ時計を持てるのは嬉しいが、やはりクロック単位の測定にはちょっと痛いな。

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

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

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

更新されてたの気づかなかった
同じ環境

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

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

ソース読んだ
FamilyとStepping逆じゃね？

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

>>126 この結果ってCPUのクロック倍率が落ちた状態じゃないかな？
EISTやC1Eで自動的にクロック倍率が落ちるので、
FSB同期のrdtscでクロック数を計測するのはいろいろと面倒かも。

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

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

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

>>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にしては少ない感じがする。
ある程度のタイミングで補正はしてくるのか？

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

>>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
マジでどっちが正しいのかわからない。

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

>>133
順当な結果ですね。

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


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

YorkfieldでHTが有効ってことになると、Nehalemがトレースキャッシュ型
アーキテクチャであるという仮説の有力性は揺らぐね。
トレースキャッシュはHTの必須条件だと思ってたが違うってことになるわけだし。

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

SMTの実装にトレースキャッシュが必須ってこたないでしょ。
Power5なんかはx86と比べるとデコーダ負荷が低いとはいえ、普通のキャッシュのままSMTやってるし。

>>135
命令の切り出しの方がネックじゃなかったっけ？

>>134
多分 HTT有効だと一部のアプリの性能が低下する ってのと同じ問題が起きるよなあ
厳密には IDAがあるのに上手く活かされずシングルスレッド性能が向上しない だけど

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

>>138
HLTをユーザモードに解放するメリットは何?
計測目的ならDOSとかRING0で計測すればいいだけだし、
OSスケジューラの都合ならHLTでコアを止めるよりもsleepしてOSに任せたほうがいいし。

ttp://journal.mycom.co.jp/column/sopinion/193/

PentiumってOutOfOrderだったっけ？

P5はインオーダー

http://pc.watch.impress.co.jp/docs/2005/1130/kaigai228.htm
>P5では、5ステージのパイプラインで、最大2命令を並列実行していた。
>次のP6では、最大3個のx86命令をuOPsに変換し、アウトオブオーダ実行。
P5でスーパースカラを初実装。
P6でアウトオブオーダを初実装。
だな。

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

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

in-order発行のtypoだと信じておこうｗ

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

out-of-order終了ｗ
カチャカチャな動作をする予想ｗ

>鼎の軽重
怪電波を飛ばすのが生業のような方々にそんな物問いませんからｗｗｗ

連載ｵﾜﾀよ

第194回 Core MicroArchitectureをもうすこし(18)
http://journal.mycom.co.jp/column/sopinion/194/

長かったな…

↓次のネタ大胆予想

「Core Microarchitectureをさらにもう少し」



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


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

>>149
今回のことで懲りたので、たぶん非PCの話題とか、誰にも突っ込まれ
ない（というか誰も興味ない）話題でお茶を濁すと見た。

> Pentium Proの世代は、命令の発行とその実行まではOut-of-Orderながら、
> 命令の完了(実行結果の書き戻し)はIn-Orderという構成で、
> これが完全にOut-of-OrderになるのはNetBurst Architecture(や、
> P6をベースにアーキテクチャを作り直したBanias Architecture)からになるのだが、

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

ハイパースレッディングは考え様によってはOut-of-Order完了だな

Out-Of-Order完了ｗｗｗ

>>153
NetBurstはそれでもいいけど、Baniasは違うよなあ

もうなんか大原って中途半端な知識で言い切るんだよね。だから色々
突っ込まれる。IPC=3だって、「他の可能性もあるが俺はこう思う」と
最初から言えばそこまで突っ込まれないのに、言い切ってしまう。
で、後から「実は他の可能性もあるし、俺はそれも知っていた」と言い訳
するんだよなｗ

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

初心に戻ろうと思い、裸になって学校へ行こうと電車に乗ったら捕まりました。

>>156
それがライターの仕事
後藤や本田や(中略)安藤だって(以下略
ブログとセカンドオピニオンで補足するだけマシじゃね

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完了だし。

>>158
それでも後藤と大原じゃ、大きく違うがな。

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

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

まぁ、でもネタを提供してくれる分にはとてもありがたく思ってるよ。

>> 162
それ大原のこのスレに対する台詞でしょ??

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

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

みっなおそう、みなおそう、CPUを見直そう
Core2Duo機に買い替えろ
みっつもりっだみつもりだ

4gamerの第5回目以降の下書きメモ帳代わりにmycomを利用した大原たん

さっさと4亀連載の続き書けや(ﾟﾛﾟ)ﾓﾙｧ!!・・・・・書いてくださいお願いしますm(_ _)m

4gamerの記事は比較的よくできているね。
あれでゲームはやってもCPUに詳しくなかった層が入るのにはちょうどよいだろう。

【ネガティブ派遣根性チェック】

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

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

セカンド・オピニオン、新シリーズ来ました。
第195回 OS小論:OSの構造をもう少し考えてみる(1)
http://journal.mycom.co.jp/column/sopinion/195/

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

「もうすこし」ではないから安心しろ。

>誰を恨むわけにもいかないんですが
このスレの住人恨む気満々だなwww
ここの住人はサイレントマジョリティーではないはずだが、考慮されている様子。

大原先生ごめんなさいｗ

全部>>173が悪いんです！！

ぬこ成分だけで全て許してしまえる

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

iいろんな意味で役に立ってるから今度ファンレター送るね。
つかHansと知り合いつのが改めて驚き。

Barcelona Architecture: AMD on the Counterattack
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939&p=4

Hammer-Infoで紹介されていたリンクをﾒﾓ

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

生活支援てw

> 他所様の出版社から出ている内容をここで引用するわけにもいきませんので

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

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

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

そこは絶望しないと

これか

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

>Intelは80386以降で、4レベルのProtection Ringという概念を導入した(Photo01)。
80286以降だろ。大丈夫か？

相変わらずツッコミきっつー

VAX/VMS が仮想記憶をインプリメントした初めてのOSだとか [1]、
4 level ring が VAX 由来だとか [2]、ほかにも色々間違っとるぞ。

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

80386の仮想記憶ってほとんどMULTICSそのままだよな。

80386は仮想記憶やページングのアーキテクチャだけは割と新しいからな

>>188
話の流れを分かってない。
MULTICS由来ってのは286から導入されたセグメンテーション機構の話。

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

流れ断ち切るようでスマソ。質問。

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

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

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

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

>>190
まずは実測してくれまいか？

スタックの先頭は通常キャッシュにのってるから速いが
沢山スタックを消費すると追いやられる
そのことを言ってるんだと思う

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

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

スタックを大量に使うこと自体はそんなに問題じゃないと思う
push. pop大量にするわけじゃあるまいし。

>>192
ヒープに載っけても結局同じだけメモリ食うんだがｗ

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

call by value -> call by reference

ここは計測スレなのに最近自作○C板のCPUスレと同種の話ばっかりじゃない?
自作○C板は自作○C板で同種のスレがたくさんある。もっと独自路線を出してほしい。
つか、どこでも読める理論話のぼり返しはほどほどにしてひたすら計測しろよと。

しかしAgner氏の計測を覆すような発見もそうそう無いんだよな

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

マジでダンゴ来た・・・もうオワリだ・・・

最初からいるだろ
x86じゃないけどCellのスループット計測結果なら出せるよ

早く貼れ

いや、やっぱり貼るな
CELLネタは荒れる

>>1が許可したら貼る。
てかCellスレあるし

トリップ外すな、ハゲ。

○◎●であぼーんは基本だろ？

http://homepage1.nifty.com/herumi/diary/0703.html#6

いつもの
http://journal.mycom.co.jp/column/sopinion/197/

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

>>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の機嫌が悪かっただけと予想。
内部構造が変わったかどうかはわからないが、レイテンシが増えたのは確実だ。

コンパイラの出力を見て初めて知ったこと。
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
とりあえずここに、手元にあった分だけ固めてアップしておく。
あとでちゃんと整形して上げます。

スループットなら倍精度以外はほとんど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(推定値)というぐらいだから精度は絶望的に低いと
思ってくださいな。
それなりに精度の高い除算をやろうと思えばソフトでやるしかない。
平方根も同じく。

LS間の「ピーク帯域」に関しては、ロード・ストアはoddパイプで処理されるから
1クロックに1命令。

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


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

てか、IBMの図におもっきし51.2GBって書いてあるじゃんｗｗ

レジスタが128本だから1レジスタ指定に7ビット。
4オペランド命令で28ビットも使ってるからOpcodeは4ビット。
（上1ビットはopcodeサイズの区別に使うから実質3ビット）

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

80286の間違いは訂正なしか。だめだなこりゃ。

精度の高い除算のやり方はは3DNow/SSEと同じ。
doubleも命令の組み合わせで一通り出来るけどスループットとレイテンシを考えると…。

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

なんつーか、普通のプロセッサ用に書いたコードがことごとく使えない
エントリポイントのmain型さえ置き換えればどうにかなると思ってたら
1から書き直しなんだよね。

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

spe_printf()は遅い悪寒。
#って、スレ違いだがね。

ネタがないな

暇ならXLATの所要クロックについて語ってくれ。
とか適当な事を言ってみる。

x86_64命令の所要クロック計測まだー

同じじゃねーかｗｗｗｗ（NetBurst以外

>>209
レスが遅れてすまん。
まあ、大体素直な感じだな。

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

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

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


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

帯域がもう少し広ければトレースキャッシュくらいに使えるんじゃないかなと思ったり。

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

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

スレ違いだし今更気づくような内容でもないだろう。
本当にAltiVec使った事あるのか？
手順が若干簡略化されてるだけでAltiVecもやるべき事は同じじゃないか。

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


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

>>221
> x86にLSを載せたらどうだろう
レジスタ同様にタスクスイッチ時にデータを退避するのか？
それともロックして占有するのか?

>>226
仮にやるとしたら、ロックするのがいいかな。
オーバーレイなんかも同時に2アプリで使えないことだし、
エンコやゲーム専用と考えれば。

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

L1キャッシュよりレイテンシの大きいローカルストアよりも
拡張XMMレジスタファイル256本のほうがまだありがたいような。
imm8を使って各レジスタを指定。

スケジューラが詰まらないならその方がありがたいです。
レイテンシ分くらい依存命令を離しているつもりなのにストールすると悔しい。

リアルモードの割り込みベクタのことIDTなんていう呼び方してたっけ？

Interrupt Descriptor Table

そのまんまの意味だな

いや、だからリアルモードの割り込みベクタテーブルとプロテクトモードのIDTはちょっと違うもんだろ、って話じゃ？

英語が理解できないのはつらそうだな。

どうして団子リオンはトリップつけてないのか。

>>230
intelの文書ではリアルモードの割り込みベクタテーブルを実アドレスモードIDTとよんでいる

>>234
漏れてるから

ありゃ、お漏らししちゃってたのか。

Intel Penryn and Nehalem 45nm Processor Update
http://www.legitreviews.com/article/480/3/
The New Technologies and Features

Super Shuffle Engine キター

Emulatorの友

> Super Shuffle Engine

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

>>240
団子ちゃん、こっちのスレでお呼びがかかってるよ。
http://pc11.2ch.net/test/read.cgi/tech/1137540671/

>>235
どの文書？

スレ違いならごめん。

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

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

>>243
コードの差は出るかもしれないし出ないかもしれない。
その周辺のコードによっても変わるし、勿論コンパイラによっても変わる。

別スレ逝った方がいいよ。
「うちの使ってるコンパイラで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));

>>243
速度を気にするなら条件分岐を排除
同確率の二択はほぼどちらかが失敗する

どうも有難うございました。

まぁ、そんな細かいことが気になるならc++で
min = std::min(a, b);
max = std::max(a, b);
とでもすればいいだろうよ。

細かいことが気になるならmin/max関数なんて使わない

なるほど、団子には皮肉が通じないわけだ。

つーかそれ、素で間違ったのに皮肉と言い訳してるのと見分けが
つかないから、皮肉なら皮肉でちゃんと分かるようにしないとｗ

明らかに皮肉とわかるのに
団子がいるスレは一段と引き締まるな

>>248みたいなことを言う馬鹿や初心者は結構いるぞ。
つまりそういう人間と君みたいな天才は区別が付かないんだよｗ
せっかく天才なんだから周りに勘違いされないようにした方が
幸せだと思っただけさ。気に障ったら許してくれｗ

( ﾟдﾟ)ノ ﾄﾞｿﾞー
http://pc11.2ch.net/test/read.cgi/tech/1084676298/411

どうもごめんなさいでした。

>>253
基本的に同意
でも多分std::maxとかって書いておけば最適な命令に置き換えてくれると勘違いしてる
初心者なんじゃないだろうか。
皮肉だ皮肉だとと必死に自己弁護してることからも明らか

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

　　　　　　　　　　　　半　　端　　な　　知　　識　　　　　　　　

皮肉だ皮肉だと自己弁護してるのが特にそうだね

いくら初心者でもmin,maxが最適な命令に置き換わるなんて発想はありえない。
ちょっとひねくれすぎ。

団子が昔そうだったとか？

ダンゴの言うことはホント正しいよね
歯向かうのは馬鹿

どう考えてもmin,maxが最適な命令に置き換わるなんてありえないな。
誰に吹き込まれたか知らないが、勝手な妄想はよしたほうがいい。

>>243がかかるクロック数を短くしたいという目的があって質問したのは
明らかなわけだが

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


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


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

言葉遣いや性格には問題ありだが。。。

>>262
組み込み関数として最適化ができるアーキテクチャ・処理系はあるよ。
x86では、知る限りでは無いけど（マクロ版ならまだ最適化される余地あるかも）

>>264
まず団子が正しいことを認めろよ。
言い訳がましい。

>>262
あるだろう

ここで真相を明かしますよ。今日の日付けを考えてみろ、と。

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

>>268を翻訳

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

条件付movとか、フラグ→マスクみたいな一般的な方法ではなく
SSE2が最初に出てくるようなミーハーイッテル馬鹿は初心者を笑えないだろ…

>>270
見苦しい。

>>271
団子よ、IDが出ないからといって見苦しい自演するな。

無意味な喧嘩すんなよ。
匿名掲示板上で自分のアイデンティティ探ししてると、
（自作板に２名ほどいるけど）本物の精神疾患になるぞ。

おまえ自作板見てないだろ？

>>243-275
スレ違い

Ｏ原ネタ振れよｗｗ

>>272
アホすｗｗｗ

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

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

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

この粘着力は酉付いてなくても真性だとわかる

MACヲタもそうだが酉なしで粘着する奴はもう一線越えてるからな

無能よかまし
無能は情報として価値が無い

>>270が言ってるのはset命令だろ。
そこでSSEとかCMOVとか言ってる時点で話が見えてない。

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

無能は価値がないけど嘘吐きは有害

>>280
>>282
なんかヤなことでもあったのか？

>>281の脳内では「条件付きMOV」と「CMOV」は別モノらしい

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

>>282
だよね。SSEしか要求しないのに生成コードすら読まずに
SSE2だなんていう嘘つきは要らない子だね。

今日付いたレスは全部嘘

インライン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が必要」ってのはどーみても綿貫ネタだよね。

>>284
SETcc r/m8

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

このグラフの目盛は13クロック前後かな?
http://pc.watch.impress.co.jp/docs/2007/0329/intel_8.jpg

相当な粘着だな

うちの団子が粘着でごめんなさいm(＿)m

粘りけのない団子なんて食えたもんじゃない

と背景雑音どもが申しております

　 　　_, ._
　 （　ﾟ Дﾟ）
　　( つ旦O
　　と＿)_)

SET命令やビット命令を最後に使ったのは何時だったか

つまらん事で荒れたのを久々に見たなぁ・・・

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

スレ違いな質問にも答えずにはいられないのが教えたがり君クオリティ

おまえらがつまらんことやってるからWolfdaleのESベンチの結果が違うスレに貼られたじゃないか

速ｗ
http://pc11.2ch.net/test/read.cgi/mac/1159817811/608

>>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いっぺんにやるから速いということかね。

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

>>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きつくなりそう…

>>302
基数が16ってのは16進法で筆算するような感じなのかな。
クロック数の変動から、256進法と思っていたが、単に商を8bitで区切って
その区切りごとに演算を早目に終わるという感じか。

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

つまりは４ビット単位の部分商を一気に計算してるんだろ

>>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)レベルに最低限必要な電圧にまで下げる。

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

自習で暇だったからランダムなfloat値1億個の入った配列を読み出して
最大値と最小値を求めるプログラム書いて時間潰してた。

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

こいつは半端に知識ある癖してどこまで理解出来てるのかさっぱりだな。
CMOVは速いんじゃなくて最悪の状態でも遅くなりにくいんだぞ。
原理くらい知ってるだろうに。

うん、それで？

>>307
稚拙な煽りだな。

落ち着け。つくづく痛い子だな。
306は内容が無いだろ。チラシの裏にでも書くんでなければせめて分り切った事でも考察入れろと。

こんなもんで
せろり2GHz

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

80/32(bit)より遅いね。
doubleの場合と分岐を使う場合はどうだろう。

>>190のを試すのと、fsqrtとfdivのレイテンシ測定をやりたいんだが、
何かやる気出ないなあ・・・。

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

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

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

命令フェッチ帯域が狭いからそれを拡充しないことにはね（Penrynでは改良してくるはず）

>>305
え、コア保持しないん！？

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

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

ちなみにCで書いてコンパイルしただけ。（SSEだけIntrinsicsを利用）
っていうかISAがスタックベースだからどうしても命令が多くなるのでしょう
一方SSEだとこんだけ。

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


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

ソース希望。

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

ループの内側はこんだけ。

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

お、THX!

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

どうでもいいけど_mm_min*だな

折角だから実測してみた。
>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遅過ぎ。

わかりにくいから数字だけ書き直しとこ。

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 ってか?

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でもそこそこ速い？

VTune9キター
ところでこのスレで使ってる人います・・？

団子先生なら買う！！！

VTune使いこなせてない漏れもいますよ。

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

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

確か予測分岐はランダムな入力に対して学習しない、つまり予測を変えないから1/2の確率で的中するんだよな。
対してcmovは予測が無いから投棄が無い代わりに速くならない。

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

あと予測をことごとく裏切る、つまり短いスパンで規則性のある入力に対してはcmovが有効だろう。
cmovは分岐テーブルも汚さないだろうから、ベンチマークではなく実際のプログラムではこれも効いてくるかも知れない。

そーいや、最大最小の問題は回数重ねると分岐パターンが収束してくわな。
NetBurstで32bit整数だと完全に汎用ALU＞SIMDだね。
PMAXSD/PMAXUDまだ使えないから余計に不利。

CellのSPEの分岐ヒント命令っていいね
ある程度のコードの長さがあって分岐の十数クロック前に
ヒントを与えていれば、ミスを完全に防げる。

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

沖縄県の方へ（命に関わる注意事項です）

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

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

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

民主党といえば、民主党の公認候補が毎日のように22時過ぎまで駅前で名前を連呼しているんだが
あれは問題ないんだろうか。

>332
通勤路では公明党と共産党がやってた。
調べたわけじゃないけど、拡声器を使わなければいいんじゃないかな。

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

スレ違いだろうが
アレだ、香港・澳門が厨国に返還されて、東アジアにおける資本主義諸国と共産主義大国間の
物流の橋渡しをする地域が無くなってしまった（台湾-厨国間の貿易拠点もなくなってしまった）。

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

負け癖は抜けませんがみんすです

仮に開放するにしても、下手なやり方だと日本にはいいことなさそうだな。

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の改善はないと考えていいのだろうか？

>>337
64bitCPUなのに64bit加算が苦手なのか？
add reg64,reg64 は、さすがにレイテンシ1でできると思うけど、
内部的には32bit*2段パイプで実現しているのかもね。

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

http://www.watch.impress.co.jp/akiba/hotline/20070421/image/ssc24.html

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

movapsにもレイテンシ2クロックかかんのかよ

> 64bitCPUなのに64bit加算が苦手なのか？
AMD64の仕様自体が64bit苦手仕様だろw

しょぼｗ

コアが増えるなら別にいいんじゃね。

ダンゴさんが書き込むとスレが引き締まるな

L2レイテンシ9だって？

なんかブロック図が想像してたのと違う。

Core−SRQ,XBar−HT,MC
　　　　　　　|
　　　　　　L3

と思ってたのに

Core−L3−SRQ,XBar−HT,MC

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

>>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
こっちで大原もちゃんと言ってた…。

適当なスレがないのでスレ違いを覚悟で質問します。
AMD64のアドレッシングモードのうち、レジスタオフセットに変位が付く形
はIA32と同じ32ビットまでしかできません。

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

例えば分かりやすい例を挙げてみます。

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

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

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

MOV RCX,[RAX+imm64]みたいな命令がほしいってこと？
本当にいると思う？

>>351
そうそうそんな奴があればいいなと思ってました。
まあ無くてもコンパイラが>>350みたいなコードに展開してくれるし
レジスタは多めなので問題はないと思うのですが、あってもいいような
気がします。

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

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

とくにAMD64やEM64Tは広大なメモリ領域を自由にアクセスできるように
なるわけじゃないですか。

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

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

>スタック領域に2GB超
エエエエ ゜Д゜

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

個人的にはイミディエイト値の扱いなんて POWER 並みで十分だと思う。
アセンブラは読みにくくなるけど。

http://pc.watch.impress.co.jp/docs/2007/0509/tawada103.htm
以前の予想通り200MHzのアップだったな。IDA。
現実的な線だった。

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

ユーザーが操作してない間は自由に動いてて構わないと思うけど。
ノートとかはプロフィールで軽くしてるだろうし、
ユーザーから見える情報が増えて心配の種が増えているだけでは。

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

やっぱりIDAショボーンだった…
kernel 2.6.25あたりで対応きぼんぬ

地雷の965でしか動かさせないとなると怖いなぁ・・・

>>347
(Core0-3 + L3)が独立小島でDRAMアクセスを含めた外の領域はL3を通して接続って形に見えるね。
スケーラビリティーを考えると妥当なやりかたにも思える。
コア領域とノースブリッジ領域の分離を明確にしたというか。

>>361
しかしクロックや電圧供給ってCore0-3とL3+NBで分かれてたと思うんだけどねえ。
L3の位置もコアに挟まれてるんじゃなくてダイの端だし、一番遠いコアだとアクセス効率悪すぎる気もするのだが。

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や∞だったなんて事は
ある事だと思います。

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

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

>>365
さすがOpteronはx87で非数、∞を使っても遅くならないですね。

よく見るとOpteronは正規化数 + 非正規化数 = 正規化数でも遅くならないんですね。

>>363
「現在、大変混み合っております。」ぐみゅう。

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

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

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

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

>>370
AthlonXP3200+だとSSE2はないけどx87とSSEはほぼ同じ結果。

>>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をかけ続けても全然オーバーフローしないのね。

ちょっと泣ける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 : +∞ * +∞ = +∞

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

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

http://pc11.2ch.net/test/read.cgi/jisaku/1179911252/
上記スレで強制NaNの計算でインテル不利にするベンチが論争を呼んでますが
しかえしに極端にAMD不利にする方法を探しています。
では。

使われないx87が遅くても欠点ではないと思うけど、
SSEには無い命令などで、今でもx87は軽視できない、とな？

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

くそ、お前らのせいでMMX Pentiumを探したくなって、
しかも見つけてしまったではないか。


ちょっとﾏﾏﾝ探してくるﾉｼ

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

Athlon64X2 3800+@939だと>>370と同じだった
vender:AuthenticAMD CPUID:FB1
x87 SSE SSE2

>>379
ﾜｸﾃｶ

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

やべ、ﾏﾏﾝ見っける前にこっちに持って行きたくなっちまったｗ
ttp://www.faith-go.co.jp/sale/20th_cpu.asp

>>383
あれ？CoppermineでもSSEはNaN,∞で問題ないですね…。

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

> AMDのCPUは昔からNaN,∞に強いんですね。
幾ら強くても普通にそれ使わないからムダw

つかなんでNANとINF食うとストールするんだろ

>388
どこかで場合わけして、該当したらマイクロコードに飛ぶんじゃない?

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

>>389
そういえばそんな物あったね、もうね、すっかり失念。

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と同じっぽいね。やはり古いだけあってクロック当たりの性能はいいけど。
小数点以下の数字が、みんな１なのが面白い。

>>376
テーマとしては面白いね。
K8に対して、Northwoodが勝つにはadd eax,eaxを繰り返せばクロック当たりで倍の性能になる。
K8に対してPentiumMが勝つには、paddd mm0,mm0を繰り返せばこれも倍。
あとは排他キャッシュの弱点をえぐり出すことかな。

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

俺はAMDユーザーだからIntelに負けて欲しいな。

ららびー

そういえば団子のサイトのRSSっておかしくね？

団子ちゃんのサイトなんてあったの！？
ちょー見てー！　アドレス教えて！

SPAMトラックバック掃除したときに消したまんまだ

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


ネタは>>395

ぐぐったら http://www.sourcream.jp/archives/2007/03/00081.php
これがトップにきたんだけど、団子ちゃんってこんなにめんこかったのか！　(*´Д｀*)

掃除前の記事はRSSに出ないみたいだね。

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 [email protected]: 3 DP(7 SP)

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

P35マザーで組んだけどなんか人柱依頼ある？

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

>>403
こういうときのために平素から測定プログラムを作っておくんだったと後悔しきり。
とはいえ最近、自分で高速化する需要が減ってたりする。

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

ちょうどVista x64動かしてるから命令長ネックの検証でもしてみるのも手だと思うけど

うお！64bitOSかよ。それを先に言え。
つっても俺は環境なしにコード書けるほど器用じゃない。すまん。

そこでVMwareに64bitLinuxですよ

アレってx64非対応の石でも使えたっけ？
QEMUならx64エミュレータあるね

>>408
今時amd64非対応の石なんて使ってないだろ。

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

動かせないよ

GeodeやCore (2じゃないほう) Duo/Soloは非対応だよ。
モバイル用途ではまだまだ現役。

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

>>410
VMwareなら動かせるよ。

VMWareはx64が使えれば動かせるな

C2DだけどXP(32bit)の上ではx64版の犬がインストールできなかった

>>414
ちゃんとVTをオンにしているんだろうな。

え、VMware使ったら32bitのホストOSの上で64bitのゲストOS動かせんの？
今までホストも64bitじゃないと無理だと思ってたんだが。

お前の思いこみを吐露しろなんて誰もいってないぞ。

>>415
うっ、、、してなかった；；

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

強気すぎるだろｗｗｗｗｗｗ
Q6600ですら95Wで266ドルになるのに。

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

何で１PのQ6600が出てくるのか

ああ2Way Opteronか。

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

AMDの中の人正気？

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ということが判るす。

http://techreport.com/onearticle.x/12777

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

Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu.
信頼性が無いのはお前の頭だと思う...

>>425
テオ様が痛い人なのは同意だけど、技術的な嘘を付くような人ではないと思うぞ。
OS作成者から見て嫌なバグとアプリケーション開発者からみて嫌なバグは違うし。

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

NHK「本日未明、ド田舎村で不発弾が発見されそれを自衛隊が処理しました。」
>>424「日本って超危険な国家だったんだ。国外に脱出せねば。」

このスレで話題になってたと思うけどBarcelonaのL3接続図
ttp://opentechpress.jp/enterprise/article.pl?sid=07/07/02/0831208&from=rss
これ、なんの資料から取り出したのかわからんけど全部L3経由になってんの。
真実はどこにー。

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

>>429
IntelもL$2経由で接続するし、HT経由より速いんじゃないか?

>>430
こう考えるんだ。

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

ライトバックだったらイヤだな

>>432
バカ？

>>434
ネタにマジレスかこわるい

532 ：名無しさん＠５周年：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 ：名無しさん＠５周年：2007/07/16(月) 16:37:16
>>532
1,499ドルか
日本円にすると18万円くらいか
これってコストパフォーマンスいい方？

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

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

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

539 ：名無しさん＠５周年：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

vtuneの話はここでいいですかね

同じ18万ならAmiga最上位版買うな

同じ18万なら8800GTX搭載Core2Duo搭載のPC一台組むな。

age

AMD K10 Micro-Architecture
http://www.xbitlabs.com/articles/cpu/display/amd-k10.html

>>441
ピークIPCこそ3のままだが、32byteフェッチとSSEがDirectPathになるのが大きい。
SSEのロードも高速化されるし、命令の流れは相当スムースになると思う。

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

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

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

それはインテル流に言えばUPC(micro-ops per cycle)。

MACオタがマイクロアーキテクチャをよく理解していないということがわかるな。
>>1のいっているピークIPCとはプロセッサのパイプラインにおいて
理論的に持続可能な命令レートを指しているので、IPC=3にほかならない。

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

○○並列というのはないか。
○○wayというも今時のプロセッサにはアレだし。
retire/cycleとか使っているのは最近みた。

リタイアメントuOPs数で比較する？

>>443
俺が言ったのは、1clkにつきx86命令を（持続的に）3つを超えては処理できないということ。
ところで、最近自作板でも面白い話題が少ないねー。

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

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

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

>>450
いや平均IPCは上がるでしょ。
Core2みたいなマクロフュージョンがないならピークIPCを上げることは無理だけど。
でも、ピークIPCを上げる目的は、平均IPCを上げることだから無問題。

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

白い変人ことだんごです。
賞味期限切れてることは内緒です。

>>451

これと
xchg edx, [eax]
これ
mov ecx, [eax]
mov [eax], edx
mov edx, ecx
どっちが早い

なんか、デジャヴが

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/

>>455
んなもんCPUによる
少なくともP6系アーキでは前者はストールしまくりんぐ

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

xchg edx, [eax] は19clkとかかかって、何でこんなに遅いんだと思ったら、
LOCKがかかるのね（詳しい動作は知らんけど）。

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

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って感じだな。
あ、プロセサコアの話ね。念のため。

Pentium Mで導入された間接分岐の予測器をようやく採用したのか

間接分岐の予測自体は以前からあるけどな
前回と同じ場所に分岐するという簡素なものだけど

Quick and Dirty Quad-Core "Penryn" Benchmarks
http://www.dailytech.com/article.aspx?newsid=8585

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

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

ICL10ちゃうの？

>>464
ICLってなに?
IntelCompilerのことなら、通常iccというと思うのだけれど。

コマンド名っしょ。
LinuxがccをもじってiccでWindowsがVisual C++のコマンド名clをもじってicl。

EXEの名前がicl.exe
Visual C++の略称がclだと思ってるんだよきっと。

>>466
ICCはIntel C/C++ Compilerの頭文字とったものだと思ってたが

ccがc compilerなんだからモジってようがモジってまいが
Intel C/C++ Compilerで間違っちゃいないでしょ。

Linux/ICC,Win/ICLで使い分けることはあるにしろどっちでも通じると思ってた
まぁどうでもいいじゃん

確かにどっちでもいいが





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

oic

コンピュータアーキテクチャの話
(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)のデータだと思われる
少し紛らわしい

>少し紛らわしい
どころじゃないんじゃね？

実際のところはダンゴさんにピシっと語っていただこう

ttp://pc.watch.impress.co.jp/docs/2007/0830/amd2.htm
AMD、新たなx86拡張命令セット「SSE5」〜「Bulldozer」コアに搭載予定

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

オペランドが増えているのにソースの一つにメモリを指定出来るのが面白いな。

PCMOVはMMXのころから欲しかった機能だ

Intelは放置する

CMOVPS/PDがないな

CPUID EAX:80000001に定義ビットがあるようなものをIntelが採用するわけがない。
（唯一の例外はx64回り）

>>481
期待して自分が傷つきたくないだけでしょ。

本質的にはこうなんだよ

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

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

いや、むしろIntelのと比較するとDSPNow!だな。

確かに内積演算なんかはIntelのがリッチに見える。
AMDのはIBMがかんでるせいかAltiVecっぽいオペレーションが統合されてる。

ダンゴさんが語るとスレが引き締まるな

なにこいつ

Intel64に続いてSSE5の登場か・・・言ったもん勝ちだな

x64をAMD64と呼び
SIMD拡張をSSE5と呼ぶ






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

>>489
x64ってめちゃくちゃダサいっていうか意味不明だろ。
xってなんだ？

x86-64と書くのが自分のお気に入り。

ちょｗｗｗそれお気に入りでもなんでもないだろ

いっそx68にすべきだったな

リトルエンディアンのアーキテクチャに68と付けるな！

Intel Core2 Duo E6800

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/

いよいよベールを脱ぐ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というシリアルインターフェイスになる。
よくわからんが、最近のボトルネックらしいので、かなり強化される模様。

個人的には、コア数のバリエーションとキャッシュ構造が一番気になるところだ。
＃最近こういう記事がなかったんで、既出情報も多いのに全然覚えてなかった。。

Intel uPs Info 2 落ちたにょ

> ついにメモリコントローラが統合された

大爆笑

を？　今までは非同期SRAMすら直付け出来なかったとか？

チックとタック。あなたの好みはどちら
http://pc.watch.impress.co.jp/docs/2007/0921/mobile393.htm

俺はやっぱりPenryn萌えだなあ。今使ってるのも「チック」のDothanだ。
確かにNehalemも燃えるんだけどね。しみじみとした情緒が欲しい。

Silverthron＠0.55W未満 の実働デモに萌えた
http://pc.watch.impress.co.jp/docs/2007/0921/idf06.htm

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が入ってる。
実クロックの計測は無理だけど一応動作は確認できる。

 

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

>>505
これはスゲエ。
Barcelonaは相変わらずSIMD論理演算のレイテンシが2だな。
addssとかのスループットも1clkに1命令を超えるのは無理か。
Crusoeの変態モーフィングも面白いなあ。

さて、これを全部まとめてExcelの表にするにはどうしたらいいかな・・・。

へたくそだけど

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

シャッフル演算のレイテンシが1ってとこに注目

SSE2のPMAX/MINのスループットは0.5だが
SSE4.1のPMAX/MINのスループットは1

命令長が長くなるから自重

なにげにAMDのmovntss/dが速いな

ダンゴさんが連投すると盛り上がるな

盛大に盛り上がってるね。

うるしぁバールのようなものぶつけんぞ

すごい盛り上がりだね。

じゃあ上げとくか

気がついたら　同じ言い訳ばかりしてる
そしていつも純損失を計上
あきらめずにIntelのプロセスに挑戦するけど
すぐ微細化するよ

シェアがあれば　らくに研究費確保できるけど
何回やっても　何回やっても
Intelがたおせないよ

あのプラットフォーム何回やっても崩せない
イベント開いて　FUDしつづけても
いずれはベンチが晒される

ペーパーローンチも試してみたけど
次世代相手じゃ意味が無い！

だから次は絶対勝つために
僕はファブだけは最後までとっておく

気が付いたら　振り子が揺れてる
そしていつも周回遅れ
諦めずにアーキを全面刷新するけど
すぐにメッキはがれる

K8でいけば　らくにPrescottたおせるけど
何回やっても　何回やっても
Baniasがたおせないよ

PenM系のトランジスタ効率破れない
アーキの方向まねしてみても
インプリメントで差がつく

高価な製造技術試してみたけど
Intel相手じゃ意味がない！

だから次は絶対勝つために
僕は裁判費用だけは最後までとっておく

こういうのって本当におもろいと思って書いてるのかなぁ。

酒が入っていれば何でも楽しい

酒が入ったときは「うんこ」でも爆笑するやつは居る。

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

( ´ー｀) ?

Yorkfield買った猛者は現れるかな。

IntelのIntelR 64 and IA-32 Architectures Optimization Reference Manual

が、更新されてPenrynも載ってる。

徹底研究"Penryn" - Yorkfieldで探る45nm世代Intel Architectureの真実
http://journal.mycom.co.jp/special/2007/penryn/index.html

シリーズ化してくれるのはうれしいね。

>>526
ストアの改良だけをえぐり出すベンチは作るのが大変そうだな。

良く言えば完成度が高い、悪く言えば無難。
>>525のレイテンシとスループットの表を見てもそうだ。
Comroeで「遅い」と感じた命令が遅くなくなっている（糞のように速い命令はない）。

それにしてもL2は24wayか。
どこに欲しいデータがあるのか探すのに24回もアドレス比較が必要だからな。
データ位置によってレイテンシが変わったりするんだろうか。

tetsuya komuroかと思った

>データ位置によってレイテンシが変わったりするんだろうか。
そんな危険なことはしない

Phenom買ってきたからこのスレ的な計測を色々しようかと思ったけど手持ちのマザーで動かんかった。
無念…

マザーも買うしかないな。
というか、同時に買えばいいのに。

BIOSは?

>>531
UNKNOWNでも動くかと思ったんだが。
BIOS画面すら拝めなかったよ。
AM2+マザーはSB700が出るまで待ちたいんだがなあ。
なんか買ってしまいそうだ。

>>532
今のところ対応BIOSは無し。
AM2+マザーでも微妙に不具合あるみたいだから出るとしても一ヶ月くらいは待たされそうだ。
ASUSのAMD690G板じゃ動いたらしいが。

イヨッ良い漢。

S3Hで動かないかなぁ

さて、マザーを買ってきたわけだが。

ﾄﾞｷﾄﾞｷ…(ﾟДﾟ；)

規制食らったのでしばらく書き込めねー。
なんか知りたいことがあれば書き込みよろ。
自分でもやろうとは思うが何やればいいかよく分からん。

>>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）を迎えるのが楽しみでたまらない。

規制解除って長いのかな。
今やってる作業終わるまでに解除されなかったら携帯からやることにしよう。

キャッシュやメモリの設定を変えてやってみた。
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

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はマシになってるけどメモリレイテンシはちょっと大きいか。

本当は同一条件でRev.Gのコアとの比較もしたいところなんだけど、さすがに時間かかるので断念。
TXとかπ焼きとかはしてるけど他に何かやることないかなあ。

見ると試してみたくなる。
--
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

>>543
年内にx64版用意しようかと思ってたけど急いだほうがいい？

VS2008のPGO試してみたいから俺も実機買うしかないか

>>545
64bit環境無いし…。
でもどれくらい速度上がるのかは調べてみたい。
環境揃えようかなあ。

ちなみにPhenomとK8じゃSSE2利用でPhenomの方が1.5倍くらい速かった。
1〜4スレッドまで綺麗にスケールしたし。
C2Qには同クロックで10%くらいは劣る模様。
K8とC2Qのデータはそんなに正確じゃないけどね。

>541と>544もクロック差を考慮するとFPU以外はCore2Duoの方が速いな。

>>538
このテストお願いしたいです。
x86 Memory disambiguition test ( with resource codes)
http://www.realworldtech.com/forums/index.cfm?action=detail&id=73407&threadid=73407&roomid=2

>>548
残念ながら俺はマウスをクリックすることしか出来んのだよ。
自作板からの出張者なのでプログラムに関しては何も…。

>>549
コンパイルしてみました。こちらをお願いします。
http://www.wikihouse.com/x86clocker/index.php?plugin=attach&pcmd=open&file=MemoryDisambiguitionTest.zip&refer=Upload

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!

これでいいかな。

>>551
ありがとう御座います。
Out-of-Orderになったのはload before loadのケースだけみたいですね。

http://journal.mycom.co.jp/special/2006/conroe/
これを真似てRMMAのデータを全部取ってみたが中々興味深い。
K8と見比べるとちょっとだけ違う点がいくつかある。
取得した数字を処理する能力が俺にあればグラフをうｐ出来るんだが、表計算ソフトは10年以上触ってないのであった…。

くどい?
--
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
数字と比較したいポイントが判ればグラフにするのは請け負いますよ。

>>554
うーんお願いしようかな。
OOo入れてみたけどすぐには使いこなせそうにない。

http://journal.mycom.co.jp/special/2007/penryn/index.html
さっき特集はソフトが古くてデータの整合性がとれないのでこっちの特集がよさげです。
もっかい特集と見比べてどのデータを渡すか選びますね。
全部渡しても大変でしょうから。

>>554
上でごちゃごちゃ言いましたが、結局特集に出てたデータ全部纏めました。
どのデータをグラフ化するかはお任せします。
CSV吐いてくれたので慣れた人がやればグラフ化は簡単だと思います。
だるかったらやっぱやめてもおｋです。

http://www-2ch.net:8080/up/download/1195964178823974.MbX2GM?dl

そしてせっかく纏めたので他の人にも提供。(パスは"phenom")
何かの参考資料としてどうぞ。
グラフ化歓迎ｗ
そのうちまた大原特集が組まれると思いますけど。
RMMAで取ったデータは他にもありますので、項目調べて欲しいと言ってくれれば用意するかもしれません。
うｐしたのはGangedのデータですが、Ungangedのデータも一応あります。

個人的にCacheの帯域にちょっとびっくり。

>>541
貴重なデータをありがとう。
マンデルブロ集合は、PenMでチューンしたので相性があるかもしれないが、
やはりSSE性能は、PenM＜Phenom＜Core2。FPU性能は大差なし。
Phenomは、実行ユニットはK8の倍あるから、コードを変えればもう少し伸びると思う。

キャッシュレイテンシは意外と素直だね。
L3のレイテンシは長いから、メモリベンチでは平凡な結果になると思うけど、
共有のデータ置き場があってコア間通信もK8以上なら、実性能は期待できる。

>>553
生データだけでもすごく嬉しいのですよ。
それにしても、>>556。L1は本当に32byte/clk近く出るのだね。

試しに「D-Cache RAM Bandwidth SSE2」をアップロードしてみました。
性懲りもなく、Core2Duoの結果もついてますがw
http://www-2ch.net:8080/up/download/1195984374904107.xGtrct?dl
# パスは>556と同じ
OpenOfficeでxls吐くとレイアウト崩れるしでかくなるのでパス。
グラフだけ、絵でアップロードした方がよかった?

>>558
サンクス。
しかし改めて並べて見るとCoreに全然引けを取ってないから凄いな。
むしろ上回る部分も多いし。
L1 hit時なんかK8の4倍だけど、これはSSE Unaligned Load-Executeってのが効いてるのかな。
K8でも64bitの2ロードではあったから。
L3も役に立ってはいるけど量が少ないのが惜しい。Shanghaiは期待出来るだろうか。

PhenomのD-CACHE LATENCY 見てたら、特性が、なんかCore2に似てきた感じだね。

キャッシュの範囲では早くなってるが、メモリの範囲ではRANDAM、PSEUDO-RANDOMでK8より遅くなってる。

あとはどれだけ各種コンパイラが頑張ってくれるかですかねぇ・・・

SandraのCache & Memory Benchmark見る限りK10よりCoreMAの方がスコア高いけどRMMAの結果と矛盾しない？
K10は2ロードだから良いとしても、CoreMAはRMMAだと16byte/cycle止まりだけどSandraはもっと行ってる気がするんだが。

>>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はロードとストアをミックスした場合の、リードとライトの帯域の合計。

>>563
K8ではXMM(128bit)へのロードはFMISCのみへのDouble Issueだったものが
K10では3ユニットいずれかへのSingle Issueになっているね。
K8でもMMX(64bit)へのロードは3ユニットで処理可能だった。
実際にはL/S Unitが2基しかないけどね。
この場合はロード帯域がカタログスペック通りになるね。

K10改良点としてXMM to XMMコピーがFMISCでも処理可能に
なったことがあるけど、性能向上にどれくらい寄与するんだろう?

>>563
ロードストアの合計だったのか。納得。
CoreMAは128bitロードストア同時に出来るもんな。

>>563
命令処理の差でしたか。

>>564
そこら辺の改良の効果も測ってみたいですねえ。


メモリのGangedとUngangedの差を調べてたみた。
けどいい加減スレ違いかな。
ここってCPUコアの話がメインっぽいし。

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はストールするので注意。

>>567
Nontempral Storeの測定もお願いします

>>567
これは興味深い結果だね。
独立したロード・ストアでも並べ方に注意って事か。

>>568
個人的にメモリストリーミングにあまり興味がないので
調べた事がなかった

MOVNT ってキャッシュ迂回するんだっけ?
訳あってシステムがDual Channel構成じゃないので
ここで回しても有意な結果が得られないかもしれん。

マンデルブロ集合ベンチをもう少し。
以下はすべてクロック当たりの性能の話です。

前スレで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つしか使いません。

AMD CodeAnalystにはまだ、K10のPipeline simulationが実装されていない…!!

AMDの資料に MMX MOVQ reg,regの実行ユニットが FADD/FMUL と書いてあるので
確かめてみたらその通り。
今さらMMXが速くなってもうれしくないだろうが、一貫性ないな。
XMM MOVDQAなどはFADD/FMUL/FSTOREだった。

libpngはいまだにMMX版が主流じゃなかったっけ？

誤爆？

AMDのMMXはまずレイテンシがネックぢゃん

レイテンシ2が3Wayてことはつまり性能を引き出すにはコードシーケンスを6並列化しないといけない。
で、論理レジスタ8本の縛りの中でfadd/fmulが休まないようにスケジューリングすれば
ロード・ストアに空きができることなんてないと思うが･･･

ということはfstoreのレジスタ間movdqaはXMMレジスタ16本の64ビットモードでこそ意味があるんでね？

分ってきてるじゃん。
以前はインターリブすりゃいいとか闇雲に言って、8本でできるかよって突っ込みたかったものだが。

頭のおかしい人に勘違いで油を注ぐなよ・・・・・

空気を読まずに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%くらいはいくのかもしれん。

EM64T より AMD64 の方が
CPUID とか RDTSC のレイテンシが小さい気がするんだけど
何で？

具体的な数字を出してください

CPUID + RDTSC の発行で
EM64T だと 300 クロック以上掛かるけど
AMD64 だと 70 クロック弱

>>580
ia32_arh_dev_man_vol2a_i.pdfより抜粋。
＞CPUID命令はどの特権レベルでも実行でき、命令の実行をシリアル化することができ
＞る。命令の実行をシリアル化することにより、前の命令においてフラグ、レジスタ、
＞メモリに対して修正が行われた場合、それらの修正がすべて完了してから、次の命令
＞がフェッチされて実行されることが保証される。

そういう事。

>>583
AMD64 でも CPUID は非特権のシリアル化命令じゃないの？

CPUIDは知らんが
RDTSCはエミュになってるんじゃない?

C2D発売直後にLinuxでRDTSCやってみたら
コアクロックじゃなくバスクロックでカウントしてた。
後日Vistaでやったときはコアクロックに準じた値になってたけど
恐ろしく実行時間がかかるようになった。

誰か、素のDOSでRDTSC追試きぼん。

よく分からん
アセンブリで書いても Linux とか Vista とか OS の影響を受けるのか
あとコアクロックとバスクロックってどうやって区別する？

バスクロックじゃなくてコアクロックがダイナミックに下がっているだけじゃねーの？

>>586
OSの作り方によっては、影響を出せる。
＞保護モード例外
＞#GP(0) CR4 レジスタのTSD フラグがセットされていて、CPL が0 より大きい場合。
＞実アドレスモード例外
＞なし。
＞仮想8086 モード例外
＞#GP(0) CR4 レジスタのTSD フラグがセットされた場合。

で、わざわざ CR4 の TSD フラグをセットして一般保護例外を発生させて
その OS は何がしたいわけ？
例外ハンドラで RDTSC をトラップして訳の分からん時間を掛けて
edx:eax に変な値を返すのか？

RDTSC の挙動を変えることの実現可能性の話をしてるんじゃないぜ
実際に Linux と Vista の違いで RDTSC が違う挙動を示すのかどうかを確認している

>>585
>>120

つまりC2D RDTSCの挙動はBIOS,OSによって変わるということだな?

BIOSでも変わるだろうし、マイクロコード書き換えでも変わるだろうし、
OSがトラップしてゲームのパフォーマンスのために昔通りの値にすることもあろうだろう。

とりあえずもう少し詳しく調べてきたよ

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" ってので改善されるのかねえ

>>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 ってことかも

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

この質問がスレに相応しいか判りませんが、
Core2のL2キャッシュの登録・削除・検索アルゴリズムって
どんなのか判りますか？

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

Intel 64 と Intel Architecture 64 ってぱっと見分かりにくいな

IA-64はIntelAMD-64の略

IntelはIA-64よりもIPFって言ってるな。

来年は順調にいけば

・Silverthorne
・Nehalem
・Shanghai

が出てくるんだよな。
全種手に入れてやんよ。

Larrabeeも思い出してあげて



上海ってただのシュリンクだからFusionの一端を担うBulldozerのほうこそ注目

Larrabeeって来年に出たっけ？
来年に出て一般人が手に入れられるようなら入手。


ShanghaiかMontrealでキャッシュの構造が変わるんじゃないかと期待してる。
IPC Enhancementsってのも気になるし。

Bulldozerは……2009年中に出るんかなあ。

知らんけどIntelはこのテラスケールプロセッサはより高度なWiiライクなゲームを将来実現するために重要だとか言ってますよ。
×箱で懲りたんじゃなかったのか

>>340のマニュアルでは, 128 bitのシャッフル/パック/アンパック等の
レイテンシは2 cycleだけど, >>505の測定結果だと3 cycleになっている.
追加されているRev.B2の測定結果でも3 cycleだし、エラッタにも該当する
ものがないから仕様なのか?
45nmのShanghaiで改善されたりするのだろうか?

×箱に関わってるのか，Intel？

初代×箱のCPUはCoppermine-128Kの733MHzだよ。

ぉ，確かに, thanks
ってことは失敗から学んだんじゃまいか

書くことないから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/

こういう記事がもっと増えてくれば良いんだが、大原か米田くらいしか書きそうにないのがなあ。
他はベンチ回すだけだし。
このスレに来る人くらいしかアーキテクチャの詳細には興味は無いんだろうか…。

今更だけどSSE5の16ビット浮動小数→単精度相互変換命令についてAMD-ATiの今後について妄想してみるのもありかと。
それにしてもNehalemは凄すぎるな。

暇だったので>>558のデータを1つのグラフに纏めてみた。
http://f12.aaa.livedoor.jp/~itatisa/phpup/cgi/src/up1886.jpg

さらに暇だったので>>556のデータをグラフ化してみた。
PASSはRMMA。
http://www-2ch.net:8080/up/download/1198948333164525.BRq4Rf

K8に比べてL2帯域が微妙によくなってる。
L1も強化した分しっかり帯域は増えてる。
だがI-Cache RAM Latencyじゃキャッシュの範囲内でBackwardがえらく遅い。
なんでだろ〜。

それにしてもCoreMAのL2は大容量かつ高速で優秀ですな。

お邪魔します。別スレから誘導されてまいりました。
Pen4のリアルモードでの動作速度についてお聞きしたいことがあります。
Pen4をリアルモードで動作させた時の浮動小数点演算速度とプロテクトモードでの
浮動小数点演算速度は大きく違うのでしょうか。
因みにPen3(1GHz)の場合、リアルでもプロテクトでも大差ないことは確認しており、
AthlonXPでは　　リアルでの速度(Pen2,100M程度)　<<　プロテクトでの速度　です。
浮動小数点演算を多用するＤＯＳプログラムをなるべく速く実行させるために
Pen4マシンの購入を検討しています。
どなたかご教示をいたたけるとありがたいのですが。
よろしくお願いします。

>>613
> 因みにPen3(1GHz)の場合、リアルでもプロテクトでも大差ないことは確認しており、
> AthlonXPでは　　リアルでの速度(Pen2,100M程度)　<<　プロテクトでの速度　です。

これはどうやって検証したの？
検証用のコードがあるのなら、アップしてPen4を持っている人に実行してもらって
結果を報告してもらえばいいのでは？

Pen4で頑張って動かすより、Xeonで力任せに動かす方が余程速いんだが。
つーか、今時なんでDOSプログラムなんぞを使うのかが理解できん。

>>613
検証プログラムをUpすればこのスレの暇なPen4ユーザが計測してくれるぞ。
過去にもいろいろ計測人柱が計測しているのがこのスレ。
漏れはあいにくNetBurstな環境は持ってないから計測できないが。

>>615
世の中いろんな人がいるんだからそれを言うのは無粋。

Core 2じゃ駄目な理由が聞きたい。
Pentium 4なんか32bitで動かしてもx87は理論値でクロック当たりPentium 3の半速だぜ

団子がうぜーからじゃね?

ﾜﾛｽ

Pen4マシンってまだ売ってるんかな

>620
売ってる。
HPの格安WSとか。

PenDはまだまだしぶとく残ってるな
あれってもう生産中止じゃなかったっけ

Core2は64Bit専用レジスタを持っていないので、32Bitでも64Bitでも消費電力も発熱量も変わらないと思われるが、Phenomは64Bit専用レジスタを持っており、これには32Bitでは動いていない物がある。
このレジスタが動き出し、発熱量が増加したとすれば、限界が下がる事は十分にあり得る。

ついでに64Bit環境でPhenomが健闘している事が、32Bitより64Bitの方が向いているという証にはなるわけだが、同周波数で同程度であっても、周波数の差で負けているのが何とも…
2008/01/05(土) 17:20 | URL | LGA774 #-

>>623
ひどいバカがいた物だな。どこの掲示板？

>ついでに64Bit環境でPhenomが健闘している
事実を受け入れられないのはかわいそうです

http://northwood.blog60.fc2.com/blog-entry-1555.html#more

Core2は64Bit専用レジスタを持っていないので、32Bitでも64Bitでも消費電力も発熱量も変わらないと思われるが、Phenomは64Bit専用レジスタを持っており、これには32Bitでは動いていない物がある。
このレジスタが動き出し、発熱量が増加したとすれば、限界が下がる事は十分にあり得る。

ついでに64Bit環境でPhenomが健闘している事が、32Bitより64Bitの方が向いているという証にはなるわけだが、同周波数で同程度であっても、周波数の差で負けているのが何とも…

６４ビット専用レジスタｗｗｗｗｗｗｗｗ
Core 2で64bitが遅いのってホントはレジスタのビット数がどうのこうのじゃないのにね。

ttp://itl.jisakuita.net/core2_mossari/1162381694.html

ダンゴさんの執着心には頭が下がる

馬鹿が気が触れてますな

>馬鹿が気が触れてますな

気が触れた馬鹿は最悪だ

気が触れない馬鹿はただの馬鹿だ。

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

>>633
多少ブレはあるけど、おそらくこのベンチに関しては65nmの>>544から変わってないね。
デコーダの改良もない感じで、予想された通りの結果だ。

Q9450を買うか

購入宣言age

ばーるのようなものやさんのPCはWolfdale/Yorkfield Readyになりますた。

これからこのスレは
ばーるのようなものやさん専用になりますた。

E8500買いました
PCケースをバールのようなものでこじ開ける作業が始まります

買ったんかよ

それからそれから？

>PCケースをバールのようなものでこじ開ける
CPUケースかと思た

ttp://pc11.2ch.net/test/read.cgi/jisaku/1198229279/l50
こっちで待機中

さぁさぁ、遠慮せずお続けになって。
ここはあなたのスレですよ。

プログラミングする人には重要な情報

CPUIDをとると
Family 6 Model 【7】 Stepping 6

になってますが、これだけだとPentium III（Katmai）と誤認します。

Extend Model値は17になってるのでこっちをチェックしませう。
まあSSExフラグ見て決めるのもOKだと思うけど。

>>643
構造上LGA775でスッポンはないと思うが。
いっぺん負荷かけてから外すと簡単に外れる。

スレ主降臨ａｇｅ

ダンゴさんの連投でスレが一気に加熱したな

誉め殺し乙

とりあえず割り算ベンチやってよ。

>>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だな（棒）

SSE4の66hを取ったら未定義オぺコード例外が発生するのかな?

さあ、間違ってもMMレジスタに作用することはなさそうだが。
ネモい

>>651
これが、Radix-16 dividerの実力ですか。
>>108とかと比べると、32bit境界が見えなくなっていて、一つ64bitっぽくなったな。
2倍は言いすぎにしても、本当にそれに近いくらいの力はありそうだ。

>>300は何だったんだ？

マザー謹製ツールが軒並み問題だらけなんでもっと人集めた方がいいかもね

>>655
単なるエイプリルフールねたのつもりよ（・∀・）

誰もやってないので

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

--- 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　　　←ありえねぇｗｗｗｗ
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で書き直す価値はありそうだけど。

○SSE4で

katmai Dual / 3Ghzで鼻からトマトジュースが出てくるところだったｗ

>>658
お、IntelCPUと計算方法が違うみたいですな。

商の桁数が多い場合でも早く終わるのか、
それとも、商の桁数が少ない場合でも時間がかかるのか。
どちらにしても、最遅で47clkというのは、むしろIntelっぽいクロック数だ。

さて、各社Penrynモデルが出揃って来ましたね〜。

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

↑これほとんどスカラだった。
明示的にSIMD化したら恐ろしいことになるんじゃないのか？

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

>>665
128bit精度の浮動小数点演算というのは書き間違い？
FPのレイテンシが3というのは大したもんだ（単精度の加算だけとか言うなよ）。
L1が64KB+64KBでL2が1MBだが、これだと排他制御が無駄に見える。
仕様が豪華になった分、ダイサイズが増えているのは残念。
性能的にはクロック当たりでCeleronMくらいだろうか。

温度に余裕があるときは、クロックを上げるのではなく
電圧を下げるというのがナイス。
容量を捨てて寿命を延ばしたエネループと同じような思想だね。

> 単精度の加算だけとか言うなよ
[H]Enthusiastに載ってるスライドのp.9-10

全ての浮動小数点加算のレイテンシは2サイクル
単精度の浮動小数点乗算のレイテンシは3サイクル
倍精度と拡張倍精度のスループットは2サイクル、レイテンシは4サイクル

スライドがテキスト化されてるのでこっちのほうがいいかな?
The VIA Isaiah Architecture
ttp://www.extremetech.com/article2/0,1697,2252201,00.asp

>>667
書いてあったのか。ありがとう。
倍精度のスループットは仕方ないけど、加算のレイテンシ2はすごいな。

> world-record
確かK6のfaddがレイテンシ2、スループット2だったと思うけどｗ
それにしても、この短いレイテンシで2GHzとか出るとしたらすごいな。

個人的にはIn-Orderのままでデュアルコアとかやってほしかったけどな。
（まあ、正直それはバランス悪いんだけど）
これからもVIAらしい萌える石を作っていってほしいです。

すっかりCNのこと忘れてた。
発表が2004年だったしなあ。
去年中に出るとか言う話をちらっと聞いたりしたが。

中々最先端だな。
Silverthorneといいコイツハオモシロクナッテキタ。

Latency 4 の 2GHz より 5 の 3GHz の方が速いんだけど．．．
最初から 2GHz 辺りをターゲットに設計してるんじゃね？

倍精度遅いんか。。。


パイをソニー製のクロいブッタイに移植してみようかと思ったけどめんどくさくて投げた。

日記あげ

ダンゴさんがCELLの話題をはじめると盛り上がるな

>>671
何が面倒臭かったんだ？

スレチだから返事はこっちに
ttp://pc11.2ch.net/test/read.cgi/tech/1183091522/

ところでなんで団子さんは職業プログラミンガーから
趣味プロミンガーになったのさ

X2のG2ってL2レイテンシとか変わってるんだろうかとふと思った

latency.exeだと20cyclesの判定

Penrynって64ビットもMeromのときに言われたほど遅くない。むしろ速い。


QPI-QuickPi v4.5 for x64, (c) 2000-2008 S. Pagliarulo
Freely distributable, email: [email protected]

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%

遅いとか騒いだ連中は猫基地外の記事を希望含む視点で読んでしまったアホだけだから。
その遅いCPUよりさらに遅い対抗馬の出来は棚に上げ、
Fusionが効かない効かないと盛んに喚いた基地外もアレだが。

先月のWinPCの記事はひどかったなぁ

Phenomで探る、AMD新世代プロセッサの真実 - アーキテクチャ研究編
http://journal.mycom.co.jp/special/2008/phenom01/index.html

大原特集やっときた。
K8とK10で割り算レイテンシが違う(>>658)ことに関してもちょろっと触れられてる。

毎度の事だが、この手の基本スペックは優れているなK8、K10。
性能はパッとしないけど。リソースの掛け方が間違ってるのかね？
その辺は後編で触れるかな。

K8は元々のコンセプトが直線ばっか速いIntelより峠だぜ！って感じを受けるよな。
IntelはPenMのチームに軌道修正されて相当救われたと思う。

ただSIMDが既に直線用だったのに、ここのところマルチコア路線になってきて
更にインオーダでSMTにしたらPen4時代以上にスカラでシングルスレッドなアプリがしわ寄せ食うよな。

SMTにする事で全体の効率は上がるわけだが、単体で見れば愕然と遅くなるわけで
高クロック化に限界が見えてる今、ロジック上どうしようもないスカラ部分の足をまた引っ張ろうというのは危険な気がする。

＞単体で見れば愕然と遅くなるわけで
それは過去のバグ付きPen4だけでねーの？
OoOがInOrderになるならそれは確かに当てはまるけど、
SMTになるだけなら性能劣化は誤差程度だべ。

2スレッド分負荷かけると、全体で120%になるけど単体は60%でしょ、と言いたいのでは
まあ、今回は4コアあるしこれが問題になることは少なそうだけど。

日本語でおｋ

>>685
686さんの説明の通りだけど、P4はOoOじゃなかったっけ？
今後IntelはSMT+InOrderにするっつー話じゃなかった？
不確かな情報ばかりでスマン。

＞今後IntelはSMT+InOrderにするっつー話じゃなかった？

そういうのもラインナップに加えるだけで路線を変更するわけじゃない

>>682
http://pc.watch.impress.co.jp/docs/2006/1016/kaigai312.htm
この辺のL3が半共有キャッシュ的な動きする付近の追試をやって貰いたいなぁ・・・

http://pc.watch.impress.co.jp/docs/2007/1215/tawada122.htm
キャッシュで思い出したけどなんでメモリアクセスって上のグラフ5みたいに遅いの？
HTの帯域が16GB/secなら素人考えでPC2-6400x2が完全に引き出せてもいい気がしちゃうんだけど。

SDRAMの最大帯域って理論上の値だから

その理論値の出ない理由が知りたい。
例えばL1やL2、それに命令のパイプライン実行にかかるクロック数は机上で計算した値と実際は同じになるでしょ。
真の帯域を理論上で算出する事は出来ないの？

車がどれだけ速くなっても、ドア開けて乗り込んでエンジンかけてシートベルト締めて…なんて時間はたいして変わらない。

DRAMだから。
DRAMは読み書きにコマンドがいるし、定期的にリフレッシュコマンドも入れなきゃいけない。
PC2-6400 の6.4GB/sって値は上の事を考えないで、データが読み書きできるとしたらという仮定の値。

DRAMコマンドとかバスプロトコルの問題じゃなく構造の問題でしょ。
レイテンシが低減できないのは。
マルチバンク構成になってるから連続読み書きはある程度理論値に近づく。

レイテンシ考えた1サイクルあたりの速度だとDDR1やSDRのCL2のものが今でも最速だからね。

帯域の話でレイテンシの話はしてないだろ。

君はバースト転送一回分だけというまったく意味のない帯域の話をしたいのか？

1GB転送するベンチマークでレイテンシも糞もなくね？

そもそもHTとメモコンは別個だろ

>>700
もしかしてコマンド一発出したら1GB送られてくる、と思ってる?

>>702
逆に1GB転送してもバースト転送一回分なの？

どんな事情であれ、プログラマとしてはあんな6.4GBx2/secなんて詐欺ではなくて
正確にクロックとか帯域を計算する方法は無いのかって話なんだが。

理論的に何処まで出せるか、どうしたら出せるかって議論は重要。

CPUが一度に取り込むのはキャッシュライン単位に決まってるだろう。

あと、Ring0で実行して計測云々ならまだしも、どうせユーザーモードで触って計ってるんだろ

Ｒｉｎｇ０（笑）

DRAM の仕組みをお勉強してね（はぁと

ばーか

実メモリにダイレクトにアクセスするのですら特権が必要なんだよ。
1GB連続した領域をアロケートしたとして、そこが実メモリなのか仮想メモリなのかはアプリ上からは判別できません

>キャッシュライン単位に決まってるだろう。
んなこた分ってるよ。で？

>実メモリなのか仮想メモリなのかはアプリ上からは判別できません
そうだけど、マッピングがそんな細切れになるとも思えないし。
つーかバースト転送ってどれくらいのサイズならいいのさ。
仮にマッピングがぐちゃぐちゃだったとしても、1ページは連続してるわけだから多少は効いてくるんじゃないの？

MEM_PHYSICAL

最大バースト長が8だから
8x64bit=64Byteより大きくならないのかな?

>>710
AWEサポートしてない環境は無視って素敵だね

Ring0(笑)

黙れスイーツ（笑）

わざわざ鯖OS入れるくらいならDOSなり自作OSなりで特権命令触ったほうが楽でしょ

そんなもの誰が使うの

本当にDOSや自作OS(wが楽だと思ってんのかｗ

自作OSの本を読んでみたが、うぎゃーって感じだった。
言っていることぐらいはわかるんだが、とにかく面倒くさくて泥臭くて。

はいはい団子あげ団子あげ

サーバOSを入れるほうがよほど「楽」だと思うがなぁ。

俺のPCだと、Dothan-1.1GHzとPC2100で1700MB/secくらいが限界かな。
>>693に同意なのだが、DRAMはプリチャージとか複雑で小難しくて、
最近は、原理は妥協して振る舞いを完全に知ろうというスタンスだ。
情けない状況だ。

>>703
確かに詐欺だね。
どっかで、インターネットが100Mbpsと宣伝しているのにレンタルのモデムだかが
ボトルネックになるから絶対に100Mbpsが出ないということで
宣伝の仕方がおかしいという話を見たことがあるが、それと似てる。

それを言ったら SATA だってそうだし．P2P の転送路を持つデバイスは皆アウトじゃない？

Hardware ってのはそういうもの，あるいはそういう約束，で FA．

ディスクデバイスは帯域がいくら上がったところでディスクの性能が追いつかないっしょ。
殆どはキャッシュの性能と言っていいんじゃないだろうか。

ISPが詐欺なのは人災だから置いとくとしても、
LANはノイズが入るから転送効率何%とかちゃんと数値があるっしょ。
メモリは6.4GBxDual Channel/sec=12.8GB/sec出ると言っておきながら
Phenom9900でさえ4.5GB/secしか出てないわけで、35%しか出てない。
転送効率とかって次元じゃない気がする。

>>724
> LANはノイズが入るから転送効率何%とかちゃんと数値があるっしょ。
ないよ。少なくともノイズがどうこういうだけで転送効率は定まらない。

> Phenom9900でさえ4.5GB/secしか出てないわけで、35%しか出てない。
CPUはDRAMにとって好ましい最適な転送パターンを行わない。
＃HDDでランダムシークばかりして「スピードでねー」とほざくのと同じ。

理想的パターンで読むデバイスをFPGAかなにかで作ればそれなりの速度で
読み出せると思うよ。

その為のバースト転送なんじゃないの？

>>724
バスプロトコルから算出した理論的な数字は理想的な特性のメモリを用いた場合等で
算出できるだろうけど、実際にはそんなメモリ無いしあまり意味ないような・・・

実運用での効率を掛けた数字なら、実効帯域とかいう言葉が昔からあるし。

DRAM の動作をきちんと理解しろ．話はそれからだ．

>>728
理解できないから困ってるんだよヽ(`Д´)ﾉ

スレ違い気味だな

ユーザーズマニュアル、テクニカルノート
ttp://www.elpida.com/ja/products/documents.html

DDR3 SDRAM、DDR2 SDRAM、DDR SDRAMの比較
ttp://www.elpida.com/ja/products/ddr3.html

>>728
お前、理解してないだろ。
なぜならDRAMの動作だけを理解しても>>1の疑問は解決しないからな。
それよりバスの通信の基本を学び、12.8GB/secのデータが常に流れ続けるというのが
ありえることなのか、考え直してみれば普通にわかる。実際はピークでは帯域がでている。
SATAにしろUSBにしろ実効値が遅いというのは帯域という言葉の指し示す範囲が
理解されていないからだ。

CPUとメモリのやりとりと言っても、通信というのは結局、ある記憶域(ラッチやキャパシタの集まり)か
らある記憶域へと情報がコピーされているだけなのよ。12.8GB/sec流れ続けるというイメージを
持っている人は送り先がの構造を記憶域(CPUでいえばラッチ/レジスタ)だということが頭にイメージできて
ないだけ。それ以外にもプロトコル上で帯域というのがどこを指しているのかという問題があるが、
>>1の疑問の範疇からは多分外れていると思う。

メモリからメモリへコピーする場合はかなり理想の帯域に近い数字がだせるだろう。
しかし、CPUの記憶域はメモリにくらべてらごくわずかでしょ?それが大部分の原因なんだよ。

>>731->>733
には大嘘が3割含まれている。これは自分で考え、学習して、
真の理解へ至らせるためのトリックだ。

>>731
ヘッダ長は大した長さじゃないだろうし、同期に時間がかかるってことかな？
それにしても35%は酷過ぎやしない？

>>732
ニホンゴムズカシイネ。でもここが肝な気がする。

>>733
L3の話ではないよね。
HTが16GB/secだってのは決まってるわけだし、仮に64KBしか無かったとしても
ループバッファみたいにどんどん上書きしていけば連続して読み出すだけなら出来るし。
CPUの記憶域というのは、何かバッファがあるって事？

俺は DRAM の cycle time がボトルネックなんじゃないかと思ってるんだが
どうだろ？

理想モデルと実物モデルを比較されても困るという話・・・

>>724
Streamベンチマークで、10GB/s出たよ。
スレッド数増やしてコア同士で帯域食い合いさせると、
トータルの帯域は上がる。Phenomは特にそんな気がする。
storeはmovntpdにすると速くなる。
環境は9500にDDR2-1066。

金銀バール
プレゼント

>>736 Phenomはきちんとしたサイクルでアクセス出来るって書いてあったような。
>>737 ノイズが激しすぎるって事？
>>738 kwsk。Sandraだって複数コアでアクセスするんだがなあ。
>>739 カスラックから来ました

例えば、普通にmovqでシーケンシャルアクセスすると、64byteのロードに47clk、
ちょっと命令を並べ替えると44clk、プリフェッチ命令を使うと39clk。
デコードや実行ユニット関係の、「メモリ以前」の問題もある（微差とは思うが）。
これは古いノートPCだから大して差がないけど、Phenomレベルだとどうなんだろう。

あと、もう一つの「メモリ以前」の問題として、ベンチマークはアテにならないというのがある。
変に実用コードっぽくなってたり、帯域を引き出す工夫が微妙だったりするかもしれない。

>>737
理想の通りに動くのがコンピュータだろうが！
・・・すみません。自分の立ち位置を言っただけです。


ベンチマークは実性能を反映するように求められてるし、
PC側は機能を肥大化させて実性能を少しでも上げようとしている。
クロック測定を通じてアーキテクチャを知るには辛い時代だ。

WinRing0はどうかね？
MSRに変な操作するとすぐカーネル死ぬから注意。

DRAM - chipset - CPU
ok?

>>742
お前の大好きな「自作OS」を紹介してやれよｗ

>>741
結果を見ると、どうしてもMulti-Media Int x4の成績に行ってしまうが、
これはSandraの問題。Core 2 QuadはSSE3 Moduleで、
Athlon 64 X2やPhenomではSSE Moduleでテストを行うためで、これはイーブンな条件とは言えない。

みたいな事が大原記事でようやく言われましたからねぇ…

とりあえず本当にメモリの帯域調べたいなら
DRAMのスループット以上が出せる設計の上で自分でFPGAなりいじるしか無いのではないでしょうか。
まぁx86の枠外れて完全にｽﾚﾁになっちゃいますが。

ダンゴさんのインテリジェンスあふれるレスが望まれるところだ

だから、メモリアクセスってのは断続的で、ソフトでいくら帯域志向なコードを書いても
送受信している時間とそうでない時間があるの。ピークでは帯域はでているが、
ベンチマークで計測される実効値はこれらの時間の平均。
OSのCPU使用率のように本質的な帯域ではないのだ。帯域と遅延の双方でものを考えないとだめなのは
コンピュータやネットワーク全般の常識。パイプライン化されている命令の実行だってそうだろう。
メモリ側の問題ではなく、ソフトやコントローラ側の問題だよ。
メモリを直でつないでコピーするだけの最小ハードを造れば理想な帯域に近い値だでるだろう。

OSのCPU使用率がCPUリソースの本質的な使用率を表しているのではないように

>>745
FPGAで頑張るまでしなくてもピークで帯域が出ているか確認するだけなら、
高価なオシロやロジアナつなげば直ぐにわかることだが。結論からいうと出ているんだけど。

団子屋さんの団子さんによる団子屋さんのための自作OS「DANGOS」近日公開予定

団子屋さんに特化したOSってどんなだろう

今の SDRAM 系の cycle time ってどの位？　まだ 50ns 切ってない？

cycle timeはおまいの脳内でどうやって定義しているの？
データシート見れば、おおよその値はわかるはず。
色んなタイミングの規定があるので、自分の都合上、最も気になる値を抽出すれば傾向は分かるはず。
内部構造と各種タイミングなどの規定に関しての理由を考えるのはスレ違い（もしかしたら板レベルで）
なので、自分で少々勉強した後で考えるヨロシ。

どうやったr理想的な実効値が出せるんだろうというのを考えてみたりするのがこのスレだったような

>>751
ベンチマーク測定用OSだな

USB2.0みたいに480Mbpsのうち一部が制御信号に使われるとかはあるのか？
DRAMのアクセスの並列化数に限界があってレイテンシが隠蔽できないのか？
メモリコントローラがネックで並列化数が増やせないのか？
>>747送受信している時間とそうでない時間があるのは何の性能が低いためか？
>>749の言うようにフルな性能は原理的に出せるものなのか？

>>754
原理を知らないと、どうしても最適化アイデアに抜けがでちゃうからさ。
まあ、本当に極限まで最適化をできた人は原理を知っているのと同等だとも思う。

>>755
32bitWindows使いながら64bitコードを実行できるような仮想OSキボンヌ。

>>756
> 32bitWindows使いながら64bitコードを実行できるような仮想OSキボンヌ。

32bitWindowsに仮想マシン乗せてその上で64bitWindowsを動かして64bitコードを動かせば解決。

Win64s出せばおｋ。

Win32sは、16ビット32ビットの壁が薄かったからできた芸当だったけどね。

64bitWindowsに32bitWindowsってラベルを貼って>>1に渡せばいいんじゃないかな？

>>740
ベンチマークは、ここ
http://www.cs.virginia.edu/stream/
から。いわゆるHPCのメモリバンドのベンチマーク。
Linuxで、gccの4.1以降で、-fopenmpつけて
コンパイルすればマルチスレッドなコードになる。

あとはSSE2とnovntpdなコードにするチューニングは
やったけど、晒すべきなのかね？

3連休の1つがつぶれるのは毎度のことだが
おいらはmovntdqaの性能でも検証してみるかな

>>756
>USB2.0みたいに480Mbpsのうち一部が制御信号に使われるとかはあるのか？
No。
アドレス線とデータ線は別系統。　
ただし、read/writeでデータがかち合わないようにするためのwaitクロックは入れる必要がある。
(SDRAM以降)
>DRAMのアクセスの並列化数に限界があってレイテンシが隠蔽できないのか？
並列化はかなり多くする事も可能。　Muuti-bank-DRAMなんて物も10年以上前から提唱されてもいる。
>メモリコントローラがネックで並列化数が増やせないのか？
メモリコントローラ・DRAMチップの双方に、コストの壁がある。
バンク数を増やす＝ビットコスト（コントローラコスト）の増大と考えて良い。
コストが上がると、ビット単価が安いDRAMを使っている意義に関る。

>>>749の言うようにフルな性能は原理的に出せるものなのか？
>まあ、本当に極限まで最適化をできた人は原理を知っているのと同等だとも思う。
プログラムの中で、同一バンクアクセス回避とか全てを前提として考えられるならある程度は
良くなる。
ただし、バンク切り替え後のアクセスタイムはある程度かかるので、x86命令に存在しない
データプリフェッチとかが必要になると思われる。(あ、それはIA64か？)

いちおうx86にもprefetch*はあるけどね

最近の最適化マニュアルには馬鹿は使うなって書いてあるけど。

ぅぅぅ
×novntpd
○movntpd
Linuxとかcygwinとか、VC持ってる人は暇つぶしにStreamどうぞ。
こういう主記憶シーケンシャルアプリでは、prefetchはほとんど意味が
ないみたい（あくまでもintel, AMDの場合だけど）。
L1のバンクとかは、ほんの少しだけ気を使う。

ぬーそくから久しぶりに思い出して富んできました。

【IT】「Core 2 Duo」は特許侵害…米大学、インテルを提訴[2/8]
http://mamono.2ch.net/test/read.cgi/newsplus/1202481381/

バースト転送以上に効率的なのはないだろうし、時間のオーダーが違うから本当に中の人じゃないと難しい話題だな。
その辺のロードの事前化をさらに推し進めたのがコアとこのヌース回りなのか？

流れを読まずに書いてみる。

SDRAMのカタログ性能が最大瞬間風速なんだよ。
そうだな、バースト長8ワードで、8ワード転送するくらいの間の。
もちろんCASレイテンシーぶんのクロック送ったあとね。

とりあえずデータシートでも読んでみたら？
つ　http://www.elpida.com/pdfs/E1128E20.pdf

>>763
>最近の最適化マニュアルには馬鹿は使うなって書いてあるけど。

w。あ、それじゃ、アフォが大部分を占めるプログラマには使えない命令だな。ｗｗｗ
使っても、使った事により効率の落ちる素晴らしい命令。ｗｗｗｗｗｗｗｗ

αの時代に、既に実装されていたインストラクションだが、50%以上のヒットを
命令実行後のある一定期間に行わないと逆にスピードが落ちるという諸刃の刃だったような。
(大昔のことなので、実装が異なる可能性もあるけどね。)

だから賢いコンパイラ様に吐き出してもらうのでは。
バカなコンパイラは吐くなってことで。

ハードウェア・プリフェッチがあるからじゃね?

レイテンシの隠蔽って考え方自体がおかしい。
隠蔽が成り立つのはマルチタスクかつCPUフルロード状態である場合のみ。
完全にランダムでやけくそに粒度の小さいデータが必要とされる演算を考えてみるんだ。
この場合は上でも何人か書いてるけどセルの最小単位であるSDR-SDRAMの速度しか出ない。
DDR1-SDRAMもDDR2-SDRAMもDDR3-SDRAMも端っこはSDR-SDRAMのままで、
それをいくつかのブロックにまとめて擬似的に拡張・増速した(ようにみえる)だけだから。
技術的にはパラレルバスをどこまで高速化できるかの挑戦ってだけで
メモリコア自体はずーっと変わってない。

>>771
いいからクソして早く寝ろ

>>762
> ただし、read/writeでデータがかち合わないようにするためのwaitクロックは入れる必要がある。
普通のライト（ライトアロケートあり）がやたら遅いのはこのためかな。

> メモリコントローラ・DRAMチップの双方に、コストの壁がある。
意外とコストに跳ね返るのだね。むむむ。

http://pc11.2ch.net/test/read.cgi/jisaku/1201341634/909
これはちょっと面白くなってきたかも・・・

それは普通にHT3.0になったからってだけだろ
CPUの性能とは関わりない
スレ違い

HT3.0になってそんなに変わったのか知りたい

むしろ最近のマシンじゃエクスペリエンスインデックスは5以上が当たり前かと思ってた。

本題に戻ろう

本題とはダンゴ先生のことだが？

ここはダンゴ劇場

バールのようなものだよ

じゃあバールのようなもの劇場w

バルバルにしてやんよ

　　ｵｲｼｽｗ　　　　　　　　　　　　　　　　？
　ｩ (⌒─⌒)　ﾑｼｬﾑｼｬ　　　　　　　 ∧_∧　　ﾑｼｬﾑｼｬ
　ｩ'`(（´^ω^))　 　　　　　　　　　　 　(･ω･｀ )
　 '`　/ つ┗━━━━━━　　　　/ つ┗━━━━━━
　　　 しー-Ｊ 　　　　　　　　　  　　　しー-Ｊ

　 (⌒─⌒):　　　　　　　　　　　　　∧,,∧ :
　　((;ﾞﾟ'ωﾟ')): 　　　　　　　　　　　　:(；ﾞﾟ'ωﾟ'）:
　:　./ つとl :　　　　　　　　　　　　　:/ つとl :　
　:　しー-Ｊ 　　　　　　　　　　　　　:しー-Ｊ :

　(⌒／ヽ-、_＿_ 　　　　　　　　　 ＜⌒／ヽ-、_＿_
／(_/＿＿＿＿／ 　　　　　　　／＜_/＿＿＿＿／

それバールだったんかｗ

「バールのようなもの」だ。

さあ盛り上がってまいりました

指定範囲のWORDをひたすらOR取りたいんだけど思いのほか処理が重い
・DWORDでor取って最後にWORDでor
・or eax,[edi];をmovとorに分解してレジスタをたらいまわしにしてペアリング
しか方法が無いのかな？

こう？
for (i = range_begin; i < range_end; i ++) sum |= array[i];


しかし今時ペアリングとかPentium1ですか？


もっとモダンなアーキテクチャならMMX/SSE*が使えるでしょ
por xmm0, [edi]で8並列だ。
16バイト境界にあってる部分だけね

宿題丸投げスレはここじゃないよ

それこそ prefetch が使えるんじゃない？ SSE で十分かな

>>788
思いのほか重いってのは、どの程度の帯域を期待してて実測はどの程度ってこと？

動画のフィルタとか書いてて、そういうごく単純なシーケンシャルなメモリ
アクセスを伴う処理ではとても良い性能が出るのにびっくりした記憶があるな。
DDR2 って速いんだな、と。

>>789
残念なことに使用しているインラインアセンブラがMMX非対応なんですよ

将来的には対応させたいってのがあって、MMXも調べてはいたんですが
mov xmm0,[edi];ができないって聞いていたんでかえって遅くなると
思い込んでいたんですが、por xmm0,[edi];なら問題無いのですね
納得しました

>>792
自分はV30,V33時代にしかx86を触っていなかったんで、最近のCPUなら
超強力なストリングス命令が豊富だと思い込んでいたんです
それこそmovesdのor版とか・・・
仕方なしにor r,mで回すとクロック通りの帯域しか出ていなくって
ペアリングするとPentiumらしい速度になって目から鱗。
MMX,SSEもメモリから直接読み込めないんじゃ机上の空論だな・・・
とこれ以上の高速化を諦めていたんです。

MMXも触ってみたいんで開発環境を見直して見ます
長文失礼しました

>>793
「インラインアセンブラが」非対応ってよく分からんな。
アセンブラが非対応なら手でバイナリを直接書けばいいんじゃね？

> 自分はV30,V33時代にしかx86を触っていなかったんで、最近のCPUなら
> 超強力なストリングス命令が豊富だと思い込んでいたんです

ストリング命令なんていまどきはやらねぇっすよ。
内部でマイクロコードがシコシコ動くからかえって遅くなることもあるぐらい。

機械語は高級命令で、CPUの中にコンパイラがあるような現在では
ストリングス命令みたいのを使って抽象化した方が最適になる時代が来るかも知れない。
GPUが既にそんな感じか。

>>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になった。

漏れはこういうときって

or eax,[edi]
or ebx,[edi+4]
or eax,[edi+8]
or ebx,[edi+12]

てな感じで依存関係を遠ざけたコード書いてるけど、
最近の CPU だと意味あるのかなぁ。

インラインアセンブラの問題か。
emit文が使えればどうにでもなるんでない？

あるいは
rep por mm0, [edi]

で頭に 66hがついたり。

>>797
LUが2基あるAMDアーキならスループット1クロックに2命令ずつ処理できる。

Intelは1load/clkなんで無意味。

無料開発環境で済ますならVisual C++2008 Expressでいいんでないの。
64ビットもSSE4も使えます。

最近のVCはANSI以前の関数引数形式が使えなくなってるので注意。

あと、movdquでのロードだけど、Core 2以降についてはそんなに遅くない。

連続した領域に対するロードは内部的にpalignrを使って補正してる。

>>797
ああ、忘れてた。orを取る順番は関係ないからそうするべきだね。
ちょっと測定してみたが、クロック数は変わらないようだ。
or処理はレイテンシが1で軽いからだろう。

>>799
まあ、気持ち気持ち。
できるだけ軽くしておくと、いいことあるよ。

>>793です

>具体的な方法とCPU名を教えてくださいまし。
開発環境はAthlonXPとAthlon64 X2です

>>797
私が実際に使用しているコードもそれと同じです。
一応の最適解と考えて良いのかな？

>>799
P5以降はV,U２基だと思っていたんですが、P5だけなのかな？

>>803
LU = Load Unit

>>803
P5はVパイプとUパイプで同時にload可能だったが、
P6以降はloadは専用パイプ1本のみに退化した。

逆にP5までは命令の並べ替えができないから、利用頻度の高いロードを
両方に持つことで効率低下を防いでる感じかな。
P6以降はLoad+Storeは同時実行できるので特別困らん。

P5までの知識ってのはAgnerの翻訳記事かな？
できれば最近の原本も読まれることをお勧めする。

IntelはP6以降は結構ドラスティックに変化してる。
逆にAMDはK7以降はゆっくり変化してる印象。