x86の次世代CPUについて総合的に語ろう

x86の次世代CPUについて総合的に語ろう。

関係スレ
Intelの次世代CPUについて語ろう 21
http://pc7.2ch.net/test/read.cgi/jisaku/1136822334/

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

>>1
良い考えだと思うんで，頑張って欲しいす。

>>1
スレ立て乙なので，頑張って欲しいす。

乾流スターのビョン・ドン・ゴンさんに聞いてみたらいいと思います

・CPU Power Consumption (Burn)
ttp://www.xbitlabs.com/images/cpu/athlon64-fx60/cons.png
110.4W : Athlon64 FX-60　(2.6GHz dual, L2 1MB×2, 90nm) TDP 110W

ttp://www.xbitlabs.com/images/cpu/pentiumm-780/charts/cons-1.png
27.0W : Pentium M 780 (2.26GHz, L2 2MB, 90nm) TDP : 27W

次世代の話題をお願いします。

化紫苑もここでイイですか？

（x86命令デコードに対応した）μOPsを実行するRISCプロセッサについて総合的に語ろう

>>8
そのμOPsを直接実行できるならRISCと認めてやってもいいけどね。

Transmetaは完全に終わってしまったのだろうか。

>>12-1000 の予測

スレの9割は過去のx86CPUについて語るスレになる！

>>8-9
誰もが考えるような仕掛けだが
今まで実現しなかったのには何か理由があるに違いない。

>>9
Pentium 4って、もしトレースキャッシュに直接μOP転送さえできれば、直接実行できそうじゃね？

さらばIPC
http://www.ne.jp/asahi/comp/tarusan/main81.htm
高クロック化とx86命令の分解
http://www.ne.jp/asahi/comp/tarusan/main89.htm
CMS由来のatomとx86由来のatomの併行動作
http://www.ne.jp/asahi/comp/tarusan/main101.htm
x86命令の分解数と実行ユニットの比率
http://www.ne.jp/asahi/comp/tarusan/main105.htm
CPUのリストラ
http://www.ne.jp/asahi/comp/tarusan/main113.htm
ILPレベルとデコーダーのバランス問題
http://www.ne.jp/asahi/comp/tarusan/main124.htm

つまりこのスレもあれだろ、

インテルとＡＭＤの議論ってこれだな
ttp://www.uploda.org/uporg305087.mp3.html
ずーーーーーーっとこの議論やってるだけみたいなｗ

誤爆すんなよ

>>13
それをやっちゃうとItaniumのように進化の過程で
ふるいμOP ISAが単なる足かせにしかならなくなるからじゃないかな

>>17
違うと思う。
x86系CPUの最大のウリは、過去のソフト資産が生かせること。
足かせなんて最初からわかってることだけど、これだけは外せない。

また、仮にμOPが動くとしてもNetBurstでしか動かないコードに何の意味がある？
逆に次世代CPUでそれを動くようにできたとしても、それが新たな足かせになるだけ。

Pentium IIIまでの最適化手法＋αなPentium Mベースのアーキテクチャが残ったことで
Pentium 4の最適化ノウハウ（追加命令はともかく）って結局無駄になったと思う。

どっこいmeromのアーキテクチャはまだ未公開。

Merom予想の途中経過
http://www.ne.jp/asahi/comp/tarusan/main122.htm

その個人のサイトあてにならんだろ

>>19
そう言えば、X11の話は如何成ったんだ？反省した？

俺にまとわり付くことだけが生きがい？

>>23
反省した？

って何様だよｗｗｗｗｗｗｗ

反省した？

前スレの埋め完了しました。


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

1000 名前：Socket774[] 投稿日：2006/02/06(月) 08:50:19 ID:s6E10/wH
1000なら柏原芳恵とセックスできる。
1000なら競泳水着姿の柏原芳恵とセックスできる。
1000ならメイドさんの柏原芳恵とセックスできる。
1000なら秘書スーツ姿の柏原芳恵とセックスできる。
1000ならブルマー姿の今の柏原芳恵とセックスできる。
1000ならスクール水着姿の今の柏原芳恵とセックスできる。
1000なら春麗のコスプレをした柏原芳恵とセックスできる。
1000ならバニーのコスプレをした柏原芳恵とセックスできる。
1000ならハイレグレオタード姿の柏原芳恵とセックスできる。
1000ならDOAのティナのコスプレをした柏原芳恵とセックスできる。
1000ならミスアメリカのコスプレをした柏原芳恵とセックスできる。
1000ならセーラ服のコスプレをした今の柏原芳恵とセックスできる。
1000ならけっこう仮面のコスプレをした柏原芳恵とセックスできる。
1000ならミニスカポリスのコスプレをした柏原芳恵とセックスできる。
1000ならスチュワーデスのコスプレをした柏原芳恵とセックスできる。
1000ならキュティーハニーのコスプレをした今の柏原芳恵とセックスできる。
1000ならモリガンのコスプレをした柏原芳恵がアナルセックスさせてくれる。
1000なら不知火舞のコスプレをした柏原芳恵が俺の乳首を弄りながらフェラしてくれる。
1000ならセーラー戦士のコスプレを一通りした柏原芳恵がディープキスをしながら手コキしてくれる。
1000ならコギャル姿の柏原芳恵が俺のアナルを舐め、乳首を刺激しながらローション付きで手コキしてくれる。
1000なら攻殻機動隊の草薙素子のコスプレをした柏原芳恵が淫言を言いながら俺の前でバイブオナニーしてくれる。
1000なら透け透けピッチリ胸あきブラウスにタイトミニの女教師ルックの柏原芳恵が生姦＆膣内射精させてくれる。

1000なら柏原芳恵が結婚してしてくれて、四六時中、淫らなセックスで俺様に御奉仕してくれる。
そして俺様の遺伝子で柏原芳恵が孕んでくれる！

使えるトランジスタ数が増えたら、まずはx87とSSE演算ユニットの強化だろうな
今のSSEユニットは、IntelもAMDも64ビットずつしか演算できない不完全なモノだし
Merom/Conroeで128ビットを一気に演算する浮動小数点SSE演算ユニットがつくってホント？

x87に関してはもう切り捨てだろ

http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_Porting_Win_DD_to_AMD64_Sept24.pdf
＞Microsoft Windows for AMD64 will not context switch x87, 3DNow!, MMX for 64-bit native threads

64ビットOSは32-bitスレッドではx87と3DNow!をサポートするけど、64-bitスレッドではしないだろう。
64ビットへの移植を考えるとx87と3DNow!を使うのやめてSSEとSSE2だけで書いとくといいよ。
って趣旨のことが、AMDの最適化ガイドにも書いてあった。スマソ。
ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF

反芻した？

現実には80bit(1bit+15bit+64bit)精度浮動小数がある都合でx64でもx87は利用可能だったりする。
でもx87/MMXの切捨てが完了しないとSIMDユニットの128bit化→XMMレジスタで４倍精度浮動小数の実現
という流れにいつまでも乗れないジレンマ。
128×1より64×2のほうが速く処理できるものが多いしね。コレを言うと卵が先か鶏が先かの話になってしまうけど。

SSEがリアル128bit化すれば、シフト演算や水平演算周りでもうちっとリッチな命令の実装も
可能になると思うのです。AltiVecのvpermの移植は無理だろうけどね。

現実には64bitの移行が大方完了し、「MMX使った演算を高速に動かしたい」って需要が縮小してきたころに
128bit×1にようやくなるかと。

もちろん「128bit×2でMMX(3DNOW!)利用時は下位のみマスクして64bit×2として利用」という
路線になる可能性もあり。
しかし、そこまでしてSIMD増強するよりは、メニィコアのためのx86のISAを引きずらないリッチな
SIMD専用コアの標準化を進めるのでは、という予想もできる。

おっと、リッチなコアはヘテロに向かないな。
３オペランドでレジスタ多数、インオーダというCellのSPE的なものを予想している。

結局一時のクロック競争ですぐに10GHzにも到達するぞ、っていう流れは
完全になくなったのかな？

http://www.itmedia.co.jp/enterprise/articles/0602/07/news011.html

>>31
リアル128bitもいいけど、64bit*2という手で来るんじゃないかな。
128bitにすると作りづらいように思うし、SSEは命令体系自体に64bit臭がするから。

スカラ倍精度とパックド倍精度の命令が同じレイテンシになったら
著しく高速化するプログラムもあるんじゃない？
K10でもSSE演算ユニットの128ビット化の噂があるみたいだし

>>35
4倍精度は128bit化必須かと。

パックド整数および浮動小数だけど、64×2で実装してるいまの方式だと、
（Yonahみたいな上手い方法を使ってるならともかく）デコーダの負担が大きい上に、
命令帯域を2倍消費するので単純にユニット増加によるスループットの向上が図りにくいのでは。
整数演算に関しては64bit動作時の汎用ALUとSIMD整数ユニットとのスループットが逆転してるんで
煮ても焼いても食えない状況かと。

もちろん8bit, 16bit, 32bit単位のパックド演算ができるにせよ、あんまり汎用的に使えたものじゃない。
しかし128bit化すればたとえ１基しかなくとも十分意味はある。
3issueで最大128+64+64=256bit同時処理が理論上可能に。

ねえ、なんでヨナァはパイ焼きが速いの？
詳しい人おせーて

ヨナーって、パイ焼き速いヨナー。

パイズリしか興味なし。

>>38
L2キャッシュの容量が2MBだからだと他スレで言ってた。
2MBあると、パイの場合はヒット率が極端に良くなるそうだ。

…ということは、ダブルパイだとYonahでも遅いのかな？

