Intelの次世代CPUについて語ろう 16プラン
4ソケットの場合、最悪値でXeonとほぼ同じ性能、
0hopや1hopならXeonよりいいわけで、全然問題
ないでしょ。しかも、これはNUMA対応してない
OSを使った場合の話で、OSさえNUMAに対応すれば、
8ソケットであろうと、別に問題ない。
さらに、インテルの次次世代CPUであるWhitefieldは、
君の評価基準だと、Opteron よりもさらに使い難い
石になるようだよ。その世代になったら、レイテンシの
点で有利なOpteronに乗り換える予定は立てててるの?
0hopや1hopならXeonよりいいわけで、全然問題
ないでしょ。しかも、これはNUMA対応してない
OSを使った場合の話で、OSさえNUMAに対応すれば、
8ソケットであろうと、別に問題ない。
さらに、インテルの次次世代CPUであるWhitefieldは、
君の評価基準だと、Opteron よりもさらに使い難い
石になるようだよ。その世代になったら、レイテンシの
点で有利なOpteronに乗り換える予定は立てててるの?
テスト
>>952
やっぱりわかっていないじゃんか。w
大規模マルチプロセッサマシンを作るうえでNUMA構成の
memory latency比はかなり重要な問題なんだよ。
OpteronとXeonではターゲットとなる範囲が違うのに
一つの尺度でしか比較しないのはおかしいだろ？
いや、それが厨房の特徴か・・・
やっぱりわかっていないじゃんか。w
大規模マルチプロセッサマシンを作るうえでNUMA構成の
memory latency比はかなり重要な問題なんだよ。
OpteronとXeonではターゲットとなる範囲が違うのに
一つの尺度でしか比較しないのはおかしいだろ？
いや、それが厨房の特徴か・・・
>952
>これはNUMA対応してないOSを使った場合の話で、OSさえNUMAに対応すれば（略
重箱の隅をつつくわけじゃないが、
プロセスがロカールメモリ搭載量を越えてしまうような使い方だと、OSが
NUMA対応とか関係ないやね。。
NUMA対応OSってのも、プロセスでのAffinity対応はしているようだが、
スレッドレベルでは未だ対応してない。
そんな完璧なものではないよ。
>これはNUMA対応してないOSを使った場合の話で、OSさえNUMAに対応すれば（略
重箱の隅をつつくわけじゃないが、
プロセスがロカールメモリ搭載量を越えてしまうような使い方だと、OSが
NUMA対応とか関係ないやね。。
NUMA対応OSってのも、プロセスでのAffinity対応はしているようだが、
スレッドレベルでは未だ対応してない。
そんな完璧なものではないよ。
性能もだが、Intelの課題は鯖から先にマルチコアを投入することだな。
今みたいに、大した需要もないのにモバイルやらデスクトップから先に投入してるようじゃ話にならん。
いい加減、需要を考えた計画立てないと本気でやばいぞ・・・
鯖から先に投入して下に落としていくってところはOpteronのが理にかなってるな。
今みたいに、大した需要もないのにモバイルやらデスクトップから先に投入してるようじゃ話にならん。
いい加減、需要を考えた計画立てないと本気でやばいぞ・・・
鯖から先に投入して下に落としていくってところはOpteronのが理にかなってるな。
大規模マルチプロセッサマシンって痛とかでも専用の独自チップセットで繋げてないか？
OpはOpだけで構成しなくちゃいけないとかいう前提で話してる気がするんだが。
OpはOpだけで構成しなくちゃいけないとかいう前提で話してる気がするんだが。
加えて言うならば、最もNUMA系の技術が進んでると思われるSGIが
OpteronじゃなくてItanium2を使っているのは大規模でノード内でも
NUMAにしてしまうと如何に扱い辛いマシンになってしまうかを
示してるのじゃないのだろうか。8Pのopteronなんてヴィジュアルテクノロジーが
出しているぐらいで、大手は全く出してない。
OpteronじゃなくてItanium2を使っているのは大規模でノード内でも
NUMAにしてしまうと如何に扱い辛いマシンになってしまうかを
示してるのじゃないのだろうか。8Pのopteronなんてヴィジュアルテクノロジーが
出しているぐらいで、大手は全く出してない。
>>955
なんか無理矢理分かってないことにしたいようだな。
初期の大規模 NUMA マシンで最も成功したのは Origin 2000 だが、
こいつの場合、2Pで 350ns、4Pで 550nsくらいだろ。
つまり、550/350 で比は 1.57 くらいだ。
Opteron だと 130/100 で、比は 1.3 に過ぎない。
現実に使われている Opteron マシンは 8P はほとんどなくて、
4P が多いから、むしろ Origin 2000 なんかよりはいいんだよ。
もちろん、後にできた Origin 3000 だと latency の比は改善して
いるし、比が小さければ小さいほどいいには決まっているが、
現在使われている Opteron は、実用上問題になるレベルじゃない。
>>960
その通り。>>955は、話の前提からしておかしいんだよ。
大規模 NUMA を構成する場合、CPU あたり3本しか出ていない
HyperTransport で直接 CPU 間を接続するんじゃなくて、
効率的なトポロジをチップセットで構築して、そこにCPUから出てる
HyperTransportを接続するのが当然だ。
逆に、もし>>955の前提を絶対とし、CPU から出ているバスで
直接 CPU 間を接続することにするなら、Xeon の場合、あの遅い FSB を
全ての CPU で共有して大規模マルチプロセッサマシンを作るってことに
なるんだぜ?
そんなことをしたら、全く性能が出ないことは自明じゃないか。
まあ、そんな馬鹿なことをする奴はいないけど。
なんか無理矢理分かってないことにしたいようだな。
初期の大規模 NUMA マシンで最も成功したのは Origin 2000 だが、
こいつの場合、2Pで 350ns、4Pで 550nsくらいだろ。
つまり、550/350 で比は 1.57 くらいだ。
Opteron だと 130/100 で、比は 1.3 に過ぎない。
現実に使われている Opteron マシンは 8P はほとんどなくて、
4P が多いから、むしろ Origin 2000 なんかよりはいいんだよ。
もちろん、後にできた Origin 3000 だと latency の比は改善して
いるし、比が小さければ小さいほどいいには決まっているが、
現在使われている Opteron は、実用上問題になるレベルじゃない。
>>960
その通り。>>955は、話の前提からしておかしいんだよ。
大規模 NUMA を構成する場合、CPU あたり3本しか出ていない
HyperTransport で直接 CPU 間を接続するんじゃなくて、
効率的なトポロジをチップセットで構築して、そこにCPUから出てる
HyperTransportを接続するのが当然だ。
逆に、もし>>955の前提を絶対とし、CPU から出ているバスで
直接 CPU 間を接続することにするなら、Xeon の場合、あの遅い FSB を
全ての CPU で共有して大規模マルチプロセッサマシンを作るってことに
なるんだぜ?
そんなことをしたら、全く性能が出ないことは自明じゃないか。
まあ、そんな馬鹿なことをする奴はいないけど。
>962
>初期の大規模 NUMA マシンで最も成功したのは Origin 2000 だが、
>こいつの場合、2Pで 350ns、4Pで 550nsくらいだろ。
曖昧な記憶なんで申し訳ないが、Originはプロセッサーレベル（ノード内）では
SMPで、ノード間がNUMAじゃなかったけ？
>初期の大規模 NUMA マシンで最も成功したのは Origin 2000 だが、
>こいつの場合、2Pで 350ns、4Pで 550nsくらいだろ。
曖昧な記憶なんで申し訳ないが、Originはプロセッサーレベル（ノード内）では
SMPで、ノード間がNUMAじゃなかったけ？
>>960
Opteronの場合は独自チップを使ってもCPU-MEMが直接繋がって
いるから問題が解決できないだろ。
>>962
すまん、お前は本当に無知だったんだな。
> 直接 CPU 間を接続することにするなら、Xeon の場合、あの遅い FSB を
> 全ての CPU で共有して大規模マルチプロセッサマシンを作るってことに
> なるんだぜ?
なっていませんよ。
> そんなことをしたら、全く性能が出ないことは自明じゃないか。
> まあ、そんな馬鹿なことをする奴はいないけど。
お前の想像が馬鹿すぎて相手する気がなったよ。w
Opteronの場合は独自チップを使ってもCPU-MEMが直接繋がって
いるから問題が解決できないだろ。
>>962
すまん、お前は本当に無知だったんだな。
> 直接 CPU 間を接続することにするなら、Xeon の場合、あの遅い FSB を
> 全ての CPU で共有して大規模マルチプロセッサマシンを作るってことに
> なるんだぜ?
なっていませんよ。
> そんなことをしたら、全く性能が出ないことは自明じゃないか。
> まあ、そんな馬鹿なことをする奴はいないけど。
お前の想像が馬鹿すぎて相手する気がなったよ。w
> >>960
> Opteronの場合は独自チップを使ってもCPU-MEMが直接繋がって
> いるから問題が解決できないだろ。
CPU-MEM 間は今のままでいいんだよ。
大規模 NUMA を構成する場合にレイテンシが大きくなるのは、
結局のところhop数が増えるからだろ。
だから、リングとかそういうhop数の増えてしまうトポロジ
じゃなくて、hyper cube とかそういう hop 数の少なくてすむ
トポロジを構成すればいいわけ。で、CPUから出ている
HyperTransport は、その CPU間接続用のチップセットに繋ぐの。
当然でしょ?
> Opteronの場合は独自チップを使ってもCPU-MEMが直接繋がって
> いるから問題が解決できないだろ。
CPU-MEM 間は今のままでいいんだよ。
大規模 NUMA を構成する場合にレイテンシが大きくなるのは、
結局のところhop数が増えるからだろ。
だから、リングとかそういうhop数の増えてしまうトポロジ
じゃなくて、hyper cube とかそういう hop 数の少なくてすむ
トポロジを構成すればいいわけ。で、CPUから出ている
HyperTransport は、その CPU間接続用のチップセットに繋ぐの。
当然でしょ?
>>963
そんな突っ込みしちゃかわいそうだよ。
ノード内のアーキテクチャとノード間のアーキテクチャは要求されるモノが違うって
事が理解できていないんだから。
>>964
自己フォロー
> お前の想像が馬鹿すぎて相手する気がなったよ。w
は
> お前の想像が馬鹿すぎて相手する気がなくったよ。w
に修正。
そんな突っ込みしちゃかわいそうだよ。
ノード内のアーキテクチャとノード間のアーキテクチャは要求されるモノが違うって
事が理解できていないんだから。
>>964
自己フォロー
> お前の想像が馬鹿すぎて相手する気がなったよ。w
は
> お前の想像が馬鹿すぎて相手する気がなくったよ。w
に修正。
> なっていませんよ。
だから、なってないって、「俺が」先に書いてるだろ。
同意してくれてありがとう。
> お前の想像が馬鹿すぎて相手する気がなったよ。w
CPU から出てるバスで、直接 NUMA を構成するなどという
馬鹿な話を始めたのは「君」だが？
そんな馬鹿なことはしないって最初に書いたのは>>960だな。
だから、なってないって、「俺が」先に書いてるだろ。
同意してくれてありがとう。
> お前の想像が馬鹿すぎて相手する気がなったよ。w
CPU から出てるバスで、直接 NUMA を構成するなどという
馬鹿な話を始めたのは「君」だが？
そんな馬鹿なことはしないって最初に書いたのは>>960だな。
> ノード内のアーキテクチャとノード間のアーキテクチャは要求されるモノが
> 違うって事が理解できていないんだから。
CPUから出ているHyperTransportを直接接続してNUMAを構成するなんて
言っている奴は、理解できてないのは確かだろうな。
> 違うって事が理解できていないんだから。
CPUから出ているHyperTransportを直接接続してNUMAを構成するなんて
言っている奴は、理解できてないのは確かだろうな。
大規模構成（マルチノード）だと、OpteronのNUMAアーキテクチャに
特に優れたメリットはないってことでよろしいですか？
965の言っている構成は、CRAY XT3なんかで採用されているんだけど
TOP500の成績を見る限りLinpackでさえたいした効率が出ていない。
特に優れたメリットはないってことでよろしいですか？
965の言っている構成は、CRAY XT3なんかで採用されているんだけど
TOP500の成績を見る限りLinpackでさえたいした効率が出ていない。
>>967
> CPU から出てるバスで、直接 NUMA を構成するなどという
> 馬鹿な話を始めたのは「君」だが？
いや、馬鹿なお前がそう勘違いしているだけだ。
>>968
> CPUから出ているHyperTransportを直接接続してNUMAを構成するなんて
> 言っている奴は、理解できてないのは確かだろうな。
2〜8ソケットまでのOpteronでは既にそうなっているんだが。
> CPU から出てるバスで、直接 NUMA を構成するなどという
> 馬鹿な話を始めたのは「君」だが？
いや、馬鹿なお前がそう勘違いしているだけだ。
>>968
> CPUから出ているHyperTransportを直接接続してNUMAを構成するなんて
> 言っている奴は、理解できてないのは確かだろうな。
2〜8ソケットまでのOpteronでは既にそうなっているんだが。
> 大規模構成（マルチノード）だと、OpteronのNUMAアーキテクチャに
> 特に優れたメリットはないってことでよろしいですか？
大規模構成の場合、ノード間はどうせCPUから出ているバスとは違う
構成にするから、CPUレベルのバスは直接には影響しない。
ただし、Opteron の場合、HyperTransport が最初から3本出ていて、
Xeon よりはるかに、ノード間接続に使えるバンド幅が大きい。
だから、現在の Xeon と比べると間違いなく Opteron の方が優れて
いると言える筈。
> 特に優れたメリットはないってことでよろしいですか？
大規模構成の場合、ノード間はどうせCPUから出ているバスとは違う
構成にするから、CPUレベルのバスは直接には影響しない。
ただし、Opteron の場合、HyperTransport が最初から3本出ていて、
Xeon よりはるかに、ノード間接続に使えるバンド幅が大きい。
だから、現在の Xeon と比べると間違いなく Opteron の方が優れて
いると言える筈。
> 2〜8ソケットまでのOpteronでは既にそうなっているんだが。
2〜8ソケットの構成を「大規模NUMA」なんて言う奴はおらんよ。
君は、2〜8ソケットを指して、「大規模NUMA」と呼んでいるのか？
2〜8ソケットの構成を「大規模NUMA」なんて言う奴はおらんよ。
君は、2〜8ソケットを指して、「大規模NUMA」と呼んでいるのか？
おいおい、じゃあどういう話だったんだい？
もともとの話は、Whitefield のリング構成が「多数コア向け」であるか
どうかってことだったんじゃないのか？
答えは「全然向いてない」だろ？
2007年発売にも関わらず、現状の Opteron 以上に hop 数が増えるわけ
だからな。
もともとの話は、Whitefield のリング構成が「多数コア向け」であるか
どうかってことだったんじゃないのか？
答えは「全然向いてない」だろ？
2007年発売にも関わらず、現状の Opteron 以上に hop 数が増えるわけ
だからな。
>>976
ありがと
ありがと
>971
あのCRAYでさえ、ノード間接続にはHyperTransportを1本しか使ってないよ。
ま、それでもバンドは広いけど。
あのCRAYでさえ、ノード間接続にはHyperTransportを1本しか使ってないよ。
ま、それでもバンドは広いけど。
> 974 ：Socket774：2005/08/29(月) 02:44:00 ID:C22GpgKJ
> >>972
> 俺は大規模NUMA、つまりノード間をHT直接接続なんて話していないぞ。
ID:C22GpgKJ だよな。
> 955 ：Socket774：2005/08/29(月) 01:45:25 ID:C22GpgKJ
> >>952
> やっぱりわかっていないじゃんか。w
> 大規模マルチプロセッサマシンを作るうえでNUMA構成の
> memory latency比はかなり重要な問題なんだよ。
これも ID:C22GpgKJ だよな。
俺は、いまどき大規模マルチプロセッサマシンというのは、
128プロセッサとかそういうレベルを指していると思ったんだが、
実は 8CPU を指して「大規模マルチプロセッサ」と呼んでいたのか？
すまん。これが誤解の原因だ。
俺にはそういう発想はなかった。(w
俺の発言は、「128プロセッサマシンを実現するには」という解釈を
すれば、全て一貫しているし、正しいと思うよ。(w
> >>972
> 俺は大規模NUMA、つまりノード間をHT直接接続なんて話していないぞ。
ID:C22GpgKJ だよな。
> 955 ：Socket774：2005/08/29(月) 01:45:25 ID:C22GpgKJ
> >>952
> やっぱりわかっていないじゃんか。w
> 大規模マルチプロセッサマシンを作るうえでNUMA構成の
> memory latency比はかなり重要な問題なんだよ。
これも ID:C22GpgKJ だよな。
俺は、いまどき大規模マルチプロセッサマシンというのは、
128プロセッサとかそういうレベルを指していると思ったんだが、
実は 8CPU を指して「大規模マルチプロセッサ」と呼んでいたのか？
すまん。これが誤解の原因だ。
俺にはそういう発想はなかった。(w
俺の発言は、「128プロセッサマシンを実現するには」という解釈を
すれば、全て一貫しているし、正しいと思うよ。(w
>>980
>>955はノード内だけで既にmemory latency比が1:2になってしまっている
のは問題だと書いただけ。つまりお前が勝手にノード内の話とノード間の話を
混ぜて勘違いしているんだよ。
>>955はノード内だけで既にmemory latency比が1:2になってしまっている
のは問題だと書いただけ。つまりお前が勝手にノード内の話とノード間の話を
混ぜて勘違いしているんだよ。
ま、しかしマルチコア、HyperTransportみたいなもの、プロセッサーレベルのNUMA等々
はすべて旧DEC（Compaqの頃かな）のAlphaロードマップにあったわけで、AMDもIntelも
アイディアはパクリだよなぁ。Alphaは超マルチコアでベクタープロセッサのように動くことも
考えていたようだし。
もう、新たなアイディアは出てこないのか。
MeromのL1-L1のダイレクト接続でスヌープがいらないみたいなのは所詮Tips程度だしな。
はすべて旧DEC（Compaqの頃かな）のAlphaロードマップにあったわけで、AMDもIntelも
アイディアはパクリだよなぁ。Alphaは超マルチコアでベクタープロセッサのように動くことも
考えていたようだし。
もう、新たなアイディアは出てこないのか。
MeromのL1-L1のダイレクト接続でスヌープがいらないみたいなのは所詮Tips程度だしな。
>>982
がいしゅつのアイディアだから、で避けていたら出来上がるのは糞石だ罠。
がいしゅつのアイディアだから、で避けていたら出来上がるのは糞石だ罠。
>>981
だって、「大規模マルチプロセッサマシンを作るうえで」って
断って書いてるんだぜ。当然、ノード間の話だと思うじゃないか。
「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
話が関係してくるんだよ？ (w
ありえない。
で、ノード内で実際に問題になるほど遅いかというと、4P までなら
全く問題ないのは上に書いた通り。ちゃんとした反論も出てないと思う。
少なくとも現在の Xeon よりははるかにマシ。
念のために書いておくと、俺も8Pのlatencyは問題だと思う。
Sunの8Pマシンがなかなか出てこないのは、たぶんOpteronから出てる
HTじゃなくて、チップセットでノード間接続をやっていて、そこで
トラブってるんじゃないかなあ。
だって、「大規模マルチプロセッサマシンを作るうえで」って
断って書いてるんだぜ。当然、ノード間の話だと思うじゃないか。
「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
話が関係してくるんだよ？ (w
ありえない。
で、ノード内で実際に問題になるほど遅いかというと、4P までなら
全く問題ないのは上に書いた通り。ちゃんとした反論も出てないと思う。
少なくとも現在の Xeon よりははるかにマシ。
念のために書いておくと、俺も8Pのlatencyは問題だと思う。
Sunの8Pマシンがなかなか出てこないのは、たぶんOpteronから出てる
HTじゃなくて、チップセットでノード間接続をやっていて、そこで
トラブってるんじゃないかなあ。
＞９８４
＞Sunの8Pマシンがなかなか出てこないのは、たぶんOpteronから出てる
＞HTじゃなくて、チップセットでノード間接続をやっていて、そこで
＞トラブってるんじゃないかなあ。
混乱する。なかなか出てこない８Pってのは多ノードの話？
Opteronの場合チップセットでノード間は、PCI-Xだよね。
＞Sunの8Pマシンがなかなか出てこないのは、たぶんOpteronから出てる
＞HTじゃなくて、チップセットでノード間接続をやっていて、そこで
＞トラブってるんじゃないかなあ。
混乱する。なかなか出てこない８Pってのは多ノードの話？
Opteronの場合チップセットでノード間は、PCI-Xだよね。
>965の言っている構成は、CRAY XT3なんかで採用されているんだけど
>TOP500の成績を見る限りLinpackでさえたいした効率が出ていない。
今時Linpackのようなプロセッサテストの結果で、総合性能を判断するやつがいたんだ。
>TOP500の成績を見る限りLinpackでさえたいした効率が出ていない。
今時Linpackのようなプロセッサテストの結果で、総合性能を判断するやつがいたんだ。
>986
いや、そういう意味じゃない。
Linpackで”さえ”性能や効率が出ないマシンが良いとは言えないってこと。
いや、そういう意味じゃない。
Linpackで”さえ”性能や効率が出ないマシンが良いとは言えないってこと。
>>984
> 「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
> 話が関係してくるんだよ？ (w
> ありえない。
ノード内のmemory latency比がノード間も含めた全体のmemory latency比に
影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
> 「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
> 話が関係してくるんだよ？ (w
> ありえない。
ノード内のmemory latency比がノード間も含めた全体のmemory latency比に
影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
>>985
俺は、多ノードだと妄想している。
でも、俺はSunの社員でもなければ、それほどちゃんと情報を
追っているわけでもないので、単なる妄想に過ぎないから
注意してくれ。
> Opteronの場合チップセットでノード間は、PCI-Xだよね。
Sun はチップセットを自力で起こしているらしいので、
このあたりは何でもアリの筈。
俺は、多ノードだと妄想している。
でも、俺はSunの社員でもなければ、それほどちゃんと情報を
追っているわけでもないので、単なる妄想に過ぎないから
注意してくれ。
> Opteronの場合チップセットでノード間は、PCI-Xだよね。
Sun はチップセットを自力で起こしているらしいので、
このあたりは何でもアリの筈。
>986
付け加えて言うなら、今時Linpackの計算部分はライブラリを呼んでるからほぼ理論ピークが
出やすい（POWERとSPARCはそうでもないんだが）。
だから、通信部分で効率は決まってくるので、如何にリッチなインターコネクト周りを
持っているかで、トータルの性能は決まってくるのよ。
大規模構成時は、Linpackであっても決してプロセッサテストとは言い切れない。
付け加えて言うなら、今時Linpackの計算部分はライブラリを呼んでるからほぼ理論ピークが
出やすい（POWERとSPARCはそうでもないんだが）。
だから、通信部分で効率は決まってくるので、如何にリッチなインターコネクト周りを
持っているかで、トータルの性能は決まってくるのよ。
大規模構成時は、Linpackであっても決してプロセッサテストとは言い切れない。
＞９８９
HTに繋げないチップセットを自前で開発ってことですか。なるほど、わかりました。サンクス
HTに繋げないチップセットを自前で開発ってことですか。なるほど、わかりました。サンクス
> ノード内のmemory latency比がノード間も含めた全体のmemory latency比に
> 影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
勿論影響する。
で、現状の Opteron の場合、ノードを8Pで構成するのは間違いだ。
ノードを4Pで構成すれば、まあ確実にXeonより高速になるだろう。
Opteron なら 4P で 8core にできるが、Xeon だとそもそもマルチ
コアがないから、そういうことはできん。
ちなみに Xeon でノードを 8Pにしたら、FSB 共有のせいで、ノード
性能は悲惨になる。Xeon 4P でさえ、FSB 共有のせいで、
1core Opteron 4P より遅いと評価されることがあるわけだからな。
少なくともメモリバンド幅を大量に消費する HPC 方面では、そう
いう評価が出ている。
結局、現状だと、ちゃんと作れば、確実に Opteron の方が速くなる。
こういう当然のことが分からない奴は、本当におめでたいな。
> 影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
勿論影響する。
で、現状の Opteron の場合、ノードを8Pで構成するのは間違いだ。
ノードを4Pで構成すれば、まあ確実にXeonより高速になるだろう。
Opteron なら 4P で 8core にできるが、Xeon だとそもそもマルチ
コアがないから、そういうことはできん。
ちなみに Xeon でノードを 8Pにしたら、FSB 共有のせいで、ノード
性能は悲惨になる。Xeon 4P でさえ、FSB 共有のせいで、
1core Opteron 4P より遅いと評価されることがあるわけだからな。
少なくともメモリバンド幅を大量に消費する HPC 方面では、そう
いう評価が出ている。
結局、現状だと、ちゃんと作れば、確実に Opteron の方が速くなる。
こういう当然のことが分からない奴は、本当におめでたいな。
>>992
> > > 「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
> > > 話が関係してくるんだよ？ (w
> > > ありえない。
> > ノード内のmemory latency比がノード間も含めた全体のmemory latency比に
> > 影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
> 勿論影響する。
なんだよその矛盾した話は。
> ちなみに Xeon でノードを 8Pにしたら、FSB 共有のせいで、ノード
> 性能は悲惨になる。
それにありえない前提を持ち出して比較するし。
> > > 「大規模マルチプロセッサマシンを作るうえで」なんでノード内での
> > > 話が関係してくるんだよ？ (w
> > > ありえない。
> > ノード内のmemory latency比がノード間も含めた全体のmemory latency比に
> > 影響を与えないと思っているお前の頭は実におめでたい。幸せに生きてくれ。
> 勿論影響する。
なんだよその矛盾した話は。
> ちなみに Xeon でノードを 8Pにしたら、FSB 共有のせいで、ノード
> 性能は悲惨になる。
それにありえない前提を持ち出して比較するし。
> なんだよその矛盾した話は。
流れを読めてないないなあ。
でも一応解説しておく。
俺は「ノード内のmemory latency比が全体のmemory latency比に
影響を与えない」とは思っていない。
しかし、「大規模マルチプロセッサマシンを作るうえでNUMA構成の
memory latency比」といきなり言われた場合、当然、ここでいう
memory latency比というのは、ノード間の話だと想像するし、実際
そう誤解したわけだ。
まさか「大規模マルチプロセッサマシンを作るうえでのNUMA構成の
memory latency比」というのが、ノード内の話をしているとは
思わなかった。
っていうか、こう言われて、ノード内の話をしてるって気づくなんて
ことは、ありえないと思う。
まあ、C22GpgKJ は言ってる本人だから、当然分かってるだろうが、
なんで Su+Yw7pI は、ノード内の話だと分かったのか、そっちが
知りたいよ。
流れを読めてないないなあ。
でも一応解説しておく。
俺は「ノード内のmemory latency比が全体のmemory latency比に
影響を与えない」とは思っていない。
しかし、「大規模マルチプロセッサマシンを作るうえでNUMA構成の
memory latency比」といきなり言われた場合、当然、ここでいう
memory latency比というのは、ノード間の話だと想像するし、実際
そう誤解したわけだ。
まさか「大規模マルチプロセッサマシンを作るうえでのNUMA構成の
memory latency比」というのが、ノード内の話をしているとは
思わなかった。
っていうか、こう言われて、ノード内の話をしてるって気づくなんて
ことは、ありえないと思う。
まあ、C22GpgKJ は言ってる本人だから、当然分かってるだろうが、
なんで Su+Yw7pI は、ノード内の話だと分かったのか、そっちが
知りたいよ。
>>994
流れをみればわかるだろ。
流れをみればわかるだろ。
>>994
IDがかわっただけだ。
IDがかわっただけだ。
>992
確かに1ノードだけ見ると4PのOpteronがbestなのはわかったけど、
そのHPCの業界だと、実装密度の点で2Pがメインなので、1ノード4P以上に
対してそこまで熱く4Pを語らなくても。。
2Pだと1Uや2Uの選択肢あるけど、4Pだと4Uしか選択しないからさ。
独自チップセットはまだ出てないし。HTにインターコネクト直付けのCRAYは1P構成だしさ。
確かに1ノードだけ見ると4PのOpteronがbestなのはわかったけど、
そのHPCの業界だと、実装密度の点で2Pがメインなので、1ノード4P以上に
対してそこまで熱く4Pを語らなくても。。
2Pだと1Uや2Uの選択肢あるけど、4Pだと4Uしか選択しないからさ。
独自チップセットはまだ出てないし。HTにインターコネクト直付けのCRAYは1P構成だしさ。
1001 ：１００１：