トップページunix
1001コメント323KB

Sun Microsystems 最期の落日

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2009/06/06(土) 20:00:02
Oracle傘下となったSun Mircrosystems
ITの未来はどっちだ!?


【前スレ】
Sun Microsystems 最期の神託
http://pc12.2ch.net/test/read.cgi/unix/1242038454/l50
0276名無しさん@お腹いっぱい。2009/06/11(木) 13:35:53
読まないどころではなく、読めないんだよ。
英語はおろか日本語もあやしい。
0277名無しさん@お腹いっぱい。2009/06/11(木) 13:36:02
>>275
読めよも何も、それはヲレの出したURLだけど?
頭おかしいな
0278名無しさん@お腹いっぱい。2009/06/11(木) 13:45:11
>>277
つまり、
グラフだけ見てスレに貼った、文章は読んでいない
ってことか。

文章も読めよ。
斜め読みでいいからさ。
0279名無しさん@お腹いっぱい。2009/06/11(木) 13:45:47
夢見ガチな人なんだよ。Intelの言ってないことまで捻出するからね。かわいそーw
0280名無しさん@お腹いっぱい。2009/06/11(木) 13:46:50
こんなん、見つけた。
ttp://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
>>278
ほいほい、要約要約。解説解説wwww
0282名無しさん@お腹いっぱい。2009/06/11(木) 13:47:40
>>278
どこまでバカなのお前?

グダグダほざかずにさっさとx86でスケールする記事貼れば?
0283名無しさん@お腹いっぱい。2009/06/11(木) 13:48:23
communities.intel.com
0284名無しさん@お腹いっぱい。2009/06/11(木) 13:48:46
>>281
要約、NICがボトルネック。
解説、SPARCとの比較ではないので無意味
0285名無しさん@お腹いっぱい。2009/06/11(木) 13:49:33
>>280
あれあれれ? SPARCの記事は「Sun関連以外で」とか言っといて、思いっきり
intel.com かよ、ひでえ二重基準ーーww ひきょーものープw
0286名無しさん@お腹いっぱい。2009/06/11(木) 13:50:05
>>282
お前が>>277なら、自分で要約しろよ。
0287名無しさん@お腹いっぱい。2009/06/11(木) 13:51:04
>>284
Opteron vs Xeonの記事としてはXeonがスケールしないってことじゃねぇか?w
0288名無しさん@お腹いっぱい。2009/06/11(木) 13:52:14
>>280
よしっ、じゃあ、おじさん要約しちゃうぞw

UltraSPARC T2+ 4発と 128GBで 15万ドル
Xeon 7400 64GBで 3万 2千ドル

Xeonの方が安い!

以上
0289名無しさん@お腹いっぱい。2009/06/11(木) 13:52:27
Intelがスケールするなんてそのintel.com(笑)の記事のどこを読んだら書いてあるのかな?w
0290名無しさん@お腹いっぱい。2009/06/11(木) 13:57:31
>>287
いや、あれは NICドライバーの飽和(back-null)とスケジューラーのせい(back-hdb)で、
『改良された OpenLDAPのせいではない』、と言ってる。
根拠は特に示してなく、憶測。
0291名無しさん@お腹いっぱい。2009/06/11(木) 14:14:33
しかし、あんなテストをなんでネットワーク越しにやるかな。127.0.0.1向いて
やればいいのに。
0292名無しさん@お腹いっぱい。2009/06/11(木) 14:14:47
結局Xeonがスケールしない事実には変わりないねぇ
0293名無しさん@お腹いっぱい。2009/06/11(木) 14:16:07
いや、きっとスケールするさ、きっと。ボクらが見つけられないだけなんだ。
たとえもしよしんばとりあえずそうだったとしても、もうすぐ QPIが出るよ、夢の QPIがw
0294名無しさん@お腹いっぱい。2009/06/11(木) 14:17:48
だよな
Intel凄いしパチョコン最強だもんな
おれら情弱だからぐぐり切れてないだけだしな
0295名無しさん@お腹いっぱい。2009/06/11(木) 14:19:01
NICドライバが悪いLinuxのスケジューラが悪い
でもOpenLDAPとXeonは悪くないんです!!!
0296名無しさん@お腹いっぱい。2009/06/11(木) 14:30:15
別に、intel.com(笑)の記事でもイイと思うんですよ?w
Intel(笑)のことを一番よく知ってるのはIntel(笑)の中の人だろうしw
スケールするかどうかすら書いてないのも、
ユーザには分からない何か深い理由があるんだろうwww
0297名無しさん@お腹いっぱい。2009/06/11(木) 14:33:15
SPECjbbでええやん
0298名無しさん@お腹いっぱい。2009/06/11(木) 14:34:27
>>295
OpenLDAPは悪くない。あいつはいいやつだ。Xeonが、悪い。
0299名無しさん@お腹いっぱい。2009/06/11(木) 14:34:58
安価なCPUでシェアを得られるように努力せよ
そして無学な民衆にXeonがスケールするかどうかや
エンプラでなにが大切かを教えてはならない
0300名無しさん@お腹いっぱい。2009/06/11(木) 14:44:49
>>283>>285
URLしか読んでないんだな。
その先に何が書いてあるのか、読んで見ろヨ。

