Intelの次世代CPUについて語ろう 17プラン

■前スレ
Intelの次世代CPUについて語ろう 16プラン
http://pc7.2ch.net/test/read.cgi/jisaku/1122463712/l50

■過去スレ
15 http://pc7.2ch.net/test/read.cgi/jisaku/1115570909/
14 http://pc7.2ch.net/test/read.cgi/jisaku/1108228581/
13 http://pc7.2ch.net/test/read.cgi/jisaku/1097947493/
12 http://pc5.2ch.net/test/read.cgi/jisaku/1089896048/
11 http://pc5.2ch.net/test/read.cgi/jisaku/1085287040/
10 http://pc5.2ch.net/test/read.cgi/jisaku/1079371291/
9 http://pc3.2ch.net/test/read.cgi/jisaku/1077935289/
8 http://pc3.2ch.net/test/read.cgi/jisaku/1076749130/
7 http://pc3.2ch.net/test/read.cgi/jisaku/1075729779/
6 http://pc3.2ch.net/test/read.cgi/jisaku/1074656386/
5 http://pc3.2ch.net/test/read.cgi/jisaku/1072672636/
4 http://pc3.2ch.net/test/read.cgi/jisaku/1069899330/
3 http://pc3.2ch.net/test/read.cgi/jisaku/1068220780/
2 http://pc3.2ch.net/test/read.cgi/jisaku/1064098746/
1 http://pc3.2ch.net/test/read.cgi/jisaku/1058361617/

※荒らし・煽り・厨房・アムド虫は放置が一番効果的です。返答せずに削除依頼を出しましょう。
　放置できない人も荒らしです。マターリしましょう。

・デスクトップロードマップ
Willamette-478 0.18μm版Pentium 4 2000年11月発売
　　↓0.13μ化
Northwood 0.13μm版Pentium 4 2001年12月発売
　　↓90nm化、64bit実装、SSE3その他大幅な変更
Prescott 90nm版Pentium 4 2004年2月発売
　　↓キャッシュ2M化
Prescott 2M Pentium 4 6xx 2005年2月発売

Smithfield デュアルコア Pentium D 2005年5月発売

・モバイルロードマップ
Banias　0.13μm版Pentium M/Celeron M 2003年1月発売
　　↓キャッシュ2M化、多少の改良
Dothan　90nm版Pentium M/Celeron M 2004年5月発売


・今後発売予定？のCPU

CedarMill 65nmプロセスCPU NetBurst系
Presler　65nm版デュアルコアCPU NetBurst系

Yonah　65nm版デュアルコアCPU SSE3
Merom 65nm版のデスクトップ&モバイル共通CPUコア EM64T
Conroe　65nm版デュアルコアCPU

関連スレ

intel雑談ｽﾚｯﾄﾞ
http://pc7.2ch.net/test/read.cgi/jisaku/1098932664/
Pentium M - Centrino - 33W
http://pc7.2ch.net/test/read.cgi/jisaku/1123902786/l50
Northwood Pentium4友の会 Part15
http://pc7.2ch.net/test/read.cgi/jisaku/1124199111/l50
Smithfield PentiumD友の会
http://pc7.2ch.net/test/read.cgi/jisaku/1117890989/
Prescott Pentium4友の会【柏原芳恵】
http://pc7.2ch.net/test/read.cgi/jisaku/1112237419/
Celeron 総合 Part6
http://pc7.2ch.net/test/read.cgi/jisaku/1119604058/
CeleronD Prescott Part4
http://pc7.2ch.net/test/read.cgi/jisaku/1106566395/
【nocona】自作でXEONだ！其の拾壱【prestonia】
http://pc7.2ch.net/test/read.cgi/jisaku/1114588731/
【IA-64】Itanium2専用スレ・その3【アイテニアム】
http://pc7.2ch.net/test/read.cgi/jisaku/1097330852/
Intel uPs Info @新mac板
http://pc7.2ch.net/test/read.cgi/mac/1121683774/

底知れず愚かな人々

2つあるがどっち削除？

こっちが早いな

>>1
乙

>>前スレ1000

