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

1 名前：1 ◆.MeromIYCE mailto:sage [2007/01/10(水) 12:32:46 ] ゆるゆる〜っと実測していきましょう。 過去ログ x86命令の所要クロック計測スレPart2 pc10.2ch.net/test/read.cgi/tech/1136527588/l50 x86命令の所要クロック計測スレ pc8.2ch.net/test/read.cgi/tech/1103609337/l50 関連スレ アセンブラ…　(゜□゜) ↑アッー！↓ pc10.2ch.net/test/read.cgi/tech/1148402614/l50 MMX SSE 3D NOW!のプログラミング pc10.2ch.net/test/read.cgi/tech/1085749218/l50 CPUアーキテクチャについて語れ 5 pc9.2ch.net/test/read.cgi/jisaku/1159238563/l50 【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】 pc9.2ch.net/test/read.cgi/notepc/1160039483/l50 もしくは、自作板にて「次世代」でスレタイ検索 まとめサイト（過去ログ置き場） www.wikihouse.com/x86clocker/index.php?FrontPage 2 名前：1 ◆.MeromIYCE mailto:sage [2007/01/10(水) 12:33:18 ] 関連サイト（日本語） コピペで動くVC++のインラインアセンブラ例 www.fides.dti.ne.jp/~tokai/vc/mmxab2.html 基本的な整数命令/スタックの使い方 ray.sakura.ne.jp/asm/ FPUやMMX,SSEの命令解説など。最適化の色々な話がある homepage1.nifty.com/herumi/adv.html pentopt（古）の日本語訳など hp.vector.co.jp/authors/VA003988/ Intelの日本語技術資料のダウンロード www.intel.com/jp/developer/download/index.htm 関連サイト（英語） Intelの最適化マニュアル（Core2についても載ってる） developer.intel.com/products/processor/manuals/index.htm Software Optimization Guide for AMD64 Processors www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7203,00.html Intel向け最適化手法やクロックテーブル、testp.zipで手軽にrdpmcが使える www.agner.org/optimize/ 各CPUのレイテンシ-スループットの表（K7K8あり） swox.com/doc/x86-timing.pdf x86CPUの各種データシート www.sandpile.org/ AMD CodeAnalyst Performance Analyzer、AMD用パイプラインの様子がわかるシミュレータ developer.amd.com/downloads.jsp CPU関係の記事が読めるかもしれない場所 pc.watch.impress.co.jp/ www.geocities.jp/andosprocinfo/ mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html 3 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 14:51:35 ] 　　　　　　　　　　ヽ　/ /⌒＼ 　　　　　　　　 ／ヽヽ|/⌒＼ii|＼ 　　　　　　　／ ／ヾゞ//／＼＼| 　　　　　　　|／　　 |;;;;;;|/ハ　＼| 　　　　　　　　 　 　 |;;;;/／⌒ヽ 　　　　　　　　 　 　 |;/（　＾ω＾） >>1おっおっおっ乙枯ー .　　　　　　　　　　　|｛　∪　　∪ 　　　　　　　　 　 　 |;;ヾ.,____,ノ 　　　　　　　　 　 　 |;;; | 　　　　　　　　 　 　 |;;;;;| 　　　　　　　　 　 　 |;;;;;| 4 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 16:41:55 ] >>1 STARGA乙ERS 5 名前：1 ◆.MeromIYCE mailto:sage実は500KBを狙っていた [2007/01/11(木) 13:23:52 ] 前スレ埋まりました。 6 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 21:01:08 ] GJ! 7 名前：デフォルトの名無しさん mailto:sage [2007/01/12(金) 16:01:16 ] 2ch閉鎖したらどーすんの？ 8 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 00:37:09 ] 大原が入稿してからついに一週間経つのにまだ掲載されてないなんて サボりすぎってレベルじゃねーぞ 9 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/14(日) 02:32:10 ] 珍しいなム板で500KB制限って ただでさえ長文とソースコードの多いスレだけど 10 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 21:51:15 ] 第189回 Core MicroArchitectureをもうすこし(13) journal.mycom.co.jp/column/sopinion/189/ やっと5日入稿分が来たよ 相変わらずこのスレ見てるな 11 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 22:00:42 ] このスレとは関係ないけど > 例えば昨年のComputexでMobile向け新コアの説明がちょっとあったが、Memory Controllerと > Hyper Transport Linkのみがモバイルに最適化されたという話で、コアそのものはK8L(というか、 > Revision H世代?)と共通になってゆく模様だ。 そのリンク先を見る限りモバイル向けコアはK8Lとは違うように見えるのだが… 12 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 23:17:12 ] サーバーを意識した設計だがRASは無い 13 名前：1 ◆.MeromIYCE mailto:sage [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 mailto:sage [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 mailto:sage [2007/01/17(水) 18:51:26 ] IA32 x86 JITアセンブラ Xbyak homepage1.nifty.com/herumi/soft/xbyak.html 動的アセンブル。なかなか使いやすそう。 mov(ecx, n); などと関数にしてしまう実装が面白い。 でも、いざ使おうと思うと、何に使ったらいいかわからないな。 自己書き換えよりは安全でスマートな方法だが、 定数部分の自己書き換えの範疇を超えた使い方があれば面白い。 16 名前：デフォルトの名無しさん mailto:sage [2007/01/17(水) 20:48:36 ] 計算式や正規表現のようなユーザから来る可変な表現からプログラムを生成。 17 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 03:40:29 ] Cの関数のような表記のアセンブラといえば、CELLのもそうじゃなかったっけ? #つーか、あれは関数表記のインラインアセンブラなのかも知らんが。 18 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 03:59:06 ] そりゃIntrinsicsじゃないのか？ ttp://en.wikipedia.org/wiki/Intrinsic_function VC++のMMX/SSE対応とか。 19 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/18(木) 06:52:49 ] あれはもともとIntelコンパイラの組み込み関数 CellのはCode WarriorのAltiVec拡張と同じ構文ルールだが あちらは「演算子」なんだな。 Cで「関数」のオーバーライドはサポートしてないはずだ。 たとえばvec_addもしくはspu_addはvector int とvector shortでは別の操作になる 20 名前：1 ◆.MeromIYCE mailto:sage [2007/01/18(木) 23:53:42 ] >>16 正規表現か。難しそうだな。 結局、定数書き換え以上のことやろうとすると、コンパイラみたいなのを 自作してプログラムに入れないといけないんだよな。 ぶっちゃけ定数埋め込みだけでも意義は大きいと思うし、 最後に0.99をかける処理をする/しないの選択みたいな要素が8個あれば 高速化を考えれば普通なら256通りのコードを用意する必要があるわけだから、 そういうのに使ってもいい。 >>17 べつにmov(ecx, n); でmov ecx, n を実行するわけじゃなくて、 将来実行するコードにmov ecx, n のマシン語を追加しているのだ。 単なる表記法の話とは違う。 21 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 00:23:01 ] >20 callが並べられれば既に最適化されている一連の関数をどういった順序で、ないし、どういったパラメータで呼ぶかが決められる。 比較処理の削減、BTBの節約程度にしかならんがな。 22 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/19(金) 00:53:26 ] 正規表現は動的にDFAを構築するlazy evaluationがナウなヤングにバカウケ （言語処理系だとHaskellとかに使われてるね） 現実には後方参照とか量指定とかのリッチな機能使いたがるから 一意に定まる部分文字列をBoyer-Moore法などを用いて先行して評価し NFAを評価するほうが主流なんだよな これは鬼車なんかが使ってる。 自己書き換えでNFAのバックトラッキングを高速に処理するとかできれば 理想だけど、まあ無理だ罠。 とにかくメモリレイテンシが重要。 ＃投機スレッディングが有効かと思ったり 23 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 01:38:34 ] 第190回 Core MicroArchitectureをもうすこし journal.mycom.co.jp/column/sopinion/190/ 24 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/21(日) 03:07:36 ] > そうなると、そうすると もちつけｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ 最近仕事が粗いな つーか、リオーダバッファが96エントリもあれば局所的なユニット不足って 十分解消できると思うんだがね俺の考えでは ROBを深くしてロード命令を先行して実行してれば たいがいのコードって つーか、リオーダバッファが96エントリもあれば局所的なロードユニット不足って 十分解消できると思うんだがね そのためにMemory disambiguationがある。 ストア命令が一個もないループなんぞ【逸】般的でしかない。 64bitではSSE2までは標準命令セットだから、そのへんの実行効率についても 検証していただきたいところだね。 25 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/21(日) 03:21:32 ] 俺くどいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ 26 名前：デフォルトの名無しさん [2007/01/21(日) 04:13:03 ] 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の差があるので、 あたらずも遠からずかな。 27 名前：デフォルトの名無しさん [2007/01/21(日) 04:15:27 ] つづき 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倍に達することになるが。 長々と書いたが、半分大原氏に向けて書いたつもり。 ここをみてる様だから。 参考文献 www.sandpile.org/index.htm 28 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 07:39:11 ] 大原なんてどうでも良い もちっと突っ込んだ話に進めよう 29 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [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 mailto:sage [2007/01/21(日) 15:12:30 ] その上整数パイプラインとFP/SIMDパイプラインに分かれてる。 32 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 15:26:22 ] その代わりK8はスレッド数が増えても急激な性能の低下はないね。 Core2はコア数×2スレッド以上になると急に遅くなる。 33 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 15:29:39 ] ソース希望。共有キャッシュだから若干遅くなるのは予想できるが、 具体的にどれくらい? 34 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/21(日) 15:34:56 ] 単純に1スレッドだけだと2MB〜4MBのキャッシュを占有できるからじゃないの？ なにが原因があるのかは知らないが コンテクストスイッチングに弱点があるとして HyperThreadingとマルチコア化で同時処理スレッド数を稼ぐ方針だから 差し引きオッケーになるんじゃねーの 35 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 16:08:42 ] 何言ってんの？K8といえば今やX2だろう。 38 名前：1 ◆.MeromIYCE mailto:sage [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 mailto:sage [2007/01/21(日) 23:37:33 ] K8では整数パイプとFP/SIMDパイプにディスパッチする手前でデコードしてたのを K8Lではディスパッチ後にデコードするようになってる。 このへんってどんな効果あるんだろ 40 名前：1 ◆.MeromIYCE mailto:sage [2007/01/21(日) 23:51:02 ] >>39 SIMDの方にディスパッチしてから64bit単位で命令を解釈し、 ある程度トランジスタを割いてうまくスケジュールして、 同じピークSIMD性能のCore2を超える実性能を叩き出す、 というのが俺の希望だが、実際どうだろね。 ディスパッチ前の命令の単位が64bitから128bitに変わったことが 影響していると考えていいと思うけど。 41 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 02:02:48 ] Intelerお久 43 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 03:57:13 ] どこが優っていて、どこが劣っているとか、 それは最終的には関係なく、結果叩きだされる性能が指標なわけで… 最近のベンチマーク結果にメモリ帯域とか、レイテンシ計測が出てくる不思議さ。 なんというか、100M決勝で10M加速を比べられているような… IPCもその意味をなすことが今後は難しいんじゃないですかね? 大原記事はこれから読むw 44 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 04:25:04 ] 読んだ。 AMDのCPUは実行IPC3で常に回っていて(脳内or観測的希望) intelのCPUはIPC4を謳ってい入るがそんなわけねーよ(AMD比)pgr、ということなのか… 瞬間風速だとしても、それを出せない回路でその数字を謳うのはある種詐欺なわけで、 たとえ一瞬だとしてもそれが出せることは大いに喜ぶべきことなのでは? (その宣伝を気に入る、気に入らないという話ではないこと前提でｗ) それを意識するあまり平均性能が落ちるとかならいざ知らず、 ほとんどのベンチマークで勝っているわけで、without メモリコントローラ。 45 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 10:40:18 ] おはようございます。 なんだよ、観測的希望ってw やっぱり眠い時レスしちゃダメなんですね。 大原氏ごめんね。 46 名前：1 ◆.MeromIYCE mailto:sage [2007/01/22(月) 14:20:45 ] >>43 論旨には賛同するが、メモリ帯域やレイテンシ計測は是非やって欲しいよ。 もちろん、そういう計測をそのままCPUの性能と思ってしまうのは論外だが、 「自分はこの処理をさせたいが、どのCPUがいいだろう？」と思ったときに 一般アプリの実性能ベンチだけではイマイチ検討のしようがない。 まあ、こういうのは最近の流行りじゃないんだろうねぇ。 確かに俺も、とりあえず帯域ベンチやっときましたみたいな記事を見ると、 色々誤解が広まりそうで嫌な感じはする。 47 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 17:20:36 ] CPUの性能を調べることと素性を調べることの差って感じか 48 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 17:55:49 ] 周波数特性だけで盲目的に音質を語るな 49 名前：1 ◆.MeromIYCE mailto:sage [2007/01/22(月) 19:03:17 ] >>47 そうだね。 あと、ベンチって結果から製品を選ぶのが目的と見せかけて むしろ好奇心を満たすものという面が大きい。 性能より素性を知りたい人が少ないってのが寂しい。 >>48 そういう意味じゃ、CPUは速いのが正義だから、まだ簡単だ。 MP3とACCの比較とか、ありゃあ泥沼になるわけだ。 50 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 19:32:31 ] マルチコアはいつから使えるコアになるのか？ www.ne.jp/asahi/comp/tarusan/main155.htm 51 名前：1 ◆.MeromIYCE mailto:sageハイパー・ブロッサム [2007/01/22(月) 20:12:17 ] >>50 実際にどっちを買うべきかという話ではなくて、CPUメーカーがシングルコア路線を続けた方が 動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話だね。 結局、俺は使ったことがないからわからないんだよな。 それに、Pen4からCore2Duoに乗り換えた人は、 Coreアーキだから速いのか、デュアルコアだから速いのか、Pen4が遅かっただけなのか、 何が原因だか容易には知ることができないだろう。 俺は前から、体感したYonahの速さからデュアルコアをすすめる人の多くが、 CoreSoloでも同じ速さを感じるのではないかと思っていたが、これも確かめるのが難しい。 一方、Intelとすれば、シングルでも非常に高速なYonahやConroeで デュアルコアをスタートさせたため、商売としては成功したと言えるだろう。 （いや、ネトバのデュアルはスタート以前というか・・・それでもエンコは強かった） 52 名前：デフォルトの名無しさん mailto:sage [2007/01/22(月) 20:47:04 ] >CPUメーカーがシングルコア路線を続けた方が動画エンコしない一般ユーザーは（今までは）幸せだったんじゃないかという話 IntelはメニーコアのマイルストーンとしてAdaptability(適応性)ってのを挙げてる。 シングルコア強化路線「だけ」ではムーアの法則に追随できないから、 まず前提としてシングルスレッド性能の強化があって、 その開発期間の隙間を埋めるのがコアの増加なんだと思う。 例えばDMTなんか65nmに微細化した今でも実装されてないし。 53 名前：1 ◆.MeromIYCE mailto:sage [2007/01/22(月) 21:27:29 ] >>52 AdaptabilityやDMTの意味がわからないが、 前提となるコストと熱設計の中で最も性能の高いものを作るだけじゃないの？ 開発期間の隙間と言っても、開発が済んだらコアを減らすわけでもないだろうし。 54 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 01:46:26 ] Speculative MultiThreadingによってILPの壁を突き破れるようになるまで シングル、マルチを無駄に意識させられるんだと思われ。 ILPを挙げるのに、これ以上トランジスタと電力に投資するのが非効率だから TLPを意識しましょうっていうのは実際逃げだろうけど、 タイタニックじゃないけど、逃げなきゃいけない状況(それ以上の解が見つからない状況)なのに 意固地に頑張る必要もないはず。 メモリレイテンシの隠蔽の効果が、めいっぱい頑張ったシングルコアを超えずとも 良い勝負かつ、より低消費電力ならそっちが正解だと思う。 そういう点から、例え現状しょうがなく目指したとしても、 むこうに今よりもbetterな解があるならそれで良いジャマイカ派。 55 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 02:29:49 ] SpMTが高めるのはMLPだ。 "ILPの壁を突き破る"という表現はおかしい。 56 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 04:35:11 ] ILPという言葉に関しては、一つのスレッドに対して使う言葉なのかな。 並列性の高まるスレッドが別であることに対しては無効であるなら認識不足だった。 勉強になります。 ttp://ja.wikipedia.org/wiki/ILP これ読む限りじゃ、投機実行もILPを高める手法の一つにはカウントされてる模様。 57 名前：1 ◆.MeromIYCE mailto:sage [2007/01/23(火) 16:12:57 ] >>56 > Speculative MultiThreadingによってILPの壁を突き破れるようになる の「ILPの壁」というのは、「シングルスレッド処理のIPC向上の壁」と言えばいいんじゃない？ ILPと言うと、メモリ以外の命令同士の依存関係を何とかするみたいな感じを受けるから。 ＃メモリアクセスもI（命令）だと言われればそうだけど。 俺は、メモリ以外のILPの問題の方が本質的だと思うので、ここではILPという言葉は使わない。 手動でプリフェッチすれば同等の性能が出るであろう技術には個人的に萌えない。 しかし、SpMTによって、手動でprefetch命令を入れたのに匹敵する効果が得られるなら、 これこそプログラマに優しい、「逃げない」技術なのかもしれないとも思った。 > 投機実行 それは、文脈からして条件分岐命令に対する投機実行のことだから、 投機的マルチスレッディングとは関係ないと思われる。 >>54 逃げなきゃいけない状況なら逃げないといけないね。 何事もバランス、中庸。 >>53ではああ言ったが、最後の2行は同意。単純に対応ソフトの普及促進にもなるし。 58 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 19:59:29 ] AMD Rev.F Processor には、RDTSCPという命令が追加されているらしいな ttp://www.atmarkit.co.jp/flinux/rensai/watch2006/watch07a.html 59 名前：デフォルトの名無しさん mailto:sage [2007/01/27(土) 19:25:36 ] >>27 journal.mycom.co.jp/articles/2005/07/14/yonah/002.html Coppermine 1394万 Banias 2038万 Dothan 2676万 Yonah 1918+1918万 60 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/27(土) 21:07:17 ] 大腹自身の記事かよｗ 61 名前：デフォルトの名無しさん [2007/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 mailto:sage [2007/01/28(日) 01:05:20 ] Pentium Mは4トランジスタじゃなかったっけ ってソースがこれだったｗｗｗｗ journal.mycom.co.jp/special/2004/dothan/001.html 大原氏は記事書く際はちゃんとウラを取って欲しいな 63 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 16:02:55 ] まあ大原もここのスレ住人も、ほとんどが確たるウラをとらずに好き 放題発言しているだけだけどな。５０歩１００歩じゃねーか？ ソースを張っても、そのソースが本当に正しいかウラが取れてるわけ じゃない場合が多いし。ソースが大原記事なんてのがその典型ｗ 64 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 17:27:01 ] PenMが4トランジスタSRAMってのは間違い。 大原自身が訂正してたよ。 6トランジスタです。 65 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 17:29:57 ] そろそろclock計測の話題に戻ろうよ。 ここは実験と実証のスレで、理屈と情報、妄想だけのスレなんて他所にたくさんあるわけだし。 66 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/28(日) 18:13:52 ] 素人が個人ブログや掲示板に自己満足記事投稿するのと 企業から金貰って大衆に読んで貰うための記事をかくのと 全然影響力・説得力が違うがね。 67 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 18:36:11 ] クロック数計測してもTr数はわからんし。 ――大事なのは素材ではなくその精神なのです。 68 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 18:49:20 ] >>66 大企業メディアの情報の質、正確性、量、速度が 個人サイトの集合を上回っているとはいえなくなりつつある ネット社会の現代、こういうライター稼業のなんてもう流行らないのかも。 しかし、それにしても国内のハードウエアレビューは質が低い。 AnandTechやTom's, INQなどは個人サイトが反映しても死ぬ気がしないんだけど、 国内ではそのような優良サイトがない。情報も一方的だし、ライターの記事は情報が少なく、遅い。 69 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 22:35:46 ] この計算はあってるの？ 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 名前：デフォルトの名無しさん mailto:sage [2007/01/28(日) 23:07:10 ] 第191回 Core MicroArchitectureをもうすこし(15) journal.mycom.co.jp/column/sopinion/191/ 71 名前：デフォルトの名無しさん mailto:sage [2007/01/29(月) 02:38:23 ] >>70 なんかどうみても、これスレを読んでいて、且つこのスレに対して 言い訳してるようにしか読めないな。 大原氏には悪いけど。 72 名前：デフォルトの名無しさん mailto:sage [2007/01/29(月) 02:50:03 ] >>70 話の持っていきかたの無理矢理感が・・・・・ 73 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/29(月) 02:59:02 ] どんな下手な書き方してもIPC=3を出せるハードという意味なら永久に無理に決まってる。 ソフト側も「IPC=3を出せるコード」であることが前提。 74 名前：デフォルトの名無しさん mailto:sage [2007/01/29(月) 03:14:52 ] そこでEPIC 75 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/01/29(月) 03:45:05 ] 4IPCを狙ったアーキじゃないって論は云々はどっちかというと この人の記事を読んで真に受けただけじゃなかろうか 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 mailto:sage [2007/01/29(月) 06:45:21 ] キャッシュラインサイズが256Bというのもその辺考えてるのかもな。 77 名前：デフォルトの名無しさん mailto:sage [2007/01/29(月) 17:55:37 ] >>76 キャッシュラインサイズが256Bって何？ 78 名前：デフォルトの名無しさん mailto:sage [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でロードのアウトオブオーダー発行が実装されるが、 どの程度のアウトオブオーダーなのか、またそれによってどの程度性能が向上するのか、 楽しみではある。 計測情報源：www.realworldtech.com/forums/index.cfm?action=detail&id=73407&threadid=73407&roomid=11 79 名前：デフォルトの名無しさん mailto:sage [2007/01/30(火) 05:36:05 ] 今回のは何を言いたいのかさっぱい伝わってこないのだが… これなら昔の電波の方がよっぽど読み応えがあったｗ 80 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 20:10:09 ] pc.watch.impress.co.jp/docs/2007/0131/ubiq170.htm これらのプロセッサでは、Coreマイクロアーキテクチャとしては初めて Hyper-Threading Technology(HTテクノロジ)をサポートすることになる 81 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 22:45:47 ] Penryn does not have HT www.theinquirer.net/default.aspx?article=37316 82 名前：デフォルトの名無しさん mailto:sage [2007/02/01(木) 02:07:56 ] grape.astron.s.u-tokyo.ac.jp/~makino/journal/journal-2007-01.html#30 むーん、オールジャパンってそういう話か、というか、それはそうなん だけど、そんなので計算機作れるのかよ、、、 83 名前：デフォルトの名無しさん mailto:sage [2007/02/01(木) 04:32:35 ] Vista 64bit版も出た事だし、そろそろx86-64の話題が欲しいですね。 スレ違いか？ 84 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/02/04(日) 15:21:39 ] 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 名前：デフォルトの名無しさん mailto:sage [2007/02/04(日) 22:47:06 ] 第192回 Core MicroArchitectureをもうすこし(16) journal.mycom.co.jp/column/sopinion/192/ 86 名前：・∀・）っ-○◎● ◆DanGorION6 mailto:sage [2007/02/04(日) 22:57:40 ] 　　ま　た　2　ち　ゃ　ん　ソ　ー　ス　か 87 名前：デフォルトの名無しさん mailto:sage [2007/02/04(日) 23:13:12 ] > Penrynの世代でHyper-Threadingが搭載されるという。 ( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ 88 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 00:31:26 ] 今回のこれは大原を弄るのは酷かもな… ネタの正確性はともかく言ってること自体は間違ってないというか、同意できる つーかYorkfieldの中身が変更されたと判明した後もガセネタ流し続けたCharlie Demerjianは死ねｗ 89 名前：デフォルトの名無しさん [2007/02/05(月) 01:17:24 ] 409 ：名称未設定 ：2007/02/02(金) 17:22:28 ID:I0BGTsMO0 journal.mycom.co.jp/news/2007/02/02/400.html journal.mycom.co.jp/photo/news/2007/02/02/Photo10l.jpg 生ハムメロンワロスｗ 90 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 01:42:10 ] つーか、なんか論点がずれてるというか、大雑把な主張になってきたな。 もともとIPC=3を技術的に細かく検証しているはずだった気がするが、 いつのまにか 「発熱や消費電力が上がる関係でIPC=3は無理です」 になってる。 なら最初からそう言って終わっとけば良かった気がするが… 91 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 01:59:27 ] このシリーズはいつまで続くんじゃー！ 92 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 02:05:06 ] Core2がIPC=4じゃないとする主張の理由の中に K8がIPC=3であると思わせる部分がある時点で 大原記事wwwとなるのは明白。 93 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 04:56:57 ] 元々はCoreMAとK8のIPC向上に対するアプローチの違いを言いたかったような気がするが。 細かく突っ込んでいって逆に全体像が見えなくなった感じだな。 94 名前：1 ◆.MeromIYCE mailto:sage実測しなきゃorz [2007/02/05(月) 19:11:14 ] >>89 Meromと果物のmelonをかけてるのだろうか？ Penrynに、L2キャッシュ増量とSSE4実装以外の目立った改善があるのか気になるね。 遅くなるプリフィックスと64bitでのマクロフュージョン、シャッフル系SSE命令などが考えられる。 まあ、このうち１つも対応されない可能性も大きいとは思うが。 命令フェッチ幅を32byteにするのはいずれ必要だけど、Penrynの次のアーキ辺りが妥当か。 95 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 19:14:56 ] Windows生ハム 96 名前：デフォルトの名無しさん mailto:sage [2007/02/05(月) 22:51:33 ] AMDの方は L3キャッシュだろ。もうどうなる事やら。 97 名前：デフォルトの名無しさん mailto:sage [2007/02/06(火) 00:03:52 ] トランジスタ増やしすぎたらいくら微細化してるとしても クロック上げるのも難しいと思うのですよねぇ 98 名前：デフォルトの名無しさん mailto:sage [2007/02/06(火) 02:25:15 ] そういえばK8LのL3は面積からしてZ-RAMじゃないな 大原妄想乙でした 99 名前：1 ◆.MeromIYCE mailto:sage [2007/02/06(火) 07:04:51 ] 初代スレの398でやったdivのレイテンシ測定をするプログラムを作ったので、 色々なCPUで試してみてくださいまし。 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 名前：デフォルトの名無しさん mailto:sage [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

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef