AMDの次世代CPUについて語ろう 5次世代

■公式ロードマップ
製品ロードマップ （短期）
ttp://www.amdcompare.com/prodoutlook/
テクノロジ・ロードマップ （3年）
ttp://www.amdcompare.com/techoutlook/
■前スレ
4 http://pc7.2ch.net/test/read.cgi/jisaku/1145187468/
3 http://pc7.2ch.net/test/read.cgi/jisaku/1138983969/
2 http://pc7.2ch.net/test/read.cgi/jisaku/1133374045/
1 http://pc7.2ch.net/test/read.cgi/jisaku/1124542812/
自作板AMD系スレッド過去ログ保存サイト様
http://amd.jisakuita.net/
■関連スレ
【CRISC】CPUアーキテクチャについて語れ【EPIC】3
http://pc7.2ch.net/test/read.cgi/jisaku/1139046363/
Intelの次世代CPUについて語ろう 25
http://pc7.2ch.net/test/read.cgi/jisaku/1147545560/

＿＿＿_
＼.＿　 | 荒らし・煽り・厨房は放置が一番。
／|＿|　| 釣られずにスルーしましょう。
|＿／＼! sage進行でマターリいきましょう。

Rev. Fの次の次に来るAMDの次世代コア「Hound」
http://pc.watch.impress.co.jp/docs/2006/0531/kaigai273.htm

拡大が進むAMDのコプロセッサ構想
http://pc.watch.impress.co.jp/docs/2006/0601/kaigai275.htm

設計のモジュラー化で市場に最適化したCPUコアを〜AMDの新戦略(1)
http://pc.watch.impress.co.jp/docs/2006/0616/kaigai282.htm

いちおうそれっぽい記事はっとく。
前スレにアドレス貼れなかったorz

>>1
乙

すまない…目の前に1000があったからつい取ってしまった。
ROMに戻るお

998 名前：Socket774[sage] 投稿日：2006/06/16(金) 02:42:37 ID:15wyeOAX
>>996
uOPsに分解された結果は、同じだよ。
もちろん、それでも速く終わる命令はパイプラインの中で時間が経つのを待ってる。

999 名前：Socket774[sage] 投稿日：2006/06/16(金) 02:43:49 ID:15wyeOAX
>>997
ストア命令が続く場合は依存るすよ。


依存がないようにコードを組むのが命令レベル並列化っていうんですが？



とりあえず「リタイアステージ」の目的を説明してくれ。
GRとFP/MMの実行パイプライン段数の違いがあると並列実行できない理由もな。

というかVTuneやCodeAnalist使ったこと無いだろドシロトが

＞CodeAnalist
アナルの達人ですか？ｗ

依存のないように組むと言われてもなぁ、変な組み方したら間違った結果のでるCPUは要らないしなぁ。

依存のある組み方したら逐次実行されるだけだろ。
大丈夫か？

一概にそうとも言えない。
まあ出てないCPUであれこれ言うのもなんだが、、、
プレスコなんかNetburstという重力に縛られた哀れなCPUだったし
K8Lがそうならないことを祈るしかない。

AMD儲のいつもの流れ


Aという技術がプロセッサ業界等で採用され始める（業界のトレンド）
→視野が狭いので知りもしない

オタ「Aという技術が他で採用されてるす。AMDもいずれ採用するんじゃないすかね」
→うざい。そんなわけないだろ

インテルがA技術の採用を発表する（インテル儲にとってトレンド）
→これだからインテルはｗ

AMDがA技術の採用を検討し始める
→これからはAの時代だ！（ここがAMD儲のいうトレンド）


もっと広い世界に目を向けるべきだと思うす

>999 名前：Socket774[sage] 投稿日：2006/06/16(金) 02:43:49 ID:15wyeOAX
>>>997
>ストア命令が続く場合は依存るすよ。

同系統の命令が続くってことは、その続いた命令は、順番に実行されるだけで、
追い越しは無いでしょ

もう無理やりですな

> 設計のモジュラー化で市場に最適化したCPUコア
> ttp://pc.watch.impress.co.jp/docs/2006/0616/kaigai282.htm

各回路のモジュラー化が進んでいる為、AMDは簡単にモジュールの拡張が可能だという内容。
で、その成果がFPUの128bit化・・・
よく見ると・・・64bit x 2・・・・これってプレスコットが32bit x 2で動作しているとか言って騒いでいたのに似てる。
K8Lはどうやらパッチモンのようですよ。

やっぱりコプロセッサは他社まかせか
もうIntelはAMPの試作と評価を終えてるのに大丈夫なんだろうか

>>11のPhil Hester(フィル・へスター)氏の真の写真（これは似非ではありません）
> http://i-bbs.sijex.net/imageDisp.jsp?id=ups1&file=1150407427793o.jpg

>>11
モノシリックな設計

物知りっく

ID:15wyeOAXは録音先生なので

よーし、おじさん（Phil Hester）は、モジュラー化の特徴を生かして頑張るぞ。
Ｋ８のFPUモジュールをもうひとつ横にくっつけて・・・・
片方のスケジューラはつぶして、片方のこれとあれをつないで・・・・・
あれれ、上手くいかない・・・・・ああ、もっと簡単に簡単に・・・ダブルで取り込めば・・・・
で、できた１２８bitFPUユニット完成でーす、これで性能は２倍だぁ(まだ確認してないけど・・)
よーし、これ発表しちゃえ!!!

http://pc7.2ch.net/test/read.cgi/jisaku/1150010642/

872 名前：Socket774[sage] 投稿日：2006/06/16(金) 00:09:52 ID:15wyeOAX
エンドユーザーにとってみれば、常に競争し、勝ち組みなしで価格が下がり性能だけが向上するのが望ましい。
しかし、それは目先の利だけである、競争が激化しコストだけが上昇し利益が出ないのであれば、企業は競争をやめてしまう。
儲からぬのに多額のコストを投下する理由がなくなるからだな。
つまり、常に競争して欲しければ勝ち組みに十分な利益を提供するしかない。
1年から4年程度はINTELの一人勝ちで良いのだろうよ。



特徴のある文体ですなぁ
彼を見続けてる人にはわかりますよね？
ほくそ笑みながら見守ってあげましょう

「INTEL」（笑）

普通、命令の依存関係をチェックして、依存関係のない命令を実行パイプに並列投入するのが
スケジューラの役割だったような・・・これはOut-Of-Orderの基本概念で別にK8独自のものじゃないし。

NetBurstのALUは倍速実行のおかげで、同じ実行パイプに投入される命令ならゆるい依存関係は
許容されるんだったっけ？
まだ、NetBurstの夢から覚めないのかな？

>>15はマ板でよく見る厨房
お前も録音と同じステージだってことに（ ﾟДﾟ）気づけよ

マ板じゃなくてム板だろ

ム板だけでなくあちこちで
知ったか→集中砲火→逆ギレ→ゴマすり
ネトナン→弄ばれ→しつこくナンパ→放置→逆ギレ
を繰り返し日々有名になっている奴

ノート自慢のために自作をけなしまくっていたのは記憶に古い
そんな奴がここに来るなんて、Mｦとか録とか5の重力に引き寄せられたのか？

K8Lのダイフォトの解析を見る限りでは、FP系ユニットは全て64bitづつで
左右に分かれてるように見えるんだが。

「SSE1整数」が今まで同様、独立した2個のm64ユニットとしても
2つ合わせて1個のm128iユニットだとしても動くフレキシブル仕様なら
同じように並べられてる浮動小数系ユニットも独立して動かすことが
出来ても不思議じゃない。むしろ簡単に出来そうだ。

つまりSSE*スカラやx87演算において加減算同士・積算同士での並列実行を
可能にすることで、Coreアーキに対する強みになる。
もちろん128bit×2のロード帯域もだが。

ただし命令帯域の縛りがあるから、あくまでピーク性能を出せるのは
128bitFP加減算＋積算の並列実行の時と思われ。

SSE*整数ユニットを増強しないとすれば、糞団子の指摘どおり
64bitモードでの汎用整数の活用で十分なスループットは
出せるようにするからと思われ。

そもそも（固定小数として）パックド整数を使うのはここ最近のゲームや
エンコーダでは流行らないし、浮動小数にフォーカスしたほうが
全体としては有利になる筈。

いずれにしてもK8Lが出るまではSSE対応ソフトではCore2のほうが
圧倒的に優勢だろうから、AMD的問題はそれまでどう乗り切るか、だわな。
幸いIntelはCore2の総入れ替えには時間を要し、暫くミッドレンジ以下では
NetBurstの在庫一掃セールだから、低価格帯では十分戦える。
マルチプロセッサ構成の鯖ならOpteronの優位を揺るがすにはまだ至らないはず。

32B Instruction Fetch

糞団子
だけ呼んだ

>>19
>NetBurstのALUは倍速実行のおかげで、同じ実行パイプに投入される命令ならゆるい依存関係は
>許容されるんだったっけ？
普通にレジスタリネーミングしてるんじゃねーの？

インテルのCore2 XEは消費電力が高過ぎ、ワット性能も低いのにくらべて、
AMD社の一部のデュアルコアプロセッサは消費電力もインテルのシングルコアのCore Solo未満となっており、
インテル社のCPUはもう使い物にならない時代が到来しております。
私自身はメーカー名にかかわらず良い物を買う派だったのですが、
もうインテル製品は買えないほど、インテルは堕落してしまいました。
AMDは不安定と言う人もなかにはいますが、それはチップセットメーカの怠慢であり 、
AMDは良いプロセッサのみを作り続ける職人派であるといえます 。AMDは直接的には関係ありません。
そもそも大半の不具合はユーザーが余分に投資すれば解決できるものばかりです。
Intelの推進するIA-64はAMD64にとってかわられ、はっきりいって最早未来はありません。

インテルさようなら

>>27
なに？　このコピペ流行ってるの？

K8LがK8ｱｰｷの拡張、L2はconflictの除去に専念を考慮してキャッシュ構造の仮説を考えてみた。
L1とL3が排他であり、たとえばコア1のL1に読み込まれると共有L3にはデータはなくなる。
だから、その際コア2-4のL2にコア1にデータが読み込まれたことを記録するんじゃないかな。
コア1は、L3にデータを書き込む場合は、自分のL2にそのことを記録する。
実はL2の正体は、流動していくデータのアドレスのみを記録するためのものである。
こう考えると、L1,L2,L3のすべてに対して同時にリクエストかけられるよね？

コア1がL1,L2,L3にリクエストして、L2でヒットもしくはヒットがなかった場合は以下のようになるのかな？
L2にヒット→該当コアにアクセス→そのコアがL1,L2にリクエスト→L1にヒット→コア1にデータを送る
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　→L2にヒット→コア1にL3のアドレスを送る→コア1がL3にリクエスト
ヒットなし→メインメモリにアクセス→L1に直接読み込み→コア2-4のL2にそのことを記録？

いや、L3無しの構成もとれることから