>>41
一応補足。
YonahはL2キャッシュが2コア共有で2MB。
シングルπだと2MBをほぼフルに使えるが、
ダブルπだと約半分になるはずという話。

PentiumDやAthlon64X2はL2キャッシュが独立なので、
ダブルπでもあまり性能は変わらない。

Yonahではシングルπよりダブルπが遅いのはその通りだが、
一般的なクライアントPCではこのような説明の方が的確。

−−−−−−−−−−−−−−−−−−−−−−−−−−

PentiumDやAthlon64X2はL2キャッシュが独立で1MB×2。
ダブルπだと2MBをフルに使えるが、
シングルπだと半分（1コア分）しか使えない。

YonahではL2キャッシュが共有なので、
シングルπでもダブルπでも2MBのL2を
フルに使ったパフォーマンスを得ることができる。

>>41
その説明だと、PentiumMより速い理由になってない。
L2キャッシュの容量が同じでレイテンシはYonahの方が長い。
俺はYonahが速いのはL2帯域の向上のせいだと思う。

>>37
４倍精度って本当にすぐ実装されるのか？
それに、Meromもμopフュージョンが実装されているから
命令帯域の負荷は小さいはず。
リアル128bit演算器を作るのは大変だと思うけどなあ。

PenDやPen4も2Mキャッシュだしなー

MeromはμOPｓフュージョンでもいいが、AMDの場合はアーキを根本から再設計する必要があるからな。
128bit化のほうが容易だろう。

32bitアプリケーションの多いうちはリアル128bit化は難しそうな気もス。

>>46
32bitアプリケーションとは関係ないだろ…

32bitはMMX禁止とかやってないからな。
特にSIMD的なコードを書いてなくとも少ないレジスタ数稼ぐためにMMXを使ってる例も少なくない。
64bit加減算もサポートしてるから簡易的には64bit整数レジスタとしても使える。

それを128bit化してMMXは下位をマスクして利用ということになると当然ながらMMX性能は半分に落ちる。

Meromは64bitALUを4つ載せているという話だから、
SSE整数に関しては64bit*4（128bit命令2つを1clk実行）とかできるのかも。

Athlon63で63bitの実現を

すげーツボにキタｗ
63bit CPUｗ

>>48
演算ユニット128ビット化で性能が落ちる理由がまだよく分からないのですが
もしかして現在上位64ビットと下位64ビットは依存解消的に処理されているのでしょうか？
>>49
いまSIMDやFP演算ユニットでやってるMMX/SSE演算をALUにやらせるってこと？
それはないのでは

>>52
2基ある64bitSIMDユニットを128bit×1基にしてしまうと、「2つのSIMD演算ユニット」としては使えなくなるじゃん。

2つの64bit SIMDユニットで無理やり1つの128bit SIMDユニットをエミュレートしてるのが今の状態。
（Pentium4は整数が64bitで2回通し、浮動小数が128bitで半速だったっけな？よくしらね）

IntelはμOPs Fusionで暫く逝くようだし、AMDなんかでも65nmではデュアルコアを縮小するのが
精一杯だろうから、128bit SIMDユニット×2は当分先になるんでね？

Intel Core with Altivec

これで解決

命令セットが違いすぎるんで共存不可能。
将来メニィコアを実装する際にSIMD専用コアとして実装するのが現実路線だな（まんまSPEか）

>>55
まあ冗談だｗ

そこまでするなら、Intel PowerPCでウィンテルともどもx86捨てて移行した方がいいしな

>>53
今のx86CPUには同じ処理ができるSIMD演算ユニットが2つあるのですか？
少なくともPen4とAth64では各種FP/SIMDユニットが一つずつだと思ってました

ALUと整数SIMDの実行ユニットを共通にするには
レジスタファイルの問題がある

>>57
MMXパックド整数ユニットは2基、ロード・ストアはPen4が128bitで役割が別々なの以外は
大概の実装は双方向64bit×2基。つか、アーキテクチャマニュアル見れ。

PentiumMでは、ALU*2、SSE整数64bit*2、FP_ADD*1、FP_MUL*1になってる。
で、ALUとSSE整数とFPは、実行ポートを共有している。
ALUとSSE整数が演算ロジックを共有しているかどうかは知らないが、
MeromがALU*4と聞くと、単純にこれらを倍にしたとも考えられる。
その場合SSE整数は64bit*4になる。

実際どうだろうね。本当に倍になっててくれたら嬉しいけど。

>>59
「二つの完全なFP/SSE実行ユニットの代わりに、FP/SSE movesとFP/SSE storeを
データプリミティヴに行う単純な二番目のポートでコスト・パフォーマンスを最適化した」
という意味の内容が10ページにあります。もしかして私、ものすごい勘違いしてます？
ttp://download.intel.com/technology/itj/q12001/pdf/art_2.pdf
>>60
Pentium �VではALUとSSE整数は別の実行ユニットだったと思います
Pentium Mでも別なのでは？
ttp://www.hardwaresecrets.com/article/270/6

演算器なんて2bitで充分なんだよ！

http://japan.renesas.com/fmwk.jsp?cnt=press_release20060209.htm&fp=/company_info/news_and_events/press_releases

そう、もはや時代は2bit

バタフライ演算が高速に処理されるのはいいな。パイ焼きが速くなりそう。
って、x86じゃないじゃん！！

>>61上
その記述は、SIMD演算の実行ポートが１つしかないという意味。
でも、128bit命令はスループットが2clk以上だから、毎クロック命令を発行すれば
2つある実行ユニットを活かせる。
ポート１にはいっぱいユニットがあって、そのポートでしか実行できない命令を続けても、
かなり並列実行できる。

Pen4のSIMDユニットは半速64bit*2と思われます。
128bitSIMDで上位と下位に依存性がないというのはPenMでもPen4でも使われている。

リアル128bit化については、Altivecのせいでクロック上げにくいとか聞くのでどうかと思った。
64bitでも、フュージョンしてやれば性能面でのデメリットはほとんどないし、
SSE3の水平演算や一部のアンパックなどは64bitの方が高速だ（扱いやすい）と思う。
FPに関しても、x64ではFPUの代わりにSISDを使うから64bitで個数を増やした方がいい。
＃俺も128bit精度のFP命令は欲しいけどナー。

>>61下
俺は、「実行ポート」が同じと書いた。確かに実行ユニットは違うみたいね。

ttp://www.agner.org/assem/pentopt.pdf
上リンクの86頁でPen4のMMXとFPは、二つの半速64ビット実行ユニットがあると結論されてますね
128ビット命令の二つの64ビット命令としてのアウトオブオーダ実行はできないとも言ってます
私は、64ビット命令が2レイテンシ/1スループット（128ビットは4/2）なので一つのユニットが二段に
パイプライン化して実行しているのだと思ってました

>>65
Pen4のタイミングはこうでないかな。
最適化マニュアルの記述、俺の実測共にこうなっている。
整数は64bitが2/1、128bitが2/2。
FPは64bitが4/2、128bitが4/2（上位と下位を並列実行するため）。

あと、64bitで2/1のユニット１個だったら、128bitは4/2でなく3/2になるはず。

addps xmm0,xmm0 / andps xmm0,xmm0 を繰り返すと、
Pen4では8clkで回る。タイミングは両方、公称4/2だからその通りの結果。
しかし、andpsをpand（2/2）に変えても結果は同じ。
このandpsとpandは動作が同じなのでタイミングも同じと思われる。

ではなぜaddps(4/2)とpand(2/2)で8clkかかるのか。
addpsは実は（4/2）*2=（6/2）の命令なのだ（と思う）。
でも普通はaddpsを続けると上位と下位でレイテンシが隠蔽されて4/2に見える。
それがand相手だと隠蔽できない。
>>65＞アウトオブオーダ実行はできない
というのは多分このことで、違う種類の相手にまではスケジュールが対応していないようだ。
PenMではこの場合も64bitずつ並列実行できる。

>>66
ごめんなさい。4/2ではなく2/2でした。
> あと、64bitで2/1のユニット１個だったら、128bitは4/2でなく3/2になるはず。
レイテンシの定義を、ある命令を始めてから同じユニットで次の依存命令が始められるまで
とすると、二段パイプの仮定で128ビットSSEを3/2でなく2/2としても嘘でない気もします。

Ath64では128ビット命令は、FMULとFADDの二つのパイプに分けられる場合にスループット1
片方のパイプでしか行えない場合はスループット1/2です。
Pen4で128ビット命令のスループットが64ビット命令の半分ということは、
やはり実行パイプは二本でなく一本ということではないでしょうか？

>>68
確かに3/2とも2/2とも言えますね。
Intelの最適化マニュアルの数字では、PenMは3/2になる書き方、Pen4は2/2になる書き方を
それぞれしている。Pen4は3/2になっちゃう場合があるので>>67みたいなこともある。
この辺は表記の問題かな。

で、64bit(2/1)*1と64bit(2/2)*2の区別って難しいんだよね。
68さんは、64bit(2/1)*1だと言いたいのだろうけど、結局どちらもほぼ同じ動作になる。
Athlonと同じだというのは状況証拠でしかない。
それに、そもそも64bitであればユニットが何個でも、128bitのスループットは半分に落ちる。

じゃあどちらかわからないのかというと、Pen4の内部では倍速で動作する部分と
半速で動作する部分があるので、SIMD部が半速と思われ、偶数の（2/2）が
正しいんじゃないかなあというわけ。

x87のスループットが1なんだが
SSEと実行ユニットが違うのか?

