Sun Microsystems 最期の落日
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2009/06/06(土) 20:00:02ITの未来はどっちだ！？
【前スレ】
Sun Microsystems 最期の神託
http://pc12.2ch.net/test/read.cgi/unix/1242038454/l50
0292名無しさん＠お腹いっぱい。
2009/06/11(木) 14:14:470293名無しさん＠お腹いっぱい。
2009/06/11(木) 14:16:07たとえもしよしんばとりあえずそうだったとしても、もうすぐ QPIが出るよ、夢の QPIがw
0294名無しさん＠お腹いっぱい。
2009/06/11(木) 14:17:48Intel凄いしパチョコン最強だもんな
おれら情弱だからぐぐり切れてないだけだしな
0295名無しさん＠お腹いっぱい。
2009/06/11(木) 14:19:01でもOpenLDAPとXeonは悪くないんです！！！
0296名無しさん＠お腹いっぱい。
2009/06/11(木) 14:30:15Intel(笑)のことを一番よく知ってるのはIntel(笑)の中の人だろうしｗ
スケールするかどうかすら書いてないのも、
ユーザには分からない何か深い理由があるんだろうｗｗｗ
0297名無しさん＠お腹いっぱい。
2009/06/11(木) 14:33:150298名無しさん＠お腹いっぱい。
2009/06/11(木) 14:34:27OpenLDAPは悪くない。あいつはいいやつだ。Xeonが、悪い。
0299名無しさん＠お腹いっぱい。
2009/06/11(木) 14:34:58そして無学な民衆にXeonがスケールするかどうかや
エンプラでなにが大切かを教えてはならない
0300名無しさん＠お腹いっぱい。
2009/06/11(木) 14:44:49URLしか読んでないんだな。
その先に何が書いてあるのか、読んで見ろヨ。
>>289
SPARC信者が英語を読めるかどうかのテストなんだわ。
いまのところ、読めてないようなレスが多いな。
ま、URLだけ見て鬼の首を取ったかのような言動しているので、
それ以前って感じだが。
>>291
127.0.0.1でいくら性能が出ても、ネットワーク越しで性能がでなければ、
LDAPサーバの構築・運用っていう観点では、あんまり意味がないと思う。
>>292
条件を書かずに、ただ「スケールする」「スケールしない」って言うのはナンセンスだよ。
0301名無しさん＠お腹いっぱい。
2009/06/11(木) 14:46:15バーゲン！バーゲン！大バーゲン！
SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる！
あれ？SPARC64VIIとの比較は？ｗ
負ける戦をしないのがIntelのいいところ
売れない製品ラインは即売却ｗ
バカにするのもほどほどにしたまえよｗ
0302名無しさん＠お腹いっぱい。
2009/06/11(木) 14:47:14>>292 = >>293 = >>294 = >>295 = >>296
5連投ですか。
0303名無しさん＠お腹いっぱい。
2009/06/11(木) 14:50:56> SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる！
Sunが主張していたよな。
サーバの価格よりも電気代のほうが重要、だから、CoolThreadsサーバを使うべきだ、と。
そのSunの主張に従って判断したら、Xeonのほうが優れてる、ってことになったんだわ。
> あれ？SPARC64VIIとの比較は？ｗ
> 負ける戦をしないのがIntelのいいところ
この言葉を引用しよう
The absence of a result certainly says something very clear to me - no story.
0304名無しさん＠お腹いっぱい。
2009/06/11(木) 14:51:22ちゃんとx86気違イのお仲間が書いた記事ならそこまで読もうよ
0305名無しさん＠お腹いっぱい。
2009/06/11(木) 14:52:13> URLしか読んでないんだな。
はぁ。URL指摘するのに、その先に何が書いてあるのか知ってないといかんの?
> SPARC信者が英語を読めるかどうかのテストなんだわ。
なるほどなるほど。で、英語が読めるとお気に入りの CPUがスケールするわけかよ?
英語の読めるバカもいるんだな。感心するわ。
0306名無しさん＠お腹いっぱい。
2009/06/11(木) 14:55:36スケールするかの話なのにいつの間にか電気代の話になってる
ATOMでOracle走らせてろよｗ
0307名無しさん＠お腹いっぱい。
2009/06/11(木) 14:57:220308名無しさん＠お腹いっぱい。
2009/06/11(木) 15:01:44一番下のコメントって、
SPARCには、UltraSPARC T2+なんかのローエンドだけではなく、メインフレーム代替のハイエンド機がある。
そういうアップグレードパスの存在を無視して、ローエンドの性能の低さを批判するのは良くない、ってことだろ。
それはその通りだ。
そこまでの信頼性が必要な客は、UltraSPARCなんか買わずに、初手からSPARC64いっとくべきだ。
0309名無しさん＠お腹いっぱい。
2009/06/11(木) 15:03:54指摘しなくたって、みんなわかっとるよ。
誰のどこでの発言か、ということよりも、発言内容のほうが大切だってのは、言われなくても、わ・か・れ。
ベンチマークで良好なスコアを出てるのは、必要な領域ではスケールしているってことじゃないか?
実用上、問題がなければ、それでいいじゃないか。
たとえばメモリのピーク帯域幅を調べるようなベンチマークでスケールしなかったら、何が問題?
0310名無しさん＠お腹いっぱい。
2009/06/11(木) 15:04:00つーか、Intelや MS周辺の文書って、なんでこんなに中身がないんだ? うっすーーーーいw
0311名無しさん＠お腹いっぱい。
2009/06/11(木) 15:04:35今更そういうことを書くのって、本当に素人なのなとうんざりするが
0312名無しさん＠お腹いっぱい。
2009/06/11(木) 15:06:17それ以上は無理ってことなんだから
もう今更過ぎてorz
0313名無しさん＠お腹いっぱい。
2009/06/11(木) 15:09:15おまえなー、もったいつけてないで、さっさと要点書けよ。何様のつもりなんだよ?
立派な英文学の知識で、さぞかしすごい訳文さらしてくれるんだろーな? 期待してるぞ。
0314名無しさん＠お腹いっぱい。
2009/06/11(木) 15:16:48今更どうしようもないっすよ
議論してもムダです
それが分かってるから違う分野で勝負かけてるわけで
全部失敗してるけどなｗ
0315名無しさん＠お腹いっぱい。
2009/06/11(木) 15:19:16ほい、16ソケット対決! SPARC64 vs Xeon
ttp://www.spec.org/jbb2005/results/res2008q3/jbb2005-20080713-00510.html
SPECjbb2005 bops = 817,158, SPECjbb2005 bops/JVM = 51,072
Model Fujitsu SPARC Enterprise M8000
Processor SPARC64 VII
# of Chips 16
# of Cores 64
# of Cores/Chip 4
ttp://www.spec.org/jbb2005/results/res2009q1/jbb2005-20090206-00568.html
SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
Processor Intel Xeon processor X7460
# of Chips 16
# of Cores 96
# of Cores/Chip 6
参考、Opteronの8ソケット
ttp://www.spec.org/jbb2005/results/res2008q4/jbb2005-20081202-00562.html
SPECjbb2005 bops = 1,037,851, SPECjbb2005 bops/JVM = 129,731
Model Sun Fire X4600 M2
Processor AMD Opteron 8384 (2.7GHz, 6 MB L3 shared)
# of Chips 8
# of Cores 32
# of Cores 32
Memory (MB) 131072
Memory Details 32 x 4GB DDR2-667 DIMMs
0316名無しさん＠お腹いっぱい。
2009/06/11(木) 15:23:01スケールするSPARCよりも性能が高いんだから、スケールしなくたって十分だ。
0317名無しさん＠お腹いっぱい。
2009/06/11(木) 15:23:10Sunの人が行き場を失って、管を巻くしかやること無いのか？w
0318名無しさん＠お腹いっぱい。
2009/06/11(木) 15:26:42ttp://www.mizuao.com/specsample/yuitable_0_0_3.html
0319名無しさん＠お腹いっぱい。
2009/06/11(木) 15:27:36Vista SP2ならCeleronで十分だなｗ
0320名無しさん＠お腹いっぱい。
2009/06/11(木) 15:38:54いいよ、もう、x86はスケールしないってことで。
オレはパチョコンしか使わないんだから、スケールしなくたって十分だ。
0321名無しさん＠お腹いっぱい。
2009/06/11(木) 15:40:20どうした? 話を逸らすにしても、ネタが愚劣すぎるぞ
0322名無しさん＠お腹いっぱい。
2009/06/11(木) 15:41:13まだ諦めんなよ
QPIが来れば、勝つるんだから
0323名無しさん＠お腹いっぱい。
2009/06/11(木) 15:42:410324名無しさん＠お腹いっぱい。
2009/06/11(木) 15:44:29一文字おきに読んだりすればいいのか? それともどっかをタテ読み??
0325名無しさん＠お腹いっぱい。
2009/06/11(木) 15:46:01逸らすも何も、適材適所でいいじゃん
ESXのGUI版管理コンソールはWinでしか動かないんだしさぁ
便利な方、楽な方に流れればサーバはSolarisだし
開発はVMware上のLinuxだし、x86使うならホストOSはWindowsでしょ
SPARC使った方が楽ならそっちの方がいいよ
ムリしてx86なんて辛すぎる
0326名無しさん＠お腹いっぱい。
2009/06/11(木) 15:47:53画面から 8inch目を離してロンパリで遠焦点にすると仏像が浮かび上がる。
この文字配置かつ意味のある文章を組み立てるのに Xeon7400がスケールしないので
4週間かかったらしい。
0327名無しさん＠お腹いっぱい。
2009/06/11(木) 16:05:52>>322から>>326まで、またまた5連投ですか
たしかにx86はスケーラビリティが悪い
6コアXeonの1ソケットのデータがないんで、あれだが・・・
ttp://www.spec.org/jbb2005/results/res2008q3/jbb2005-20080812-00518.html
SPECjbb2005 bops = 185,899, SPECjbb2005 bops/JVM = 92,950
Model PRIMERGY RX100 S5, Intel Xeon X3370, 3.0GHz
Processor Intel Xeon X3370 (3.0GHz, 2x6MB L2, 1333MHz system bus)
# of Chips 1
# of Cores 4
# of Cores/Chip 4
ソケットが16倍コアが24倍になっても、性能は11.6倍だもの。
ソケットで見れば72%、コアでみれば48%だ。
ttp://www.spec.org/jbb2005/results/res2008q4/jbb2005-20081027-00554.html
SPECjbb2005 bops = 60,853, SPECjbb2005 bops/JVM = 60,853
Model Fujitsu SPARC Enterprise M3000
Processor SPARC64 VII
# of Chips 1
# of Cores 4
# of Cores/Chip 4
ソケットが16倍で、性能は13.4倍。
x86とは比べ物にならない、リニアなスケールですな。
0328名無しさん＠お腹いっぱい。
2009/06/11(木) 16:17:06> Model PRIMERGY RX100 S5, Intel Xeon X3370, 3.0GHz
> Processor Intel Xeon X3370 (3.0GHz, 2x6MB L2, 1333MHz system bus)
これって QPI?
0329名無しさん＠お腹いっぱい。
2009/06/11(木) 16:18:44あ、こっちか。これって違う機種なんだな..
> SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
> Processor Intel Xeon processor X7460
これって QPI?
0330名無しさん＠お腹いっぱい。
2009/06/11(木) 16:23:40多分FSBと思う
0331名無しさん＠お腹いっぱい。
2009/06/11(木) 16:25:26X7460
どちらも45nmの、QPIになる前の製品だよ。
0332名無しさん＠お腹いっぱい。
2009/06/11(木) 16:26:430333名無しさん＠お腹いっぱい。
2009/06/11(木) 16:27:34コアが21.3倍で性能は11.6倍・・・つっても54%だな。
0334名無しさん＠お腹いっぱい。
2009/06/11(木) 16:29:44SPECjbb2005 bops = 1,757,035, SPECjbb2005 bops/JVM = 1,757,035
Model Fujitsu SPARC Enterprise M9000
Processor SPARC64 VII
# of Chips 64
# of Cores 256
# of Cores/Chip 4
コア64倍で性能28.8倍
0335名無しさん＠お腹いっぱい。
2009/06/11(木) 16:30:05QPIを導入するまでもなく、SPARC64 VIIよりXeonのほうが性能が上なんですが。
1ソケットなら3倍
16ソケットでも2.6倍
改善ではなく、さらに差を広げる、だろう。
0336名無しさん＠お腹いっぱい。
2009/06/11(木) 16:34:2416ソケットと比べると、コア4倍で性能2.15倍か。
64ソケットも注ぎ込んでも、Xeonの16ソケットに追い付かないんだな。
0337名無しさん＠お腹いっぱい。
2009/06/11(木) 16:36:13なんでそう話をごちゃまぜにするかな...
> 改善ではなく、さらに差を広げる、だろう。
スケーラビリティが「改善」する。4コアとか FSBでスケールしてる規模では
むしろオーバーヘッドになる。
0338名無しさん＠お腹いっぱい。
2009/06/11(木) 16:39:06まあ、x86この先もせいぜい性能が伸びるといいけどな。
Sandy Bridgeで AVXな。ベクトルベクトルw
0339名無しさん＠お腹いっぱい。
2009/06/11(木) 16:44:52ズバリ、コアのクロックを下げる
SPARC64 VIIと同程度の性能になるまで、コアのクロックを下げる
それだけでスケーラビリティは良くなりますよ。
逆に言うと、
SPARC64VIIのコアのクロックをXeonと同程度の性能になるまで上げることができれば、
スケーラビリティが下がるでしょうね。
0340名無しさん＠お腹いっぱい。
2009/06/11(木) 16:51:21そんな単純なもんじゃないだろ。
帯域幅がボトルネックならともかく。
0341名無しさん＠お腹いっぱい。
2009/06/11(木) 16:57:500342名無しさん＠お腹いっぱい。
2009/06/11(木) 16:58:35絶対値の問題ではない。
0343名無しさん＠お腹いっぱい。
2009/06/11(木) 17:00:360344名無しさん＠お腹いっぱい。
2009/06/11(木) 17:28:000345名無しさん＠お腹いっぱい。
2009/06/11(木) 17:30:400346名無しさん＠お腹いっぱい。
2009/06/11(木) 17:56:320347名無しさん＠お腹いっぱい。
2009/06/11(木) 18:10:41> SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
> Processor Intel Xeon processor X7460
> # of Chips 16
> # of Cores 96
> # of Cores/Chip 6
こいつは 4ソケット 24コアを 4筐体 HSIで接続したもんらしいね。
NUMAになるかな?
16ソケット 96コアでスケールするんならたいしたもんだ。
0348名無しさん＠お腹いっぱい。
2009/06/11(木) 18:12:56QPIだとどういう構成が可能になる? 16ソケット 96コアを超えれそう?
0349名無しさん＠お腹いっぱい。
2009/06/11(木) 19:05:450350名無しさん＠お腹いっぱい。
2009/06/11(木) 19:08:150351名無しさん＠お腹いっぱい。
2009/06/11(木) 19:12:46ttp://www.spec.org/power_ssj2008/results/
0352名無しさん＠お腹いっぱい。
2009/06/11(木) 19:21:14ttp://tweakers.net/reviews/649/7/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-7.html
それと、Linuxも 4コアならまあいいとこ行ってるな。Solarisにはかなわんがw
ttp://tweakers.net/reviews/649/9/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-9.html
0353名無しさん＠お腹いっぱい。
2009/06/11(木) 19:23:18SPARCがいません。
0354名無しさん＠お腹いっぱい。
2009/06/11(木) 19:32:25うむ、US T1よりもOpteronのほうが優れているように見えるね。
0355名無しさん＠お腹いっぱい。
2009/06/11(木) 19:33:52勝てない戦いはしない、ってことかと。
0356名無しさん＠お腹いっぱい。
2009/06/11(木) 19:38:04そうだね
0357名無しさん＠お腹いっぱい。
2009/06/11(木) 19:53:56http://blogs.sun.com/HPC/entry/video_andy_b_shows_nehalem
0358名無しさん＠お腹いっぱい。
2009/06/11(木) 19:55:46そろそろZFSやProject Crossbowとかも語って欲しい
0359名無しさん＠お腹いっぱい。
2009/06/11(木) 20:02:35あの6000シリーズ(だよね?)のブレードにXeon 4発か。すげーな。
Sunってさ、SPARCよりもx86のほうが、高密度なブレードを製品化してるよね。
6000シリーズだとSPARCだと1発しかなかったと思う。
0360名無しさん＠お腹いっぱい。
2009/06/11(木) 21:47:170361名無しさん＠お腹いっぱい。
2009/06/11(木) 23:06:09忘れた頃に2ソケットの出たよ
いまだに4ソケットは出ない
過去スレに貼られていたPDFでは、
4ソケットならOpteronやXeonよりもスパコン性能高いよ
ってな計算があったが、いまだに4ソケットは作られず。
0362名無しさん＠お腹いっぱい。
2009/06/11(木) 23:06:51ttp://tweakers.net/reviews/649/8/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-8.html
うむ、US T1よりもOpteronのほうが優れているように見えるね。
おい、SPARCならリニアにスケール(笑)の厨房の謝罪まだか?
馬鹿の一つ覚えみたいにリニアにスケール(笑)連呼してたな。
x86以前に当のSPARCが実アプリでスケールしないのにさ。
結論: SPARCの方がリニアにほど遠いスケーラビリティ
0363名無しさん＠お腹いっぱい。
2009/06/11(木) 23:27:11下のグラフはMySQLが悪いってことで無視するとして、
上のグラフを見ると、T1のほうがスケールしているよ。
Concurrencyを増やしていって飽和した部分の縦軸の数字を見ると、4コア→8コアで、ほぼ倍になってるから。
Opteronだと2コア→4コアで、倍よりも小さい。
しかし、どちらが優れているかといえばOpteronだ。
T1はConcurrencyが高くないと本領を発揮しないし、
たとえ本領を発揮しても、
T1 4コアよりOpteron 2コア、
T1 8コアよりOpteron 4コア
のほうが全領域でパフォーマンスが上なのだから。
0364名無しさん＠お腹いっぱい。
2009/06/11(木) 23:29:56スケールしなくてもSPARCよりXeonのほうが性能が高い、ゆえに、スケールしないのは問題ではない
っていうことで、スケールするかどうかは、どうでもいいんだわな。
0365名無しさん＠お腹いっぱい。
2009/06/11(木) 23:31:44お前が言ってるのはスループット。
スケーラビリティって言葉の意味わかってるか?
コア数が増えたときにどれだけ性能が伸びてるかだぞ。
もう一度グラフとにらめっこして出直してこいw
0366名無しさん＠お腹いっぱい。
2009/06/11(木) 23:32:50下のグラフではSPARCがぼろぼろということになる。
0367名無しさん＠お腹いっぱい。
2009/06/11(木) 23:37:20スループットでSPARCが粘っているのはハードウエアマルチスレッディングがあるから。
つーか、このくらいは直ぐ見てわからんとスループットコンピューティングの意味理解できんぞ。
0368名無しさん＠お腹いっぱい。
2009/06/11(木) 23:40:13メモリ=DRAMに関してはCPUメーカーの技術差が出にくいので
基本的にはCPUコアが速いほどメモリがボトルネックになる度合いが大きく、
スケーラビリティをあげるのは難しくなる。
むしろ単体コアで圧倒的でもこれだけのスケーラビリティを維持して、絶対性能で圧勝しているので
議論する意味もない。
0369名無しさん＠お腹いっぱい。
2009/06/11(木) 23:42:180370名無しさん＠お腹いっぱい。
2009/06/11(木) 23:51:30おまえ、グラフろくに見てないだろ。
横軸はコア数ではないぞ。
>>367
SPARCが粘ってる? 何を言っとるんだ。
Concurrencyが低いと性能が出てないだけじゃないか。
0371名無しさん＠お腹いっぱい。
2009/06/11(木) 23:51:32確かに差はよくみないとわからないが、
SPARCの方がスケールしているよな。
0372名無しさん＠お腹いっぱい。
2009/06/11(木) 23:54:01次の日会社で仕事している時間帯によっぽど暇なのかニートなのか知らないが、
SPARCマンセー書き込みで暴れている不思議w
0373名無しさん＠お腹いっぱい。
2009/06/11(木) 23:55:230374名無しさん＠お腹いっぱい。
2009/06/11(木) 23:56:09まあ、こんな単純な現実の性能話も理解できないようでは
少なくともコンピュータ関係の仕事は続けられないだろうが。
0375名無しさん＠お腹いっぱい。
2009/06/12(金) 00:20:40> OpenLDAPは悪くない。あいつはいいやつだ。
ちょっとスレ違いだが、
例えばback-sqlなんか使うとスケールしているベンチマーク結果とかあるの?
0376名無しさん＠お腹いっぱい。
2009/06/12(金) 09:30:50まさか「英語ななめ読み」とか言ってたやつじゃないよな?
早く訳文がみたいぜww
0377名無しさん＠お腹いっぱい。
2009/06/12(金) 09:33:340378名無しさん＠お腹いっぱい。
2009/06/12(金) 09:42:08「x86はスケールしない、したがって SMP用 CPUとしてはクズ」
という命題について議論しているのに、
> っていうことで、スケールするかどうかは、どうでもいいんだわな。
こんなこと言うやつは鼻つままれて外へ放り出すべきだな。
典型的バカ。サル以下。ひとりで暮らせ。ここへは来るな。
0379名無しさん＠お腹いっぱい。
2009/06/12(金) 09:45:120380名無しさん＠お腹いっぱい。
2009/06/12(金) 10:41:10わけろって話だろ
「x86はスケールしない」
「x86はSMP用 CPUとしてはクズ」
0381名無しさん＠お腹いっぱい。
2009/06/12(金) 11:15:06正直にいってごらん、英語わかりませんって。
0382名無しさん＠お腹いっぱい。
2009/06/12(金) 11:17:33なぁ、>>364は皮肉だろ、どう見ても。
スケールしてるものに対して、スケールしないって言ってるんだから。
>>380
0と1の両極端で考えるのは、やめれ。
0383名無しさん＠お腹いっぱい。
2009/06/12(金) 11:19:200384名無しさん＠お腹いっぱい。
2009/06/12(金) 11:28:510385名無しさん＠お腹いっぱい。
2009/06/12(金) 12:07:200386名無しさん＠お腹いっぱい。
2009/06/12(金) 13:03:32いわゆるパーマンの法則
0387名無しさん＠お腹いっぱい。
2009/06/12(金) 13:32:350388名無しさん＠お腹いっぱい。
2009/06/12(金) 13:45:15ただし、必要なコストも目ん玉が飛び出るほどあがる。
いわゆる、Sun + Oracle の法則。
0389名無しさん＠お腹いっぱい。
2009/06/12(金) 13:47:320390名無しさん＠お腹いっぱい。
2009/06/12(金) 13:55:59だな。ある規模以上は逆立ちしても増やせないアーキに対して、
増設でそれの性能以上を出すシステムの価値は、小規模の場合の掛け算にはならない。
..って、こんなあたりまえのこと解説する必要があるとはwwwwwwww
Sunのミドル以上の SMP機のユーザーって、ファッションで買ってたとでも
思ってるのか?
0391名無しさん＠お腹いっぱい。
2009/06/12(金) 13:57:14QPIだとどういう構成が可能になる? 16ソケット 96コアを超えれそう?
0392名無しさん＠お腹いっぱい。
2009/06/12(金) 14:12:17
■ このスレッドは過去ログ倉庫に格納されています