>>289
SPARC信者が英語を読めるかどうかのテストなんだわ。
いまのところ、読めてないようなレスが多いな。

ま、URLだけ見て鬼の首を取ったかのような言動しているので、
それ以前って感じだが。

>>291
127.0.0.1でいくら性能が出ても、ネットワーク越しで性能がでなければ、
LDAPサーバの構築・運用っていう観点では、あんまり意味がないと思う。

>>292
条件を書かずに、ただ「スケールする」「スケールしない」って言うのはナンセンスだよ。
0301名無しさん@お腹いっぱい。2009/06/11(木) 14:46:15
客は価格しか見てないんです!
バーゲン!バーゲン!大バーゲン!
SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる!
あれ?SPARC64VIIとの比較は?w
負ける戦をしないのがIntelのいいところ
売れない製品ラインは即売却w

バカにするのもほどほどにしたまえよw
0302名無しさん@お腹いっぱい。2009/06/11(木) 14:47:14
それにしても狂信者の連投っぷりは凄いな

>>292 = >>293 = >>294 = >>295 = >>296
5連投ですか。
0303名無しさん@お腹いっぱい。2009/06/11(木) 14:50:56
>>301
> SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる!

Sunが主張していたよな。
サーバの価格よりも電気代のほうが重要、だから、CoolThreadsサーバを使うべきだ、と。

そのSunの主張に従って判断したら、Xeonのほうが優れてる、ってことになったんだわ。

> あれ?SPARC64VIIとの比較は?w
> 負ける戦をしないのがIntelのいいところ

この言葉を引用しよう
The absence of a result certainly says something very clear to me - no story.
0304名無しさん@お腹いっぱい。2009/06/11(木) 14:51:22
信者も何も、そのintel.comの一番下のコメントにすべて代弁してあるじゃん
ちゃんとx86気違イのお仲間が書いた記事ならそこまで読もうよ
0305名無しさん@お腹いっぱい。2009/06/11(木) 14:52:13
>>300
> URLしか読んでないんだな。

はぁ。URL指摘するのに、その先に何が書いてあるのか知ってないといかんの?

> SPARC信者が英語を読めるかどうかのテストなんだわ。

なるほどなるほど。で、英語が読めるとお気に入りの CPUがスケールするわけかよ?

英語の読めるバカもいるんだな。感心するわ。
0306名無しさん@お腹いっぱい。2009/06/11(木) 14:55:36
話題逸らしに必死だな
スケールするかの話なのにいつの間にか電気代の話になってる
ATOMでOracle走らせてろよw
0307名無しさん@お腹いっぱい。2009/06/11(木) 14:57:22
SPECjbb-2005の、SPARC64VIIの4ソケットの結果、ないな。
0308名無しさん@お腹いっぱい。2009/06/11(木) 15:01:44
>>304
一番下のコメントって、
SPARCには、UltraSPARC T2+なんかのローエンドだけではなく、メインフレーム代替のハイエンド機がある。
そういうアップグレードパスの存在を無視して、ローエンドの性能の低さを批判するのは良くない、ってことだろ。

それはその通りだ。
そこまでの信頼性が必要な客は、UltraSPARCなんか買わずに、初手からSPARC64いっとくべきだ。
0309名無しさん@お腹いっぱい。2009/06/11(木) 15:03:54
>>305
指摘しなくたって、みんなわかっとるよ。
誰のどこでの発言か、ということよりも、発言内容のほうが大切だってのは、言われなくても、わ・か・れ。