>>70
そこが唯一の謎。鋭いです。
80bit精度だからユニット違うのかな〜とか思っている。
ていうかプレスコのSSEレイテンシが奇数(;´Д｀)

プレス子のSSEユニットには半速のものと、2.5分の1速のがある
･･･んなわけないか

これまで半速交互で回してたSIMD浮動小数点の二つのパイプの中に
偶数or奇数段でしか働けないステージがPrescottではできたとか
全速4/1の２回回しで4/2だったものが5/1の２回回しで5/2になったとか？？？

所で此処は、x86命令の所要クロック計測スレの続き？

次スレが立ったあとの雑談。テンプレがどうこうの話にて。

982 名前：Socket774 ：2006/02/04(土) 22:48:48 ID:pQKfehTx
もともとIntelの次世代CPUスレでAMDの話をするスレ違いな人達を
隔離するために出来た隔離スレなので、スレが存在するだけで価値あり。
真面目にテンプレに文句言ったりしてるのはちょっと笑っちゃう。

986 名前：Socket774 ：2006/02/05(日) 00:41:11 ID:JUjr/4Y3
>>982
どっちでも同じような話が出るけど。
比較対象としては当然の話だし。

987 名前：Socket774 ：2006/02/05(日) 02:31:26 ID:siRO18eK
じゃぁ、「x86の次世代CPUについて語ろう」スレが立ったらいいじゃん。
と思ったが、どうせ双方のアンチ厨が最適化やら安定性やらで罵り合って
対決スレ化するのが関の山なんだろうな。

そろそろ埋めてもよくね？

988 名前：Socket774 ：2006/02/05(日) 05:40:24 ID:8muxG8Y4
双方の事を語るスレは、ただでさえ対決スレ化するのに
次世代なんてソースと妄想でどうにでも転ぶ話題を扱ったら、凄い事になりそう。



・・・ちょっと見てみたい気もするがｗ

989 名前：Socket774 ：2006/02/05(日) 16:40:19 ID:D3J/cLfs
立てました。

x86の次世代CPUについて総合的に語ろう
http://pc7.2ch.net/test/read.cgi/jisaku/1139125138/

↑がここの>1

>>27あたりからSSE演算ユニットの128ビット化があるかについての話題だったのが
途中からx86命令の所要クロック計測スレ（ム板）の連中（推定）が乱入してきて
どんどん話がずれていった、っちゅうこったな。