>>29
そんなに遅くしてどうする気だ(笑

相変わらず読み難い長文が平気で垂れ流されてるスレですね。

>>26
真の依存性はレジスタリネーミングじゃ解決できない
倍速ALUはそのための工夫ではある

参考：↓の「ハザードとリネーミング」
http://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%B8%E3%82%B9%E3%82%BF%E3%83%BB%E3%83%AA%E3%83%8D%E3%83%BC%E3%83%9F%E3%83%B3%E3%82%B0


漏れはメリットの小ささ（OoO-CPUでRAWひっかかりまくりのプログラムってどんなんだ？）に比べて
デメリット（クロックが倍の部分を作るために電力↑↑）が大き杉だと思うけど

要は、L1とL3の関係は今まで通り。ただ、L3の容量増大と共有によってレイテンシが増加するかも
L1とL3が排他であるから、特定のコアがデータを持って行くと、他のコアが参照した場合に困る
どのコアが持って行ったか記録しとけば、全部のコアに問い合わせなくてもすむからレイテンシが減るし、関係ないコアがじゃまされることもない
これなら、少なくとも性能の低下はないのか
以下、ご批判をどうぞｗ

>>34
何度も言わせるな、遅くなるだけだ。

>>26
ちなみに参照したのはここ。
ttp://www.atmarkit.co.jp/fpc/special/pentium4arch/pentium4arch01.html

AMDはコンロー出てくるまでは、自ら価格を落とす必要はなしと判断しているのでしょう。
コンロー前に2.8G売り切って、コンロー出たら、FXを貯めておいた3Gにして、
2.8Gまでは対抗出来る(生産出来るだけの量が売れる)価格まで下げる。

65nm立ち上げまでは生産量増えませんから、今のシェアキープでしょうね。
65nm立ち上がった時点で、クロックUPと低価格で攻勢開始。Houndで追撃ってところでしょうか。

キャッシュ量は、メモリーIFのレイテンシを削減する設計なので、あんまり載せても効果は薄いでしょう。
むしろ、IntelがAMDに対抗するために大量のキャッシュを搭載せざるを得なくなってると見るべき。

結局CPUコア性能でもキャッシュの容量＆性能でも、Intelに対抗する手段が
不透明ってのが現状なのかな。

ハイエンドサーバーは当分大丈夫だとしたら、あとはデスクトップ＆モバイル
だが、廉価デスクトップとモバイル用にPCI-Ex4（x2でも可？）直結のCPUなん
てどうかなあ？

GPUを直結出来れば性能（特にUMA時）で有利になるし、確かHTをノース／サウス
接続に使ってるnVidiaのサウスチップがそのまま使えるし。確かAMDの方針とし
てもmobileは別コアにする筈だから、これにだけPCI-Eを載せるなら不都合は無い
訳だし。

問題はローエンドデスクトップが、ミッド＆ハイエンドデスクトップと別MBに
なるという、Socket754/939 の問題を再現しかねない点かな？

↑良く考えると「AMD EfficeonII」だな、コリャ。（汗

ConroeのOC耐性は凄い、空冷4GHzも可能だ。
AMDが65nmで少々クロックを上げた程度では全く追い付けない。
> ttp://www.xtremesystems.org/forums/showthread.php?t=103381

Conroeの４GHzはAMD社の最新CPUの５GHzに匹敵する。

情報を鵜呑みにして踊らされる人の典型。

>>38
http://www.atitech.ca/products/mobilityradeonx1800/specs.html
｜Native PCI Express x16 bus interface

Mobileでもハイエンドも含めるには、x16が必要って事ですね。

性能の低いGPUだと x8 や x4 でも充分かどうか、何故かスペック頁に載って
なかったですが、フル稼働しない場合の省エネ動作として、x4やx8動作（非動作
部分はスタンバイさせる）は、CPUで必要そうな気がします。

>>41
まだ売られてないんだし、発売前に踊っても買えないから問題ないお
発売後に期待通りだったらまた踊り続ければいいんだお（　＾ω＾）

AMD苦難の時代だな
まぁここ数年苦しみ続けてきたインテルを思えばまだマシか

>>44
>>37
全然苦難の時代じゃないしインテルのようにひどい製品を広告力だけで売るようなことは出来ない。
なぜならAMDには性能的に劣るものでも盲信して買うような厨なファンがいないから。
64シリーズは地道に賢い消費者を味方につけて売り上げを伸ばしてきた。
AMDだろうがインテルだろうが、よいものを見抜ける目を持ったものたちなのである。
へたな製品を出すならまったく売れないだろう。
また、AM2とコンローを比べてAMDが終わったというバカがいるがそうではない。
AM2は単にDDR2導入のためのマイナーチェンジでCPU的には何の変化もない。
それでも低電圧や低価格、すでに所持しているものにとってはDDR2が流用できるなど魅力も多い。
コンローは今までも最も優れたCPUではないかと言われていたPentiumMのニコイチの進化形。
インテルは最悪なCPUとなってしまったPentium4をようやく捨て、まったく新しい路線で起死回生を狙ったのである。
つまり、まだ発売すらしていないコンローと現行のAM2を比べるのは間違い。
AMDが次に出してくる65nm製品やHoundと比較すべきものである。

> なぜならAMDには性能的に劣るものでも盲信して買うような厨なファンがいないから。
2chの自作板に住み着くアム厨がいる。
AM2はConroeよりも圧倒的に性能が悪いのは明白だ、でも買うやつはいるw

CPU単体の性能では完全に今はintelターンだな。
元々、お互い半分ずれた周期でアーキテクチャを更新してるから当然の結果ではあるが。

だが、商業的にはどうだろうな。
Opteronの躍進、AMD64の採用、電力効率&マルチコアへの路線転換etc・・・と企業戦略としては
完全にintelは後手に回ってるし、Fab36の稼動で薄利多売と高利少売を両立できる体制も出来た。
独占禁止法関連でintelへの牽制も少しずつだが効いて来てる。

この状況で投資家がどう動くかが鍵かもしれんが・・・

> 元々、お互い半分ずれた周期でアーキテクチャを更新してるから当然の結果ではあるが。
AMDはAthlon64発表以来殆ど進化していないのだが・・・

>>48
SSE3対応、HyperTransport2.0、DualCore化、DDR2対応は進化じゃないのか？

だとしたら、NetBurstも2000年11月の発表以来、大きな変化はPrescottだけでそれ以外は
FSBクロック向上とキャッシュ増量という力技で進化とは言えんな。
強いて言うならHyperThreadingくらいだが、あれも最初から組み込まれてた機能をONにしただけで
OFFのままの中途半端なものを買わされた連中がバカを見ただけに過ぎん。
PrescottはSSE3を除けば果たして改良といえるかどうか・・・ある意味、あれがNetBurstにトドメを刺したとも言えるしな。

他の分野では既にあるとはいえ、DualCoreという構造的にも大きな変化がある分、まだ進化と言えると思うがな。

いずれにせよ、基本アーキテクチャの開発→市場への投入→小改良→・・・というサイクルはほぼ半周ずれだから、
しばらくはAMDも今までと同じようにはいかんだろうが・・・K8でバス周りを真っ先に改良しておいたのは正解だろうな。

>>49
全然というか、全く進化とは言えない。

４：主観で決め付ける

>>50
ならConroeも全く進化してないと言うべきだな。
ステッピングが示す通り、単なるP6の改良に過ぎん。
バスはクロックこそ上げてるがNetBurstの流用だし、ComplexDecoder+SimpleDecoderという構成や
パイプラインの基本構造もP6そのもの。

改良が進化じゃないなら、P6vsK7は昔から何も変わらないことになる。
一度、NetBurstに進化(個人的には退化だが・・・)しておきながら、P6に舞い戻ってきてるんだから退化かもな。

>パイプラインの基本構造
これは詳細発表されたんですか?
良ければ詳細キボン。

>>51
客観的事実だ。
設計は何も変わっていない。

>>52
詭弁は聞き飽きた。

P6とK7は兄弟みたいなもんだと言う人もいるからね。
Conroeの改良点がもたらした効果というのは、そのままK8にも適用できる訳だ。
このあたりは学会なんかでアイデアそのものは昔からあるものがほとんどで、実装には
特許だの権利だのといった制限が付けにくいし。

あとは匙加減の問題だな。
ピーク重視になりがちなintelと平均値や最低値の底上げを重視するAMDではそのあたりは
かなり違うからね。

> P6とK7は兄弟みたいなもんだと言う人もいるからね。
というか、K7はP6の真似っ子に過ぎないし、K8はK7を拡張したバージョンだ。
この拡張は結構優れていたが、K8Lは急増の産物でしかなさそうで予定している程の成果は難しいだろうな。

>>54
どっちが詭弁なんだか。
K8のSSE3対応、マルチコア化、DDR2対応などの一連の改良を進化じゃないと言い張るなら、
NetBurstやBanias系の同様の改良も進化じゃないと言うことになるのは当然じゃないか。

どうでもいい
3年前に遅れに遅れて出した3200+や、P4 3.2GHzを未だに高値で売り続けるAMDとIntelがDQNってことでいいよ

問題はどちらが先にこの状況を脱するか、だ

AMDとインテル、方向性が違っていて面白い
もともと会社の規模や文化からして違うんだし、いいと思う
AMDのコプロがどこまで普及するかが見物

L1とL3とでレイテンシの差が有る、L3が共用、L1がコアごとに別という構造なら、
L1とL3とを排他にすることをやめればいい。
排他にしなけりゃ、読んだことで内容が変わることも無いから読んだときのタグ付
は要らなくなる。単純に、書き込んだときに、どのコアが書き換えたかのタグ付を
するだけでよい、読むコアが自分以外のタグを見たら再度読み直すという単純な
動作だけで済む。

>>56
今のx86系CPU自体が、RISC系プロセッサとかがとっくに通過した技術の流用に過ぎないんだから、
真似がどうのと言うのは無意味。

>>61
自作板なんて、井の中の蛙の住処なんだから突っ込んじゃかわいそうよ

シェアが少ないのに俺等がシェア握ってるんだと勘違いする人も居て困る。

1週間前の漏れとか(　ﾟ∀ﾟ)<ﾌﾟｯﾌﾟｰ

>>57
> K8のSSE3対応、マルチコア化、DDR2対応などの一連の改良を進化じゃないと言い張る

進化ではないな。
SSE3対応は、拡張命令セットへの対応でしかない。
マルチコア化は元々の設計がマルチコア前提だから進化とは言えない。
DDR2対応も、単に新メモリへの対応に過ぎない。

進化の欠片すらない。

毎回思うんだが「〜に対応しただけ」を進化じゃないと言うなら
何を進化という尺度に入れるんだろう…

常識的には実回路の増強や新たな設計を進化というのだろうね。
アム厨はは信者が多いから常識が通じなくて困るな。

ふーん。まあそれで良いんじゃね。
俺は信者同士の対決見てるのが楽しいからもっと適当な話題で盛り上がっててくれ。

>>60
それは読み込みに行くときは常にL3まで確認しに行くということか？

K8LのL3キャッシュについて言えば、現在までの議論を総合すると、
前スレの809以上に高性能なキャッシュになる発言は全く出ていないな。
もっとも、前スレの809もなんちゃってキャッシュでしかないけどな。

> AMDの次世代CPUについて語ろう 4次世代
> http://pc7.2ch.net/test/read.cgi/jisaku/1145187468/809

これまでのまとめ。

K8LのL3はL1L2と完全な排他構造となる。
排他構造とする理由はL1L2が排他構造で各コア毎に独立したキャッシュを持つから、L3を積んでもL1L2を走査した後に、
他コアへのL1L2の照会(コヒーレンシ制御の為)を必要とするから、L3は出来るだけL1L2と排他なキャッシュである方が効率が良くなるからだ。
不完全な排他構造の疑惑が>>801に書かれているが、上記のようにL1L2の走査後に必ず他コアへの照会がある為、L3は完全排他構造を維持できる。
次に、L3はダーティキャッシュ(破棄時にメモリへの書き込みが必要なキャッシュ)を含まない。
ダーティキャッシュの書き込みはL2より破棄されるときに行われる。
これにより、L3はメモリが保持するデータの写しでありヒットすればそれなりにレイテンシが向上するという性質を持つ。
他スロットのL3とのコヒーレンシ制御は厳密である必要がなく(ダーティキャッシュを含まないし、共有制御はL1L2のみで良い)照会パケットは送らない構造だと思われる。
この為、L3と実メモリは同時にアクセス可能となる。

ふーやっと解析終了・・・長かったぜ。

>>64
＞進化の欠片すらない。
よくそういうこと言えるね。君がAMDの幹部だったらそうはしなかった、とでも言うつもり？

つーか、そもそも進化なんて言葉はこのドッグイヤーな業界には大げさすぎるよ。分かりやすく進歩でいいよ。
俺は「〜に対応しただけ」でも十分な進歩だと思うし。

ああ、俺様がAthlon64の開発チームにいたらとっくの昔に進化しているな。
まずは、デュアルコア化が当たり前になる状況なら排他キャッシュを廃止し高性能なL2共有キャッシュを開発するね。

>>71=64
じゃ今からでも遅くない、入社してくれ。頼むぜ

あんな糞な会社にはヘッドハントされても行かないよ。

君の場合はヘッドじゃなくてテールというか

(トカゲ)テールカット

>>71
はいはい。>>37と>>45を1000回読んで土下座してね。

>>75
どこで電波拾ったか知らないがFXの3GHzを出したところでE6600にすら勝てないのは明白なんだよ。

ま、キャッシュをいくら強化してもI/Oには効かないからな・・・

同一チップ内のコヒーレンシ制御で若干有利な程度で、ソケット間のコヒーレンシ制御にはほとんど無効、
ソケット間でしか共有してないデータでもキャッシュが共有になってるおかげで、共有データを参照していない
無関係なコアもコヒーレンシ制御に巻き込まれるというところか。

K8LのL3共有キャッシュは、コヒーレンシ制御には全く恩恵ないけどな。
自コア内のL1L2でキャッシュエラーのときは他コア全てで照会(L1L2走査)が必要。
もっとも、今始まったことではなく前からずっとだけどな。

で、キャッシュ性能が悪いからL2の走査も時間がかかるっと・・・

ttp://hissi.dyndns.ws/read.php/jisaku/20060620/REx4a1VQQmM.html

>>78
一つ聞いていいか？
毎度毎度「走査」と言ってる様だが、お前の理解している「走査」ってのは、具体的に何をやってるんだ？
キャッシュに対して「走査」するというのがどうもイメージ出来ないんで、説明頼む。

>>78
L1L2でキャッシュエラーが起きたコアだけキャッシュをフラッシュすりゃいいだけじゃね？
他のコアはそのまま走る。

既出かもしれないけど、K8L

ttp://www.theinquirer.net/?article=32424
ttp://www.chip-architect.com/news/K8L_floorplan.jpg

なにこのおやじ

COMPUTEX TAIPEI 2006 - AMDの次世代テクノロジを探る、CTO・Phil Hester氏インタビュー
ttp://journal.mycom.co.jp/articles/2006/06/20/computex01/
大原雄介と後藤弘茂との共同インタビューだそうですよ。
現在の出てる情報の確認ってかんじですねぇ。

K8 の L3 の悪口言ってるインテラーは、Itanium (Montecito) の悪口言ってる
ことにもなるんだがなあ。
Montecito も L2 は分離、L3 は共有。もっとも Montecito の場合は L3 は
間違いなく Inclusive だろうけど。
ただし、インテラーが繰り返し言ってる

> 自コア内のL1L2でキャッシュエラーのときは他コア全てで照会(L1L2走査)が必要。

ってゆうのは Montecito でも同じ。
別にこれは排他キャッシュの特徴じゃないよ。

シングルスレッド性能が重要なデスクトップでは、L2 共有は当然の解だけど、
サーバの場合はそうとも言い切れないのねえ。

別に悪口は言ってない、事実を喋っているだけだ。
InclusiveなL3共有キャッシュを有している場合、L1L2L3でキャッシュエラーなら同一ソケット内のコアへの照会は不要だ。

アホか。

別コアの L1 が dirty なデータを持ってたら、その L1 に
照会するしかなかろう。
Write Thorugh キャッシュしかなかった大昔じゃあるまいし、
Write Back キャッシュが当たり前の現代では、別コアの
L1, L2 に照会する必要があるのは、Montecito だろうが、
Core Duo だろうが同じ。

いつまでも寝言を書き続けてて、恥ずかしくならんのか？

>>87
アホはお前w
InclusiveなL3共有キャッシュを有しているのだから、L3キャッシュエラーの時点で同一ソケット上のL1L2の全てがキャッシュ保持されていないことが判明している。

で、もし L3 キャッシュにあることが分かったら、それから L1 や L2 に
問い合わせするわけ？
そうすると、L3 ヒット時のレイテンシは、L3 問い合わせ + L1/L2 問い合わせ
になるわけだ。それって遅いじゃん。

レイテンシのことをちゃんと考えて作れば、L3 への問い合わせと L1/L2 への
問い合わせは並列に行なうように作るはず。そうすれば、L3 ミスヒット時も、
L3 ヒット時も効率は変わらん。排他キャッシュだろうが、そうでなかろうが、
速度は変わらん。
それぐらいのことも分からんの？
本当にアホ？

>>89
> で、もし L3 キャッシュにあることが分かったら、それから L1 や L2 に
> 問い合わせするわけ？
> そうすると、L3 ヒット時のレイテンシは、L3 問い合わせ + L1/L2 問い合わせ
> になるわけだ。それって遅いじゃん。

ほい、そのとおり。

> レイテンシのことをちゃんと考えて作れば、L3 への問い合わせと L1/L2 への
> 問い合わせは並列に行なうように作るはず。
そんな馬鹿なことはしない、逆に遅くなってしまう。

L3共有キャッシュは便利だが、L1L2より遅いこと前提で設計されている。

> それぐらいのことも分からんの？
> 本当にアホ？
アホはお前だってばw

> > レイテンシのことをちゃんと考えて作れば、L3 への問い合わせと L1/L2 への
> > 問い合わせは並列に行なうように作るはず。

> そんな馬鹿なことはしない、逆に遅くなってしまう。
> L3共有キャッシュは便利だが、L1L2より遅いこと前提で設計されている。

はあ？
遅くなるわけないじゃん。
先に結果が分かればその結果だけ利用して、遅れてきた結果は捨てれば
いいんだから。本物のバカですなあ。

実際、Conroe のキャッシュの宣伝項目にある Direct L1 to L1 cache
transfer って、まさにそういう技術だろ。
インテラーって、インテルの技術も知らんのか。

話がK8のL2ロードレイテンシが比較的長いことを前提にしてる時点で寝言だよな。

通常、ロードレイテンシはキャッシュに対してアドレスの照会を行い、ヒットしたデータのロード完了まで
の時間だから、アドレス照会まででヒットが無ければ大した時間はかからん。

L2=512KByte/Mem=512MByteを前提条件とした場合なら、キャッシュがメモリ上のデータを保持している
確率は1/1024だから、照会でロードレイテンシと同等の時間が必要になるケースなど極僅かだ。

> 話がK8のL2ロードレイテンシが比較的長いことを前提にしてる時点で寝言だよな。
前提になどしていない、その為に敢て走査と書いてある。
これはヒットしない場合が多いこと前提としている。

>>91
お前は喋らない方がいい、知能が低すぎる。
そのことは>>87でもわかる。

>>87 って、どこかおかしい？
L3 にヒットした場合、L1 や L2 に問い合わせて、ダーティなデータを
抱えてるかどうか確認しなきゃいけないのは確かだよね。

> 通常、ロードレイテンシはキャッシュに対してアドレスの照会を行い、ヒットしたデータのロード完了まで
> の時間だから、アドレス照会まででヒットが無ければ大した時間はかからん。
> L2=512KByte/Mem=512MByteを前提条件とした場合なら、キャッシュがメモリ上のデータを保持している
> 確率は1/1024だから、照会でロードレイテンシと同等の時間が必要になるケースなど極僅かだ。

見るべき視点が間違っている。
キャッシュエラーによる照会が多発することで、各コアに大きな負担が掛ることを忘れている。
１コアだけのロードレイテンシを見てたらダメだなw
全てのコアが稼働状態にあるときの負荷を気にしてくれよ。

>>95
87は86に対しての発言としては不適当だ、それは既に>>88に書いてある。
>>88を失念していた様が見て取れる。
ついでにいうと、>>89は>>86の失態をごまかす為に書かれていると見るのが普通だよw

>>94
そしてお前の知能はさらにその下だ（爆
どのレスを見てもそれは明白（核爆

そもそも俺は最初の書き込みで Inclusive って書いてるんだから、
>>88を失念するなんてことが不可能なのは明白だと思うのだが。
L3 への問い合わせと L1/L2 への問い合わせを並列して行なえば、
>>88 のケースでもレイテンシの悪化などは起きないんだが、まだ
分かってないのか。

で、結局 >>91 にはまともな反論を思いつかないから知能が低過ぎると
中傷するしか手がないわけね。かわいそうな奴だなあ。

>>99
他コアへの照会数が増えることをお前は無視している。
他コアからの照会が発生すると、自コアの作業を止めて先に照会に対する返信を行わねばいけない。
これが、4コア同時に発生することとなり負荷は大きくなる。
それをお前は失念している。

で、L1L2は各コア独立しており、L1L2でヒットした場合は、共有フラグが立っていなければ他コアへの照会は不要だ。
L3共有キャッシュを搭載する目的としてキャッシュエラー時の照会パケットを減らす目的があることを忘れないでくれ。
各コアの基本キャッシュはL1L2であることもしっかりと理解しておけ。

でだ、K8Lの場合は、L3がL1L2と完全排他構造にするのが都合がいい。
でその場合、L3とメモリーは同時アクセスが可能とな。
このような特性になるが、コヒーレンシの軽減には全く役に立たないものであると言ってるだけだ。
その意味で、なんちゃって共有キャッシュとなる。

> 他コアへの照会数が増えることをお前は無視している。
> 他コアからの照会が発生すると、自コアの作業を止めて先に照会に対する返
> 信を行わねばいけない。

それは単純に間違い。
ひょっとしてソフトウェアエンジニアでハードウェアのことを全く知らない人？
ソフトウェアの場合、あるスレッドが作業を行なっている間は、そのスレッドは
他の作業を行なうことができない。
しかし、ハードウェアなら、物理的にトランジスタや配線さえ増やせば、
他の作業を止めることなく、並列に作業を行なうことができる。
ソフトウェアでスレッドを増やすのと同じことだが。

> それは単純に間違い。
そりゃ凄いw
おもいっきり笑ってしまったぞ。
で、おまえの妄想を聞かせてくれ。

単に配線をするだけの話だよ。
まあ Conroe の宣伝文句を実装しようとすると、L1 のポート数を増やす
必要があるので、それはそれなりに大変な話だが、今回の K8L の話なら、
ttp://journal.mycom.co.jp/articles/2006/06/20/computex01/001.html
の図2を見れば分かる通り、あるコアから、L3 への問い合わせと
別のコアの L1/L2 への問い合わせは、クロスバーに経由で別の経路を
通るので、並列に発行しても何の問題もないことが分かる。
配線はちゃんとあるわけ。

つまり、あんたよりも、AMD の設計陣の方が賢いと。
あたりまえだけどね。

さて、アホ君は放置で・・・

>>84
> COMPUTEX TAIPEI 2006 - AMDの次世代テクノロジを探る、CTO・Phil Hester氏インタビュー
> ttp://journal.mycom.co.jp/articles/2006/06/20/computex01/

> --ところでL2キャッシュのサイズが1MBから512KBに減ったわけですが、これは何故でしょう?
> キャッシュシステムのモデリングを行って、各コアがどのくらいのサイズのL2を持ったときに
> 最も良いシステムパフォーマンスを発揮できるかを検討した。その結果、
> L2に1MBを搭載すると(各L2のコヒーレンシ確保のために)L3やクロスバーの負荷が高まるという結論が出ている。

面白いことが書かれている。
L2を小さくした方が、コヒーレンシ制御で有利という趣旨である。
これは下手にL2を大きくして、照会パケットによりヒットするよりは、L2を小さくしてL3へ吐き出し(ダーティ時はメモリへも吐き出すことでクリーン化する)
L2ではヒットせずにL3でのヒットのほうが有利との発言だ。
このようにCTO・Phil Hester氏もまた、コヒーレンシの悪化を気にしているのである。
ここらが、なんちゃってL3共有キャッシュの真髄といえるかもなw

> これは下手にL2を大きくして、照会パケットによりヒットするよりは

「各L2のコヒーレンシ確保のために」ってのを、単に照会のコストと読むわけね。
違うんじゃねえ？
L2 で共有しているラインの同期を取るためのコストじゃねえの？

K8L コアはマルチソケットにもそのまま対応したコアで、照会だけなら、
別に今回の話に限らず、HT 経由で頻繁に来てるはず。マルチソケットからの
照会に耐えられる L3 やクロスバーが、たかが他のコアからの照会に
耐えられないわけがない。

> あるコアから、L3 への問い合わせと
> 別のコアの L1/L2 への問い合わせは、クロスバーに経由で別の経路を
> 通るので、並列に発行しても何の問題もないことが分かる。

さすがアホ君だけある、他コアL1L2への照会とL3及びメモリのアクセスを同時に可能とのおバカ発言が飛び出しましたよ♪
これは非常に怖い。
他コアでL2解放の為、ダーティキャッシュをメモリへ書き込む動作と、自コアが他コアへのL2照会とメモリロードが同時アクセスするケースを
考えてみよう。
自コアのメモリロードが他コアのメモリストアより先に飛び込んだケース。
このケースのときに他コアからの返信がキャッシュ保持となってる保障はどこにもない。

> L2 で共有しているラインの同期を取るためのコストじゃねえの？
同期を取るコストなら大きい方が圧倒的に有利なのだが・・・

> さすがアホ君だけある、他コアL1L2への照会とL3及びメモリのアクセスを同時に可能

その記述には、メモリアクセスのことは一言も書いてないわけだが、
どこから空目したの？ 気でも狂った？

> 自コアのメモリロードが他コアのメモリストアより先に飛び込んだケース。

当然一貫性制御はするでしょ。
まさか、何もしないと主張してると読んだわけ？
追い詰められると、ここまで空想が激しくなるんですね。

それ以外の記述もいろいろ変だけどね。

> 他コアでL2解放の為、ダーティキャッシュをメモリへ書き込む動作と、

L2 解放したら、メモリじゃなくて、L3 に書き込むでしょ。

> 自コアが他コアへのL2照会とメモリロードが同時アクセスするケース

メモリロードを同時に発行するとは俺は一言も書いてないわけだが。
メモリのバンド幅は限られてるので、そこまではしないんでないの？
メモリの場合、どうせ100クロック近くかかるわけで、キャッシュアクセス
と同時に発行しても、隠蔽できるレイテンシはメモリアクセス全体の
コストに比べて少ないからね。

>>108
お前が書いてなくてもAMDはL3とメモリは同時アクセスすると言っている。

俺メモ：ID:qfDm/Dlb　＝　録音

俺メモ：ID:fcZeb4m3　＝　雑音粘着の屑

> 同期を取るコストなら大きい方が圧倒的に有利なのだが・・・

実装面積が限られていて、L2 と L3 を同一チップ上に載せることを
考えると、そうとは限らないでしょ。
同期をとろうとするとキャッシュライン全体をまるまる転送する必要が
あるわけで、かなり長時間かかる。それぐらいなら、L3 の容量を大きく
して共有しちまった方が効率いいでしょ。

>>112
ん?
L3を非完全排他にするのかな?
そのケースは考えられるが、あまり良い方策とは思えない。
もっとも、一番単純な拡張で済むからその可能性は高いけどな。

L3を非完全排他とするのなら112の理屈もOKだが、そうなるとL3キャッシュのヒット効率は悪化する。

> お前が書いてなくてもAMDはL3とメモリは同時アクセスすると言っている。

お、そうなのか？
ポインタきぼん。

まあどっちにしても >>106 がいろいろ変なのは変わらないけどね。
例: 一貫性制御しないと仮定、L2解放→メモリ書き込み

>>111
俺の認識だと録音はそういうのを書かないはず。　よってハズレだったか。　すまんね。

ということは、おまえ、本物（トリップは忘れた）だろ？

> L3を非完全排他にするのかな?

俺はそう思ってるよ。
そもそも、複数のコアから共有するのに、完全排他にするのは
かなり面倒でしょ。

> そうなるとL3キャッシュのヒット効率は悪化する。

そうなるね。
ここはトレードオフだけど、それでも十分L3の効果はあると思うよ。

> ポインタきぼん。
自分で探せ。

> まあどっちにしても >>106 がいろいろ変なのは変わらないけどね。
> 例: 一貫性制御しないと仮定、L2解放→メモリ書き込み
思考停止して正当化するのは良くない。

> > ポインタきぼん。

> 自分で探せ。

えー。
AMD スレのみんな。オラにポインタを分けてくれ！

# そろそろ会社行こ

亀レスだがMontecitoは非共有L3
共有L3なのはTlusaな

MACオタ,　Come　on　！

MACオタなら（略

>>116
> 俺はそう思ってるよ。
> そもそも、複数のコアから共有するのに、完全排他にするのは
> かなり面倒でしょ。
面倒というか、普通は完全排他にするけどな。
AMD社の発表を聞いていたら、完全排他にするより開発期間が優先されていると思われる。
まぁ、非完全排他だろうなw

> ここはトレードオフだけど、それでも十分L3の効果はあると思うよ。
あんまり無いのではないかな?
もちろん、L3が無いよりはマシだが、クリーンキャッシュしか保持出来ない構造は痛いし、４コア分のL2と共有される確率は高くなるから２MBでは容量が不足だな。

K8LのL3共有キャッシュが非完全排他だった場合は、なんちゃってL3共有キャッシュからも脱落し、
ベンチマーク専用L3共有キャッシュになってしまうだろう。

他コアのL1L2に保持されているキャッシュがL3共有キャッシュに存在していてもそれは無意味。
自コアのL1L2でキャッシュミス後に、他コアのL1L2照会がされるのでそこでヒットする。
つまり非完全排他だった場合は使われもしないキャッシュを大量に保持する構造であり意義は小さい。
しかし、ベンチマーク専用と言うのなら、その欠点も表面化することは少ないのでそれなりに良い結果となるだろう。

しかし・・・K8LはとんでもなCPUになりそうな予感がするのは俺だけか?

普通に性能向上を果たすと思うが
まあCoreには及ばないだろうってのはわかりきったことだし
そこら辺は4x4で対抗するということでしょ

価格次第ではハーパータウン買えって話になりそうだけど

ここで熱く議論してる香具師は、やっぱそれ関係の業界にいるの？
趣味レベルでこういう議論できる人ってあんま見ないんで…

何故だろう。ID:qfDm/Dlbのが虚言に見える。
全角英数とか使うからだろうか。
それとも内容を理解せずに書いてるように見えるからだろうか。

>>125
どのあたりに疑問があるのか言ってみれw

非完全排他にした場合、L2とだけではなくL1とも非完全にするしかないことも理解出来ているよな?
完全排他の場合は、L3への追加も削除も効率を落とすことなく行うポイントがあるが、非完全排他の場合にはそれがない。
結局のところ、L2破棄時にL3へクリーンキャッシュを追加するだけとなる、L3が満杯なら使用率の悪い古いキャッシュと置き換えるだけだ。
もちろん、既にL1へ取り込まれ更新されダーティキャッシュになる前のキャッシュまで整理されずにL3に残り続けているというありさまなんだよ。
この読まれると不味いキャッシュはL3を読む前に他コアへの照会の結果L1L2でヒットするから問題こそないがな。
非効率極まりないものでしかないんだよ。
ベンチマーク専用キャッシュとはよく言ったものだw

何を隠そう、ID:qfDm/DlbこそがK8Lの設計者だったのだ

『アホ君はほっといて』とか、『知能が低すぎｒ（ｒｙ』とか言うけど、
世の中には俺のようなバカもいるので、
4gamerの記事の様に、メイドで説明してくれなきゃ困る

もっとも悲惨なのがID:qfDm/Dlbが事実を述べているのか、
嘘っぱちを抜かしているのかが分からないことだ。

・・・俺はほとんど理解できないorz

ttp://journal.mycom.co.jp/articles/2006/06/20/computex01/001.html
|--これにより、L3とMain Memoryに同時にアクセスすることでメモリレイテンシを抑えるわけですね?
|その通りだ。

虚言に見えるのは、相手を蔑む姿勢と、「インテルのやることは素晴らしくて、AMDのやることは
つまらない」って結論以外認めない論理展開だよ。

書き込みの時間を時系列で見てくと、この議論で彼の人生がいかに浪費されているかがわかる。
議論の相手が会社に行ったりしているのと対照的に…

取り敢えず、ID:qfDm/Dlbの書き込みは独自用語とかが多くて理解不能なのが困る。
グダグダと理解不能な単語を並べず、スパっと論理回路図でも描いてどっかにUPしてくれ。
俺としては、無駄に長文書かれるよりそっちの方が解り易くて助かる。
(当然だが、論理回路にはMIL記号というきちんとした規格があるから、独自記号は無しでな。)

キャッシュの動作を語るくらいだから、それくらいはお安い御用だろ？

あと一つ気になったんだが、ID:qfDm/Dlbの言うキャッシュの「走査」ってなんだ？
単語から受ける印象だと、C言語のfor文のようにキャッシュを1lineずつ走査しているような感じだが。

K8だとL1/L2は共に64Byte/lineだから、L1で1024line・L2=512KByteでは8192lineもあるんだが？
こんなので「走査」なんかしてたらキャッシュが無い方が速いだろ・・・

技術を語る事が「目的」じゃなくて「手段」になってるからなあ
どんなに正しい事書こうが詭弁にしか見えない罠

>>130
それって、図1と違い、図2では、メモリアクセスのパスと
L3 アクセスのパスがクロスバーから見て分離されていて
同時に並列してアクセスできるって言ってるだけでは？

>>109 は、>>108 への返答だから、L3 アクセスする際には
常にメモリにも並列してアクセスすると主張しているような。
それってかなり過激な主張だと思うけど。
L3 はメモリよりもはるかにバンド幅が太いから、同じレートで
アクセスすると、メモリの側のバンド幅が溢れてとても困った
ことになるはずだよ。

>>133
お前はスキャンという単語で、総当たりと解釈し全キャッシュラインを全て読むと理解したのか?
凄く理解力だなw
一般人程度の知識と知性があれば、スキャンするキャッシュラインはアドレスによりダイレクトに決まることを理解出来るだろうし、
スキャンはWay分で済むことも理解できるのだか・・お前にそれを要求するのは無理かなw

>>135
電波ってますか?

>凄く理解力だなw
あぁ、この辺の日本語の不自由さが虚言に見えるのかもしれない。

L3 と実メモリへのアクセスを、常に同時に行なうって主張の方が
電波だと思うけど。

>>137
不自由なのか?
貧弱な発想なんだなw

>>138
ロード時は並行してアクセスだぞ。
もちろん、L3でヒットすればメモリへのアクセスは打ち切られる(又は破棄)けどな。
レイテンシ隠蔽の基本的な手法の一つだよ。

L3 アクセス時に L2 同時アクセスみたいに、メモリ階層の浅い方に
同時にアクセスするなら、なんとかなるだろうけど…

L3 アクセス時に D-RAM 同時アクセスのように、メモリ階層の深い方に
同時にアクセスしようとすると、バンド幅も狭いし、レイテンシは大きく
なるから、うまくいかないでしょ。
L3 アクセスのリクエストと同じ頻度で D-RAM にアクセスしようとすると、
アクセス要求だけで、メモリバスが飽和するのでは？

それに、cache についてはカスタムロジックだから、処理の中断とかも
自由に定義できるけど、DDR2 に、READ コマンドの一般的なアボート機能って
ないのでは？ いくつかの条件が重なった場合には別の READ コマンドに
よる割り込みだけはできるみたいだけど、制約が大きいので、そういう
風に単にメモリアクセスを打ち切るというわけにはいかないのでは？

>>140
もう一度言うけど、電波ってます?
それと、打ち切れない場合が多いから破棄と書いてるんだよ。

>>138
うむ
同時はありえない

>>142
へーそうなんだw
じゃそういうことにしておこうか?
L3を積むと、メモリロードはL3の走査後となるからその分遅くなるってことで俺としてはそれでも構わないよ。
K8Lって悪くなる一方だなw

>>143
論理回路（物理層）の勉強をするべき

> それと、打ち切れない場合が多いから破棄と書いてるんだよ。

だとすると、まさに >>135 や >>140 で書いたとおりに、
結果的に L3 にヒットするから無駄になるメモリアクセスだけで、
メモリバスが完全に飽和するわけで、非常にまずいでしょう。

> L3を積むと、メモリロードはL3の走査後となるからその分遅くなるってこと

その理屈だと、L2 を積むとメモリロードは L2 の走査後となるからその分
遅くなるってことになるけど…
メモリ階層が増加した結果費やされるレイテンシよりも、そのメモリ階層に
よるキャッシュ効果の方が大きいから、メモリ階層を増やすわけで…

いくらなんでも、もう少しは考えてから返事を書いた方がいいと思いますよ。

>>144
つまらぬ発言だな。
幼稚過ぎるよ。
この場合の同時は、当然のことだけど動作が完了するまで待たないってだけだ。

>>145
全然不味くない、L3は所詮オブザーバーヒットしたらラッキーって程度でしかない。
ちなみにL1L2も同時アクセスだよん。

さらについでな説明をしておくと、メモリのロード命令は完了(実ロードされるまで)するまで結構長く待たされる。
それに比べて、キャッシュ走査は速いからメモリロードの要求は貯めておくバッファが用意されている。
連続ロードの場合、メモリロード待ちバッファが一杯になるまで先行できる仕組みだ。
で、このロード待ちバッファに存在している時は、これを破棄または取り消すことが可能になっている。

> 全然不味くない

バスが飽和している状況では、そもそもリクエストが出せないんですが、
もしかして分かってないですか？

> ちなみにL1L2も同時アクセスだよん。

>>99 で、ID:FYZQm2Nx が、L3 と L1/L2 への問い合わせを並列して行なうって
書いてたときには、>>100 で思いっきり否定していたみたいですが…
>>100 のご自身の発言は誤りだったということでしょうか？

>>148
頭悪いなぁ、どうせそんなことしか返信できないと思ったから先に>>147を書いておいてあげたよ。

いや、それは全然答になってないんですが…

あなたが実は全くハードウェアを理解されてないことが、私には
はっきり分かりましたので、もう引っ込みます。
おつきあいいただき、ありがとうございました。
ではでは。

あらら、負け犬が吠えてどっかに行ってしまったようですよ。
どこが、全然答えになっていないのか聞きたいですね。
L3へのアクセス要求とメモリーへのロード要求が同時並行に発せられていることがまだ理解できませんか?
そしてL3がヒットすれば、ロード待ちバッファを破棄すれば良いだけ。
既にメモコンへ指令済みで読み出し状態であっても構わない。
読み込まれて来た段階でロード待ちバッファを確認するたけで破棄出来ますからね。

>>151
じゃあお前は勝ち犬か。おめでとう。ワンと鳴けやｗ

ワン♪

> --もう一つ。AMDはK7とK8でL1とL2にVictim Cacheの構成を取ったわけですが、
> 新コアもまたL1とL2はVictim Cacheの構成でしょうか? それとL3はどうなりますか?

> いい質問だが、ここのところは覚えていない。Chuck Moore(AMD Senior Fellow)に確認してから返事をするよ。

さすがに、不完全排他とは即答し辛らかったんだろうな。
覚えていないなんて、そんなのありえねぇ。

>>136
>大辞林 第二版 （三省堂）
>そうさ 【走査】<
>（名）スル
>テレビジョンやファクシミリなどで、送信の際に、画像を多くの点に分解し、それぞれの点の明暗などを電気信号に変換するために、
>一定の順序で各点をたどること。また、受信の際に、電気信号を点の集合に変換して画像を構成する操作。スキャン。
「一定の順序で各点をたどること」だそうだが？
一般人程度の知識と知性があれば、まず最初に頭に浮かぶのは語源通りの動作だな。
専門知識を持ったエンジニアなら尚更そうだ。

取り敢えず、前言を撤回しておく。
やっぱ、回路図書かなくていいよ。見るまでもないから。

>>154
重要なポイントが隠されてるから即答しなかったんじゃないのか？
インタビューの内容はintelの耳にも入る可能性があるんだから。

> 「一定の順序で各点をたどること」だそうだが？
Set Associativeだから、タグアレイを順次検索するからスキャンで正しい。

>>146
>動作が完了するまで待たないってだけだ。

え？　何が何を待たないって？

ちゃんと筋道を立てて書いてくれ。

’待たないこと’と’同時’は別の意味です。
物理層より前に、ちゃんと言葉も勉強しましょう。

>>157
幼稚園にお帰り。

>>158
もうちょっと、あたまつかえよ

幼児に頭を使ったら通じないよ。

日本語でおｋ

日本語をちゃんと使えてない人に言われてもな。

熱いなぁと思って見てたら痛いだけの人だったのね
頭の悪い俺にはよくわからん話だからどうでもいいが
勝ち犬様って現実世界では確実にうざい人扱いさられてるんだろうなぁ

AMDの中の人がメモリとL3には同時にアクセスするって言ってるのにイチャモン付けるのは何でなんだ？
ちなみに、このことはCTOのPhil HesterだけでなくSenior FellowのCharles Mooreも言ってる。

だから、それは L3 とメモリのアクセスパスが独立していて、
同時にアクセスが「できる」という意味では？

ID:qfDm/Dlb が主張しているような、L3 アクセスの際、常に
メモリにもアクセスを試みるっていうのは、それとは全然違うし、
そもそも実現不能でしょう。
この実現不能ってのが分からないのは、発言を全然違う意味に
解釈することになるので、ちょっとヤバいと思う。

ID:dnp8WgFi = アホ でFA?

> 我々のマイクロプロセサは主記憶のコントローラ回路を内蔵するので，3次キャッシュ
> にヒットしなかったときのペナルティが少ない。2次キャッシュがヒットしなかった際に，
> 3次キャッシュと主記憶を同時にアクセスして，3次キャッシュがヒットした際に主記憶
> へのアクセスを中止すればいいからだ。
by Charles Moore

だいたい今のK8でもL2とメモリは同時にアクセスしにいけるでしょ。

同時にアクセスする

ID:dnp8WgFiの頭の中
Start========>L3読み込み完了
Start========>メモリ読み込み完了

一般の人の理解
Start========>L3======>読み込み完了
Start========>メモリ===============================================================================>読み込み完了

>>167
だから、それは L3 とメモリのアクセスパスが独立していて、
同時にアクセスが「できる」という意味では？

Charles Moored氏が主張しているような、L3 アクセスの際、常に
メモリにもアクセスを試みるっていうのは、それとは全然違うし、
そもそも実現不能でしょう。
この実現不能ってのが分からないのは、発言を全然違う意味に
解釈することになるので、ちょっとヤバいと思う。

抽出して読んでみた。
ID:dnp8WgFi = アホ でFA

これか。
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060518/238286/

これって少なくとも DDR2 世代では >>140 に書いた理由から、
不可能だと思うけどな。
まあメモリコントローラから D-RAM にコマンドを発行するよりも
前に、中断が間に合えば可能だけど。そういう意味なのかな？

>>168
ここでは、メモリバスが L3 よりもバンド幅が狭いために無理だと
いう話をしているので (>>140 参照)、その図では反論になってない。
というか、レイテンシの図では反論にならないってことが分からない
のはヤバい。

ID で分かると思うけど、>>169 は俺じゃないよ。

> http://hissi.dyndns.ws/read.php/jisaku/20060621/ZG5wOFdnRmk.html

ID:dnp8WgFiはアホでFA

Charles Moored氏とdnp8WgFiのどちらが正しいの?
Charles Moored氏は嘘吐きですか?

>>173
>>171 に書いたように、メモリコントローラが、メモリバスに
コマンドを出す前に中断ができるなら、Charles Moore氏の
言葉どおりのことが、DDR2 でも実現できるとは思うよ。

>>147 や、>>168 では、バスが飽和するという指摘に対して
まったく反論になってない、つまり、この発言者はハードウェアを
理解してないことは、既に述べたとおり。

> L3 アクセスのリクエストと同じ頻度で D-RAM にアクセスしようとすると、
> アクセス要求だけで、メモリバスが飽和するのでは？

dnp8WgFiがアホなのは、L3 アクセスのリクエストと同じ頻度でD-RAMにアクセス要求が発令されると思っているところ。
アホ決定ですよ。

> L3 アクセスのリクエストと同じ頻度でD-RAMにアクセス要求が発令されると思っ
> ているところ。

いや、それは ID:qfDm/Dlb の主張で、俺の主張は「そんなことは実現不能だ」
ってことなんだけど。
読めば分かると思うけどねえ。

飽和って言ってもL3が無かった今まではL3へのアクセスと同じ頻度でメモコンへの要求があったわけだしなあ。
4コアになってそれなりに強化はされてるんだろうが。

qfDm/Dlbは要求が連続する場合>>147に書いてるように、D-RAMへは実際にアクセス要求は発令されないと理解しているようだけど

>>177
メモリコントローラを通してメモリバスに要求を出す場合、
当然、その要求の回数はメモリバスのバンド幅に制限される。

ID:qfDm/Dlb の主張は、L3 と D-RAM に同じ回数の要求を
発行できるということを意味していて、L3 とメモリバスの
バンド幅に違いがある以上、そんなことは当然不可能なわけ。

>>179
おいおい、いい加減なこと言うなよ。
俺はそんなこと一言も言ってないぜ。
なんか、スレが伸びてると思って来てみたら無茶苦茶言いやがって、このボケ。

お前が勝手に、ロード要求とメモコン受付とメモコンからD-RAMへのロード指令が直結していると解釈しているだけだろうが。
そんな単純構造でしか物事を理解できないような知能しか持っていないから俺の発言を誤読してるんじゃねぇのか。

俺、qfDm/Dlbな。

Hammerの資料だが
ttp://www.amd.com/us-en/assets/content_type/DownloadableAssets/MPF_Hammer_Presentation.PDF
１8,１9ページを参照しる

>151
>L3へのアクセス要求とメモリーへのロード要求が同時並行に発せられていることがまだ理解できませんか?
>そしてL3がヒットすれば、ロード待ちバッファを破棄すれば良いだけ。

ここまではいいが

>既にメモコンへ指令済みで読み出し状態であっても構わない。

ここが問題ってことかな?

>>178
あ、そうか。>>147 はそういう意味だったのか。読み間違えてた。
すまん。>>150 は取り消す。>>147 はまともな発言だ。

ただし、>>148 の後半で書いたこと、すなわち ID:qfDm/Dlb が、
>>100 から >>148 までの間で、意見を正反対に変えたという
事実は残るが。

>>182
何を言ってるのかチンプンカンプン。
俺に言いたいことがあるのなら、整理して要旨をまとめてから問うようにしろ。

>>146
>この場合の同時は、当然のことだけど動作が完了するまで待たないってだけだ。

この場合の’同時’は、L3アクセスのフェイズとメモリアクセスのフェイズが重なっているという
意味で、同期しているという意味では無いと言うべき。

説明が下手じゃね？

で結局さ、キャッシュ制御はMOESIかMESIなのかどっちなんだ？
長文が多すぎて一々見るのはめんどい

俺もそういう話は聞きたいな。
ちなみにPOWER4の2次キャッシュはMESIを拡張した7状態で管理してるらしい。

K8Lの場合、同一ソケット内での共有とか他ソケット間での共有とかの区別がありそうな気がする。

>>186
> K8Lの場合、同一ソケット内での共有とか他ソケット間での共有とかの区別がありそうな気がする。
全くないというか、区別する必要がない。
これは、なんちゃってL3共有キャッシュの恩恵とでも言えるのかもしれないけどな。
L3共有キャッシュに付いてはコヒーレンシ制御は全くされていないというかできない。

>>185
それどうでもいい話だな。
公開されていれば、それなりに楽しめるだろうがキャッシュ構造の違いから多少のアレンジはあるのが普通だ。

コヒーレンシ制御で言えば、K8Lは何の面白みもない。
Woodcrest等は、L1のコヒーレンシ制御とL2共有キャッシュのコヒーレンシ制御が異なるからそれなりにアレンジしてみると楽しめるだろう。
この場合、L2共有キャッシュのコヒーレンシは他ソケットのL2共有キャッシュ間とで行うのが効率が良いことになる。
つまり、１ソケットだけならL2のコヒーレンシ制御は不要となり常にExclusiveの状態でのキャッシュ保持となる。

ここで言う共有はMESIでのSharedであって共有キャッシュのことじゃない。
同一ソケットの他コアとだけデータを共有してることが分かればわざわざ他ソケットにInvalid要求を出す必要が無いし。

>>189
それを判別するのに都合がいいのが>>188だよ。

WriteThroughなら分かるけどWriteBackなら他ソケットのL2間でsnoopしても意味ないんじゃ。
L1にDirtyCacheがあるかもしれん。
結局、読み込むときは他ソケットのL1まで照会することにならんか？

っていうかL1はWriteThroughなのかな。

一日中スレに張り付いて現実と妄想を区別できず事実事実とブツブツ言ってる引きこもりニートがいるのはここですか？

で、実際どっちなのよ。
口の汚さや引きこもりニートとかどうでもいいから、真実を知りたい。
そもそも詳細が一般レベルに伝わっているのか、L3キャッシュ機構について。

>>185
AMDの資料によればL1-DataCacheはMOESIプロトコルサポートとなってる。
(資料のアドレスは自宅のPCにあるから、夜帰宅後に示す。)

実際の制御の詳細は記載されてないが、個人的にはModified,Owned,Invalidの各bitと
SharedとExclusiveを示す3bitのカウンタによる制御と考えてる。(0がExclusive,1〜7がShared)

これだと、他コアからのロード要求で該当アドレスのデータがあった場合、Sharedカウンタをインクリメントして
データを返し、受信側はSharedカウンタと有効応答数をチェックして簡単なエラーチェックが出来る。

L1/L2から共有データが破棄(またはWriteBack)される場合は、破棄要求を他コアに送信し、受信側は該当アドレスの
Sharedカウンタをデクリメントする。

これだと、単純なカウンタ制御だけでExclusiveとSharedの状態遷移がスムーズに制御できるし、他コアの共有状況も
ある程度だが把握できる。
現行K8がDualCoreでも論理8コアまでしかサポートしないのも、このカウンタが3bitまでしかないと考えれば納得できる。

8コアまでなのはHTのNode管理が3bitだからじゃないの？

>>195
>>84のリンクを読んで見た感じだとHyperTransportそのものの制限ではないはずだ。
ttp://journal.mycom.co.jp/articles/2006/06/20/computex01/002.html

＞--別の聞き方をします。HyperTransport V1ではNodeを3bitのカウンタで管理していました。なので、8Nodeが最大でした。HyperTransport V3ではどうでしょう?
＞そのカウンタは増やす。現在は8だが、将来のアドレス拡張などに備えて拡張する。
＞--どこまで増やすのでしょう?
＞それはインプリメントに依存する。HyperTransportではそこまで規定していない。

この「インプリメントに依存する。」と言う部分がヒントになって思いついたんだけどな。
HyperTransportのノード管理だけなら3bitなんて大したサイズじゃないし、将来性を考えて
最初から8bitとかもっとキリのいい所に規定しておいても良かったはずだ。
だが、キャッシュ周りのインプリメントに影響するとなると1bit増やすだけで×ライン数分
サイズが増えるからそういう訳にはいかないからな。

また、変なのが湧いてきたなw

とりあえず

ID:vo5salCs=アホ?

内容に対するツッコミ無しで、アホだの日本語で、だの、何も考えて無い様な
レスは止めろよな。見苦しい。

>>197はオタに知識で対抗できない連中みたいだなｗ

ここにいるのはCPUのアーキテクチャオタ？

>>196
特定ビットが予約されているみないなことはよくあるし、
ARMのThumb命令みたいな形でコマンドを定義すれば、
バス幅を変える必要もあまりないんじゃない?

それはそうと、非対称性複合コア+モジュール化なんて、ますますどっかのCELLみたい

>>185
これのP.255に記載がある。
ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF

>>201
なるほど、それも考えられるか・・・

一応、カウンタ方式だと一つメリットが考えられる。
ExclusiveとSharedの2状態だけで管理する場合、破棄要求を受け取ったコアは対象アドレスのデータを
SharedからExclusiveにするか、Sharedのまま残すかを判定しなきゃならなくなるが、そのためには自コア以外に
同じデータを共有しているコアがあるかどうか問い合わせなければならない。
カウンタ方式なら、常に自コア以外のコアがいくつ同じデータを共有しているかわかるから、問い合わせの必要は
なくなる。(単にカウンタをデクリメントして0になったらそれがExclusiveであることを意味する。)

少々、トランジスタを消費する方法だが、HyperTransportを通過するパケット数を減らすには有効だと思う。

素人が多いな。

>>202
カウンタ方式はお勧めしない。
ムダが多いだけで、効率が悪いからだ。
そもそも、共有状態にあるデータは非常に少ないという前提を失念している。
ほんの僅かばかりの共有データの為に、カウンタの導入はムダだ。

でAMDに隠し球はあるのかね？
性能よりも省電力方向でいって欲しいな

省電力技術はAMDよりIntelのほうが進んでるからなぁ。

AMDは今までデスクトップはよかったがモバイルが全然ダメだったからツケが回ってきたな

>>203
そうか？
MOESIプロトコルだとModified,Owned,Exclusive,Shared,Invalidの5状態を管理するのに
最低でも3bit必要だが、カウンタ方式ならExclusiveとSharedの管理に3bit、残り3状態に
2bitだからせいぜい2bitしか違わん。

状態遷移にしても、5状態の組合せになる状態遷移回路を制御するより、3状態の組合せ＋
単純カウンタの方がはるかに簡単だと思うが？

2Way程度なら大した効果はなかろうが、K8Lがターゲットとする32Wayや64Wayではパケット量
削減は深刻な問題だと思うがな。

> 2bitだからせいぜい2bitしか違わん。
もう、滅茶苦茶な話をされても困るよ。
お前は、カウンターだけしか持たぬつもりか?
それたど、状態を適切に把握することは不可能だ。
それに、これからマルチコア化が進み、４ソケットでも最低４x４=16コア以上になると言うのに自身を除いた共有フラグがたった7bit?
無駄だ、無駄だ。

もう生体CPUでいいや
処理能力ならPen4 2.8CGX4級程度余裕で出せるし

>>207
良いと思ったらここに書かんで、特許申請しておけばいいのに。

210 名前： Socket774 [sage] 投稿日： 2006/06/23(金) 10:15:25 ID:gibFrwTZ
>>207
良いと思ったらここに書かんで、特許申請しておけばいいのに。

何気に気に障ることを書いたカナ？　カナ？

インタビュー中のカウンタって参照カウンタのこと?
IDだとかナンバリングだとかそっちの意味で捉えてた。

>>208
だからK8Lではbit数を増やすんだろ？
必要なトランジスタ数が増えることがデメリットではあるが、技術的にはなんら困難はないごく簡単な拡張だ。
コヒーレンシ制御のパケットがHyperTransportにかける負荷の問題はK8設計当初から問題点とされてきた部分だからな。
K8Lで更にその負荷を軽減するために、よりトランジスタを必要とする共有L3を追加する位だから、この程度の基本的な
パケット削減手段は最初から実装されていてもおかしくない。
カウンタのインクリメント・デクリメントなんて、論理回路の初級の問題集で真っ先に扱う程度の簡単な回路だし、
動作も1クロックで完了する高速なものだから、速度面でも複雑な状態遷移回路より有利だ。

130nmの初代K8ではダイサイズへの影響が深刻だったから、必要最小限に留めたんだろうが、65nm化とL2減量となる
K8Lなら一気に8bit位まで拡張しても、ダイ上で必要な面積はむしろ減る。

パケット削減のメリットと同時にトランジスタ増量のデメリットがある事位は、こちらでも最初から認識してるんだが、
それ以外に何かデメリットがあれば「具体的」に解説してくれ。

＞ほんの僅かばかりの共有データの為に、カウンタの導入はムダだ。
それこそ、共有L2の方が無駄だな。
共有化と引き換えにレイテンシの増加というデメリットとのトレードオフだぞ？
僅かばかりの共有データの為に、大量の非共有データや命令のロードレイテンシを増加させる方がよっぽど無駄。


>>210
いや、俺がボーっと資料眺めながらでも思いつく程度のことだから、もう考えた奴はいるだろ。

>>214
お前、これをわざと避けてるだろw

> お前は、カウンターだけしか持たぬつもりか?
> それたど、状態を適切に把握することは不可能だ。

> それこそ、共有L2の方が無駄だな。
> 共有化と引き換えにレイテンシの増加というデメリットとのトレードオフだぞ？
> 僅かばかりの共有データの為に、大量の非共有データや命令のロードレイテンシを増加させる方がよっぽど無駄。

お前、何にも判っちゃいねぇな、というか無理やり反論か?
共有キャッシュの効能は、お前が思っているよりずっと強力だ、もちろんConroeのL2キャッシュの話だがな。
共有L2を有することで、新規ロード時に他コアへ照会パケットを送らなくて済む。
さらに、１スレッド時はL2の全てが使える。
マルチスレッド時の照会はL1だけで済む。
このような利点と、本来欠点であるはずのレイテンシの増加はIntelの技術力で抑え込んである凄まじい程に高性能なキャッシュなんだよ。

>>215
・・・ああ！つまり
>それたど
も突っ込みどころだったのか、気が付かんかった。
とりあえず日本語を習ってから来い。と言っておこう。

>16コア以上になると言うのに自身を除いた共有フラグがたった7bit?
・・・現行K8を想定した上で「3bit」と書いてるはずだが？
どこから「7bit」なんて出てきたんだ？
ま、64コアでも6bitで足りるがな。
2進数もついでだから習って来い。

横レスで申し訳ないが

>>216
CPUアーキティチャ素人の素朴な疑問なんだけどさ、

>１スレッド時はL2の全てが使える

このあたりは誰が制御するんだろう。CPU内？OS？

>>217
へへ、つまりお前は、状態の保持などなしで単にSharedカウンタだけで良いと言っているんだな?
まず、ここをはっきりとしろ。

無能者相手にするのはちっとばかり疲れるから嫌だなぁ。

>>218
CPUだよ。
OSの領域ではない。

>>220
ほう。
そうすると走ってるスレッドの内容によって動的にL2確保するわけ？

>>221
基本的にそうなる。

>>219
最初に書いた通り、MOESIプロトコルの状態制御のみに限定した場合は
Modified,Owned,Invalidの3状態＋Exclusive,Sharedの管理カウンタだが？
それ以外の状態保持はMOESIプロトコルには直接関係しないだろうということで無視した上での話だ。

そもそも、アドレス管理からしてK8→K8Lでは40bitから48bitへ拡張されるらしいからな。

で、デメリットの解説はまだか？

>>223
それだと>>207の2bitの計算と合わないから、やり直せ。

>>222
ありがと。
素人考えだけど、そのあたりの確保する予測がハズレた場合とか
同時に走ったスレッドの内容によっては、排他より効率悪くなる場合ない？
それでも十分なL2速度確保してるから実害はないのかもしれないけど。

>>225
キャッシュラインによっては、複数のコアで競合(取り合い)するケースが出てくる。
過度な競合はキャッシュ性能を低下させる原因にもなる。
Conroeは、キャッシュラインを過度に取り合わぬようにする機構が組み込まれている。
キャッシュライン毎で一定時間毎に各コアの使用数をカウントし、当初は8Wayずつに分けられていた境界を各コアの実情に応じて0→16Wayまで変化させている。
この機能によって、一定時間内は境界を変更しないことで、過度の競合を押さえているわけだ。
よく考えられた仕組みとなっている。

>>226
ほうほう。面白いね。ちょっと勉強してくるわ

おっと、各状態が同時にONになり得る事を想定に入れるのを忘れてたな。
Modified,Owned,Invalidに各1bitで3bit、SharedとExclusiveは同時にONにならないので1bitのON/OFFで
表現すればいいから4bitだな。
カウンタ方式では最初の3bitは同じで、カウンタが0〜7で3bit、合計6bitだな。(現行K8前提での話)

・・・やっぱり2bitしか違わん訳だが？
どういう計算なら2bitがNGになるのか、解説よろしく。
あと、デメリットの解説もな。

これから仕事なんで、次に見る時までに頼むぜ、「本物」さん。w

>>228
> カウンタが0〜7で3bit
ここが間違っているところだ。
このカウンターは各コアとのShared状態を保存するのだから、７コアなら7bit必要。
ちゃんと勉強してから投稿しろ。

>>218
>>１スレッド時はL2の全てが使える

>このあたりは誰が制御するんだろう。CPU内？OS？

頻繁にキャッシュが書き換えられる結果、占有スレッドに関するキャッシュの割合が増えるってことでしょ。
むりやり増やすわけじゃないと思われ。

いつもの二人か。

そうして、いつもの結果w
やめときゃいいのに

・・・ああ、なるほどね。　自分以外のコアに各bitを対応させてるから7bitなのか。

そんなにいらんよ・・・自分以外のコアがいくつ同じデータを参照しているかだけ保持すれば充分だ。
破棄要求を出すときに、キャッシュラインのアドレスとカウンタの値を一緒に格納するだけでいい。
(1)破棄要求パケットを最寄のどれか1コアに転送。
(2)要求を受信したコアは該当アドレスがあれば、Sharedカウンタをデクリメントすると同時に
受信パケットに格納されたカウンタもデクリメントする。(なければそのまま。)
(3)受信パケットを更に別コアに転送。
(4)以下、(2)・(3)を繰り返し、パケット内のカウンタが0になった時点で転送中止。
これなら、1つの破棄要求パケットを各コアの間で順次転送するだけで済むし、途中でカウンタが0になったら
それ以上の転送も必要ない。
WriteBackの時はWriteBackされるデータもパケットに載せて転送すれば最新のデータも同時に反映できる。
ついでにOwnedフラグも一緒に転送して、カウンタを0にしたコアの共有データが新たなOwnedになるようにすれば、
Ownedの譲渡も完結する。
わかりやすく言えば回覧板みたいなやり方だな。

欠点があるとすれば、順次転送することで処理開始から処理完了まで時間がかかることだが・・・
L1/L2から破棄またはWriteBackされる共有データは参照履歴が一番古いから破棄・WriteBackされる訳だから
多少時間がかかっても問題は極めて少ない。(たまたま同時アクセスがあった場合にちょっと待たせる程度。)

ま、処理時間を優先する場合は破棄・WriteBackパケットを全コアに無条件に送信するという方法もあるが、
この場合はSharedカウンタの値は必要ない代わりにパケット数は増えるがな。

いずれにせよ、数だけ把握してれば用は足りるな。

>>233
お前、マジでアホだろ?w

壊れた録音テープ

これだけ長く読みづらい書き込みがつづいているが、役に立つ話はゼロ。
やたら用語をつかいまくって難しい話をしているようだが、中学生レベルの間違いばかりで中身もゼロ。
それがこのスレのクオリティ。

いや、煽りや罵倒がいけないんだ。
本来はまともなレベルの人も何人かにたはず。
でも埋もれてしまう。

このスレをこんなにしたのは全て淫厨です（藁

またぞろReverse HTの腐れルーマーが浮上してきたすけど、引っかかってるヒトが
皆無でがっかりしたす(笑)

AMD Socket AM2 has a secret weapon
http://www.theinquirer.net/?article=32589

Reverse HT(HyperThreading)について。
いわゆる動的マルチスレッド技術で、AM2ソケットのAthlon X2で隠し機能として実装されている。
ソフトウエア側からDual CoreをSingle Coreに見立てる
(=Single Threadを動的にマルチスレッド化しながら実行するともいう)
ことによって、6命令/cycleの高IPCを実現。

AMD to Boost Single-Threading Performance on Multi-Core Chips, Say Sources.
http://www.xbitlabs.com/news/cpu/display/20060622143710.html

xbitは更に詳しい。

To activate it customers will “only need to update the processor driver and the mainboard BIOS,”
they say. Microsoft Corp. will reportedly even release a corresponding patch for the operating systems
that will allow recognizing two cores of the Athlon 64 X2 as a single one.

Reverse HTことCombined Modeを有効にするには、新しいプロセッサドライバ、新しいBIOSが必要。
MSはDual Coreを単一プロセッサとして認識させるためOSのパッチを用意。

>>241
Reverse HTわハードウェア的な実装としてわ腐れルーマーの領域すけど、引用している
xbotlabsの記事にあるように
　　------------------------
　　Microsoft Corp. will reportedly even release a corresponding patch for the
　　operating systems that will allow recognizing two cores of the Athlon 64 X2
　　as a single one.
　　------------------------
(最近もEfficeon の販売を引き受けたりと)長年の尻舐めの甲斐あって、Microsoft から
OS的デュアルコアサポートを勝ち得た可能性わ、あるかと思われるす。

xbit読み直したら全然違ってた。

Combined Modeでは、2コア分のリソース、例えば2セット分のデコーダを1コアのためだけに使える(=6 inst./cycle)
とかそういう話で、動的マルチスレッド技術の類ではないようだ。

Combined Modeと通常のモードは動的に切り替え可能。なかなかおもしろい。

Reverse HTでどの程度シングルスレッド性能がアップするんだろう。

Intelが独自路線で好き勝手やってるからMSとしてはAMDを押すに決まってるだろう。
MSを慈善団体かなんかだと勘違いしてるのか。

>>244
> 例えば2セット分のデコーダを1コアのためだけに使える(=6 inst./cycle)
これも殆ど嘘みたいなもので、たんなるプラシーボ効果を狙った詭弁だろうな。
実際は、Combined Modeで片方のコアの電源をOFFにすることと、クロックUP(倍率を増やす x9をx10)だけだろうな。
元々デュアルコアはシングルコアと比較して１７%程度低いクロックで動作させている。
片側のコアの電源を切り完全停止さすことで原理上１７%程度のクロックアップが可能になるってだけの話だ。
MSにしても、片方のコアを停止する程度のことなら、既にマルチソケットでの障害回避機能でCPU切り離し(CPU割り当て変更後に切り離す)等は
実装済みだから簡単なパッチを用意するだけで対応は可能だ。

それにしても、ネタが明かされると陳腐な話で笑う程度のことでしかない。
まぁ、それでもシングルコア動作になるとはいえ17%程度のクロックアップ効果はAMDに取れば非常に有用だろう。
Conroeに絶対的な差を付けられていたことを思えば、17%アップは紛い物であったとしても見かけ上はAMDのCPUを陳腐化から救うことになる。

xbitの推測をもって「ネタが開かされた」とか書いてる痛い人がいます

何の根拠もないのに〜だろうな。とか言っちゃってる痛い厨がいます

>>247
んじゃ今まであるデュアルソケットなマシンで
>既にマルチソケットでの障害回避機能でCPU切り離し(CPU割り当て変更後に切り離す)等は
>実装済みだから簡単なパッチを用意するだけで対応は可能だ。
やってみ？簡単なんだろ？ｗｗｗｗｗ
WindowsでもLinuxでもSolarisでもでもいいから。んでその簡単なパッチうｐってみ？

http://pc7.2ch.net/test/read.cgi/jisaku/1150872014/721
721 ：Socket774：2006/06/23(金) 22:54:32 ID:0WhA3Ykz
情報が正しいならば、Anti-HTには失望したとしか言えない
ttp://www.intel.co.jp/jp/developer/technology/magazine/research/EPI-throttling-1005.htm
超ガイシュツでした

>>248-250
お前等、何でそんなに必死なんだよw
根拠というか、デュアルコアを仮想的に１コアにする程度でクロックあたりの性能が飛躍的に伸びるようなことは考え難い。
そんなに簡単に性能が上がるなら誰も苦労はしないし、既にずっと高性能になっている。
つまりAMD社の言うことは、とんでもなく疑わしく嘘に充ち溢れていると、ある程度の知識がある人達には思われてしまうわけだ。
まぁ、お前等は無知のようだからAMD社の広報を真に受けてプラシーボ効果とクロックアップ効果で喜んでいればいい。

>>252
ttp://www.realworldtech.com/forums/index.cfm?action=detail&id=69544&threadid=69522&roomid=11
ttp://img154.imageshack.us/img154/8774/1194mp5zlusr4uni9bc.png

なんかｲﾝﾃﾙにもCore Multiplexing なるものがあるらしいが・・・

個人的には興味あるけどな、R-HTT。
まあ、今のAM2に実装されてるとかはともかくとして。


昔、HTTが出たときに、最終的には各実行ユニットを独立させ、
必要に応じてこれらを束ねて論理CPUを構成するような仕組みになる時代が来るのかな、
なんて妄想をしたことがある。

そうすれば、シングルスレッドで駆動できる平均的なユニット数を超える実行ユニットを
実装しても、使い切れない場合は別の論理CPUを構成して使うとか、そんな感じでトータルと
しての性能を向上させられるのかな、とか。

まあ、こんなのはスケジューリングとか出来ないと思うんで、無茶な妄想だとは思うけど、
なんとなく、路線が似たような気もするんで、どうなるか興味アリ。

>昔、HTTが出たときに、最終的には各実行ユニットを独立させ、
>必要に応じてこれらを束ねて論理CPUを構成するような仕組みになる時代が来るのかな、
>なんて妄想をしたことがある。

HTTからそんな妄想ができるなんてすごい勘違…才能ですね

>>254
INTELのHTテクノロジは、比較的軽いプロセスが複数同時実行される場面でのスループット向上が主な目的だ。
Sunのナイアガラとコンセプトは変わらんよ。

>>253
Intelが現在研究中のものとしては、シングルスレッドプロセスを動的にマルチスレッドプロセスに自動変換し実行することでの性能向上だ。
しかし、このような基礎研究においても既に限界は見えている訳でそのプロセス自体のアーキテクチャを改変しない限り並列性を高めるのは難しい。
そこで現在では、高性能な汎用並列化モジュールに絞って研究がされている状況だ。
この汎用並列化モジュールは、コンパイラでの組込と、インタープリタ形式での実装の両面で検討されているが、まだまだ研究の段階でしかない。
汎用性を持たすと並列性の向上率は下がるのがネック(当たり前の話だが)であり、新たな発想の出現を待つと言ったようなものでしかない。
現実は非常に厳しいのよ。

AMDの隠し玉とやらが事実上4×4とHTXバスだけなのはわかった

x86とかだとIPCはもう上がらないという常識があったので、K8はレイテンシ削減で平均点を上げようとした
でもBaniasはトランジスタを増やさずに、古いバイナリでVLIW並みの高IPCを出してみせた(結果、自らItaniumの首を絞めた)
抜け道はまだあったわけだ
HTTも少ないトランジスタ追加で疑似デュアルコアの効果を出す裏技だった
抜け道、裏技は出尽くしてはいなかった
今でもコアは半分の時間しか働いてないし、コア数はまだ増えていくのだから、
複数コアを使ってシングルスレッド性能を上げる裏技もあるかもしれない
1コアを2コアに見せかけるより、2コアを1コアに見せかけるほうが無理がないと思う

by ﾊﾟﾜﾚﾎﾟ後藤
Gesherはコア間のインターコネクトに特殊な技術を採用しており
コア間は高度に統合される・・・なんちゃらかんちゃら

ID:hEof9TqDは間違いなく雑音だな。よくもまぁ、こう妄想をあたかも真実の
ように語れるもんだ・・・・

1個のコア止めてその分もう1個のコアクロックアップするとかもうバカかとｗｗｗ
それとな、
>根拠というか、デュアルコアを仮想的に１コアにする程度でクロックあたりの性能が飛躍的に伸びるようなことは考え難い。
>そんなに簡単に性能が上がるなら誰も苦労はしないし、既にずっと高性能になっている。
こんな事言ってるようじゃ数年前の考え方だぞ。全く今のトレンドに乗れてない。

>>259
それなんてスーパースカラ？

ここで言われている技術とは関係なく、
1個のコア止めてその分もう1個のコアをクロックアップというのは
ありだと思うな。この場合、熱密度が問題になりそうだが。

投機的マルチスレッディングもFoxtonテクノロジももうおなかいっぱいです

アム厨はAM2に10%以上の性能向上期待していたわけだが、結果はご覧のとおり。
結果が分かるようになってから殆どのアム厨は、最初からそんなの期待してねぇよと言い出したわけで、
今回のAnti-HTについては是非ともアム厨の期待の程を率直に聞きたいというわけだ。

ちなみに、俺としては６命令デコード/サイクルになったところで性能は殆ど上がらす、精々2〜3%程度と予想する。
Anti-HTモード時は多少のクロックアップ(10%)が当時にされるとしてトータルで1.03x1.1=13.3%程度の性能向上と見る。

是非、アム厨もしくはAMD社の広報に期待している人の予想を書いてくれ。

>>265
お前以上のアム厨はここにはいないよ

当時ってなんだよ、同時の間違い。

>>266
つうことは、アム厨は全く期待してないってことだな?
それなら良いんだが、やたらに騒ぐバカがウザイので騒ぐならちゃんと予想値を出してみろってことだ。

ウザイかどうかは主観の相違。
俺から言わせればお前の方がウザイと思うのと同じようにだ。

ガセだろうがなんだろうがネタで遊ぶのは基本だろｗ

遊ぶなら、予想値を発表してからにしろってことだな。
騒ぐだけ騒いで、そんなの知らねぇと後で言われてもどう対処していいか困るからな。
まぁ、AM2のときの空騒ぎは爆笑ものだったけどな。

>>269
>遊ぶなら、予想値を発表してからにしろってことだな。

ありもしないものを妄想して、おまえの仲間になれということか。
やなこった。

依存関係(ry
あふぉか>>R-HTT

>>269
ちょっｗｗ対処とかｗｗはらいたいｗｗｗ
ネタだったら藁えばいいだけじゃん
そんなに自分中心で話し回してかまって欲しいならVIPにでスレ立てろｗ

Reverse-HT、技術的に面白いかどうかだな。
どうせベンチじゃスコア上がらないだろうしそっちで期待はしてない。
むしろ、アプリケーション毎に動作が切り替えられるとか言うんだったら感動。
デュアルコアへの移行に伴うパフォーマンスの低下を最小限にしてくれるだろうし。

っていうかね、IntelならともかくAMDがこんなの開発するなんてマジ信じられん。
あと一ヶ月、ずっと疑い続けるに違いない。
その先にあるのは落胆か、それとも…。

独自性をだしてみたかったんです＞＜

まあ、AMD信者も８割方ガセだと思ってるんだろうけどけどね。

ただ、久々の面白ネタだし、盛り上がってもいいんじゃね？

分岐命令の投機実行に使うのは？
確か分岐先を各コアに割り当てるような事を
何処かで読んだ記憶があるのですが

方コア停止&クロックアップが一番現実的かなぁ。
ひた隠しにしてきたのも頷けるし。

分岐結果を両方とも実行するという力技ならItaniumが実装してる
で、プロセッサ名からわかるとおりコンパイラの協力が必要不可欠なんでAMDには期待できない
xbitに記事があったと思うが片肺殺してクロックアップ説の方がまだ現実的だし、理にかなっている

>>275
馬鹿だなぁ、盛り上がっちゃったら焜炉の買い控えまで発生しちゃうじゃないか。(w

>>278
＞コンパイラの協力が必要不可欠なんでAMDには期待できない

その通り。あのIntelですら出来ないんだから。これで2回目だよ。

>>275
しかし、そのガセをAMD社の広報たる者が真顔でやるんだからAMDは怖い。
普通に信用を大きく損なう行為だ。

>>281
むしろガセじゃなかったときの方が怖い。

いや、それ怖いというか普通に常識が覆るだろ。
AMDのフェローが冗談半分で「Anti-HT」の話をしてた時は、「AMDも追い詰められているんだなぁ、
無茶を言う」との感想だったけどConroeの発売日1日前にそれを実行する予定だったとは参ったね。
一応は、デコーダ周りを結合して遅延することなくスケジューラにuOPsを供給するようだから、ガセじゃないのだろうけど、
それでの性能向上など殆ど無いにも等しい、実クロックを多少は上げるようだからそのことを隠蔽してしまえるだろうけど、
まともな企業のすることじゃないよ。
あと、気になったのは、その時のフェローの発言の中にFPUユニットも2倍のような説明もされてかと思うが、
これはどうやらK8Lと混同していたようだ。

>>281
＞そのガセをAMD社の広報たる者が真顔でやるんだから

>>283
＞ガセじゃないのだろうけど、



どっちなのかね？

>>284
きっと二重人格

>283
> まともな企業のすることじゃないよ。

インテルが、P4のパイプライン段数を増やしまくって3GHzのCPUを作ったときに
俺は、そう思った。性能は上がらずに、消費電力だけBurstしたんだから。

客観的に見ればイカれた会社なのはINTELでFA？

> 性能は上がらずに
P4になり、動画再生能力やエンコード性能は飛躍的に高性能化したよ。
AthlonXPでは最後まで追い付けなかったのは記憶に新しい。

そもそも熱湯は動画再生能力やエンコード性能向きな石だしな
そう割切れば悪くない

INTEL自身が、P4はそのようなCPUだと最初から断言してたからな。
P4に条件分岐の多いソフトを高速で動かせというほうが無理な注文だ。
ネットバーストを毛嫌いしている奴の殆どが、これ等の前提条件を理解せずに騒いでいただけなのが滑稽だったわけだか、
今はもう昔の話として片付けて良い時期かもな。

その前提条件を理解できなかったのではなく、
その前提条件が世間に受け入れられなかった、ってことじゃね？

まあ、今となってはintel自身がそれを理解した、って意味では
片付けても良いとは言えるかもね。
問題は、それで野に放たれたネトバが、
今日も無駄に電力を熱に変えてる、ってコトだけだ。

一般的には受け入れられて爆発的に売れたのだが・・・
INTELがちゃんと市場を把握していた結果だ。
もちろん、プレスコットは失敗作だけな。(これもINTELは最初から認めいてる)

なんで雑音（＝ID:Ay9E9Mu7）と普通に会話してんだよ

P4を必死に正当化するのはなぜ？何の意味があるの？

逆工作員だからな。
Intel儲痛いって思わせることが狙い

必死に正当化って何が?
事実を語っているだけで、P4はどんなものでも超高速に処理しますなんて電波なこと言った覚えはないぞ。
P4の発売で、PC業界は不況から脱し他の業種が軒並み落ち込むなか堅調に推移した事実を忘れてもらっては困る。
P4により、PCで動画を扱うのが一般化し、現在では多くのPCにTVチューナーが搭載され、茶の間で使う形の大画面一体型PC
までラインナップされるようになったと言っても過言とは思わんよ。

受け入れられなかったというか、Intelが予想したよりも
そっち系の需要が少なすぎたって感じかな。

需要が少なかった
予想以上にクロックあがらなかった
鯖には無理があった
消費電力問題

まあ当時は世間的にクロック至極主義だったから
マーケティング的に高クロック可能なアーキにしたのもあるかもしらんが。

>>293
わかっちゃいるけど日本語通じるうちはおｋ

また顔真っ赤にして正当化しとる・・・ｷﾓｯ

Pen4のおかげで不況から脱しってどれだけ妄想が激しいんだよｗ

ドットコムバブルが弾けたり、半導体不況が訪れたことは無視ですかそうですか。

国産CPU作ろうぜ！
チョンからは金をむしり取られ、米からは肉を買わなければ金を払えと脅される
資源も乏しい日本はそろそろ限界だろ

こんなときだけ愛国心をみせるようになったら、もう終わりだと思うす（笑）

つ[Superｴｯﾁ]

>>300
お買い上げ有り難う御座います。
http://www.nec.co.jp/press/ja/0509/1301.html

受け入れられた・・・つーか、他ならぬintelが選択の余地がほとんど無い状況を強引に作り上げただけだがな。

専用のコプロを乗っけようとしてるくらいだから、ソフトウェア対応が必要だから
ありえないとかは話が違うと思われ。

株価を下げまいと、必死なんだよ。
たぶん。

>>305
日本語でおk

・便所セレや北森セレでそこら中のオフィスが阿鼻叫喚だった
・ニワカユーザーが提灯ベンチで(ry
・Xeonの処理能力がPenIIIベースのと比べ(ry
・電源が(ry

そもそも条件分岐を嫌うチップがCPUを名乗っちゃいかんね
エンコ専用でAMDのサブソケットに入れて貰うくらい下手に出たらネトバも可愛げがあったかも
熱くて誰も使わんか・・・

名乗っちゃいけないとは大きく出たね。
ネトバは、5GHzとかの高クロックで回っていれば、
別に悪くないCPUになってたはず。

クロック当たりの性能が悪いのは高クロックに振ったせいだから。
現状のネトバの悪い点は「クロックの低さ」だ。

普通、CPUってのはコンパイラの吐き出す命令を分析して
アーキティクチャを決めるんだけど、
pentium4はそれをせず(っつーか、intelのチップはたいていそうだが）
クロックが速ければ速いだろう(想像)、将来はpentium4に最適化
されたコンパイラが出る(希望的観測)の元に開発されたってのも
あまり効率的でない原因のひとつだな

Intelはそんな打算的なことはしてない。自社製コンパイラ持ってるからｗｗｗ
VC++やGCCにもきちんと技術提供してるし。

むしろPen4向けに最適化されてない古いコードが遅かったわけで

キャッシュサイズでも条件分岐でもK8に劣っていたPen4
当然π焼きスコアも振るわないが
限界までOCという条件では逆転してPen4のほうが速いんだよな

回せば速いよ。うん。定格ではダメポだったけどね('A`)

当のIntelが「2004年ごろには600Wに到達」なんて予測をプレゼンしてたから、
冷却さえおいつけば本当に600WのCPUを作るつもりだったんだろう。

パイプラインバブルの大きさこそNetburstの真骨頂だろ
どうせILPは4か5で打ち止めだし
その時TLP(Netburst)の時代が来るのかEPIC(IA-64)が来るのかはわからないけど

と次世代っぽいこと書いてみる

>>313
同感だがそれを許さなかったのは時代だよな
CPUなんざ電気食って当たり前の風潮なら
今頃5G出てただろ
インテルが時代を見誤ったのは間違いないのさ

面白いのはGPUがこの先どうなるかだよな
何故かハイエンドGPUに関しては
電気食って当たり前がまかり通っている
VIAがCPUでもGPUでもやってること一緒なのが素敵だ

それこそ >314(600W ほどの数字だったかは覚えていないが)が
言っているようなキチガイ沙汰の数字を当時本気で信じていたのなら
あまりにも抜け作だろう。

省エネ回帰とかそういう次元じゃないよ。

「クロック指標優先・性能はその次(ベンチの内容をいじれば OK)」という
マーケティングの都合を見抜けていないのは消費者として問題あり

でも普通の人には見抜けないよね

>>68
キャッシュコントローラーが、な。
コアがんなもの観に行くこたぁねぇんよ。

>>314
そう言えば、今度のCOMPUTEXで1000W級の電源がドカドカ出て吃驚したよ

アレが今後デフォになるのだろうか…

インテル「Core4はAthlon64 X4の140Wに対したったの138Wで、消費電力が少なくてすむ。
1000Wなんて使うのはAMDプラットフォームだけだ」

AMDのAM2やソケットFとは比較にならんな。

Woodcrestの反響は凄い。
> 世界中で、150 社以上のシステム・メーカーから、同製品を搭載した 200 機種以上のサーバーやワークステーションの販売を予定しています。
> また、日本国内においても、主要システム・メーカーおよびチャネル企業各社が、
> 最新のデュアルコア インテルR XeonR プロセッサー 5100 番台を搭載したサーバーとワークステーションを、順次製品化する計画です。

採用企業からのコメントも凄いことに
> ttp://www.intel.co.jp/jp/intel/pr/press2006/060626b.htm

マイ糞とIBMの二枚舌わろすｗｗｗ

Microsoft-応援→AMD-応援→nVIDIa
　↑↓　　（微妙にケンカ）　　↑↓
　Intel-応援→Linux-応援→ATI

×　Linux-応援→ATI

ttp://www.itmedia.co.jp/enterprise/articles/0606/29/news068.html
このスレには仮想化機能がセキュリティ上の脅威にならないと
言っていた奴が沢山いたよなぁ。

まったく問題ないよ。それは我々が2年前に発表したものに対する対応でしかない。

>>327
この電波まだいたのかｗ
知能低い粘着ｗｗ

>>329
より知能が低い事を晒して楽しいのか？

外部の端末からの検索ならわかるんじゃない?

結局Houndのキャッシュはどうなるんだ？

俺jailとかchroot多用してるが327がなんで脅威なのか判らん・・・

池沼だからしょうがなく。

>>333
jailやchrootは外を隠蔽する事で中で起きる問題を閉じ込める機能。
つまり、外が攻撃されれば無力。
仮想化機能も外の世界を作って中から外を隠蔽できる。

>>332
現状に排他的な共有L3つけて終わりでしょ。

>>333
マトリックスって映画観れば理解できるよ。
あのまんまの話がコンピューター内では現実に起こりうる。

>>337
わけわかんねぇ

仮想化技術、貸そうか？Ｗ

死罪

ギャグの終了　このギャグは応答していません。
スレに戻ってギャグの状態を確認するには、[キャンセル]をクリックしてください。
ギャグをここで終了した場合は、ツッコミされていないギャグが失われる可能性があります。
ギャグを直ちに終了するには、[すぐに終了]をクリックしてください。

応答していないギャグ　仮想化技術、貸そうか？Ｗ.exe を終了することを選択しました。
ギャグが応答しません。
この問題をMaccrosoftに報告してください。
仮想化技術、貸そうか？Ｗ.exe のエラー報告が作成されました。
弊社では、この報告を製品の改善に役立てるとともに、匿名の機密情報として扱います。
エラー報告に含まれるデータの詳細：　仮想化技術、貸そうか？Ｗ

エラーの報告　この問題を報告していただきありがとうございました。

> http://pc7.2ch.net/test/read.cgi/jisaku/1151802697/172 より

> それから
> ＞Read担当コアが他コア全てに対してL1L2照会と自L3アクセスと他コアL3照会と同時にメモリアクセス
> はなんか違う気がする。

違わないよ、アクセスアドレスにより担当コアが決められているからこそ照会と同時にメモリアクセスが可能なんだよ。
共有L3はロジック的にはメモリ側として考えて、担当コアが受け持つラインブロック単位で担当コアが同時に管理する。
これだとダーティキャッシュを扱えることになる。

しかし、完全排他は無理だな。

Conroeスレからの移動

向こうの>>173
＞しかも、その結果はRead受け持ちコアに一旦集めた後に依頼元へ返信される仕組みだ。
資料読もうよ…。Read担当コアには集めずそのまま依頼元に返してるって。

俺の推測はこんな感じ
Houndを想定してるから各CPUは直結で。

CPU1内の自コアL1L2と他コアL1L2をProbe
　↓
CPU1内の共有L3をProbe
同時にCPU1からCPU3にメモリ読み込み要求を出す
　↓
CPU3は自キャッシュ全ての照会とメモリの読み出し動作を行う
同時にCPU0,1,2へのProbe要求を出す
　↓
CPU3は自キャッシュのProbe結果をCPU1に返信
CPU0,2は自キャッシュ全てのProbeを行う
　↓
CPU0,2はProbe結果をCPU1に返信
メモリのデータがDRAMからCPU3に届く
　↓
CPU3はCPU0にメモリのデータを送信
　↓
CPU0はCPU3にSourceDoneを返信

あの資料から推測する限りこれが自然だと思うんだけど。
各CPUはそれぞれが自立してProbeするわけで。
それがさっきの言葉に引っかかった理由。

すまん、時間切れだ。
また、晩にでもレスするよ。

朝からレス無しか

AMD silently launches Dual-Core Optimiser
http://www.theinquirer.net/default.aspx?article=32790

Conroeスレ占拠しすぎ。
IntelのL2より小さい犬っころの共有L3なんぞに価値など見出すわけない罠

>>346
AMD Dual Core Optimizer Released
ttp://www.tweakguides.com/

マルチCPU未対応のソフトでの不具合解消みたいなもんだ

淫厨のL2キャッシュに対する信仰は、常人には理解できん…
まあAMDもモデルナンバーで差別化してたけど

>>347
占拠って…淫厨ID:guWaYbJCが勝手に喚きだしたろうがｗ

システムバランス＆コストバランスを考えずに、単にキャッシュが多ければ良いと思っている奴はにわか。

65nmになってクロック上げられんのかなあ。

クラックすればいいじゃん

プロセスというより第3世代歪みシリコンで上がる予定。

第三世代歪Siはすでに実装されてるという話もある。

十分リーク電流が抑えられてるなら、微細化でクロックは上がる
逆に抑えられないとネトバのように微細化してもクロック上げられない。

65nm版のラインアップが漏れ聞こえてくる頃にはわかるんじゃないかな

NetBurstは熱の壁でクロックが上げられなかったけど、K8も同じ理由なのかという点が引っかかる。
OCしてもそれほど伸びないしさ。

65nmの最初のトランジスタは最後の90nmのそれと同じってAMDが言ってたよな。CTIとかいうやつ。
だからクロック耐性向上は配線遅延の分しか期待できないんじゃないかな。
Vtの違うトランジスタをどう使うかでも変わるだろうけど。

要素としては持っていくんだろうけど、ゲート長や絶縁膜厚とかまで一緒かどうかなんてわからないんでは？
AMDの65nm製品が出てくるのもまだ先だし。

AMDの65nmは絶縁膜厚1.3nmかな。

プロセス間のトランジスタ技術共有はSTTって名前でしょ。
65nmでクロックは伸ばせるかもしれないけど、消費電力まで抑えられるかはまだ分からんよね。
プレスラみたいにOC耐性良くても消費電力大きかったら製品の競争力は落ちてしまうので、
最近のAMDは90nmでもCTIでトランジスタを改良しつつ、低漏れ電流なトランジスタの割合を増やして
低消費電力かつクロックそのままの"ENERGY EFFICIENT"を作っているんだと思う。
トランジスタの改良のほとんどを低消費電力化に向けてる感じ？
この歩留まりが良好だと65nmではクロックにも傾けられるだろうから、期待していいと思う。

K7/K8はSIMD整数ユニットのレイテンシが2ってのが圧倒的に弱点かと。
ユニットをストールなしに稼動させようと思ったら、4並列になるようにコードをスケジューリングしないといけない。

Core 2のそれはレイテンシ1で済んでてしかもフル128bitなのに。
だから性能の出しやすさに大きな差が出る。

ただ逆にx87やスカラ浮動小数ではいくらか分はあるかと（SIMD浮動小数はまぁK8Lまでは諦めろ）

今どき整数演算のことで優劣語られてもなあ

もっと強力なFPUをくれ
今の10倍くらい速いやつを

しかしMPEGエンコーダやゲームでもパックド整数演算は使うし
浮動小数演算ベースでもマスク演算なんかはSIMD整数ユニットでやる

SSE4で整数演算の強化が行われてるから、使う機会は増えると思ふ。
ほぼエンコーダや暗号処理向けだけど。

>ユニットをストールなしに稼動させようと思ったら、4並列になるようにコードをスケジューリングしないといけない。
MMXで4並列ってことか? 128bit整数SIMDなら2並列でいいと思うんだが。

>>366
それもある意味正解だけど、内部的には上半分と下半分に分解して別々に処理するから、依存関係とかで
スケジューラの負担が逆に増えたりして結局伸びなかったり。

同じこと（１２８ビットSIMDベース）やったら、たとえばCore(Yonah)なら１個のFused-μOPとして扱えるし、
レイテンシ１だから並列処理を気にする必要自体が無くなる罠。

スケジューラの負担を減らすために、K8Lで整数SIMDは128bitになるのか？

>364
一体何に使う気なんですか…

ダンゴリオン（＝団子）は鳥屋を撃沈したと思って
機嫌が良くてたまらんのだろうな。ﾆﾔﾆﾔ

前々から指摘してたことなのに「刑事告発の用意ならあるぜ」って言うまで聞かなかった池沼が悪い
てか、あの居直りっぷり見てて相当DQNだと思いました。
指摘さえされなきゃそのまま違反してられたのに、見たいな愚痴たれてるっしょ。

まぁアレは自業自得です。

HoundのL3は完全にメモリのコピーって主張してた人は結局消えたのか。
何でそんな考えになったのか知りたかったのだが。

かかってこいや

どこかでSIMMとか得意気に連呼してた虫が湧き出しそうな悪寒

団子の読解力にある種の感動を覚えた！

Nは痛い新人雇ったな。

>>370 >>375
えっと、正直、逆に何の話をしてるのかサッパリですわ
心当たりがいっぱいあり過ぎて

えっと、そのインスパイ屋2006さんがおまいらの殿様であるうちは、
いくら技術力で圧倒できても、彼やその取り巻きが気に入らなければ
不可だってことくらいは百も承知ですわ。
なおかつ和解などする気はない。
これでいいかな？

Sun and AMD to share common socket
http://www.theinquirer.net/default.aspx?article=32854

OpteronsとSparcがソケ互換に

amd

>>378
よくわからんけど
なんのメリットがどちらに有るの？

2008年の予定だから、おそらくTukwila(CSI)への対抗策

SparcからOpteronへ行くところはあっても、逆は存在しないだろうな
そう考えるとやっとSparc終わるのかって思う

Sunの解体は着実に進んでいる

IPFとXeonのプラットフォーム共通化は曲がりなりにもx86互換であるIPFシステムの
低価格化にある罠ｗ

しかし、いまだに130nmプロセスが現役なIPFも大概だよなぁ

Alpha AXP が Slot B で Athlon と M/B 共通に出来る(なってた)


なんかデジャヴ…

実際問題、Sunの真骨頂たるJavaの実行速度、SolarisよりWindows、SPARCよりOpteronなんかのほうが速いもの

>K7/K8はSIMD整数ユニットのレイテンシが2ってのが圧倒的に弱点かと。
Conroeのほうが良いのは当たり前だけど、ソフト方面の努力で隠蔽できる程度だろ
そうでなければ、Netburstでベンチが高速に動くなんてありえなかった

>>387
Netburstはクロックの高さが長所だから、
K8にしてみればNetburstをクロック当たりの性能で
ある程度大きく上回る必要がある。

>>385
これか・・・　この後Alphaは・・・・
http://ascii24.com/news/i/hard/article/2003/04/01/642822-000.html

Transitive Emulator Ports Sparc/Solaris Apps to Linux on Xeon, Itanium
http://www.itjungle.com/breaking/bn062806-story02.html

>>387-388
NetBurstのSIMDは実際のところ大して速くないんだよな。
整数はユニットがクロックの半速動作で128bitを2クロックもしくは64bitを2クロックで2命令
（下位と上位は1クロックずれるらしい）

PenMやAthlon64は64bitで等速のSIMDユニットが2基。
Pen4は実クロックこそ、これらのおおよそ1.5倍を実現してるが、SIMDユニットレベルではスループットは0.75倍でしかない。
movaps/movapd/movdqaを使ったLoad/Storeの帯域がものすごいから、それをもってトータルのスループットで
上回ることが出来る（場合もある）。いずれにしても苦しいが。

倍速ALUのほうに懸けてたからな。アレがそもそもの間違いだが。
アレだけでどれだけのダイ面積と電力を消費してたと思う？
逆にアレがあったからこそ整数SIMDのスループットがないがしろにされてた面もあると思う。

パックド浮動小数に関しては、同じく128ビットの半速ユニット搭載
こちらはx87やスカラ演算では下半分しか使えないのでAthlon優位。
128ビットフルに使えば実クロック数の強みとL/S帯域でPen4優位。



この点、Coreマイクロアーキテクチャは、MMXやx87でも十分Athlonに対抗できる性能が出せるだけのユニット数を搭載してる。
むろん等速だし、128bitフルに使えばスループットは倍。
SPECintでの圧倒的な数字はICCのオートベクトライズの効果によるものの可能性が高い。
逆に言うと、Intel C++やVector Cなどの自動ベクトル化ツールさえ使えば、あの程度のコードなら明示的にコードを
記述しなくてもSIMD化してくれるくらい、性能を引き出すための開発者の負担は軽い。

再来年のHoundになっても大した性能向上は期待できないってのがなぁ
4コアなんて要らんし

>>392
Conroeに対してよく言われるセリフを言わせていただく。

発売されていない製品の優劣を語っても無駄

安心したか？

本当に来年の今頃でるならデモがあってもいいころだが…
はて？

>>392
4コアは必要だよ
8コアは今の環境だとわからんが、vista次第だな
かつてDual CPU使ってもいないやつが、「2コアいらねぇｗｗ」って言ってたのと同じ

俺はひとまず10倍高速なFPUをもった16コアのCPUが欲しいです
用途は3DCGです

デュアルコアOp使ってる俺から言わせれば
いくらコアがあっても足りないような業務用とか、不毛な趣味ならともかく

ごく普通のパソコン用途では2コアでおｋ
事務作業用のPCなら1コアでイナフ

>>397
基本的に同意。
結局会社に導入されるＰＣは、
営業・事務はセロリンあたり、
研究・儀重は、今はおｐてろん
になってしまう。

でも個人でも3コアぐらい欲しい。ながら仕事が多いものでｗ

エンコとかゲームとかやってみた限りだと、4CPUまでなら使ってくれるソフトは比較的多い
8CPUは完全とは言わないけど、ほぼ無駄だった。
一部のベンチで8CPU 100%になっただけ。

>>396
オプテロンのソケットで使える２コアなCellが出れば実現しそうだな。

でもメモコンがRDRAMだしHTT対応も要るし、ゴッソリ新規作成が必要そうだが。

>>400
どっちかというとHTXカードでの提供の方が早そうだな。

>>398
3コアといえばXBOX360CPU

Cellの高い浮動小数のスループットなんて所詮単精度だけですよ。
高い精度を求めないゲーム専用の石

Cellネタ引っ張るなｷﾁｶﾞｲ

じゃあ、HoundのCore2のL2より小さい共有L3ネタ再開

ロジック回路小さくしてL2を128MBくらい積めばいいんじゃね！？

今の無かったことにして！

デュアルチャンネルｄｄｒ�Vは１２８ｂｙｔｅ単位でアクセスすることに
なると思うんだけど、キャッシュラインは１２８ｂｙｔｅになるの？

AMDは覚えやすい名前のブツを作るべきだ

いやいやAMDは〜ronという命名ルールを貫くべきだ
Athlon、こいつだけ異端児

>>403
どうせ高性能CPUなんて、ゲームくらいにしか使ってないだろうが。

128byte = 1024bit!

Conroe XE　　 3.33GHz dual 4MB FSB1333MHz TDP 95W '06Q4 　$1199 (Athlon64 X2 4.16GHz相当)
Conroe E6900 3.20GHz dual 4MB FSB1066MHz TDP 65W '06Q4 　$969　(Athlon64 X2 4.00GHz相当)
Conroe E6800 2.93GHz dual 4MB FSB1066MHz TDP 65W '06Q4 　$749　(Athlon64 X2 3.66GHz相当)
Conroe E6700 2.67GHz dual 4MB FSB1066MHz TDP 65W '06Q3 　$529 　(Athlon64 X2 3.34GHz相当)
Athlon64 FX-64 3.00GHz dual 　1MBx2　 TDP ???W AM2 '07Q1
Conroe E6600 2.40GHz dual 4MB FSB1066MHz TDP 65W '06Q3 　$309 　(Athlon64 X2 3.00GHz相当)
Conroe E6500 2.40GHz dual 2MB FSB1066MHz TDP 65W '06Q4 　$269 　(Athlon64 X2 2.88GHz相当)
Athlon64 FX-62 2.80GHz dual 　1MBx2　 TDP 125W AM2 '06/6/6 $1236
Athlon64 5400+ 2.80GHz dual 　512KBx2 TDP ???W AM2 '07Q1
Athlon64 FX-60 2.60GHz dual 　1MBx2　 TDP 110W 939 '06/1 　　$1031
Athlon64 5200+ 2.60GHz dual 　1MBx2　 TDP　89W AM2 '06Q3
Athlon64 5000+ 2.60GHz dual 　512KBx2 TDP　89W AM2 '06/6/6 $696
Conroe E6400 2.13GHz dual 2MB FSB1066MHz TDP 65W '06Q3 　$239 　(Athlon64 X2 2.56GHz相当)
Athlon64 4800+ 2.40GHz dual 　1MBx2　 TDP　89W AM2 '06/6/6 $645
Athlon64 4600+ 2.40GHz dual 　512KBx2 TDP　89W AM2 '06/6/6 $558
Conroe E6300 1.86GHz dual 2MB FSB1066MHz TDP 65W '06Q3 　$210 　(Athlon64 X2 2.23GHz相当)
Athlon64 4400+ 2.20GHz dual 　1MBx2　　TDP　89W AM2 '06/6/6 $469
Athlon64 4200+ 2.20GHz dual 　512KBx2 TDP　89W AM2 '06/6/6 $365
Athlon64 3800+ 2.00GHz dual 　512KBx2 TDP　89W AM2 '06/6/6 $303
Conroe E6200 1.60GHz dual 2MB FSB1066MHz TDP 65W '06Q4 　$179 　(Athlon64 X2 1.92GHz相当)
Conroe E6100 1.33GHz dual 2MB FSB1066MHz TDP 35W '07Q1 　$149 　(Athlon64 X2 1.60GHz相当)

>>411
廃スペック＝ゲーム　というあたりでもうね…
出直してきなさいと小一時間（ｒｙ

>>406
俺はロジック回路は今後縮小されると思ってる。超高速で動き、発熱量小さい簡素なコア
でね。んでAnti-HTとHTTが両方実装されるのではないかと。んで、小さいL1,L2とデカイ
L3(数十M)、それで8コア位になるんじゃないかなと思う。勿論OS側でAnti-HT使った処理
能力の高いコアとHTT使った処理能力の低いコアを判別できないといけないが。

多分マルチコア化に行き詰まったらそっちの方向に進むんじゃないかな？

８ｐｒｅｆｅｔｃｈ×８ｂｙｔｅ×２ｃｈで１２８ｂｙｔｅ

ttp://www.elpida.com/pdfs/J0876E20.pdf
バースト長４(バーストチョップ)というのを使えば
６４ｂｙｔｅでアクセスできるの？
名前からすると連続で８つのデータが来るのを
ぶった切ってると思うんだけど、性能は良いの？

ロジック回路が超小さいItanium2ﾏﾝｾｰ

俺は殆ど単精度で済むんだが
倍精度にする程桁数の多い処理って皆何してるの？

真面目な数値計算各種いろいろ？

最終的な有効数字は、たいていの場合単精度でも表せる範囲内だと
思うけど、浮動小数点演算の場合、計算途中で、有効桁数がどっと
減ることがあるから、安全側に振ると倍精度になるんじゃねえ？
気合い入れて真面目に書けば単精度でも済むことが多いと思うけど、
かなり面倒じゃないかなあ。

あと、Cellは倍精度でもけっこう速いらしいよ。
ttp://slashdot.jp/comments.pl?sid=322480&cid=969082
しかしこの結果見るとIA64使う意味ないねえ。
AMD64の方が安い分マシ。

１．東工大がTSUBAMEを公開
7月4日の@ITに西川特任助教授の談話として，「構築に20億円、電気代やサポートエンジニア費用
などの運営費に年間3億円掛かっている。入札で各社が頑張ってくれたので、本来であればとても
この値段で構築できるシステムではない。」と書かれていますが，一般に値引率が大きい大学商談
としても相場の半値以下の感じで，こういうダンピングをやるから，スパコンは儲からない，儲からな
いから開発費が出ない，従って，開発エンジニアが減らされて東工大の卒業生も採用できないという
悪循環に陥ってしまいます。大学の先生が，値切って，自分だけ安く買えれば万歳，あとはどうなっ
ても構わないというセンスでは困ったものです。

コピペするなら引用元くらい書けよ

>>418
CADなんか普通に要る
精度は0.001ミリ（小数点以下3桁）程度は普通だし、
設計するもののサイズが1メートル以上なら小数点以上に4桁必要
最低でも7桁の精度が要るけど、単精度は6桁しかない

>>419のリンク先のリンク先のバークレーの論文によるとOp248で実験
プロセッサ数が書いてないんだが、書いてある数値からすると1CPUでの値っぽい。

K8LクアッドコアOpとかになると、倍精度ではベクタとかCellとそれなりに戦えそうだなぉぃ。
x86系のCPUがここまで戦えるっつーことにちょっとﾋﾞｸｰﾘ・・・

でもCellより、現行の汎用PowerPCの方が速い

>>422
CADで使ってるユーザーが、果たしてどれだけ居るのやら。

単精度で間に合うユーザー>>＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞倍精度が必須なユーザー

IA32のCPUが数多の非IA32な他CPUを駆逐していった歴史を見れば、単純な絶対
性能差が市場での勝敗を決めないのは、一目瞭然でそ。

>>424
その汎用のPowerPCをＰＣ用にエンハンスしてくれなくなったから、MACがIntel
に鞍替えした訳だが。

そうか？
むしろ俺的には、ゲームとかの不真面目（というのは、失礼かもしれんが）な
分野以外じゃあ、浮動小数点数≒倍精度という認識なんだが

俺自身、技術系と業務系の経験しかないんであれだが
ぶっちゃけ単精度を仕事で使ったことは一度もないし

普通浮動小数点といったら倍精度

単精度はグラフィクスとかの"使い捨て処理" 専用だと思ってた

>>426-427
倍精度、倍精度って言ってるだけで抽象的な発言ですね。
宗教論争と変わらん。

GK乙

AMD売れてないんだそうですね

誤差が累積するような計算は倍精度じゃないと実用にならないよ。
電気でも流体でもシミュレーションやるなら必ず倍精度。

Reverse Hyperthreading does not exist
http://www.theinquirer.net/default.aspx?article=32885

やっぱガセだったっぽいね。

>>419
PPEはフルセットのPowerPCだからそりゃFPUも載ってるし、
SPEではソフト処理させる必要があるが、それでも7コア分あるから
クロック数×コア数の力技でそれなりの性能は出せてるみたいだけど
↓
http://www.cs.berkeley.edu/~samw/projects/cell/CF06.pdf


Core2はパックド倍精度を利用することで１コアあたり4DP/clockの演算が可能。
これが年内には4コア搭載で、合計16DP/clockに達する。
2.66GHzなら42GFlopsを超える。（単精度ならその倍）

なんにせよCellは専用のコア設計をしてもまだあの巨大ダイ。発熱もかなりのものらしいし
高い玩具の域を出ませんわ。


＃いずれにしてもItaniumは要らない子になってしまうね。

>>433
Core2 Duo 2.66GHzが42GFlops…
Core2 Duoでも、AltiVecを上回れませんか…

>>434
倍精度の話をしてるんだけど。単精度なら単純にその2倍ですが。
AltiVecでいつ倍精度がサポートされたんですか？（・∀・）

AltiVecうんこ

AltiVecの性能ってさ、どうせ積和(vA * vB + vC)演算だけは
1オペレーションでできるから2×4で8SP/clockとか言ってるんだろ。
同様にCellのSPEもだろうけど。
積-差や和-積なんかはもちろん2オペレーションかかる。
8SPだと思ってたらガッカリすることになるだろう。

Core2は単精度×４or倍精度×２の加減算ユニットと積算ユニットが
それぞれ１つずつだから、積＋和はもちろん積＋差でも、さらには単精度の加算と
倍精度の積算でも、同時に並列実行できる。
AMDもK8Lでそれに追従する形だ。

ゲーム機としては贅沢な石だが、コンピュータとしてみれば、Cellは言われてるほど高性能じゃない。
平均性能がカタログスペックの20分の1というSCEの伝統を覆しそうに無いしな。

DSP と CPU の中間だと思えば面白い石なんじゃないの?

>>438
面白いって意味じゃ、これ以上ない石じゃないかね。
自分の趣味で叩くのにはいいと思う。
ただ、やっぱり倍精度FP性能がもうちょっとあると
嬉しいかなあ。

GKの戯言なんか聞く必要ないよ。
Core2 DuoとかCPUアーキテクチャスレにもCell厨が湧いてたしな。

PS2のCPUだって、関和演算やマトリックス演算だけは
恐ろしいスループットを誇っていたではないか。
現実には(ry

ユーザープログラミングの余地がちゃんとあるかどうかで評価は分かれそうな気も。
PS3がパソコンだって言い張るなら、MSオフィスが動けとは言わないけど、GNOMEなりKDEなりが
実用的な速度で動くのは最低限だよな。

PPEはともかくSPEは倍精度はハードでサポートしてないから、パックド整数を駆使して
ソフト的に処理しないと使えませんぜ。
命令スケジューリングとかで骨が折れる事間違いなし。

Cellがたいしたもんじゃないってわかりきってたんだから、お前らスルーしろよ
さんざんファビョった挙げ句、今更どうこう言うなんてアフォだな

久しぶりに覗いてみたら何でCellの話になってるの？
Appleにも売れず外販の見込みすらなく、Sony本体からも駄目出しされてる出来損ない。

倍精度倍精度焙煎にんにくうるさいな

>>428 >>431
精度が要求される計算は倍精度でも足りない。
本格的にシミュレーションするなら128bit以上使うでしょ。
逆に余り精度が要求されないなら単精度で大概間に合う。

>>440
むしろアンチソニーの方がウザい。
SPEにも倍精度ユニットが搭載されてることくらい知っとけ。

↑最高にアホ

パックド倍精度「命令」ならあるが直接実行できる「ユニット」はない。
マイクロコード実装で、複数の整数演算の組み合わせで実行される。
逆にソフトでやるからこそIEEE754規定の精度に従うことができる。
自前でソフト実装しないと使えないというのは誤りだが、都度ソフトで
実装してやったほうが速いかもしれんわな。

単精度のほうは精度は度外視。IEEEのフォーマット上は23bitの
仮数部があるが、事実上の精度は15bit程度。
そのへんはSSEでも同じ。

>>447は本当にｱﾎだなｗ

まったく関係ないけど
アンチソニーの流れって凄いよね
製品ごとに善し悪し有るだろうに

その「悪し」代表がCell

アンチCellならアンチIBMに流れそうだけど…
例の企業とIBMが契約してるのか、Sonyに法則発動中なのか判断しかねるが

■後藤弘茂のWeekly海外ニュース■
コプロセッサの時代を開く、AMDの「Torrenza」イニシアチブ
ttp://pc.watch.impress.co.jp/docs/2006/0713/kaigai287.htm

AMDはコアの開発よりコプロベンダを囲い込む戦略でいくようです
どっかみたいに買収を繰り返すつもりなんでしょうか
個人的にはPCクラスタ用にネットワークカードをHTXに挿してシステムバスに流し込めたらｲｲｶﾅ

>>453
そのためのinfinibandカードと一緒に出てきたのがHTXだったろ。

最近エンコが多いので、エンコ用コプロがあればなぁ〜
それ以外はＣＰＵ負荷ほとんどないのが意味ないｗｗｗ

>>448
EEと勘違いしてるだろ。
http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318&p=4
>Unlike the Emotion Engine, the SPE contains a double precision (DP) unit.

>>442 >>448
どこからその自信たっぷりの発言が沸いてくるのかソースが欲しいところですな。
http://www.cs.berkeley.edu/~samw/projects/cell/CF06.pdf
この辺の論文を見る限りCellは倍精度でもそこそこの速度が出るようだけど。

基地外GKの連投乙

「そこそこの性能」ってのは8コア（PS3では実働7コア）分でだろｗｗｗ
計14.63GFlops（ピーク性能）ごときじゃKentsfieldを出すまでもなく
Conroeのローエンドにも負けだな。

いったいその低速なDPユニットがどんな構成になってるのか説明してみてくれよｗｗｗ
理解の範疇超えてるぜ。

いずれにしても、Kentsfieldと同時期に出る石と2004年のシングルコアアーキテクチャを
同列に比べても意味の無い数字だ。

PCにはベクトル化・パラレル化しにくい処理こそ重要であって
GPUにでもやらせておけばいいFP性能（それも複数コアの合計値）で
オナっても意味なし。

なんにせよ、地に足のついてない新設計のCPUを出しても、マシンごとに
新たにコードを書き直すのが当たり前のゲームならともかく、既存コード
資産でのパフォーマンスを重視するPCやサーバ市場で受け入れられる由は無い罠。

しかもゲームですらたかだか800MHz程度の低速CPU積んだマシンにも劣勢らしいがｗ
暴れたくなる気持ちもわからないでもないが、PCのコプロセッサとして利用とか
活路でも見出さない限り、この板的には要らない子だね。

Conroeの2.4GHzの倍精度だと19.2GFlopsか。
Pentium XE 965（3.73GHz）だと14.93GFlopsね。

Cellの倍精度演算の仕組みは知りたいな。

>>457
単精度ユニットがあれば、単精度計算を数回繰り返すことで倍精度計算は可能だ。
っていうか、問題はそこではない。

CellにはSPE毎に32bitの単精度ユニットが4つ搭載されてはいるが、
64bitの浮動小数点演算を1サイクルで実行可能な「倍精度ユニット」は実装されていないのだよ！

倍精度ユニットがあれば、2ユニット*8コア*3.2GHz = 51.2GFLOPSが理論上可能なハズだ。

>>460
単精度数回で倍精度って相当きつくない？
まともに倍精度を意識したハードでないと
14.63GFlopsとかすら無理だと思うけど。

>>461
数命令/数サイクルだとHWサポート無いとキツイかﾅ・・・

CellだとSPで理論値200GLOPSくらいで、DPになると7%くらいに激落ちしてるから
とりあえずHWで有効な倍精度サポートが入ってるとは思えないなｗ

倍精度サポートしてるなら50や100GFLOPS逝っておかしくない

ttp://www.theinquirer.net/default.aspx?article=32978
>PS3 Cell yields are in the toilet

ゲーム機はもうPCベースにすれば良いよ・・・
仕様とOSだけMicrosoftが作って
ハードはそれを満たせばいいって。

MSX復活。

>>463
>ゲーム機はもうPCベースにすれば良いよ・・・
PCがx86から乗り換えてくれるなら、賛成

コプロ

HWサポートはIEEE倍精度浮動小数形式と複数のパックド整数/単精度との
相互変換さえあればなんとかなる希ガス。
どのみち倍精度関連の命令は単精度との変換以外は加減算と積算・積和算しかないので、
足りないものはソフト実装しか無い罠。

つか、どうせピーク性能だから加減算の性能だろ。

両仮数を32bit整数×2×2に展開
↓
指数の大小比較
↓
小さいほうの仮数を差分だけシフト
↓
普通に整数加(or減)算
↓
桁上げ（or下げ）の解決＆浮動小数形式へのパッキング

これで俺の脳内では2DP/4clk程度のスループットに収まると思ってるんだが

乗算は複数回の積和算が必要になるな。上位53bitだけ求まればいいので
そこそこテキトーでいい気もするがな。

ttp://japan.cnet.com/news/ent/story/0,2000056022,20170387-2,00.htm
65nmは今年中に出荷されるみたいだな。
原文も"AMD will start to ship chips"だし。
もしかしたら年末には秋葉で手に入るかも？

あと45nmが液浸ってのは初めての情報のような。
SRAMを試作したっていうのはすでに出てきたが。
Intelはドライ露光だけど、コスト的にはやっぱ液浸の方が高いんだろうなあ。
"欠陥数はすでにドライ露光と同レベル"とASMLは言ってたりするから歩留まりは時期的にも問題になりそうにはないが。

>>461
底抜けのアホばっかだよなぁ。
整数ならともかく、浮動小数点数の場合、
半分ずつ分けて計算なんてできるわけねえっつーの。
packed整数って何のことかも知らずに言ってる奴は救いがたいアホ。

PS 3のHDDにフル機能Linuxを搭載
http://pc.watch.impress.co.jp/docs/2005/0609/kaigai187.htm
だそうです。

しっかし、CellのSPEには倍精度浮動小数点演算器も搭載されているって、全然知られていないんだな。
http://ascii24.com/news/i/tech/article/2005/02/10/imageview/images765508.jpg.html
ISSCCではCellの倍精度乗算器について論文発表があったし、die photoにも見ての通りDP部がある。
http://www.geocities.jp/andosprocinfo/wadai05/20050219.htm
ま、計算速度が非常に遅いので、用途がかなり限定されそうだけど。

>>467
期待しても無駄だよ。
AMD社が発表している最新のロードマップだと65nmの供給は2007/1Qからだし本格化するのは2007/3Q。
その段階でも、高クロック品は90nmだから90nmと同等のクロックになるのは年内一杯掛かりそう。
TDPは65Wで90nmのEEと変わらないし性能も全く同じ、変化しているのはダイサイズと65Wの選別が楽になる程度。
こんな調子だからK8Lが2007年に発売されるなど期待しない方がいいし、性能も期待しない方が良い。

> ttp://images.dailytech.com/nimage/2008_large_amd_q307.jpg

↑なんなのこれ。

プロセッサーが十分高速になった昨今、重要なのは性能よりも価格や値下げではないだろうか。

>463
それなんて XBOX?

AMDがプロセスで遅れるのはある意味必然だからな。
intelの生産終了期の歩留り≒AMDの生産開始期の歩留り
らしいから。

dailytechの記事を「AMD社が発表している最新のロードマップ」と言うのはどうかと思うが・・・。
R-HTTの時も真に受けて必死に反論してたんだろうなぁ。

だから負け犬GK（ID:JBJ3+3bd ）はスレ違いってか板違いだから来るなって

内部構成がどうであれDP演算があからさまに遅いことに変わりは無いだろ。
インオーダだからその低速っぷりに後続の命令は待たされるんだよ。
だからブラックボックスとしてみればどういう演算ユニット構成だろうと
遅いものは遅い、それだけ。

得意の単精度浮動小数ですらスカラ性能で見れば数十分の１程度。
SPE全部に均一に割り振れるような単純な演算でのスループットなんて
汎用性がなさすぎるの。
256KBのアドレス空間に命令コードとデータが収まるかっつーの。
それが７〜８個ってデータの出し入れを担当してやらなきゃいけない
PPEの負担どんだけ重いんだよ。
そのPPEすら2issueでインオーダの貧弱なコアだしな。

大量の物理演算専門のコプロならPhysXがあるしこちらは既にMSもDirectXで
サポートを表明してる。PC用途でCellの出る幕は全く無しだ。
とにかくCellなんて自作板には要らないクズCPUだから
ゲハ板にでもスッテンロ。

何だが倍精度ヲタが必死だが、それはそれで倍精度専用のコプロを望めば
済む話ジャマイカ。

Cell登載のコプロはそれで充分用途はあるし、少なくとも倍精度用コプロ
より思いっきり沢山売れるだろう。そしてそれはAMDへの貢献度合いの差に
もなる。

今後のAMDのコプロ政策の中では、どちらが優秀という話は不毛な論争だと
思う。

倍精度が遅いだけが問題じゃない。

SPEが直接メインメモリから読み書きできない。
PPEから明示的に読み書きしてやらねばならず、命令・データ合わせて
256Kに収めないといけない。
256KBじゃ、ポケステやドリカスのVMのミニゲームが入る程度だぜ
とても汎用演算には不向き

さらには32bit固定長命令なのにレジスタ一個指定するのに
7ビットも使ってるせいで、命令セットの拡張が困難。
使い捨てアーキテクチャもいいところ。

まとめ。

2000年前後〜デュアルコア製品が登場し始める。
数年後…

2005年〜Athlon64 X2が登場。「これからはデュアルコアの時代だ！」
同じ頃、Cellが発表される。仕様をみるとピーク以外はたいしたことがないのはわかっていたが、
外界に目を向けない鎖国民たちが「８コア」の部分にのみたまたま見てしまい反応し、騒ぎを起こす。

1年後…騒ぎを起こしてファビョっていた連中が「Cellは結局〜〜なんだから」と気づき、自ら騒ぎを起こしたにも関わらず、Cellの話題を出すと怒り出す。

まあ、じきに鎖国に戻り、信者たちは外界に目を向けなくなるだろう。
めでたし、めでたし。


で、AMDの話題は？あ、発売されてもいない製品を語るのはダメなんでしたっけ＾＾；；；；ｗ

これから変革期らしいけど
Core2Duo対AM2が当分続くの？
前評判だとインテルに分がありそうだけど、AMDに対抗策は？

最低でも2007年までは、ＡＭＤやられっぱなし。

そうなんだ…
ソケAから乗り換えたかったけど、アムダーだし我慢しておくよ

>>480
ES品が出ても話題にしては駄目です
正式に発売してからでないと怒る人たちがいますから。

まさかAMDだけはいいっていうおかしな人はいないと思いますけどね＾＾；

>>471
これってコピペ？

AMDだけは発表前でもOK牧場。









なぜならここはAMD次世代スレ。
決してCell雑談スレではナイ。

スレタイも読めないほど国語力が低い連中にそんな難しい話が理解できる訳が無いｗ

Cellは最強の撒き餌だという事はわかりました

AMD は '4x4' Power Programs で Conroe に反撃
http://www.pcmag.com/article2/0,1895,1989028,00.asp

>4x4 プラットフォームはマザボに二つの物理的なソケットを配置、
>二つのソケットは AMD の Direct Connect アーキテクチャによって互いに接続されている。
>AMD Athlon 64 X2 プロセッサが両ソケットに搭載され、計 4 コアになる。

>8 コアの "8X8" プログラムの登場は 2007 年。
>4 つの仮想的なプロセッサコアを持つ二つの物理的なプロッセッサで構成される予定。

>4x4 プラットフォームの登場時期についてはまだ公式に明かされていないが、
>AMD の広報担当は「早いうちに発表します」と言い、
>インテルをある程度出し抜くことができる時期に間に合わせる可能性をほのめかした。

Athlon 64 x2 １つのシステムと比較して、開発中の 4x4 プラットフォームでは
Vista の最新 beta 上の 3DMark 06 や Maxon Cinebench R9.5 、 WinSAT などの
マルチスレッドのベンチマークで、平均 80 %　のパフォーマンス向上が見られる。

>>486
> AMD は '4x4' Power Programs で Conroe に反撃
へー、そりゃ凄いね、INTELもびびり捲ってると思うよ。
まぁ、そういうことで、俺はConroe買って横から眺めているからガンガレw

録音、また1日中２ちゃんか？

>>481
インテルはどうなんでしょうね？
FSBいつまで使い続けるんだろう・・・。

いや、流石に8X8は…
可能不可能じゃなくてさ…一体いくら掛かって何ワット必要なんだよ…

http://enterprise.watch.impress.co.jp/cda/static/image/2005/04/22/fy05-048_dl585.jpg
http://h50146.www5.hp.com/products/servers/proliant/dl585_sh.html
1000�hくらいじゃね？

>>494
リンク先に870Wと800Wと書いてあるが？・・・
もちろん電源容量だから使用量はもっと下か・・・

100WクラスのGPUが4つ8つ搭載されるとなると、それどころでは済まない・・・・

>>495
リンク先の話な・・・誤解させる文書でｽﾏｿ

次元の超えた爆音を轟かせるエンスージアストPC誕生の予感

ttp://sources.redhat.com/ml/binutils-cvs/2006-07/msg00051.html

ttp://sourceware.org/cgi-bin/cvsweb.cgi/src/include/opcode/i386.h.diff?cvsroot=src&r1=1.68&r2=1.69
K8Lに追加されるSSE命令群はSSE4aと呼ばれているようだ。

ttp://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-i386.c.diff?cvsroot=src&r1=1.218&r2=1.219
PROCESSOR_AMDFAM10の定義にCpuMNIが入っていないので
MNI(SSE4)は使えないかも

「CELLチップの歩留まりは良くて１０〜２０％」
http://blog.japan.cnet.com/nakajima/archives/002988.html

何だこのレベルの高いスレは。お前らいったいどこでそんな知識身に着けてきたんだ。

AMDに関係ないことが殆どだな

>>500
スレ違いなわけだが…
元記事 (www.reed-electronics.com) の方を読むと、「良くて 10%〜20% だが、
logic redundancy があれば、それを倍にできる。IBM 以外で、(CPU について?)
それをやってるところがあるかどうかは知らないが」とあるので、なにもないと
10%〜20% だが、IBM の力で 20% 〜 40% にしてるとも読めるんだが、本当の値は
いったいどちら？

このインタビューでの、logic redundancyってのは、SPE8個のうち7個を使うだけってことで、それでチップの歩留まり上げられる
ってこと自慢してるんじゃないかと
あと、10〜20%ってのも、IBM以外の会社ならCellくらいのサイズのチップをつくれば、その程度しか歩留まり上がらないだろうね
って感じで、例にしかすぎない気がする
本当はもっと良いのか、悪いのかは謎だけど

ブログの中島さんもウソを書いてるわけじゃなくて、自分が別のところで、SPE8個そのまま使う仕様だと37%くらいじゃねって
勝手に予想してたのが、IBMのインタビューで10〜20%ってえらい低い数字を挙げてるから、ついそれに飛びついちゃった
だけかと
つまり、タイトルが恣意的で、内容も別記事を見ないとちゃんと把握できないという嫌らしい書き方だ

普通にやれば、10%〜20%になるが、logic redundancyを使っているから37%になっている

ってことか

ん？PPE１個＋SPE7個での歩留まりに決まってるだろ
１コアは無効にして出すことは決まってるのに、何で全コア分動作するダイの歩留まりに言及する必要があるんだよ

「100mm四方のダイ程度の歩留まり」とは言うが、IntelやAMDのメインストリーム〜バリュー向け
ダイは、90nm四方程度で、それを更に「logic redundancy」やってるわけで。

たとえばYonahであれば片コアが動かないものはCore Solo、
さらにキャッシュ半分のCeleron M 4xxシリーズなどという風にローエンド版に
回すことにより、フルセット版としては基準落ちのダイを有効活用することで、
償却効率を上げている。
さらに、スペックは固定でないから全部2.16GHzで動く必要は無く、クロック耐性に
応じて低クロックのコアとすることができる。

Cellが100mm四方相当ならIntelやAMDは50mm四方相当ですか？
Cellの歩留まりは十分悪いでしょうな。

元記事のインタビューでIBMの副社長さんが言ってるんだから、漏れにかみつかれても…

Electronic News: What’s the defining factor that makes some chips better than others?
Reeves: Defects. It becomes a bigger problem the bigger the chip is. With chips that are one-by-one and silicon germanium,
we can get yields of 95 percent. With a chip like the Cell processor, you’re lucky to get 10 or 20 percent.
If you put logic redundancy on it, you can double that. It’s a great strategy, and I’m not sure anyone other than IBM is doing that with logic.
Everybody does it with DRAM. There are always extra bits in there for memory. People have not yet moved to logic block redundancy, though.

10〜20%って数字を挙げてるところの主語は"you"だから、IBM自身の歩留まりについて話してないでしょ。あくまで一般論みたい感じで、
他社がCellみたいなチップ作ったら、10〜20%がせいぜいだろうって言ってる。
で、"you"がlogic redundancyを使えば、"you"も歩留まりを倍にできる、と副社長が言ってるわけだ。
で、その後でlogicについても、IBM以外に冗長構成やってるかは知らんが、DRAMだとやってるねー。logic block redundancy
だと、まだ一般的じゃないようだね、とIBMの副社長が言っている。
というわけで、記者の質問に対し、"logic redundancy"を使うのがうちのチップ製造の肝だ、とIBMの副社長が回答してるだけで、
10〜20%って数字が実際のCellの歩留まりかどうかは、よくわからんのじゃないの？

logic redundancyがSPE1個冗長の構成、という話と読んだのは漏れだから、違うといわれたら、そうかもしれないが

とりあえずIBMはAMDから歩留まりのノウハウ？を手に入れたらしいから10〜20%なんてことはないと思う。
AMDのSempron（たぶん）は95%の歩留まりらしいからな。

スレ違いを続けて本当に申し訳ないが、中島さんの37%って試算の数字も、PPE1個＋SPE8個だと37%で、
PPE1個＋SPE7個だと69％で、SPE7個にするのは経営上正しいって話で出てきただけ
（計算の前提は、http://satoshi.blogs.com/life/2005/05/post_12.html　を見てくれ）
中島さんも10〜20%を37%と比較してることから、logic redundancyについてはSPEの冗長構成と読んでる模様
だからと言って、漏れの読み方があってるかはまた別問題だがなー

>>508
分かりやすい解説有り難うございました

>>480

冗長化は主要なPCメーカーなら既にやってるしIBMのお家芸でも何でもない。
INTELにしても冗長化しやすいキャッシュを大きくしても歩留まりがあまり悪化しないのはそういうことだ。

>>513
察するに、IntelのプロセッサはSRAM素子でロジックを実現しており、
そのためPCメーカーが後付けでロジックの冗長性を確保することも
可能、という発言趣旨かと思うが。

まさに次世代だな。リコンフィギュラブルすぎ。

>>479
SPEに何のためにDMAコントローラが乗っているのかと。
しっかい相変わらずここはアンチCellスレだなぁ。
アンチやるにもちょっとはもう少し知識を付けては如何でしょうか。
醜いですよ。

どっちもスレ違い

64bitは苦手なCore Microarchitecture
http://pc.watch.impress.co.jp/docs/2006/0718/kaigai288.htm

>>517
あくまでも32bitと比較しての話だから、Core x64動作　＜ K8 x64動作　って
話にはなってない。

まあ次回の記事にネタを残しただけだろうから、ワクテカしてマテ。

>>518
その比較はもう意味がないんじゃないかな。このあまりに悲惨な数字を見てしまうと
64bitアプリケーションを走らせるためにCoreが選ばれることはほとんどいないと思える。
(32bitで走らせれば1.5倍速いCPUを敢えて遅い64bitとして使うのはかなり勇気がいる)

興味深いのは64bit OS上での32bitアプリケーションの性能かな。これがそこそこならば
まだなんとか64bitモードの意味がある。

結局「全方位及第のAMD」と「一点豪華なIntel」という構図は変わっていないが
「今までのコードが速いAMD」と「新しく書いたコードが速いIntel」の構図は
64bitの観点からは混沌となったかもしれない。

別にintelびいきじゃないけど、WoodcrestのベンチだとOSはWin鯖x64やXPx64だが？
ちゃんとベンチテスト環境を見ずに数字だけ見ても意味ないんだがなー
あとアスキーのベンチでも（これはベンチ環境が謎だが）、64bitがまんべんなく遅くなってるならともかく、
64bitの方が速いのもあるので、結局コードの最適化の話で、intelコンパイラだと64bitだと32bitよりさらに
速くなりますよって、可能性もなきにしもあらず

つまりインテルのCPUはわざわざ最適化してやんないと何も出来ないゴミってこと

>>520
ねっとばーすとの時も今後コンパイラの改良が云々と言われ続けてきた末に今があるので
microoptimizationには期待しない方が。「64bitの方が速いものもある」という状態から
コンパイラによって「64bitの方が遅いものもある」という状態にまで持っていくのは無理。

その前に新しいコンパイラが出ても使ってもらえないという現実の深く広い川が……

しかも、今のConroeに合わせた最適化をすると、64bitに合わせたCPUを作ったときは、また最適化し直さないと性能が
でないということになるだろうね
いつものintelのことだが

ちなみに、Woodcrestの方が性能上ってグラフだけど、x64のベンチが少ないのでまだ微妙だが、64bitだとクロック辺りだと
Opteronとほぼ互角の印象を受ける
Hound世代できちんと性能アップしているなら、intelのDP鯖奪回作戦もそうそう上手いこといかなさそうだ

32bit/64bitに限らずとにかくフェッチ帯域が足りないと思う。
9バイト10バイトの命令なんてSSE使ってたらガンガン使うのに、フェッチ帯域ネックで
演算ユニットに行き届かないってのが最悪のパターン

次の世代はかなり期待出来そうじゃないですか？

>>521
この世のどんなものでもそうだろ

>>524
お前アホだろ?
そんなこと言い出したら、CPUなんて何もかもが足りていないよ。
SSE処理は十分に高速なのになにをほざいている。

IntelはItaniumがあるので
AMD主導のx64にはあまり力を入れていないのだろう

クマー

>>528
単純に時間不足だったんだと思うけどな
IA-64があるからというか、HPの手前捨てるわけにもいかないし、
独自なx86-64を作ろうにもMSからサポしないと言われたら実装もできないし

時間不足と言えばVTの方はどうなってるんだろう。

>>527
お前アホだろ？
逆汗してみればわかｋるが、最低でも4バイト、REX付きなら5バイトは使う。ロード・ストアが絡めば8バイト
CoreMAくらいユニット数がリッチだとユニット使い切るのに全然足りねーんだよ。

断言するが、CoreMAに改良がない限りAMDはK8Lで圧倒的な逆転を遂げる。

64bitもそうだけど>>530の言う仮想化技術も、すごく中途半端な実装なんだよね
どっちもこれから旬な技術なのに・・・
32bit蔵ではいいかもしらんが、鯖市場では微妙になってしまう

分かりやすい話をすると、CoreMAは上り下り計256ビットのL1間転送帯域と
128bitのload/storeを各1本持つにもかかわらず、L1の読み書きのスループットは
多くのケースでNetBurstの256bit/clockに満たない。

なぜか？
フェッチ帯域が足りないから。

K8LはもしくはLoad/Store各1つに加え、128bitのLoadを2つ、同時発行可能だが、
16バイトの命令帯域じゃ使い切れるわけがない。
K8Lのフェッチ帯域の32byteへの拡大は必然といえる罠。

＞だんご
使いきれないほどのunitを載せた理由を説明してくれ。

いっぺんに改良は大変なので弱いところから順に改良していくから。

よく練られたコードを除き、まんべんなく分散されるよりも
一つのユニットに負荷が集中する事の方が多いので
各々のユニットに余裕を持たせておく必要があるから。

デコーダが2命令/clockでLoad/Storeが3個の場合
初めからデコーダを3命令/clockにしないからアンバランスなんだ
という話になるが、実際にはLoad/Storeの帯域、フェッチの帯域、
ALUの数、Conroeに見られるようなデコーダやuFusionの特性、
もっと広い範囲で見るとL1, L2の帯域など様々な要因が織り混ざって速度が決まっている。
従って、何らかのユニットが2個だと少ないが3個だと使い切れない、
といった単純には割り切れない状態になっている可能性が考えられるから。

とりあえずNetBurstよりクロック数が落ちるからSIMDの増強は急務だったのでしょうな。
90nmでNetBurstの失敗が明らかになるまではCoreMAはモバイル用のアーキテクチャだったので
SIMDユニットは64bitで、SSEはμOPsフュージョンでやるものと思ってました。
なんでこんな化け物がTDP34W程度(Merom)に収まるのかただただ不思議ですわ。

なんにせよ、トレースキャッシュ採用を本気で信じてますた。
うまくバランスをとれば省電力技術と高性能を両立する技術になりうると思うし
実際オレゴンもイスラエルも次の世代のCPUはトレースキャッシュ採用のようですが。


なんにせよ、1スレッドの性能を上げるための技術は引き続き必要になると思います。
クロックが上げられないから尚更ね。

ダンゴはアフォ決定だな。
K8Lだと云々と言う。
しかしK8はダンゴの思惑と違ってConroeより性能が悪く、ダンゴに言わせると設計ミスの屑CPUとなる。
されど、K8Lは違うの言い張る。
AMDの広報を信じて疑わぬのは何故だ?
K8Lはダンゴに言わせると屑CPU、そんな屑CPUしか作れないAMDの広報を何故信じているのか聞かせてくれ。

K8がConroeより性能が悪い→K8は設計ミスの屑CPU
K8が屑→K8Lも屑

という論理がすでに破綻してけど、あえて同一論調で言うのなら
K8の足元にも及ばなかった屑CPUのNetburstしか作れなかったIntelが
Conroeを生み出せた事実をもって、反証となると思うけどね。

まあ何にせよ、現物勝負じゃね？
どこの会社の看板背負ってるかで、現物の性能が変わるわけでもなし。

その時代にあったものを作るだけでしょう。
CoreMAにもっと早期に着手してたとしても90nmで作れてたとは思えない。
シングルコアでもおそらくTejasなみの巨大ダイになってたはず。

Pentium Dだって、90nm時代は圧倒的に負けてたけど
65nmプロセスになってAthlon64 X2とためはれるだけの消費電力レンジに落ち着き、
性能の出せるクロックまで上げられるようになってる。

今はIntelがプロセスでリードし、しかも新アーキ投入でリードしてるからこういう状況に
なってるけどプロセスルールは互角になり、新アーキも投入。
後発の強みでAMDがリードに転じても何ら不思議はない。

K8LがK8の拡張にすぎないなら、CMAはCPUIDが示すとおりPentium Proの拡張の拡張ですが。



整数での優位はどちらに傾くかは微妙だけど浮動小数は十分逆転可能なスペックですわ。

とりあえずﾊｧﾊｧできればいいだけの一消費者としてﾀﾞﾝｺﾞの予言にwktkしとこう。




外したらてめーのうんこを食ってやるからな！

ここまでの一連の発言で、ダンゴがアフォで知ったかなのは明らかだと思うが、
匿名とは言え、変な宣言するのはやめとけ。

ID:SzK9d2Cj がアフォで知ったかでは無い発言をしてくれるそうです。

んじゃ俺様が代理で、
てめぇら、よーく耳の穴かっぽじって聞けよ。
K8Lに多大な夢見るんじゃねぇぞ、こんにゃろ。
回路を増やしますとか、機能を上げますとか言ってもだな〜、
それが本当に実現されるのかは物が出てみないことには分からんのだよ。
しかも、回路を増やしたり、一部の性能を無理矢理上げたりすると、どこかにそのしわ寄せが起こり、そう簡単に性能が上がる訳じゃねぇ。
これをトレードオフと言うのだよ。
ダンゴのアフォはそんな当たり前のことを無視してK8Lをマンセーしているから叩かれる。
世の中甘くねぇぞ、もっとシャキっとしろ、シャッキっな。

Conroeはブツが流れ出す前からﾏﾝｾｰレスが氾濫してたわけだがｗ
それにそんな素人な話より似非でも何でもマニアックな話のほうが読み手として面白い。

K8Lについてネガティブな見方が多い中、ﾀﾞﾝｺﾞのポジティブな意見は面白い。
お前のレスはつまらん。

「性能が上がるとは限らない」って言うだけなら白痴でも出来る詭弁。
SSE自分で触って経験も踏まえて語ってる香具師に何も例を述べずに
アホといって掛かっても説得力が無い。

SSEのユニット幅倍増による演算スループット向上に合わせ、フェッチ帯域を拡大するのは妥当。
メモリロード付き演算のネックが解消するため、実質的な命令帯域は向上する。
さらにフェッチ帯域の向上は64ビット汎用演算のスループット向上もはかれる。
たとえば add r64, imm64 で10バイト。フェッチ帯域16byteなら3命令取り込むのは
厳しいが、32byteなら余裕だ。
Core2よりキャッシュ容量は少ないが、メモコンやHTバスの帯域はある。
整数のピーク性能は高くないだろうが、長い命令安定した性能は得やすくなる。

技術的な問題であれば、K7/K8はL1命令キャッシュにフェッチする際に
プリデコードを済ませているので、フェッチを倍増しやすい。
さらに、プリデコード情報を用いてデコード前の段階で汎用整数パイプとFP/SIMDパイプに
振り分けてしまうので、デコーダの負担も軽く、66Hプリフィックスなどの問題を抱えなくて済む。

Core2はフェッチ帯域を32byteにしなかった理由は想像に難くない。
Core2のプリデコードはフェッチ後なので、フェッチ帯域を増やしても
今度はプリデコードユニットがネックになるだろう。
トレースキャッシュの発想自体はK7/K8のプリデコード命令キャッシュより
進んだものであったはずなのに、P6に退行している。
アラが多い。

問題は、命令長が長くなるとμOPsの供給が追いつかなくなる4issueか、
よりリッチなオペレーションも安定して供給のできる3issueか
どっちが性能が出しやすいかだな。

>>546
その意見が正しいのならK8は何故そうなっていない?
K8はAMD64の元祖ですぜw
これまでは出来なかったけど、次は出来るってか?

それはPentium Mで64bit対応しなかった理由を聞くようなものものだ。
池沼きわまれり。

プロセスルールの縮小やステッピングの改良に伴ってK8は進化している。
L/S帯域の倍増も、SSE3採用もデュアルコア化も、HTの1600MHz化。
130nmと90nmの間にどれだけの改良が行われたと思う？
65nmではそういった拡張が出来ず公式発表のスペックを満たせない理由が
あるというなら、教えてもらいたいものだが。

AMDはついこの間まで、K8は完璧で拡張するところなどないとほざいていたのを忘れたか?

>>548
それを達成するのに3年。
上がわずかだが徐々に性能をあげようとも、Athlon64 3000+など、2年近く値段が変わらなかった。
AM2が出るまではその3000+よりも性能の劣っていたSempronも、Athlonにならい性能そのまま値段そのまま。

K8が来年、再来年と改良はされていくだろう。
だがそれで対抗できるのか？

K8Lで拡張しているのはユニットのデータ幅であって
K8パイプラインの構成そのものでは無いってのはわかってるよな？

>>550
それを言うならIntelは2年近くにわたってそれを下回る性能しか出せなかっただろｗ
競争が無い市場は停滞するからな。
ようやくIntelが動き出した「消費電力当たり性能」ならかなり向上してるな。
Pentium 4はキャッシュ増量くらいしかできなかったし、それに伴い消費電力も増加した。
ようやく下がったのは65nmになってから。

IntelはHyperTransport対抗のバスアーキテクチャいつ出せるの？
Opteron対抗に対抗できない限り、メニーコア戦略云々も
決して見通しは明るくないな。

Opteronに対抗できない限り、

Opteronは4ソケット以上で持て囃されてればいい。
サーバー全市場の10%にも満たない市場で頑張ってくれ。
2ソケットまでならHTもメモコンも魅力は殆どなくなるからな。

>K8LがK8の拡張にすぎないなら、CMAはCPUIDが示すとおりPentium Proの拡張の拡張ですが。
拡張だろうがなんだろうが、性能で勝てなきゃまさに負け犬のなんとやら。
K8Lと対峙するべきCPUがNehalemになってないことを祈りたいよ、本気で。
いや、そうなった方がいい場合も考慮しておくか♪　>Nehalem失敗説www

NetBurstも随分中身が変わってるし、Core省略も換えないとは言い切れないし、
やはり現物が出てこないものをどうこう言うのは火傷の元ですよ、実際。

4ソケットは知らんが8ソケット以上になると相手はItaniumですぜ。
Xeonと比しても尚薄紙の如きRAS機能で8ソケット以上のハイエンド市場を狙うのはちょっと無謀では。
付け加えると、IPFと競合するってことはPPCやSPARCとも競合するわけで。

Opteronがこれから売れる市場は、4ソケット以上での自作か、安売りサーバー市場だけのような・・
あ、そうそう大学関係やデモ用スーパーコンピュータのCPU需要がある。
そんなところだろ。
一杯売って沢山儲けてください。

0.35μm, 180nm, 90nmときてこのペースなら次の停滞期は45nmかな。
もとい、どっちが圧倒的優位な状況がいいとか馬鹿げたことは考えない。
競争原理が働かない市場は停滞するだけだって話。
K8LがコケてCore2が高値安定したほうがいいって思う人はいるみたいですが。

K8Lは転けた方が俺は嬉しいな。
Conroeに届かず、半額セールを期待する。
セカンドPCに最適だと思うね。

中途半端に同性能だと、どちらも価格は下がらないし、K8Lが優秀だったとしても45nmに直ぐ移行するIntelは
そう簡単に値を下げないからろくなことにはならんよ。

>>556
Itaniumが死んでいる件について

>>556
Itaniumも4socketが標準だぞ。
Xeonと同じFSB使ってるからな。
大規模サーバは4wayをセットにしてセット間をチップセットで繋いでる。

あとSunのX4600はIAサーバにしちゃなかなか堅牢だそうだ。
メインフレーム市場を侵食できると面白いけど。

>>560
IPFは3世代先までは開発が決定している件
>>561
ttp://www.geocities.jp/andosprocinfo/wadai06/20060715.htm
>X4600はメインフレームほどの堅牢性はありません

団子の人もINTEL派だ認識してるが、誰かさんとは違って
ハードだけでもの考えてないだけだと思うんだが。
ソフトあってのハードだしソフト屋視点から見ると、今現在のC2Dの弱点て結構ある。
特にサーバ市場で考えるとね。

そういや Opteron 32CPU だったかの Horus はどうなったん?

>>557
x86しか使えない職員、学生をかかえる大学くらいだろ、Opteron買い込むのは
Itaniumはさらにドンマイ

そうでもないようなふいんきなんですよね

例えばXenでHVM使おうと思った時、現状のVTだと使い物にならない。
AMDのSVTと違って、メモリ制御やI/O制御エミュレートしてくれないから。

仮想化技術はレンタル鯖なんかにも使われてくるし、
企業ベースでもロードバランシングと仮想化技術を組み合わせて
適切なリソース配置することでコストを抑えられる。

そういう意味で現状のCMAはサーバ市場では非常に危うい。
まあK8Lが再来年に伸びるなら、それまでに手を打つ期間はあると思うが。

>>546
　　-----------------------------
　　SSEのユニット幅倍増による演算スループット向上に合わせ、フェッチ帯域を拡大するのは妥当。
　　-----------------------------
SIMD (Single Instruction Multiple Data)わ，文字通り命令あたりのデータ処理量を上げる手法す。
なぜSSEの強化が命令フェッチに直結する。。。なんてトンデモ説が妥当なんすか(笑)

>>567
K8Lにおいて、予想される1clkあたりのピークスループットは、
一般的な整数演算は3命令、整数SIMDは2命令、
80bitFPUの演算は2命令、FPのSIMDは2命令。
つまり、普通の命令とSIMD命令でスループットはあまり変わらない。
そして、命令長もそんなには違わないが、やはりSIMDの方が長い。

> 文字通り命令あたりのデータ処理量を上げる手法す。
SSE強化で、命令のバイト数あたりの処理時間は短くなっだのだ。
だから命令フェッチ帯域が重要になる。

資料

命令長(REXと即値は含まない)
x87: 2 Byte
SIMD-SP: 3 Byte
SIMD-DP: 4 Byte

アドレッシングによる命令長の増加
[reg] +0 Byte
[reg +disp8] +1 Byte
[reg +reg*n] +1 Byte
[reg +reg*n +disp8] +2 Byte
[reg +disp32] +4 Byte
[reg +reg*n +disp32] +5 Byte
(n=1,2,4,8)

>>557
そう言えば、東京工大のスパコンってOpteron何個積んでるんだっけ？

Itaniumなんて誰買うの？

http://enterprise.watch.impress.co.jp/cda/topic/2005/12/16/6853.html
「Itaniumベースのシステムの売り上げは、サンやIBMを上回っているのです。
特に日本市場はメインフレームからのリプレースやRISCからのマイグレーション
でリードしています。Itaniumベースのシステムの売り上げは、SPARCベースの
システムの1.6倍に、POWERベースのシステムの1.17倍という数字が出ています。」

http://enterprise.watch.impress.co.jp/cda/topic/2006/02/07/7170.html
「Itaniumはエンタープライズおよび科学技術分野での導入を中心に確実にシェアを
伸ばしている」「近年はRISCからの移行が加速している。とりわけ日本ではSunの
SPARCシステムからの移行が160％、IBMのPOWERアーキテクチャのシステム
からの移行が117％と、世界におけるRISCからの移行トレンドを牽引している」

http://enterprise.watch.impress.co.jp/cda/foreign/2006/02/21/7251.html
IDCによると、Itaniumサーバーの認知度は向上しており、購入意思を示す企業が
増えているという。また、利用中の企業の顧客満足度も高く、概して好意的な反応
だったという。 このほか、HPのPA-RISCサーバー顧客の3分の2がItaniumサーバー
への移行を検討していることも分かった。適用分野としては、ERPやCRMなどの
ミッションクリティカル分野での採用を検討するところが多いという。

http://enterprise.watch.impress.co.jp/cda/static/image/2006/04/07/intel654.jpg
「IDCによるとItaniumベース・サーバ−の出荷金額は2004年の14億ドルに対して
2009年には66億ドルまで成長すると予測している。また、日本においても出荷が
伸びており、2005年下期においてはSPARCを上回る出荷金額だった」

>>572
にわかに信じ難い。

NECと日立が力入れてるからか、日本”だけ”Itaniumのシステムが売れている

AMDは2本の128bitロードユニットを駆使して高速化しようとしてるんだから
それを有効に使うには16バイトじゃフェッチ帯域が不足する。

同様にCore2も上り下り計256kの帯域を生かしにくいですわな。
MMXだと命令長は基本3バイトだっけ。

へー、K8LのL1データキャッシュってスゲー速いんだ。
知らなかったよ。

まだ128bit/clockですよ。K8L待ちですな。
まぁ、実効で最速はNetBurstでしょうな。

>573
記事の日付をみると微妙に沈没前夜…

Itaniumって都市伝説かと思ってた。

Itaniumなど存在しない

Itaniumの中の人など存在しない

　　ある　　　　　　　　　　なし
アルミニウム　　　　イタニウム
あるある大百科　　トリビアの泉
あるひ〜森の中　　グリーングリーン

後藤弘茂のWeekly海外ニュース
コプロセッサへの分散が進むAMDの次世代CPU
http://pc.watch.impress.co.jp/docs/2006/0721/kaigai289.htm

●AMDのCPU開発と密接に絡むコプロセッサ戦略
●各社で異なるサブプロセッサの統合の仕方
●他社のコプロセッサもAMD CPUに統合する
●CPUに統合するコプロセッサは市場が決める
●不鮮明なAMDの汎用プロセッサコアの今後の発展
●プロセッサコアの改革はパーツ単位で行なってゆく
●汎用プロセッサコア集約からコプロセッサ分散へと変わる戦略

K10無しで当分はK8Lのままって事か
6年後にはK11の足音が聞こえてくるだろうか

ここは静かですね・・・

恐らくKxxって表記は無くなるんではないかなぁと。
明確なコアの世代交代は今後は無いと思われるし。

既存のソフトが走る性能を落とさないためのK8コアには、ほとんど手を入れないってことかね

[PATCH] Add alignment to amd family 10 instruction tests
ttp://sourceware.org/ml/binutils/2006-07/msg00261.html
フェッチは32 Byteだがアライメントは16 Byteでいいようだ

ところでAMD Family 10 = K10 = K8L なのだろうか

CPUの機能ブロックがモジュラー化されるから
明確にKxx世代って言うのは難しくなるかなぁと思った。

Compute coreが変われば世代交代って言えるかな？

>>588
ま、たしかにコアは同じか少しの改良のままでも、あとはブランド次第だね
「Athlon64」ブランドに何かを付けるとか
「Athlon」ブランドにするか
それとも別のブランドにするのか。

ただ、GeForceやRadeonみたいに、前世代のソフトを使うと速度が低下するとか起きたら困るな

そろそろAthlon 65出せよ

むしろAthlon'07

Athlon XPでおｋ

Athlon Vis太

>>593
それ、日本語でアセンブラ書けそうだな

Athlon128 だろ。

プレフィックスを増やして、汎用レジスタを４倍の６４個くらいにすれば、
まだまだ性能ウプが出来そうだし。

性能向上をクロックやモデルナンバーで表現していたのは消費者としては分りやすかったけど、
コプロセッサの性能をそういう分りやすい形で表現するのはかなり難しいね。
どうするんだろう。

>>590
来年まで待てよw

情報待ちだお

次のアムドは
Athlon Conroe

2007年Q1 AMDやっと65nm Intelは4コアCPU発売
2007年末 AMDやっと4コアCPU発売 Intelは45nmプロセスへ
2008年 AMDやっと新CPU K8L発売
2009年 Intel 8コアCPU発売 32nmプロセスへ

>>600

そんなのイヤー

ATIと合併しちゃったけど、これって技術的なものにどのくらい影響するかな。

結局のところ，AMDが思いつくことができた「売れる」コプロってのわGPUだけだった。。。と(笑)
http://pc.watch.impress.co.jp/docs/2006/0725/amdati.htm
　　------------------------------
　　【Q】 リリースの中で述べられていたCPUとGPUの統合というのは、ダイレベルでの統合を
　　　　意味するのか
　　【A】 そうだ。我々は1つのダイでCPUとGPUを統合することを計画している。すべての市場で
　　　　こういったものが今すぐに求められているわけではないが、ニーズはある。
　　------------------------------

その場合、コプロと言うよりは
組み込み向けの統合プロセッサでしょ（1チップ）

コプロは別の路線で、これからの計画では？

これはMACｵﾀ先生が朝も早くから盛大に早漏してらっしゃいますね。

それか、メーカー製の大半は内蔵ＶＧＡだけど
ＡＭＤの場合ＧＰＵアクセスがＣＰＵ経由してメモリアクセスになるからボトルネックになる
CPU+GPUのやつにすれば直接アクセスできるようになるから解決ということかな？？？

そうだろうね。
ハイエンド製品には大容量&広帯域のメモリが必要だし、
CPUにオンダイなGPUじゃちょっと性能不足だろうね。

オンダイのGPUも使用しつつ、接続はPCI-Expressなり何なり、
外部のハイエンドなGPUをサポートする、という形なら、
オンダイなGPU分のアクセラレートも望める、という形が理想的な予感。

つか、HTXでGPU接続の目がでてきたっすな。

今のハイエンドGPUだとメモリ帯域は40GB/s程度でしょ。
一方K8はDDR2-800使っても12.8GB/s。
HT3.0でも20.8GB/sだし。
普通にGPUを統合するにしてもハイエンドは無理だね。
コプロ化して演算をさせようと思っても帯域の問題が出てくるな。
まあ演算させる内容にもよるだろうけどさ。

今すぐじゃなければ出来るよ。
シリコン貫通電極が２００８年位に実用化される。
その他に無線方式もあるし。
無線はＴbit/s既に試作してる。
目標はＰbit/sだそうだからな。

>>608
一番早そうなのは、CPUと同じソケット化したGPUエンジンと、DVIインターフェース
を載せたDVIトンネルチップだろうな。

これならプラットフォームは一つで済むし、GPUに必要な性能＆メモリ量を差し替え
だけで実現出来る。

久しぶりのMACオタなのに
一レスで終わりか

HTXの方が早いだろ。
ソケット化は二年はかかる。

結局のところ，MACオタが思いつくことができた「ケチ」のつけ所ってのわ１ﾚｽだけだった。。。と(笑)

>>611
そういやDVIトンネルで、どの程度の帯域を喰うのか考察してみた。

1920x1440(24BPP)だと8MB必要だから、これを85Hzのリフレッシュレート
に間に合う様に転送するなら、705MB/S　か。HyperTransportの帯域なら
全然問題ないなあ。

なまじUMAみたいにワークメモリをメインメモリに取らないから、その分
軽くなる訳だし。

ノート用CPUには、DualCoreなんかよりもコプロGPUをオンダイで組み込ん
だモノを提供する方が良い鴨ね。

age

http://pc.watch.impress.co.jp/docs/2006/0725/amdati.htm
| 【Q】 ATIは今回の件についてすでにIntelに話はしたのか。
| 【A】 いや、していない。

いいのか? それで。

突っ込むところはそこじゃないだろ?

> 【A】 我々はIntelと違い、インターフェイス規格をオープンにしている。例えば、IntelはチップセットもネットワークコントローラもIntel製であることを要求する。これにより、
> 他社のコンポーネントを排除している。我々はこういったことはしない。我々はインターフェイスをオープンにすることで、各社にAMDエコシステムへの参加を呼びかける。

これ身勝手な論理。
インターフェイスの中心にAMDがあることを示唆するものであり、決してオープンとは言わない。
ご都合主義の物言いはもうやめて、Intelを取るかAMDを取るか二社択一の選択を迫るべきだ。
敵対するのなら徹底的にすればよいのであって、都合の良いところだけIntelを利用しようと思わぬことだ。
インターフェースも何もかもINTELとAMDで共有化は全くないようにすればはっきりする。

「AMDエコシステム」の中心にAMDがいるのはオープンじゃないというのは
難癖にしても酷すぎるな

>>618
nForce for intelはintelバスとHyperTransportの両方使ってるが？
AMDの言うオープンってのは金を取るか取らないかの違いだろ。

まあ、二社択一を絶対条件にするなら、サードパーティが全社intelから離反するのは
明白だな。
ただでさえ、intelの推進するプラットフォーム構想は極論すれば「intel製品以外使うな。」という
独占的構想だからな。

> まあ、二社択一を絶対条件にするなら、サードパーティが全社intelから離反するのは明白だな。
それはありえないな。
どちらに付くかは、各社それぞれの都合で決まる、お前の妄想と一致することはないな。

intelとチップセットメーカーはモロに競合するが、AMDとは直接競合はしないからな。
チップセットメーカー同士の戦いなら、ファブレスでも勝算はあるが・・・

バスライセンス料払ってまで製造能力では全く勝ち目のない相手に挑むほど間抜けな奴がいるとは思えんがな。

cpu+gpuっていうのはGPUが〜GHzで動作するということなのですか？

No

CPU、GPUがお互い協力して、どっちかが忙しいときには遊んでないで助けるっていう形になれば無駄がないのにね
あとメモリも

AMDとATIのプロセッサは1つに融合する
http://pc.watch.impress.co.jp/docs/2006/0725/kaigai290.htm

>>623
今のCPUコアだって基本クロックのｎ倍速だから、GPUだけｍ倍速って手を
使ってくるだろう。

VIA C3もネヘミア以前はFPUだけCPUコアの1/2で動作してたし、異なる倍速
のユニットを同じダイに載せるのは、何ら問題無い筈だし。

1チップに収めるのはいいとして、どういう用途を睨んでいるんだろうね。

>>628
オンチップVideoを使っていた様な用途だろうね。

ノートＰＣや家庭向けメーカー製ＰＣあたり。

オプテロンだと64bitFP対応した専用コアを用意して、殆どが科学計算用途で
一部を表示装置に回す算段かな？FPUユニットの発展版として入れ替えるって
ところ。

もしかしたらノートPCやメーカー製PC向けでも、FPUユニットとの入れ替えを
してくるかもしれん。どうせ64bitFPなんて一般用途では殆ど使ってないのだ
から、32bitｘ２で代用して少々遅くなっても32bitFPが激速なら文句は出ん
だろうし。

それがいやなユーザーにはオプテロンを買わせれば済む。

＞64bitFP

そんなの昔からx86にあるじゃん。
Core2で64bitFP×4/32bitFP×8だぜ？
いつの時代の人間だよ。

統合する汎用シェーダーで演算可能なものは任せる、というスタンスなんでしょう。
特にグラフィック関係に限らず。

>>630
だから今ダイに載ってるFPUを発展解消する形でGPUと入れ替えちゃえば、ダイサイズや
開発リソースの節約が図れるって話をしたつもりなのだが。

因みに次期C7（Isaiah）は、FPU機能を新SSEユニットに取り込んでしまうらしいが。

>>632
＞因みに次期C7（Isaiah）は、FPU機能を新SSEユニットに取り込んでしまうらしいが。

Intelが何年も前からとっくにやってることじゃん。
現行製品で64bitのFPUで128ビットのSIMD浮動小数演算みたいなことやってるAMDからすれば
目新しいことかも知れんが。

>>623
今のGPUクロックがなかなか上がらないのはASICプロセスだから


まさかわざわざカスタムとASICを共存させるなんてしないだろうから
いずれ CPU+GPU オンダイまでいけば同一プロセスだろうけど

IsaiahのSSEは128bitに成ります。
FPUはSSEと兼用。
単精度演算なら同時に4つ、倍精度演算なら2つを実施可能。
加乗算の高速化や除算/平方根を非同期で行えるようにする。

何時出るんだろう・・・

ちなみに、IsaiahでようやくOut-of-OrderとSuperScalarが実装される。
（現行のIntel,AMDのアーキテクチャに近づく。）

ttp://pc.watch.impress.co.jp/docs/2006/0609/comp09.htm

この辺読むとATiのGPUで物理演算できるみたいだから、CPU+GPUが実現されれば、
PhysXの死亡は確定かな。

それにしても
ttp://pc.watch.impress.co.jp/docs/2006/0606/comp02.htm
つい６月にIntelの基調講演内でデモった技術が７月にはAMDの物というのは何ともはや。

>>636
PhysXは既にMSが公式にサポートしてる。

AMD+ATIはまだこれから。どっちかというと
AEGIAにSDKを出してもらうかも知れない立場。Cellもそうだし。

>>633
AMDのSSEユニットは3Dnow!も請け負っていたから、FPUまでは手が回らなかっ
たのジャマイカ。

でもそのお陰で専用FPUが残ったからなのか、確か現行品での浮動小数点演算
能力は、IntelよりもAMDの方が高かったと思うが。

まあIntelがSSEメインでFPU性能を重視してなかったせいかもしれんが、AMD
ならFPU性能での優位を保ちたいだろうから、上手くGPUにFPU機能を作りこむ
のを期待したい。

NetBurstのFPUはクロックの半速動作の128bit SIMDユニットで処理してて
x87やSSE*スカラ演算は半分しか使えない仕様だった。

いっぽうAMDは等速で64bit幅。
x87を使う古いコードだけは、浮動小数ユニットの実クロックぶんだけ
AMDのほうが速かったが、128ビットフルに使うSIMDでは、AMDは2分割して
通すことになるので、Intelが圧倒的に優位。

Coreでは128ビット・等速になってるので、お得意だったx87やSSE*の
スカラ演算性能すら同クロックで同等、SIMDならダブルスコアだ。
x64ではx87よりSSE*を積極活用することになるので、64ビット構成では
圧倒的に不利だな。
K8LではCore2を追従することは確定のようだが。

>>638
んで、どういうパイプライン構成にしたいのか図示してみろよ。
ユニットだけ増やしても命令供給が追いつかなきゃゴミ同然だぜ。

PCの世界でオンチップメモリは有りえるのかね
HPCの人たちはプロセスが進んだらスクラッチパッドもしくはオンチップメモリを
どんどん増やせって言ってるけど

追加 1000個とか同時につかうのを前提らしいけど

>>639
> AMDは2分割して 通すことになるので、Intelが圧倒的に優位。
等速64bitと半速128bitなら互角じゃん。
ついでに、ネトバは64bit半速*2だ。
むしろレイテンシなどでAMD有利だが、
クロックが上だからネトバの勝ち。

つまりK8Lでは再びぶっちぎりというわけですね？

ここで勝利宣言するか

２００８年に出てきてから、ごめんなさいするのねw

>>642
> むしろレイテンシなどでAMD有利だが、

間違い。実際は分割することで依存関係チェインが出来て効率悪化している。
リビジョンが上がって改善されてきたが、根本的な解決手段は128ビット化（K8L）なわけだ。

クロック数ぶんNetBurst優位というのは正しい。
クロックを伸ばしていければx87やSSEスカラ浮動小数も同等以上に
持っていくつもりだったんだろう。

>>646
分割したら依存関係は緩くなるよ。
（これはネトバも同じこと）
実際、128bit化したCore2では
シャッフルなどが遅くなっている。
64bitの方か小回りが効いていいのだ。
128bit化はパワーを増強するだけ。

まあ、内部命令数が増えるから
デコード・スケジュール・リタイヤなどの
負荷は高くなるけどね。

>>639
という事は、未だにSSEによる浮動小数点演算は活用されてないって事でファ？

いくらＯＳがx64になっても、アプリの方がx64になるのは少し後だし、まして
や今まで動作してた浮動小数点演算処理を、SSEで書き直すのはそのコストを
吸収出来るくらいの性能差が必要だが、そこまでの差は無さそうな気がするが。

>>648 補足

Itanium の失速状態を見れば、ソースを書き換えて迄対応するのを、世の中の
ユーザーがどれだけ嫌がってるかの証左だと思ってる事が、先の意見の前提。

シンプルなコード書いて最適化はコンパイラに任せろ

>>639
昔から偶に見かけるが、NetBurstのFPUはクロックの半速動作って何？

そのままの意味。

3.6GHz動作ならSIMDユニットは1.8GHz動作なわけ。
ALUが熱すぎるからSIMDだけでも半速で動かさないとつらい訳よ。

P4のSIMDは半速だが、FPUもそう？
FPUの加算はスループット1だよ。

ALUは倍速なのは知ってたが、FPUは半速だったのか。
へぇ。

またこの話題か
プレスコットのFP演算のレイテンシが奇数だから等速だろ

上と下が半分ずつ交互に動けば１になるだろう
FPmulは下半分だけしか入らないみたいだが。

>>622
intel向けのチップセットは儲かるよ
数が違うよね

>>650
それで済むならx64はイランわな。IA64のItaniumが64bit市場を制覇してた筈。

OSがCPUに合わせて最適化すればいい。

人間がコンピュータに合わせて最適化すればいい。

>>659
つ[http://www.gentoo.org/]

>>657
儲かんねーよ。
Centrinoといい、今のプラットフォーム構想といい、他社締め出しの意図丸出しに加えて
チップセットの増産体制が本格化したら、intelより圧倒的に安くない限り誰も使わん。
ディスカウント合戦になってintelに勝てるはずもないしな。

何かの間違いでたまたま売れたとしても、売り上げに比例してバスライセンス料をintelに
持ってかれるだけでintelが儲かるだけの話だ。

AMDの方はバスライセンス料も取らんし、チップセット作ってないからCPUが増産されれば
各社のチップセットも必然的に需要が増えるからな。

優遇税制で企業誘致してる土地と、やくざにみかじめ料取られる土地で、どっちが商売しやすいか
なんて考えるまでもない。

でも数(マーケット規模)が違う…

優遇税制で企業誘致してる富山の土地
やくざにみかじめ料取られる東京の土地

座布団一枚！

AMD向けチップセットの純利益と、
バスライセンス料を引いたintel向けチップセットの純利益は
一体どちらが多いのですかね?

中の人しかわからないんジャマイカ

でもIntelのIGPが悲惨だったからノートで結構出てたっしょ　＞RadeonExpress
しかもどちらかと言うとミドルレンジ辺りで。965Gが伝統通り悲惨だったらメーカーは板挟みだなｗ

ノート向けのchipsetは今年いっぱいくらいは945のまま
だから、intelはVistaPremiumを945でも動くってことにしくれ、と駄々をこねざるをえなかった

>>663
数と言っても、intel系で10%程度のシェアとAMD系で50%のシェアなら大差ない。

965からは90nmだそうだが、こうなるといよいよサードパーティじゃ勝負にならん。
CPUでは既に前世代のプロセスだが、チップセットで90nmなんて他社には無理。

intelバスは使い回し効かんが、HyperTransportはCPU以外との接続でも自由に使えるし、
メモリコントローラはCPU統合だから、ダイサイズ抑えられて検証の手間も減るし、
実績さえ積めばサーバー向けにも食い込める可能性があるしな。

二社択一なんてアホなこと言い出すとも思えんから、一応、保険程度にintel向けも
作るだろうが、基本はAMD向け中心になるだろうな。＞サードパーティ

IntelはNorthが90nmでSouthが130nm。
VIAも次の9xx世代は90nmか80nmに移るらしい。
SiSは今年110nmで、来年80nmとか。
TSMCかUMCがあるからプロセス自体は提供されてるしな。
問題はどっちも予定が当てにならんことだが。

Geforce6100/6150が既に90nmじゃなかった？　まぁintel向けじゃないけどね。
あとサウスは電圧の関係で微細化は厳しい悪寒。チップセットにPCI MAC、後付で PCI PHY とかしないと

>>672
ノースだってAGPで3.3Vや1.5Vを、メモリもDDRで2.5V、DDR2で1.8Vを使ってるが。

まあPCIはレガシーになっていくから、確かに昔のISAみたいにアダプタICは必要
かもしれんが、それはノースやGPUがVideo出力するのと同じと考えれば済むかも。

>>673
PCI-Express(0.8V)やDDR2(1.5〜1.8V)、SATA(0.5V)と比べると IDEとPCI の5Vは別次元っしょ。
それにAGPの時はまだ130nmとか180nmだったんだし。

chipsetが大電流をその電圧で供給するわけじゃなし。
intelのICH8もPATAはなくしたが、PCIは残ってるな。
いよいよでも信号はレベルコンバータででもすむだろうし、PCIe接続とかで外に出されてもそんな問題でもないだろう。

90nmだと3.3Vを作るのはかなり難しいってばっちゃが言ってた。

ttp://www.dailytech.com/article.aspx?newsid=3595
何に使うかわからんけどCellAccelerator
Torrenzaにも使えんかな

>>670
それならAMD向けは価格下げて欲しいよ
チップセットとマザボは価格が直結するとは思わないけど。

もしかしてIntel向けで10%シェア取る方が
AMD向けで50%シェア取るより簡単なんじゃない

サードパーティーはみんなその考えでIntel向けに参入してるでしょ。
でも結局はIntelが強すぎる、と。

インテルが強すぎるというか、バスライセンスの問題でしょ。
インテル自身で作るにはライセンス料いらないから安くできたりする
しかし他社が作ろうとすると、そのコストがかかってしまい儲からない。

ATiがいいチプセト作ってくれればいいが、過去の例から全然だめだし
nVIDIAはダメダメ、かつ今後は協力してくれるかすらわからない。

INTEL向けで成功するのはエントリー向けの
安いチップセットのみ
利益の多いメインストリーム〜ハイエンドの領域は
ほぼ100%といってもいいほどINTELチップで
埋め尽くされてるしな(´・ω・｀)

intelの場合、他社と同じ130nmや90nmでも既に1・2世代前のプロセスだからな・・・
償却の進行度が全然違うからコスト競争になったらまず勝てん。

しかも半分以上のFabは300mmウェハだった気が…

そう言えば、intelはRambusのバスライセンスは解決してんだっけ？

>>681
つ[鯖ﾜｸｽ]

http://journal.mycom.co.jp/special/2006/conroe/

Conroeベンチなのだが、前半のそれぞれのCPUの基本的性能分析のところを見ると
K8の素性が良いとの評価だ
ダンゴがK8の次のコアでL1の帯域増えるって言っていたが、その通りなら、
32bitで同等くらい、64bitでは大幅にぶち抜くってのはあり得そうだな

大幅に、とはいかないかもしれないが逆転はできるだろうね

ttp://pc.watch.impress.co.jp/docs/2006/0703/kaigai286.htm
を見ると分かるがHoundでは128bit×2
デコード、SSE性能も追いつくならあとはキャッシュ次第かねえ。
64byte維持でレイテンシが増えたりしなきゃ行けるかな。

そこにある図を見て、L1はデータキャッシュだけ帯域増えるのかと思っていたよ
命令キャッシュも当然帯域増えると思うべきなのかな

K8のデコード部の素性が良いのは単にプレデコードキャッシュの恩恵でしかない。
K8は排他キャッシュ構造なのでL1命令キャッシュをプレデコードキャッシュにするのは容易い特徴を有している。
しかし良い面ばかりでもないことを意識しておく必要もある。

>>685
性能劣化がなく帯域を倍増することが可能かは非常にあやしい。
実際に出来てみないと評価できないな。

>>684
ServerWorksは既にIntel向けから撤退して久しい。DDR2対応チップすらない。

もしHoundで逆転してもすぐ後にNehalemの恐怖が…
逆転しない場合がそれ以上の恐怖なのがﾂﾗｽorz

2007年にK8Lで2008年にもNewCoreあるよ。

2008年は”core update”だった希ガス。
2008年中盤に45nmに移行予定として、どこで”core update”するんだろう？
あと、”Direct Conｎect Architecture 2.0”で、もう一度Intelを突き放すと
どこかのｲﾝﾀﾋﾞｭｰで言っていたけど、DCA2.0ってｺﾌﾟﾛ+北橋をCPUに統合？

2008年のNewCoreはモバイルじゃね。
Hound系が降りてくると思う。

2008年のモバイルは

Intel Core3 VS AMD モバイルコア(K8)
というわけだな

FTC、米Rambusに独禁法違反の裁定
ttp://enterprise.watch.impress.co.jp/cda/foreign/2006/08/03/8386.html

やっと鉄槌が下されたか。これで少しはCPUやPCの性能ウプがし易くなるな。

Core2ってSSEのユニットはいっぱいあるんだけど、ある程度のところまでいくと
命令フェッチ帯域が足引っ張って、性能頭打ちなのよね。
Core2のSIMD整数に比べて浮動小数が比較的伸びてないのは、浮動小数のほうがレイテンシが長く
ロード・ストアの依存度が高いからだと分析する。
で、アドレッシングつき命令で８バイトくらい使っちゃうから今度は帯域がネックになる。
もちろん既存アーキテクチャでは平均的に圧倒的な性能を発揮するんだけど、
一部の命令のスループットはNetBurstを下回るわけで、やっぱり改善して欲しいよね。

トレースキャッシュっていうのも解決手段のひとつではあるとは思うんだけど、今度は汎用命令
（相当のμOPs）の格納効率が落ちる。

フェッチが32byte/clockあればSSEもたいがいの64bit命令も、３命令コンスタントに取り込める。
SSE厨としては、初の128bit SIMDユニット搭載のK8Lに期待するところはある。


現行アーキテクチャで32byteのフェッチ帯域といえばItanium2がそうでしょう。
まぁ固定長LIWだけど。

>>694-695
妄想で語るなハゲ。
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/PhilHesterAMDAnalystDay.pdf

>>696
今まで誰がもうけてきたんだろうねぇ。（ｗ

>>697
Core2に限らず、浮動小数演算ってレイテンシが長く成るでしょ
あと32byteのフェッチ帯域って、PPCとかSPARCとかのRISCチップに無かったっけ？

RMMAの測定結果がおもしろかったので、754pinのAthlon3400+でも同じか確かめてみたんだけど、
大原記事にある命令以外でも大抵同じ傾向がでたんだけど、
2byte命令のMOV,ADD,ORだとほぼ2byte/cycle、LEAだと1byte/cycleくらいしかでなかった
これは命令の性質上こんなもんなの？

>>700
いずれも固定長4byteですな。PPC G5で4issueだから16byte程度でしょう。

VLIW系は
Itanium 2 ・・・16byte×2（3*2issue相当)
Efficeon ・・・32byte×1(8issue相当)

http://www.geocities.jp/andosprocinfo/wadai06/20060805.htm

＞各種ベンチマークでCore 2 DuoがOpteronに勝っている主因は，キャッシュを含めたデータアクセス性能が高い点

これが当たりなら、今後のAMDの方向性は大正解ということになるな。

？

Z-RAMで鬼の様なL3積んでくれないかな。コア4つでL1-64k+64k L2-512k L3-128Mとか。

せいぜい32MBくらいが限界だと思う

チートCPUは焜炉でした。。。。
http://pc7.2ch.net/test/read.cgi/jisaku/1154290759/

K8は非常に優等生で、何をやってもそつなくこなす印象で、
対してCoreは特定の処理に特化してチューニングをしている
雰囲気が見受けられる。

http://journal.mycom.co.jp/special/2006/conroe/006.html

リンク先見たがコンローが特別負けているようには見えないな。
K8がマイナーチェンジすればまだまだ戦えることはわかった。

>>707
そんなこと言われてもなぁ、サクラエディタ64bitとメモリ帯域を除く殆どのベンチ結果で
ＣｏｎｒｏｅはAMDのCPUを圧倒してるしなぁ。

L1 Hitの範囲でK8とCoreは同等。
L1 Miss / L2 Hitの範囲ではCoreのLatencyの方が少ない。
L1 Miss / L2 Missの範囲に成ると、メモコン内蔵したK8の方がLatencyが少ない。
って事でしょ

L1も帯域が全く違う。(ConroeはK8の倍だ)
L1からの読み込み待ちでConroeはK8の二倍の性能。
キャッシュミスを前提に考えるようなソフトは元々から低速だ。

あーあ、言っちゃった…

だからメモリ帯域とか、分岐予測とか、そういう内部機構で対決させても意味ないよ。
結果だけが全て。

あと大原は凄い仕事したと思う、どこぞの天皇メモ報道並みに。
これでミスリードだろうとなんだろうと、k8はまだまだいける、という希望的観測をAMD信者に見出させ
Houndに繋がるまでの心の拠り所を作った。

流石は大原雄介だ！魔術師の二つ名は伊達じゃなかった！

K8Lの妄想

確かに、L1の帯域を倍に上げますと公表している。
しかも、デュアルアクセスも可能にすると公表している。
これだけを見せられると一般人や信者は凄いと思ってしまう。

しかし、これには大きな落とし穴がある可能性が高い。
それと引き替えに、レイテンシの悪化が想定されてしまうからだ、AMDはそのことには決して触れない。
しかし、よくよく考えてみればL1やL2の性能はそう簡単には上がらない。
性能が簡単に上げられるのならL1はもっと巨大で、もっと性能が良いものになっている。
それでなくてもAMDのL1はIntelの倍の容量があり、性能を高めるのは容易ではない。
大原はそんなこと承知の筈であり自身に都合の良いところだを都合良くまとめたに過ぎない。
しかし、uOPsはどのようになっているか不明であると言いながらだ。
結論として、何一つまともには聞こえてこない。

>>715
AMDのパターンを考えてみると、レイテンシは極力押さえつつ帯域アップを目指して
……製品化が遅れるとかな。

>>715の後半は壮大な詭弁だな。こういうのがいるからアンチ編む厨は馬鹿にされるんだよ。
K8のL1はAssosiativityを2Way（PenM/Coreは4Way)に落としてPenMの2倍の容量を得てるだけで
別に無理でもなんでもない。
ロード帯域は単に信号線を倍にすればいいだけ。
PenM→CoreでL1ロード帯域は倍増してるがレイテンシやAssosiativityは一切犠牲にしてない。
プロセス微細化が問題を解決してもなんら不思議はない。
レイテンシの増加とかアホさらせ。

Associativity

ごめんね慣れない英単語使って

まあ一般論としてはどれも間違ってないけど、L1でレイテンシ増は考え難い罠。
>しかし、uOPsはどのようになっているか不明
とりあえず>>715はさり気に良い事言ったNE。

>>71
Assosiativityを2Wayに落としても容量が増えるわけねぇよw

ちなみにWay数で大きくレイテンシが変化するのは16Wayを越えるような場合であり、2Way〜8Wayなら殆ど関係なし。
実容量が増えると、実装容積が増えることでレイテンシに影響する。
更に、信号線を増やせばと言っているがそんな単純なものじゃねぇよ。

探索の深度が減らせるので、Latency=3の範囲で実装できるメモリ容量は増えるよな。
4Wayと2Wayじゃえらい違いですぜ。

しかも、キャッシュラインをまたぐとペナルティが大きいから、「16バイトアドレス境界を跨がない」
という制約が加わってる。
帯域が増えるとロードレイテンシが増加する理由さっさと言えよ。説得力がまるでないぞ。


[雑音にはわからないかもしれない課題]
Pentium 4のL2のレイテンシが異常に大きかった理由を説明せよ
ヒント：キャッシュライン

>>722
Way対応計算は2Way〜8Wayなら殆どかわらねぇよ。
お前、頭おかしいの?

はいはい、だったらなぜCore 2 Duoは8Wayにしないのですか？

一度に読み書きする（キャッシュラインを跨がない）データ幅が増えるとレイテンシが増えるという
トンデモ理論の説明が出来ない以上、何を言っても説得力がありません。

>>724
ConroeのL1は命令・データ共に8Wayだが、
それがどうかしたのか?

たしかに8Wayだな。読んでなかった。
しかし、電子の移動度が上がらないと無理な改良ですわ。
2Wayと8Wayなら余計に探索のレイテンシの差がつく罠。

AMDが65nm化でロード・ストア帯域を増やすとレイテンシが増える
それは、自分が嫌いなAMDだからそうあって欲しいっていう無根拠な希望的観測じゃないのかな？

> 一度に読み書きする（キャッシュラインを跨がない）データ幅が増えるとレイテンシが増えるという
> トンデモ理論の説明が出来ない以上、何を言っても説得力がありません。
この馬鹿げた発言にはどう答えたらいいのだ?

キャッシュライン長を好きなだけ大きくすると、キャッシュラインは跨がないからレイテンシは増えないのでお得ですとでも言いたいのか?
L1のような超高速なキャッシュになるとライン長の大きさすら速度に影響することを理解してくれ。

どこをどう読み間違えればそうなる
キャッシュライン長を増やすなんて言ってないだろ。お前マジ池沼だわ。

32Byteの1キャッシュライン上のデータの読み書きをbyteずつをalignedな16byteずつにすると
どうしてレイテンシが増えるのかさっさと説明しろよオイ

ちなみにキャッシュラインサイズが増えるとL/Sのレイテンシが増えるのはL1じゃなくてL2だよ。
Northwoodは64byteキャッシュでレイテンシ2だった。
もうわかるだろ、>>722にもさっさと答えてくれ、雑音先生

8byteずつをalignedな16byteずつにすると

誰が雑音先生なのだ?
お前か?
帯域を増やすのもそう簡単なことじゃねぇよ。
65nmになってもそれはちっとも変わらねぇし、変えようとすれば搭載するトランジスタ性能をどれだけ高性能化出来るかなんだよ。
ちったぁ勉強してから発言しろな。

64byteキャッシュライン構成でL1-L2間の帯域がたとえば上り下り各8byteなら
L2から1キャッシュラインをロードするのに、32byteキャッシュラインのそれより、
4クロックは多めにかかる（単純計算で）

それがキャッシュラインサイズを大きくすることによるレイテンシの増加だよ。
もともと高クロックを狙った設計だから、1クロックあたりの移動度の問題もあるけどね。

ID:R0NF0tOiは雑音先生の主張と全く同じだしｗｗｗ

> もともと高クロックを狙った設計だから、1クロックあたりの移動度の問題もあるけどね。
これはNetBurstの話。

> もともと高クロックを狙った設計だから、1クロックあたりの移動度の問題もあるけどね。
やっとまともなことが言えたじゃねぇかw
てめぇは時間かかりすぎなんだよ、呆けがぁ。
結局のとこだが、回路をリッチにすることに新トランジスタの性能を使っちまうと、今度はクロックが上げれねぇ。
そんなこんなでAMDの発表は非常に煙たいんだよ。
出て見なけりゃ全く評価出来ない内容となっているってことさ。
今からそんなに期待するのはどうかと思うぞ。

> そんなこんなでAMDの発表は非常に煙たいんだよ。


「そんなこんな」と前の文章との繋がりが不明。
煙たいと思うのはてめぇの主観であって客観性がない罠。
IBMの65nm SOIは非常に優秀だという話を聞きますが。

団子いじるなよ、時間の無駄だぞ
ヲタとは基礎知識に差がありすぎるからいじりがいもねえし
都合が悪くなりゃあ「俺消費者だし」で逃げるぞｗ

>>734
IBMの名前さえ出せば納得してくれるとでも思っているのか?
相手はIntelですよ、全世界で最も優れた設備と研究機関とシリコン技術を有しているIntelな。
一度顔を洗って出直してこいよ、ぼうや。

>>735
そうかもな、だんだんムダだと言うことが分かってきたよ。

雑音がしょっちゅう使う言葉"トランジスタ性能"。
でもそれが具体的に何を指しているのかは不明。

まあ電流量でも見たかったらMyCOMのレポートでも見てこい、と。

>>736
話と関係ないけど、AMDのSOIはIBMのものなんだが

64bit→128bit化は単純にアクセス幅の問題だから増やしたからといってレイテンシには直接
影響しないはずだがな。
元々パラレルバスの有利な点はそこなんだし。

バス幅拡大で難易度が上がるのは等長配線だな。
ただそれもK8Lが65nmからってことだと、元のままの回路での光学シュリンクなら単純にバス配線長は
ほぼ2/3でレイテンシ面では余裕が出来るから、それで相殺されてレイテンシは維持できるだろ。

Prescottみたいにキャッシュ容量倍増だと、単純に配線長も倍になるからレイテンシは増えるがな。

レイテンシが増えることにしないと
AMDが失敗することにしないと
気が収まらないのです。

ただレイテンシって言いたいだけちゃうんかと。

感情ありきで、何を語らせてもIntelは素晴らしい、AMDは糞としか言えない。
まともに技術論を語らせるだけ無駄。

AMDのL1キャッシュにおける32Bキャッシュラインの2ウェイセットアソシエイティブで
64KB+64KBという構成は、初代K7（0.25μm）の時点で既に実現してきたもの。
(K6は32KB+32KB)
むしろその間に、IntelはPentium III→Pentium Mで容量2倍、Core 2で8ウェイ化。
K8のキャッシュ構成に無理があると言うなら、Intelのほうがだいぶ無理してることになる。

逆に言うと、L1キャッシュ自体の性能強化は行えると思うがな。
レイテンシを2にしたり容量を倍増するのは苦しいかもしれんが、4ウェイ化くらいは
やれるかもしれんわな。

遅れるのはあるだろうな。
そしてそうなったら、確実にＡＭＤオワタ＼(^o^)／

はやく光子を使うCPUを作って欲しい。
電子使うなら発熱に頭を悩ませることになるんだ。

はやく重力子を使うCPUを作って欲しい。
光子使うなら距離差に頭を悩ませることになるんだ。

重力子でも光速は超えないのでは？

量子コンピューターまだぁ？ｗｗｗ

空間を捻じ曲げて距離をなくすのでは？

ワームホール使ったほうが速くね〜？

>>736
そのインテルが90nmのリーク電流で大失敗したのは、記憶に新しい話だが。

あれが地球温暖化を悪化させた影響は、無視出来ないくらい大きいと思う。

そして今度はAMDの方がﾔｳﾞｧｲ立場に置かれてしまっているという現実…
orz

本当に残念だが、時代が変わってしまった。
K8Lで逆転したら、昔話で馬鹿にするなんてことしなくてもすむのかな。

それはそうと、例の対決、誰か見てきてくれよ。

つーかエロなんて本能なんだから規制するようなもんじゃねえだろ
幼稚園児にＡＶどんどん見せてやれ

排他キャッシュというのはメモリーからロードした時にＬ２を経由せずにＬ１に収め、
Ｌ１からパージされたらＬ２に収めるという動作になり、Ｌ１のパージ時の処理が
複雑な感じ。Ｌ２を共有にしようとしたら必然的に排他に出来ない感じだが？

んで、ノートとデスクトップでマイクロアーキの設計が分断されるわけか。

>>750
幼稚園児はちゃんとパパママのプロレスごっこをシッカリ見てるからオケ。

って、スレ違いカキコだな。

>>752
デスノートでマイコの身体が分断？

やっぱ将来的にはコアが増えるだけか？
シングルスレッドが格段に早くなる奴だしてほしいんすけど

スレッドを大量に吐くOSやアプリを希望してはどうか

>754
あと60年くらい待っててくれ

革命的に速いのを用意してやるから

キャッシュとメモリ性能を上げればよいという結論はスルーか？

でもItaniumやPPCはそこまで速くないし…
スレッドを大量に吐くOSやアプリを希望してはどうか

>>758
2001年のデュアルコアからやっとコアが増えた、クアッドコアPOWER5+はどうなん？

>>746
縮地法か

つーか、AMDｵﾜﾀとか言ってるﾔﾂって、AMDに潰れてほしいのか?
もしAMDが潰れてしまったら、競争がなくなって大変なことになるんじゃないのか?

C2DだってAMDに性能でﾘｰﾄﾞされてなかったら、出さなかっただろうし。

本当に潰れそうになったら IBM が拾ってくれないかな

AMDｵﾜﾀとか言ってるﾔﾂってｷﾁｶﾞｲとﾈﾀだろ？

AMDｵﾜﾀとか言ってるやつが大抵人生ｵﾜｯﾃﾙからなぁ＾＾；

>>764
intelの社員は勝ち組だけどね

リストラ部署の人はそうでもないようです。

社員の平均所得はAMDの方が上だった希ガス・・・

Intelのほうが工場とその作業員が多いからな
研究開発要員は会社が大きいからとはいえ、一定数で事足りる

逆にAMDは研究開発要員を会社規模の割には多く抱えなきゃIntelに対抗できんからな。

まさにAMDは少数精鋭のエリート集団

>>769
で、キミは高卒？中卒？

まあ、そう煽るな。

5分で反応するなんて凄いな

>>770
きもいなおまえ・・・

簡単なこと
FlashRAM混載してVLIW型CPUにしてしまえばいいんですよ。
クルーソー型の動的最適化掛かるやつを

煽る奴はバカ

VLIWはISAの問題なのに、なんでそれが出てくる。
確かに複雑なx86のデコーダの問題とはオサラバできるけど
それはもはやx86CPUとはいえない代物だ

あー
内部VLIWな。
インストラクション受入れはx86で
>>776

K8Lがテープアウトしたす。
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~111541,00.html
　　---------------------------
　　 In addition to launching its Next-Generation AMD Opteron processors, AMD also
　　announced the completion of the design, or tape-out, of its native Quad-Core AMD
　　Opteron processors.
　　---------------------------
ダイのレイアウト図だけで信者を騙し続けるという状況から脱却できたことわ，素直に喜ぶ
べきかと思うす。

>>778
それはIntelも同じでわ？

クロックと提灯ベンチで信者どころか一般ユーザーまで洗脳し続けるのよりはマシだろう。w
もっとも、そのおかげで自分の首を絞めてしまった部分もあるが。

K8Lってシングルコアでも普通に売られるのかな？
マルチコアに特化するように設計されてるからそれはない？

米ＡＭＤ、次世代ＭＰＵを07年発売
ttp://www.nikkei.co.jp/news/main/20060816AT2M1600G16082006.html

単純に現行のK8を光学シュリンクすると1コア50mm^2を切るのだけど、
メモリーコントローラの幅は縮小できないので、キャッシュを巨大化するなり
コアをもう一個並べるなりして100mm^2四方程度に収める必要があるとか。

それこそCore Duo形式でシングルコアAthlonはX2の片コア無効版として出した方が
合理的だろうね。

Sempronはチップセットとのワンチップ化とかやり出すと面白いかも。

>>779
AMDファンとしてわ、発売されていないK8Lがテープアウトされても話題にしてわいけないらしいす。

>>784
それはIntelも同じでわ？

気持悪いからバカ丸出しの文体をまねてアホの相手をするな

AMDのクアッドは、クロックどの辺りからリリースされる予定なの?

Socket F Opteronも悲惨な出だしのようすね。。。
4-socket/8-coreでのSPECint2000_rateの比較す。
　Xeon 7041/3GHz: 114(base)/114(peak)
　　　　http://www.spec.org/cpu/results/res2006q3/cpu2000-20060710-06446.html
　Opteron 8220SE/2.8GHz: 146(base)/166(base)
　　　　http://www.spec.org/cpu/results/res2006q3/cpu2000-20060721-06572.html
　Xeon 7140M(3.4GHz): 161(base)/162(peak)
　　　　http://www.spec.org/cpu/results/res2006q3/cpu2000-20060724-06780.html

アム虫の心の拠り所である＞2-socketでネットバーストXeonにすら追いつかれるとわ(笑)

Tulsa ktkr!!
明らかにIntelはスコアが同等になるようにL3を調整してきたなｗ
しかしbaseで160overってスゲーな…

Xeonでも性能が出せない訳じゃないってのはわかるが、あれは金かかるからな。
IBMのX-Seriesだと、チップの開発だけで3年と1億ドルも投入してるし。

> 明らかにIntelはスコアが同等になるようにL3を調整してきたなｗ

16MB on-chip L3 キャッシュの威力って奴ですかね。

> しかしbaseで160overってスゲーな…

base と peak がほとんど変わらないから、Intel C compiler が、
SPEC + Intel CPU の組合せ向けに、きちんとチューニングされてるって
ことじゃないのかな。

baseの意義は誰でも比較的容易にそのスコアが出せるって点にあるわけで

問題は、ユーザの使ってるアプリケーションで性能が出るかでしょ。
Intel コンパイラが、どんなアプリでも最適なコードを吐けるほど
賢ければ問題ないけど、SPEC のベンチマーク対象を認識して出す
コードを調整してるんだった意味なし。
base と peak で、ここまで差が出ないとすると、後者の可能性も
それなりにありうるのでは？ まあ、実際にどちらなのかは何とも
言えないけどさ。

あと、俺の印象だと、gcc 使うと NetBurst の方が遅くなる率が
高い。サーバだとやっぱり Linux が結構強いんだが、Linux だと
カーネルからアプリまで全て gcc でコンパイルされてるから、結局
Opteron の方が速かったり。

SPEC叩くならRegulation位知っておけ、と。

以前からSPECに限ればXeonもOpteronを上回ったりしてた。
>>788は偽物だろ

>アム虫の心の拠り所である＞2-socketでネットバーストXeonにすら追いつかれるとわ(笑)
アム虫の心の拠り所って8socketでしょ？

>>795 さん
　　------------------------
　　以前からSPECに限ればXeonもOpteronを上回ったりしてた。
　　------------------------
速度を測るSPEC2000とスループットを測るSPECrate_2000の区別がつかないヒトがここにも
いたすか。。。　ちなみにrateの成績わソケットの数だけメモリ帯域が増える恩恵で，シングル
コアの時代からOpteron有利ということになっていたす。
　・2004Q2頃の4-way (4-socket) SPECint_rate2000
　　Opteron850/2.4GHz: 63.4(base) / 68.5(peak)
　　Xeon MP/3.0GHz: 59.0(base) / 61.6 (peak)

>>796 さん
　　-------------------------
　　アム虫の心の拠り所って8socketでしょ？
　　-------------------------
だんだん脳内で数が増えていくすね(笑) >>554-561でも読み返すと良いかと思うす。

SPECint_rate2000 の登録データのリンクす。
　・2004Q2頃の4-way (4-socket) SPECint_rate2000
　　Opteron850/2.4GHz: 63.4(base) / 68.5(peak)
　　　　　　http://www.spec.org/cpu/results/res2004q2/cpu2000-20040503-03009.html
　　Xeon MP/3.0GHz: 59.0(base) / 61.6 (peak)
　　　　　　http://www.spec.org/cpu/results/res2004q2/cpu2000-20040322-02934.html

Pacificaの事も考えてあげて下さい。

Macヲタ、スループットみたいな基本的な単語も分かってないのか。

スループットっていうのは、単に単位時間あたりに処理される量を
示す言葉で、シングルコア、シングルスレッドでも使えるんだぞ。

確かに Sun の言うスループットコンピューティングは、個々のコアが
遅くてもマルチコアでトータルで速ければ良いということを示す宣伝
文句だが、別にマルチスレッドでないとスループットという言葉を
使えないわけではない。

>>800
ソッスネ

新コア出た直後に勝ててないんじゃ
終わってると普通は言うんだがなｗ

quadcoreになったとして、どのくらい性能が向上するのか。

>>802
だな。

だから90nmなネトバは、発熱に関してイキナリ最終回状態だった訳だが。

でもK8Lが出た時はどうなるか、ちょっとドキドキするよ。

そういや逆HyperThreadingってどうなった？

>>797
>>554-561はどう見ても4ソケット以上と書いてあるな。

>>805
妄想で終わったｯﾎﾟｲ

MACオタにはインテルも検討しているらしい4×4とコプロについて語ってもらいたいす

>>808
http://pc7.2ch.net/test/read.cgi/mac/1121683774/727
わたしわ，あなたがたがhttp://pc7.2ch.net/test/read.cgi/mac/1121683774/360-361の
ような異常な価格体系に異をとなえないことを常々不思議に思っているす。。。

>>809
作った人間がなにを幾らで売ろうが自由なんで。

キチガイの相手をするなよ

4x4は、苦し紛れ。

ソケットタイプのGPU（コプロ）は出ない。
DX10(10.1??)世代はPCI-E接続のGPUであれ、それは既にコプロとみなせる。
ただし、それはGPGPU的なソフトが現れて初めて実現する。
2ソケットの片側にはCPUか、またはGPU以外のコプロが乗っかるだろう。
ATIを手に入れたことで、AMDのGPU(VPU)の統合の意思は既に明らか。

また、我々一般人が2ソケットマザーを使用する必然性は今後も無いだろう。
一般的な用途ではGPU(VPU)の応用で、ほぼまかなえそうだ。
GPU(VPU)が処理可能な分野ならパフォーマンスもCPUを圧倒する。

我々が試せる数少ない例として
姫野ベンチの結果・・・

公式認定
ttp://w3cic.riken.go.jp/HPC/Symposium/2005/benchmark.pdf

個人サイト
ttp://gpgpu.jp/article/17502609.html
こちらは3次元配列を2次元配列にしてたりするんで
CPUとの比較はどうなのかなって気もしたり・・・

Microsoftが、どう動くか・・・

シュリンクでダイサイズが余るならメインメモリごと乗っけてくれたらいいのに

余る量が、帯に短したすきに長しなのさ

こんなに早くレスが返ってくるとは思わんかった・・・

きもいよな　粘着してんだよ

>>809
マルチプロセッサ対応CPUが高いんじゃなくて、シングルプロセッサ対応CPUが安いとは考えないのか？

PowerPC系と違ってintel/AMDの場合、ネットやメール位にしか使わないようなライトユーザーや
ビジネス向けクライアント、ノートPC等シングルプロセッサの使用環境が数の上では圧倒的に多いわけだが。

MP向けの動作保障・価格設定であんなに大量にシングルで使われるんじゃ、いくら数量でディスカウントしても
割りにあわんだろ。

どうせシングルでしか使わないのなら、MP向けのバリデーションコストを省いて安くした方がメーカーもユーザーも
助かるしな。

単に、需要のバランスに合わせた製品ラインナップと価格設定というだけの話だと思うが、それのどこが異常なんだ？

だが その時代はもう終わろうとしている

>>817
インターネットを使うユーザーなら、デュアルプロセッサは充分役立つぞ。

セキュリティチェックや動画再生なんかは、インターネットでは当たり前田のクラッカー
状態だから、マルチタスクで使い易いこれらにはデュアルプロセッサがシッカリ活用出来る。

ビジネス向けでも、Office系ソフトをチマチマ使うだけの用途ならイランだろうが、これ
からそういう訳にはいかんだろ。グラフィックてんこ盛りなWindows Vistaなんか、OSその
ものがマルチタスクが大前提な作りになってそうだし。

>>819
そのためのデュアルコア・マルチコア化だろ？
結局、シングル「プロセッサ」なのは変わらんて。

もはや、「シングルソケット」「デュアルソケット」のほうが無難な言い回しか

>>819
> OSそのものがマルチタスクが大前提な作りになってそうだし。

マルチタスクじゃなくてマルチスレッドだろ。
以前「Win98はマルチタスク未対応」とか言ってたアホがいたが、おまえか？

>>822
OS/2雑誌なんかではWin98のマルチタスク処理のあらを探して
「マルチタスク対応は不完全」とか記事にしてたな。当時。

PrescottはどういうCPUだろうか。発熱量が増えていることは確かだ。
負荷をかけたとたんに急激な温度上昇がみられるし、そう判断できる。
空気の流れが存在しない試験台で44℃程度だから、ケースに収め
、空気の流れがあればもう少し低くなるだろう。
intelが推奨しているケース側面の吸気ダクトを装備すれば、もう少し発熱は抑えられそうだ。
そうすると、発熱問題はまだ大丈夫ということになる。
テストに使ったPrescottは、最大で60Aを超える電流が流れる。
細いピンで60A以上の電気を流さなければならない。
大電流に耐えられるよう、mPGA478からLGA775になり、同時にピンからパッドに変更している。
増えた接続面のほとんどが、電源に費やされている。

LGA775でも発熱量は大きいが、放熱性が向上しているようで熱に関するトラブルは聞いていない。
パイプラインは31段となり、より高クロック動作が可能になっている。
LGA775により電源周辺を改善し、今度こそ高クロックを狙ったとしても、そこで初めて「発熱問題」が出てくる。
クロック効率を落としながらも、徹底的にクロックを上げ、市場にアピールする「クロック至上主義」だったが、ここでintelは方針を転換。
デュアルコア化を押し上げることになった。そうすれば、消費電力を落としたコア(クロックを下げたコア)を2個使って性能を向上させることができる。
intelはNetBurst(Pentium 4系)のCPUを中止し、クロックよりも全体的な処理能力向上を目指すことになった。
intelの考えまで変えさせたPrescott。これはクロック至上主義の終焉を意味している。

圧力をかけてまで製品を売ろうとしたintelは、Prescottからの圧力に負けたのかもしれない。
長いCPUの歴史の中で、Prescottは消すことができない重要なCPUになるだろう。

やっべｇｂｋ

>>822-823
汎用コンピュータからこの業界に関わった者からしたら、W98がマルチタスク
なんて完全に詐欺ＪＡＲＯ。

>>826
マルチタスクの定義は？

>>827
っttp://e-words.jp/w/E3839EE383ABE38381E382BFE382B9E382AF.html

OSに独裁権のないノンプリエンプティブなんて糞。こんな言葉はＰＣが
出てくる前は存在しなかった。要するにマーケティングの都合で出てきた
後付の定義でしかない。

だけども、ユーザに提供している環境はマルチタスクだが。
実行コンテキストを保存したままアプリケーションをスイッチできるDOSSHELLもマルチタスクだしな。

「不完全なプリエンプティブマルチタスク」

完全なプリエンプティブかどうかがどうユーザにとってのメリットにつながるんだ？

アプリが暴走するとOSまで道連れにするのがデメリットでないというなら
正直何も

>>832
プリエンプションわ，タスクスケジューリングの問題であって，メモリ保護とわ関係無いすけど。。。

あるだろ。フロッピーの初期化中に他の作業ができないとか。
んで、そのフロッピーがいかれてると（以下略

>>834
　　------------------
　　あるだろ。フロッピーの初期化中に他の作業ができないとか。
　　------------------
それわフォーマットプログラムが悪いだけす。
co-operativeマルチタスクわプロセッサ資源を有効に使用するという点でプリエンプションより
優れているすけど，約束事を守らずに無駄にCPU資源を独占するコードが混じると利点がぶち
壊しになるってだけの話す。

そういえば，Windows386とかの時点でFDを2枚同時にフォーマットするという芸当をやって
いたような気がするすけど，あれわプリエンプションじゃ無いす(笑)

>>832
そもそもアプリが暴走するというイレギュラーな事態を前提とするのがおかしくね？
完全なプリエンプティブマルチタスクを実現しているはずのNTでもBSODは起きるし
だれそれの責任でOSを道連れにするという言い訳は話のすり替えでないの？

別にノンプリエンプティブの方が優れてるって言ってるわけじゃないんだから。

ユーザに「マルチタスク」を提供している事実は変わらないけど、それが
どのように「まがいもの」であるのか説明してちょうだいな。

俺は>>823じゃないけど…
そもそもマルチタスク(プロセス)っていうのはリッチになったプロセッサのパワーを出来るだけ無駄にしない(遊んでる時間を少なくする)ために発案された物。
で、個々のプロセスが別のプロセスを意識して動くなんて無理でしょ。
(プログラマが「自分のアプリを使う人はこんなアプリも使うに違いない」とか想定しながらそれらとの親和性を高める努力をしなくてはならない。
あるいは資源の排他的占有を出来るだけ減らすとか。本末転倒だけど。)
つまりOSにしか出来ない仕事をOSが投げちゃってるから紛い物ってことなんじゃないの。
つか無限ループとかその辺のチェックが甘い言語だとデバッグ地獄に堕ちられるなｗ
横レス&乱文すまん。

> co-operativeマルチタスクわプロセッサ資源を有効に使用するという点でプ
> リエンプションより優れているすけど，

ｲﾀﾀﾀﾀﾀ
ごく最近まで、co-operativeなマルチタスクOSしか選択肢がなかった
ユーザらしい意見だな。(w

プリエンプティブなカーネルなら、レイテンシ制約の厳しいプロセスに
高い優先度を与えておき、そうではないプログラムには低い優先度を
与えるといったことができる。プロセッサ資源を有効に活用するっていう
のは、そういうことを言うんだ。
例えば I/O を多く行なうプロセスに高い優先度を与えると、システム
全体のスループットが増加する。この時、そうしない場合に比べて、CPUの
アイドル時間は減る。すなわち、CPU 資源をより効率的に使うことができる。

co-operative なマルチタスクしかサポートしてないカーネルだと、
そういう最適な CPU 割り当てが、そもそもできん。

> そもそもアプリが暴走するというイレギュラーな事態を前提とするのがおかしくね？

アプリの暴走なんて、実際には、しょっちゅう起きるものだから、
そういう事態を前提としない方がおかしい。

> 完全なプリエンプティブマルチタスクを実現しているはずのNTでもBSODは起きるし

これはほぼ全て、ハードの不良か、デバイスドライバのバグだよ。話が違う。
きちんと検証されてないハードやデバイスドライバを使うのが悪い。
アプリケーション → カーネル → ハード という依存関係があるわけだから、
右側にあるものほど、より信頼できるものを選ぶべき。

あと、なんか誤解しているようだが、Windows 98 も、ユーザプロセスの
プリエンプションは、サポートしてるよ。
そういう、スケジューリング的な意味では、Windows 98 は真のマルチタスク
OS と言って良い。(ここが MacOS 9 あたりとの大きな違い)

Windows 98 が真のマルチタスクじゃないっていうのは、メモリ保護が不完全で、
暴走したプログラムや悪意のプログラムが、他のプログラムやカーネルのメモリ
空間をブチ壊すことができたからだな。
それでも MacOS 9 に比べれば、メモリ保護機能もだいぶマシではある。

まあ、Windows 98 には、メモリ節約のために、16bit 時代からのモジュールを
引続き使っていたため、使えるシステムリソースの制約が厳しかったとか、
他にもいろいろ問題はあったが。

実行予定のタスク内容が事前にある程度わかっている場合は
co-operativeでもpre-enptiveでも大差はない。
そもそも、実行時に優先度を変えなければいけないような状況にあるということは、
システム設計自体に問題があるとも言える。
システム構成におけるハードのコストがこれだけ小さくなっている現状では
pre-enptiveなカーネルの必要性はあまりないとも言える。
ま、優秀なシスマネがいるという前提の話ですけれどもね。

>>841
おいおい、実行時に優先度を変えるのは、システム管理者じゃなくて、
カーネルなんだけど。
まともなマルチタスク OS は、システム全体のスループットを最大にする
ために、動的にプロセスの優先度をいじってるんだよ。
いくら優秀なシステム管理者がいても、そういうカーネルの肩代りはできん。

そいえばVistaだとカーネルモードに位置してたGDIがどっか行くから
その分安定するのかな。

>843
あ、ようやく文理なの? (っていうか元通り?)

そのかわり、D3Dがカーネルの深部まで食い込むんだろ
意味ナス

4*4待つのとE6600あたりで今組むのとどっちが正解なんだろう
今は特にAthlonXP2500+で不自由してない

AthlonXP2500+で一日３００万リクエスト(訪問者数５万人/日)のＷＥＢサーバー普通に動作してるしな。
ベンチとったら、Op146で毎秒３万８０００リクまで対応可能だった。
(3万8000リクエスト/s×一日＝３２億８３２０万リクエスト/日)

Op146＝2Ghz＝Athlon 64 3200+相当のマシンで、毎日３２億８３００万人にhtmlページを1つずつ見せることができる計算。

そんなにCPU何に使うのかと。とくにサーバー分野では、もう十二分の性能だと思う。

３コア以上必要な「ながら」作業は、
別PCでやった方が良いんじゃないかね。
つまり、精々２コアで十分。
もっとも、実際に使ってみないと分かんないけどね。

>>847
そんなん動かすものにもよるだろ。
静的HTMLでmod無しならそれでも十分だろうが、CGIやサーブレット動かしたら
じきに足りなくなる罠。
2chなんか何年も前から数十台体制だぜ。

1台の性能上げるよりは複数台で負荷とリスクを分散したほうがいいな。

>>847
38000rpsってどんな設定だよｗｗｗｗ
てかベンチ用ガチガチ設定でkeepaliveONで回してそれがどんな指標になるんだ？ｗ

>>850
ベンチ用だか、なんだか知らんが、
Athlon2500+で動ナビの画像直リン(アダルトHPのヤフー的なサイト)
を大量に収容してもCPU負荷２０％だ。
Apache使ってたころは、Op175でも動ナビくらったら８０％になってたが
WEBサーバーソフト変えたらAthlonでもぜんぜん大丈夫になった。
＞＞一日１０万人はアクセスされてるサバがAthlonXP2500で動いてるんだぜ。
これ以上アクセスされるサーバーがそんなに世の中にあるとは思えんが。

SPECのベンチで、毎秒何十万の在庫処理できるってベンチでても、超大企業ならともかく
普通の会社でそんな高性能なマシン必要ないわな。(毎秒何十万の処理かます必要ある会社あんのかよ？)
サーバー分野では、もう十二分以上のオーバースペックだと思う。
(パソコンメーカーは新製品売る必要性あるから勧めるんだろうが、法人分野ではそんな高性能なのもう要らんだろ)

>ベンチ用ガチガチ設定でkeepaliveONで回して
3万8000rpsは間違いだった。
Requests per second: 48480.62 [#/sec] (mean)
４万８０００rpsだった。(インスト初期のデフォルト状態で)
keepaliveOFFで1万9974rpsかな。計算しなおすと、41億8867万人に毎日htmlページを表示できる計算。そんなに人間いねーよ

リクエストってのはry

>>851
某スレのコピってきただけじゃねーかｗｗｗｗ
しかもアレ146じゃなくて148なｗｗｗｗ


せめて自分で回してから書き込めよ。

AMD's Next Generation Microarchitecture Preview: from K8 to K8L
http://www.xbitlabs.com/articles/cpu/display/amd-k8l.html

>>851
サーバソフト、何に変えたん？

LiteSpeed Web Server


まじでおすすめ。

>>856
ども。
謳い文句はいいとこ取りだね。

移行しようとして嵌った（んで回避した）話でもあれば良いんだけど、
日本語の運用情報がweb上にはあまりないように見える。


自称 Apache の後継だけあって、下記の特徴の通りかなり Apache ユーザを意識している。

静的コンテンツの速度は Apache の 6〜9倍
PHP は Apache(+ mod_php) の 1.5倍以上の速度
Apache の設定ファイルを理解するので移行が容易
アプリ(CGI)接続用の独自のプロトコル(LSAPI) [PHP, Ruby/Rails]
CGI も FastCGI も JSP(AJP1.3) とか大概の外部アプリが動く
SSL、GZIP圧縮、静的ロードバンラサ、VirtualHostも使える
.htaccess に互換があるのは凄い

851の中の人じゃないが、Ruby on Railsの重さに耐えかねてMongrelとともに
試験導入してみたらやたらレスポンス良いから拍子抜けした。

>>853
いや、あれベンチして書き込んだの俺だし。そういや148だった。本人ですが。

もしも積極的なFab戦略が裏目に出てAMDが倒産したら
何処が助け舟出すのかねぇ

>860
つぶれられると独禁法で困るIntelが筆頭候補だな

MS(ゲイシ?)がappleの株を持ってる、という事実。

90年代にアポーが金に困ったときに投資してるからね。

自作板のやつってOSの話題になるととたんに素人臭い議論始めるけど、
もしかしてCPUの話もその程度なの？

中身については素人が多いんじゃない？
特にOS（というかソフト）の話になるとビックリするほどユートピアなのが多いよ
部品差し込んでベンチとるだけなら誰でもできるしなｗ