Sun Microsystems 最期の落日
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2009/06/06(土) 20:00:02ITの未来はどっちだ！？
【前スレ】
Sun Microsystems 最期の神託
http://pc12.2ch.net/test/read.cgi/unix/1242038454/l50
0269名無しさん＠お腹いっぱい。
2009/06/11(木) 10:40:06だれかこれ↑の要約ぷりーず。
..オレがやっちゃうよ?w
0270名無しさん＠お腹いっぱい。
2009/06/11(木) 11:02:40NICがボトルネック
これでOK
>>269
勝手にどうぞ
ていうか、英語を斜め読みできない人は、高卒以下?
0271名無しさん＠お腹いっぱい。
2009/06/11(木) 12:24:49それはちと厳しいなｗｗｗ
0272名無しさん＠お腹いっぱい。
2009/06/11(木) 12:34:380273名無しさん＠お腹いっぱい。
2009/06/11(木) 12:45:47つーか、お前誰？ｗ
0274名無しさん＠お腹いっぱい。
2009/06/11(木) 13:07:00んじゃ
ttp://connexitor.com/blog/pivot/entry.php?id=191
こんな悲惨なアタマ打ちじゃない、リニアにスケールしてる記事プリーズ。
NICがボトルネックじゃないやつね。言っとくがオレ見たことないし。
0275名無しさん＠お腹いっぱい。
2009/06/11(木) 13:33:22なぁ、まずは
ttp://connexitor.com/blog/pivot/entry.php?id=191
を読めよ。
>>273
やべぇ、やべぇよ、その発言は。
対象の一人以外は全員が味方だという錯覚は、ヤベェよ。
>>274
論外な事例を持ち出して、それを否定するなら別のものを出せって、どういう了見だよ。
0276名無しさん＠お腹いっぱい。
2009/06/11(木) 13:35:53英語はおろか日本語もあやしい。
0277名無しさん＠お腹いっぱい。
2009/06/11(木) 13:36:02読めよも何も、それはヲレの出したURLだけど？
頭おかしいな
0278名無しさん＠お腹いっぱい。
2009/06/11(木) 13:45:11つまり、
グラフだけ見てスレに貼った、文章は読んでいない
ってことか。
文章も読めよ。
斜め読みでいいからさ。
0279名無しさん＠お腹いっぱい。
2009/06/11(木) 13:45:470280名無しさん＠お腹いっぱい。
2009/06/11(木) 13:46:50ttp://communities.intel.com/community/openportit/server/blog/2009/05/08/sparc-better-than-intel--no-it-is-not-and-i-have-data-to-prove-it
==英語を読まない人への要約==
UltraSPARC T2+がXeonより優れてるなんて、嘘っぱちだ。
0281名無しさん＠お腹いっぱい。
2009/06/11(木) 13:47:00ほいほい、要約要約。解説解説wwww
0282名無しさん＠お腹いっぱい。
2009/06/11(木) 13:47:40どこまでバカなのお前？
グダグダほざかずにさっさとx86でスケールする記事貼れば？
0283名無しさん＠お腹いっぱい。
2009/06/11(木) 13:48:230284名無しさん＠お腹いっぱい。
2009/06/11(木) 13:48:46要約、NICがボトルネック。
解説、SPARCとの比較ではないので無意味
0285名無しさん＠お腹いっぱい。
2009/06/11(木) 13:49:33あれあれれ? SPARCの記事は「Sun関連以外で」とか言っといて、思いっきり
intel.com かよ、ひでえ二重基準ーーww ひきょーものープw
0286名無しさん＠お腹いっぱい。
2009/06/11(木) 13:50:05お前が>>277なら、自分で要約しろよ。
0287名無しさん＠お腹いっぱい。
2009/06/11(木) 13:51:04Opteron vs Xeonの記事としてはXeonがスケールしないってことじゃねぇか？ｗ
0288名無しさん＠お腹いっぱい。
2009/06/11(木) 13:52:14よしっ、じゃあ、おじさん要約しちゃうぞw
UltraSPARC T2+ 4発と 128GBで 15万ドル
Xeon 7400 64GBで 3万 2千ドル
Xeonの方が安い!
以上
0289名無しさん＠お腹いっぱい。
2009/06/11(木) 13:52:270290名無しさん＠お腹いっぱい。
2009/06/11(木) 13:57:31いや、あれは NICドライバーの飽和(back-null)とスケジューラーのせい(back-hdb)で、
『改良された OpenLDAPのせいではない』、と言ってる。
根拠は特に示してなく、憶測。
0291名無しさん＠お腹いっぱい。
2009/06/11(木) 14:14:33やればいいのに。
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コアが速いほどメモリがボトルネックになる度合いが大きく、
スケーラビリティをあげるのは難しくなる。
むしろ単体コアで圧倒的でもこれだけのスケーラビリティを維持して、絶対性能で圧勝しているので
議論する意味もない。
■ このスレッドは過去ログ倉庫に格納されています