ベンチマークで良好なスコアを出てるのは、必要な領域ではスケールしているってことじゃないか?
実用上、問題がなければ、それでいいじゃないか。

たとえばメモリのピーク帯域幅を調べるようなベンチマークでスケールしなかったら、何が問題?
0310名無しさん@お腹いっぱい。2009/06/11(木) 15:04:00
もっかい読んでみたけど >288 以上のことは特に書いてなかったぞ。
つーか、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
>>309
おまえなー、もったいつけてないで、さっさと要点書けよ。何様のつもりなんだよ?
立派な英文学の知識で、さぞかしすごい訳文さらしてくれるんだろーな? 期待してるぞ。
0314名無しさん@お腹いっぱい。2009/06/11(木) 15:16:48
10年以上前からIntelがスケールしない状況は全然変わっていないわけで
今更どうしようもないっすよ
議論してもムダです
それが分かってるから違う分野で勝負かけてるわけで
全部失敗してるけどなw
0315名無しさん@お腹いっぱい。2009/06/11(木) 15:19:16
>>310から>>314まで、またもや5連投か。

ほい、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
いいよ、もう、x86はスケールしないってことで。
スケールするSPARCよりも性能が高いんだから、スケールしなくたって十分だ。
0317名無しさん@お腹いっぱい。2009/06/11(木) 15:23:10
最近スレの流れ速過ぎ。

Sunの人が行き場を失って、管を巻くしかやること無いのか?w
0318名無しさん@お腹いっぱい。2009/06/11(木) 15:26:42

ttp://www.mizuao.com/specsample/yuitable_0_0_3.html
0319名無しさん@お腹いっぱい。2009/06/11(木) 15:27:36
性能が高い、ねぇw
Vista SP2ならCeleronで十分だなw
0320名無しさん@お腹いっぱい。2009/06/11(木) 15:38:54
>>316
いいよ、もう、x86はスケールしないってことで。
オレはパチョコンしか使わないんだから、スケールしなくたって十分だ。
0321名無しさん@お腹いっぱい。2009/06/11(木) 15:40:20
>>319
どうした? 話を逸らすにしても、ネタが愚劣すぎるぞ
0322名無しさん@お腹いっぱい。2009/06/11(木) 15:41:13
そんな
まだ諦めんなよ
QPIが来れば、勝つるんだから
0323名無しさん@お腹いっぱい。2009/06/11(木) 15:42:41
そうそう、QPIで大逆転するんだからさ、今までのはカスでも。
0324名無しさん@お腹いっぱい。2009/06/11(木) 15:44:29
で、>280 にはなんて書いてあったんだ? 隠れた意味があるんだろ?
一文字おきに読んだりすればいいのか? それともどっかをタテ読み??
0325名無しさん@お腹いっぱい。2009/06/11(木) 15:46:01
>>321
逸らすも何も、適材適所でいいじゃん
ESXのGUI版管理コンソールはWinでしか動かないんだしさぁ
便利な方、楽な方に流れればサーバはSolarisだし
開発はVMware上のLinuxだし、x86使うならホストOSはWindowsでしょ
SPARC使った方が楽ならそっちの方がいいよ
ムリしてx86なんて辛すぎる
0326名無しさん@お腹いっぱい。2009/06/11(木) 15:47:53
>>324
画面から 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
>>327
> 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
>>315
あ、こっちか。これって違う機種なんだな..

> SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
> Processor Intel Xeon processor X7460

これって QPI?
0330名無しさん@お腹いっぱい。2009/06/11(木) 16:23:40
Penrynを3つ搭載
多分FSBと思う
0331名無しさん@お腹いっぱい。2009/06/11(木) 16:25:26
X3370
X7460
どちらも45nmの、QPIになる前の製品だよ。
0332名無しさん@お腹いっぱい。2009/06/11(木) 16:26:43
んじゃ、QPIで大幅に改善、だw
0333名無しさん@お腹いっぱい。2009/06/11(木) 16:27:34
おっとX3370は3.00GHzで、X7460は2.66GHzか。