ttp://www.digit-life.com/articles2/cpu/intel-yonah.html
> Thus we can assume (it's confirmed by some sources) that Merom/Conroe processors
> will have 128-bit full-frequency floating point SSE arithmetic for all operand types.

ttp://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/H-I_roadmap.html
> 2007年以降の話として、真剣に検討されていることは間違いないけれども、時期、実現方法ともにはっきりしない。
> 各コア内のSIMD unitの128-bit化　　　　　20%

↓以下何事もなかったかのように次世代妄想対決スレを続行

将来的にはどうなるんだろ？
IPCをあげつつ、電力消費考えつつある程度の実行ユニットになりつつ・・・なのかな？

ＩＰＣは４が限界？まだいけそう？

>>77

IPCだけの話じゃなくなってきてるから。IPC向上に伴うパフォーマンスの向上と
トランジスタ消費コストが見合わないって話になってる感じか。
効率よくダイを使うなら、これ以上シングルスレッドの性能上げるより
マルチスレッドの方がトータルではいいんでは？って話じゃね。
Intelは急激なマルチコア派、AMDはやや慎重。
アムダールの法則があるけど、どう転ぶやら・・・。
むしろプログラムする側に大きな変革が求められるから
それをどう乗り越えていくか。

4Issueになったからって、実際に4近い平均IPCを実現するのは難しくね？

x86-64でレジスタが増えたから、コンパイラが依存関係のないコードを吐きやすくなった
だから、4IPCを狙うことにしたんじゃないかな

この場合、別に4IPCにならなくても、
前世代の3Issueより、平均IPCが上げられれば意味あるんじゃないの。

4IPCなんかピークでも無理でしょ。
64だって通常だと2も行かないくらいらしいし。

>>80
レジスタ数の増加はそんなに関係ない。
ナウいCPUではpush/popやmov*をレジスタリネーミングのヒントに使ったりして
並列実行で性能を稼いでる。
帯域・ユニット数が増えたら増えたでロード命令の投機実行とかに使える。

まぁ、Yonahの性能の30％増しを期待するなら間違いだろうな。

メモリアクセスが多少でも減れば十分じゃね？
デュアルコアでただでさえ圧迫してるんだし
リコンパイルだけなら10%程度早くなるだけでも万々歳っしょ

キャッシュがない時代のレジスタの数の差はそれはそれはすばらしい結果でしたな

>>28
その資料はふるいの？
Win64でもx87ステートはコンテキストスイッチの際、復帰・保存されるよ。

>>83
レジスタリネームはx86のレジスタ数制限によって使われているものであって、
コンパイラから見ればレジスタ数が多いほうがハザードが減らしやすくなるのはいいことでは？
そっちのほうがパイプラインやIPCの調節もしやすそうだし。

まぁx86-64のレジスタも少ないほうだから今までとあんまり変わらんか。

寅スレがない（話題がなくなったから次スレないとも言うｗ）のでここ借ります

Transmeta、CulturecomへのCrusoe売却を中止
http://pc.watch.impress.co.jp/docs/2006/0213/transmeta.htm

>>86
IA-64（論理レジスタ：整数128本＋浮動小数128本）でもレジスタリネーミングあるよ

だってレジスタリネーミングは偽オペランド依存性解消のためだもん
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%A6%E3%83%88%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC%E5%AE%9F%E8%A1%8C

>>88
×IA-64
○Itanium

レジスタリネーミングないIA-64実装もたぶん不可能じゃない罠
（そんなおバカなもん作られること永遠にないだろうけどｗ）

やぱ命令セットの互換を重視したまま性能うｐするのはOOOOOOOが必要なのか。

>>81-82
その点、PenMはIPCをさげないような設計になってるのはいいと思うんだよね。
Athlon64はIPCを引き上げるような設計になってるみたいだけど。

>>82
Pen4を1とすると、Athlon64シングルコアだと1.5〜1.7ぐらいかもね。（モデルナンバーから考えると）

>>90
IA-64はコケたも同然ですが何か？ｗ
結局、過去との互換性が重要なのよ。古いソフトがIA-32で書かれすぎたから。
古いエロゲとか古いエロゲとか古いエロゲが動かないと困るしｗｗｗｗ

>>82
単純にDhrystone MIPS値から見ると、Ath64は4.5 MIPS/MHz、
PenMは4.0 MIPS/MHz、Pen4は2.9 MIPS/MHzくらいはあるようだ。
x86はVAXより命令数が少なくなるのでIPCの絶対値は分からんが。

>>92
Athlon64≒PenM≒Pen4×1.5
かと思ってた

>>93
ソフトによっては若干変わるが感覚的にはそんなもんだね。

ALUとAGUがペアで各３基あるぶん、最大スループットはAthlon64のほうが若干高くなる。
（「若干」といったのはデコード・リタイヤメントステージがボトルネックになるから）
ただ、PenMはMMX/SSE2を含めて整数演算のレイテンシが短いぶん小回りがきくから、
PenM＞Athlon64になることも。L2キャッシュの容量・帯域・レイテンシもPenM優勢だね。

>>92
でもPenMのほうがIPC落ちにくいんだっけ？
確かにノートのほうがはやいし・・・

K6 vs Pen2もそうだったけど、IPCはK6の方が高かったが、Pen2はバックサイドキャッシュが効いて
結局はPen2有利な結果がでるプログラムが多かった

L2キャッシュ容量が豪華なPenMと、演算器が豪華なAth64が互角の効率になってる訳ですね。
ベンチによってはメモリ帯域も大きくきいてくるようですが。

>>94
でも、Pen�V→PenMでL2キャッシュのレイテンシは増えてるけどな

クロックも上がってるけど?

レイテンシをクロック数で数えるか時間で計るか。
クロック数で数えるとクロック上がればレイテンシも大きくなるわな。

同クロックのPen3とPenMで体感速度まったく違うからなぁ

ヒント：メモリ速度

DDR400のDualChannnelでも10倍近く違う。

PC133は理論上1GB/sくらいか。
DDRで実効速度がよけいに出るような仕組みでもない限り１０倍は厳しいんじゃないか？
DDR400のDualは理論では6.4GB/sなわけだし。
でも言われてみれば１０倍はすでに手が届く範囲だな。年もとるわけだ……orz

>>98
Dothan(10サイクル)→Yonah(14サイクル)でもL2キャッシュレイテンシは増えてる
だが、これが原因で成績が大きく落ち込んだベンチは今のところ見当たらない
Hammer(12サイクル)も長レイテンシだが、それで致命的になることはないらしい
Yonahは大容量の統合L2キャッシュのため、Hammerは大容量L1キャッシュとの排他統御のため
と理由は違うが、L2キャッシュレイテンシが大きいのはトレンドらしい

>>98
レイテンシは増えても、クロック当たりのL2性能はP3よりも上がっているよ。

PenMがP3より速いのはキャッシュラインサイズが増えたから（他にも原因あるかも）。
YonahのL2が速いのは、帯域が増えたからと思われ。

ハードウェアプリフェッチの進歩
Banias以降素晴らしい

テーブル参照は自動にせよ明示的にせよプリフェッチが使いにくいんだな
たとえばこういうのはどうしようもない。
http://www.dawgsdk.org/tripmona/index.php/optimization

テーブル全体をロードしておくにはL1のサイズが足りず、なおかつ、
テーブル参照の直前まで番地が確定しない。

こういうのは、L2には収まれば純粋にL2のロードレイテンシおよび帯域に依存するのだが
レイテンシ増加するとなれば、演算を複数束ねて相対的にレイテンシを隠蔽するしかない。
だがx86の少ない論理レジスタ数じゃ限界が見えてる。

もはやL1に収まる範囲内のテーブルに収めるしかなかろうな。
世知辛い世の中ですな。

むろん、モノによっては
「L2の大容量化でより大きなテーブルがスッポリ収まるようになった。マンセー」
という声もあるかもしれんがの。

CoreプロセッサはULVを除けば完全にデュアルコア専用マスクになるようですな。

>>107
マルチスレッドアプリなら、HTにより遅延を隠蔽…
というのが昔インテルが書いてたシナリオだったんだろうが、
Pen4の失敗により消えてしまった。

HTを使うとキャッシュのヒット率が下がるから、
Pen4のようなパイプラインが長いCPUだと
キャッシュミスが致命的なので遅くなってた。
でも、現在のPentiumMやIntelCoreのようなCPUで
HTを導入したら割といいのではないかと思う。

とはいえ、2本程度のHTではなく4本以上のHTでやらないと効果は薄いかも。
もちろん、実行ユニットの数は相応のものにする必要がある(4倍とは言わないまでも)。

ﾈｯﾄﾊﾞｰｽﾄはところどころに光る原石が（けっこう多く）ちらばってたのに
ﾊﾞﾗﾝｽの悪さなどで脂肪した無念なｱｰｷﾃｸﾁｬということで(・∀・)ｲｲ??

どんなアーキテクチャでもそれは言えるんだけどね。

結局はバランスをどう取るかで評価は決まる。

>>107のコア・ループ実行に要するクロック数の平均値
Pentium III(Coppermine)74万
Celeron(Coppermine)198万
この差の原因はなんだろう。
L2のレイテンシ?
Pentium III(Tualatin)77万
Celeron(Tualatin)78万

L2 chacheだろう。
128kには収まらないが、256kに収まるループなんだろうな。

(･∀･)ﾁｬｯｼｭ!!

つまり、こういうことでしょ
ttp://pc7.2ch.net/test/read.cgi/jisaku/1138610260/127

医者はどこだ！！！

AMDのL2キャッシュ容量がなかなか上がらないのはなぜ？
L1キャッシュはAMDのほうがはるかに大きいのに

何と比較して？
1MBまで出てるじゃないですか

インテルの製品は90nmで1MBから2MBに増え、今年中に4MBが出るそうな
でもAMDのAthlon 64は登場時の1MBのままで、Rev.Fでも1コア1MBが最大

単純にプロセスがintelに比べて遅れてるってのが一つ
数出すためにダイエリアを削らざるを得ないってのが一つ
とにかく、大規模L2を許すリソースがAMDには無い。少なくともミドルエンドまではね。

ミドルエンド

エンドミルなら知ってる。

マジレスすると「ミドルレンジ」が正しいよな。
エンドは端っこ。
「ハイエンド」とか「ローエンド」は端っこだけど、「ミドルエンド」は形容矛盾。

エンドミルかとｵﾓﾀ

次世代エンドミルについて総合的に語ろう

ねねね、寝ぼけてたんですよー

次世代レミオロメンについてこなぁぁゆきぃぃぃ

>>116
バスにまだ余裕があるから。
intelはquad coreでバス帯域が不足するのを見越して
今から2nd cacheの増量に向かっている。

どっかでK8同士(A64vsSemp)のベンチ見たけど、P4vsCele程に性能低下してなかったなぁ。
今のところ1MBあれば十分なんじゃない？ そう云う設計になってるとか。

A64：排他機構が足を引っ張ってあまり伸びない
Semp：排他のおかげで容量の少なさの割りにキャッシュのヒット率高い


てか、Celeronはバス帯域とかHT有無とかでも差別化されてるから。

>>116
L1が大きいのはトレードオフもある。AMDのL1は容量が大き目の代わりに
アソシエイティビティが2ウェイしかない。
どういうことかというと、番地の下位部分が同一のキャッシュラインが
２つまでしか存在できない。
偶にそれがボトルネックになる。

IntelはAMDのよりL1容量が小さい代わりにレイテンシの短さとアソシエイティビティを重視。
それをL2の広帯域と低レイテンシ（最近は広帯域と大容量、ハードウェアプリフェッチ）でもって補い、
性能を稼ぐ形。

>>128
そりゃそうだろ。
64vs旋風では、K8の要であるメモコン性能に差はつけられていなんだから。

>>130
そう言えば、intelとAMDのﾏｲｸﾛｺｰﾄﾞって大きさ一緒なのかな？

IntelがL2に割いているトランジスタをAthlonは別のことに使っているだけ
という気もする。

淫照はしばしば発熱に使っていた。
真空管仕様にすればいいのに。
http://www.unisys.co.jp/ENIAC/eniac06.html

>>118
X2だとAMDでも2MBだが。
Conroeは今のところ共有4MBでしょ？

それからIntelはPenDの9xxですでに4MB達成済み。

どーもintelのキャシュは、密度、電力、速度など
あらゆる点で優れてるキガスる
構成も巧み

おいらもあのバランスが絶妙だと思う。
PenMは神レベルだけど、でもNetBurstはPrescottで完全崩壊の希ガス。

>>135
AMDも65nmにシュリンクすれば、
経済的にみて4MBにできるっしょ。

なんでもいいけどAMDは65nmになったら排他キャッシュ廃止して〜廃止〜
もうSempronでも256Kじゃなくて512Kでいいじゃん。
この先の事考えるとどう考えてもガンだよ。

PenMって、そんなにいいか？
使った感触は、ごく普通って感じだが

>>135
1コア当たりと書いてあるでしょ。L2キャッシュがコア別なのと共有なのでは利き方が全然違う
>>137
Prescottでは、ボトルネックが別のとこにあってL2キャッシュ増えても意味ない場合が多いね
PenM系やHammerだと、演算器の効率が良すぎて、メモリアクセスにボトルネックが来ちゃう
今のところ、メモコン導入のHammerより大容量L2キャッシュのPenMのほうが勝ってる感じかな

>>139
一次キャッシュが増えそうな気もする。
まあどうなるにせよAMDの中の人がんがれ、と。

L1増やすと
レイテンシ据え置きならキャッシュラインのサイズも倍増しないといけない
キャッシュラインサイズを据え置きにするなら探索木を深くしないといけないのでレイテンシ増加
もしくはWay数削減でダイレクトマッピング化（最悪・・・）

丁度CellのSPEのローカルストアがダイレクトマッピングみたいな形か。
てかSPEでダイレクトに扱えるメモリがあの中だけだからキャッシュも糞もないわけだが。

AMDは、Bartonの時はL2を512KBに倍増して北森と戦ったが、
今回は大容量L3キャッシュでIntelに対抗するらしいね

今のK8で大容量L3キャッシュなんて大して意味無いと思うんだけどなぁ…
既にL2の容量はそこそこあるし、ダイレクトコネクトのおかげでメモリも低いレイテンシで扱える。
キャッシュ容量で出る性能差なんて僅かなもんだろ。

…もしかしてL3はダイレクトコネクトやめる布石とか？
だとしたら嫌だなぁ…

DEC Alphaを焼き直し中なんだろ

サーバー向けでは独立L2キャッシュは続ける意向だからL3キャッシュは必須。
32ソケットまでサポートするって言ってるしね。

ダイレクトコネクトをやめたくはないだろうけど、次世代の
RAM規格がどう転ぶか分からないから、一時的にやめざるを
えないかもって感じなんでしょ。

もうXDRでええやん…と思ってしまう。
Intelにシャブ漬けにされたJEDECよかRambusの方がパートナーとして信頼出来そうだし。

メモリってのはパソコンのメインメモリだけで使われてるわけじゃないから
簡単にはいえんのよ

簡単に言ってよ。
いや、簡単じゃなくてもいいから予測ぐらいしようよ。
「難しい」で済ましてちゃつまんなーい

現在PCはDDR1+DDR2
組み込み系はSDRAM→DDR1への移行中
VGAはGDDR3全盛
ゲーム機においては
Xbox360:GDDR3
PS2:DRDRAM
PSP:DDR1
(PS3:XDR+GDDR3)
PCにも使われる汎用品が使われてるのはこのくらい？

DDR1はAMDのDDR2移行により今後縮小するも、組み込み用に一定の需要を維持。
GDDR3とDDR2はメモリ業界の先の展望が読めないため、ある程度の期間主流になると思われる。
一部GDDR4の使用が始まっているが、まだニッチ。
GDDR4の普及だが、GDDR3の需要がゲーム用に確保されているので、
モジュールメーカーはGDDR3→GDDR4への移行を渋ると思われる。
また、GDDR4の需要自体も超ハイエンド以外あんまし無い。よって多分ニッチのまま。

個人的にはnVIDIAがXDRをPC用に採用→ATI+JEDEC内部崩壊と予測してるんだが…
JEDECは手詰まりな感がある。今回はRambusに負けるんじゃね？

メモリ製造だけじゃなくてメモリコントローラ側でもライセンス発生するから
メモリコントローラ自作が普通な組み込み系では大問題だろ？

組み込みは別に無理にXDRに移行しなくてもいいんじゃないの？
そもそもする必要が薄いし、今まで通りPCに1テンポ2テンポ遅れて
SDRAM→DDR1→DDR2でゆっくり移行していけばよろしいかと。

その先？その先の事なんぞ知らん。
組み込み系にDDR2が普及するまであと5年くらいかかるだろうし、
そのぐらいになったら次の展開も見えてくるでしょ。

XDRに行くくらいならGDDRにでも移行しとけっとこった。

メモリをママン直付けにしろと言うのか

とにかく
FB-DIMM→Rambus特許に引っかかって死亡？
DDR3→DDR2-800の本採用で急速にいらない子化
な状況で次世代CPUと対になる次世代メモリを探そうぜ、という事ですよお前等。

＞DDR3→DDR2-800の本採用で急速にいらない子化

「DDR2→DDR1-400の本採用で急速にいらない子化」と言われていたが
Intelが移行を強行した結果今夏のAM2でPCに関してはほぼ移行が終了しつつある。
つーわけで結局のところDDR3もIntelが移行を強行するかによると思う。

>>154
PCのメインストリームの後追いしてるからこそ
ノウハウがたまったりコストが安かったりしてるんだがな

で、何でキャッシュの話からメモリの話に成ってるの？

>>149
Rambusは大嫌いだけど、Rambusに訴えられたりして揉めるよりは手を組んだほうがいいかもね。
XDRを採用するかどうかは別としてね。

>>155
GDDRがメモリモジュールにできると思ってるのか？

>>160
確かに。
次世代CPUの話から、次世代メモリの話に変わってますね。

まぁメモリコントローラ内蔵が増えてきてるんで関係がないとも言い切れないからな

>>158
DDR2の時とは事情が違う。
DDR3をそのまんま採用すると1チャネルあたりDIMM1本というショボイ事態になる可能性大だからな。
DDR3を直で採用するのならDDR2-800x2でいった方が性能・容量的に圧倒的にバランスがいい。
まぁDDR3を採用する時にはメモリの更なる多チャンネル化を図るという手もありはありだが、
デュアルコアでもDDR2-800x2で帯域足りちゃうだろうし、DDR3はレイテンシが増える。
そしてDDR1→DDR2の時と違ってレイテンシ増大を補う技術があるわけじゃなし。
性能を考えるとあんまりいい手じゃないと思うんだよもん。
とにかくDDR1→DDR2と同じレベルで考えてるのはゴミうんこ
なんでDDR3が踊ってばっかでちっとも進まんのかちーと考えろ

>>159
つまらんレス返すなうんこ
組み込み市場は今の設備をそのまま利用→漸減で特に問題無いと分かったらさっさと次世代PCメモリについて考えろや。

>>160
いやさ、だってさ、AMDにとってはものすごーく重要な話だし、IntelもPARROTではダイレクトコネクト使うとか言ってんじゃん。
ダイの利用法を考える上でメモリの特性を考慮するのは非常に重要な事だと思いますです。
まぁIntelさんの場合は「うるせーとにかく大容量キャッシュ」という強引な手法が使えるんですが…


ごめん、みんな。
AMDの動きがあまりにのっそいからしびれを切らしただけなんだ…

いい机より いい秘書を
http://www.teu.ac.jp/kougi/tukamoto/ipsj/9909/ie9909.html
＞SDRAMやRDRAMのような、連続アドレス参照だけが速いメモリでは不満

PCインターフェイスのシリアル化に意欲的なIntel
http://pc.watch.impress.co.jp/docs/article/20010831/hot162.htm
＞パラレルインターフェイスを延命させたい業界

DRAMの前に立ちはだかる最大の壁グラニュラリティ
http://pc.watch.impress.co.jp/docs/article/20011130/kaigai01.htm
＞PC向けなら、RDRAMがいちばんいいソリューション

メモリインターフェイスもシリアルに。Intelのシリアルメモリ構想
http://pc.watch.impress.co.jp/docs/article/20011207/kaigai01.htm

Rambus上級副社長Steve Tobak氏インタビュー
http://pc.watch.impress.co.jp/docs/2002/0715/kaigai01.htm
＞DDRは醜い(ugly)ソリューションだと思う。

2006年にはDIMMスロットはたった1スロット/チャネルに?
http://pc.watch.impress.co.jp/docs/2003/0711/kaigai002.htm

RDRAMが拒絶され、FB-DIMMが受け入れられた理由
http://pc.watch.impress.co.jp/docs/2004/0911/hot337.htm

FB-DIMMに向かうIntelとその先
http://pcweb.mycom.co.jp/articles/2004/09/12/idf5/002.html
＞DDR4にあたる規格が持ち上がりつつある

Intel CPUはシリアルFSBへと向かう
http://pc.watch.impress.co.jp/docs/2004/1117/kaigai135.htm
＞「シリアルDRAM」になれば、さらにレイテンシーは小さくなる。

順調なDDR2 667、FB-DIMMの発熱問題について
http://pcweb.mycom.co.jp/articles/2005/03/04/idf1/

指針の分かれるDDR3
http://pcweb.mycom.co.jp/articles/2005/09/07/idf1/002.html

Intelのロードマップに影響を及ぼすFB-DIMM問題
http://pc.watch.impress.co.jp/docs/2005/1114/kaigai224.htm
＞Intelがやらないなら自分たち(ADT参加DRAMベンダー)はAMDと組んでやって行く

IBMとの共同開発で変わるAMDのCPU
http://pc.watch.impress.co.jp/docs/2006/0206/kaigai239.htm
＞DDR3については、AMDは明確に推進

>>165
乙

次世代CPUの話なら、IntelのConroe/Meromは整数論理演算器を強化するようだけど、
AMDのK8Lのサーバ向け製品は、浮動小数点演算器を強化するという話があります。
今のPenMとK8では、整数系実用ベンチではメモリアクセスがボトルネックになるのに対し、
浮動小数点系ベンチでは演算器スループットがボトルネックになることが多いと思います。
実装コストも違うと思いますが、どっちの演算ユニット数強化が効果大なのでしょうか。

AMDの動きがのっそいなんていつもの事じゃん･･･
Hammerなんて何年遅れたよ･･･

>>167
Conroeの4issue化はすぐにベンチスコアの向上にはつながらんだろうが、
将来のHT実装には必要だということじゃない？

>将来のHT実装
これ、頑なに否定＆非難する層がいるよね。
PentiumM系はパイプライン短いからストールしても実害少ないし、入れる必要ない"

ごめ、途中送信してしまいました。
入れる必要ない派、と
マルチコア化した今、HTTのような中途半端なマルチスレッディング技術は技術として必要ない派。
がいるわけだけど。
メモリレイテンシの隠蔽やら、ヘルパースレッド等、まだ使い道は十二分に残されていると思われる。(というかこちらが本命)

クロックをかつてのようにあげられなくなった以上、こういった別の機能で差別化するのにも
一役買う予感がするよ。

PARROTでスケジューリングが向上することを見越しての4 issue化

整数型が64bit化すると相対的L2キャッシュサイズが半減するから、
メモリレイテンシの問題はIntelのほうが深刻だな

>>170
HTみたいに密接に併走してるｽﾚｯﾄﾞが暗号鍵作ってるとﾚｲﾃﾝｼ変動から推測できちゃったとか

↑みたいに何があるかわかんないし
ﾒﾓﾘﾚｲﾃﾝｼ隠蔽だけ目的の同時には併走しない*MTしか生き残れないんじゃない？

実装の問題なのか、OSの問題なのかわかんないけど
速くならないからだろ、HTやっても
RISCチップでは、SMTやFGMTでみんな速くなってるんだが

x86は命令数が多いから、RISCに比べてスピンロックが多いじゃないの？
RISCの事はよう知らんけど

Conroe/Meromの4issue化は、イスラエルチーム開発のPARROTを導入するための第一歩のようですね。
4issue化の効果が出てくるのは、次々世代でトレースキャッシュと動的最適化が実装されてからですか。
ttp://www.cgo.org/cgo2004/papers/11_57_ROSNER_RONI.pdf

K8Lが本当にFP演算器を倍化するなら、128ビットSSE2命令のスループットが今の1/2から1になり、
スカラより1サイクル多かったパックドのレイテンシが、スカラと同じになるでしょうね。
ただし、スカラのスループットは倍増でも、パックドはDoubleデコードのせいで実効1.5倍かも。

他スレで見た話なんだが、Pen4でNOP命令がトレースキャッシュにキャッシュされないって本当？
TransmetaのコードモーフィングがNOPを削るって話は聞くが

効率アップで省エネ？(実行ユニットの共用)
http://www.ne.jp/asahi/comp/tarusan/main136.htm

実行ユニットの共有なんてどこのメーカーでも最初に研究やってるだろ
そもそも実行ユニット自体はネックにはなってないと思うけど

ホットスポットを改善する目的で使うならレスポンスがかなり悪化しそうだが

>>178 仕事で使ってるマシンでコソーリ実験した。どうみてもサボりです。本当にありがとうございました。
【環境】
マシン：ﾌﾟ640, WinXP Pro 
コンパイラ：VC2003 
プログラムソース：http://up2.viploader.net/mini/src/viploader14287.zip.html

【実行結果】 
256→93.824clock
1024→357.656clock
4096→ 1477.22clock
16384→16817.8clock
65536→ 66816.8clock

【考察】
NOPの個数が増えるにつれ消費クロック数が増える。
また、ループ内のNOPがトレースキャッシュの容量12KμOPsを超える個数になると
急激に速度が落ちている。
オンキャッシュの場合1/3+α倍、キャッシュミスすると1＋α倍のクロック数を要してる。

どうやらNOPもトレースキャッシュに入るらしい。
キャッシュに載ってる場合命令帯域が、キャッシュミスの場合デコーダ本数（1基）が
ネックになってる。なお、αの部分はOSのオーバーヘッドと考えられる。

【結論】
正直すまんかった。勘違い。
ただ、http://pc7.2ch.net/test/read.cgi/jisaku/1139114170/
の↓も明らかに間違い。きょうびのCPUのパイプラインが1issueなわけないだろ。多分3倍するとほぼ正しい。

944 名前： 933 [sage] 投稿日： 2006/02/28(火) 21:18:11 ID:k9AttTYF
最近のワカイ奴って、NOP並べてほぉら理論性能xxMIPS!!って通じないんだな… 
Pen4 670なら一秒間に38億回のNOP演算が可能なんだぜ。PenD950なんか68億回だぞ。 
FX-57の秒間28億回、PenM780の22億6千万回にくれべたら圧倒的じゃないか。 

>>175
HT入れるなら、実行ユニットの数をそれに見合ったものにすることが必要。
Pentium4はパイプラインがスカスカだからこそHTを実装できた(別の問題はあるが)。
だから現状のままの実行ユニット数でHT入れるのはナンセンスだが、
そういったことを考えて実装すれば効果は期待できると思う。

HTはPentium4でだいぶ印象が悪くなってしまったが、HT自体が問題ではないと思う。
HTを使うとキャッシュのヒット率が下がるので、Pentium4のようなパイプラインが長いCPUでは
キャッシュミス時のペナルティが大きいためかなり遅くなるのだと推測する。

>>181
MIPS値か…
昔はCPUメーカーが平気でそういうことやってたからねぇ。

昔というか今でもだろ

>Pentium4のようなパイプラインが長いCPUでは キャッシュミス時のペナルティが大きいため
そのペナルティの隠蔽のためのHTTだったわけだが。
実行ユニットも稼働時間より、空いている時間の方が長いわけで
その効率改善もHTTの良い部分だったはず。

他のCPUのSMTとかだとレイテンシ隠蔽の効果でてるけど
pentium4のHTの場合、エンコードとかレイテンシの影響がほとんど
ない処理でしか速くなってない
L1キャッシュ容量が少なすぎるのが原因なんだろうけど

>>185
熱湯はL1も多重化しないとダメだな
コアの上下左右にL1置いて切り替えれば最大４スレッドまで逝ける（？）

>>184
キャッシュミスによって空いた実行ユニットを埋める効果は確かにあるが、
それでも埋めきれず、スカスカだったのがPentium4の問題。

無いよりあるほうが良い事には変わりなさそうですが?

問題というか、もともと高クロック＆SMTを前提にしていたから
パイプラインはスカスカでもかまわない、というアーキテクチャ。

そもそも、パイプラインが長いとキャッシュミス時のペナルティが大きいというのが
意味不明。

えー

>>190
待て待て待て

190 Socket774 (sage) 2006/03/06(月) 10:48 ID:7CXRFsp+
そもそも、パイプラインが長いとキャッシュミス時のペナルティが大きいというのが
意味不明。

をいをい

Pen4でL1キャッシュミスをするとリトライが発生するので確かにペナルティは大きい。
リトライが発生する仕様なのは、L1レイテンシを短くするため。
そうまでしてL1レイテンシを短くしたいのは、パイプラインが細分化されているから
普通に作るとL1レイテンシが長めになってしまうため。
そういう意味では、パイプラインが長いから間接的にキャッシュミスのペナルティも
大きくなったと言えるが、一般的には関係ない。
なので>>190のようなレスをしたのだが、間違っていたら具体的に指摘ぷりーず。

確かに、キャッシュミス時に空くはずの実行リソースがリプレイに使われてて、
SMTで性能が上がらない、Pentium 4は意味不明だよな

それはつまり、パイプライン再充填の時間は
キャッシュミスによるペナルティには含まれない、という考え方か?

分岐予測の失敗

>>182が言っているキャッシュというのはトレースキャッシュのこと。
182がデータキャッシュのつもりで書いたなら182が間違い。

>>184の言っているペナルティの隠蔽というのはデータキャッシュのこと。

>>190は、182からのキャッシュ話がデータキャッシュについての話だという
前提で（思い込んで）話している。

>>199
データキャッシュのつもりじゃないよ。
パイプラインの話と絡めたからわかると思ったんだが。

Intelの次世代CPUアーキテクチャ「Core Microarchitecture」
http://pc.watch.impress.co.jp/docs/2006/0309/kaigai248.htm

わざとループを大きくしてトレースキャッシュミスさせるコード書いてみたことあるけど、
デコードネックで1命令/clkしか出ない。てか>>181に書いてる通りの感じ。

HT使っても物理的には1個のCPUなので、まぁHTなんてただの飾りです。
依存関係のチェインの長いコードを並列実行するのには有効かと思います。

ソフトによっては、HT使ったら速度が落ちるという奇妙な現象もありますなぁ
（2スレッド動かすにも起動するにもHT切ったほうが速いという不思議な事態）

ただの飾りでもパフォーマンスアップすることもあるんだから面白いよなwww
intelのSMT技術が熟成するためには必要な実装だったのかもよ?
将来的に見ればさ。
いつ例のSpeculative MultiThreading実装するのかは知らないけど。

新アーキのIDFで明かされた部分＋妄想を、ベンチ騒動のないここに書き込ませてください。

噂のMacro-Fusionはスキャン＆ピック段階での2つのx86命令の融合（比較＋分岐など）。
特定の連続命令を一括ピックして、μops変換前の"Instruction Queue"へ送るらしい。
一回のフェッチ幅は「６命令」という資料から、16バイトか。

Reservation Stationの部分が"Schedulers"という表現なのは、ALU、AGU、FPUへの命令で
スケジューラが別のPen4式を思わせるが、ALUとAGUへの命令は融合されているし、
レーンごとに別のスケジューラを備えているK8式なのだろうか？
「4 issue wide」はALU数ではなく、デコードから発行まで4並列でμopsを管理できる、
という意味のようで、3整数レーン＋FP/SIMDレーンのK8と似た構成？

PenMからALUとMMX/SSEが１つずつ増え、"FPmove"が３つある（３つは機能が違う？）。
MOVMSKPSなどのWIRE、シャッフルなどのPFSHUFの機能は、FPmoveにあると予想される。
発行ポート共用は変わらず、PenMにあったStore Data専用ポートがなくなって、
Pen4式にAGU専用ポート*2(Load/Store Address)+共用ポート*3の構成になったみたい。
SIMD FP演算器はFMul(x87共用)＋FAddの構成を変えずに128bit化（スループット1）。
128bitロード/ストアも一回で処理するようになった。

と、後藤が書いてなかったか？

>>205
後藤弘茂氏のレポートとはずいぶん違うような
むしろ>>204はCoreはHammerの丸パクリだと言ってるような

すげぇ不思議なことがある
yonahとかconroeとかこれだけの性能で、
ロードストアユニットが、ロード1個、ストア１個しかないって点
athlonとか、同クラスのRISCチップは
ロードストアユニットが、もっとリッチなのに

Athlonは2Load/clkだが、ただそれだけのことだ。
CPUの速さを決める要因は他に山ほどある。
単に設計思想の違い。

Yonahについて言えば、L2キャッシュがAthlonより圧倒的に速い。
Conroeはおそらく1Loadが128bitで2Load*64bitのAthlonと帯域は同じ。
それでも2Loadできた方がいいが、ユニットの構造やスケジュールの点で
Intelは1Loadを選んだのだろう（2だったら嬉しいけど）。
そうやってトランジスタを節約すれば他のもっと重要な機能の強化もできる。

128bitロードって昔どっかのCPUで見たような気がするが…気の所為か

>>208
AthlonはLoad/Store共用×２だろ。

>>209
NetBurstがそう

Merom/Conroeは4issueだから1クロックにLoadとStoreを発行しても
あと2命令は発行できる。（NetBurstは3-2=1命令)
これが圧倒的なパワーの秘密では。
これだけのロードストア性能があればXMMレジスタが8本しかなくても十分足りる。

