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

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

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

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

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

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

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

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

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

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

3 :デフォルトの名無しさん:2007/01/10(水) 14:51:35
          ヽ / /⌒\
         /ヽヽ|/⌒\ii|\
       / /ヾゞ///\\|
       |/   |;;;;;;|/ハ \|
             |;;;;//⌒ヽ
             |;/( ^ω^) >>1おっおっおっ乙枯ー
.           |{ ∪  ∪
             |;;ヾ.,____,ノ
             |;;; |
             |;;;;;|
             |;;;;;|



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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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


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

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

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

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




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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大原氏には悪いけど。

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  ま た 2 ち ゃ ん ソ ー ス か



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

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

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

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

生ハムメロンワロスw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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


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

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

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

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

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


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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

長かったな…

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


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



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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)