コアが21.3倍で性能は11.6倍・・・つっても54%だな。
0334名無しさん@お腹いっぱい。2009/06/11(木) 16:29:44
ttp://www.spec.org/osg/jbb2005/results/res2008q4/jbb2005-20081022-00543.html
SPECjbb2005 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:05
>>332
QPIを導入するまでもなく、SPARC64 VIIよりXeonのほうが性能が上なんですが。
1ソケットなら3倍
16ソケットでも2.6倍

改善ではなく、さらに差を広げる、だろう。
0336名無しさん@お腹いっぱい。2009/06/11(木) 16:34:24
>>334
16ソケットと比べると、コア4倍で性能2.15倍か。

64ソケットも注ぎ込んでも、Xeonの16ソケットに追い付かないんだな。
0337名無しさん@お腹いっぱい。2009/06/11(木) 16:36:13
>>335
なんでそう話をごちゃまぜにするかな...

> 改善ではなく、さらに差を広げる、だろう。

スケーラビリティが「改善」する。4コアとか FSBでスケールしてる規模では
むしろオーバーヘッドになる。
0338名無しさん@お腹いっぱい。2009/06/11(木) 16:39:06
>>336
まあ、x86この先もせいぜい性能が伸びるといいけどな。
Sandy Bridgeで AVXな。ベクトルベクトルw
0339名無しさん@お腹いっぱい。2009/06/11(木) 16:44:52
x86のスケーラビリティを高める、いちばん、簡単な方法は・・・

ズバリ、コアのクロックを下げる
SPARC64 VIIと同程度の性能になるまで、コアのクロックを下げる

それだけでスケーラビリティは良くなりますよ。


逆に言うと、
SPARC64VIIのコアのクロックをXeonと同程度の性能になるまで上げることができれば、
スケーラビリティが下がるでしょうね。
0340名無しさん@お腹いっぱい。2009/06/11(木) 16:51:21
>>339
そんな単純なもんじゃないだろ。
帯域幅がボトルネックならともかく。
0341名無しさん@お腹いっぱい。2009/06/11(木) 16:57:50
そうやってコアのクロックを下げた製品がXeon MPじゃん
0342名無しさん@お腹いっぱい。2009/06/11(木) 16:58:35
あたま悪いねー。インターコネクトの飽和は相対的な問題だっての。
絶対値の問題ではない。
0343名無しさん@お腹いっぱい。2009/06/11(木) 17:00:36
バスの概念しか頭にない限りいくら絞ってもムダ。理解はムリ。
0344名無しさん@お腹いっぱい。2009/06/11(木) 17:28:00
で、Xeonよりも高性能なSPARCはどれ?
0345名無しさん@お腹いっぱい。2009/06/11(木) 17:30:40
CPU単体では売ってませんから
0346名無しさん@お腹いっぱい。2009/06/11(木) 17:56:32
Xeon採用サーバよりも高性能なSPARC採用サーバ、って意味だろが。
0347名無しさん@お腹いっぱい。2009/06/11(木) 18:10:41
>>315

> 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:56
>>347
QPIだとどういう構成が可能になる? 16ソケット 96コアを超えれそう?
0349名無しさん@お腹いっぱい。2009/06/11(木) 19:05:45
SPECjbb以外の公表値はないの?
0350名無しさん@お腹いっぱい。2009/06/11(木) 19:08:15
SPARCの結果を貼って楽しいのは、他にはSPEC CINT2006rateくらいかな。
0351名無しさん@お腹いっぱい。2009/06/11(木) 19:12:46
ほい。
ttp://www.spec.org/power_ssj2008/results/
0352名無しさん@お腹いっぱい。2009/06/11(木) 19:21:14
スケール具合のグラフ見つけたよ。PostgreSQLは優秀だねぇ。

ttp://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:18
>>351
SPARCがいません。
0354名無しさん@お腹いっぱい。2009/06/11(木) 19:32:25
ttp://tweakers.net/reviews/649/8/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-8.html
うむ、US T1よりもOpteronのほうが優れているように見えるね。
0355名無しさん@お腹いっぱい。2009/06/11(木) 19:33:52
>>353
勝てない戦いはしない、ってことかと。
0356名無しさん@お腹いっぱい。2009/06/11(木) 19:38:04
>>251
そうだね
0357名無しさん@お腹いっぱい。2009/06/11(木) 19:53:56
AndyタソのNehalemスパコンきたー!