>>210
何を指摘されているのかよくわからないけど、
それを言うならLoad/Store/ALU共用*3（ユニット数）では？
それにストアは1clkに1回までのはず。

ごめん、AMDの最適化リファレンス読んでくる。
これだとあくまでMMX/3DNOW!のがパフォーマンス出るのね。

K8Lってx87/3DNOW!をどうするのかって未だに謎じゃね？
x87や3D NOW!を1クロック2命令発行できるようにするか
それとも、128bitパックド浮動小数を1μOPsで扱えるようにするか

3D Now!は、そろそろ切り捨ててもいい希ガス。。
実効性能やベンチ評価を考えたら64bit性能を半分にしてでも128bit化
するべきだろうね（少なくともFPは。MMXはどうだろう）。
ただ、一部の3D Now!ファンを裏切るのが心苦しいが。

そういえば、MeromでのMMX性能はどうなんだろうね。

K7
ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
AppendixB: Pipeline and Execution Unit Resources Overview
　Execution Unit Resources
　　Load/Store Pipeline Operations

■ Two 64-bit loads per cycle or
■ One 64-bit load and one 64-bit store per cycle or
■ Two 32-bit stores per cycle

K8
ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
Appendix A Microarchitecture for AMD Athlon. 64 and AMD Opteron. Processors
　A.15 Load-Store Unit

