07/01/10 12:32:46
ゆるゆる～っと実測していきましょう。
過去ログ
x86命令の所要クロック計測スレPart2
ｽﾚﾘﾝｸ(tech板)l50
x86命令の所要クロック計測スレ
ｽﾚﾘﾝｸ(tech板)l50
関連スレ
アセンブラ… (゜□゜) ↑アッー！↓
ｽﾚﾘﾝｸ(tech板)l50
MMX SSE 3D NOW!のプログラミング
ｽﾚﾘﾝｸ(tech板)l50
CPUアーキテクチャについて語れ 5
ｽﾚﾘﾝｸ(jisaku板)l50
【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】
ｽﾚﾘﾝｸ(notepc板)l50
もしくは、自作板にて「次世代」でスレタイ検索
まとめサイト（過去ログ置き場）
URLﾘﾝｸ(www.wikihouse.com)
2:1 ◆.MeromIYCE
07/01/10 12:33:18
関連サイト（日本語）
コピペで動くVC++のインラインアセンブラ例
URLﾘﾝｸ(www.fides.dti.ne.jp)
基本的な整数命令/スタックの使い方
URLﾘﾝｸ(ray.sakura.ne.jp)
FPUやMMX,SSEの命令解説など。最適化の色々な話がある
URLﾘﾝｸ(homepage1.nifty.com)
pentopt（古）の日本語訳など
URLﾘﾝｸ(hp.vector.co.jp)
Intelの日本語技術資料のダウンロード
URLﾘﾝｸ(www.intel.com)
関連サイト（英語）
Intelの最適化マニュアル（Core2についても載ってる）
URLﾘﾝｸ(developer.intel.com)
Software Optimization Guide for AMD64 Processors
URLﾘﾝｸ(www.amd.com)
Intel向け最適化手法やクロックテーブル、testp.zipで手軽にrdpmcが使える
URLﾘﾝｸ(www.agner.org)
各CPUのレイテンシ-スループットの表（K7K8あり）
URLﾘﾝｸ(swox.com)
x86CPUの各種データシート
URLﾘﾝｸ(www.sandpile.org)
AMD CodeAnalyst Performance Analyzer、AMD用パイプラインの様子がわかるシミュレータ
URLﾘﾝｸ(developer.amd.com)
CPU関係の記事が読めるかもしれない場所
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(www.geocities.jp)
URLﾘﾝｸ(mypage.odn.ne.jp)
3:デフォルトの名無しさん
07/01/10 14:51:35
ヽ / /⌒＼
／ヽヽ|/⌒＼ii|＼
／ ／ヾゞ//／＼＼|
|／ |;;;;;;|/ハ ＼|
|;;;;/／⌒ヽ
|;/（ ＾ω＾） >>1おっおっおっ乙枯ー
. |｛ ∪ ∪
|;;ヾ.,____,ノ
|;;; |
|;;;;;|
|;;;;;|
4:デフォルトの名無しさん
07/01/10 16:41:55
>>1
STARGA乙ERS
5:1 ◆.MeromIYCE
07/01/11 13:23:52
前スレ埋まりました。
6:デフォルトの名無しさん
07/01/11 21:01:08
GJ!
7:デフォルトの名無しさん
07/01/12 16:01:16
2ch閉鎖したらどーすんの？
8:デフォルトの名無しさん
07/01/13 00:37:09
大原が入稿してからついに一週間経つのにまだ掲載されてないなんて
サボりすぎってレベルじゃねーぞ
9:・∀・）っ-○◎● ◆DanGorION6
07/01/14 02:32:10
珍しいなム板で500KB制限って
ただでさえ長文とソースコードの多いスレだけど
10:デフォルトの名無しさん
07/01/14 21:51:15
第189回 Core MicroArchitectureをもうすこし(13)
URLﾘﾝｸ(journal.mycom.co.jp)
やっと5日入稿分が来たよ
相変わらずこのスレ見てるな
11:デフォルトの名無しさん
07/01/14 22:00:42
このスレとは関係ないけど
> 例えば昨年のComputexでMobile向け新コアの説明がちょっとあったが、Memory Controllerと
> Hyper Transport Linkのみがモバイルに最適化されたという話で、コアそのものはK8L(というか、
> Revision H世代?)と共通になってゆく模様だ。
そのリンク先を見る限りモバイル向けコアはK8Lとは違うように見えるのだが…
12:デフォルトの名無しさん
07/01/14 23:17:12
サーバーを意識した設計だがRASは無い
13:1 ◆.MeromIYCE
07/01/14 23:38:58
俺はnopは実行ユニット使ってると思っていた。そこで実験。Dothanで。
結果は大体見えるけど、初心忘るべからずってことで生真面目にやってみますね。
ループ回数は1000回、10000回で測定。場合に応じて回数を変化させて傾向を見る。
lp:
and edx,edx
dec eax
jnz lp
これはキッカリ1.5clk/loop。
lp:
xchg eax,eax ; nopと書くのと同じマシン語になる
dec eax ; ここをecxに変えても所要クロックは全く同じ
jnz lp
これは1.56clk/loop程度。なぜちょっとだけ遅いのだ。
nopが遅いってことではなくて、loopが整数クロックでない複雑さが影響している感じ？
もっとも、2clk未満なのでnopとdec eaxに依存関係がないのはわかった。
（ていうかnopを連続させるベンチを見れば、nop同士にも依存関係がないのは明らか）
たぶん、nop命令は同時使用レジスタ数とかのシバリとかも関係ないだろう。
（普通のxchg命令はレイテンシが2clkと遅いので計測からはよくわからなかった）
14:1 ◆.MeromIYCE
07/01/14 23:40:26
lp:
nop
nop
mov eax,[esi]
dec ecx
jnz lp
これは2.0clk/loopで回る。
lp:
nop
nop
and eax,eax
dec ecx
jnz lp
こっちは2.6clk/loop。nopがALU（Dothanでは2個）を使っているのがわかる。
1loopでALUを5回使うので、必ず2.5clk以上かかるのだ。
nopは、命令ポインタであるeipの値を1増やす以外何もしない命令だが、
CPU内での扱いで言うと、レイテンシ1・スループット1の命令としてALUを1個使うが、
その他スケジュールなどでの制限事項には引っかからないタチのいい1byte命令、
という感じで、これは他のCPUでも同じじゃないかな。
クロック計測の観点から言えば、「実行する」と表現した方がわかりやすいと思う。
この辺は言葉の問題なので、適宜使い分け。
15:1 ◆.MeromIYCE
07/01/17 18:51:26
IA32 x86 JITアセンブラ Xbyak
URLﾘﾝｸ(homepage1.nifty.com)
動的アセンブル。なかなか使いやすそう。
mov(ecx, n); などと関数にしてしまう実装が面白い。
でも、いざ使おうと思うと、何に使ったらいいかわからないな。
自己書き換えよりは安全でスマートな方法だが、
定数部分の自己書き換えの範疇を超えた使い方があれば面白い。
16:デフォルトの名無しさん
07/01/17 20:48:36
計算式や正規表現のようなユーザから来る可変な表現からプログラムを生成。
17:デフォルトの名無しさん
07/01/18 03:40:29
Cの関数のような表記のアセンブラといえば、CELLのもそうじゃなかったっけ?
#つーか、あれは関数表記のインラインアセンブラなのかも知らんが。
18:デフォルトの名無しさん
07/01/18 03:59:06
そりゃIntrinsicsじゃないのか？
URLﾘﾝｸ(en.wikipedia.org)
VC++のMMX/SSE対応とか。
19:・∀・）っ-○◎● ◆DanGorION6
07/01/18 06:52:49
あれはもともとIntelコンパイラの組み込み関数
CellのはCode WarriorのAltiVec拡張と同じ構文ルールだが
あちらは「演算子」なんだな。
Cで「関数」のオーバーライドはサポートしてないはずだ。
たとえばvec_addもしくはspu_addはvector int とvector shortでは別の操作になる
20:1 ◆.MeromIYCE
07/01/18 23:53:42
>>16
正規表現か。難しそうだな。
結局、定数書き換え以上のことやろうとすると、コンパイラみたいなのを
自作してプログラムに入れないといけないんだよな。
ぶっちゃけ定数埋め込みだけでも意義は大きいと思うし、
最後に0.99をかける処理をする/しないの選択みたいな要素が8個あれば
高速化を考えれば普通なら256通りのコードを用意する必要があるわけだから、
そういうのに使ってもいい。
>>17
べつにmov(ecx, n); でmov ecx, n を実行するわけじゃなくて、
将来実行するコードにmov ecx, n のマシン語を追加しているのだ。
単なる表記法の話とは違う。
21:デフォルトの名無しさん
07/01/19 00:23:01
>20
callが並べられれば既に最適化されている一連の関数をどういった順序で、ないし、どういったパラメータで呼ぶかが決められる。
比較処理の削減、BTBの節約程度にしかならんがな。
22:・∀・）っ-○◎● ◆DanGorION6
07/01/19 00:53:26
正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ
（言語処理系だとHaskellとかに使われてるね）
現実には後方参照とか量指定とかのリッチな機能使いたがるから
一意に定まる部分文字列をBoyer-Moore法などを用いて先行して評価し
NFAを評価するほうが主流なんだよな
これは鬼車なんかが使ってる。
自己書き換えでNFAのバックトラッキングを高速に処理するとかできれば
理想だけど、まあ無理だ罠。
とにかくメモリレイテンシが重要。
＃投機スレッディングが有効かと思ったり
23:デフォルトの名無しさん
07/01/21 01:38:34
第190回 Core MicroArchitectureをもうすこし
URLﾘﾝｸ(journal.mycom.co.jp)
24:・∀・）っ-○◎● ◆DanGorION6
07/01/21 03:07:36
> そうなると、そうすると
もちつけｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
最近仕事が粗いな
つーか、リオーダバッファが96エントリもあれば局所的なユニット不足って
十分解消できると思うんだがね俺の考えでは
ROBを深くしてロード命令を先行して実行してれば
たいがいのコードって
つーか、リオーダバッファが96エントリもあれば局所的なロードユニット不足って
十分解消できると思うんだがね
そのためにMemory disambiguationがある。
ストア命令が一個もないループなんぞ【逸】般的でしかない。
64bitではSSE2までは標準命令セットだから、そのへんの実行効率についても
検証していただきたいところだね。
25:・∀・）っ-○◎● ◆DanGorION6
07/01/21 03:21:32
俺くどいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
26:デフォルトの名無しさん
07/01/21 04:13:03
URLﾘﾝｸ(journal.mycom.co.jp)
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の差があるので、
あたらずも遠からずかな。
27:デフォルトの名無しさん
07/01/21 04:15:27
つづき
URLﾘﾝｸ(journal.mycom.co.jp)
これと同じことを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倍に達することになるが。
長々と書いたが、半分大原氏に向けて書いたつもり。
ここをみてる様だから。
参考文献
URLﾘﾝｸ(www.sandpile.org)
28:デフォルトの名無しさん
07/01/21 07:39:11
大原なんてどうでも良い
もちっと突っ込んだ話に進めよう
29:・∀・）っ-○◎● ◆DanGorION6
07/01/21 12:48:50
「モノ書くってレベルじゃねーぞ」
30:デフォルトの名無しさん
07/01/21 14:47:40
大原氏の検証が正しいどうかかわからないが、Core2のトランジスタ数が少ないのは事実であろう。いずれにせよ、Core2のトランジスタ効率はかなり良い。
K8の60-70%程度の演算パイプライントランジスタ数で、120％の性能を発揮しているのだから。
遡れば、K7 2200万トランジスタに対して、Pen3 950万トランジスタで、クロック当たり性能がほぼ互角だったのだから、AMDのアーキテクチャーには無駄が多いのかもな。
K8のブロック図を見ても
コンプレックスデコーダー*3
対称型ALU*3
AGU*3
馬鹿正直設計と言えるかもしれない。
31:・∀・）っ-○◎● ◆DanGorION6
07/01/21 15:12:30
その上整数パイプラインとFP/SIMDパイプラインに分かれてる。
32:デフォルトの名無しさん
07/01/21 15:26:22
その代わりK8はスレッド数が増えても急激な性能の低下はないね。
Core2はコア数×2スレッド以上になると急に遅くなる。
33:デフォルトの名無しさん
07/01/21 15:29:39
ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、
具体的にどれくらい?
34:・∀・）っ-○◎● ◆DanGorION6
07/01/21 15:34:56
単純に1スレッドだけだと2MB～4MBのキャッシュを占有できるからじゃないの？
なにが原因があるのかは知らないが
コンテクストスイッチングに弱点があるとして
HyperThreadingとマルチコア化で同時処理スレッド数を稼ぐ方針だから
差し引きオッケーになるんじゃねーの
35:デフォルトの名無しさん
07/01/21 15:52:36
Intelの共有キャッシュ = 再構成可能キャッシュ
36:デフォルトの名無しさん
07/01/21 15:59:52
そうだね。
黙っててもマルチコア化は進んでいくわけだから、シングルスレッド強化のほうが、むしろ理にかなってるとも言える。
また、1コア当たりのトランジスタ数を抑える方が、コアを増やす上で、これまた理にかなっているだろう。
K8Lは、さらに1コア当たりのトランジスタ数を増やすようであるが、
面積で言えば、20％ほど増える。単純計算では5000万トランジスタぐらいか。
K8 5000万対Core2 2870万で互角以上なら、多少のマイナスも問題ないだろうし、
さらに5000万対2870万 x2コアって戦い方も出来る。
37:デフォルトの名無しさん
07/01/21 16:08:42
何言ってんの？K8といえば今やX2だろう。
38:1 ◆.MeromIYCE
07/01/21 23:32:22
>>23
4issueのCPUで演算パイプラインが常時IPC4で回るとかあり得ないのは
当然のことだと思うのだが、意図的に間違えてるのか？
そういう意味じゃCore2もK8もIPC3すら全く達成できてない/する気がない。
それとは別に、パイプラインを3→4に強化すれば高速化するのは間違いない。
その高速化に対して、IPC4+のケースがあることも、そうじゃないことも貢献している。
その他色々な強化を積み重ねて、Core2はあのスピードを手に入れたのだ。
K8だってCore2だって、IPCが1.4のところを1.5にしようと必死に頑張って作ったはず。
あと、俺はむしろK8の演算器（(ALU+L/S)*3）が過剰でバランスが悪いと感じる。
もっとも、これがK8のパワーの源だとも思うし、実際にはそう悪くないのだろう。
よく言われることだけど、ALUが過剰とかキャッシュだけ多いとかいうのは
設計思想の違いで、どちらが良い悪いというものではない。
バランスが悪いとダメだけど、K8やCore2がそこまでバランスが悪いとは思わない。
ところで、大原さんは別にCore2を貶してるわけじゃないんだよね。
ただ、「Core2は（x86命令で）IPC4を狙った設計ではない」と主張してるだけで、
4issueは無駄だとか、K8より性能が劣るとか、設計が悪いとかは、言ってない。
なぜそう主張したいのかが、さっぱりわからないんだけど。
今度のK8Lは、「より確実にIPC3を出し続けることを狙ったCPU」だと思う。
このK8Lと、「IPC4を狙ってデコード・スケジュールでつまづく」Core2の戦いは楽しみだ。
39:・∀・）っ-○◎● ◆DanGorION6
07/01/21 23:37:33
K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを
K8Lではディスパッチ後にデコードするようになってる。
このへんってどんな効果あるんだろ
40:1 ◆.MeromIYCE
07/01/21 23:51:02
>>39
SIMDの方にディスパッチしてから64bit単位で命令を解釈し、
ある程度トランジスタを割いてうまくスケジュールして、
同じピークSIMD性能のCore2を超える実性能を叩き出す、
というのが俺の希望だが、実際どうだろね。
ディスパッチ前の命令の単位が64bitから128bitに変わったことが
影響していると考えていいと思うけど。
41:デフォルトの名無しさん
07/01/21 23:54:41
そそ、Intel processorが特別ピーキーで(絶妙な)設計なだよなー（・∀・）
AMDに限らず、RISC processorでも馬鹿正直といったら失礼だけど、大雑把なつくりのがおおいし。
Intel processorは、伝統的に速くなるところはそれだけ投資するし、速くならないところは細部でも積極的にケチる。
社内で実プログラムの動作が研究し尽くされていて、開発能力に余裕がなければできない芸当。
decode BWみたいに局所計測系benchmarkの単調な命令の羅列ではまったく実力がわからん。
Intel processorは、いつも公開されるarchitecture的なspecから予想されるよりも実性能が高い。
これはcompilerの出来だけの問題ではない。
あと、大原はIPCという言葉の使い方がよろしくない。
IPC xxを狙ったarchitectureという考えをそもそも捨て去らないと…。
実効3IPCや4IPCなんて最初から誰も考えちゃいないのに。
42:デフォルトの名無しさん
07/01/22 02:02:48
Intelerお久
43:デフォルトの名無しさん
07/01/22 03:57:13
どこが優っていて、どこが劣っているとか、
それは最終的には関係なく、結果叩きだされる性能が指標なわけで…
最近のベンチマーク結果にメモリ帯域とか、レイテンシ計測が出てくる不思議さ。
なんというか、100M決勝で10M加速を比べられているような…
IPCもその意味をなすことが今後は難しいんじゃないですかね?
大原記事はこれから読むw
44:デフォルトの名無しさん
07/01/22 04:25:04
読んだ。
AMDのCPUは実行IPC3で常に回っていて(脳内or観測的希望)
intelのCPUはIPC4を謳ってい入るがそんなわけねーよ(AMD比)pgr、ということなのか…
瞬間風速だとしても、それを出せない回路でその数字を謳うのはある種詐欺なわけで、
たとえ一瞬だとしてもそれが出せることは大いに喜ぶべきことなのでは?
(その宣伝を気に入る、気に入らないという話ではないこと前提でｗ)
それを意識するあまり平均性能が落ちるとかならいざ知らず、
ほとんどのベンチマークで勝っているわけで、without メモリコントローラ。
45:デフォルトの名無しさん
07/01/22 10:40:18
おはようございます。
なんだよ、観測的希望ってw
やっぱり眠い時レスしちゃダメなんですね。
大原氏ごめんね。
46:1 ◆.MeromIYCE
07/01/22 14:20:45
>>43
論旨には賛同するが、メモリ帯域やレイテンシ計測は是非やって欲しいよ。
もちろん、そういう計測をそのままCPUの性能と思ってしまうのは論外だが、
「自分はこの処理をさせたいが、どのCPUがいいだろう？」と思ったときに
一般アプリの実性能ベンチだけではイマイチ検討のしようがない。
まあ、こういうのは最近の流行りじゃないんだろうねぇ。
確かに俺も、とりあえず帯域ベンチやっときましたみたいな記事を見ると、
色々誤解が広まりそうで嫌な感じはする。
47:デフォルトの名無しさん
07/01/22 17:20:36
CPUの性能を調べることと素性を調べることの差って感じか
48:デフォルトの名無しさん
07/01/22 17:55:49
周波数特性だけで盲目的に音質を語るな
49:1 ◆.MeromIYCE
07/01/22 19:03:17
>>47
そうだね。
あと、ベンチって結果から製品を選ぶのが目的と見せかけて
むしろ好奇心を満たすものという面が大きい。
性能より素性を知りたい人が少ないってのが寂しい。
>>48
そういう意味じゃ、CPUは速いのが正義だから、まだ簡単だ。
MP3とACCの比較とか、ありゃあ泥沼になるわけだ。
50:デフォルトの名無しさん
07/01/22 19:32:31
マルチコアはいつから使えるコアになるのか？
URLﾘﾝｸ(www.ne.jp)
51:1 ◆.MeromIYCE
07/01/22 20:12:17
>>50
実際にどっちを買うべきかという話ではなくて、CPUメーカーがシングルコア路線を続けた方が
動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話だね。
結局、俺は使ったことがないからわからないんだよな。
それに、Pen4からCore2Duoに乗り換えた人は、
Coreアーキだから速いのか、デュアルコアだから速いのか、Pen4が遅かっただけなのか、
何が原因だか容易には知ることができないだろう。
俺は前から、体感したYonahの速さからデュアルコアをすすめる人の多くが、
CoreSoloでも同じ速さを感じるのではないかと思っていたが、これも確かめるのが難しい。
一方、Intelとすれば、シングルでも非常に高速なYonahやConroeで
デュアルコアをスタートさせたため、商売としては成功したと言えるだろう。
（いや、ネトバのデュアルはスタート以前というか・・・それでもエンコは強かった）
52:デフォルトの名無しさん
07/01/22 20:47:04
>CPUメーカーがシングルコア路線を続けた方が動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話
IntelはメニーコアのマイルストーンとしてAdaptability(適応性)ってのを挙げてる。
シングルコア強化路線「だけ」ではムーアの法則に追随できないから、
まず前提としてシングルスレッド性能の強化があって、
その開発期間の隙間を埋めるのがコアの増加なんだと思う。
例えばDMTなんか65nmに微細化した今でも実装されてないし。
53:1 ◆.MeromIYCE
07/01/22 21:27:29
>>52
AdaptabilityやDMTの意味がわからないが、
前提となるコストと熱設計の中で最も性能の高いものを作るだけじゃないの？
開発期間の隙間と言っても、開発が済んだらコアを減らすわけでもないだろうし。
54:デフォルトの名無しさん
07/01/23 01:46:26
Speculative MultiThreadingによってILPの壁を突き破れるようになるまで
シングル、マルチを無駄に意識させられるんだと思われ。
ILPを挙げるのに、これ以上トランジスタと電力に投資するのが非効率だから
TLPを意識しましょうっていうのは実際逃げだろうけど、
タイタニックじゃないけど、逃げなきゃいけない状況(それ以上の解が見つからない状況)なのに
意固地に頑張る必要もないはず。
メモリレイテンシの隠蔽の効果が、めいっぱい頑張ったシングルコアを超えずとも
良い勝負かつ、より低消費電力ならそっちが正解だと思う。
そういう点から、例え現状しょうがなく目指したとしても、
むこうに今よりもbetterな解があるならそれで良いジャマイカ派。
55:デフォルトの名無しさん
07/01/23 02:29:49
SpMTが高めるのはMLPだ。
"ILPの壁を突き破る"という表現はおかしい。
56:デフォルトの名無しさん
07/01/23 04:35:11
ILPという言葉に関しては、一つのスレッドに対して使う言葉なのかな。
並列性の高まるスレッドが別であることに対しては無効であるなら認識不足だった。
勉強になります。
URLﾘﾝｸ(ja.wikipedia.org)
これ読む限りじゃ、投機実行もILPを高める手法の一つにはカウントされてる模様。
57:1 ◆.MeromIYCE
07/01/23 16:12:57
>>56
> Speculative MultiThreadingによってILPの壁を突き破れるようになる
の「ILPの壁」というのは、「シングルスレッド処理のIPC向上の壁」と言えばいいんじゃない？
ILPと言うと、メモリ以外の命令同士の依存関係を何とかするみたいな感じを受けるから。
＃メモリアクセスもI（命令）だと言われればそうだけど。
俺は、メモリ以外のILPの問題の方が本質的だと思うので、ここではILPという言葉は使わない。
手動でプリフェッチすれば同等の性能が出るであろう技術には個人的に萌えない。
しかし、SpMTによって、手動でprefetch命令を入れたのに匹敵する効果が得られるなら、
これこそプログラマに優しい、「逃げない」技術なのかもしれないとも思った。
> 投機実行
それは、文脈からして条件分岐命令に対する投機実行のことだから、
投機的マルチスレッディングとは関係ないと思われる。
>>54
逃げなきゃいけない状況なら逃げないといけないね。
何事もバランス、中庸。
>>53ではああ言ったが、最後の2行は同意。単純に対応ソフトの普及促進にもなるし。
58:デフォルトの名無しさん
07/01/23 19:59:29
AMD Rev.F Processor には、RDTSCPという命令が追加されているらしいな
URLﾘﾝｸ(www.atmarkit.co.jp)
59:デフォルトの名無しさん
07/01/27 19:25:36
>>27
URLﾘﾝｸ(journal.mycom.co.jp)
Coppermine 1394万
Banias 2038万
Dothan 2676万
Yonah 1918+1918万
60:・∀・）っ-○◎● ◆DanGorION6
07/01/27 21:07:17
大腹自身の記事かよｗ
61:デフォルトの名無しさん
07/01/28 00:54:47
>>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トランジスタで作っているか、公式発表の数字がうそか、どちらかだろう。
62:・∀・）っ-○◎● ◆DanGorION6
07/01/28 01:05:20
Pentium Mは4トランジスタじゃなかったっけ
ってソースがこれだったｗｗｗｗ
URLﾘﾝｸ(journal.mycom.co.jp)
大原氏は記事書く際はちゃんとウラを取って欲しいな
63:デフォルトの名無しさん
07/01/28 16:02:55
まあ大原もここのスレ住人も、ほとんどが確たるウラをとらずに好き
放題発言しているだけだけどな。５０歩１００歩じゃねーか？
ソースを張っても、そのソースが本当に正しいかウラが取れてるわけ
じゃない場合が多いし。ソースが大原記事なんてのがその典型ｗ
64:デフォルトの名無しさん
07/01/28 17:27:01
PenMが4トランジスタSRAMってのは間違い。
大原自身が訂正してたよ。
6トランジスタです。
65:デフォルトの名無しさん
07/01/28 17:29:57
そろそろclock計測の話題に戻ろうよ。
ここは実験と実証のスレで、理屈と情報、妄想だけのスレなんて他所にたくさんあるわけだし。
66:・∀・）っ-○◎● ◆DanGorION6
07/01/28 18:13:52
素人が個人ブログや掲示板に自己満足記事投稿するのと
企業から金貰って大衆に読んで貰うための記事をかくのと
全然影響力・説得力が違うがね。
67:デフォルトの名無しさん
07/01/28 18:36:11
クロック数計測してもTr数はわからんし。
―大事なのは素材ではなくその精神なのです。
68:デフォルトの名無しさん
07/01/28 18:49:20
>>66
大企業メディアの情報の質、正確性、量、速度が
個人サイトの集合を上回っているとはいえなくなりつつある
ネット社会の現代、こういうライター稼業のなんてもう流行らないのかも。
しかし、それにしても国内のハードウエアレビューは質が低い。
AnandTechやTom's, INQなどは個人サイトが反映しても死ぬ気がしないんだけど、
国内ではそのような優良サイトがない。情報も一方的だし、ライターの記事は情報が少なく、遅い。
69:デフォルトの名無しさん
07/01/28 22:35:46
この計算はあってるの？
URLﾘﾝｸ(www.anandtech.com)
If we assume that 288M transistors (6T SRAM) will be used by the 6MB cache,
that leaves 122M transistors for L1 cache and the rest of the core.
Applying the same calculation to Conroe gives us 99M transistors left over,
meaning that there are roughly 23% more core-logic,
control and L1 transistors being used in Penryn than in Conroe.
70:デフォルトの名無しさん
07/01/28 23:07:10
第191回 Core MicroArchitectureをもうすこし(15)
URLﾘﾝｸ(journal.mycom.co.jp)
71:デフォルトの名無しさん
07/01/29 02:38:23
>>70
なんかどうみても、これスレを読んでいて、且つこのスレに対して
言い訳してるようにしか読めないな。
大原氏には悪いけど。
72:デフォルトの名無しさん
07/01/29 02:50:03
>>70
話の持っていきかたの無理矢理感が・・・・・
73:・∀・）っ-○◎● ◆DanGorION6
07/01/29 02:59:02
どんな下手な書き方してもIPC=3を出せるハードという意味なら永久に無理に決まってる。
ソフト側も「IPC=3を出せるコード」であることが前提。
74:デフォルトの名無しさん
07/01/29 03:14:52
そこでEPIC
75:・∀・）っ-○◎● ◆DanGorION6
07/01/29 03:45:05
4IPCを狙ったアーキじゃないって論は云々はどっちかというと
この人の記事を読んで真に受けただけじゃなかろうか
URLﾘﾝｸ(www.ne.jp)
別に ALU+Load, ALU, ALU, Store
もしくは ALU, ALU, ALU, Load or Store
でもx86換算4命令になるわけだがな。
インオーダで実行するわけじゃないんだから、3IPC以上出せないというのは
大きな間違いだよね。
従来のアーキテクチャではストア命令が来る度に、格納先が確定するまで
後続のロードとそれに依存する命令を発行できないという縛りがあるわけで、
レジスタが少なくロードストア頻度の高いx86でIPC=3を実現する上で大きな縛りになってる。
Core 2で導入されたMemory Disambiguationはそのへんを解決してる。
大原氏はCore 2で平均IPCを引き上げるためのその辺の機構を正当に見てない希ガス。
安藤壽茂氏なんかの記事はちゃんとそのへんも触れてる。
76:Store forwarding
07/01/29 06:45:21
キャッシュラインサイズが256Bというのもその辺考えてるのかもな。
77:デフォルトの名無しさん
07/01/29 17:55:37
>>76
キャッシュラインサイズが256Bって何？
78:デフォルトの名無しさん
07/01/29 20:47:10
P6,Netburstでは、unknown store-addressがあってもそれ以降の別のストアはアドレス計算できれば発行可能。
またunknown load-addressがあってもそれ以降の(アドレス計算可能な)ロードやストアは発行可能。
唯一できなかったパターンがunknown store-address以降の(アドレス計算可能な)ロード発行で、
これはCore 2で可能になった。
これに対してK7,K8では、unknown store-addresがあるとそれ以降のロードやストアは発行できない。
またunknown load-addressがあってもそれ以降のロードやストアを発行できない。
ロードやストアのAGU命令はインオーダー発行になっているようだ。
K8Lでロードのアウトオブオーダー発行が実装されるが、
どの程度のアウトオブオーダーなのか、またそれによってどの程度性能が向上するのか、
楽しみではある。
計測情報源：URLﾘﾝｸ(www.realworldtech.com)
79:デフォルトの名無しさん
07/01/30 05:36:05
今回のは何を言いたいのかさっぱい伝わってこないのだが…
これなら昔の電波の方がよっぽど読み応えがあったｗ
80:デフォルトの名無しさん
07/01/31 20:10:09
URLﾘﾝｸ(pc.watch.impress.co.jp)
これらのプロセッサでは、Coreマイクロアーキテクチャとしては初めて
Hyper-Threading Technology(HTテクノロジ)をサポートすることになる
81:デフォルトの名無しさん
07/01/31 22:45:47
Penryn does not have HT
URLﾘﾝｸ(www.theinquirer.net)
82:デフォルトの名無しさん
07/02/01 02:07:56
URLﾘﾝｸ(grape.astron.s.u-tokyo.ac.jp)
むーん、オールジャパンってそういう話か、というか、それはそうなん だけど、そんなので計算機作れるのかよ、、、
83:デフォルトの名無しさん
07/02/01 04:32:35
Vista 64bit版も出た事だし、そろそろx86-64の話題が欲しいですね。
スレ違いか？
84:・∀・）っ-○◎● ◆DanGorION6
07/02/04 15:21:39
URLﾘﾝｸ(www.anandtech.com)
Penrynはdual coreだ。そしてquad coreはただそれらを二つパッケージに封入しただけだ。
ただ、あとからシングルダイの製品が登場するかもしれない。
トランジスタ数が4億1000万なので、Penrynが6MBの共有L2 cacheを持つと予想できる。
Penrynのロジック部はConroeの進化形になるだろう。
キャッシュの増量分以上の機能的・性能的追加が期待できる。
2億8800万トランジスタが6T-SRAMの共有L2キャッシュに利用されているとすれば
残り1億2200万トランジスタはL1キャッシュとコアに費やされていることになる。
同じ計算をConroeに適用すると、9千9百万のトランジスタがコアとL1 cacheに割り当てられている。
これらの事実はPenrynではConroeと比較して23%多いトランジスタがL1 cache, 論理, 制御に
使用されるのを意味する。
追加される機能が不明である現時点でさえ、SSE4のサポートがそれらのトランジスタの
かなりの部分を占めると予想するだろう。またIntelが45nmでクロックを上げるので
Penrynが3GHzよりも高いクロックで登場するのを容易に予想できる。
Conroeのオーバークロック耐性を考えると、Penrynのクロックが非常に良いのを見ても
そんなに驚かないだろう。
85:デフォルトの名無しさん
07/02/04 22:47:06
第192回 Core MicroArchitectureをもうすこし(16)
URLﾘﾝｸ(journal.mycom.co.jp)
86:・∀・）っ-○◎● ◆DanGorION6
07/02/04 22:57:40
ま た 2 ち ゃ ん ソ ー ス か
87:デフォルトの名無しさん
07/02/04 23:13:12
> Penrynの世代でHyper-Threadingが搭載されるという。
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ
88:デフォルトの名無しさん
07/02/05 00:31:26
今回のこれは大原を弄るのは酷かもな…
ネタの正確性はともかく言ってること自体は間違ってないというか、同意できる
つーかYorkfieldの中身が変更されたと判明した後もガセネタ流し続けたCharlie Demerjianは死ねｗ
89:デフォルトの名無しさん
07/02/05 01:17:24
409 ：名称未設定 ：2007/02/02(金) 17:22:28 ID:I0BGTsMO0
URLﾘﾝｸ(journal.mycom.co.jp)
URLﾘﾝｸ(journal.mycom.co.jp)
生ハムメロンワロスｗ
90:デフォルトの名無しさん
07/02/05 01:42:10
つーか、なんか論点がずれてるというか、大雑把な主張になってきたな。
もともとIPC=3を技術的に細かく検証しているはずだった気がするが、
いつのまにか
「発熱や消費電力が上がる関係でIPC=3は無理です」
になってる。
なら最初からそう言って終わっとけば良かった気がするが…
91:デフォルトの名無しさん
07/02/05 01:59:27
このシリーズはいつまで続くんじゃー！
92:デフォルトの名無しさん
07/02/05 02:05:06
Core2がIPC=4じゃないとする主張の理由の中に
K8がIPC=3であると思わせる部分がある時点で
大原記事wwwとなるのは明白。
93:デフォルトの名無しさん
07/02/05 04:56:57
元々はCoreMAとK8のIPC向上に対するアプローチの違いを言いたかったような気がするが。
細かく突っ込んでいって逆に全体像が見えなくなった感じだな。
94:1 ◆.MeromIYCE
07/02/05 19:11:14
>>89
Meromと果物のmelonをかけてるのだろうか？
Penrynに、L2キャッシュ増量とSSE4実装以外の目立った改善があるのか気になるね。
遅くなるプリフィックスと64bitでのマクロフュージョン、シャッフル系SSE命令などが考えられる。
まあ、このうち１つも対応されない可能性も大きいとは思うが。
命令フェッチ幅を32byteにするのはいずれ必要だけど、Penrynの次のアーキ辺りが妥当か。
95:デフォルトの名無しさん
07/02/05 19:14:56
Windows生ハム
96:デフォルトの名無しさん
07/02/05 22:51:33
AMDの方は L3キャッシュだろ。もうどうなる事やら。
97:デフォルトの名無しさん
07/02/06 00:03:52
トランジスタ増やしすぎたらいくら微細化してるとしても
クロック上げるのも難しいと思うのですよねぇ
98:デフォルトの名無しさん
07/02/06 02:25:15
そういえばK8LのL3は面積からしてZ-RAMじゃないな
大原妄想乙でした
99:1 ◆.MeromIYCE
07/02/06 07:04:51
初代スレの398でやったdivのレイテンシ測定をするプログラムを作ったので、
色々なCPUで試してみてくださいまし。
URLﾘﾝｸ(www.wikihouse.com)
Dothanでの結果は、こんな感じ。
除数大↓ 被除数大→
15 23 39 39 39 - - -
15 15 23 39 39 39 - -
15 15 23 23 39 39 39 -
15 15 23 23 39 39 39 39
>>95
Windows生ハムの遅さを高速なmelonプロセッサがおおまかカバー、
melonプロセッサがWindows生ハムの素晴らしい機能を引き出す、
ってか。
いや、Vistaの話じゃないですよ。
100:デフォルトの名無しさん
07/02/06 10:43:10
Opteron146(Socket939 core=Venus)の結果をば。
除数大↓ 被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40
101:デフォルトの名無しさん
07/02/06 11:53:40
Pentium 4 630 Prescott 90 nm
CPUID F.4.3
除数大↓ 被除数大→
68 68 67 68 68 - - -
69 71 67 68 69 69 - -
69 69 69 69 70 68 70 -
69 69 70 73 71 71 69 69
102:デフォルトの名無しさん
07/02/06 13:10:50
Pentium 4 631 CedarMill 65nm
CPUID F.6.5
除数大↓ 被除数大→
84 88 88 87 87 - - -
88 88 88 88 88 87 - -
87 88 87 87 87 87 88 -
87 87 87 87 88 87 88 88
103:デフォルトの名無しさん
07/02/06 13:42:24
Athlon XP-M 1800+ Thoroughbred Low Power
除数大↓ 被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41
K6-2 400MHz Chomper Extended
除数大↓ 被除数大→
19 19 19 19 19 - - -
19 19 19 19 19 19 - -
19 19 19 19 19 19 19 -
19 19 19 19 19 19 19 19
104:デフォルトの名無しさん
07/02/06 15:07:00
動かしてみるに吝かではないのだけれど、CPUの情報もプログラムで拾って表示してくれると便利だと思う。
それと、Linux版が欲しいとか贅沢も言ってみる。
ってことで、手元のCeleron 2GHz(という以外判らない)
除数大↓ 被除数大→
51 51 51 51 51 - - -
51 51 51 51 51 51 - -
51 51 51 51 51 51 51 -
51 51 51 51 51 51 51 51
105:デフォルトの名無しさん
07/02/06 17:56:32
Celeron 1.7GHz(Willamette-128K)
除数大↓ 被除数大→
50 50 50 50 50 - - -
50 50 50 50 50 50 - -
50 50 50 50 50 50 50 -
50 50 50 50 50 50 50 50
106:デフォルトの名無しさん
07/02/06 18:00:28
Opteron144(Venus)だけど>>100と同じ結果
107:デフォルトの名無しさん
07/02/06 18:19:44
Pentium II
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
108:デフォルトの名無しさん
07/02/06 18:23:44
Conroe
除数大↓ 被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41
109:1 ◆.MeromIYCE
07/02/06 22:02:53
みなさんありがとう。
小さい数の割り算だと速くなるのはPenM～Core2だけみたいだね。
Pen4はステッピングが進むにつれて遅くなってくなあ。これがネトバだよな。好きだ。
K7/K8が、PenMの遅いところと同等程度。意外と速くないが、整数はこんなものか。
K6-2は低クロックとはいえさすが。今にして思えば味のある石だった。
PenIIがPenMと似た数字なのが面白い。PenMも地味にいい改良してるよなあ。
>>104
↓こういうのを表示できるようにして、後でアップします。
GenuineIntel Family:6 Model:D Stepping:6
Linuxは誰かにコンパイルしてもらいたいが、それにしてもVC++のインラインアセンブラはまずい。
アセンブラ部をNASM用にすることは可能だと思うので、ちょっと挑戦してみる。
>>108
あれ！？ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。
PenMの改善点を洗練させた感じだ。
基本的に被除数が32bitに収まる場合を高速化してるみたいだな。
Yonahのときに、割り算が速くなるという話があったが、Core2も同じか？
持ってる人Yonahの測定お願いします。
110:デフォルトの名無しさん
07/02/06 22:05:10
YonahとBaniasの計測がほしいね。それで完璧。
111:・∀・）っ-○◎● ◆DanGorION6
07/02/06 22:41:06
GCCなら-masm=intelオプションでほぼそのまんま移植できた希ガス
112:・∀・）っ-○◎● ◆DanGorION6
07/02/06 22:42:54
ほれPentium M（Banias）
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
113:1 ◆.MeromIYCE
07/02/06 22:50:46
>>112
マジで！！！？？
114:デフォルトの名無しさん
07/02/06 22:52:44
今までの計測結果を見ると、
Banias->Dothanで大きな除算の改良が入ったように見える。
除数によって大きくlatencyが変化しているのはConroeのみなので、
もしかすると、Yonahから除数側の改良が入ったのかも知れず。
Yonahの計測結果ﾏﾀﾞｰ??
115:デフォルトの名無しさん
07/02/06 23:13:16
いや、除数側の改良もDothanからか。
Yonahでの発表は厳密にはウソってことでFA?
116:デフォルトの名無しさん
07/02/06 23:19:49
AMDFAM10について考察希望
ｽﾚﾘﾝｸ(jisaku板:557番),558,606-609,644-646
最新版はsvnで
svn co svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i386
117:1 ◆.MeromIYCE
07/02/06 23:26:08
>>99の測定は、下のコードと、そこからdiv ebxを抜かしたコードとの
差をdiv命令のレイテンシとしている。
lp:
add eax,xa ; xa,xdはメモリ
mov edx,xd ; 被除数は毎回破壊されるので毎回読み込む
div ebx
mov esi,eax ; レジスタをクリアして、かつ依存関係を保たせるあがき
neg eax
add eax,esi
dec ecx
jnz lp
いちおうPenMでは正しい結果を出してると思うけど（以前の測定でも散々追試してるし）、
ループ処理がそれなりに重いのでCPUによっては微妙かもしれないと不安になってきた。
もう少しいい処理・わかりやすいループのアイデアある？
まず、ループをアンロールというのはやろうと思う。
118:1 ◆.MeromIYCE
07/02/06 23:50:27
>>115
いや、Yonahの発表からすると、Yonahの時点でCore2の速さだったんじゃない？
どうも新しいCPUはレイテンシが微増する傾向があるみたいなので、
Yonah（PenMと同じ世代）がCore2（新しい）より速いということも考えられる。
>>108を見ると、PenMを改良したものからピッタリ2clk遅くなっている感じだ。
>>116
コンパイラの対応からK8Lの特徴を読み取ろうというのか。
costを見ればいいのかな。コンパイラに必要な情報というのはいい情報かも。。
119:デフォルトの名無しさん
07/02/07 01:43:41
Merom T5600
除数大↓ 被除数大→
17 25 33 41 41 - - -
10 17 25 33 41 41 - -
10 10 17 25 41 41 41 -
10 10 10 17 41 41 41 41
Pentium M 1.40GHz
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
Athlon 64 X2 4800
除数大↓ 被除数大→
40 40 40 40 40 - - -
40 40 40 40 40 40 - -
40 40 40 40 40 40 40 -
40 40 40 40 40 40 40 40
Sempron 3000+(Socket A)
除数大↓ 被除数大→
41 41 41 41 41 - - -
41 41 41 41 41 41 - -
41 41 41 41 41 41 41 -
41 41 41 41 41 41 41 41
120:デフォルトの名無しさん
07/02/07 06:02:45
>>109
> あれ！？ConroeのrdtscってFSBクロックとか聞いたけどちゃんと測れるのか。
C1E等でクロック倍率が下がっている時でも
FSB１カウントにつきTSCは最高クロック倍率（
E6600なら9）ずつカウントアップする仕様みたい。
どんな時でもrdtscを２回実行すると、その差は必ず
(E6600の場合)9の倍数になる。
2コアでほぼ同時にrdtscを実行すると2コアともほぼ近い値が返ってきたが、
MBのBIOSをアップデートしたら、2コアで全く異なる値が返るようになってしまった。
その後、WinXPのデュアルコアパッチを入れたら2コアでほぼ近い値が返るようになった。
121:1 ◆.MeromIYCE
07/02/07 08:09:24
>>120
なるほど！数字としては今までと同じで、精度がコアの倍率分だけ悪くなっているのか。
2コアで同じ時計を持てるのは嬉しいが、やはりクロック単位の測定にはちょっと痛いな。
カウンタはどこにあるのだろう？
マザーボードのBIOSで影響するということはCPUの外だとも思えるが、
それだと2コアで異なる値が返ることがあるという現象に説明がつかない。
カウンタはコア毎にあって、CPUが起動するときに合わせるのかな？
>>99
CPUIDを表示するのと、>>117で言ったアンロール（2回）をやったのをアップし直した。
アドレスは同じ。
122:デフォルトの名無しさん
07/02/07 08:39:01
Core Duo T2400 1.83GHz
除数大↓ 被除数大→
14 22 30 38 38 - - -
7 14 22 30 38 38 - -
7 7 14 22 38 38 38 -
7 7 7 14 38 38 38 38
123:122
07/02/07 08:45:22
更新されてたの気づかなかった
同じ環境
GenuineIntel Family:8 Model:E Stepping:6
除数大↓ 被除数大→
15 23 31 39 39 - - -
8 15 23 31 39 39 - -
8 8 15 23 39 39 39 -
8 8 8 15 39 39 39 39
124:デフォルトの名無しさん
07/02/07 11:35:52
>>100を本日アップ分で再計測
AuthenticAMD Family:1 Model:7 Stepping:F
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
125:・∀・）っ-{}@{}@{}@ ◆DanGorION6
07/02/07 13:10:10
ソース読んだ
FamilyとStepping逆じゃね？
126:デフォルトの名無しさん
07/02/07 13:18:45
Core 2 Duo E6300
GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
20 30 39 48 48 - - -
12 20 30 39 48 48 - -
12 12 20 30 48 48 48 -
12 12 12 20 48 48 48 48
127:デフォルトの名無しさん
07/02/07 15:33:54
>>126 この結果ってCPUのクロック倍率が落ちた状態じゃないかな？
EISTやC1Eで自動的にクロック倍率が落ちるので、
FSB同期のrdtscでクロック数を計測するのはいろいろと面倒かも。
128:デフォルトの名無しさん
07/02/07 17:56:51
Merom T5600
GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
18 26 34 42 42 - - -
11 18 26 34 42 42 - -
11 11 18 26 42 42 42 -
11 11 11 18 42 42 42 42
PentiumM 1.4GHz
GenuineIntel Family:5 Model:9 Stepping:6
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
Athlon 64 X2 4800
AuthenticAMD Family:2 Model:3 Stepping:F
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
Sempron 3000+
AuthenticAMD Family:0 Model:A Stepping:6
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
129:デフォルトの名無しさん
07/02/07 21:51:56
>>103再計測。やっぱFamilyとStepping逆だね。
AuthenticAMD Family:6 Model:8 Stepping:1
除数大↓ 被除数大→
39 39 39 39 39 - - -
39 39 39 39 39 39 - -
39 39 39 39 39 39 39 -
39 39 39 39 39 39 39 39
AuthenticAMD Family:5 Model:8 Stepping:C
除数大↓ 被除数大→
18 18 18 18 18 - - -
18 18 18 18 18 18 - -
18 18 18 18 18 18 18 -
18 18 18 18 18 18 18 18
130:デフォルトの名無しさん
07/02/07 22:33:58
GenuineIntel Family:6 Model:8 Stepping:6
除数大↓ 被除数大→
38 38 38 38 38 - - -
38 38 38 38 38 38 - -
38 38 38 38 38 38 38 -
38 38 38 38 38 38 38 38
131:1 ◆.MeromIYCE
07/02/08 00:02:01
>>123
二度手間ごめん。しかも結果違うorz
おそらく>123の方が正解。
これで、Core2のdivはYonahを2clk遅くしたものだとわかった。
Banias→荒削りのDothan→完成形のYonah→Meromの変化が面白い。
>>124>>129
これも結果が異なるのか。やはり測定法に問題ありだな。
>>123>>130とは逆にクロック数が減っているが、ALUパワーの差、かな。
K6-2も（当時としては）ALUが強い。対してP6系は総合的に速い割にALUは弱い。
2つのループの差からクロック数を求めているため、div以外の特徴も混ざってしまう。。
>>125
うあ～！俺のDothanはFamilyとSteppingが同じだから気がつかなかったよ。
指摘サンクス。後でこっそり修正しておきます。
>>127
確かに>126は2割、>128は1割だけクロック数が増えているな。
CPUのクロックが落ちても（今までのCPUと違って）rdtscのクロックは変わらないということか。
ただ、誤差が1～2割というのはSpeedStepにしては少ない感じがする。
ある程度のタイミングで補正はしてくるのか？
測定した人たちへ：毎度ヘボプログラムでごめんなさい。
132:1 ◆.MeromIYCE
07/02/08 00:40:35
>>128のMeromってよく見たら>>108の1clk増しじゃん。。
ここ見たらCore2のレイテンシは18～42clk（>>128と同じ）と書いてあるのだが、
URLﾘﾝｸ(www.agner.org)
こっちを見ると17clk（>>108と同じ）と書いてあり、
URLﾘﾝｸ(aceshardware.com)
マジでどっちが正しいのかわからない。
133:デフォルトの名無しさん
07/02/08 02:58:10
>>126-127 >>131
EIST と C1E を切って測定してみました。
GenuineIntel Family:6 Model:F Stepping:6
除数大↓ 被除数大→
18 26 34 42 42 - - -
11 18 26 34 42 42 - -
11 11 18 26 42 42 42 -
11 11 11 18 42 42 42 42
134:1 ◆.MeromIYCE
07/02/08 20:40:15
>>133
順当な結果ですね。
単純にedx=0, eax=1, ebx=1としてdiv ebxを連続実行すれば
1÷1のレイテンシが求まるから、それを基準にすればいいかな。
でも、大体結果は出ているし、またバグ出すと嫌なので
ここらで手を引きます。
後藤弘茂によると、ノート用Core 2 ExtremeはIDAナシのようだ。
こういうところからIDAの思想が若干見えるか？
135:・∀・）っ-○◎● ◆DanGorION6
07/02/08 21:32:04
YorkfieldでHTが有効ってことになると、Nehalemがトレースキャッシュ型
アーキテクチャであるという仮説の有力性は揺らぐね。
トレースキャッシュはHTの必須条件だと思ってたが違うってことになるわけだし。
フェッチ・プリデコード帯域を倍にして交互にデコードすれば従来アーキでもいける？
136:デフォルトの名無しさん
07/02/09 01:18:43
SMTの実装にトレースキャッシュが必須ってこたないでしょ。
Power5なんかはx86と比べるとデコーダ負荷が低いとはいえ、普通のキャッシュのままSMTやってるし。
137:デフォルトの名無しさん
07/02/09 01:55:15
>>135
命令の切り出しの方がネックじゃなかったっけ？
138:デフォルトの名無しさん
07/02/09 01:59:28
>>134
多分 HTT有効だと一部のアプリの性能が低下する ってのと同じ問題が起きるよなあ
厳密には IDAがあるのに上手く活かされずシングルスレッド性能が向上しない だけど
至極真っ当且つナイスな技術なのにソフトウェアが台無しにするという。。。
ユーザーがHALT命令を制御できればなあー
将来的にはハイエンドサーバーみたいにCPUパーティションの動的な変更もできる様になると尚良し
139:デフォルトの名無しさん
07/02/10 13:49:18
>>138
HLTをユーザモードに解放するメリットは何?
計測目的ならDOSとかRING0で計測すればいいだけだし、
OSスケジューラの都合ならHLTでコアを止めるよりもsleepしてOSに任せたほうがいいし。
140:デフォルトの名無しさん
07/02/12 04:32:58
URLﾘﾝｸ(journal.mycom.co.jp)
141:デフォルトの名無しさん
07/02/12 07:17:18
PentiumってOutOfOrderだったっけ？
142:デフォルトの名無しさん
07/02/12 19:30:56
P5はインオーダー
143:デフォルトの名無しさん
07/02/12 20:51:15
URLﾘﾝｸ(pc.watch.impress.co.jp)
>P5では、5ステージのパイプラインで、最大2命令を並列実行していた。
>次のP6では、最大3個のx86命令をuOPsに変換し、アウトオブオーダ実行。
P5でスーパースカラを初実装。
P6でアウトオブオーダを初実装。
だな。
つーかそもそもスーパースカラとアウトオブオーダは別系統の技術だった
と思うけど（まあセットで実装されることが多いが）、大原は混同してないか？
>筆者のテクニカルライターとしての鼎の軽重を問われかねない。
駄目じゃんｗ
144:デフォルトの名無しさん
07/02/13 00:53:54
in-order発行のtypoだと信じておこうｗ
つか、out-of-order発行（in-order完了）じゃ
いわゆるふつーのout-of-orderじゃん
145:デフォルトの名無しさん
07/02/13 06:08:15
out-of-order終了ｗ
カチャカチャな動作をする予想ｗ
146:デフォルトの名無しさん
07/02/13 06:41:12
>鼎の軽重
怪電波を飛ばすのが生業のような方々にそんな物問いませんからｗｗｗ
147:デフォルトの名無しさん
07/02/17 23:33:25
連載ｵﾜﾀよ
148:デフォルトの名無しさん
07/02/17 23:41:28
第194回 Core MicroArchitectureをもうすこし(18)
URLﾘﾝｸ(journal.mycom.co.jp)
長かったな…
149:・∀・）っ-○◎● ◆DanGorION6
07/02/18 00:06:52
↓次のネタ大胆予想
150:・∀・）っ-○◎● ◆DanGorION6
07/02/18 00:14:42
「Core Microarchitectureをさらにもう少し」
addの例はおかしいだろ。
ニーモニックからバイトコードへの変換はアセンブラがやるもので
この辺のデコードだけなら楽にこなせるはずだ。
プレフィックスも少ないし。
このへんだけ見ればx86ってコンパクトだなと思う。
むしろ2～3バイトopcodeまわりがテラカオス
151:デフォルトの名無しさん
07/02/18 00:30:46
>>149
今回のことで懲りたので、たぶん非PCの話題とか、誰にも突っ込まれ
ない（というか誰も興味ない）話題でお茶を濁すと見た。
152:デフォルトの名無しさん
07/02/18 00:33:28
> Pentium Proの世代は、命令の発行とその実行まではOut-of-Orderながら、
> 命令の完了(実行結果の書き戻し)はIn-Orderという構成で、
> これが完全にOut-of-OrderになるのはNetBurst Architecture(や、
> P6をベースにアーキテクチャを作り直したBanias Architecture)からになるのだが、
NetBurstやBaniasがOut-of-Order完了な訳ないじゃん。
153:デフォルトの名無しさん
07/02/18 00:37:57
ハイパースレッディングは考え様によってはOut-of-Order完了だな
154:デフォルトの名無しさん
07/02/18 00:42:44
Out-Of-Order完了ｗｗｗ
155:デフォルトの名無しさん
07/02/18 14:54:15
>>153
NetBurstはそれでもいいけど、Baniasは違うよなあ
156:デフォルトの名無しさん
07/02/18 15:18:22
もうなんか大原って中途半端な知識で言い切るんだよね。だから色々
突っ込まれる。IPC=3だって、「他の可能性もあるが俺はこう思う」と
最初から言えばそこまで突っ込まれないのに、言い切ってしまう。
で、後から「実は他の可能性もあるし、俺はそれも知っていた」と言い訳
するんだよなｗ
一度初心に戻って勉強しなおせよ。
157:デフォルトの名無しさん
07/02/18 16:39:17
初心に戻ろうと思い、裸になって学校へ行こうと電車に乗ったら捕まりました。
158:デフォルトの名無しさん
07/02/18 20:28:54
>>156
それがライターの仕事
後藤や本田や(中略)安藤だって(以下略
ブログとセカンドオピニオンで補足するだけマシじゃね
159:デフォルトの名無しさん
07/02/18 20:35:53
URLﾘﾝｸ(www.amd.com)
> Q: What are some of the advanced features of the AMD-K5 Microprocessor?
>
> A: ・4-issue core with full out-of-order execution and completion
この辺を見て「Out-of-Order完了」という言葉を使っているのかな。
AMDは、内部RISC命令の実行結果をROBに書き込んだ時点で
内部RISC命令の実行完了 という意味で書いているのだろうが、
そういう意味だったらPentium ProもOut-of-Order完了だし。
160:デフォルトの名無しさん
07/02/18 20:57:34
>>158
それでも後藤と大原じゃ、大きく違うがな。
二人が同じに見えるなら、それはそれで見る目が無いよ。
161:158
07/02/19 00:48:00
何だか、何を書いても叩かれそうだからライターの格付けはしないが。
素人にわかるように説明するのに「～かも知れない」ばっか使うわけにはいかないよねって話。
でも、あの特集記事が叩かれるのもわかるんだよね。
「K8はそんなに悪くない。むしろよく見える。」な結論ありき丸出しの記事だったもん。
IPCなんて言葉は使わずに>>38 >>41 >>43-44みたいなことを適当に書いておけば良かった。
162:デフォルトの名無しさん
07/02/20 00:26:13
まぁ、でもネタを提供してくれる分にはとてもありがたく思ってるよ。
163:デフォルトの名無しさん
07/02/20 00:47:19
>> 162
それ大原のこのスレに対する台詞でしょ??
164:1 ◆.MeromIYCE
07/02/20 17:19:34
>>148
結局、Core2のIPCが3だという主張以外はまっとうで普通な内容だったな。
本来ならば、この記事を肴にしてSSE4やそれ以降の命令の実装についてとか
32byteフェッチ3命令パイプのK8Lと16byteフェッチ4命令パイプのCore2の比較とか
色々このスレで議論できたはずなのに、ちょっと惜しい感じだ。
プロならちゃんとやれとも思うが、色々事情があってこういう格好になってしまったのだろう。
数年前と比べて、CPUの話題が減ってきてるような気がするんだよなあ・・・。
時代の流れか、それとも単に俺が手持ちのPentiumMに飽きてきただけか。
165:デフォルトの名無しさん
07/02/20 18:41:07
みっなおそう、みなおそう、CPUを見直そう
Core2Duo機に買い替えろ
みっつもりっだみつもりだ
166:デフォルトの名無しさん
07/02/20 19:49:18
4gamerの第5回目以降の下書きメモ帳代わりにmycomを利用した大原たん
さっさと4亀連載の続き書けや(ﾟﾛﾟ)ﾓﾙｧ!!・・・・・書いてくださいお願いしますm(_ _)m
167:デフォルトの名無しさん
07/02/21 00:31:05
4gamerの記事は比較的よくできているね。
あれでゲームはやってもCPUに詳しくなかった層が入るのにはちょうどよいだろう。
168:デフォルトの名無しさん
07/02/21 09:27:01
【ネガティブ派遣根性チェック】
3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らないのは当然だ
□派遣先社員より自分の生涯収入が低いのは当然だ
□派遣先とに尻尾を振り、いつまでも派遣を続けることが大切だ
169:デフォルトの名無しさん
07/02/24 00:32:24
170:デフォルトの名無しさん
07/02/26 00:22:15
セカンド・オピニオン、新シリーズ来ました。
第195回 OS小論:OSの構造をもう少し考えてみる(1)
URLﾘﾝｸ(journal.mycom.co.jp)
「もう少し」とついているのが不安をかきたてる…
171:デフォルトの名無しさん
07/02/26 00:31:44
「もうすこし」ではないから安心しろ。
172:デフォルトの名無しさん
07/02/26 05:16:52
>誰を恨むわけにもいかないんですが
このスレの住人恨む気満々だなwww
ここの住人はサイレントマジョリティーではないはずだが、考慮されている様子。
173:デフォルトの名無しさん
07/02/26 09:26:09
大原先生ごめんなさいｗ
174:デフォルトの名無しさん
07/02/26 12:33:04
全部>>173が悪いんです！！
175:デフォルトの名無しさん
07/02/26 21:27:43
ぬこ成分だけで全て許してしまえる
いや記事にも期待してるけどスレ違いだな
176:デフォルトの名無しさん
07/02/26 22:34:09
iいろんな意味で役に立ってるから今度ファンレター送るね。
つかHansと知り合いつのが改めて驚き。
177:デフォルトの名無しさん
07/03/01 22:15:13
Barcelona Architecture: AMD on the Counterattack
URLﾘﾝｸ(www.anandtech.com)
178:デフォルトの名無しさん
07/03/02 21:38:33
Hammer-Infoで紹介されていたリンクをﾒﾓ
レジスタ間接分岐の高速化手法 (PDF)
URLﾘﾝｸ(www.mtl.t.u-tokyo.ac.jp)
179:デフォルトの名無しさん
07/03/02 23:53:07
生活支援てw
180:デフォルトの名無しさん
07/03/06 02:27:17
> 他所様の出版社から出ている内容をここで引用するわけにもいきませんので
著作権 (著作者が云々、文化が云々という建前で出版社やレコード会社の利益を最大化するための道具であり既得権益)
を、本音の方の意味で遵守すると正当な引用すらできなくなっちゃうのか
181:デフォルトの名無しさん
07/03/07 01:24:37
439 ：デフォルトの名無しさん ：2007/03/07(水) 01:18:11
狂ったようにx86命令の所要クロックを計測するスレ Part3
ｽﾚﾘﾝｸ(tech板)
と紹介されたが、スレタイに「狂ったように」が付いてなくて失望した
182:デフォルトの名無しさん
07/03/07 16:07:02
そこは絶望しないと
183:デフォルトの名無しさん
07/03/07 22:01:10
これか
【激遅】AppleGCC【絶望】
ｽﾚﾘﾝｸ(tech板)l10
184:デフォルトの名無しさん
07/03/08 01:05:22
>Intelは80386以降で、4レベルのProtection Ringという概念を導入した(Photo01)。
80286以降だろ。大丈夫か？
185:デフォルトの名無しさん
07/03/08 01:18:51
相変わらずツッコミきっつー
186:デフォルトの名無しさん
07/03/08 07:56:57
VAX/VMS が仮想記憶をインプリメントした初めてのOSだとか [1]、
4 level ring が VAX 由来だとか [2]、ほかにも色々間違っとるぞ。
[1] Wikipedia によると商用では 1961年の Burroughs B5000 が最初らしい。
研究用だと、さらに数年さかのぼる。
IBM の汎用機も VAX/VMS よりずっと以前に仮想記憶をサポートしてるはず。
VAX は 1970年代終りなので、ずっとずっと新しい。
[2] よく知らんが、たぶん MULTICS 由来。
187:デフォルトの名無しさん
07/03/08 12:59:43
80386の仮想記憶ってほとんどMULTICSそのままだよな。
188:デフォルトの名無しさん
07/03/08 19:08:02
80386は仮想記憶やページングのアーキテクチャだけは割と新しいからな
189:デフォルトの名無しさん
07/03/10 02:37:09
>>188
話の流れを分かってない。
MULTICS由来ってのは286から導入されたセグメンテーション機構の話。
386から入ったページング機構はインテルにしては(?)素直で作りで良い
んだが、TLBにASIDがないのがちと古い感じ。
190:デフォルトの名無しさん
07/03/12 01:03:57
流れ断ち切るようでスマソ。質問。
VCExpressコンパイラでローカル変数として配列等大量にオブジェクトを定義している関数内部で
関数入口：sub esp, ローカル変数のサイズ分
関数出口：add esp, ローカル変数のサイズ分
と展開されたコードがあります。
このコードが有る場合、パフォーマンス大幅に落ちるから気をつけてくださいな、と上司から言われたんですが、
何処に根拠があるのかサッパリで悩んでます。
パフォーマンスは落ちるものなのでしょうか
自分なりの答え：
スタック領域使うからレジスタで演算するよりも速度が落ちる？
191:デフォルトの名無しさん
07/03/12 01:25:39
>>190
まずは実測してくれまいか？
192:デフォルトの名無しさん
07/03/12 01:42:35
スタックの先頭は通常キャッシュにのってるから速いが
沢山スタックを消費すると追いやられる
そのことを言ってるんだと思う
メモリ沢山使う＆アクセス頻度が低い
ならば、メモリはヒープからとったほうがいいかもしれない。
あ、ちゃんと実測してね。思い込みはダンゴの元。
193:・∀・）っ-○◎● ◆DanGorION6
07/03/12 01:48:04
スタックを大量に使うこと自体はそんなに問題じゃないと思う
push. pop大量にするわけじゃあるまいし。
194:・∀・）っ-○◎●
07/03/12 01:50:13
>>192
ヒープに載っけても結局同じだけメモリ食うんだがｗ
まだ直線的に並んでたほうがassociativityの制約に引っかかりにくいｗ
机上論だがｗ
195:デフォルトの名無しさん
07/03/12 02:01:11
call by value -> call by reference
196:デフォルトの名無しさん
07/03/12 02:05:51
ここは計測スレなのに最近自作○C板のCPUスレと同種の話ばっかりじゃない?
自作○C板は自作○C板で同種のスレがたくさんある。もっと独自路線を出してほしい。
つか、どこでも読める理論話のぼり返しはほどほどにしてひたすら計測しろよと。
197:・∀・）っ-○◎●
07/03/12 02:18:37
しかしAgner氏の計測を覆すような発見もそうそう無いんだよな
命令レベルじゃなくて何かのプログラムコードレベルで
ボトルネックを分析するとか？
198:デフォルトの名無しさん
07/03/12 02:25:27
マジでダンゴ来た・・・もうオワリだ・・・
199:・∀・）っ-○◎●
07/03/12 02:44:07
最初からいるだろ
x86じゃないけどCellのスループット計測結果なら出せるよ
200:デフォルトの名無しさん
07/03/12 03:06:29
早く貼れ
201:デフォルトの名無しさん
07/03/12 03:07:19
いや、やっぱり貼るな
CELLネタは荒れる
202:・∀・）っ-○◎●
07/03/12 03:08:55
>>1が許可したら貼る。
てかCellスレあるし
203:デフォルトの名無しさん
07/03/12 14:43:18
トリップ外すな、ハゲ。
204:デフォルトの名無しさん
07/03/12 14:55:40
○◎●であぼーんは基本だろ？
205:デフォルトの名無しさん
07/03/12 19:38:51
URLﾘﾝｸ(homepage1.nifty.com)
206:デフォルトの名無しさん
07/03/12 20:50:00
いつもの
URLﾘﾝｸ(journal.mycom.co.jp)
と、65nmAthlonのL2キャッシュレイテンシについての考察
URLﾘﾝｸ(journal.mycom.co.jp)
207:1 ◆.MeromIYCE
07/03/13 12:23:41
>>181
実際狂ったように測定していなくてゴメン。
>>190
アセンブラレベルでは、sub esp, ローカル変数のサイズ分 は ただの引き算だから、
1clkで終わってしまう簡単な処理だ。
でも、マルチタスクOSで動かす以上、Windows側のメモリ管理で時間がかかるとか？
今時間ないので後で実測したい。
>>202
256KBのLSのレイテンシとピーク帯域、FP_SIMDのレイテンシ・スループットを希望。
x86じゃないけど、自分で実測したデータなら誰も文句言わんでしょ。
>>206
レイテンシ測定はここ。
URLﾘﾝｸ(journal.mycom.co.jp)
何で生データを載せてくれないだ。くそっ。意味わからんグラフばっか載せやがって・・・。
キャッシュラインサイズの64byte以下のstrideで速くなるのは当然として、
それ以上のstrideで変化しているのは単にCPUの機嫌が悪かっただけと予想。
内部構造が変わったかどうかはわからないが、レイテンシが増えたのは確実だ。
208:1 ◆.MeromIYCE
07/03/13 12:51:01
コンパイラの出力を見て初めて知ったこと。
or ecx, -1 (83 c9 ff) という3byteでecxに32bitの-1を入れることができる。
1byteの-1は32bitに符号拡張される。
まあ、xor ecx,-1 はnot ecx でいいし、高速化に使う機会はないかな。
>>196
ネタ切れ、というのが主な原因なんだけど、
実際クロック測定は、何を測定するか考えて、実際に測定して、考察して書き込む、
という手順を踏まなければならない。
そして、そのそれぞれが、思った以上にめんどくさい/難しい。
そこで、何を測定するかだけでも思いついたら書いてくれ、って前から言ってるけど。。
あと、cpu-zのレイテンシ測定の全CPU分を集結させたいと思っている。
このスレでも何度か上がってるけど、いざ90nmK8のデータが欲しいと思っても、
どこにあったかわからなかったので。
URLﾘﾝｸ(www.wikihouse.com)
とりあえずここに、手元にあった分だけ固めてアップしておく。
あとでちゃんと整形して上げます。
209:・∀・）っ-○◎●
07/03/13 19:32:13
スループットなら倍精度以外はほとんど1だよ。
SPEのLSはレイテンシ6だよ。Coppermineがレイテンシ6だったから
今のCore 2も、独立キャッシュにしてL2のエントリ数削れば
それくらいいけるんじゃないのって思うと萎える。
んなわけで、レジスタが128本もあるから、必要なデータは展開して
しまった方がいいわけだ。
AltiVecでVSIUパス命令に相当する整数演算命令はレイテンシ2、
あとの命令（VCIU、VPERM相当）は大体レイテンシ4。
あと、浮動小数はfma（積和算）で6、faddで4。
逆数を求めるfrestなんかも4で処理出来、fmaと組み合わせれば
レイテンシ10・スループット2で除算ができてしまうんだけど、
estimate(推定値)というぐらいだから精度は絶望的に低いと
思ってくださいな。
それなりに精度の高い除算をやろうと思えばソフトでやるしかない。
平方根も同じく。
210:・∀・）っ-○◎●
07/03/13 19:48:30
LS間の「ピーク帯域」に関しては、ロード・ストアはoddパイプで処理されるから
1クロックに1命令。
ロードかストアを発行×3.2GHzだから51.2GB/secでしょう
DMA転送中はどうだかまだ調べてない
SPE-SPEのDMA転送帯域とかならこのへん
URLﾘﾝｸ(www-128.ibm.com)
211:・∀・）っ-○◎●
07/03/13 19:56:22
てか、IBMの図におもっきし51.2GBって書いてあるじゃんｗｗ
212:・∀・）っ-○◎●
07/03/13 20:01:29
レジスタが128本だから1レジスタ指定に7ビット。
4オペランド命令で28ビットも使ってるからOpcodeは4ビット。
（上1ビットはopcodeサイズの区別に使うから実質3ビット）
そういえばPentium 4もμOPsレベルではレジスタ数は128だか256だかでしたな。
213:デフォルトの名無しさん
07/03/13 20:01:51
80286の間違いは訂正なしか。だめだなこりゃ。
214:デフォルトの名無しさん
07/03/13 20:45:51
精度の高い除算のやり方はは3DNow/SSEと同じ。
doubleも命令の組み合わせで一通り出来るけどスループットとレイテンシを考えると…。
それでもこれだけ割り切ったプロセッサでdoubleが扱えるだけ幸せ。
215:・∀・）っ-○◎●
07/03/13 23:09:18
なんつーか、普通のプロセッサ用に書いたコードがことごとく使えない
エントリポイントのmain型さえ置き換えればどうにかなると思ってたら
1から書き直しなんだよね。
それでもprintfなどがそのまま使える分マシ
（PPEで動くヘルパースレッド向けにDMA転送して処理してる？）
216:デフォルトの名無しさん
07/03/14 01:37:23
spe_printf()は遅い悪寒。
#って、スレ違いだがね。
217:・∀・）っ-○◎●
07/03/16 23:26:50
ネタがないな
218:デフォルトの名無しさん
07/03/16 23:48:45
暇ならXLATの所要クロックについて語ってくれ。
とか適当な事を言ってみる。
219:デフォルトの名無しさん
07/03/17 04:43:37
x86_64命令の所要クロック計測まだー
220:・∀・）っ-○◎●
07/03/17 05:08:51
同じじゃねーかｗｗｗｗ（NetBurst以外
221:1 ◆.MeromIYCE
07/03/18 21:50:08
>>209
レスが遅れてすまん。
まあ、大体素直な感じだな。
x86のキャッシュはマルチタスクに対応するための複雑なメモリ管理や
L1L2（ものによってはL3も）の多重階層で、かなりレイテンシが増えているよな。
それを考えればCellのLSは順当な性能だ。
x86にLSを載せたらどうだろう。
256KBでレイテンシ6、128bit/clkという性能で、更にL1L2キャッシュは今まで通りとする。
LSは新SSE命令で明示的に使う必要があるが、使えば効果は大きいと思う。
（L1とLSの両方に高速な配線をつなぐのは技術的に困難か？）
レジスタは128bit*128で2KBか。
こんなにあると、コーディングにまた別の感覚が必要になるなあ。
>>219
実際問題、普通にパソコン買うと32bitのWindowsVistaになっちゃうんだよね。
64bitの計測ができるのは、だいぶ先の話になりそうだ・・・。
222:・∀・）っ-○◎●
07/03/18 22:06:52
帯域がもう少し広ければトレースキャッシュくらいに使えるんじゃないかなと思ったり。
223:・∀・）っ-○◎●
07/03/19 02:01:23
ロード・ストア命令が16バイト単位でしか読めないから、多段階ルックアップテーブル
作ろうと思ったら各要素16バイトでパディングしないといけない。
ストアがさらに厄介で、含まれる16バイト領域をロードしてからマスクして値を重ね合わせ
格納する。
16バイト境界をまたがってた日なんか目も当てられませんな。
スカラなプロセッサ由来でスカラ－ベクタの交換も柔軟にこなせるx86+SSEの
使いやすさを認識するためにも使ってみるべきプロセッサですな。
224:デフォルトの名無しさん
07/03/19 02:57:39
スレ違いだし今更気づくような内容でもないだろう。
本当にAltiVec使った事あるのか？
手順が若干簡略化されてるだけでAltiVecもやるべき事は同じじゃないか。
225:・∀・）っ-○◎●
07/03/19 03:37:14
スカラプロセッサの補助としてベクトル演算器があるのと、
スカラ演算までベクトル演算器でやらなりゃならないのとは根本的に違うだろ。
AltiVecではアドレス演算はスカラ演算器で行い、ベクトル演算はデータの
処理のみに専念できる。このへんはx86と同じ。
AltiVecはせいぜいベクトル-スカラ間の値直接交換がないくらいで、
いったんL1に書き出して読み出すだけでいい。
SPUにはスカラデータを扱う命令そのものがない。
1バイト単位はおろか4バイト単位のロードすらない。
（そのくせアドレス生成や条件分岐ではベクトルの第一ワードでしか使えない）
16バイト単位で読み出して適宜シフトしなきゃいけない。
このへんがスカラ演算が圧倒的に遅いと言われる要因。
226:デフォルトの名無しさん
07/03/19 04:22:02
>>221
> x86にLSを載せたらどうだろう
レジスタ同様にタスクスイッチ時にデータを退避するのか？
それともロックして占有するのか?
227:1 ◆.MeromIYCE
07/03/19 10:12:27
>>226
仮にやるとしたら、ロックするのがいいかな。
オーバーレイなんかも同時に2アプリで使えないことだし、
エンコやゲーム専用と考えれば。
でもやっぱりマルチタスクできないのは不便だよな。
OS側でも工夫のしようはあると思うが、
そうまでして使う価値があるかは正直疑問だし。
228:・∀・）っ-○◎●
07/03/19 21:00:40
L1キャッシュよりレイテンシの大きいローカルストアよりも
拡張XMMレジスタファイル256本のほうがまだありがたいような。
imm8を使って各レジスタを指定。
229:デフォルトの名無しさん
07/03/19 23:40:14
スケジューラが詰まらないならその方がありがたいです。
レイテンシ分くらい依存命令を離しているつもりなのにストールすると悔しい。
230:デフォルトの名無しさん
07/03/24 00:59:06
リアルモードの割り込みベクタのことIDTなんていう呼び方してたっけ？
231:・∀・）っ-○◎●
07/03/24 01:10:07
Interrupt Descriptor Table
そのまんまの意味だな
232:デフォルトの名無しさん
07/03/24 01:12:47
いや、だからリアルモードの割り込みベクタテーブルとプロテクトモードのIDTはちょっと違うもんだろ、って話じゃ？
233:デフォルトの名無しさん
07/03/24 03:18:03
英語が理解できないのはつらそうだな。
234:デフォルトの名無しさん
07/03/28 15:47:10
どうして団子リオンはトリップつけてないのか。
235:デフォルトの名無しさん
07/03/28 16:08:32
>>230
intelの文書ではリアルモードの割り込みベクタテーブルを実アドレスモードIDTとよんでいる
236:・∀・）っ-○◎●
07/03/29 00:41:01
>>234
漏れてるから
237:デフォルトの名無しさん
07/03/29 03:14:36
ありゃ、お漏らししちゃってたのか。
238:デフォルトの名無しさん
07/03/29 09:03:33
Intel Penryn and Nehalem 45nm Processor Update
URLﾘﾝｸ(www.legitreviews.com)
The New Technologies and Features
Super Shuffle Engine キター
239:デフォルトの名無しさん
07/03/29 09:57:21
Emulatorの友
240:・∀・）っ-○◎●
07/03/30 01:40:45
> Super Shuffle Engine
128ビットシャッフルのスループット改善ですか
241:デフォルトの名無しさん
07/03/30 01:45:33
>>240
団子ちゃん、こっちのスレでお呼びがかかってるよ。
ｽﾚﾘﾝｸ(tech板)
242:デフォルトの名無しさん
07/03/31 01:47:05
>>235
どの文書？
243:デフォルトの名無しさん
07/04/01 10:32:22
スレ違いならごめん。
C言語で以下のようなソースがあったとして、
if( a < b ){
min=a;
max=b;
}else{
min=b;
max=a;
}
if( a < b )のかわりにif( a <= b )としても問題ないけど、この２つで出力
されるアセンブラソースや所要クロックに差は出るかな？
intなら同じだけどfloatでは差が出るとか有り得る？
244:デフォルトの名無しさん
07/04/01 11:05:39
>>243
コードの差は出るかもしれないし出ないかもしれない。
その周辺のコードによっても変わるし、勿論コンパイラによっても変わる。
245:・∀・）っ-○◎●
07/04/01 11:23:10
別スレ逝った方がいいよ。
「うちの使ってるコンパイラでASMコードの出力の仕方が解らないので教えてください」
SSE使えば比較文自体排除できる罠。floatだとこんだけ。
__m128 xa = _mm_set_ss(a);
__m128 xb = _mm_set_ss(b);
_mm_store_ss(&max, _mm_max_ss(xa. xb));
_mm_store_ss(&min, _mm_min_ss(xa. xb));
246:デフォルトの名無しさん
07/04/01 11:27:17
>>243
速度を気にするなら条件分岐を排除
同確率の二択はほぼどちらかが失敗する
247:デフォルトの名無しさん
07/04/01 11:34:00
どうも有難うございました。
248:デフォルトの名無しさん
07/04/01 11:55:50
まぁ、そんな細かいことが気になるならc++で
min = std::min(a, b);
max = std::max(a, b);
とでもすればいいだろうよ。
249:・∀・）っ-○◎●
07/04/01 12:05:11
細かいことが気になるならmin/max関数なんて使わない
250:デフォルトの名無しさん
07/04/01 12:53:36
なるほど、団子には皮肉が通じないわけだ。
251:デフォルトの名無しさん
07/04/01 13:15:01
つーかそれ、素で間違ったのに皮肉と言い訳してるのと見分けが
つかないから、皮肉なら皮肉でちゃんと分かるようにしないとｗ
252:デフォルトの名無しさん
07/04/01 13:19:50
明らかに皮肉とわかるのに
団子がいるスレは一段と引き締まるな
253:デフォルトの名無しさん
07/04/01 13:23:45
>>248みたいなことを言う馬鹿や初心者は結構いるぞ。
つまりそういう人間と君みたいな天才は区別が付かないんだよｗ
せっかく天才なんだから周りに勘違いされないようにした方が
幸せだと思っただけさ。気に障ったら許してくれｗ
254:デフォルトの名無しさん
07/04/01 13:38:16
( ﾟдﾟ)ノ ﾄﾞｿﾞー
ｽﾚﾘﾝｸ(tech板:411番)
255:デフォルトの名無しさん
07/04/01 14:20:42
どうもごめんなさいでした。
256:・∀・）っ-○◎●
07/04/01 14:21:23
>>253
基本的に同意
でも多分std::maxとかって書いておけば最適な命令に置き換えてくれると勘違いしてる
初心者なんじゃないだろうか。
皮肉だ皮肉だとと必死に自己弁護してることからも明らか
>>254
Hacker's Delight日本語訳発行以降、
半端な知識で「MSBをシフトすれば分岐が排除できる＝速い」と思いこんで
改悪コード書く厨が増えたよな。
257:デフォルトの名無しさん
07/04/01 14:43:29
半 端 な 知 識
258:・∀・）っ-○◎●
07/04/01 15:06:04
皮肉だ皮肉だと自己弁護してるのが特にそうだね
259:デフォルトの名無しさん
07/04/01 16:07:16
いくら初心者でもmin,maxが最適な命令に置き換わるなんて発想はありえない。
ちょっとひねくれすぎ。
260:デフォルトの名無しさん
07/04/01 16:08:54
団子が昔そうだったとか？
261:デフォルトの名無しさん
07/04/01 16:32:03
ダンゴの言うことはホント正しいよね
歯向かうのは馬鹿
262:デフォルトの名無しさん
07/04/01 16:34:42
どう考えてもmin,maxが最適な命令に置き換わるなんてありえないな。
誰に吹き込まれたか知らないが、勝手な妄想はよしたほうがいい。
263:・∀・）っ-○◎●
07/04/01 16:35:02
>>243がかかるクロック数を短くしたいという目的があって質問したのは
明らかなわけだが
細かいこととは、かかる処理時間を少しでも短くすることなわけで
min/max関数が最適な命令に置き換わるという勘違いでもしてないかぎり
出来ないレスだと思うけどねこれは
248 ：デフォルトの名無しさん ：2007/04/01(日) 11:55:50
まぁ、そんな細かいことが気になるならc++で
min = std::min(a, b);
max = std::max(a, b);
とでもすればいいだろうよ。
>>259-260 ←見苦しい弁解だな
264:デフォルトの名無しさん
07/04/01 16:40:20
言葉遣いや性格には問題ありだが。。。
265:・∀・）っ-○◎●
07/04/01 16:41:07
>>262
組み込み関数として最適化ができるアーキテクチャ・処理系はあるよ。
x86では、知る限りでは無いけど（マクロ版ならまだ最適化される余地あるかも）
266:デフォルトの名無しさん
07/04/01 16:41:52
>>264
まず団子が正しいことを認めろよ。
言い訳がましい。
267:デフォルトの名無しさん
07/04/01 16:45:34
>>262
あるだろう
268:248
07/04/01 17:07:41
ここで真相を明かしますよ。今日の日付けを考えてみろ、と。
という冗談はさておいて。
そもそも元質がCでって書いているんだから、C++で書いてある時点で>248はネタだって判るでしょうに。
269:・∀・）っ-○◎●
07/04/01 17:10:04
>>268を翻訳
「max/minが関数名と重なってるからstd::ネームスペース指定してみたけど
二重に誤爆しちゃったみたい。俺ってお馬鹿♪」
270:デフォルトの名無しさん
07/04/01 17:56:56
条件付movとか、フラグ→マスクみたいな一般的な方法ではなく
SSE2が最初に出てくるようなミーハーイッテル馬鹿は初心者を笑えないだろ…
271:デフォルトの名無しさん
07/04/01 18:23:00
>>270
見苦しい。
272:デフォルトの名無しさん
07/04/01 18:28:49
>>271
団子よ、IDが出ないからといって見苦しい自演するな。
273:デフォルトの名無しさん
07/04/01 18:41:39
無意味な喧嘩すんなよ。
匿名掲示板上で自分のアイデンティティ探ししてると、
（自作板に２名ほどいるけど）本物の精神疾患になるぞ。
274:デフォルトの名無しさん
07/04/01 18:51:22
おまえ自作板見てないだろ？
275:デフォルトの名無しさん
07/04/01 18:56:01
>>243-275
スレ違い
276:デフォルトの名無しさん
07/04/01 19:03:28
Ｏ原ネタ振れよｗｗ
277:・∀・）っ-○◎●
07/04/01 19:35:46
>>272
アホすｗｗｗ
>>270
SSE2じゃなくてSSEまでのサポートで使えるけど。
CMOVならPentium Pro以上が要求される。
Pentium/PMMXは切り捨ててよくてPPro/P2は切り捨てちゃだめって基準は理解できない。
CMOVは対応する組み込み関数あったっけ？コンパイルオプションやインライン
ASMくらいしか使う手段なかったと思うが。
どうせSSE未サポートのx86互換チップなんて今後発売される見込み無いんだし
x64ではSSE2までは標準ISAに入ってるんだから覚えておいていいと思うけど。
ハードウェアの投機実行機構に任せるより下手すりゃ遅くなるような
ビットマスク生成とかの厨コーディングより、いま市場に出回ってるCPUの
大半で使える最速の方法を知ってたほうがよっぽど役に立つだろ。
278:デフォルトの名無しさん
07/04/01 19:53:13
この粘着力は酉付いてなくても真性だとわかる
279:デフォルトの名無しさん
07/04/01 20:33:12
MACヲタもそうだが酉なしで粘着する奴はもう一線越えてるからな
280:デフォルトの名無しさん
07/04/01 20:38:45
無能よかまし
無能は情報として価値が無い
281:デフォルトの名無しさん
07/04/01 20:42:30
>>270が言ってるのはset命令だろ。
そこでSSEとかCMOVとか言ってる時点で話が見えてない。
CMOVの組み込み関数はVCの64bitモードになかったっけ。
32bitで使えないならあんま意味ないけどな。
282:デフォルトの名無しさん
07/04/01 21:15:58
無能は価値がないけど嘘吐きは有害
283:デフォルトの名無しさん
07/04/01 21:27:04
>>280
>>282
なんかヤなことでもあったのか？
284:・∀・）っ-○◎●
07/04/01 21:34:37
>>281の脳内では「条件付きMOV」と「CMOV」は別モノらしい
set命令って何？
_mm_set_ssならmovssに展開されるだけだよ。
むろんemmintrin.hなんて要求されない
285:・∀・）っ-○◎●
07/04/01 21:37:20
>>282
だよね。SSEしか要求しないのに生成コードすら読まずに
SSE2だなんていう嘘つきは要らない子だね。
286:デフォルトの名無しさん
07/04/01 21:46:07
今日付いたレスは全部嘘
287:・∀・）っ-○◎●
07/04/01 21:55:15
インラインASM的にはこうか？
__asm {
movss xmm0, DWORD PTR [a]
movss xmm1, DWORD PTR [b]
movss xmm2, xmm0
maxss xmm0, xmm1
minss xmm2, xmm1
movss DWORD PTR [min], xmm0
movss DWORD PTR [max], xmm2
}
x87スタック←→XMMレジスタは普通の方法使えばメモリに書き出して読み直すので
その分オーバーヘッドが生じるが、
arch=sseでコンパイルしてれば浮動小数演算はほとんどXMMレジスタ上で行うことができる。
んで、SSE2命令なんてどこに必要なの？ねぇ、教えて？
>>286
だよね。「SSE2が必要」ってのはどーみても綿貫ネタだよね。
288:デフォルトの名無しさん
07/04/01 22:01:37
>>284
SETcc r/m8
289:・∀・）っ-○◎●
07/04/01 22:24:59
mov eax, [a]
mov edx, [b]
sub eax edx
setg（以下まんどくせ。movsxって結構オーバーヘッドなかったっけ？
MMXまんせー（uint32のとき
Core2とかならXMMレジスタ使った方がいいかもよEMMSのオーバーヘッド省けるし
movd mm0, [a]
movd mm1, [b]
movd mm2, mm0
pcmpgtd mm0, mm1
pand mm2, mm0
pandn mm0, mm1
movd [max], mm2
movd [min], mm0
emms
290:デフォルトの名無しさん
07/04/01 22:37:26
このグラフの目盛は13クロック前後かな?
URLﾘﾝｸ(pc.watch.impress.co.jp)
291:デフォルトの名無しさん
07/04/02 00:46:40
相当な粘着だな
292:デフォルトの名無しさん
07/04/02 01:30:13
うちの団子が粘着でごめんなさいm(＿)m
293:デフォルトの名無しさん
07/04/02 01:33:03
粘りけのない団子なんて食えたもんじゃない
294:デフォルトの名無しさん
07/04/02 01:35:07
と背景雑音どもが申しております
295:デフォルトの名無しさん
07/04/02 01:38:50
_, ._
（ ﾟ Дﾟ）
( つ旦O
と＿)_)
296:デフォルトの名無しさん
07/04/02 10:24:01
SET命令やビット命令を最後に使ったのは何時だったか
297:デフォルトの名無しさん
07/04/02 16:21:18
つまらん事で荒れたのを久々に見たなぁ・・・
スレ違いだ他池ボケで済むだけなのに。
298:デフォルトの名無しさん
07/04/02 17:31:52
スレ違いな質問にも答えずにはいられないのが教えたがり君クオリティ
299:デフォルトの名無しさん
07/04/03 00:09:42
おまえらがつまらんことやってるからWolfdaleのESベンチの結果が違うスレに貼られたじゃないか
300:デフォルトの名無しさん
07/04/03 00:24:54
速ｗ
ｽﾚﾘﾝｸ(mac板:608番)
301:1 ◆.MeromIYCE
07/04/03 12:45:37
>>238
これは嬉しい！
>>300
速すぎて、クロック測定ルーチンがポシャってないか不安なくらい。
Intel、45nmプロセスの次期CPU「Penryn」の詳細を公開
URLﾘﾝｸ(pc.watch.impress.co.jp)
とりあえずMeromとの比較まとめ。
L2キャッシュは1.5倍の6MB、12MB版もあり。ダイサイズは25%縮小。新たにSSE4が載る。
SSEのShuffle系の命令の遅さが改善される。
整数/FP共に除算の性能が上がる。FPUの平方根も高速化。
FSBクロックが上がり、プリフェッチにも手が入る。
省電力機能のDPD、シングルスレッド性能のためのEDA。
Yonahの消費電力はなぜ少ないのか
URLﾘﾝｸ(pc.watch.impress.co.jp)
Deep Power Downは、YonahのEnhanced Deeper Sleepと何が違うんだ？
まさか、YonahのDC4ステートがMeromになかったのか。
Enhanced Dynamic Accelerationは、IDAの改良版だろうか。
"Radix 16"の16は何だろう。>>300を見ると相変わらず8bit単位でクロック数が変わっている。
命令のデコードが速くなるという記述もあるが、divのuOP数も減るのか？
今までは ちまちまやっていたのを、16bitいっぺんにやるから速いということかね。
引きずってる弱点もあるだろうけど、十分に洗練されてきたと感じる。
302:デフォルトの名無しさん
07/04/03 13:41:42
>>301
＞"Radix 16"の16は何だろう。
見えてきたPenryuとNehalemの「革新性」 (1/2)
URLﾘﾝｸ(plusd.itmedia.co.jp)
で元麻布の言ってる事が確かなら、「基数を16にした除算器（Radix-16 divider）」
しかし予想外に新要素が多いね。
シュリンク+SSE4ぐらいかと思ってたんだが。
こらAMDきつくなりそう…
303:1 ◆.MeromIYCE
07/04/03 14:40:04
>>302
基数が16ってのは16進法で筆算するような感じなのかな。
クロック数の変動から、256進法と思っていたが、単に商を8bitで区切って
その区切りごとに演算を早目に終わるという感じか。
Nehalemは、単純にIPCで見て素直な上がり方をするのかなあ。
P6と違う味のするコアでPenrynを完全に超えてくれたら嬉しい。
304:デフォルトの名無しさん
07/04/03 16:31:14
つまりは４ビット単位の部分商を一気に計算してるんだろ
305:デフォルトの名無しさん
07/04/03 20:13:26
>>301
>速すぎて、クロック測定ルーチンがポシャってないか不安なくらい。
>>128のMeromの半分だし妥当では?
>Deep Power Downは、YonahのEnhanced Deeper Sleepと何が違うんだ？
>まさか、YonahのDC4ステートがMeromになかったのか。
>Yonahの消費電力はなぜ少ないのか
>URLﾘﾝｸ(pc.watch.impress.co.jp)
>その段階に入ると、Yonahは、新たに設けられたEnhanced Deeper Sleep「DC4」と呼ばれるステイトに入る。
>これは、Deeper Sleepよりさらに電圧を下げるステイトだ。
>Enhanced Deeper Sleepでは、CPUコアを再起動しないですむ、コア保持(Core retention)レベルに最低限必要な電圧にまで下げる。
スライドを見る限りではこのコア保持レベルより更に電圧を下げるという話みたいね。
306:・∀・）っ-○◎●
07/04/03 21:49:44
自習で暇だったからランダムなfloat値1億個の入った配列を読み出して
最大値と最小値を求めるプログラム書いて時間潰してた。
案の定だが、SSEベクトル＞SSEスカラ＞＞＞＞＞＞x87
fcmov*って大して速くないんだな
307:デフォルトの名無しさん
07/04/03 22:54:19
こいつは半端に知識ある癖してどこまで理解出来てるのかさっぱりだな。
CMOVは速いんじゃなくて最悪の状態でも遅くなりにくいんだぞ。
原理くらい知ってるだろうに。
308:・∀・）っ-○◎●
07/04/04 05:09:26
うん、それで？
309:デフォルトの名無しさん
07/04/04 06:49:23
>>307
稚拙な煽りだな。
310:デフォルトの名無しさん
07/04/04 07:39:57
落ち着け。つくづく痛い子だな。
306は内容が無いだろ。チラシの裏にでも書くんでなければせめて分り切った事でも考察入れろと。
311:・∀・）っ-○◎●
07/04/04 07:51:45
こんなもんで
せろり2GHz
x87+CMOV 1100msec
SSE(スカラ) 320msec
SSE(ベクタ) 230msec
312:デフォルトの名無しさん
07/04/04 21:21:14
80/32(bit)より遅いね。
doubleの場合と分岐を使う場合はどうだろう。
313:1 ◆.MeromIYCE
07/04/06 23:39:33
>>190のを試すのと、fsqrtとfdivのレイテンシ測定をやりたいんだが、
何かやる気出ないなあ・・・。
NehalemにはSMTが載るらしいが、数年後なら4～16スレッドに
備える意味があると踏んだのだろうか。
まあ、サーバー用途とかだろうけど。
SMTの効果だが、NetBurstと同等くらいはあるのではないだろうか。
ネトバは元々スカスカだから、SMTで資源を有効利用できる。
とはいえ、SSEのレイテンシで見ると、実はCore2よりもネトバの方が
スループットに対してレイテンシが短い（パイプライン充填率が高い）。
Nehalemでは、きっちり4命令/clkをコンスタントに供給してくるだろうし。
これはつまり、Core2の効率が悪いと言っていることになるが、
実際にあれだけ強化したCore2がK8の20%増ししか速くないのだから、
発揮できていない潜在パワーはかなりあるはずだ。
（これは別にCore2の設計が悪いという意味ではない）
314:・∀・）っ-○◎●
07/04/06 23:48:21
命令フェッチ帯域が狭いからそれを拡充しないことにはね（Penrynでは改良してくるはず）
315:1 ◆.MeromIYCE
07/04/07 00:09:44
>>305
え、コア保持しないん！？
>>311
float1億個といったら400MBじゃんか。
それでもメモリネックにならないのか。
cmovは１個に20clk以上かかってるぞ。
比較-フラグ-移動のレイテンシが長いんだろうなあ。
いずれしても、これからの時代はFPUを使う意味がないね。
316:・∀・）っ-○◎●
07/04/07 01:05:52
ちなみにCで書いてコンパイルしただけ。（SSEだけIntrinsicsを利用）
っていうかISAがスタックベースだからどうしても命令が多くなるのでしょう
一方SSEだとこんだけ。
movss xmm2, [ecx+Offset]
maxss xmm0, xmm2
minss xmm1, xmm2
ちなみに手動でアンロールしたら同じ環境でスカラ280ms, ベクタ200msくらいになった。
キャッシュは128KBだしFSBは400MHｚ、メモリはよくわからん。
プリフェッチは使ってない（てかあんま意味なさそう）
317:デフォルトの名無しさん
07/04/07 05:48:00
ソース希望。
って、SSE版は掲載済みか。
318:・∀・）っ-○◎●
07/04/07 09:08:29
ループの内側はこんだけ。
//FP版
if (a[i] > fMax) fMax = a[i];
else if (a[i] < fMin) fMin = a[i];
//SSEスカラ版
__m128 sa = _mm_load_ss(&a[i])
xmax = _mm_max_ss(xmax, sa);
xmin = _mm_max_ss(xmin, sa);
//SSEベクタ版
__m128 pa = _mm_load_ps(&a[i])
xmax = _mm_max_ps(xmax, pa);
xmin = _mm_max_ps(xmin, pa);
319:317
07/04/07 09:29:14
お、THX!
それはいいけど、いい加減そのメルアドはやめなさいよ。
320:・∀・）っ-○◎●
07/04/07 10:04:21
どうでもいいけど_mm_min*だな
321:デフォルトの名無しさん
07/04/09 13:16:33
折角だから実測してみた。
>Intel(R) Xeon(TM) CPU 3.40GHz [fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl est tm2 cid xtpr]
>gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
>gcc -O3 -std=c99
if (p[ic] > vMax) vMax = p[ic];
if (p[ic] < vMin) vMin = p[ic];
0.61 sec #fucomして普通にjne/jmpで分岐
if (p[ic] > vMax) vMax = p[ic];
else if (p[ic] < vMin) vMin = p[ic];
0.64 sec #fucomしてあっちこっちにjmp
>gcc -msse2 -O3 -std=c99
if (p[ic] > vMax) vMax = p[ic];
if (p[ic] < vMin) vMin = p[ic];
0.91 sec #fucomiしてfcmovnbe
if (p[ic] > vMax) vMax = p[ic];
else if (p[ic] < vMin) vMin = p[ic];
0.90 sec #maxはfucomiして普通に分岐、minはfucomiしてfcmovnbe
__m128 tmp = _mm_load_ss(& p[ic]);
xMax = _mm_max_ss(xMax, tmp);
xMin = _mm_min_ss(xMin, tmp);
0.18 sec #movss, maxss, minss
__m128 tmp = _mm_load_ps(& p[ic]);
xMax = _mm_max_ps(xMax, tmp);
xMin = _mm_min_ps(xMin, tmp);
0.13 sec #movaps, maxps, minps
SSEの方はどっちも>311とは綺麗にクロック比になっている辺り。
それから察すると、>311はホントにfcmov使ってたんだろか。
つーか、fcmov遅過ぎ。