ガーン。
Galaxy は全て薄型ブレードサーバなのかと誤解してますた。
薄型ブレードサーバもあるよってだけだったのか。
どうもありがと。(泣

intelにせよAMDにせよ、HPC系でPower4+の時のようにメモリ帯域足らないから
Dualコアの片方を殺すって使い方にならないと良いんだけど。。。

密度とコストパフォーマンスを考えると1U 2ソケットをIB接続クラスタかな。
RDMAのlatencyはOpteron > Xeonになると聞いたことがあるのでOpteronは
必ずしも優位ではない。つまりは用途次第。

>>9
そんな用途にはベクトルマシンを・・・

>10
IBでもPathscaleのようなHyperTransportにダイレクトに繋げられるやつだと
RDMAでもOpteronの方がLow　Latencyのようですよ。1.32usだそうだ。

>>12
PCI-XやPCIeのIBと比較するとコストが問題。IBもニッチになったよな。
最初の予定通りチップセットにIBが組み込まれていればなぁ・・・

>12
まったくですな。HPCは市場自体がニッチだけど。。。
チプセトにIB組み込まれていたら、TCPoverIBとかあるから
ふつうにPCで使われていたのかもしれないのに。
QsNet、InfiniBand、MyrinetどれもPC側へフィードバックしませんねｗ

しかし、なんだか少なくとも3hopぐらいで知人のような気がしてきたんだが…
HPCで、しかもIBやってるとこって、かなり限られるよね。
(ちなみに俺はIBは、やってない。1hopの知人では何人かいるけど)

この業界は狭いので最大2hopであたりますね。大学-旧国研-メーカー

俺はしがない外注なので、その3つには入りません。(w
だからやっぱり3hopかな。

>>15-16
最近はPCクラスタのユーザが増えてきているから2hopはちょっと無理がありますよ。
俺はHPCの人じゃないですが有名人(M先生とか)まで1hopか2hopですね。
やっぱ3hopが現実的でしょう。

昨晩からなにやら伸びてると思ったら。
Gk乙とだけ言っておく。

底知れず愚かなseRKraHs ｷﾀ(ﾟ∀ﾟ)!!

Gkf6/42t = 外注なのか。
なるほど。。。

一応貼り
Opの話は↓でしる

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

Banias開発者に聞く、Intelの次世代省電力CPU技術
http://www.itmedia.co.jp/news/articles/0508/29/news008.html
Mr.エデンの興味深い話。
Yonahはかなり進化しているとのこと。

本田ちゃん、もっと突っ込んで聞いてくれよー。

>>22
＞「Pentium IIIに対するBaniasの進化に対してDothanが同程度進化
＞しているとすると、DothanからYonahへの進化はその数倍もの大きな
＞差があります。YonahからMeromの進化も決して小さくはありませんが、
＞DothanからYonahへの変化ほど大きなものではありません」
まあこれは「PenM系初のデュアルコアだからとても設計苦労したんだよー」ってことなんだろうな。
性能面ではYonah→Meromでジャンプアップしてもらわんと困る。

DothanからYonahがよっぽどスゴイんだろ
それより気になるのが
Conroeの設計が
オレゴンチーム(゜ロ゜;)
次ヘマしたらどうする？
制裁くわえるか(笑)

そもそもP-Mの元のP6
造ったのはオレゴンだし。

でもネトバ作ったのオレゴンだし(笑)

>マイクロアーキテクチャは同じですが、
>最終的なチップのデザインは彼らが行っています

だから
なんかいじられそう(笑)

もう終わりが見えている？

>>29
何が？

>>30
>>29の脳内限定でintelの歴史が。

>>31
ﾜﾛｽ

>>24
よーし、プ→炭と実績のあるオレゴンチームなら、
きっとConroeは期待どおり「焜炉」となる！！

゜　　　　　　　　　○　　　　゜
　　　o　｡　　 　 ゜ﾟ　　ﾟ ．　　　　o　　　　　　○o
　　　　　　　　ｒ⌒ヽ　　(⌒⌒)　　ｒ⌒ヽ/,
　　　　 、、;(⌒ヾ　　　((⌒⌒))　　/⌒) ),　　, 。
　　、　ヾ　(⌒　　　 ﾌｧﾋﾞｮ━━ﾝ！⌒⌒);;）／.　,
　、＼(⌒ゝ;(⌒ヾ　　In＿�Иn＿�пﾜ）／）) .,／ ,,
（(⌒-丶(;;;(⌒ゝ;;(⌒(；｀д´)｀д´)　,⌒⌒);;;;;））)⌒)
　(;;;;(⌒(⌒;;;(⌒　⊂　 焜　 |　炉　⊃／　)）⌒)）;;;;）-⌒)）
ゞ　(⌒⌒=─　　　　(,,フ.　ﾉ (,,フ .ﾉ　　　　─=⌒⌒)ノ;;ノ;;;::)
（(⌒≡＝─　 人从;;;;　レ　　レ'　;;;从人─＝≡⌒)丿;;丿ノ

LrlIg5ik

どっかのホームページで
Conroeが最高2.93GHzで出るって書いてあったTDPは65W
今日ドスブイマガジンを見たらWoodcrestが2.93GHzでTDP80Wと書いてあった
さてこのTDP15Wの違いはなんでしょう

メモリじゃね

なんでメモリやねんなωτ〃ゃねω

すまん、キャッシュね

キャッシュじゃない

ttp://www.geocities.jp/andosprocinfo/wadai05/20050827.htm
> 最近の話題 2005年8月27日
> ３．Merom，Conroe，Woodcrest
> (中略)
> そして，MutiplyとAdd命令をくっつけてMultiply Accumulate命令にするMacro OP Fusionもあるそうですが，

マヂですか？

FB-DIMMのコントローラとCSIをダイに統合してるのも関係あるんじゃない？

ちなみにアスロン64×2のTDPは最低でも89Wで
Conroeより24Wほど高くなってます
アム厨には
インテルとはTDPの意味が違うと言う人がいますがスルーしましょう

>>43
で、焜炉はいつ出るんだ？
65nmのAthlon64はいつ？

出てない製品と現行品を比べる阿呆もスルーな・・・

AMDは次世代CPUが無いから現行品しか比較できないのねん

>>44
焜炉は来年Q3
>>45
全く情報が無いから比べようが無い
だから現行CPUを引き合いに出しただけ

腐った頭には何言っても無駄か・・・

ageといい、頭の悪いカキコといい……。
アンチの騙りでしょ？

>>48
腐ってるので何を言っても無駄ですよ。
頭脳明晰な>>48様はこちらでAMDの次世代CPUに関して存分に語って下さいませ。

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

アム厨スレに誘導すんな

なんか、なんちゃらの法則が崩壊してからIntelって夢と現実の差が大きすぎると思わないか？
パラノイヤから狼少年への変身？

おりゃ、AMDの話なんざ全くしてないがな・・・
本当に腐ってら

>>43
頭悪いカキコ……( ﾟдﾟ)

>>43が書いてる事って本当？

>>55
少なくとも現時点では。
AMDの65nmは'07H1だっけか？

そんな情報あったっけ？一時期2006年前半とかいう情報はあった気がするが。
いくら何でもIntelから一年遅れは無い気がする。
（最近トラブってるという噂があるけど）来年後半じゃないかね。

06年前半って釣音じゃない？

>>57
一年遅れだ

正直今買うならPenDよりPen4 6ｘｘの機種買っといた方がいいっぽいの？

部屋を含めて冷却できる自信があるなら、PenDも悪くはないと思われ

>>58
Fab36に着工したての頃は量産開始が2005年中という話もあった。
Intelも当初の予定より遅れてるからさすがに消えたみたいだけど。

一応Fab36は今年中に生産開始になってるからねえ。
最初の製品は90nmかも知れんが65nm対応工場を長い間遊ばせておくとも思えん。
2007年中盤には65nmへの完全転換を果たすらしいから、その一年前から65nm製品が出てくると睨んでる。
SocketM2に移行して数ヶ月後には65nmが出てこないかと密かに期待してるんだが。
ちょうどSocket939とWinchesterの関係みたいに。

インテルはもうとっくに65nm立ち上げてるよな？

>>60
yes.
負荷100%で回すとDはクロック下がるし、
負荷50%以下なら D820≒620

AMDは今回もこれぐらいのスケジューリングをしてるんじゃないの？

Fab 30はなぜこんなに順調なのか
http://pc.watch.impress.co.jp/docs/article/20001207/kaigai01.htm

>>65
この頃は、当初予定を半年前倒しとかあったけど、今は逆だな。
半年後ろ倒しｗ

つか、今はFab30のスケジュールで言えば99年Q1ぐらいの感じでしょ

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

Yonahはジュアルコアとジュアルチャンネルでオンボードグラフィックもキビキビ？

何が言いたいんだ？

これがインテルの本気か。PenXEのリテールファンの音すごい。
ttp://koti.welho.com/pnystro2/Hauskat_videot/PXE840_Cooling.avi

>>69
CPUによる変化はVertexShaderの速度の向上しかない。あとは915GMから945GMへの変更点だけだし。

>>71
掃除機かよ

>>71
ﾜﾛｽwwwwwwwwww

Netburstって何だったんだろうな。
淫厨よ、Yonahが出てくるまで地獄を味わうがいいｗ

>>74
アム厨いい加減な事言うな！
Yonahがいつ出るか、出ても予定通りの性能（ｒｙ

アム虫が来るととたんにレベルが下がるなぁ。
このスレもそろそろ潮時だね。

そういえばプレスコは実物が出るまで北森比一割増のIPCとか言ってたな。

淫厨だけの時も、別の意味でレベル低いけど

>YonahではCPUのパワープレーンが単一で、クロックドメインもコアで分離されていない。
>そのため、こうした制御になっている。2コアの周波数&電圧が連動していることは、平均
>消費電力にある程度の影響を与えるはずだ。
>Merom世代でも、コア単位の電圧と周波数のフレキシブルな制御は難しいため、基本的
>にはYonahと同種の制御になると推測される。

http://pc.watch.impress.co.jp/docs/2005/0831/kaigai208.htm

IDF Fall 2005 - Merom/Conroe/Woodcrestの登場
ttp://pcweb.mycom.co.jp/articles/2005/08/31/idf1/
Yonahは全ての整数演算ユニットでSSE/SSE2が実行できることが既に公開されているから、
つまり整数演算に関してはパイプラインが3本ということになる。

要するに2つのコア間で同期を取る際に、L1キャッシュの中身のSnoopを直接行えるという話である。
これにより、同一プロセスの中の2つのスレッドが別々のコアで実行されている際の
スレッド間同期を取るオーバーヘッドは、YonahやAthlon 64 X2と比較しても明らかに小さくなっており、
Hyper-Threading方式と比較してもほとんど遜色ないと考えられる。


Q: この4 issueというのは、たとえば倍速のExecution Unitが2つという意味ですか?
それとも等速(Regular Speed)のExecution Unitが2つという意味でしょうか?

　A: 等速のものが4つだ。

Q: 次にEM64Tについて教えてください。Prescottの世代では、Execution Unitは32bit幅になっており、
64bit命令を処理する場合はこれを2つに分けて実行していました。
で、Conroeの世代はどうなのでしょうか?

　A: これ以上の詳細は話すことができないが(笑)、これだけは言える。
　Conroeの世代は4 issueの64bitマシンでEM64Tをサポートする。これはNativeな64bitマシンだ。

Q: もう一つだけ確認させてください。
Conroeの世代では、64bit命令と32bit命令の処理速度は同じなのでしょうか?
純技術的には、1個の64bit Execution Unitは同時に2つの32bit命令を処理することも可能だと思うのですが、
このあたりはどうでしょう?

　A: それについては今回明らかにできない。

Q: ということは、たとえばMeromとConroeではパイプラインの構造が異なる可能性があるわけですか?

　A: 悪いがそれには答えられない。

Desktop担当幹部も口が堅いなあ

XEはPreslerじゃなくてPaxvilleのFSB1066MHz版を投入するんかな。
しかしPreslerとほぼイコールなDempseyでもFSB1066MHzが可能らしいからPreslerにそのまま行くんだろうか。
おれとしてはCedarMillでXE691を出してほしいが・・・

>また、4 issueのスーパースケーラであるが、これは後で確認できた話だが整数演算「のみ」であり

間違い発見した
>>DDR2-677の2chだと8.4GB/secに達するのに対し

DDR2-677の2chだと10.8GB/secの間違いですね

>>82
XEラインにL3共有のTulsaを持ってきたら、intel見直す。

PreslerとDempseyがPaxvilleのシュリンクだったら。
もうちょっとはこの2つも救いようがあるんだろうが。

やっぱり、炭と同じく“並べただけ”か。

>>86
90nmでPaxvilleを作って、65nmにシュリンクするのを待っていたら
MeromとConroeが登場するからな。
最初から65nmで作る選択肢もリスクを考えるとありえない。

intelの65nmプロセスは90nmみたいに
出てきたらリークびっくりとはならないようで一安心ですよ?
yonahのデモ見て安心した。
conroe、meromも大丈夫かな。

>>88
PreslerとCedarMillは出て来るまで判らん。
製造プロセスでは無くネトバの問題だし。

現在のものより下がってれば概ねオケ(w
だって買わんし。

Intelのシュリンク自体に問題あるなら、BaniasやDothanも大変な
ことになってるはずだしな。

Banias系は元から省電力設計だったから受ける影響が
軽微だっただけだと思われ。
実際、ネトバも180nm→130nmでは下がってる。

>>92
ネトバが元から省電力設計では無かったからコケたんだよ。
K8も130nm→90nmでクロック上げてないだろ。

今まで通りにシュリンクで消費電力大幅減になると見込んで
電力効率悪化するけど性能は上がるような変更してみたら
予想外に下がらなくてorz

ってのがﾌﾟﾚｽｺじゃなかったっけ

ネトバ
130nm→クロックage→90nm
PenM
130nm（省電力）→クロックage→90nm（省電力）
K8
130nm→クロック据え置き→90nm（省電力）

こんな感じかと。

Dothanが半年遅れたのはもう忘れたか

Yonahも当初の予定から半年遅れてますんで既に

Yonahと違ってドタキャンだったろう

X86以外の次世代はどう？

>>96
クロックが当初の予定通り≒熱で遅れた可能性は低い

>>96
歩留まりが上がらなかったんじゃなかった？

>>101
ﾌﾟがコケた→土讃の需要（予想値）が大幅増

あたりが正解じゃないかと。

>>102
それはIntelの場合は考えられないんじゃないか・・・・
と思ったが市場出荷量も大幅に違うからあるのか？？？わからん。

モバイルはTDP縛りがきついから量は取れにくいかもな。
90nmプロセス自体の歩留まりは最高だが。

次のCPUIDのファミリーはなんだろ
NT 4.0対応を続けるなら23あたり？

デスクトップに使えばい、、、うわなにw

http://pc.watch.impress.co.jp/docs/2003/1010/kaigai031.htm
同じ90nmのDothanの遅れについては、現在、消費電力と熱が原因らしいことがほぼ
明らかになっている。そして、同じ90nm世代のPrescottの抱える問題もここにあるようだ。

http://pc.watch.impress.co.jp/docs/2003/1027/kaigai038.htm
現在のBステップのμPGA478版Prescottを搭載した場合、バスエラーが発生
するケースが見つかったことにあるという。その原因は、バスインターフェイスの
電圧振幅が、規定されたスペックに合わないケースが出たからだという。

>>107
引用元も無い推測記事出されてもな。

>>103
藁の時不況で出荷数減って大幅前倒しが行われた。

>>102
脳みそ腐ってるな・・・

> これ以上の詳細は話すことができないが(笑)、これだけは言える。
>Conroeの世代は4 issueの64bitマシンでEM64Tをサポートする。
>これはNativeな64bitマシンだ。
Oh！ＡＭＤｼﾝﾀﾞﾅ・・・・・

>>110
お前ほどではないよ。
土讃にリーク対策施した形跡が無いだろ。
あるいはキャッシュのゲート長伸ばした（ﾌﾟCｽﾃ→Dｽﾃでの更新）のかもしれないが、
せいぜいその程度しかやっていない。

intelの90nmプロセス自体にリーク電流対策のためのギミックはなかったような・・・？

歪Siをパフォーマンスを上げるんじゃなくて省電力になるように使う。
そもそもAggressiveClockGatingがあるからな。
これをもっと細かく配置するとかで消費電力を削減したのかも知れん。

ttp://pc.watch.impress.co.jp/docs/2003/1009/ubiq28.htm
「●同じ600MHzで、Baniasよりも消費電力が増えるDothan」
以降を見るとDothanでもリーク電流で苦労したのは確実。

あと、本当だったかどうかは知らないが
ttp://pc.watch.impress.co.jp/docs/2003/0806/ubiq18.htm
> Intelはこれまで、Dothanの熱設計消費電力は21Wだと説明してきたが、
>7月半ばのアップデートで30Wに近い熱設計消費電力になると通知してきたという。
なんて話もある。

>>114
EISTで最大消費電力は下がらん罠。（例：ﾌﾟ）
誰かEISTでTDPが抑えられたとかトンデモ記事を書いていたが。

EISTの話なんてしてないわけだが

インテルの技術は世界いちーーーーーっ！
リーク電流の問題も来年見事に解決する。

リーク電流の問題も世界いちーーーーーーーーーーーっ！

に見えた。
オレ、きんもーっ☆

>>118
あぁお前物凄くキモい

>>119
御意！　編む厨はｷﾓｲ！

ｴｸｰｽｽｹｰﾙの1GHz越え版の情報まだか

>>121
WHAT?

>>112
需要が増えたのに応じて
発売時期を後ろにずらすという判断をしたと
考えるやつよりは、腐ってないだろ・・・

>>122
素直にRaidカードとかのチップの事かとオモワレ
たぶんだが・・・

>>124
THANKS

>>121
ttp://www.theregister.co.uk/2005/08/23/intel_demos_monahans/

High-kはどこいった？

High-k，Metal Gate，Tri-Gateは45nm。

AMDはHigh-kとMetal Gateを65nmで導入するという淡い夢を見たこともあったなあ。

完全空乏型SOIも当初は65nmで採用だったような

>>99
低電圧版Itanium 2 1.30GHz/3MB L3キャッシュ/400MHz FSB 62W 57,240円
CPUだけだと悪くなさそう。次世代はプロセスも追いつくのでXEONから流れるかも。

Xeonとプラットフォームが共通化されたら気軽に差し替えて使えるようになるんかな。
ファームの問題も結構ありそうだが計算用にはいいなあ。

プロセス技術でのIBM･AMD･Sony･Toshiba･CSM連合は、肝心要のIBMの工場がメタメタで
バリバリの最新技術導入すると死ぬため、前と比べると割と慎重になってきてまつ。
唯一連合組んでないIntelが一番身軽なはずだけど、こっちも歩詰まり考慮してか保守的でつね。

Centaurは…

>>133
cellのこと？

>>116
AggressiveClockGating＝EIST

それはひょっとしてギャグで言ってるのか!?（AA略

>>137
orz

何れにせよAggressiveClockGatingでも最大消費電力は減らんぞ。

今ふと思ったんだが、AggressiveClockGatingで消費電力が減るのは、

1.CPU使用率が100%切っている時
2.パイプラインストールが発生している時

な訳だが、まさかCedarMill/Preslerに積んだなんて事は・・・

積むメリットはあってもデメリットはないぞ？

CPU使用率が100%であっても、消費電力がMAXになるとは限らない。
すべてのリソースをbusyにするようなプログラムは珍しいから。

となると、
すべてのリソースがbusyになったときの消費電力に合せて、
電力や廃熱の設計をすると、いつも余裕があってもったいないよね。

ならば、消費電力や温度の枠内に収まるように管理しながら
動的にクロックを上げてやれば、より性能が上がってｳﾏｰだよね。

そういう考え方で作られたものが、
熱でクロックが下がる!
と叩かれてるのは、ちょっとなぁ。

CPUに連続的に負荷をかけるアプリもあるけれども、
速度が必要なのは10秒のうち1秒だけというアプリが多いと思う。
昔だと、漢字変換で変換キーを押した瞬間とか、ね。

>>139
CPU使用率が100%であってもALUやFPUが全て回っているとは限らないわけだが
そういうわけで、Aggressive Clock Gatingは最大消費電力にも効果がある場合が多い

いや、その場合を最大とは言わない・・・

>>143
淫輝ＣＰＵの辞書に「最大」の２文字はありません。
熱も電力も平均で語るのが淫輝Ｑｕａｌｉｔｙ！！

>>141
売り方がまずかった。
3.2Gだけど熱で2.8Gになります。
じゃなくて
2.8Gだけど温度低ければ3.2Gで動きます。
だったら誰も文句言わなかったろう。

↑
それだ!(w

>>145
通常クロック 2.8GHz
温度が低いと 3.2GHzで動作します！
その名もPenD 840 約6万円

一方で、いつもいつでも 2.8GHz
PenD 820 約3万弱もよろしくね。

・・・で売り出すのか？

>>141
PenDはエンコしか取柄が無いからなあ。
そのエンコがCPUに連続的に負荷をかけるアプリなわけで、
唯一の得意分野でクロックダウンするPenDは叩かれて当然。

Pen4 630とPrnD 830
積むならやっぱPen4か？

High-k、Metal Gate、Tri-Gateとかラボでの開発うまくいってないんだろうな。
うまく行ってるなら、今回の新マイクロアーキももうちょっとパイプラインの段数大きく
したはず。 今後数年は、リーク問題に解決の見込みがないから、14段になったんでしょう、多分。

完全に新アーキとかいってるけど、NetBurstがこけたとはいいにくいだけで
ベースがPenMだから14段と少ないままなのでは

>>151
『ネトバをベースに作ったPenMみたいなモノ』なわけだが。

まだ肝心のトレースキャッシュやデコーダーについて触れていないから
どうだかわからないよね >NetBurstを色濃く残す。

>>150
利益率の高いモバイル系をベースにするのは当然の戦略だと思うが。
K8だって、鯖系の♪ベースだし。

>>148
エンコなんて少し遅くたって別に構わないじゃん。
それよりも、瞬発力があったほうが体感速度が上がる。

>>152
ネトバがベース？
何を寝ぼけた事言ってるんだ？

パイプラインは段数増やせば増やすだけミスのペナルティが大きくなる罠
トレースキャツシュ採用ならステージ数は実質倍以上。命令実行密度をあげるためのダイナミックスケジューリングにおおよそ10段使えるとすれば、無理なく実行できるのかも。


4issueは2wayパイプライン×2μOPsフュージョンかも。
具体的にはMMX×4、FPU×4かもね。
SSExが1クロック2命令実行できる。AltiVecも真っ青。

トレースキャッシュにデメリット無かったっけ？
ちなみにアム厨ではありません

>>156
『基本構造をネトバから引き継いで、セッティングをPenM風に』
てな感じの開発者インタビューをどこかで見た。

これだな。
ttp://pcweb.mycom.co.jp/articles/2005/08/31/idf1/003.html

Q: 新MicroArchitectureは、NetBurst ArchitectureとBanias Architectureを併せたものでしたね?

A: 我々が説明しているのは、NetBurst ArchitectureのFeatureをConroeのMicroArchitectureに取り込んだというものだ。
NetBurstの持ついくつかの特徴は、Conroe世代には欠かせないものだからだ。
具体的に言えば64bit、Quad Pump Bus(P6バス)、VT、LaGrande Technologyなどだ。
その一方で、Power Designのphilosophyに関してはBanias Architectureから持ってきた。
つまりPhilosophy of Designだ。つまりFeatureとPhilosophyをNetBurstとBaniasから持ってきた上で、
New Architectureを定義したということだ。

64bitとかVTとか別にNetBurst用ってわけじゃねーだろ
元々HTだってなかったんだし

どうせ力技でデュアルダイにするのならPenMとItanium2のデュアルダイ
作ってくれよ。

>>161
『構造（の一部）をネトバから、熱的な設計思想をﾊﾞﾆから』
と書いてあるだろうが。

>>160
それってネトバベースって言うより半々じゃない？

>>163
だからどう考えてもPenMベースに付加機能じゃねーの？

>>164
『Featureをネトバから、Philosophyをﾊﾞﾆから』とわざわざ言い分けているのは、
回路の構造自体はネトバに近いと言う意味なわけだが。

キャッシュにヒットする限りフロントエンドのデコーダを休ませられるので、省電力化にはかなり有効だけどね
逆にトレースキャツシュなしに4issueはデコーダ4つフル稼働させる羽目になり、しかもデコード込みで14段じゃ4issueを活かしたリオーダリングは困難。
結果パイプラインがスカスカでかえって電力効率を落とす羽目にもなる。

Meromは倍速ALUもなくなったし、極端に高クロックを狙った設計でないから、
キャッシュのレイテンシを増大させることなく「ある程度」容量を増やせるはず。
理屈は省略するけど。

あと、ミスヒット時のペナルティ軽減の意味でデコーダを複数用意する手もある罠。
それでもクロックゲーティングがあるから消費電力に殆んど影響しないし。

64bit、P6バス)、VT(ryはネトバを持って来れば既にくっついている。
一方で熱的には、パイプラインを短くして、ALUを等速化して、各種省電力機構も導入し、
ﾊﾞﾆ風に仕上げる。

以外にどう読めるんだろうか？

「ネトバの省電力技術」で最も有効なものがトレースキャツシュだと思うんだが。

ttp://pc.watch.impress.co.jp/docs/2005/0825/kaigai206.htm

ここには

> 実際には、次世代マイクロアーキテクチャの開発は、Baniasを開発したIntelイスラエルの
> 開発チームが担当した。そのため、Banias→Yonah(ヨナ)の発展型として開発したMeromに、
> NetBurstのフィーチャとバスを取り込んだと推測される。

とか書いてあるな。

>>168
BaniasになくてNetBurstにあった特徴(4T)をNetBurstから、設計思想をBaniasから持ってきたと読めた。

Feature：物理的
Philosophy：論理的

日本語と英語だから厳密には意味違うけどな。

>>171
Philosophyの前で『Power Designの』と限定してあるんだが。

>>172-173
いきなり訳しが違うと思うんだが・・・

>>170
よくやった！！
今携帯からだから反論が出来なかった・・・

元麻布春男先生がきましたよ

＞おそらくはNetBurstを継承したアーキテクチャであったであろうTejas/Jayhawkのデュアルコア/マルチコアから、
＞モバイル用のコアであったBanias/Dothanをベースにしたデュアルコア/マルチコアへ転換した、ということなのだと思われる。

＞奇しくもNetBurstを生んだ事業部の事業部長は、結果として二人相次いで辞任したことになる。
自尊心回路崩壊完了

＞Feature：物理的
＞Philosophy：論理的
＞日本語と英語だから厳密には意味違うけどな。

どこでこういう誤りが刷り込まれたのか、そっちが気になるので ID:Ie1MXSyR さん出て来てくだつあい。

トレースキャッシュのデメリットって、
容量多くするとクロックあげられないとか、そんなところ?
今回はクロック志向じゃないみたいだし、
デコーダーの消費電力(熱)のこともあるから使ってる気はするけど、どうなのかねぇ。

あとパイプラインの段数をNetBurstに於ける最大の特色と捕らえてる人には
Merom Conroeの14段(Conroは違うかもしれないらしい?)だけ指摘して
ほらPenMライクですよ?、という評価になるかもしれんね。

倍速ALUと異様に長いパイプラインは特徴だと思うが

fea・ture

━━ n. 顔の一部 ((ひたい・目・鼻・口など)); （pl.） 容貎; 特徴; 主眼点; 長編［主要］劇映画 （feature film）; （新聞・雑誌の）特集記事; （テレビの）特別番組 ((on)); 目玉商品.
━━ vt. …の特徴になる; 呼び物にする; 特集する; 出演［主演］させる; 〔米話〕 想像する.
━━ vi. 重要な役割を演ずる ((in)).

http://dictionary.goo.ne.jp/search.php?MT=Feature&kind=ej&kwassist=0&mode=1


phi・los・o・phy

━━ n. 哲学; （特定の）哲学体系; 原理; 人生観; 沈着; 悟り; 秘訣.

http://dictionary.goo.ne.jp/search.php?MT=Philosophy&kind=ej&kwassist=0&mode=1

設計思想はP-Mでアーキテクチャの特徴にネトバが見られるって感じかねえ。

まぁぶっちゃけどっちでも良いんだけどね(w
intelの示すConroe Merom世代の低消費電力と性能が事実なら。

>>170,175,176
アフォ
intel社員の話と仮説を同等に扱うなよ。

>>180
その通り。ｽﾏﾇ

>>180加味しても、イスラエルチームが1から組んだ（ﾊﾞﾆでも無い）アーキテクチャだと思うのだが。

パワフルで比較的クールなMerom

性能がよくて消費電力/発熱が少ないなら大歓迎さ

>>182
完全新規アーキとはよめんなぁ
PenMだって完全新規じゃねーし

ただたんにPenMのすばらしさが開発陣でも話題になり
Yonaの効率の良さをベースにすれば
デスクトップ、モバイル、サーバーで同一コアにできてより集中できる
だが、デスクトップやサーバーで受け入れるためには64bit化もろもろが必要になる

ってだけじゃねーの？

そしてNetBurstの事業部長左遷

英和辞典じゃなく普通の辞典を引いたら?

ttp://dictionary.reference.com/search?q=feature

7. An item advertised or offered as particularly attractive or as an inducement: a washing machine with many features.

>183
皮肉ﾜﾛｽ

>>185
このインタビューを終えての大原の纏め。
　　　　　　　　　　　 ~~~~~~~~
＞デザイン的にはYonahからスタートした「のかもしれない」(実は筆者は、今ではこれすら疑っている)が、
＞結果としてかなり違うものになっていると考えてもよさそうだ。

このイン(ryを見る前の後藤、元麻布の推測。
>>170,176　　 ~~~~~~~~

何れが信用に足るのかはまあ、置いておく。

IDF関連の記事とか読んでれば、MeromはBanias系と普通に捉えると思うんだけど。
CNETの誤報はいかんね。あれで考え違いした人がだいぶいるんじゃないのかな。

Dightal Health Groupは左遷じゃねーの？

大原が（漏れみたいにorz）誤訳していない限り、

『Power Designの』philosophy

と言う言い方は、非常に引っかかる言い回しなわけだが。

NetBurst発表時もパイプラインの段数はTraceCache後だけの20段って発表してたよな。
Pen3みたいな普通の14段で3GHzとか達成出来るんだろうか。

現状PenMで３GHｚはわりといけることを考えると
デスクトップやサーバー向けはTDP高いしプロセスルールもあがってるし
いけないことはないのでは？

Net-burstのﾄﾚｰｽｷｬｯｼｭはついでにμOpsにしてるからまぎらわしいけど
ﾄﾚｰｽｷｬｯｼｭって言葉自体はISA無関係
（だからx86のままで格納するﾄﾚｰｽｷｬｯｼｭなんてのもどっかがやろうと思えばできるはず、ほとんど意味なさそうだけどｗ）
http://pc.watch.impress.co.jp/docs/2004/1108/kaigai132.htm
＞トレースキャッシュは、Pentium 4でも採用されている命令キャッシュ方式で、
＞プログラムの中の実際に使われるコードのトレース(実行されるパス)にそって命令をキャッシュする。
＞プログラムの命令順序に従ってキャッシュする従来の命令キャッシュよりも効率がいい。

http://techon.nikkeibp.co.jp/word/data/ID0517.html


だから（本当は）uOpsｷｬｯｼｭ≒ﾄﾚｰｽｷｬｯｼｭ

>>194不等号まちがったｗ
×だから（本当は）uOpsｷｬｯｼｭ≒ﾄﾚｰｽｷｬｯｼｭ
○だから（本当は）uOpsｷｬｯｼｭ≠ﾄﾚｰｽｷｬｯｼｭ

スマートキャッシュって何？

共有キャッシュのIntel流の呼び名。




たしかAthlonは、命令をL1にフェッチする際に命令長を表すビットを先頭に付加して格納する機構だったはず。
プリデコードてやつだね。
従来デコード処理の一部だったものをパイプラインの外に追い出してるという意味では案外近いのかも。

featureは特性とか特徴というニュアンスだったと思う。
某米企業の組み込み石のマニュアル翻訳したことがあったが、featureが数十箇所にわたって出てきた罠。

何かわけわかめになってるけど
「NetBurst ArchitectureのFeatureをConroeのMicroArchitectureに取り込んだというものだ」
ってのは，Conroeのμアーキをベースにして熱湯の特徴を付け加えたって意味だろ
で，その特徴とやらは「具体的に言えば64bit、Quad Pump Bus(P6バス)、VT、LaGrande Technologyなどだ」ってことで
これは（今の）熱湯アーキの特徴ではあるが，言ってしまえば枝葉でしかない

featureって日本語には訳せない単語だよな。
英和辞典に載ってる意味は本当の意味とかなりずれてるのが多いと思う。
"特長となる機能"みたいなニュアンスかねぇ。
VTや64bitはおまけ機能だからそれを引きついでもネトバベースとは言えないな。
まぁ、ここまで変わっちゃうとフルスクラッチと言っていいでしょう。
フルスクラッチと言うと、全部新設計ではないとかいちゃもんつける奴がいるが、
今時過去の資産使わないで回路設計することなんてまずないし。

リッチなMicrocode層で柔軟に対応可能、と言うNetBurstの特徴が引き継がれているのかなぁ?

>フルスクラッチと言うと、全部新設計ではないとかいちゃもんつける奴がいるが、
>今時過去の資産使わないで回路設計することなんてまずないし。
昼間に一人出没してたご様子ですよ。

>>201
Netburstの特徴を引き継ぐと言っていたから、Microcodeを利用した柔軟な拡張性は引き継ぐと思う。

>>179
倍速ALUと4命令並列はどっちが良いのかね？

>>203
そりゃもちろん、消えてなくならない方さ

辞書なんか引くよりも、生きた用例を参考にしる。

コンピュータ業界でfeatureといったら、
機能一覧に書かれる項目のようなことだ。

具体的に言えば、
・64ビット
・Quad Pump Bus
・VT
・LaGrande Technology
だと、その後で言ってるでしょ。

それにさ、
○○をConroeのMicroArchitectureに取り込んだ
という文章になっているのに、
NetBurstのマイクロアーキテクチャベースだなんて受け取るのは、日本語すら読めないと・・・。

>>205いい事言った
そもそも散々ゴトーｻﾝとかが前からPenMの発展型ﾏｲｸﾛｱｰｷって言ってるのになんでネトバベースって思うかが分からん

>>201,202
http://pc.watch.impress.co.jp/docs/2004/0310/kaigai072.htm
後藤記事で考察してるんだけど、
NetBurstの柔軟性は、Richなデコード層とそれを支援するトレースキャッシュ
によるものなんだけど、Meromでは設計思想から違うよね。
別にNetburstのVT,LT,EM64TというFeatureはAMDの実装もあるように、Netburst
じゃなきゃ実現できないものじゃない。Netburstのほうが容易だろうけれど。
ただ、Yonahに対して改良した大きい部分は、それらに対応するためにデコード層を
多少高機能にしたことかもしれない。

Meromにはトレースキャッシュが採用されてないってこと?
"個人的"にはトレースキャッシュ neary equal Netburst なんだけど。

4issueの実行ユニットを埋める為にはデコーダーも相当頑張らないといけない筈で、
今でさえCPUの中で一番のhot spotはデコーダーだというし、
トレースキャッシュがあれば、デコーダー休ませられるぶん消費電力&熱的に有利では?
将来的に取り入れるであろうParrotを重要だとお偉いさんも発言してるし。
parrotとトレースキャッシュについてはこちら、ちょと古いけど。
http://pc.watch.impress.co.jp/docs/2004/1108/kaigai132.htm

トレースキャッシュなんざー、特徴でも何でもねーよ、とか
PentiumMは既にトレースキャッシュ採用してんだよﾊﾞｰﾔ(確か詳細がはっきりとは発表されてないはず)
というのなら俺が馬鹿だったので聞かなかったことにしてくださぃ。

ごめん、nearlyﾀﾞﾀｰﾖ…orz

トレースキャッシュは積んでないだろう（はず）だけど、そこを明示した記事あるのかな？
大原あたりがきちんと聞いてればよかったのだけど。

>>208
個人的には NetBurst の特徴はなんと言っても、
クロック最重視で、徹底的に細分化した長いパイプライン
なので、これがない限り NetBurst とは言えないな。

トレースキャッシュなんてのは機能の一つで、どういう
マイクロアーキテクチャにだって載せられるものでしょ。
それに、本当に NetBurst 系のマイクロアーキテクチャ
なら、HyperThreading をサポートしない理由がない。
(俺は単純に HyperThreading を載せている時間がなかった
のでサポートしてないんだと考えている。)

全体設計は PenM ベースで、そこに NetBurst から
いくつか機能を持ってきたってところでしょ。

>>211
現時点ではそれが有力だよね。
ただ、舵切ったらなりふりかまわず執拗に、って体質だからかなーり細部まで手を加えてBaniasから出発してても、似つかない実装になってる気もする。
P6コア→Baniasの跳躍みたいに。

○ Timna（Katmai+i810）→Banias+i85xの躍進

4issueを従来型アーキで実現するのは、デコーダを増やすしかなく、
ダイナミックスケジューリングも複雑になり、消費電力等の問題から現状困難。
したがって、トレースキャツシュを採用するのはほぼ確定。
で、μOPのデータ構造はBanias流。

これでいいじゃん。

ネットバーストはμOPsを結合する機構はなかったので、新機能になりうる。

>>212
確かにどっちにしても最終的にでてくるのは似ても似つかない実装になってそうではあるね

トレースキャッシュつかってるかなぁ？
大原のインタビュー見るとデコーダ増やしてるみたいだしそうは思えないのだが

Q: Executionが4 issueということは、Decoderも4 issueという理解でよいですか?

A: その通りだ。ただ、これは標準的(Standard)な実行の例だ。たとえばメモリの
ロード/ストアはより多くの時間が掛かる。標準的な命令なら、Decode /
Execute / Retirementを4 issueで実行できる。

Q: ところでそのissueですが、ここで言っているのはMicroOpsを4 issueで実行
できるという意味でしょうか? それともx86命令を4 issueで実行できるという意味でしょうか?

A: これ以上の詳細は話すことができないが、ただ前の世代のアーキテクチャでは
条件がよければ3つのx86命令をMicroOpsに変換して同時に実行する事ができた。
私に言えるのはここまでだ(笑)。

Whitefield、CSI に問題ありで半年遅延。2007H2?

ttp://www.theinquirer.net/?article=25887
Intel needs this interconnect yesterday, and
each day of delay will hurt. Even if it ends
up being a little less than optimal, it is a
lot better than the current bus.
とまで言われてるし… orz

Meromがトレースキャッシュだったとして、
Cステイト管理で片側CPU Sleep時のスヌーピングは如何するんだろね？
Yonahと同じ様にL2に退避？

>>216
そう、それでは単にデコーダ増やしてるということが読み取れるだけで。
消費電力の観点からは、デコーダのパイプライン段数はそれほど増やせないし、
そうすると、わざわざ（イスラエル部隊が）トレースキャッシュ導入する必要性は感じられない。
Yonahも積んで無いし。

トレースキャッシュは確かにデコーダ数をけちることもできるが、リフィルの高速性を考えるなら4ユニットあったほうがいい。


トレースキャツシュの省電力効果は、デコーダの数を減らせることよりも、眠らせることができることのほうが大きい。

トレースキャッシュにしっかり収まっていればデコーダが稼働しなくていいから
パイプライン段数はあんま関係ない気がするが。

それよりデコーダを休ませることができない従来型で、更にユニット数を増やせば消費電力面で不利だな。
スケジューリングも困難だし。

デコーダ4本を2コアで共有、トレースキャッシュ付きとか

Meromが出たあと、藁やPenDみたいに言われませんように。

WhiteFieldといえばネコミミの元祖綿の国星

Merom/Conroe/Woodcrestの製品ラインナップだが、Photo11の様な形になっている。
Mobileは単一構成で、おそらくは4MBキャッシュのDual Core。Mobility TDP Envelopeは
おそらく30W前後(これがメインストリーム)と15W(これがLow Voltage)、それと5W前後
(これがUltra Low Voltage)になるだろう。
一方DesktopはTDPは65Wで固定だが、Photo11のダイの図を信じてMobileのサイズから
推測するならば、キャッシュは4MBと8MBの2種類。
Serverは現在のXeonが130Wのレンジに達しているから、40%削減すると78Wとなり、ほぼ
80W といったところか? こちらは2コア・8MBキャッシュのWoodcrestと、4コア・32MB(!)
キャッシュのWhitefieldという構成になる。
80Wのレンジはおそらく4コアのWhitefieldに適用されるものになるだろう。
http://pcweb.mycom.co.jp/articles/2005/08/31/idf1/001.html

>>225
あんたの予想だいたい当たってるじゃん
モバイルは35Wサーバーは80Wちなみに動作周波数は2.93ね

Q: ではパイプラインの構造はMicroArchitectureですか? それともImplementationですか?
A: Implementationだ。
Q: ということは、たとえばMeromとConroeではパイプラインの構造が異なる可能性があるわけですか?
A: 悪いがそれには答えられない。

へぇー

>>227
塀

>227
それってパイプラインがどうであろうとそれはMicro Architectureじゃないですよ、ってことなん?
NetBurstでもパイプライン段数の変化があったわけだし、
開発はそれに関してはMicro Architectureじゃないと捉えてるのかな。
じゃぁ、NetBurstのMicro Architectureって何さ。

>>229
Q: ここで言うMicroArchitectureとは何をさしていますか?
A: それはMachine Implementationだ。x86準拠というのがArchitectureであり、
MicroArchitectureはそれをどうインプリメントするかというものだ。
製品はMicroArchitectureによってDriveされる。例を挙げよう。
MicroArchitectureはパイプラインの数とか深さといったベーシックになるものだ。


1つ上の問答

つまり通常言われる「アーキテクチャ」というのはIntelの言うところの
MicroArchitectureということですか？

てか、>>227に引用している質問自体がおかしいだろ。
陰照がMicroArchitectureとはImplementationの事だと
言ってるのに、「パイプラインの構造はMicroArchi
tectureですか? それともImplementationですか」
という質問は、どっちも同じ事を聞いてる。

>>232
"Machine Implementation"とただの"Implementation"はまた違うってとったのかな？

たるさんも更新キテるもより

深さはMicroArchitecture
構造はImplementation
だろ

>>231
もともと、CPU関係でアーキテクチャっていったら、命令セット
アーキテクチャ、すなわち命令セットの仕様のことを指すのよ。
従って、この意味だと、IntelもAMDもアーキテクチャは同じに
なるわけ。まあ3DNowとか微妙な違いはあるが。
最近、マイクロアーキテクチャのことをアーキテクチャと書く
誤用が増えてるだけ。

>>235
うーん、俺は>>232と同感。

http://pc.watch.impress.co.jp/docs/2004/1109/kaigai133.htm
ここではPentiumMの先にPARROTがある、とされている。
http://pc.watch.impress.co.jp/docs/2004/1108/kaigai132.htm
イスラエルの研究チームが発表したPARROT論文には
トレースキャッシュ前提で内容解説されている。
(記事には、Pentium 4よりもずっとスマートなトレース選択機構によって、より効率のいいトレースキャッシュを実現するようだ、と有り。)

辺りから次(Merom Conroe)にはトレースキャッシュ採用、と夢想してたんだけど。

>>237
Merom世代だとPARROTは実現までは間に合わないような気がするざんす。

PARROT実装はともかく、より効率のいいトレースキャッシュとやらは入れとく価値ありと思ったんだけど。
デコーダーの消費電力と熱の問題方面で。
http://pcweb.mycom.co.jp/articles/2005/08/31/idf1/003.html
ここではMeromのアーキティクチャで10年ｶﾞﾝｶﾞﾙって言ってるんだよなぁ。
PARROT、10年後か、期待した俺ｶﾜｲｿｽ

>>238
PARROT＝トレースキャッシュじゃありませんよ？

http://pc.watch.impress.co.jp/docs/2004/1109/kaigai02.jpg
この図を見るからには、N（Merom like）はトレースキャッシュ無しな気が。

http://www.itmedia.co.jp/news/articles/0508/29/news008.html
＞「Pentium IIIに対するBaniasの進化に対してDothanが同程度進化
＞しているとすると、DothanからYonahへの進化はその数倍もの大きな
＞差があります。YonahからMeromの進化も決して小さくはありませんが、
＞DothanからYonahへの変化ほど大きなものではありません」
エデン氏の言葉からすると、トレースキャッシュを導入する程の変化はないように感じられる。

http://pc.watch.impress.co.jp/docs/2005/0826/kaigai207_08l.gif
後藤ちゃんのロードマップではデスクトップ・ノートの未来が埋まっていない。
ただPARROTが導入されるであろうMeromの次は枠だけ画いてある。

いずれにしてもまだIntelはリークできる段階にない。
ということはPARROTを実装するのはまだまだ道が遠い状態。
特にトレースセレクタ/フィルタ/ビルダ（ホットコードを選別しトレース構築）や
トレースオプティマイザ（バックグラウンドでのコード最適化）の部分が大変そうだ。

Merom の次は、Whitefield と同様、メモリコントローラ内蔵に
なるんだろうけど、それを今言うわけにはイカンということでは？

>>242
PARROT自体がアーキテクチャじゃないの？

>>243
今言うわけにはイカンというか、おそらくメモリインターフェースのシリアル化をしたいのであろうが
その規格もどうなるか不透明なので明かせないというか

やるならFB-DIMMからじゃね

鯖はそうなるだろうが、コンシューマ機には
FB-DIMMのような冗長性は不要っしょ。
FB-DIMMはRegistered DIMMの代わりになるように
考案されたソリューションだから。

＞このアーキテクチャではおそらくシングルコア分の性能向上は(PARROTを除けば)
＞今回世代限りで飽和するだろうと思う。

PARROTの見通しが立たないようだと2003Q3以降のNetburstの惨状・・・・
以上の停滞をMeromアーキテクチャが見舞うことになってしまう。
メモコン統合等、他の手を準備しているのかどうか心配だ。

次々世代だとされているPARROTアーキテクチャはおそらく、アーキテクチャ（処理手法)としての検証段階で、シリコンへの実装研究はまだか始まったばかりだと思う。
これはまた、選択肢の一つに過ぎず、違う選択になるかもしれない。有力候補の１つという位置づけだと思う。

IntelにしてみればAMDに対して同等か、多少上回っていれば乗り切れると判断するだろうから、Banias延長のYonahでそれが実現可能だと程度目処がついて、2008年頃登場のPARROTかもしれないCPUに繋げる心積もりでしょう。
ただ、PARROTが既に既定路線かもしれないので、それを実装するのに足がかりになる構造を持っている可能性くらいはあるかもしれない。

結局どうなるかはわからんって事でしょ

INTELCPUにはいったいいつになったらメモコンがのるんだ？
PARROTからか？

>>251
K8と同時にやらなかったのだから、シリアル化まで待つのが定石だろう。
だいぶ先だよ。

>>252
シリアル化って2008とか？

>>253
45nmになってから。

デコーダが電力を食うなら、複雑なデコーダを使うのをやめりゃいいじゃん。
つまりx86の命令セットをネイティブに実行するのをやめればいい。

それから、メニーコア時代になれば、メモリアクセスの帯域がネックになる。
ネックになるのが悪いことじゃなくて、ネックになるまでコアを詰め込むべき。
そうすると、各コアではメモリアクセス待ちが多発するだろうから、
パイプラインがスカスカでストールしまくっても構わないと思う。

>>255
ごめん、言いたい事がワカラン

前半は
IA-64 + IA-32EL
TransmetaのCMS
Alpha + FX!32
色々な実装例はあるけど、そういう方向に行くべきだと。

後半は
VIAのWinchip系の、絶対性能は低いがトランジスタ数の割には性能のよいコアを、たくさん詰め込めと。
1割の速度向上のためにトランジスタを1割以上増やすな、と。

>>257
すまん、アホにしか見えん

>>257
まぁ、今までの例からいってソフトは所詮エミュだお。
どんなに頑張っても、ハードで実現出きるような
満足なパフォーマンスが得られるとは思えん。

>>257
その三例、どれもこれもパフォーマンスに難有り。
スジのいい技術とは思えん。
そういう方向に未来は無さそうだが。

インテルって65nm世代って順調？

>>261
結局、現物が出てみないと何とも言えんよ。
取り敢えず、Yonahは順調で１ヵ月程繰り上がって、
１月早々CES(5〜8日）で発表されるとか。

今年のNaPaプラットフォームもCESじゃなかった？
そう考えるとMEROMの時期が難しくないか？
第3四半期って事はIDFの直後辺りに発表かな？

まぁ、舞台に拘るならIDF falｌかWPC EXPOとかが時期的に近いんでないかい。

>>264
IDFFall自体でか・・・
前にもIDFで新製品発表ってあった？

いや、知らんけどね。
よく考えたら今までも決まって特に何かのイベントで
製品発表してたわけでもない気がするし。

まぁな

>>264
今までの例だと、PenDとかでは決算発表前だったな

>>268
じゃあConroeの発表は第3四半期の決算発表前って事で

http://pc.watch.impress.co.jp/docs/2005/0906/kaigai209.htm
↑来たよ後藤さん
「機能拡張の割に小さいYonahのコア」

ttp://techreport.com/etc/2005q3/idf/index.x?pg=4
このMitosis見ると、IntelはもうSMTよりCMTで
性能向上する方向に向いてそうだな。

>>271
どゆこと？

.anandtech.com/cpuchipsets/showdoc.aspx?i=2492
↑ここの2ページ目にトレースキャッシュのことが書いてあるけどConroeに採用するってこと？
あと3ページ目の一番最後に
アムドのK9と同じくらいかそれ以上みたいなことが書いてある(Conroe)

http://www.powup.jp/jinken/leaflet/A3_v1.0_OMO.jpg
http://www.powup.jp/jinken/leaflet/A3_v1.0_URA.jpg

自民も推進みたいなもんじゃねーの

スレ違い

>>271
ttp://www.sun.com/processors/throughput/faqs.html#5

>>273 藻前リーディング力無さ杉　これなら中学生でも読めるはず
trace cache の話は Netburst の説明（この頁の3/4はこれまでの Intel の
アーキテクチャの解説で肝心の結論は「まだ良く分からん」ｗ）
3頁目の K9 と Conroe の比較は現時点で分かってる情報
>but we know even less about K9 than we do about Conroe.

あれ？
アムドのK9って消えたんじゃなかったっけ？

K9が何だったのかさえ明かされていないので
結局何がどう変わったのかは不明

まぁアムドが次に何を出すか分からんからとりあえずConroeで逆転ってことだ

>>281
そう甘くないかとorz

intelの場合はI/Oが従来型な分、
それだけでも大きなヘッドルームが残されてるからね。
そもそもk7からk8の性能向上分はほとんどメモコン統合だし。

てか、intelがWhitefieldでメモコン統合とシリアルバス実装してきたら、
AMDのアドバンテ−ジ無くなるな・・・

http://pcweb.mycom.co.jp/photo/articles/2005/09/06/siggraph2/images/038l.jpg
算術計算ベンチマークをBrookベースでPentium 4 3.0GHzとGeForce 7800 GTXで実行したときのパフォーマンス比較。
その差はかなり大きい

時代はGPGPUか

メモコン至上主義者やたらと多いな。
K7→K8の性能向上は、アーキテクチャの改良とクロック上昇分が主であって、
メモコン統合の効果は"？"だろ。

K7からK8になって、クロックは下がったぞ。

>>286
同一MNならばな。
豚：1.66GHz〜2.2GHz
濱：1.6GHz〜2.4GHz

アホ？

同一モデルナンバーでは、クロックが下がった
つまり
同じクロックでは、性能が上がった

性能向上は、クロック上昇によるものではない、ってことだね。
K7よりも高い周波数で動くものがK8にあるのは、より新しい技術で作っているからだよね。

>>289
それもあるだろうけど
K7がK8より高クロックになったらマズイっていうマーケティングの都合もあるんじゃない
PenMのクロックが止まってるのもそれだろうし

PenMはTDPの問題だろう

整数演算の小さなﾌﾟﾛｸﾞﾗﾑだと同周波数でK7の方がいい場合があったような

>>290
何のためのモデルナンバーだ。
それにK8が出た当初はK7の方がクロックが高かった。

>>293
3400+(2.2GHz)って、後出しだっけ？
3000+(2GHz L2 512KB)は後で出たと記憶しているが。

FX-51(2.2GHz)が同時。3400+(2.2GHz)は後だな。
何れにせよ>>293＝アフォ

>>295
ウルセーばか。290よりはマシだw
どっちにしろマーケティングの都合は関係ない。

おまいらここはアムドのスレじゃないでちゅよ

最初に出荷開始をアナウンスしたK8は、
Opteron 244(1.8GHz)、242(1.6GHz)、240(1.4GHz)で、
それは2003/4/22のこと。

一方、K7で最高クロックとなるのは、
AthlonXP 2800+(Thoroughbred 2.25GHz)で、
それは2002/10/1発表

ちなみに、
AthlonMP 2600+(2.133GHz)は2003/2/4発表
AthlonMP 2800+(2.133GHz)は2003/5/6発表
AthlonXP 3200+(2.2GHz)は2003/5/13発表

アフォ度
XP(64)とMP(♪)を比べる298＞|越えられない壁|＞293

ところで、皿2800+(2.25GHz)って実際に販売されたっけ？

さてあんたらに問題です
ここは何のスレでしょうか

アッーー！！

まぁRx028TQeもアフォだったということで。

>>299
K7 vs K8でクロックの話をしているのに、
XPとMP、64とOpteronの違いを持ち出すほうが、アホだと思うが。

>>301
すまんかった。
ついカッとなってやった。
今は反省している。

>>304
別にいいっすよ
それにしてもYonahはまたびみょーな時期にでるな
EM64Tに対応してたら買うかもしれなかったが・・・

別にいいんじゃないの。
性能インパクト的には Dualcore＞64bit だろうから。
メーカ的にも春夏商戦Yonah、秋冬商戦Merom（Vista）で逝けるし。

K8の時もそうだったけど、実際手にとってみないと判らないこの
待たされドキドキ感がいいよね。

まぁTDPがさがるからConroeを待つとするか

CPU内に調停回路とやらがあればFSB半分にならずに済むの？

１本はどんなに頑張っても２本にはならない

>>309
何の話？Paxvilleの事？

特定の製品でなくて一般的な話では。

CPU内に調停回路を持つ場合、コア間の通信は、CPU内で高速に行なえるが、
CPU内に調停回路を持たない場合だと、低速のFSBを経由して、
ノースブリッジが其々のコアとFSBを介して調停をし、通信する事になる。

>>311
ヨナとかコンロの話

わざわざ調停してるって事は一つのバスにぶら下がってるって事だから
結局時分割で通信するしかないような。

調停回路無い代わりに共有キャッシュだった

>>315
確かに･･

素人臭い質問でスマンが、共有キャッシュというのは
２つのCPUから同時にアクセスされても応えられるものなのか？
それとも片方は順番待ちになるのか？

>>317
IDFの記事くらい目をとうそうよ〜

>>317
お前IDFの記事見てないのか？

conroe期待してもいいですか？
ウィラメット、プレスコットのように
前より性能が低いことはないですか？

プレスコ以下なんか絶対ありえん

>>321
炭

>>322
炭はプレスコが二人羽織してるだけだろうが。

>>323
同意

ユニバーサルバイナリに興味があって、いまさらMac-mini買ってみたけど、
今日公開されたAltiVec→SSE移植のドキュメントによれば
EM64TのIA32eモード（AMD流にいえばLONGモード）でFP/MMX使うかどうかすらまだ未定らしいね。

Win64ではOSがFPU/MMXレジスタを保存しないとのうわさ
もしそうなら、FPU/MMXをつかうのは事実上無理

FPU/MMXを使うメリットって何？
SSE2/3の方が性能出るんだろ？

ヒント：懐古厨

>>328
何それ？

Windows限定で言えば、VCなどのMSの言語を使用する限り
ランタイムは80bit精度の演算をしないからFPU不要。
でもいいのかなぁって感じ。

　　　 In＿�п@ ／￣￣￣￣
　 In（　｀∀´）＜　あげ
　（´⊂ 　炭　⊃ ＼＿＿＿＿
　（　つ　ノ ノ
　｜（_＿）＿）
　（_＿）＿）

あぁ確かにそうでつね

>>327
現行Pentium Mでは逆。
１２８ビットのSIMD演算ユニットの半分をマスクして利用っていう実装なら
文句なしにSSE2/3だが
実際には２つの64bitSIMDユニットを使った演算に展開してるというのは
知ってるでしょ。

Yonahでは解消するといわれている（らしい）問題だけど。

まあ、Pentium 4ですらmovq×２回＞movdquだし、使い場所を選ぶ。
たとえば下位QWORDしか使わない場面でMMXユニット２個使うのは
結構無駄じゃん。
MMX演算ユニットが１２８ビット演算ユニットの下位QWORDマスク
みたいな贅沢な実装にならない限り、２個１実装である限りは、
部分的にでもMMXを使ったほうが速いケースは出てくるのですよ。

Appleが使う時点でのEM64Tの実装がFP／MMXが８本かどうかも疑問だしね。
いちおう命令セット的に１６本に拡張してもx64との互換性は保てると思われ。

>>333
ありえん

つかMMとXMMは排他じゃないんで。
同時に使えるし相互にデータ交換する命令もある。
浮動小数をXMMで使いながらMMX使うことだってできる。
ちなみにMSのPSDK2003ではたしかに使えないがVS2005ではMMXがそのまま使える。

なんにせよ使えないより使えた方がいいに決まっているだろ。
すくなくともMeromまではSIMD ALUは128ビット化されないし。
そうなれば2個の演算ユニットに別々の命令を行わせることができたほうがいい。

IntelやAMDにとってx87や同じレジスタを利用しているMMXは将来を
考えた時に邪魔な存在と判断された。

近視的思考は止めたら？

>>336
CPU自体は問題なくx87/MMXを使えるよ
IntelとAMDは全く関係無い
純粋にMSのWin64の実装の問題

>>337
そんな当たり前の事を自慢げに話されてもなぁ・・・
EM64TやAMD64が普及して32bitがLegacyとなればx87やMMXの
ロジックを手抜きできる。手抜きした分はSSE?に使えば全体として
happyになれる可能性が高い。
特にx86系はデコーダが苦しいとされるのでその効果は馬鹿に
できないと思われ。

>>336
セグメントレジスタは？　リアルモードは？　仮想386モードは？

スマン
自演の邪魔でもしてしまったか

>>339
お前馬鹿だろう。

セグメントレジスタ -> セグメントセレクタとしてまだ使われている
リアルモード -> 過去互換性の為必要
仮想386モード -> 仮想86モードの事か？www

64bit native modeでx87とMMXをサポートしない事は互換性を必要と
しないからだという事が理解できていないな。

>>341
（>>326の噂が本当なら）MSが必要としてないのは分かるが、
どのレスをどう読むとIntelやAMDが必要としないと読めるんだ？

ああ、>>336や>>341も必要としてないのは分かってる。
ついでに言えば漏れもいらんけどな。

>>342
> （>>326の噂が本当なら）
確認してみればいいじゃないか。簡単なプログラムを書けばできるぞ。

> どのレスをどう読むとIntelやAMDが必要としないと読めるんだ？
MSが全て悪いみたいな馬鹿な事を書いたから違うと書いたのですが？

>>343
それは
「IntelやAMDが必要としていないから、MSもあえて互換性を取らなかった」
といいたいの？　そう思うソースある？　ウスターとかトンカツ以外の。

>>344
仕様書よく読んでから出直してね。

FSBが1066Mhzになるのはいつ？

>>346
おそらくConroe

>>326
ｱﾌｫか。普通にありえん。
互換性とプログラムの柔軟性をを無視して
たかだか64bit8本だかのレジスタ保存のオーバーヘッドごときを気にするとは思えない。
釣られすぎです。

簡単なアセンブラでテストできるから
64bitの開発環境があるひとはテストキボン

>簡単なアセンブラでテストできるから

ここは笑うべきところかｗ

>>349
笑いどころの分からない漏れはイケテナイのだろうか。

FPUレジスタの内容をダンプするプログラムと、
FPUレジスタの内容を変更しまくるプログラムを、
同時に走らせれば一目瞭然。実に簡単。

もっとも、漏れの周りには64bit Windowsがないので、
そういう意味では非情に難しいテストではある。

2つのプログラムを同時に起動し、
それぞれがFPUスタック、もしくはmmレジスタに
値の違うデータを書き込んでみて、読み取って
それが書き込んだものと一致するか確認すればいい。

movq mm1, [eax]
//ここになにかウェイトをおく。
movq [eax] , mm1

これだけ。

上のプログラムでは上書きしてるとか比較してないとか
レジスタの値がどうのこうのとか、いろいろあるだろうけど、
まあ、その辺はｷﾆｼﾅｲでｸﾚ。

ttp://slashdot.jp/comments.pl?sid=252134&cid=726749

アホか！！！
x86 64bitでのRegisterCallについてのドキュメンテーションじゃないか。

x86 32bitのstdcall規約の関数はどうなってると思う？
eaxは関数の結果のリターンに使われる。
edx,ecxは呼び出した関数が適当に変更するので、戻ったときの値は不定である。
ebxその他のレジスタは関数呼び出しの前後で値は変更されないことを保障する。

それだけのことじゃないか。
プロセスレベル、スレッドレベルでのレジスタの保存くらいはやってるだろ。

もまえら、岩波書店や共立出版のカーネル設計の本よめよ。
TSSがなんたるかぐぐれ。

カーネルモード限定の話っぽいな。

>>348 80ビット

>>351
64bitで[eax]かよ。

>>356
32bitでもkernel modeでFP,MMXを使用する場合のレジスタ退避は必要ですよ。
DDKのdocumentぐらい読んでね。

まぁ、結論から言えばuser mode programのFP,MMXレジスタの退避はする。
ただしwebにある過去の情報から考えるとリリース前のバージョンでは退避し
ていなかったモノがありそう。ml64でもこんなメッセージを出すし。
x87 and MMX instructions disallowed; legacy FP state not saved in Win64

>>358
x64でもポインタじゃないかぎり、汎用整数値はDWORD推奨だけどね。

>>359
eaxと書かずに[eax]と書いた理由がわからないんだね。www

なんか変なビパーがいるな

逆に
movq mm0, eax

が通るとでも思ってるのだろうか。

>>361
64bitなら
movq mm0,[eax]
じゃなくて
movq mm0,[rax]
だと指摘した後に
movq mm0,eax
が通ると思っている？
と質問する馬鹿がいる事に驚いた。

32bitのコードとはことわってなかったわけで
movq mm1,[eax]
は32bitでは正しいコードだし、まがりなりにもXP 64bit Editionでは実行可能。

しかし>>361は32bit用でも64bit用でも通らない。

そしてmm1がmm0にすり替わってることに気づかない馬鹿がいた

>>363
> 32bitのコードとはことわってなかったわけで
そりゃそうだwww
64bitの話をしているんだからwww

スレ読み直してこいや

>>363
(・∀・)ﾆﾔﾆﾔ

すぐID変えるのやめようね。

>>z8EmdPn0痛すぎる。

>>366
好きでID変えているわけじゃないんだが・・・

まぁ、少なくとも俺の他に2人いるぞ。
信じたくないだろうけどなwww

>>z8EmdPn0
自分の愚かさに気付け

ひょっとして録音か？

>>368
自己レス
俺が他に2人いると思ったが、その2人が同一人物である可能性は否定できなかったな。

コードとかプログラムとかさっぱりわからないのでCPUの話しようよ。

プログラムにバグなんかあるわけないだろ。
ＣＰＵじゃあるまいし。

ここ次世代CPUスレだよな？

>>372
CPUとプログラムが・・・

http://www.digitimes.com/mobos/a20050908A2004.html
Yonah,CedarMill,Preslerは揃って1月の登場になりそうだと。

>>375乙

>>375
スレ関係無いけど、Fab36が10月から量産か…

次世代語る前に今の世代のCPU勉強したほうが。

CedarMillってTejasの生き残りだっけ？
SSE4あったりするの？

>>378
お前スレタイ読めるか？
>>379
多分違うかと

次世代っていつ頃の話だ？
vistaが出たらPCを買い換えようと思うけどその時は次世代CPUになってる？

Merom、Conroeが出ている。

>>379
本来はTejasの65nm Versionだったけど、Tejasキャンセルにより、
Prescottの65nm Versionに変更された。

CEDEC2005 - デュアルコアプロセッサのためのマルチスレッド対応ゲームの開発事例
ttp://pcweb.mycom.co.jp/articles/2005/09/10/cedec1/

だそうだ

>>380
現代の計算機も判ってない香具師が次世代を語るのはいかがなものかと思ったけれど
それはそれで面白いな。

本当に"わかってる"奴なんて一握りだろうに…
いかがなものか、なんて言えちゃう位だろうからわかってる人なんだろうけど。

じゃあＣＰＵの勉強はどこですればいいですか？

まずOSの勉強をすれ。OSを知らんとIRQもMMUも本質的に理解できない。
岩波と共立出版だな。

つ［4-8222-8056-X]

Tejasって4つCPUが見えるHTだったっけ？
SSE4はまだ残っているんだろうか。
conroeに搭載されたりして。

>>390
CONROEは可能性あるな

Paper: Intel buys entry-level chipsets from ATI
ttp://www.digitimes.com/mobos/a20050912PR207.html
Intel may purchase a combined volume of 1.5 million chipsets from ATI and SiS per month,
with shipments to start in October this year, the paper said

Server and Workstation Roadmap
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2528&p=3

Intel prepares to roll out 65 nano Pentium 4s
ttp://www.theinquirer.net/?article=26071

Intel prices up Yonah microprocessors
ttp://www.theinquirer.net/?article=26062

Yonahは1月6日らしいな。

ttp://arena.nikkeibp.co.jp/winpc/col/02/map_intel.shtml
>IntelはデュアルコアCPUロードマップを積極的に展開する一方、
>次期Pentium 4 6xxシリーズとして開発している「Cedar Mill」（シダーミル：開発コード名）は、
>ハードウエアバーチャルマシン機能の「Virtualization Technology（VT）」を動作させないことにした。

どうやらCedar MillはVT、disableにするらしいね。

preslerはどうなるんだろう。
CederMill二つだからやはりdisable?

記事読めば「デュアルコアCPUのみを高性能化するようだ」と書いてあるんだからさ
普通はenableだと考えないか？

ごめん、記事読んでなかったよ。

http://pc.watch.impress.co.jp/docs/2005/0913/ubiq124.htm
YonahをスリムデスクトップPC向け市場に投入へ
Intelは同じ第1四半期にハイエンド向けだけでなく、新しいプラットフォームとしてスリムPC向けの製品ラインを投入する。
具体的には、YonahをデスクトップPC市場へと投入する。

>Banias系コアの流れをくむConroeは3GHz台の動作周波数で駆動され、
>4MB/2MBのL2キャッシュを備えるモデルが用意されるという。
>また、「Merom New Instruction(MNI)」と呼ばれる新しい命令セットも追加される予定で、
>主にメディアファイル処理時の性能が大幅に向上することになるという。

SSE4もあるみたいだな。

merom、conroe世代のセロリンについては、何かアナウンスされてる?

>401
いや
と言うか
ペンティアムブランドで出すかすら分からない

>>400
どこの引用？

記事読もうぜ

携帯だから記事読めない

>>400
テハスのそのままメロンに使っていたら受けるな。
今度は何個くらい追加されるんだろう？

　　　　　　　　　　　　In＿�� 　　
　　　　　　　　　　 |||（｀Д´#）　読めない
　　　　　　　　　　 ○　プ ⊂)
　　　　　　　　 ／旦／三／／|
　　　　　　　　|￣￣￣￣￣| .

全スレ1000です。
外注の方まだ見てるかな？
ギャラクシー出ましたね。Opteron　8wayも出る予定ですね。
コメントほしいなｗ

Intel 975X chipset to support Nvidia’s SLI and ATI’s CrossFire
ttp://www.digitimes.com/mobos/a20050913A4012.html
Intel has reached a licensing agreement with both Nvidia and ATI
that will allow Intel users access to drivers to enable SLI or CrossFire, the sources noted.

>408
粘着やめろ。
殆ど関係ない話でスレ潰した関係者は氏ね

>>410
お前の脳内じゃメモリインタフェースのトポロジがCPUに関係無い話なのか？

>お前の脳内じゃメモリインタフェースのトポロジがCPUに関係無い話なのか？
でもopteronは"intel"製 CPUじゃないですから。

>>412
確かに

おそらくintelはCPUの一般名詞なんだよ

>>395
INTELの説明では、Pen4 6x1シリーズでVTをディセーブルにするのは、消費電力を抑えるため。
と、WinPCの本間文の記事には書いてた。

>>412
メモコン内蔵のメリット・デメリットの話だろ。
Opteronが既にメモコン内蔵を採用しているってだけ。

そんな狭い視野じゃ次世代の話なんで無理だな。www

>>416が広い視野を披露してくれるそうです

>>417
なんでシングルコアでVT disableする予定になったと思う？

>>418
なんで？

FSBもうあがらんのんかのう？

>>418
シングルコアだとコンテクスト切り替えが必要になるからだろ。
プロセッサが各々独立して動く必要がある。

別に関係ないと思うよ。
機能の有効・無効で差別化して売るのはいつものIntelの常套手段だから。

>>422
同意
性能が落ちるなら落ちるで全然構わない
デュアルコアに誘導するネタにできるから
コンテクスト切り替えなんてシングルコアでもやってるわけで

広い視野まだ?(´・ω・`)

既にVMwareやVirtual PC/ServerがあるのにVTで何が変わる？

>>425
おまいVMwareやVirtualPC使った事無いだろ、
てかVTの解説記事とかも読んでないだろ。

>>426
それで何が変わるんだ？

ソフトウェアエミュとハードウェアエミュの差による性能差。

>>428
速くなるのか？

そりゃ、各仮想マシンをハードウェアで管理支援する事になるからね。

>>430
残念！
VMware社は従来のdirect execution and binary translation方式とVT-xで
どちらか一方が性能的に有利とは決まらないといっている。

>>431
ttp://www.vmware.com/news/press/ibd_1.html
オーバーヘッドを縮小するって言ってるが。

>>432
俺が見たソースはIDFの資料だ。
参加した人から貰ったんだけど勝手にupできんし・・・
実際はwebから簡単なpasswordで入手可能だから探してくれ。

セッション名はEnterprise Virtualization for Intel Platforms
資料22ページだ。

仮想化技術で何ができるんですか？

俺がIDFでMSのヤツから聞いた話は
XenとVTｵﾝのPen4で、260%速くなるって聞いたかな
AMDのは(´ー`)ﾁﾗﾈｰﾖといっていた

ちなみに口伝のみなので、資料などはない

Xenはuser/kernelがring3/1だからね。
VMwareのring3/3とは事情が違うよ。

AMDとintel仮想化技術に関して
互換性がないらしいけど、
どっちが勝つとおもう？
SSEのようにintelが勝つのかな？
3Dnowってまだ使われているんだっけ？

穴があるとか性能とかそんなの関係無しにMSが対応すれば生き残る
VTが生き残るのは>>435読むと確定のように思える
AMDのも対応するなら生き残るだろう

穴や性能に関してはVTの将来バージョンで解決されるでしょう。

どっちが性能がいいかは分からんけど
少なくともｱﾑﾄﾞはまだ「パシフィカ？」ができてなく
VPはできている(というか実装済み)
よって今のところインテル有利

AMDのPacificaの仕様は、VTより先に公開されてるじゃなかったっけ？

>>441
でもまだ向こうは実装すらしてない

>>438
MSのアダム氏によると、VTのサポート、ならびに「Pacifica」（AMD）のサポートは、2006年末までに
出荷予定のVirtual Serverバージョンに含まれる見込みだという。
http://www.itmedia.co.jp/enterprise/articles/0508/25/news018.html

>>442
タイミングから見ると、今のAMDのOp用Egypt/Italy/Denmarkはdisableっぽいけどな
…San DiegoとVeniceは知らんが

穴って・・・デバイスのバスマスタ転送にCPUがどうやって関与しろと・・・
Intelの方針としてはチップセットにDMA remapping機能を加える予定にはなっている。

>>441
いや、普通にintelが先。今年の1月に既に仕様書公開してる。

>>444
Rev.Fからよ。

Intel invests $345 million to expand 200-mm U.S. fabs
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=SMASYZIFWO0MUQSNDBESKHA?articleID=170703488

自作板のみなさまの長年の勘からすると
Meromコアはかなり期待できるものになりそうですか？

>>449
PenMがイイから期待できる。

まぁYonahが出ればさらに予想しやすくなるんだろうけど
MeromはYonahの改良版だからね

>>450
改良版と言うより
進化版と言った方がいい

お前　国語の成績悪かっただろ。

>>449
65nmプロセスの出来次第。
現状では判断材料なし。

Intel、3億4500万ドル投じ製造能力拡大
http://www.itmedia.co.jp/news/articles/0509/16/news022.html


Merom/Conroeのﾀﾞｲｻｲｽﾞって
ｲｽﾗｴﾙﾁｰﾑのいつものｹﾁｹﾁ作戦でめちゃくちゃ小さくなるかと思ってたけど
意外とｲﾒｰｼﾞほど小さくないのかもね？

>>454
Conroeはキャッシュがデカイからねぇ
コアは小さいみたいだよ

>>454
それはチプセトのfabだね。
最近、チプセト足りなくてひーひー逝ってたからね。

>>456
金儲けが出来なくてな

イスラエルチームに過度の期待はどうかと思う
ネットバースト作ったのもP6作ったのもオレゴンチームだしね
PentimMが成功しているのはP6の素性の良さが半分くらいある

>>458
確かに期待のし過ぎは良くないと思うが
PenMはP6がベースだがあまりP6の面影を残して無いらしいぞ

・パイプラインの段数増加
・大容量省電力2次キャッシュ
・μopsフュージョン
・P4バスをベースに省電力化
・SSE2搭載

省電力にたいしてのてこ入れはかなりの修正箇所だと思うし
P6→PenMのほうがYona→Meromより変更点は多いと思う

>>460
携帯だからどこか分からんが(P6→PenM)≧(Yonah→Merom)≫(PenM→Yonah)の順で進化度が高いらしいよ

P6→PenM　フルスクラッチ
Yonah→Merom　フルスクラッチ
Dothan→Yonah　改良
Banias→Dothan　小改良
だった思うんで違いの大きさもこの順かと
メロンはまだ先だからハッキリしないけどね

メロンベースのコンロはオレゴンチームだから
改悪のキケン性もなきにしもあらず・・・

>>462
まぁ>>458の言う通り
P6を作ったのもオレゴンだけどな

改悪言っても、今度は消費電力に対しての性能比を売りにしていくんだから、
TDPがMeromより上という以上、絶対性能はConroeが上にならざるを得ないんじゃ…?
Meromのoverclockingで同じ程度の値段のConroeの性能を抜く、というのなら
改悪かもわからんが…

>>464
オレゴンだったら・・・やりかねん

　　In＿�п@　　　In＿�� 　　　　In＿�п@
　（＠ε＠)つ　（　｀∀´）つ　（Φ∀Φ）つ
　（　二つ　　　　（　二つ　　　　（　二つ
　　＼./ /、　　　　＼./ /、　　　　＼./ /、
　　　 ∪`Ｊ　　　　　 ∪`Ｊ　　　　　 ∪`Ｊ
俺達オレゴンチームの辞書に成功の文字はない！

R520みたいになったり・・

コンロは単にメロンのVth下げてVcore上げたバージョンでしょ

月刊アスキーにYonah 2GHzのベンチが載ってたぞ。
縁故もゲームもPenD840と同等以上、でもX2 4800+にはかなり及ばないみたい

>>469
ほんとかよ
ほんとだったら
意外に使えないな

>>469
ほんとだ・・・
今本屋に行ってきた
ただFSBのこととかを考えたらそう悲観する数字でも無いな

だからP6もオレゴンなんだが。
それからConroeがオレゴンなんていう情報はない。
オレゴンチーム方がイスラエルより古参なんだけどね。
NetBurst一発でどうこういってるやつは、2ch情報に洗脳されすぎだろ。

それからPenMのデコーダが今までP6とたいして変わらないということに気づけよ。

>>472
IDF関連の記事を探せば
オレゴンがConroe担当だって分かる

YonahでAMDぶっちぎるつもりだったのか・・・
ここの厨どもは

>>473
俺がP6→PenMが
大きく改良と言ったのはITメディアの記事を読んだから
細かいところまで知ってる訳では無い

ま、ConroeではあっさりAthlon64は抜かされるわけだが。

エデン氏　「いえ、そうではありません。確かにMeromはイスラエルで設計されましたが、
他のプロセッサに関しては別のチームが設計を行っています。例えばオレゴンのチームは
デュアル／マルチプロセッサの経験、サーバ向けプロセッサの経験が豊富です。
マイクロアーキテクチャは同じですが、最終的なチップのデザインは彼らが行っています」

これか。たしかにConroeはオレゴンがやっているようだ。

>Yonah
PenDをロバ呼ばわりできるだけの性能はあるのは事実か。
それに、互角以下とはいえ、ノート向けCPUでAthlon64 X2と勝負になるなら大したものだと思う。

PrescottとSmithfieldが駆逐されるのは時間の問題かな。

>>479←Yonahのピン数ww
それもあって
YonahもVIIVの対象になったんだろうな

pin数は多分従来通り478だと思うけどな。（Socket名は479だが）
と詰まらないツッコミをしてみる。

今一番気になっているのはConroe登場時にローエンドをどれくらいの価格で出してくるかなんだよな。
$500以上でしか提供されないとかだとどれだけ性能良くても微妙だ。

よく考えたら
今までのPenMが479ピンで
Yonahが478ピンじゃない？

>>481
Conroeはハイエンドからの投入になるみたい。
で。しばらくの間はハイエンドがConroe、メインストリームがPreslerで住み分ける模様。

Conroeがメインストリーム〜ローエンドに降りてくるの発売後しばらくたってからじゃない?

Baniasは最初479pinで途中から478pin、Dothanは最初から478pinだったと思う。

後藤の記述でConroeはハイエンドから、というのは見たような記憶は確かにあるな。
ただ、Conroeと同時期にAllendaleというコア名で廉価版の噂もあったり。
これが本当かどうか。

>>472
次の世代のCPUが前の世代のCPUより性能が低いって状態に
なったのはP6（Pentium Pro）からなんだが

>>478
ConroeとMeromの差異ってFSB位しか無いと思ってたけど、他にも有るのか？

＞例えばオレゴンのチームは
＞デュアル／マルチプロセッサの経験、
＞サーバ向けプロセッサの経験が豊富です。

デュアルプロセッサ／マルチプロセッサの経験って・・・
オレゴンはPenMを２個くっつけただけのコアとか出しかねないＷ

ヨナ、コンロが出たらX2安くなりますか。
ヨナのIPCどれくらいかな？

>>478
よめばわかるじゃん。

マイクロアーキは共通でも、インプリメントが違う（　´∀｀）

>>487
ttp://pc.watch.impress.co.jp/docs/2005/0825/kaigai08.jpg
Whitefieldは2個くっつけたように見えるな

>>490
本当だねぇ
2次キャッシュの共有が4コアだと難しいのかね

Trをいちいちスリープさせるとか言ってたような記憶尾があるんだが
性能も下がるからMeromには使ってConroeには使わないとかやりそう

>>490
どう見ても説明用の絵だろ。ｗ

>>485
Pentium PROは 16bitコードが遅いため、そういう世評があったけど、
32bit コードは劇速だったよ。俺はPentium PROをUNIX系OSで使って
たから、世評とは反対で、非常に満足してたな。

最初に出た P4 は、たしか P3 と同じ 1.4GHz だったので、P3 の
7がけくらいの性能しか出なくて、みんな売るのに困ってなかった?

> 最初に出た P4 は、たしか P3 と同じ 1.4GHz だったので、

これは間違いか。P3 は当時 1GHz ぐらいだったのね。
でも、1.4GHz どころか、1.7GHz の P4 でさえ、P3 1GHz や
Athlon 850MHz に負けるという評価が残ってるな。(w

ttp://www.atmarkit.co.jp/fpc/motoazabu/011_2001-04-27/about_bench.html

UNIX サーバ屋的性能評価も、同様だった記憶がある。

ソフト的な問題もあるんじゃね?
SSE2つかって初めて、的な感じだし。
マルチコアもソフトウェアの対応がｷﾓでしょうなぁ。

サーバアプリでは、MMX や SSE って、ほぼ全く活用機会がないのよ。
これに対し、マルチコアは非常にサーバ向きで、既にソフト的な対応
は完了していると言ってもいい。

だから、マルチコアをクライアント向けCPUから始めて、いまだに
サーバ向けCPUでマルチコアの選択肢がないIntelって、戦略的に変
なのね。

まともな鯖は既にマルチプロセッサだからIntelのFSBでこれ以上コア増やしても性能でないんじゃね

FSBよりコア間トポロジの問題の方が大きいでしょ。
墨をサーバ用に出されたらそれこそ売る方が困っちゃいそう（苦笑
まともにマルチコアで使えそうなのはMerom以降になるだろうから、
当面は「クライアントをマルチコアに」の名目で売りさばくのは
戦略としては間違ってないと思う。商売の是非はともかくとしてね。

XeonDPに墨採用⇒2プロセッサから4プロセッサになるため
　　　　　　　　　　　　　FSBが800から400とか533とかに下がる
XeonMPに墨採用⇒L3付の墨でないといまいち意味がないが
　　　　　　　　　　　　　L3付の墨はダイがでかすぎる

>>497
intel：クライアント向け軸足
AMD：鯖向け軸足

だから。


X2とYonahの価格帯見ても、

X2：2石鯖廉価版
Yonah：HTTの代わりにデュアルコア採用

と言った感じが見て取れる。

>Yonah：HTTの代わりにデュアルコア採用
これはどこからそんなイメージが…
SMTとデュアルコアはまったく別のものなのに。

>>502
鯖WS的では無い用途に於いて、

HTT&2石の価値≒2アプリ同時起動で速度低下し難い

だもの。

> intel：クライアント向け軸足
> AMD：鯖向け軸足
> だから。

つい最近までは逆だったよ。最近の Opteron の成功までは、
AMD のサーバ向けシェアはほとんどゼロだった。
戦略的にクライアントに軸足を置いてるわけじゃなくて、
たまたま現状、Intel の戦略がコケてるだけでしょ。

>>504
いや、

Xeon＝Pentiumの小改良
Athlon＝MPやOpteronの機能制限版

かなり昔からこうだが。

と言うかintelの本来の鯖石は痛だし。

その鯖石の現状がｲﾀﾀ・・・

> Xeon＝Pentiumの小改良
> Athlon＝MPやOpteronの機能制限版

Pentium=Xeonの機能制限版
MPやOpteron=Athlon の小改良
とも言えるじゃん。
Xeonはキャッシュ増やしてMPにしただけ。
OpteronはHTの数増やしてMP,registered DIMM対応にしただけ。
Athlon 世代は MP より Athlon の方が先に出てたし。
Athlon 64 世代がまず Opteron から出たのは歩留まりと、
64bit 対応がサーバで特に重要だからでしょ。
てゆうかクライアントはそもそも OSがなかったし。

>>508
AMDの方は最近だが、
intelがクライアント向けから先にリリースするのはPentium以前からだぞ。
鯖WS市場を他社に席巻されるのも初めてでは無いし。

もともとPC屋で、サーバ向けとしては後発メーカなので、
クライアントが先に出ること自体はあたりまえだけどね。
でも、P3 系アーキの初代である、Pentium PRO は、
インテル的にはサーバ向けの扱いじゃなかった? まあ
Win16 が遅くてそれしか活路がなかったというのはあるが。

それに、ローエンドサーバ向けでシェアを下げたのは今回が
初めての希ガス。これまでにあったっけ？ Crusoe が出た
ころにブレード向けでちょっと話題になったけど、誤差の
範囲だったと思うが。

>>510
X68000

・・・鯖じゃ無いなぁw

>>469
立ち読みしてきたが
ベンチマークスコアのってねーじゃん

PentiumMをもとにこれくらいになるとアスキー編集部で予想したグラフ

がのってるだけだった

>>508
Opteronは明らかにマルチプロセッサ重視の設計だが。
ついでに、Ath64出た時点でもクライアント向け64bitOSは無かったんだが。

>>513
予想なの？

>>515
見てくるといいよ

PentiumMの元にしてFSBの666MHz化とデュアルコアでの予想グラフだった
共有2次キャッシュとかは考慮されてないと書いてある
パイプラインとか除算の高速化とかSSEの改良とかどういう予想であのグラフになったんだろうか

> Opteronは明らかにマルチプロセッサ重視の設計だが。

ソケット数に比例してメモリバンド幅が上がるから、
Intel の FSB 方式よりもマルチソケット構成で明らかな
利点があるというのは同感だが、高い性能電力比や、メモリ
レイテンシの向上は1ソケットのクライアントPCでも十分に
有効だから、>>501のような意見には賛成できんな。
NetBurstのような冷却機構に負担をかける設計は、むしろ
騒音を気にせずファンを回せるサーバ向きであって、家庭に
置くクライアントPCには適さないって考え方だってできるだろ。
(もっとも爆熱仕様はブレードサーバには向かんが)

> ついでに、Ath64出た時点でもクライアント向け64bitOSは無かったんだが。

これは Athlon の headroom がなくなったための単なる見切り発車だろ。

信頼性が重要なサーバには多少枯れたモノを使うべき。
その分野で失うものが無いAMDが勝負を仕掛けて当たっただけ。

゜　　　　　　　　　○　　　　゜
　　　o　｡　　 　 ゜ﾟ　　ﾟ ．　　　　o　　　　　　○o
　　　　　　　　ｒ⌒ヽ　　(⌒⌒)　　ｒ⌒ヽ/,
　　　　 、、;(⌒ヾ　　　((⌒⌒))　　/⌒) ),　　, 。
　　、　ヾ　(⌒　　　 ﾌｧﾋﾞｮ━━ﾝ！⌒⌒);;）／.　,
　、＼(⌒ゝ;(⌒ヾ　　In＿�Иn＿�пﾜ）／）) .,／ ,,
（(⌒-丶(;;;(⌒ゝ;;(⌒(；｀д´)｀д´)　,⌒⌒);;;;;））)⌒)
　(;;;;(⌒(⌒;;;(⌒　⊂　 焜　 |　炉　⊃／　)）⌒)）;;;;）-⌒)）
ゞ　(⌒⌒=─　　　　(,,フ.　ﾉ (,,フ .ﾉ　　　　─=⌒⌒)ノ;;ノ;;;::)
（(⌒≡＝─　 人从;;;;　レ　　レ'　;;;从人─＝≡⌒)丿;;丿ノ

↑
このAAが笑える出来になるといいなぁ、マジで。
intel 65nmに期待してるよ。
マズはハイエンドからの供給って事だけど、
x2みたいに高すぎ買えねーよヽ(`Д´)ﾉｳﾜｧｧｧﾝ、って言う流れは避けられそうもないけど。

CPUの話も興味深いんですが、貧乏人にとっていまのマザボが使えるかどうか
気になります。そのあたりの情報はどうでしょうか？

>>521
LGA775のままらしいよ。
そのまま載るかどうかは微妙だろうけど（PenDもだめだし）

>>522
ヨナとかメロムはどうですか？

そのあたりの情報は
月アスに載ってる

たとえソケット互換でもどうだろう。
プラットフォーム戦略とかやるくらいだから、
intel的には古いﾏﾏﾝのことは考えてない気もする。

>>525
まぁ少なくとも
ConroeはLGA775だな

>>524
月刊アスロン？

>522
BIOSで対応とか無いのかな？
将来のことを見越してFSB1066のﾏﾏﾝ買っちゃったから気になる。
まぁ安かったからいいんだけどね。メモリもDDRだし。

>>528
世間は３Ｇ携帯なのに先を見越して衛星携帯買ったぐらいの勢いだな

イリジウムのことかああああああああああああああああああああああ

イジリウムだとなんかエロい

>>528
もしかして
915世代のﾏﾏﾝ？
それじゃあ
Conroeは無理
確か
975世代を
Preslerと共有だった

>>517
ソケット数に比例してバンド幅があがるってこたぁないだろ。糞記事に洗脳されるな。
数が増えても一応帯域が維持されるだけだ。普通に考えりゃわかるでしょ。

>>533各ソケットにそれぞれメモリが接続されるから「トータルの」メモリバンド幅は、ソケット数に比例して上がるんだよ。(ソケットあたりのメモリバンド幅は当然一定)もしかして、そういうことも知らないの?

>>533-534
両方ただしいとおもうけどな

ただメモリを排他利用してると仮定しないと（ここらへん534)
結局メモリがネックになるんじゃないのかな(ここらへん533）

チップセット依存じゃないのかな
と丸くおさめてみるテスト

そうだな。OSとプログラムの書き方によるだろう。
コンロはバスインターフェースが変わらなかったらLGA775のままだろう。
今のMBが使えるとはあんまり思えんがｗ

>>536
MeromはSocket Mとよばれる478でも479でも775でもない新ソケットと聞いたが

OpteronとXeonじゃ、サーバーベンチでダブルスコアになりかねんぐらいの
大差があったのはお忘れですかのう
鯖用のアーキテクチャのOpと元はクライアント用のXeonの差じゃよ

Pen3Xeonのまま高クロック化していっていればひどい状況じゃなかっただろうけどなぁ

まぁPenMの動き見る限り大丈夫そうだが

>>517
＞上段
メモコン統合は兎も角、HTはシングルプロセッサ機に本当に必要かどうか疑問だが。

＞下段
現実のCPUは取り敢えず置いておくとして、
メモコン統合の様な1チップ集中をやると騒音は増すんだが。（例：n力）

おぷやathlon64がどうこうなのは別スレで。
xeonがどうこうなのは、このスレで。

>>537
pin数は479pinってどっかで見たな、それよりXeon系のLGA774ってGND一本減っただけ？

Xeon系だったらコアごとの電源制御も視野に入れて欲しいなー

>>540
FSB みたいな共有バスから、HTやPCI ExpressみたいなP2P高速シリアル
リンクへの移行は時代の流れでしょ。共有バスでは今の転送速度で
限界に近いが、HTやPCI Expressは今後も十分高速化の余地があるわけで。
せっかくPCI Expressで周辺はシリアル化してるのに、CPUとの接続に
いまだに共有バスがはさまってるってのはむしろ順番が逆でしょ。
高速化の必要があるCPUの回りからシリアル化するほうが理にかなってる。
IntelだってWhitefield世代ではそうなるんだろうし、いまだにそんな
こと言ってるってことは、トレンドが読めてないと思うよ。

>HTはシングルプロセッサ機に本当に必要かどうか疑問だが。
必要なんじゃね？ヌフォなんか初代からHT使ってたし、早くて安定してて
安くて汎用性に富んだバス使った方が他社がチップセットの開発とか楽だろ
うし。PCI-EやInfinibandとの親和性も高いし。元々Athlon(雷鳥〜)自体HT
にちょっと似たEV6(PtoP)バスだし。

逆にIntelがなんでシェアードバスに拘るのかがワカランね。

ま、結局比較対象があっての検討なんで
結局はこのスレでもOpやら64の話がのぼるわな。

話題に上るのはわかるけど、時々そっちがメインになる人間の多いこと多いこと(w

>>544-545
共有バスとパラレスパスを混同している。
転送速度のヘッドルームはシングルプロセッサならまだそこそこ余裕があるし、
速度さえ出れば性能的には大して差は出ないからな。
メモリとIOとの分離とかはまた別の話だしな。

もっともIntelはアナログ系の設計に関しては決して得意じゃないようだから、
とっとと狭幅クロックバスに移行した言ってのはあるだろうね。
シリアルDRAMを推進してたのもそれがあるし。

>転送速度のヘッドルームはシングルプロセッサならまだそこそこ余裕があるし、

あるか？PCI-EとかInfiniband、S-ATA2、それらの性能十分に発揮するには
今のバスじゃいっぱいいっぱいじゃね？デュアルコアになって更にバスがボト
ルネックになる事増えるだろうし。

それとSSE*、今よりバス早けりゃもっともっと性能出そうな気がするのだが、
将来的には256Bitパックド演算とか出てくるだろうし、逆にPen4の様なパイプ
ラインが深く、ベクトル(系？)演算を得意とするCPUの方がバススピード必要な
位だと思ってるのだが。



今からでもいいからSiSの4ch-RDRAM出ないかな・・・

>>549
SSE*はキャッシュを増量してDRAMとのやりとりは先読み・遅延書き込みしたほうが利く。
DRAMそのものが遅いんじゃね。
ゲーム機なんかはメインメモリそのものがSRAMなみに速いからキャッシュが不要。
このへんはさじ加減がかなり重要だが。
増やしたら増やしたでレイテンシが増大するし、そのぶん転送帯域増加で補うとか。

FSBが166MHzしかないG4でもAltiVecはやっぱり速い。
レジスタが多い分L/S発行頻度が少ないからね。

>>550
漏れはG4持ってないからアレだが、AltiVecって本当に早いの？ベンチだけ
って印象なんだが・・

それと先読み・遅延書き込みはやっぱ限度があるだろ？CPUキャッシュにも。
漏れが言いたいのはPen4みたいな突飛なCPU(失礼)作るならせめて1点だけ
でも最強！って言い切れる部分が有った方が存在価値があっていいんｼﾞｬﾏｲｶ
と思って・・


だからこそRD-RAMには生き残って欲しかった。メモリ2枚で4chも出来たしね。
ラムバスとっとと死んでもっかいRD-RAM復活くれないかな・・w

AltiVecとSSEでどっちが早いか比較してるサイトないのか？

結論言うと、用途にもよるが得意な処理なら圧倒的に速いよ。

Pentium4とG4、どちらも最大3命令（Pen4の場合μOPs）/clkだが
・G4は128bitパックド整数／浮動小数を1issueで扱え、L/Sもしくは整数や浮動小数で、
あと２命令は別個に並列実行可能。
・Pentium 4の（というか現行IA32の）SSE*の実装は64bit×2issueで、あとはレジスタが
少ない分ロード、ストアがボトルネックになってそれ以上は並列実行できない。
慢性的な命令帯域不足。
（だからこそレジスタの増えるEM64Tはプレス子のSSE*演算にもメリットがあった）

ただG4はFSBがメモリに追いついてないので、ストリーミングみたいなことやると
めっぽう弱いのね。
G5ではFSB帯域がようやくメインメモリを超えた
ただし、どこそこレイテンシが増大してる。
（といってもそれでもスケジューリングはMMX/SSE*よりは楽）


まあ、早いとこx86/x64でもSIMDをリアル128ビット化したほうがいい罠。
Meromが4issueらしいら、各演算ユニット・L/Sユニット128bit×2基搭載なら、
完全にPowerPCを超えうる。
ジョブズがIntelに何を見せられたかは知らないが、少なくとも整数だけは
現行PPC（これもG4かG5かは不明）の倍以上の電力当たり性能になるらしいが。

で、AltiVecが足ひっぱってG4はクロックが上がらずあぼーん
というわけか…。

つーか、Pen4の場合、
2サイクルかかってるだけで実装は128bitなんじゃないの？。
何せNetBurstの浮動小数点演算器の多くは半速で回っているという話もあるくらいだからな。

演算の種類はSSEの方がリッチなんじゃなかったっけ？
垂直、水平のパックド演算とかAltiVecはどうなんだろ。

>>554
いや、実装は64ビットだよ。
Pen4の場合64bitずつ、上下にわけて2倍のクロックで演算してる。
だから整数ならMMXと変わらないか、スケジューリングがかえって面倒。

ちなみにデコーダで2個の64ビットSIMD命令に分割してやるのは
PenMやK8なんかの場合ね。

どこぞの元ゲームハードメーカー流にいえば「128ビット級」。

>>554
うむ。SSEのxmmレジスタは128bitだ。

シェアードバスの件は上りと下りで共有しているため、
ある意味シェアードといえるんじゃなかろうか。
ドライバとレシーバのことを考えると実装は多少大変？
等長配線しなければならないようならさらに大変かｍ

>>555
そんな話はじめてきいたな。
NetBurstで倍速で動いているのは単純汎LUの2つだけだ。
MMX_ALUやFP演算系は等速かそれ以下のスピードなはずだが…。

>>557
いや、等速で2回にわけてやるから2クロックかかるの。

そもそもps{r,l}ldq以外は単純にMMX/3DNOWを2つくっつけただけで
簡単に実装できる代物だし。

たとえば足し算の場合、Intelの最適化マニュアルによれば
MMX(64bit) Latency 2clk、Throughput 1clk
SSE2(128bit) Latency 4clk、Throughput 2clk
なにを言わんかは。

で、AltiVecが圧倒的にハイスコアだしてるベンチは？
せっかくIntel版MacOSXもでてることだし、比較できても良いと思うが…。

John the RipperのDESベンチかな。
http://todd.dailey.info/archives/2005/07/18/john-the-ripper-1638-benchmarks-on-a-dual-27-powermac/
http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=7

NoconaやOpteron150がデュアル構成で測ってるかどうかは解らないが、
SIMD対応のベンチでダブルスコア以上の性能を出してるわな。

http://www.anandtech.com/linux/showdoc.aspx?i=2163

リンク訂正

せっかくなんで手持ちのマシンでクロックの近いのを。捏造はしていない。
NEC LaVieRX Pentium M (Banias) 1.5GHz, Windows XP SP2 Memory 768MB
MMX最適化版

> john --test
Benchmarking: Standard DES [48/64 4K]... DONE
Many salts: 200583 c/s
Only one salt: 190005 c/s

Benchmarking: BSDI DES (x725) [48/64 4K]... DONE
Many salts: 6125 c/s
Only one salt: 6091 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 3688 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 215 c/s

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 187602 c/s
Long: 510721 c/s

Benchmarking: NT LM DES [48/64 4K]... DONE
Raw: 728653 c/s

Mac-mini PowerPC G4 1.42GHz, MacOS X Tiger, Memory 512MB,
Altivec最適化版

$ ./john --test
Benchmarking: Traditional DES [128/128 BS AltiVec]... DONE
Many salts: 642227 c/s real, 667595 c/s virtual
Only one salt: 586188 c/s real, 596933 c/s virtual

Benchmarking: BSDI DES (x725) [128/128 BS AltiVec]... DONE
Many salts: 22220 c/s real, 22860 c/s virtual
Only one salt: 21639 c/s real, 22080 c/s virtual

Benchmarking: FreeBSD MD5 [32/32 X2]... DONE
Raw: 3604 c/s real, 3731 c/s virtual

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 269 c/s real, 279 c/s virtual

Benchmarking: Kerberos AFS DES [24/32 4K]... DONE
Short: 96409 c/s real, 99391 c/s virtual
Long: 264089 c/s real, 270583 c/s virtual

Benchmarking: NT LM DES [128/128 BS AltiVec]... DONE
Raw: 4501K c/s real, 4641K c/s virtual

同じくMac-mini Altivec非使用版。
x86のMMX非使用版は・・・見ない方がいいかと。

$ ./john --test
Benchmarking: Traditional DES [32/32 BS]... DONE
Many salts: 185753 c/s real, 191104 c/s virtual
Only one salt: 176908 c/s real, 181259 c/s virtual

Benchmarking: BSDI DES (x725) [32/32 BS]... DONE
Many salts: 6131 c/s real, 6308 c/s virtual
Only one salt: 6099 c/s real, 6249 c/s virtual

Benchmarking: FreeBSD MD5 [32/32 X2]... DONE
Raw: 3484 c/s real, 3599 c/s virtual

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 245 c/s real, 253 c/s virtual

Benchmarking: Kerberos AFS DES [24/32 4K]... DONE
Short: 99481 c/s real, 102347 c/s virtual
Long: 243378 c/s real, 250375 c/s virtual

Benchmarking: NT LM DES [32/32 BS]... DONE
Raw: 2510K c/s real, 2587K c/s virtual


アーキ統一を機にMacにアプリを移植しようと思ってMiniを買ったものの
はっきり言って脱力感に襲われた。
なんでPPC辞めちまうんだよと。

SIMDが効いてないKerberos AFS DESだけはPentium Mが逆にダブルスコア
だが、たぶんL/Sのユニット数（PenMは１本に対しG４は１本しかない）の
問題かと。S-Boxをテーブルルックアップに展開しているからね。

つか、もともとモトローラ(Freescale)は通信制御用の石作ってるメーカー
なんで、暗号に強いのはある意味当然ではあるのだけどね。
VPERMなんてもろにAESとかのバイト転置に有用なユニットだし、
逆にそれ系以外に使うにはリッチすぎる。

○　（PenMは２本に対し

たぶんL/Sがネックになりやすい処理に限っては結果的に
x86のほうが速くなることもあると思う。
（G５は２本になったもののロード専用１本、ストア専用１本なんで）
逆にロードが２本になればx86が勝てる処理はかなり減ってくるかと。
もっとも、足回りが大事だけど。

激しく乙

乙！
しかしどっちがどうよいのかいまいちわからんｗ
グラフが同じようで違う・・・

>>565
ユニット本数よりバスが100MHz〜166MHzのG4では厳しいのでは

cygwin入れて1.6.39のソースを再buildしてみた。

$ ./john --test
Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts: 559903 c/s
Only one salt: 515833 c/s

Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts: 18449 c/s
Only one salt: 18195 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 3722 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 250 c/s

Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
Short: 194241 c/s
Long: 488645 c/s

Benchmarking: NT LM DES [64/64 BS MMX]... DONE
Raw: 4739K c/s

コンパイラの進化のおかげか、幾分かまともなスコアになった。
が、それでもクロック数でもFSB帯域でも下回るMac-miniに負ける。
SSE*はデコーダネックで性能が出にくいのでおそらくはこんなもんだろう。

しかし恐ろしいことに、G4のプロファイルをとってみるに、まだパイプラインの半分も
使い切れてない。

整数演算ユニットをあと２つほど駆使してうまくスケジューリングすれ2，30％のアップは
狙えるかもしれない。

Intel debuts low-power 65-nm process
ttp://www.eetimes.com/news/latest/showArticle.jhtml?articleID=170704744&pgno=1
The P1265 process is said to have demonstrated leakages of only 0.01-nA/micron,
as compared to 100-nA/micron for the high-performance process, according to Intel.

To enable the breakthrough, Intel has modified its 1264 process.
These transistor modifications result in reductions in the three major sources of transistor leakage:
sub-threshold leakage, junction leakage and gate oxide leakage.

後藤弘茂のWeekly海外ニュース
ハードウェア仮想化とマルチコアCPUの関係
http://pc.watch.impress.co.jp/docs/2005/0920/kaigai213.htm

>>570
英語・・・
誰か訳してくれちょ

>>572
［WSJ］ Intel、電流リークを1000分の1にする技術を開発
http://www.itmedia.co.jp/news/articles/0509/20/news042.html

>>571・573
本当ならすごいな。ただ、intelってしょっちゅう大風呂敷広げるから物が出るまで半信半疑だ。

1000分の１ってすごいな･･･。
商品になった時には数割程度しか減らないんだろうけどｗ

>>575
逆にいまダタ漏れしてるって場合は
1/1000＝殆ど出ない
になるのかとおもわれます

後藤氏の仮想化の話だが、
メニーコア時代のキャッシュコヒーレンスがボトルネックとなるという話だけど、
1ユーザーが1バーチャルマシーンで高負荷なタスク1つを走らせる場合などは
全てのコアを使うより、コヒーレンスで足を引っ張らないだけのコアだけを割り当てて
実行することになったりするのだろうか?

まぁ、コアが多くなれば成る程、格コアに対するスレッドやタスクの割り当て電力管理等を
ハードウェアレベルで統括する専用制御コアが必要になってくるのは明白だと思われ。
ソフトウェアレベルじゃ全く期待出来ないからね。

>>572
携帯機器用プロセッサで導入されるみたいね。
PC用プロセッサに対応できる技術じゃなさそう。

>578
そうなってくると、今度は単純なコア数が性能のピークに直結しなくなって
更にﾏﾝﾄﾞｸｻｲことになりそうですね。
微細化が限界まで至って、対消費電力比の性能が限界まで行き詰ったら
今度はダイサイズ(コア数含む)で競い合って、
最後はどうなりますか…

そして、量子コンピュータへ

>>573
�dクス

1/1000っていったら0.1Wなわけで・・・
シンクレスだぞｗ

>"電流リーク"を1000分の1にする

リーク電流の話だぞ

ヨナはこけないと思うけど，
コンロこけると思わんか？
コンロこけると思う人手をあげなさい．

(presler以降の)ハイエンドから投入と明言してる以上、
現状より悪くなることはないと思われ。
サンプルの段階で既に調子良いのでしょう。

っていうと、ヨナーのデスクトップ版の周波数低いのを買えばよしか。
コンロへの乗り換えはソケット一緒だといいな〜

Yonahが（65nmプロセスごと）コケなけりゃConroeがコケる可能性は殆ど無いぞ。

LGA775はなさそうだな。ピンの大半が電源供給用だろ。

Meromは4issueに拡張してるから、わからんよ。64ビット拡張もあるし。
G5も4だっけな。

>>588
Yonahはあくまで基本的にモバイルCPU（ソケットもチプセトもノート用）よ。
Yonah採用したデスクトップ製品は出るかも知れんが、
自作としてはあまり期待しない方が良いと思うよ。

IDFに出てた超薄型デスクトップは結構ツボったけどな。
よくよく考えればノートの筐体を縦にしただけともいえる。

Yonahは結構期待してるんだけどね。SSEｘの128ビットパックド演算がどのデコーダパスでも１クロックで実行できる。
実質命令帯域が増えたようなもの。
そうなると、演算ユニットもかなり改良されてる気がするんだがな。
既存のIntelチップは複数の演算ユニットに対しポートを共有する形態をとってて、それが足かせになってたけど、
１ユニット１ポートに振りなおすとか。

>>590
IDFの記事見たか？
まぁそのままいけばだが
LGA775のままだな
>>591
分からんぞ
Preslerの2.8Gより
Yonah最高クロックの方が
性能がいい希ガス
というより絶対

河童→藁、北森→ﾌﾟ、クラスの悪化は当初から予想されている場合（前者）と、
プロセスルール変更に伴って（後者）以外にゃ起こりようが無いだろう。

どっちにしろコンローは90Wなんだろ。
デスクトップでも20W級のCPUはでないものか。

Conroeは65ｗだな。

どうせ「Intel TDP75%の法則」が働いて、実際は90W超えたりするんだろ

情報が旧い。
Conroe 90W→65W
Merom 45W→35W

もっともTypical TDPだろうけどな。

マルチコアが仮想OSで役に立つというのは一般消費者からは
ものすごく消極的な理由付けにしかならないんじゃないか？
仮想OSが役に立つ業務が存在することは自分が利用者として
身にしみてるわけだが元来一般家庭でも利用価値が高いはずの
マルチユーザーが実はそれほど役に立ってないというのに

>>595
残念だが発熱が高くてもベンチを上げろという要求のほうが強いな。
Mも釣もGeodeもサイリックスもマイナーだし。
>>599
逆にズアルなら高くても売れるようだな。
シングルから見れば爆熱のX2も品薄だし。

>>599
ソフト次第ともいえる。

シェアードキャッシュがオフィス系で有効というが、Yonah/MeromがMS謹製のOfficeベンチで
どれだけ性能が伸びるか見ものだと思うが。

>>601
そもそもOffice系はマルチスレッドに対応してないし、
する意味も大して有るとは思えないから、
Dualcoreやシェアードキャッシュは意味ないでしょ。
整数演算が強化されてる分は向上するだろうけど。

シングルアプリがデュアルコアで速くなるというならわかるんだけどね。
もちろんその可能性も否定しないが。
ただクロック向上ほどその変化はわかりにくい。
単なるセールストーク用で終ってしまうのは悲しいことだ。

>>602
いや、OfficeなんかはActiveXやDLLの塊だから、複数のドキュメント開いてるときでも
キャッシュの効率面で有利になるらしい。
あと、.NETなんかが絡んでくると(VS2005では.NETでOfficeのアドインを簡単に
作れる機能が充実している）どうしてもマルチスレッドが絡んでくるはず。

仮想OSだけじゃなくて、いまのjavaVMとか.Net frameworkとかの
アクセラレーション?にコアを動的に割り当てるなどもするんじゃない?

>>605
正解
バックグラウンドコンパイルとかAWTスレッド、JavaSoundスレッドとか
プロファイラでものぞいてみればすぐわかるがスレッド結構立ち上がるもんだよ

並列GC使えば効果大きいしね
スループットとレスポンスを解決する方法として2種の並列GCがある

そしてこれらのアプリは64bitだーとか32bitだーとか関係ない
64bit対応VM上で動かせばレジスタ増えてるから何もしなくてもそれなりに速いとかね

Javaのダイナミックコンパイルの最適化は勝手にSSE使うようになってきたりしてるから
同一コードがより早く、という点でかなり面白い
静的なコンパイルより統計取りながらコンパイルしていくほうが有利になる場合も多いしね

最近はGC後の再配置に効率のよいアルゴリズムを採用した結果
キャッシュのヒット率が上がったりして何も考えないCのコードより速かったりした

おや　その特徴的な文体はｗ

>>607
お前こそ、だ。
いい加減自分の都合の悪い、もしくは録音にあてはめる行為はやめたらどうだ。

それだけじゃなんだしなぁ・・・
あと墨。

>>598
それ、メインストリーム向けの数字。

>>609
別にメインストリーム向けでいいじゃん
普通ULV版なんかを基準に話すか？

自作の方が好まれれるパフォーマンスデスクトップは90Wのままですよ。

>>611
それ、どこに書いてあるの？

サーバー用には確か90Wだという発表はあったね。

80Wです

あれそうだっけ、ｺﾞﾒｿ

>>611
XEやFX買うのは極一部だと思うのだが。

Intel、3.80GHzのPentium 4 571などを製造中止
http://pc.watch.impress.co.jp/docs/2005/0921/intel2.htm

http://pc.watch.impress.co.jp/docs/2005/0921/intel.htm
サブスレッシュ「ホールド」(笑

>>618
普通に使われてる。
ttp://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&rls=GGLD,GGLD:2005-29,GGLD:ja&q=%E3%82%B5%E3%83%96%E3%82%B9%E3%83%AC%E3%83%83%E3%82%B7%E3%83%A5%E3%83%9B%E3%83%BC%E3%83%AB%E3%83%89

ttp://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&rls=GGLD,GGLD:2005-29,GGLD:ja&q=%E3%82%B5%E3%83%96%E3%82%B9%E3%83%AC%E3%82%B7%E3%83%A7%E3%83%AB%E3%83%89

>>619
http://www.google.co.jp/search?hl=ja&c2coff=1&rls=GGLD%2CGGLD%3A2005-29%2CGGLD%3Aja&q=%E3%82%B5%E3%83%96%E3%82%B9%E3%83%AC%E3%83%83%E3%82%B7%E3%83%A7%E3%83%AB%E3%83%89

まぁ意味わかるからいいけどさ

>>618
発音記号を見ろ。hを省略する場合もあるが笑われるのはお前だ。
http://dictionary.goo.ne.jp/search.php?MT=threshold&kind=ej

そう？

>>622
ﾃﾗﾜﾛｽwww

わーい笑われたー

>>622
中学からやり直せ・・・いやリアル消防か？

>>625
まぁチャンネルとチャネルが気になるお年頃ってわけですわ

>>626
高校生？

スレッショルドが普通だな

yonahってデュアルコアになるんだな。
ＰｅｎＤみたいに糞ＣＰＵになるかもな

ヨナはシングルコアのモデルもあるし
PenDはベースとなるPen4がすでに問題だったのではないかね

Yonahは最初からデュアルコア前提のダイ。
半分不良のものを片コア殺してシングルコア版として出すだけだよｗ

K9キャンセルになったが，
焜炉に対抗できるAMDのコア（K10?)はいつ出るの？

ﾜﾛﾀ
さすがintel次世代スレ

>>591
パイ焼きとか見ると、以外に回せるかもしれないね

>>632
良く知らない、今の所'07らしい
ttp://pcweb.mycom.co.jp/news/2005/06/18/102bl.jpg

Yonahは
史上最高のデュアルコアプロセッサになること間違い無し！！(同価格帯で)

期待が持てそうだな

>>631
こんなのもあるけど
http://www.itmedia.co.jp/news/articles/0504/08/news009.html
実際どっちになるんだろう？

ちゅおー

>>635
マザボの価格で相殺されそうですから、割良くない気がしますけどね。

ガベージ・コレクションをGCなんて略すのは一般的なのか？>>606
最後の二行を見るまで、おれは判んなかった。

>>640
ソフト屋なら割と一般的
ガベージコレクタともとれるときあるからあれだが

とりあえずJavaや.NETの動作はPen4よりPentiumMが圧倒的に得意
並列動作はHTができるにもかかわらずね

つーわけでソフト屋にとってはYonaがちょうど望まれる石っぽい
開発をノートですることも多いからね

なんせIDEのほかにアプリ鯖やDB、そして肝心のソフトのデバッグとプロセス立ち上げまくるわけだし

マルチスレッド化されてないCベースのソフトとマルチスレッド化が容易な中間言語系と
仮に速度がつりあった場合、開発者がどっちをとるか、というのもみものでもある
スレッドが言語レベルでサポートしてるとやっぱりちがうし、Javaのアトミッククラスみたいに
CPUのレベルまで入り込んだものもどんどん増えると思う

Lisp屋の俺にはGCはGC以外の何物でも無い

http://pcweb.mycom.co.jp/news/2005/09/21/005.html

むしろスレッドを活用するほどに性能にシビアならC++だろ。
templateの応用はGenericsより進歩が速いので開発のしやすさでも勝る。

>>644
シビアとかじゃなくて、言語レベルでスレッドもってるやつは
マルチスレッド化をさほど意識しなくても簡単につかえるってことだよ。

そしてガチガチに最適化するぜーとかいうやつでもマルチスレッドの技術がないとかよくあること。
そしてせっかく最適化したシングルスレッドもさほど速度出てない（今はそんなことないけど）
中間言語系のマルチスレッド対応アプリに速度で負けてあぼん。

もちろんできるやつはなにやってもいけるんだけどね。

あと必死にtemplateのよさいってるようだけれども、genericsかどうかとか
そんなレベルじゃないよ、開発効率は。

いや、マルチスレッドの技術がないような連中はオブジェクトの寿命も考えない馬鹿コードを生産するぞ。

>>637
CeleronMはどうせSpeedStepないからって
片方のコア死んでいるやつを使ったりして
で、あたりのやつだけシングルコア専用マスクのYonahの選別落ちだったりな

シングルコア専用じゃないとCeleronMは価格優先だからきつそうだが

どっちにしろSpeedStepなしとキャッシュ半分、コア数半分と
PentiumブランドとCeleronブランドとはっきりとした性能差が出るだろうね

Yonah CeleronはEIST Enableって噂もあるけど

メロンがこけてヨナのFSB800になる可能性はある？

>>649
Pen4ｲﾗﾈ、セレでｲｲじゃんには懲りているだろうからなあ。

>>651
だいたいもうサンプルは出てる訳だし
コケると言うか遅れることはあるかも
TDPの関係で

>>651
そもそも
MeromもFSB667だぞ

リーク電流を克服しても、4issueじゃ別の面で苦しい気が

MeromはFSB1333

最初のMeromはNapaプラットフォームをそのまま使うからね。

メロンはFSB667、焜炉がFSB1066だろ？

NapaはFSB667、Santa RosaはFSB800．

何？
サンタロザって

モバイルＣＰＵと同じぐらい省電力になればと思うけどどうせならないな・・・・
６０Ｗぐらいになってしまいそう。

>>661
コンロのこと言ってるのか？

将来は数百コアになるらしいけどコアって物理的に何個乗るの？
十個、二十個は乗るかもしれないけど五百個とか九百個でも大丈夫なの？

>>663
プロセスルールが許す限りは何個でも載る。
整数に浮動小数にMMX/SSEにアウトオブオーダに・・・とフルセット揃ったコアは1個か2個で
SIMDやグラフィックに特化した小さなコアを何個も載せる計画だろう。

ヒント：プロセスルールがn世代進めば１コアあたりの面積は2^-n倍になる


なお、ダイのサイズは80〜200mm²程度に収めるだろう。

そんなにコア増やして効率が上がるのかいｗ

>>663
その電波の発信元は何処かね？

つい最近下記の記事があったよ

ヘテロジニアスなマルチコアになったらどんどんコア数は増えそうだな


ハードウェア仮想化とマルチコアCPUの関係
ttp://pc.watch.impress.co.jp/docs/2005/0920/kaigai213.htm

ttp://www.ebjapan.com/content/l_news/2005/03/08re_intel050304.html
ttp://www.designnewsjapan.com/news/200503/08etest_intel050308.html

http://www.itmedia.co.jp/enterprise/articles/0503/04/news030.html

そう言えば、PARROTの論文に書いてある比較ベンチCPUがMeromとかたるさんが書いてたな

Bakerってエージェント志向言語かな

志向→指向

アプリがマルチスレッド化されるのが当たり前になってきて、
通常使うアプリが３つくらい立ち上がってたとすると8個くらいまでは
デスクトップでも恩恵はありそうだ

そしてエンコードは恐ろしい速度で終わる

鯖は正直100個もあっても使おうと思えば使うといった感じ
サービス志向が強くなって処理の大半は鯖でやる、といった感じになるかもね
PDAとか携帯電話とか家電とかがクライアントのメインになってきたり


どっちにしろコンパイルしたらコーヒータイムな時代からは想像もつかんな

既に終業前にバッチ突っ込んで出社時に結果確認してた時代からは想像もつかなくなってるけどな

"パーソナル"コンピュータで３コア以上は無駄以外の何物でもない

それはお前のパーソナル

頭がお花畑な人がいるな。

マルチコア・メニイコアで皆ハッピーなら、10年前からそうなってたよ。

>>677
１０年前はまだクロックを伸ばし続けることができただろ。

ここ数年になって一気に鈍化した。

頭がお花畑な人がいるな。

シングルコアで性能向上できるなら、ネットバーストは見捨てられなかったよ。

アホばっかりだ

状況の変化を理解出来ないんだな。
今後も十年前と同じ事しかやらないと思い込んでるし。

だれかメモリアクセスが発生したときの
一般的なレイテンシを教えてくれ。

とりあえずうちの環境ではメモリの部分でのアクセスに9クロックかかっているようだが。
（DDR400・200MHzベースで）
ras信号-trcd-cas信号-tcas-バーストクロック(DDR)
これであってる？

マルチコアなんて激無駄。
シングルコア＋Hyper-Threadingがベスト。

http://www.ne.jp/asahi/comp/tarusan/main49.htm
http://www.ne.jp/asahi/comp/tarusan/main72.htm
http://www.ne.jp/asahi/comp/tarusan/main88.htm
http://www.ne.jp/asahi/comp/tarusan/main90.htm
http://www.ne.jp/asahi/comp/tarusan/main96.htm
http://www.ne.jp/asahi/comp/tarusan/main107.htm
http://www.ne.jp/asahi/comp/tarusan/main119.htm

>>683
かるくみてみたがなんでマルチコアになるとシングルコアより性能が大幅に下がるんだ？

>>684
おまえの頭の中はシリコンが涌いてるようだな
小学校の算数からやりなおせ

そもそも、シングルコアとマルチコアのトランジスタ数が同じという仮定が間違ってる。
アーキテクチャの観点ばかりでものを考えるとこういう間違いを犯す。

たるさんはマーケティング面とアーキテクチャ面はちゃんと分けて書いてるだろ

ロジックに同じ量のトランジスタを使う場合、シングルコアの方がシングルスレッド性能はずっといいからね。
そして世にあるソフトはシングルスレッドがいまだにとても多いし、マルチスレッド化がしにくい計算ってのも少なからずある。

HyperThreadingをはじめとする一つのCPUコアで複数のスレッドを動かす技術は、
性能がそれほど極端に伸びないかわりにトランジスタをあまり食わない。
だから、ロジックを比較的リッチに保ったまま(シングルスレッド性能を落とさずに)マルチスレッド性能も向上できる。
もっとも現状のPC用にでてるデュアルコア程度ではマルチコアのトランジスタのコストパフォーマンスの悪さはあまり問題になってない。
つまりシングルコアと同等のリッチなコアを複数搭載できるし、ソフト的にも2スレッド動けばPCでは十分な局面がほとんどだから。
コストパフォーマンスの悪さが問題になるのは4か8コアあたりからかな。

>>664
プロセスルールの限界はどこなの？
インテルのロードマップだと45n世代で4コアが主流になるみたいだけど、このままどこまで微細化は進むの？
0.1nとかありえないと思うのだが。

実験室レベルでは原子サイズまでのメドはできてるんだっけ？

単分子トランジスタの実験には成功しているようだ。実用のメドは知らん

>>685
純粋に高クロック化していったところでTDPとかもう限界なんじゃないの？

予定ではプレスコは大幅に消費電力を下げる経済的なコアで
実際物が出てきてみたらこういう状況

>>692
つっこむならもうちょっと賢いこと書いてくれ
「クリティカルパス」とか「熱密度」とか

TDPが飾りと化してる淫照は、どうせ空冷限界を超えた炭を出すなら最初から手蓮出しとけよと

もちろん熱密度が一番重要だと思ってるが、わかりやすく、な

シングルコアﾏﾝｾｰ
http://www.biwa.ne.jp/~yok/838RANK-NEW.htm

>>690
>>691
プロセスルールでいうとどれくらい？0.01n位か？
原子サイズ以下は無理だよね。だから実験室レベルだと限界に達したってこと？
それとももっと微細化は出来るの？
実験室レベルから実用化まで何年位なの？
>>693
>>694
熱密度が高いと何が問題なの？下げるのはどうすれば良いの？

>>696
今の所intelのロードマップでは'11に22nm(プロセス1270)までは書いてあるけど、
如何なるんだろね？シリコンの結晶構造の最小サイズが0.54nmだから
何とか成ると言えば何とか成るかもしれないが…

>>697
intelのロードマップ≒多重債務者の返済計画

>>696
100mm^2の表面積を持つ物体と10000mm^2の表面積を持つ物体があったとして
発熱量が同じならどっちが冷やしやすいと思う？

700

>>699
　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ/⌒)　　100mm^2の表面積を持つ物体クマー
　 /⌒) (ﾟ)　　　(ﾟ)　|　.|
　/　/　 　( _●_)　 ミ/　　
.（　　ヽ　　|∪|　　／ 　　
　＼　　　 ヽノ　/ 　　　
　 /　　　　　　/　　 　　
　|　　　　　　 / 　　 　　
　|　　／＼　＼ 　　 　
　|　/　　　 )　 )　　　
　∪　　　 （　 ＼　　　　
　　　　　　 ＼,,＿）

原子って
何ﾅﾉメートル？

四畳半の部屋と、８畳の部屋と、どっちがエアコンの効きが良い？
そっから考えると、面積の小さいほうが冷やしやすい。

今のやり方のままだと30nmかその次の22nmだかでもう打ち止めだったような。

>>703
たとえとして不適当と思われます。
室内エアコンなら四畳半も８畳も性能に対して室内空間は十分広いと考えられるので、室温が同じなら熱容量が
多い広い部屋のほうが当然不利です。

この例えだと「同じ温度の大きさの違うヒートシンクどっちが冷やしやすいか」に近いね。

CPU冷却は発熱体が小さいのでヒートシンクを使うくらいなので、ある程度までは大きいほうが有利(固体内の対流
空気による冷却を期待できるしそもそもファンの形状に余裕があれば冷却能力も上げられるので)。

>>703-704
家庭用エアコンと業務用エアコン、同じ広さの部屋を冷やすとしたらどちらが冷える。

あたりが適当かと思われ。

>>1 質問ですがこのスレは自作板と、
どういう関係があるのですか？ 全く関係ないと思いますが…

>>706
ついでにこっちのスレにも同じ事言ってこい。
↓
VIA C7 スレ
http://pc7.2ch.net/test/read.cgi/jisaku/1117267861/

>>706
ここで話題になったCPUが発売されて、
最初に（除卸、店、ベンダ）購入するのは自作erなわけだが。

>>706
そんな事言ったら
自作板が成り立たない訳だが？

>>705
それって、リテールのオマケとAlphaとどっちが冷える？の喩えと違うけ？

>>706
次世代CPUの性能や仕様について語り合う
　　　　　　　　　　↓
自作PCパーツについての、長期的な展望や購入計画に役立てる
(今後も末永く使用できるか・買い替えの好機はいつか)
　　　　　　　　　　↓
自作PCライフの充実に繋がる

ちょっと考えれば、すぐに分かりそうなものだけど・・・
AMD次世代CPUスレでも同じこと訊いてる香具師がいて、
いつ明解な返答レスが付くかと思って待ってたんだけど、
結局誰も答えていなかったのが不思議でならない。

エアコン話は、エアコンそのものが熱源で、部屋は媒体。
実際のコアは、コアの面積そのものが熱源。

比較として全く筋違い。大丈夫か喪前ら。

>>669
これで64プロセッササーバー作ってタスクマネージャー開いたら大変だな。
>>702
原子核は1fm位だから0.000001nmかな。原子半径はもっと大きいけど。
>>707
リンク先でも同じ扱い。>>706は3スレ目に行かないのかな。もしかしてここの前もあるのか？

プロセスルールの微細化は、量産性、経済性も考慮しなきゃいけない。
32nmは割とすんなり行くだろうけど、それ以降、確証があるわけじゃない。
考えて見れば、プロセスルールが限界に至ったところで、特に一大事
というわけでもないんだよねえ・・、まあ、PC業界は嫌だろうけど、
こんなもんでいいよ、と思ってる人多いだろうし。

>>713
ここ。
http://pc7.2ch.net/test/read.cgi/jisaku/1124542812/

>>714
プロセス微細化が限界に達したら、どう考えても一大事。

>>1 質問ですがこのスレは○○板と、
どういう関係があるのですか？ 全く関係ないと思いますが…


これ、単なるコピペ荒らしのフォーマットだろ。
荒らしにマジレスする人がいないのは当たり前。

>>716
+++の言うことなんかスルーするのが一番だよ
何より時間のムダ

>>718
そうなのか、スマソ。

様々な産業で、進歩があまり無い中でもずっと存続してるわけで。
半導体産業の爆発的な進歩のほうが異常なんだけどね。

>>688
ポラックの法則に破れてキャンセルされた「Tejas」
http://pc.watch.impress.co.jp/docs/2004/1224/kaigai144.htm
＞ポラックの法則は、CPUのマイクロアーキテクチャを拡張してダイ(トランジスタ数)を2倍に増やしても、
＞性能は2の平方根の約1.4倍程度にしか伸びないという経験則だ。

ただマルチコアがシングルスレッドを速くしないのはほぼ確か
まー過去のソフトがほっといても速くなった今までがラッキーすぎたってことでしょ？

>>704のこと
すでに90nmでゲート酸化膜が原子数個分まで薄くなってるらしい

これからは量子力学的効果で絶縁してるはずのところでも電流だだ漏れ（リーク）がますますひどくなるから
プロセスルール縮小も大変そう

そういえばプレスココアは何であんなにデカイんだ？
キャッシュ除いたコア部のトランジスタ数、北森比2倍位になってたような。

ﾄﾗﾝｼﾞｽﾀ2倍性能1.4倍の法則なんて8086のころからあったこと
今になってあーだこーだ言う問題ではない

>>668-669
電波記事の元ネタを探すに苦労しますた。これだな、
http://www.intel.com/technology/techresearch/idf/platform-2015-keynote.htm
ここのThe Trend to Many-Core
インテルでは10数コアの実験をしており、数百コアの
可能性もあるって事をRattnerが言ってるって事でしょ。
将来は数百コアになる、って話しとずいぶんニュアンス
が違うと思うけど。
そもそもこのRattnerっておっさん、数年前には2010年
には15〜20GHzになるなんて予測していたわけなので、
まあ、信用ならんわな。

別に今時メニーコア自体、珍しい事でもないよ。
数十〜数百コア単位のMPU開発してんのなんてIntelだけでも無い品。

(コンシューマにおける)メニイコアの輝かしい未来を信じてる人って
数年前に10〜20GHzの熱湯バーストを信じてた人達なんだろうなあ

Cellとかは、メニイコアって言うのかな？

>>727
うおっ、コアをそういう風に解釈すれば、有りなのか。
>>725のいう数百コア単位のMPUってどういう物なんだろうな。

Cellはヘテロジニアスなメニイコアだあねえ

○ メニイコプロセッサ

強弁するならピクセルシェーダーユニットやバーテックスシェーダーユニットもそれぞれ一つのコアとか言える罠
nVidiaのG70は30以上のコアを集積したメニイコアでございますとか

ttp://pcweb.mycom.co.jp/news/2005/07/27/002.html

ゲーム用以外ではSUNがNiagara（8コア）出したので、これがどうなるかが
興味あるよね。

httpdとか単純なプロセスが大量に生成されるWebサーバーは得意みたい
だけど、通常用途では今のところそれほど速くはならないみたいだね。

だけどメチャ期待している。

デスクトップでメニイコア使いたいよ

それならリコンフィギュアラブル系のPUも既に数十コアですか

まぁ各種コプロも内蔵されてきてるし方向としては同じような感じかもな

対応アプリがないと高速化しないということが

逆に考えると同じように標準になることによって当たり前のように使われる・・・はず

前にも書いたと思うけど、IBMとciscoがネットワーク用に188個のCPUコア
集積したチップ作ってる。intelもネットワーク向けに開発中のハズ。まあ専門用途だけどね。

intelのヘテロジニアスなコアが、（その数というより）洗練されたアーキテクチャで
強力という展開なら面白いし、特定用途向けのコアが積んでたらなおいい。
もちろん帯域やソフトウェア的な問題は大きいんだけど、intelもこのスレの住人も
分かってることだろう。

>>732
で、その通常用途って何よ？って感じなんだが。

特定用途向けはそれこそ専用のチップがある
CPUのコアを増やす必要は無い

CPUを大量に導入というよりはDSPも1チップに組み込んだって感じなんだよな

でもPC用途の場合CPUコア複数でいいと思われ

ビデオチップも内蔵するきならかまわんけど

メニイコアって言っても幅があるからねぇ。
汎用CPUと特殊用途CPU分けて考える必要がある。
数百個コアとか言ってんのは、特殊用途であって汎用CPUの話で無いよ。
一般用途の汎用CPUは無理せず（シングルスレッド性能犠牲にせず）
微細化によって増やせる程度の10コア前後って話よ。

>>737
へぇ〜。特定用途ごとに専用チップ沢山積むんだｗ
PCの歴史でも勉強してきな。

↑アホ

アホだな
文章読めない

特殊用途向けのMMX/SSEやAltiVecが広く受け入れられてる現状を考えれば

そのときになってみればソフト次第でどうにかなる気もする。

>>737の考えがどれほどアホな事なのか解らないというのは痛すぎるねぇ。
昔はFPUですら特定用途向けの専用のチップだったというのに。

ロジック回路を増やすこととコア数を増やすこととを混同してるアフォ

>>745
ヒント：ヘテロ

このスレには半導体業界の中の（市場規模はデカイが）狭いところしか見てない人が常駐してるようだ

ワンチップでいろいろできたほうが信号遅延は小さいんだがな。

メモリレイテンシ改善のためにメモコンを統合するような時代だ
ダイ上に特定用途に有効な小さなコアを載せるのも自然な流れだろ。

Tunt+g7Yは凄いなぁ、
では是非半導体業界を広い視野でみて
今後Intelを筆頭としたCPUメーカーが何をやってくのか予言してくれｗ
君の話だとIntelが既に言及してる事も否定出きるようだし。
ホント凄いわｗ

まぁ、インテルが高クロックシングルコア捨ててデュアルコアに走ったのは、
今以上の性能をシングルで出すメリットが無いと思ったからだろ。
高性能が必要なのは、ゲームと動画編集のみ。
この二つに特化するなら、デュアルコアにした方がいい。

ゲームプログラマはしぶといから、１年もあればデュアルコア用のプログラム作成ノウハウゲットするさ。

熱の話は、ちょうど良い解説が始まった希ガス
ttp://pcweb.mycom.co.jp/column/architecture/001/

>>750
メリットがないんじゃなくて、熱問題でにっちもさっちもいかなく
なったからでは？

マルチコア時代でもシングルスレッド性能は重要。

いや、だから今以上の性能は必要なのか、と。

おいおい、高クロックにメリットがないと判断してたなら
PentiumIII〜Banias系だけしか出さなかったろうよ

>>754
同一マイクロアーキテクチャを仮定した場合、
2コア2GHzよりも、1コア4GHzの方が、ほぼ常に性能が高いと
考えて良い。なぜなら、アムダールの法則により、コア数を
増やしても、性能はリニアには伸びないから。
だから、シングルコアで性能が伸びる限りは、コア数はむし
ろ少ない方がいいんだよ。

ただ、ポラックの法則から、投入するトランジスタ数と、
性能向上率の比では、複雑なシングルコアCPUよりも、単純な
コアを複数積んだ方が、トータルスループットの点で有利。
この辺を強調したSunのマーケッティングワードが、
スループットコンピューティングだな。

（消費電力・発熱を大きくしてまで）シングルスレッド性能を上げる必要は無いな。

>>757
話が逆で、必要がないわけじゃないんだが、消費電力・発熱の
点で限界にぶちあたったので、シングルスレッド性能を上げたく
ても上げられなくなったってことだよ。

特定用途向けというのは、高速汎用ロジックをぶん回せばいいじゃないか、
それのほうがCPUの高速化に従って速くなるんだし、柔軟だ、という考え方も
前からある。（Lispチップが潰れたのもそんなところか）
でも、消費電力の面を考えれば専用ロジックのほうがいいという点と、
膨大なトランジスタの使い道として、今後特定用途のコアを入れるというのは
以前より有効になるんじゃないかなと。
http://pc.watch.impress.co.jp/docs/2005/0530/spf06.htm
上のTarariのようなのを別コアに入れれば面白いなと思ったのと、Rattnerも
XML処理のことは言ってる。あとはJava/.NETとかね。
Niagaraには暗号処理ロジックが（メインコアとは別に）入るとかなんとか。
ちょっとあいまいな記憶だけど。

特にPC向けx86系CPUの場合は絶対にシングルスレッド性能を前のアーキテクチャより落とすわけにはいかないしねえ。
ConroeでもILPを相当強化してるし。その上でマルチコア化してる。
サーバとかHPC、ゲーム機なんかはマルチスレッド化されてるソフトが相当量あってノウハウもいっぱいあるし、
比較的容易にドラスティックにソフトウェアを置き換えられるから、シンプルなコアをいっぱい並べる方法も楽にできるんだろうけどね。

Intelはこの辺のソフトウェア資産のしがらみも克服すべくランタイムベースのソフトウェア開発環境を推進してた気がするが、
Microsoftがいるし結構難しいだろうなあ。

＞ゲームプログラマはしぶといから、１年もあればデュアルコア用のプログラム作成ノウハウゲットするさ。

( ﾟдﾟ)ﾎﾟｶｰﾝ

ま、ゲームプログラマっていうかゲームソフト自体が、ほかのアプリと違うもんな。
ハードウエアの性能を引き出せないと、そのままライバルに見栄えのおとるソフトに仕上がるから、
マルチスレッドにどれだけ対応できるかも競争だしね。

マルチスレッドなプログラムは、バカでもとは言わんがそこそこできるやつなら普通に書ける。

ただ、然るべきデュアルコア/マルチコア/メニイコアのシステムでパフォーンスを引き出せるかは全然別問題。
4スレッド対応ベンチがPentium XE 840だと(ノ∀`)ｱﾁｬｰなことになることがあったように。

> Niagaraには暗号処理ロジックが（メインコアとは別に）入るとかなんとか。

その通り。
Web フロントエンドサーバは、大量のSSLコネクションをさばくための
暗号処理が馬鹿にならなくて、そのために SSL アクセラレータ専用
ハードウェアを導入するとか、そういうことが当たり前になっている。
Niagara は、まさに Web フロントエンドサーバ向けのプロセッサなので、
このために SSL 高速化のロジックや、TCP offload エンジンを CPU 側に
内蔵している筈。
TCP offload エンジンは、昨今の PC 用 Gigabit Ether カードも内蔵
してるけどね。

つーか、Intelの願望とは裏腹に、PCはメニーコアよりもワンチップ化の方向に激しく進む気がするのだが。
実際、AMDなんかはI/Oの統合にも積極的なわけだし。

は？

AMDはPCIeやらUSBバスインターフェースの統合も考えているようだよ。
メニーコアがPCであまり必要とされなければワンチップ化の方向に進化する可能性も高いかと。

メニーコアって何のことか分かってる？

32コア以上はメニーコアっていうんだよ。Intel用語ではな。
あまったトランジスタの使い方の話をしているので、メニーコアvsシステムワンチップ化
っていう比較を出しているのだが、ソフト屋さんにはそういう流れは理解できないのかね。

なんでメニーコアとシステムワンチップ化が両立出来ないんだよｗ

8層基板必須にするか？
俺の予想では、PCI-Eｘは単なる噂にすぎず、
内部で評価はされてるかもしれんが、当分は出てこないだろう。
理由はメリットがほとんどないから。

CPUとGPUを統合したようなマルチコアはかなりメリット大きそうだが
（数Gで動作するGPU！、CPUと密接に連携できる！等）
大量のピンをメモリバスに割く必要があり、
（さらにCPUオンボードとなったり、MBが8層基板になったり・・・）これも不可能に近いだろう。

>>770
だよねえ。I/Oに使われてるトランジスタなんて多く見積もってもCPUコア一つに満たないだろうし。
PCIeやメモリコントローラみたいな比較的低レベルなI/Oならともかく、USBとかその辺統合する性能的メリットも全く思いつかんし。

ていうかトランジスタの使い道の話してたんだ。分からんかったよw

I/OがCPUダイに占める面積の割合はどんどん増加しているし、
I/O関連のロジックの量は馬鹿にできないぞ。

今後はI/Oの方がCPUコアより高クロックになるってのはIntelもAMDも認めているし、
実はかなり重要なんだが。

今すごい電波受信な人を見かけた気がしますが、錯覚でしょうか

>>764
やはりそうですね。Thx

漏れがメニーコアに悲観的なのは、PCに対する性能要求がすでに減退してきていると思うから。
自作オタ的には満足できないだろうけど。

PCは年々低価格化がつづいているし、今後、性能に対する要求がうすければ、
ワンチップ化、低価格PC、一人多数PCの時代に突入する可能性もありかと。

I/Oが重要なのは分かるが問題はコストに見合う性能向上があるかどうかだろ。
それにI/O統合が有効な分野ってあまり思い浮かばないなあ。


と思ったら低価格PCの話かよ。

ちょっと読めば理解できる内容だと思うけどな。
別にワンチップ化の話は漏れの前にもでてきているし、
そのまえはプロセスの進化が必要ないみたいな話もされてるし、
有り余るトランジスタをどう使うかってのは今の先端LSI技術の焦点なのだが。

＞TCP offload エンジンは、昨今の PC 用 Gigabit Ether カードも内蔵
＞してるけどね。

ハァ？

ワンチップ化の問題点はCPUとその他の進化速度が違うことだな。
随時性能を上げていこうと思うと開発費かかる。
ソフトウェアの進化にもついて行かないといけないし。
結局、性能を低く纏めた組み込みっぽくなりそう。GeodeLX800みたいに。

低価格向けって事はダイ面積も小さいって事だろうけど。
それだと高性能でダイ面積が大きいCPUはどう進化するの？

つかAMDもメニーコア志向だよ。

コアワンチップ化とまったく方向性は反しない。

Intel's new instructions to Rockton round the clock
http://www.theinquirer.net/?article=24781

SO, YESTERDAY WE TOLD you about AMD and integrated PCIe,
and that Intel had a bunch of goodies to compete with. One of them is called RT or Rockton Technology,
another in the long line of *Ts. With clock speeds basically stalled, you have to do something with those
transistors, and Rockton is one of the better ideas.

InquirerのRockton Technologyの記事でも、クロックを上げる以外のトランジスタの使い道
っつーことで、RocktonとPCIeの統合が比較されているわけだが。

AMDは32コア以上に関してなんか語ってたっけ？
別に、IO統合したから多数コアが絶対無理とはいわないけど。

オンダイでL3キャッシュ64MBとかやってほしい

メニイコアは♪だけにしてもらいたい

>>779
そんなに驚く話?
Intel だと i82544 以上のモデル (82547 を除く) とか、
Realtek 8169 とか、データシートを読めば、
TCP segment offloading のことが載ってるよ。

自作板の人間はこういう話はあまり興味ないのかな。

>>785
TCP segment offloadingなんて低レベルな物をTCP offloadエンジンとは呼ばない。

>>786
ああ、そういう意味で言ってたのか。
確かに完全にボード側で処理する奴もあるね。F社とか。
I/O 時の CPU負荷を考えると、たしかにそこまでやるのが
理想なんだけど、Niagara内蔵のTCP offloadエンジンって、
そこまでやるの?

>>787
やっていたとしても不思議じゃないよ。
特にメニイコアならSMPでTCPプロトコルスタックを処理させるよりも
非対称MPとして専任させるのも悪くない。

>>782
その記事は知ってる。
ただ、もしやるとしてもPCI-Eの先に何を繋ぐか？って問題がある。
鯖向けだからGigabitEtherくらいしか無いだろうと思うけど。
レイテンシを削減して意味がある物って他に何だろう。
やっぱあんま意味無い気がするんだよな。

あと、65nmや45nm程度じゃ熱対策も考えないといけないしトランジスタは全然有り余らないでしょ。
もっと遠い未来の話かと思っていたのだが。
IntelもAMDも近い将来ではコアを増やし続ける方向だし、（トランジスタ使う）
FSBやHTを強化してチップセット間を速くする方向性も一致してる。（チップセットのI/O強化）
それにマルチコア化するとメモリ帯域も増やさないといけないから、メモコンを統合してる場合はそっちでもピン数食われそう。
SocketFではFB-DIMMで4chとか勝手に期待してるんだが。


ちなみにIntelもAMDも"現状では"8コア程度が有効という考えでは一致してる。
そこでIntelは"将来は"メニーコアとぶち上げたが。
ソフトウェアの進化や仮想化ってのが出てきたからどこまで行くかな。

>>788
なるほど。
今の TOE 実装って、基本的にストレージ用途をターゲットに
してるから、TCP のオプションとか、ちゃんとサポートして
いるか、ソフト屋的には不安なんだよね。Web サーバでって
いうと、相手は遠距離だから、最低限、ウィンドウサイズとか
はちゃんと広げて欲しいんだけど、SAN だとそこまで遠い相手
は普通気にしないから… そういう意味で、TSO 程度の方が
性能は劣るけど、むしろ安心というか。
まあ Fのは太平洋越えとかデモってたから、ちゃんと実装して
そうだけど、他のベンダのはどうなんじゃろ。

>>790
TOEの内部で使われているOSは*BSDだったりするのでむしろWinなんかより安心と言う意見もある。
値段はまだ高いが・・・

>>558
今さらだが。
＞MMX(64bit) Latency 2clk、Throughput 1clk
＞SSE2(128bit) Latency 4clk、Throughput 2clk

これは、上は整数、下は浮動小数点の数字だよ。
Pen4のSSE2整数のクロック数は、Latency 2clk、Throughput 2clk が正しい。
しかも、Latency 2clk、Throughput 1clk の命令を２回やるとしたら、
Latency 3clk、Throughput 2clk となる（上位と下位は依存性がないので）。

Pen4のSIMDユニットは半速128bit（よって64bitのMMXには不向き）と考えるのが自然かと。

つまり、今後のCPUは、ノースブリッジ統合＆メニーコアの方向に進んでいく。
celeron等の低価格向けCPUは、メニーコアはせずにCPU上にビデオ機能も内蔵（ビデオメモリーとして、メインメモリから容量を１６メガほど剥奪）させる。

こんな感じ？

http://www.ne.jp/asahi/comp/tarusan/SMT-CMT.jpg

>>793
MediaGXおもいだした

が、すでにビデオ統合チップセットがほとんどをしめるこの時代
メモリコントローラ内蔵したらビデオも近くにおきたいというのは当たり前だしな

画面表示するだけでFSBに大量のアクセスがはいるのは望ましくないしな


>>794
本当にマルチスレッド化してたら２，４コアの性能上昇は上だからちとあてはまらんよ
しかも加速して性能伸びるもんか？

http://www.ne.jp/asahi/comp/tarusan/SMT_CMT.jpg

>>789
現状では、PARROTでも8コア以上は効果が薄いらしいな

>>794
これは何？
マルチプロセサによる性能向上を否定してんの？

次世代というかYonahについてですが
Yonahは殻付きですか？殻無しですか？

>>798
単石とtr数1/2の石*2を比べているの。

>>798
「HyperThreadingﾏﾝｾｰ」

前にも書いたけど、DualコアでもTr一定という仮定がそもそも現実と違ってるんだよ。
実際に出てきてる製品の構成を見て議論しないと机上の空論になっちまう。
微細化の限界より熱密度の限界に早くぶつかっちまったから、現状はTr余り気味なんだよ。
だからキャッシュ増やしたり、Dualコアにしたりしてるんでしょう。

>>802
たるさんの表はそもそもTejasの推定で書いた表
だからリーク等は考慮しないって前提で書いてる

その前提がそもそも現実とかけ離れてるから、ここで議論するに値しないと思う。
ここはintelの次世代CPUを語るスレだからな。 純粋な技術論としては間違ってないと思うよ。

現実

Athlon 64 4000+ (2.4GHz)　　　　平均価格*45,976円
Athlon 64 X2 4800+ (2.4GHz)　　平均価格109,133円

>>804
だからこそ、リーク問題が無ければなぁ…とは思うよ

熱密度問題がやばいなら65nm〜45nm・・・のCPUはそもそも出せない。
各社とも設計段階でホットスポットが出来ないように設計してる。

クロック上昇の一番の足枷は、現在の銅配線における「配線遅延」。

>>807
違うでしょ。微細プロセスでスピードを出そうとすると
リークが酷い。酸化膜の薄膜化で非常に不安定な特性が
出やすい。この2点を克服しないと製品として成り立たない。

>>808 リークはプロセスの改善で解決するが配線の遅延は難しい、
銅配線もローｋも一回限りの効果、あと残るのは３次元にするだけ。

http://pcweb.mycom.co.jp/articles/2004/01/01/moore/
＞そうですね。先日のパネルでは、配線の方がよっぽど問題だと

あほんだら　
配線の遅延が大きく影響するのは各部分のクロックを同期させるから。
そのへんよう考えてみ。

ﾌﾟﾚｽｺでは配線はかなり最適化が進んだけどな。
おかげでばんばんOCできるように。
あとは斜め配線を使えばさらに最適化出来るかな。

>>809
だからプロセス改善でリークは解決出来ていないでしょ。
夢を語ってどうするの？
配線遅延問題なんてその先の話だし、レイアウトである
程度回避できる問題。現状でもそうしているし。

>>810
2003年末時点では、リークはここまで酷いとは世界中で認識
されていない時代。
> トランジスタのリークも大きな問題だが、「配線をおろそか
> にしていいわけではない」と。
当然おろそかにしていいわけないですね。あたりまえの
事を言ってます。

そこでＣＮＴですよ

>>813
如何でも良いが、>>810はプレス子の問題が顕著化した頃の話

>>815
2003年10月に世間で騒ぎになっていたっけ？
勘違いであったならば、申し訳ない。

もうインテル以外なら誰の目にもプレスコの熱の問題は明らかだったのに、
インテルがまだ方針転換を決めてなかった時代か…
インテルほどのトップメーカでも、目の前の問題を見誤ることがあるんだ
ねえ。いや、むしろトップメーカだからこそ、解決できると自社の力を
過信したのか。

>>816
もっと早い、7月には話題に成ってた
ttp://pc.watch.impress.co.jp/docs/2003/0722/kaigai005.htm

激化する技術への挑戦 〜トライ・ゲート・トランジスタ発表の背景〜
http://pcweb.mycom.co.jp/news/2002/09/24/13.html
この夏、Prescottが熱い。来年は消費電力100Wオーバーへ
http://pc.watch.impress.co.jp/docs/2003/0722/kaigai005.htm
140Wへとひたすら走る? Intel CPUの消費電力
http://pc.watch.impress.co.jp/docs/2003/0725/kaigai006.htm
やはり問題はリーク電流に起因する消費電力とTDPの大きさ
http://pcweb.mycom.co.jp/news/2003/09/19/17.html
どんどん変わるPrescott FMBスペック
http://pc.watch.impress.co.jp/docs/2003/1010/kaigai031.htm

すでに、IA64では非同期が導入されてるからねぇ。 非同期使ってうまく設計すれば
配線遅延はそれほどボトルネックにならないと思ってるけど、どうなんだだろうか。

>>820
そりゃそうだろうけど
制作コストの問題が大変と聞いた
特にマザーボードなんかすんげえ高く付くらしいが

っttp://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2526

>>792
padd*系のlatency/throughput見てみろよ。
組んだこと無いのバレバレ

アラインメントされて無いデータに関してはMMXのほうが速い。

PreslerのExtreme Editionでは、
相対的に重い2つのスレッドを1つのコアのHTに割当てしまう
ポカは起こさないような改良はされてるのかな？
やっぱバカチョンのままなのかな？

>>824
それ、OSの仕事じゃないの？

latencyは据え置きだがthrouputは綺麗に2倍
一部はlatencyまで倍かそれ以上

Throuputっていうのはこの場合各演算ユニットのパイプラインで一命令の処理で食らうクロック数のことだろう。
MMX版で１クロック、SSE2整数で２クロック食うってのは、つまり64ビットずつ処理してるからなんだ罠。

Preslerってクロック200MHzふえるだけなんだよね？
Presler自体はHTOFFだったきがするが

次世代で解決されてればスレ的には問題なし。

>>827
炭もﾌﾟﾚｽﾗもHT有効なのはXEだけだよ

インテルはXEでるとは明言してなかったと記憶してたが

DempseyはHTある

PreslerからHTTonにするんじゃなかった?
どこかで読んだ気がするけど、多分俺の妄想の予感。

anandtech>>822や後藤の記事を参照しる
http://pc.watch.impress.co.jp/docs/2005/0816/kaigai01l.gif

そこで非同期設計ですよ。

PreslerでもPentium DではHTはオフ。XEではオンにされるだろうが、コアがなんになるかは分からん。
Paxville FSB1066になるのかDempsy FSB1066になるのか。両方の可能性が示唆されてる。
PaxvilleならFSB1333MHzも可能なはずではあるが・・・

英文はよめんが後藤のみたら予想としかかいとらん

今の状態でも熱がアップアップなのに、FSBを1066とかしたらますます手に負えなくな
るヤカン
プレスラが仮にうまくいったら、プレスコと同じくらいの消費電力に収まるのかな？
それでも熱いけど。

>>823
IA-32 Intel Architecture Optimizationを見たが、MMXが2-1、XMMが2-2だったぞ。
普通は、独立した2-1を２回やると3-2になるんだが、これについてはどう思う？

実際組んだことないってのはそう。普段はPenMで、P4は数日しか触ってない。
MMXのスループットが１なのは俺もなぜだかわからなかったのだが、
NetBurstは、ALUを倍速にして、複雑なとこはスピード落としてるらしいから
SSEのFPユニットは半速だと思っていた。
SSEのクロック数はほとんど偶数だし。

勘違いしてるようだけど128bit幅のデータブロックを扱う必要のある場面なんてほとんど無い。

たとえばフルカラーのDIBのデータを扱うのにしても、1ピクセルあたり8bit×４＝32ビット
現在主流の128ビットブロック暗号の多くの実装も、実行時間のほとんどを占めるS-Boxでは
64ビット＋64ビットに分けて交互にビットの置換を行っていく。
64ビット単位で扱うと有利なデータは数多いけど、128bit幅がないと遅くなるアルゴリズムってのは
あんまり無いんだ罠。
じゃあどうやるかというと、ループ回数を半分にして2回分のデータを扱うようにするだけ。

要するに、「MMXでは128ビットのデータを64×2に分解してたがSSE採用により1個で処理できる」
ってケースは稀で、
実際には、64ビット以下の単位で扱えてたものを、SSE2の採用により
ループ2回分のデータを1度にまとめて処理するということのほうが多い。

一度に扱うデータ量が増えても、その分ライトバッファの消費が倍増し、
かえってレイテンシを増大させることもしばしば。

レジスタの少ないx86アーキテクチャでは、ライトバッファ上にデータがあるかないか、
あるいはL1上にあるかないか、のほうが、性能に響くケースは多い。
論理算術演算のレイテンシより、ロード・ストアのレイテンシのほうが大きいからね。

そういう意味でPentium4でもSSE2整数の適用で性能が上がるケースってのは限られたケース。
John the Ripperだっていつまで経ってもSSE2は採用されないし（なぜならMMXより性能落ちるから）
Pentium 4でSSE2を使う意味は、16バイト境界に合わせたデータを同時にロード・ストアできることにこそある。
つまり、ほとんど、movdqaに集約されてる。
（それでもキャッシュのヒット率を落とすくらいならMMXでやったほうが速い。）

まあ、x64で論理レジスタの増えるSSE2のほうが結果的に速いケースは今後増えてくるだろうけどね。

>>838
＞勘違いしてるようだけど128bit幅のデータブロックを扱う必要のある場面なんてほとんど無い。
それはわかっているつもり。
MMXが得意なPenMでなら、SSE2を使うよりもMMXが速いのも経験している。
（P4では経験がないためわからない。MMXが速いケースがあるのは知っている）
>>838の内容に関してはほぼ全面的に同意。

で、それはいいのだが、俺はPen4のSSEユニットが64bitか128bitかを知りたい。
以下IntelのHPからの引用。


Pentium 4 プロセッサ内部では、各セクションが異なるクロック周波数で動作しています。
このように、各ロジック・セクションの動作周波数を最適化した結果、Pentium 4 プロセッサの
高いパフォーマンスが実現しています。最も高い周波数で動作しているのは ALU バイパス実行ループで、
プロセッサ・コア・クロックの2倍 (ファスト・クロック) で動作しています。これは、ほとんどの
整数プログラムの演算を行うもので、きわめて重要な役割を果たしています。このほかのほとんどの部分は
プロセッサ・コアと同じクロック (3GHz ファスト・クロックの1/2) で動作していますが、
これは設計が複雑になるのを防ぐためです。また、ファスト・クロックの1/4で動作するセクションもありますが、
これも設計を容易にすることを目的としています。バス・ロジックは100MHz で動作し、
システム・バスに対する高いニーズを満たしています。

補足。
俺はPen4のSSEの実装は半速128bitだと思っている。
64bitだと言うなら、paddd xmm0,xmm0がレイテンシ3でなく2なことや、
addps xmm0,xmm0（レイテンシ4）を連続で実行したとき１命令4clkになることを
（レイテンシ4のPenMでは１命令3clkになる。これは64bitずつ実行するため）
説明するうまい理由がない。

Yonahって945/955搭載ママンに乗りそうですか？

まぁ普通に無理だろ。
最近のIntelは新CPUには新チップセット必須な感じだし。

>>841
無理だろ
945､955は炭の
コアが別のコアのL2にアクセスする時チップセットを経由するんだから
まぁ詳しい事は分からんが

Presler→ConroeやYonah→Meromは同じチップセットでいけるみたいだが。

Yonahは478PINだったような

それも北森の478とは違うソケットだろう

>>844
俺は945､955
に関して言っただけ
後
Preslerは開発期間がある程度あったから
チップセットを経由しなくても大丈夫になったとかじゃない？
まぁ素人だからその辺りはよく分からん

調停用専用チップを別ダイで乗せるんじゃないのか？

>>846
炭/Preslerの構造は、石が2個に分かれている以外ほとんど変わらんが。
因みに、機能が足りない場合は対応できないけど、余計な物が付いていても対応可能だから、
案外945､955でConroeも動く鴨。

>>468
ふ〜んそうなのか
デュアルダイは面白いよな
Preslerの分のコアを
シーダミルに回せる訳だし

>>840
SIMD演算ユニットが128bit半速なら、MMX等の64bit演算のスループットも2になるのでは？
PUNPCKH** と　PUNPCKL**のレイテンシが違うのは何故？

>>847
それはPaxville

65nmコアは電圧が下がると思うので、ﾏﾏﾝ&BIOS次第の希ガス

>>850
同意。

半速云々はSSE2がMMXの2倍のクロックサイクルを要してるから出てきた勘違いだろうな。
もっとも有力な説は、64ビット等速で64bit単位でも128bit単位でも1μOPで扱えてるだけ。
実行時に２つぶんのデータに分解して2クロックかけて処理してる。

半速云々はSSE2はMMXとは別の専用演算ユニットがあると勘違いした香具師が唱えた説だろ。

スループット/レイテンシ関係は、
http://pc8.2ch.net/test/read.cgi/tech/1103609337/l50
でやった方が良くないか?
まあ、あっちの1か14あたりが出張してきてるみたいな感じだが。

Yonahのシングルスレッドレベルでのパフォーマンスの改良はほとんどSSE μOPsフュージョン
によるところが大きいと思う。
SSExが１μOPで対応できるからデコーダの負担が減りどのデコーダでも通せるようになり、
そのぶんSSExを使った浮動小数のスループットが改善される。
しかし、演算ユニットが増えてるかどうかは疑問やね。

YonahからはμOPｓフュージョンでXMMレジスタベースの演算も1μOPで扱えるようになるから
実質SSE命令帯域が増えたようなものだが、ユニット数やポート共有の縛りが改善されてなければ
伸びは少ないと見ている。

Meromではリアルで命令帯域を4issueに増やしてるが、これがどう出るかね。

実際のところPentiumMの現状の問題点はSSEなどを多用したエンコード系だけなんだし
それが一気に改善されて、デュアルコアでさらにブーストってことで
しばらくはノート用にするにはもったいない石になるのかね

現状でも780だっけ？あれはとんでもなくいい動きしてるけど

>>855
intelの方針としては、需要をノート、スリムに引き込んでX2（TDP89W/110W）を無力化したい、
と言った所だと思われ。

>>793
つ Timna

>>852
おい、MMXとSSE2は整数系以外は基本的に別だろ。

Ｔimnaはイスラエルチームの最高傑作

>>853
だね、態々亀レスしてプログラムの話を始めるからな…
それで大体スレが止まるから困ったもんだ

>>853
んじゃ、Pen4のSSEの話は、あっちに移動します。
失礼しました。

コンロって名前が悪くない？
プレスコットみたいに爆熱にならなければいいが。

そんなくっだらねぇ事で思い悩んで、心を痛めていらっしゃるのは、
全世界中でお前唯一人だけだ馬鹿。

>862
アメリカじゃあ全く問題無いぞ

アメリカじゃ部屋の照明に100�hのハロゲンランプがボコボコ付いてるってのは本当なんだろうか？

全室空調で問題なし。

>>857
今の、９０nmプロセスが余裕で実現出来てる今の世の中なら、Timnaを出す理由は大きいと思う。
低価格帯だけじゃなく、高価格帯でも、CPUがチップセット内臓なメリットは大きいはず。
昔と比べて、必要なダイ面積は半分以下なわけだし。

VIAやSiSから圧力受けて、中止になるかもしれないけどな。

>VIAやSiSから圧力受けて、中止になるかもしれないけどな。
これ笑うところですか?

>>862
「コンロー→コンロ→焜炉→爆熱っぽい名前だから悪い名前」っつー
発想は、例えば
「海→Sea→シー→シ→死→縁起悪いから海の呼び方変えたほうが良くない？」
と同レベルだってこと分かってる？

わざわざ日本の言葉を考慮して
名前をつけることはまずないんじゃないの
日本のみがターゲットになってるなら別かもしれないけど
どっちにしろアンチはマイナスな名前を無理やりつけてくるから関係ないんジャマイカ

ウンコ、チンコも特に問題は無いから大丈夫だろｗ

ヴィーヴテクノロジなんて日本考慮してない代表では
日本人には発音しにくい聞き取りにくい

>>870
しかし藁、ﾌﾟ、炭・・・糞コアだった。
河童、鱈、北森・・・良コア。
雷鳥、蓑、苺、真皿、偽皿、豚、黒浜、新城、勝銃、紅・・・。
AMDには外れがない。

AMDの話なんかしてないわけだが
厨房は散れ散れ

>>870
ガソリンのエクソンは、日本のことを考慮して名前を変えた
そうだよ。最初はエンコにするつもりだったそうな。(w

>>873
糞コアか良コアかは別としてペニスがあるだろ

製品名ならともかく、一部のマニヤしか気にしないただの開発コードに
他言語圏での響き云々とか自意識過剰もいいところだと思うが。


今回はPentiumって名称も変えてくるかもしれないから、そっちのほうがインパクトを与えうる。

>>876
>>873にはちゃんと紅って書いてあるだろ。

こじつけにも程があるぞ>878

心底どうでもいい

藁は感じが糞に似ているな。
今の時代、クロックでも効率でも負けるいいところなしだけどな。
コンロはどうなることやら。

INTELのメニーコアは、100個のコアーとかいっているが、
5年後にPentium４のことを考えると、コアが40個くらいか？
コアを増やす方が、クロックをあげるより難しそうだ。

はぁ？
フルセット揃ったコアを載せる必要なんてないんだから

SIMD専用だったり逆に非搭載だったり、単純なコアの物量を増やして
スレッド数で性能を稼ぐアプローチだろ。
現状でもクロックを2倍にするよりコア数をたとえフルセットのままでも4倍にするほうが簡単。

確かにそうだが、SMPの方が作るの簡単そうなんだが。OS含めて。
コア数は増えるだろうな。スレッドは４つまでならクロックよりありがたい。

>>883
そういう特殊戦向けがネットバーストだったわけで見事玉砕したわけだが

SIMD専用コアでもソフトライセンスは必要だろうか。ｗ

>>873
アム房が意図的にIntel製品には熱そうな名前を捻出していることに気づけよ。
大体、その手の名前をこのんで使っているのは厨房が多いからな。
まともな書き込みするやつはちゃんとした表記で書いてる。

>>886
SPEみたいな小さなローカルメモリで走るOracleが書けるかが問題だなｗｗ

「アム房」「アム厨」とかを好んで使っているのも真性厨房が多いからな。

メニイコアをやるんだったらフルセットかつ性能的に偏りのあるコアをいろいろ積んで
スレッド管理チップみたいなもんが動的に最適なコアにスレッドを割り振るようにするのかねえ。

>>890
普通にIRQLで管理するんじゃ？

全然関係無いけど、R500のShaderのハードスケジューラー
ってどんな実装してるんだろね？

>>891
どうだろうねぇ。
興味はあるけど俺にはちと高尚すぎる話題だな。
D3Dのプログラム書いたことないんで。
それと一応スレ違い。

>>887
そこに上がってるので熱そうな名前って炭だけじゃん。

CPUファンが止まったり外れりしたら即死するAthlonコアってなんだったっけ？

>>894
炭

>>891
IRQLって・・・何考えてんだ？

PS3のCELLとかその辺みたいなヘテロジニアスマルチコアは明示的にどのコアを使うか指定できるんだろうけど、
PC用はそうはいかないんで動的スケジューラ(?)がいりそうだね。

そのコントロール含めてCell（OS）だよ
だから、ユーザーは意識せずともコアが増えればスケーラブルに性能を伸ばすことが出来る

というのがウリ

箱360の2スレッド3コアのほうがはるかに使いやすそうだけどね

AMDは、今考えりゃK8以前はすべてはずれみたいなもんだったろうに…。

やはりメモリコントローラ統合は伝家の宝刀。
先に抜いた方が何とやら。

PPEのジョブスケジューリングや、分散型SPEカーネルは現時点では相当ウンコらしい
恐らく8個(7個)のSPEのうち半分は不良債権と化す

そもそも開発チームは冗長性を見込んで多めの6個と検討していたのに、あのおっさんが余計なことを

>>900
そんな気もするがインテルは一生抜かなそうなんだよ。

どのみちNetBurst路線でもAESアクセラレータとかは載せる予定だったんだろ。
Javaや.NETのアクセラレータは乗っけて欲しいね

FB-DIMMの世代では、抜くという話も。

>>904
確かにナ

Whitefield の世代で抜くことは決定済みじゃないの？ 2007Q2 だっけ?
順調に行ったとして、デスクトップやノートだと 2007H2 か 2008H1 ぐらい？

ノートを中心に今のマシンのほとんどはすでにUMAになってるから
メモリコントローラがCPU側に来るとデメリットもそれなりだよなぁ

メモリ → GMCH → ビデオ
が
メモリ → CPU → ノースブリッジ → ビデオ
と1hop増えるわけだから、ビデオチップに対するレイテンシは
犠牲になるだろうね。

ただ、ビデオチップの仕事はストリーム処理なわけで、
レイテンシの影響は軽微な筈だから、バンド幅さえきちんと
確保していれば、実のところ悪影響はほとんどないんじゃないの？
既にそういうアーキテクチャへ移行している Athlon 64 の方が、
Pentium 4 よりもゲーム系のベンチマークではむしろ高速なこと
が多いってことは、この推測を裏付けていることになると思うん
だが。

たぶん、メモリコントローラ内蔵で改善される CPU のレイテンシ
の影響の方が、ずっと効いているんだろうね。

それのデメリットってのは従来と違う実装が必要になるという
チップセット設計側の手間の問題で性能的問題ではない。

>>908
そらディスクリートな3Dグラフィックスの話であって、UMAなシステムではちょっと事情が違うだろう。

なんせ使えるメモリ帯域がIntel用なら最大800MHz/128bit(DDR2-800 DualChannel)なのに対し、
K8では最大でも上り16bit(1GHz)+下り16bit(1GHz)でしかないからね。
UMAシステムではメモリ帯域はあればあるほどいいから、柔軟に高速なメモリを採用できるほうがいい。
レイテンシは大して問題にならんようだ。

レイテンシやパフォーマンスの問題ではなくて、
なにもせずとも常にDAC読み出しのためにバスが動き続けることが果たして
消費電力的にもいいことなのかわからん

ってことだ

　北橋にVRAMを混載すればいいのでは？

>>910
なんかいろいろ勘違いがある気がするな。
まず K8の HyperTransportの片方向の速度は 16bit×1GHz=2GB/s
ではなくて、16bit× 2(DDR) ×800MHz=3.2GB/s だろう？

それに Intelで最大800MHz/128bit(DDR2-800 DualChannel)というが、
現状、Intel 製チップセットでサポートされているのは DDR2-533
までだろう? 将来の話である DDR2-800 と引合いに出すのに、現状の
K8 のメモリバンド幅と比べるのは変だよ。

AMD は、来年頭に Socket M に移行して、DDR2 をサポートする。
それと同時に HyperTransport も 2.0 にバージョンアップし、
クロックも 800MHz から 1.0〜1.4GHz に向上する。また 16bit 幅
というのは固定ではなく、2bit 〜 32bit までの幅を選択できるから、
2.0 で 32bit 幅を選べば片方向 11.2GB/s までサポートできる。
この世代になると、片方向のみの場合で DDR2-800 DualChannel と
ほぼ等速、トラフィックが双方向ある場合は倍の性能となる。
というわけで、まったく遜色ない値なんだが？

>>913
ああ、HyperTransportについては間違ってたようだ。Up1GHz/Dl1GHz DDRで8GB/sかな。
でもメモリはいまだにDDR400のDualだから6.4GB/sだね。廉価機だと3.2GB/sか。

先の話はともかくとして、現状でメモリコントローラ内蔵のK8用チップセットでは広帯域のメモリを提供できてないことは事実でしょ？
DDR2-800も当面先になってしまうし、しばらくはメモリ帯域に合わせて内蔵グラフィックスもそれなりにチープなものにせざるを得ない。
もうDDR2-800はすぐそこだし、DDR2-667も完全に軌道に乗ってるからね。

> HyperTransportについては間違ってたようだ。Up1GHz/Dl1GHz DDRで8GB/sかな。

その 1GHz, 8GB/s って値はどこから拾ってきたんだ？
現状、Athlon 64 や Opteron の CPU間リンクに使われている HyperTransport
のバンド幅は、PC3200 デュアルチャネルと同じ片方向 6.4GB/s だよ。
ttp://pc.watch.impress.co.jp/docs/2003/0916/kaigai023.htm

もっとも Opteron は HyperTranport リンクを 3本積んでいるので、
その意味では、さらにその 3倍のバンド幅があるわけだが。

> 先の話はともかくとして、現状でメモリコントローラ内蔵のK8用チップセッ
> トでは広帯域のメモリを提供できてないことは事実でしょ？

DDR2 をサポートしていない以上、ハイエンドでのメモリ帯域では現状負けて
いるのは確かにその通りだな。
ただ、UMA の主用途はグラフィック統合型チップセットなので、現時点で
これは全く問題になってないと思うんだがどうよ？
グラフィック性能をちょっとでも気にする場合に、チップセット統合の
グラフィック機能を使う奴はおらず、必ずビデオカード側にメモリを搭載
するからな。
チップセット統合グラフィックのように、プアーな性能しかない場合には、
6.4GB/s でもむしろ余るぐらいなんじゃないのか？

> DDR2-800も当面先になってしまうし、しばらくはメモリ帯域に合わせて
> 内蔵グラフィックスもそれなりにチープなものにせざるを得ない。
> もうDDR2-800はすぐそこだし、DDR2-667も完全に軌道に乗ってるからね。

DDR2-667 や 800 が、グラフィック統合チップセットの主ターゲットである
安価なマシンで使われる時代には、Socket M が普及しているから全く問題
なかろう。双方向で見るとインテル系の倍のバンド幅になるから、むしろ
インテルの方がヤバいんじゃないのか？

おっとっと、今年に入ってから 1GHz 8GB/s 版が出てたのか。
失礼した。

今年に入ってからというのも語弊があって、Athlon 64 の方は
去年からだったんだな。ちょっと目を離してるとすぐ時代遅れ
になっていかんな。

あと、気になってもう一度調べてみたんだが、
HyperTransport のバンド幅として >>915 に挙げた後藤氏の
記事は誤りで、やはり俺が最初に書いた >>913 が正しかった。
クロックが 1GHz に上がっているから、片方向 4GB/s という
ことになるな。
例えば
ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33425.pdf
を見れば、
One 16-bit link supporting speeds up to 1 GHz (2000 MT/s)
or 4 Gigabytes/s in each direction
とはっきり書いてある。

DDR-400 メモリでもデュアルチャンネルだとバンド幅が足らない
計算になるが、問題になってるって話を特に聞かないのは、
やはり UMA で使われるグラフィックス統合型チップセットの
性能がプアーなせいじゃないのかな。

>>908
CPUコアアーキテクチャが全然別物だから、メモコンの実装の差異がパフォーマンスを決めてるという
論調はおかしい。