The 12-entry queue can request a maximum of two L1 cache operations (and mix
of loads and stores) per cycle.

あれ、32bit*2なら2ストアもOK！？
隣のアドレスだったら32bit+32bitでまとめてストアするとかかな。
ストアしながらだと2ロードできないのも知らなかったな。

K7では Store は 32bitx2 で
K8では 64bitx2になった

ALU側はStoreを2つ実行できるけど
FPU側は1つしか実行できないのだろうか?

俺の知識が古かったようだ。ごめんよ210。

＞＞217

賠償するニダ！！！

アーキテクチャだけでガラっと性能が変わるのはインテルの怠慢だよね。
それはおいといて・・・

内部処理を全部256bitとか512bitとか1024bitとかでやってしまえば
もっと高速になるはずなんだけど・・・どうなんだろう。
3Ｇ以上のクロックは難しいのであれば、どんどんやってくれるしかないかと

>>219
俺もそういうのは夢見るけど、ダイサイズ・発熱などを考えると現状が限界なのでしょう。
怠慢てのは酷いな。CPU開発に何年かかると思ってるんだ。
IntelはCPUメーカーなんだから俺やお前よりずっとCPU作りに詳しいはずだぜ。

>>219
ｱﾌｫ

>>219
256bitVLIWで8命令同時実行はEfficeonがやってたでしょ。結果は・・・。