http://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
>>357
あの6000シリーズ(だよね?)のブレードにXeon 4発か。すげーな。

Sunってさ、SPARCよりもx86のほうが、高密度なブレードを製品化してるよね。
6000シリーズだとSPARCだと1発しかなかったと思う。
0360名無しさん@お腹いっぱい。2009/06/11(木) 21:47:17
SPARCじゃ性能出ないし
0361名無しさん@お腹いっぱい。2009/06/11(木) 23:06:09
>>359
忘れた頃に2ソケットの出たよ
いまだに4ソケットは出ない

過去スレに貼られていたPDFでは、
4ソケットならOpteronやXeonよりもスパコン性能高いよ
ってな計算があったが、いまだに4ソケットは作られず。
0362名無しさん@お腹いっぱい。2009/06/11(木) 23:06:51
354 :名無しさん@お腹いっぱい。 [↓] :2009/06/11(木) 19:32:25
ttp://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
>>362
下のグラフは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
jbb2005のスコアが示すように、
スケールしなくてもSPARCよりXeonのほうが性能が高い、ゆえに、スケールしないのは問題ではない
っていうことで、スケールするかどうかは、どうでもいいんだわな。
0365名無しさん@お腹いっぱい。2009/06/11(木) 23:31:44
>上のグラフを見ると、T1のほうがスケールしているよ。
お前が言ってるのはスループット。
スケーラビリティって言葉の意味わかってるか?
コア数が増えたときにどれだけ性能が伸びてるかだぞ。
もう一度グラフとにらめっこして出直してこいw
0366名無しさん@お腹いっぱい。2009/06/11(木) 23:32:50
スケーラビリティでいうと、上のグラフは両者互角。
下のグラフではSPARCがぼろぼろということになる。
0367名無しさん@お腹いっぱい。2009/06/11(木) 23:37:20
もしかしてこんなグラフも読めないやつが多いようなので念のためいっとくと
スループットでSPARCが粘っているのはハードウエアマルチスレッディングがあるから。
つーか、このくらいは直ぐ見てわからんとスループットコンピューティングの意味理解できんぞ。
0368名無しさん@お腹いっぱい。2009/06/11(木) 23:40:13
>>364
メモリ=DRAMに関してはCPUメーカーの技術差が出にくいので
基本的にはCPUコアが速いほどメモリがボトルネックになる度合いが大きく、
スケーラビリティをあげるのは難しくなる。
むしろ単体コアで圧倒的でもこれだけのスケーラビリティを維持して、絶対性能で圧勝しているので
議論する意味もない。
0369名無しさん@お腹いっぱい。2009/06/11(木) 23:42:18
Xeon最強!
0370名無しさん@お腹いっぱい。2009/06/11(木) 23:51:30
>>365
おまえ、グラフろくに見てないだろ。
横軸はコア数ではないぞ。

>>367
SPARCが粘ってる? 何を言っとるんだ。
Concurrencyが低いと性能が出てないだけじゃないか。
0371名無しさん@お腹いっぱい。2009/06/11(木) 23:51:32
>>363
確かに差はよくみないとわからないが、
SPARCの方がスケールしているよな。
0372名無しさん@お腹いっぱい。2009/06/11(木) 23:54:01
それにしても俺が書き込んでいるときはSPARC厨が静かなんだよなあ。
次の日会社で仕事している時間帯によっぽど暇なのかニートなのか知らないが、
SPARCマンセー書き込みで暴れている不思議w
0373名無しさん@お腹いっぱい。2009/06/11(木) 23:55:23
じつは君の裏の姿がSPARC(ry
0374名無しさん@お腹いっぱい。2009/06/11(木) 23:56:09
>>327の前後とか日中こいつら一体何してるんだろうかと思う。
まあ、こんな単純な現実の性能話も理解できないようでは
少なくともコンピュータ関係の仕事は続けられないだろうが。
0375名無しさん@お腹いっぱい。2009/06/12(金) 00:20:40
>>298
> OpenLDAPは悪くない。あいつはいいやつだ。

ちょっとスレ違いだが、
例えばback-sqlなんか使うとスケールしているベンチマーク結果とかあるの?
■ このスレッドは過去ログ倉庫に格納されています