>>219
内部256bitとか、512bitってSIMDのこと?
だったら、ロードストアとかメモリ帯域が足りないから
演算器拡張しても速くならないんだよ
ちなみに64bit積和算を、4operation/clock可能なsx-8は
8プロセッサあたり、512GB/sのメモリ帯域

＞＞アーキテクチャだけでガラっと性能が変わるのはインテルの怠慢だよね
新コア出して速くなるのは当たり前だろ
ならないほうが問題だ

結局将来性(IA-64)より目先の利益(EM64T)取ったしな。

>>255
K8との競争上、仕方なかったんだろ

>>226
違う。K8以前からIA-64は見捨てられていた
・IA-32(x86)が永続(この業界では20年程度を指す)する

http://pc.watch.impress.co.jp/docs/article/20010829/kaigai02.htm

>>227
でもその時点では、HPCやサーバーはIA-64で行く予定だったはず
最悪のシナリオでも、メインフレームクラスでは
IBMのPowerと市場を二分してる予定だったろうし
エントリーレベルサーバーでも、itaniumがぽちぽち
使うはずだったと思う

痛は最初からトランジスタ効率悪すぎ
マルチコア化など何も想定してなかったとしか思えない。

Itanium最強
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2598&p=4

>>229
熱湯よりはコアだけなら小さくない？

しかしCISC VS RISCなんてやって頃が夢の様だな…

Sossamanはただの「Xeon LV」だそうです

http://pc.watch.impress.co.jp/docs/2006/0315/intel.htm

>>233 そりゃそうだろ、他に何を期待してたんだ

サーバー分野はあからさまだな。
新コア売りにしたくないと見える。
woodcrestが出てもXeonブランドで売るつもりらしい。

xeonとか、せろりんブランドはそのままでいくんだろ

こういう中途半端さが、どうも好かんね

いまのXeonが売れなくなってしまうと困るからだろ。
Intelは金の亡者なところがどうもいただけないよ、まじで。

企業である以上金の亡者であることは仕方が無いと思うが

独占環境がなければ、「金の亡者」企業は世間が潰す。
独占維持をしてるから、「亡者」振りはますます盛ん。

　　　 　ミﾐ ヽヽヽヽﾘﾘﾉﾉノノ
　　　　ミ　　 ,,､,､,､,､,､,､,､､ 彡
　　　　 l 　i''" 　　　　　　　i彡
　　　　.|　」　　　／'　'＼　　|
　　　 ,ｒ-/　　 -･=-, ､-･=-　|
　　 　l　 　　 　 ﾉ( ､_, )ヽ　　|
　　　　ｰ' 　　 ノ､＿_!!＿,.､　 |
　 　　 ∧ 　　　 ヽニﾆｿ　　　l 　　　239が正しい
　　 ／＼ヽ 　 　　　　　　　 /
　／ 　 　 ヽ.　 ｀ー--一' ノ/ヽ

これから４コア８コアって増えていくの？
コア増やす路線の次にはどんな計画があるのか気になる。
なんかコア増やすのもめちゃくちゃにクロック上げるのも、
電力とか熱ですぐ頭打ちになりそうだから。

>>242
そのまま能力が高いコアと、一部の仕事だけ速いが後はそれなりのコアの集合体
になって、山ほどコア増やす…しか出来ないな、今の所。

それでもメモリとの入出力には限界あるし、いづれどこかで頭打ちか。

しかし謎は解けない。(趣味のCore Microarchitecture考)
http://www.ne.jp/asahi/comp/tarusan/main137.htm

たしかにintelプロセッサって、実行ユニット数の割りに性能高すぎるよな

メモリーコントローラさえ搭載してないしね。
某会社の製品はレイテンシを鬼のように削る仕様なのに
あっさり追い抜かれてるんだから世話無いよ。
今まで見てきたのは幻想だったのだろうか。

>>246
メモリコントローラ搭載してても、そんなに早くないプロセッサなんてけっこうあるお
まあ、K8は性能向上が目的だから、第一線で戦える性能が必要になってくるが

実メモリにアクセスするプログラム書いてみれば
メモコン同梱の偉大さが判るよ

その代償も限りなく大きいわけだが

そんな代償を払いつつ、あっさり抜かれたw

【レポート】 IntelのCore Microarchitecture
http://pcweb.mycom.co.jp/articles/2006/03/21/intelcore/

インテルの次世代チップについて--「Pentium M」開発責任者に訊く
http://japan.cnet.com/interview/story/0,2000050154,20098951,00.htm

>>250
キャッシュが利く範囲でばっかり回るプログラムでは
4MB対1MBでは、勝負にならんわな
いまんとこ、出てるのはそんなプログラムのベンチだけだろうし

キャッシュ効きにくいベンチ
http://images.anandtech.com/graphs/conroe%20preview%20followup_03090640343/11150.png
http://images.anandtech.com/graphs/conroe%20preview%20followup_03090640343/11152.png

縁故って、書いたことないが
ベクトル演算性能で決まるっぽい印象が
ベクトル演算はコンロが上だろうさすがに
後出しでそこで負けるのはありえん

>>254
iTuneはしらんが、WMVエンコはMMX命令がほとんどでSSEをあまり使わない。
Conroeの128bitSSEユニットが生かされない例。

後出しでそこで負けるのはありえんってのは、
もう省電力にしても、整数演算なりトータル性能でも言えてしまう気が。

そりゃ、後出しで負けるのはありえんわな。
AMDも、後出しの後出しが完成するまで
当分の間守備ターンの運命は避けられん。

攻守入れ替え自体は毎度のことではあるが、
延命策がパッとしないのと、次が見えてこないのが不安ではある。

>>256
ネトバの頃は内部演算がMMX+MMX=SSEじゃなかったけ？

よーわからんが
縁故にキャッシュは利くのか？
非常に利きそうに感じるんだけど。

>>259
エンコに効くよ
ただそれより同じ処理をまとめて並列化しようとする
マイクロコードがintelのほうがAMDより数段進んでる
だから未来についても

intel=アムダールの法則から開放されるので
100個まで急速に移行するだろう

AMD=アムダールの法則の縛りで8コアぐらいから
緩慢になるだろう

と見解に違いがある

実際AMDのＣＰＵはメモリ間のレイテンシがすくないので
キャッシュにあんまり左右されない作りではある
ただしそれは一般的なソフトで

似たような処理の連続となるエンコードはやはり
intelのＣＰＵに多めのキャッシュのほうが得意だとおもわれる

馬力のintelと加速のAMDみたいな感じではないだろうか

>>259
大量の逐次データ処理だから、ほとんど無意味。

Cellとかの、ストリーミングプロセッサが典型。
ちっとやそっと増やしてもキャッシュが無意味なら、
シリコンをキャッシュに使わないで、その分のコア多数でなんとかしよう理論。

どっちだよ、意見ばらばらやん
縁故しないから、どうでもいいんだがｗ

巣エンコならセロリンDをOCして使うのがベスト

>>258
Conroeは(Packedな)SSEは1つのμopで済むでしょ。

これだけ頑張っても現行Athlon比で20%しか速くない。
AMD相手だから20%は全然セイフティーリードにはならない。
まだ出ていないけどデスクトップ用のホットバージョンCoreDuo比ならほとんど互角と思われ。
革新技術を投入して画期的な性能を発揮する、みたいな宣伝術にうかれていたけど冷静になってみると..

だといいなぁおいｗ
FX比較なのにConroeEX使ってないンﾀﾞﾖ?

つか、エンコはレイテンシじゃなくてスループット重視だから、メモコン搭載云々よりも
メモリ帯域と、大容量・高速なキャッシュと、強力な演算パイプラインが命だろ。

GallatinコアのP4EEが典型だが、L3搭載によりメモリレイテンシは増えたものの
Northwoodよりも格段にスコア伸びてただろ。
純粋にバスだけがボトルネックになるのはごくシンプルなブロック転送くらいだしね。
演算パイプラインの改善やコア数を増やすだけでも十分効果はある。

K8のメモコン・HT内蔵の強みは、多くのプロセスが同時に動き頻繁に
コンテクストスイッチの起こるサーバ市場にこそあるだろ。
一般のPC用には、キャッシュ大盛りで十分。

>>267
エンコなんて単純流れ作業じゃなくて
シミュ系のレースゲームとかハードコアフライトシミュみたいなのではどっち
が有利なの？

エンコというか、DCTや量子化はキャッシュほとんど関係ない。

まだ現実を直視できない奴がいるのか

エンコードで重要なのは、単純なプロセッサパワーだよ
演算器が多いとか、クロックが速いっていうチップが
単純に速い
だからpentium4でも性能を発揮できた、エンコでは

>キャッシュが利く範囲でばっかり回るプログラムでは
>4MB対1MBでは、勝負にならんわな

それ以上のプログラムなら匹敵するんだろうか?
どう考えてもマズ無理じゃね?
プログラムサイズは変わるけど、
AMDのキャッシュサイズが増えないことには
勝負になるも何も…

キャッシュだけで大差つかないだろ。メモコンで差がつかないのと同様。
Banias(1MB)とDothan(同2MB)で性能大差なかったり

無駄に巨大化してもキャッシュ自体のレイテンシが増えて遅くなるケースもありうるし
このへんはバランスが重要だと思う。

なんにせよプリデコーディングや命令のパッキング、統合メモコンなしで同クロックのK7/K8並みの
性能を発揮できてたPenMは凄いってことだ。

プログラムは局所性があるからキャッシュ容量の効果は飽和する。
普通は512〜1Mで飽和する。
レイテンシ短縮の効果は飽和しない。

>>274
複数の（スレッド）プロセスが動くサーバープログラムなら飽和しない。

サーバープログラムは >>267 も言っている通りメモコン内蔵も効果有る。
結局、大容量キャッシュだろうと低レイテンシメモコンだろうと効果有る。


エンコはバランスが大事としか言えない。
DCTや量子化だけでなく動き検出が必要で、画像２〜３フレーム分の
キャッシュ容量がないと同じデータを何度もメモリから読むことになるので
必要充分のキャッシュ容量は必要。
しかし、エンコはストリーム処理なのでそれ以上は必要ない。
ストリーム処理はメモリからのプリフェッチがしやすいので
ある程度のレイテンシはカバーできる。後は帯域と演算器の馬力次第。

結局、漏れが255に適当に書いたのが
ほぼあたりってこと？

マカーにPPC970に代わってitaniumを買わせれば、IA64が主流に成ると思う。
AMD64/EM64Tあぼーん。

>>277
970非互換の64bit、e700があるお（　＾ω＾）

無意味な仮定やね…

Intel CPUスレもIntel・AMD比較スレもあるのに、
Intel CPUの優位性とAMD CPUの欠点とAMDファンの人格否定を
繰り返し主張する人達がなんでAMD CPUスレに居るわけ？

>>280
君は真面目に勉強して進学してきたから
今まで目にする事が無かったかも知れないけれど
世の中には信じれないような馬鹿がたくさん居るって事さ

むしろAMD CPUスレは隔離スレとして活用するべきかと。
現状、AMD使いだろうがIntel使いだろうが、IntelCPUスレの方が有用であろう。

そろそろ暖房はいらないと思うが・・・

隔離スレのふいんきは断然 i のほうだと思うが

日によって違うみたいだ。
昨日あたりは、I再建A停滞スレが隔離っぽかった。

そっちは、名前からして隔離所だろｗ
行った事ねえよ

インテル次世代24スレmada-

Intelスレに503が来やがった・・・最近はまともな流れになってたのになぁ。

　　　　　　　| |::::::::::::::::::::::::::::::::|￣~`l;:;:;:;:;:;:;|
　　　 　 　　 | |::::::::::::::_;;;;;;;;;;;;;;;j . 　 |;:;:;:;:;:;:;|
.　 　 　　　　 | |::::::::::｢　　　　　 　 　''ｰ- :;;:|
　　　　　,. ::'';:;| |:::::::::::Ｌ. ...----i　　. _　 　||
　　 　 r'::::::::::;::| |:::::::::::::::::::::;:;:;:;:;|　　|;:~`''';:;!
.　 　 　|:::::::::';:';:| |:::::::::::;:;:;:;:;:;:;:;:;j　.　ｌ;:;:;:;:;:;:|
.　 　 　 |:::::::::':;:::| |;:;:;:;-―'; T''"'''ｰ〈､,_;:;:;:;:;!
　　　　　|:::::::::::';ゝ'"　, ,;/l,;､!. 　 　 };､)､`ヽ{
　　　　　 |:::;:-'" .;' ;'.j'A'-;j-ﾞ;、　　j_,!,j,';';　`i
　　　 　 　!"l　　l'; l ;j'_,,,.,.,_　ヽ　 __ﾉﾉｌ l l　, !
. 　 　 　　!　! .!　i'; ';.jl:;;::j. `　　　i:;:jヽjﾉ';'　ｌ |
　　　　　 | ';';, ';　! ';,'! ~~ 　 　 　 `" .!,!'j;' ,.!`!
　　　　　 |　;';; ':,　!. !'､ 　 　 　 ' 　 ,ﾉ,;',',','ﾉ　ヽ
. 　 　　　j}　'; ';, ':,jヾﾄﾐ' 　　`'''' _,. "; ;'ﾉ;'ﾉ　　　　　下がりすぎなのでageますね♪
　 　 　 ,;'　!　':,':,. ! ,;ヾ､`' ､.,,,. '"::::::!'ﾉ ｌ''!
　 　 　'　　l':, ._;ノ,,,',,_ヾ:､　ｉ'' ;　 ;' .;;、! ｉ !
　　　　　　 l >=＝＝､ ヾ､ｰ=､､ ; ';, ';, ','; ｌ
　　　　　　 j',.:'　　　 `:､ヾ;､;::`!,_:::','; ;,ヾ,ヽ!
　　　　　　;';'　 　 　 　 .ヽ''iヽ::::::`:.､;;'.:';ヾ,ヽ,
. 　　　 　 l 　 　　　 　 ::; `:!}､::::;:-::''ヽ;.: ';'.;':ヾ､
　　 　 　 i　　 　 　 　 .;'　 j;､`"　_,. -:;`､ i:';::';ﾞ;ヽ,
　　 　 　〈:.　　　　　 .::!:　　 ヽ. r':::::::::';:;:;iﾉ.:.i::!,',　ﾞ'
.　　 　 　 !:..　　　　.::::l::　 :. 　 !. !::::::,';:;:;:j.:..;'.:.j j
. 　 　　　　!:　　 　.:::::}::::　 ::..　.} 'i;:;:;:;:;:;ｨ　ﾉ;ﾉ '"
.　　　　 　 {::　　 .: :::::|:;::::. ..::::::::ｌ.:|:;:;:;:;/:`く
　　　　　　 }::　　　:::::|:,ヽ:::::::::::::j:.|;:;:;:;|:::::::::ヽ,
　　　　　　.}: 　 　 :::::|;:;i .}-―''7.:|;:;:;:;|:::::::::::::ヽ、
　　　 　 　{:　　 :　::::j;:;:j j--::::j:.:.|;:;:;:;:|:::::::::::　 ::L

intelやAMDが言うマルチコアやメニーコアって、
所謂ヘテロセクシャルマルチコアと呼ばれるもののことなんでしょうか？詳しい人教えて下さい。

>>290
君、面白いね。俺と一緒に吉本行かない？

>>290
http://search.impress.co.jp/cgi-bin/namazu.cgi?query=%A5%D8%A5%C6%A5%ED%A5%B8%A5%CB%A5%A2%A5%B9&submit=%B8%A1%BA%F7&whence=0&idxname=pc&max=20&sort=score
http://search.impress.co.jp/cgi-bin/namazu.cgi?query=%83z%83%82%83W%83j%83A%83X&idxname=pc

現在ﾊﾟｿｺﾝ購入予定なのですが、ｺﾝﾛｰがでるまで待てとみなさんに言われます。

時期はいつごろ出るのでしょうか。

わかる方いらっしゃいましたらよろしくお願い致しますm(__)m

>>293
一般に入手可能になりそうなのは多分今年年末。ただ、その時点でもVistaReadyPC
みたいな感じだからなあ。Vistaが出て、主要アプリがVista対応するくらいまでは
待ちだと思うけど。多分来年春にVistaなので、来年の秋以降くらい。

ま、その頃になると今度は4コアCPU？って言われるだろうから、また待ちだろうけどな。

>>294
　　----------------------
　　一般に入手可能になりそうなのは多分今年年末。その時点でもVistaReadyPC
　　みたいな感じだからなあ。
　　----------------------
アム虫のFUDご苦労様す。Intelの出荷計画わ､こんな感じす。
http://images.dailytech.com/nimage/1136_large_intel.png
年末にわ､そうとう潤沢に供給されるす。

誰も呼んでないって。

intel次世代ｽﾚで忙しいだろ?

>>296
今日の私の書き込みなら､AMD次世代スレッドの方が面白いかと。。。

ttp://it.nikkei.co.jp/business/news/index.aspx?n=MMITaa001028042006

>>298
ご自分かご家族の勤め先と比べて見ることをお勧めするす。
http://money.cnn.com/magazines/fortune/fortune500/snapshots/672.html

>>299
＞純利益は同38％減の13億4700万ドル
しかも来期からはＶ字回復（の予定）

クビになる香具師にとっては、これでリストラされちゃたまらんだろうなぁ
アメリカ流は厳しいなｗあっちは好景気だし転職できればまーいいのか

所謂独占利益体制の「ウィンテル」は、「テル」から破綻しようとしてるってわけさ。
おわかり？＞299

windowsにライバルなしなのを何とかしてくれｗ

信濃ってなんだろう、と一瞬思った

サーバでは、winもtelもアレになってきたけどね。

特急信濃でつか

Cell

windows関係のしなのって言ったらシナノケンシしか無いだろ。