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

Sun Microsystems 最期の神託

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001名無しさん＠お腹いっぱい。2009/05/11(月) 19:40:54
コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」


【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/
0876名無しさん＠お腹いっぱい。2009/06/04(木) 11:02:54
そんな過去の失敗事例を、いつまでも叩き続けるなよ。
XeonやOpteronには、それこそ膨大なエラッタが現在進行形であるんだぞ。

まぁ自分なら、Xeonの枯れたところを選ぶがね。
0877名無しさん＠お腹いっぱい。2009/06/04(木) 11:55:36
だったら実績のある SPARC64 でいいじゃんｗ
0878名無しさん＠お腹いっぱい。2009/06/04(木) 12:00:28
>>875
それは「信頼性問題」じゃないだろ..
0879名無しさん＠お腹いっぱい。2009/06/04(木) 12:14:50
>>878
会社に対する信頼の問題だな。

64bitとして売っておきながら、実際には32bitだったのなら。
0880名無しさん＠お腹いっぱい。2009/06/04(木) 12:52:16
>879
> 64bitとして売っておきながら、実際には32bitだったのなら。

をっと、x86 core architectureに対する悪口はそこまでだ。
0881名無しさん＠お腹いっぱい。2009/06/04(木) 13:19:52
くだらない.. ネタないんだな。
0882名無しさん＠お腹いっぱい。2009/06/04(木) 14:27:25
L3をoffにしたCPUもあったじゃないの
仮想化使って過負荷にしないとバグを再現できないみたいだが
0883名無しさん＠お腹いっぱい。2009/06/04(木) 15:42:12
だからー、信頼性問題つったら、運用時の故障だろうがよ。
まともな話題全部「埋めて」くれるなオマエは。鳥頭過ぎなんだよ。くんじゃねーよ。
0884名無しさん＠お腹いっぱい。2009/06/04(木) 15:58:46
>>883には自分がスレを荒廃させたという自覚がないようです。
0885名無しさん＠お腹いっぱい。2009/06/04(木) 15:59:44
なんでそんなにおつむよわいの?
0886名無しさん＠お腹いっぱい。2009/06/04(木) 16:11:50
馬鹿を上手にあしらえないのなら黙ってろ。
0887名無しさん＠お腹いっぱい。2009/06/04(木) 16:14:48
あしらうどころから煽るだけの低能
0888名無しさん＠お腹いっぱい。2009/06/04(木) 17:27:31
「故障が故障が」言ってたやついたけど、実害にあったやつ実は少ないんだな..
ガセか?
オレは Fire 6800と 4500が稼働する環境と付き合ったことあるけど、
uptimeでみる限り両方とも何年もノントラブルだったけどな。
0889名無しさん＠お腹いっぱい。2009/06/04(木) 17:28:47
それは電源入ってただけ
0890名無しさん＠お腹いっぱい。2009/06/04(木) 17:52:30
いや、ORACLEでめいっぱいディスク領域取ってそこそこのトランザクションと
日次バッチ走るようになってたよ。オレはそこに寄生させてもらう小さいの
作っただけだったけど。Fire 6800の方。
ビクともしてなかったね。
4500の方は、常時負荷かかかるような環境じゃなかったけど、
突発的に処理のかかるようなシステム。自然現象相手のやつ。
やっぱデマなんだな..
0891名無しさん＠お腹いっぱい。2009/06/04(木) 18:02:20
そういえばもう一つあった、Fire 4800だったと思うな、隣のグループが Javaの
サーブレットコンテナ走らしてて、スワップが 4GBで足りなくて 1GB増やしたら
どうの、ってガリガリ開発やってた。
かなり長期間に渡って開発に使ってて、同じ構成でたくさんユーザー先に
導入してるはずたけど、ハードウェアに問題が出たなんて聞いたことがない。
0892名無しさん＠お腹いっぱい。2009/06/04(木) 18:29:10
おれも四桁台ではない
三桁台ならE450がひどかった
0893名無しさん＠お腹いっぱい。2009/06/04(木) 18:35:52
Sunでボロボロだったのは、もっと前。

しかしなんだな、6800なんて詐欺みたいなマシン・・・ご愁傷さま。
0894名無しさん＠お腹いっぱい。2009/06/04(木) 18:39:26
3桁台ならそれこそ両手で軽く足らんくらい扱ったが、そんな不良なんぞ
一切聞いたことがないぞ。
ここで誰か書いてたのは E20kの話だったと思うけどな。
0895名無しさん＠お腹いっぱい。2009/06/04(木) 18:41:57
>>893
まあ、買ったのはオレじゃないし.. 大学病院。
自分じゃよー買わんわけだが、価格設定は、各社そんなに差はないだろ。
パソコンのスペック掛け算する性癖のある貧乏人には、そりゃ高いわなwwww
0896名無しさん＠お腹いっぱい。2009/06/04(木) 18:53:26
いや、そういうんじゃなくてさ。

6800って、ドメインで使うわけだが、結局、出番のない柔軟性だったりするんよ。
0897名無しさん＠お腹いっぱい。2009/06/04(木) 23:28:39
>>874
あったよ。だからCDMっていうfpu部のチェックツールがでてきた。
まあItaniumにも問題があってＣＰＵ交換の話があったけどね。
0898名無しさん＠お腹いっぱい。2009/06/04(木) 23:39:46
>>894
2000夏のこの問題にはやられなかったんですね。よかったですね。
> Systems affected by the problem appear to be those
> based on 400-MHz UltraSPARC-II CPU modules
> using either a 4MB or 8MB cache.
これはSunがバックレたから避難の嵐だった。

逆にE20kは全く問題なかった。
i-modeの事件もE20kの問題じゃないしね。
0899名無しさん＠お腹いっぱい。2009/06/04(木) 23:41:17
>>896
柔軟性は高いけど、その分価格が高いからね。
0900名無しさん＠お腹いっぱい。2009/06/04(木) 23:54:33
次スレ

Sun Microsystems 最大の企業売春
http://pc12.2ch.net/test/read.cgi/unix/1242037807/
0901名無しさん＠お腹いっぱい。2009/06/04(木) 23:57:34
>>498
Cacheエラーの問題だろ？
Sunはばっくれちゃいねーよ。
全部ミラードCacheの石に交換したｗ
UIIはひどい石だったな。
次のUIIIもダメで、結局UVIまで石の信頼性は上がらなかった。
逆に言うと、UVI以降、深刻なトラブルは起きていない。

最近のSunがダメなのはミッドレンジ以上のサーバじゃなくて
エッジ系のサーバ。
製造委託している会社があまりにもひどくて、「お前ら、絶対
出荷検査していねーだろ」と思うくらい故障率の高いモデルが
二年に1回位現れる。
その度にSunは反省するんだけど、二年経つと忘れるんだなｗ

T2搭載した5000系のサーバのファーストロットがボロボロ。
ブレードの二世代目もボロボロ。
X4150もメモリのエラーが多くてｗ

設計は優れていると思うんだが、製造委託先が間違って
いるよｗ

Oracleに救済されるまで落ちぶれたのはある意味当然。
0902名無しさん＠お腹いっぱい。2009/06/05(金) 00:31:34
>>901
これ、相手によって対応に差があったんだよ。
全部交換しますって告知はしなかった。

> 設計は優れていると思うんだが、製造委託先が間違っているよｗ

これはその通り。アメリカのメーカはそういうの結構多いね。
0903名無しさん＠お腹いっぱい。2009/06/05(金) 00:38:28
＞製造委託している会社があまりにもひどくて、「お前ら、絶対
＞出荷検査していねーだろ」と思うくらい故障率の高いモデルが
＞二年に1回位現れる。
＞その度にSunは反省するんだけど、二年経つと忘れるんだなｗ
反省なんてしてねーよ。
客先別にテスト項目が違うんだ。文句言うとテストが厳しくなる。テストに落ちたものは別の客先行きになる。
0904名無しさん＠お腹いっぱい。2009/06/05(金) 00:45:30
>>800
だからまだNehalem-EXが出てないんだよ、馬鹿。
Nehalem-EXが出るまで待て。リニアにスケールとか議論する以前に
少ないCPUでも大差で勝てちゃうからそんな話題にすらならんと思うがw
あとスケーラビリティが向上するのはQPIだけじゃないんだけど、
cacheのプロトコルとかAPICの拡張とかがある。
まあここのSPARC馬鹿には説明しても理解できない内容であるが。
0905名無しさん＠お腹いっぱい。2009/06/05(金) 00:49:23
つか、今のx86とまとも性能比較できるのってもうPOWER6くらいだろ?
他は比較するのも可愛そうなくらいの差がついて久しいのだが。
0906名無しさん＠お腹いっぱい。2009/06/05(金) 00:55:11
POWER6もNehalemの登場で脱落だろ
0907名無しさん＠お腹いっぱい。2009/06/05(金) 00:56:05
ここでよく暴れてるSPARCしか見えてない頭のおかしい人は
認めたくない現実から目を背けてしまったんだよ
Windowsを大昔の認識のまま語る頭のおかしい人も同じ
0908名無しさん＠お腹いっぱい。2009/06/05(金) 01:17:23
良いんじゃないの、ベンチマークじゃなくてアプリを動かせば世界一速い CPU らしいから w
0909,,・´∀｀・,,）っ-○○○2009/06/05(金) 05:52:58
今のSPARCって1コア当たりの性能でAtomより速いかどうかも微妙
0910名無しさん＠お腹いっぱい。2009/06/05(金) 06:20:01
1990年からSUN信者が現在にタイムマシンでやってきて、今のSUNの現状も見たら、、
0911名無しさん＠お腹いっぱい。2009/06/05(金) 06:20:43
>>901
コストカットしないと、高くて売れないから、綱渡りになるのは仕方ないと思う。
0912名無しさん＠お腹いっぱい。2009/06/05(金) 06:23:27
>>909
UltraSPARCシリーズは、まぁ、そうだろうが、
富士通のSPARC64は、かなり速いんじゃないか?

もうSPARC使わなくなって久しいので実機触れん。
0913名無しさん＠お腹いっぱい。2009/06/05(金) 06:36:19
AtomはPentium-Mより遅いぞ
使ってみればわかるがマジで遅くてストレスたまるレベル
0914名無しさん＠お腹いっぱい。2009/06/05(金) 08:09:40
>>903
>文句言うとテストが厳しくなる。テストに落ちたものは別の客先行きになる。

うわー外国企業にありがちな話だなw

もっとも、最近はキヤノンの品質管理が酷い話とか記事を見ると
日本企業も短期的なコスト重視で欧米化してるのかな。
0915名無しさん＠お腹いっぱい。2009/06/05(金) 08:28:53
>その度にSunは反省するんだけど、二年経つと忘れるんだなｗ

半年ごとに担当者が入れ替わるからだろｗ
0916名無しさん＠お腹いっぱい。2009/06/05(金) 09:26:46
担当者っていうか、委託先の製造ライン人がみんな入れ替わっちゃうらしいよ。
中国人のIT関連労働者って３−６ヶ月で仕事を変わるのが普通らしい。いくら
製造技術や品質管理の教育しても追いつかない。
0917名無しさん＠お腹いっぱい。2009/06/05(金) 11:02:24
中国の工場は、人を教育するだけ無駄。
他所の工場で教育を施された人を高給で引き抜くしか手はない。
0918名無しさん＠お腹いっぱい。2009/06/05(金) 11:03:26
関連工場がみな中国にあるから、しかたなく、中国に工場を構えてるんだろうな。
台湾とか東南アジアとか、もっと良い場所はあるんだが、関連工場がないんだわ。
0919名無しさん＠お腹いっぱい。2009/06/05(金) 11:06:24
中国共産党の巧みな戦略だよ。
世界の工場になって技術とビジネスを吸い取るのは。

安いからといって中国に工場を移したり、中国の工場に発注したりしていると、
そのうち、中国なしには何も作れなくなって、中国に頭が上がらなくなっちゃう。

というわけで、Sunは昔からの製造委託先の日本を、もっと使ってほしいな。
0920名無しさん＠お腹いっぱい。2009/06/05(金) 11:08:31
昔は英国製の多かったよな。東欧にもあったような。
0921名無しさん＠お腹いっぱい。2009/06/05(金) 11:14:26
どーせアジアに生産拠点おくなら台湾でいいじゃんｗ
0922名無しさん＠お腹いっぱい。2009/06/05(金) 11:41:08
台湾よりも中国のほうが便利なんだよ。
今は部品工場が中国にあるから、台湾で製造するとなると、手間が増える。
0923名無しさん＠お腹いっぱい。2009/06/05(金) 12:52:53
TIの工場って中国にあるの？
0924名無しさん＠お腹いっぱい。2009/06/05(金) 13:03:45
あっはっはぁ。
0925名無しさん＠お腹いっぱい。2009/06/05(金) 15:33:59
ZFS、SMFなどSolaris由来の技術と13,000ものUbuntu由来パッケージが利用できる「Nexenta」レビュー
http://sourceforge.jp/magazine/09/06/03/088248
0926名無しさん＠お腹いっぱい。2009/06/05(金) 18:13:33
>>920
痛リア製もあったな。なつかしい。
0927名無しさん＠お腹いっぱい。2009/06/05(金) 19:03:22
ピザボックスならイタリア製で適切
0928名無しさん＠お腹いっぱい。2009/06/05(金) 19:59:35
>>923
CPUじゃなくてサーバの話さ。

>>926
Olivettiだっけ?
0929名無しさん＠お腹いっぱい。2009/06/05(金) 20:04:01
オリベッティのミニノート欲しかったなあ…
0930名無しさん＠お腹いっぱい。2009/06/05(金) 20:37:02
えーと、スレタイお願いします。あれは予備スレってことで。
0931名無しさん＠お腹いっぱい。2009/06/05(金) 20:58:57
Sun Microsystems 最期の瞬間
0932名無しさん＠お腹いっぱい。2009/06/05(金) 21:47:11
最後のリリース、でいいんじゃない?
0933名無しさん＠お腹いっぱい。2009/06/05(金) 21:52:26
未だにPower6をありがたがっている奴がいることに驚く。
ダメダメと言われたSPARC(UltraSPARC T2/T2+)にも
性能で負けているのにｗ

Nehalem-EPと比べるのもおこがましいわ。
int/fpともに2倍の大差じゃんｗ

RISC系で期待出来るのは、富士通のSPARC64VIIIfx
だけかもな
0934名無しさん＠お腹いっぱい。2009/06/05(金) 21:58:46
SPECrate以外の...はもういいや。
0935名無しさん＠お腹いっぱい。2009/06/05(金) 22:08:20
当分は、SPARC64VIIIfxは全量が京速スパコンに行くんじゃね?
0936名無しさん＠お腹いっぱい。2009/06/05(金) 22:32:56
>>934
いろんなCPU上でのビジネスアプリ走らせて見ると
SPECint_rateの比に近くなるけどな。
どちらにせよ、Xeon4500系にPower6は勝てないのは
明白。まぁ、1〜2世代の差をつけられているので
当然の事だけど。
0937名無しさん＠お腹いっぱい。2009/06/05(金) 22:36:59
>>935
エリソンに買い占めてもらうかｗ
fx大量生産して欲しいな
0938名無しさん＠お腹いっぱい。2009/06/05(金) 23:08:34
826 名前：Trader＠Live![sage] 投稿日：2009/06/05(金) 23:06:18 ID:8uS1IHmE
だまれ小僧！お前にサンが救えるか

＜ｵｼﾒ

0939名無しさん＠お腹いっぱい。2009/06/06(土) 00:08:28
http://www.atmarkit.co.jp/news/200906/03/javaone.html

オラクル CEOのラリー・エリソン氏はヨット好きで知られている。世界最大のヨットレース、
アメリカズカップにも出場するエリソン氏所有のヨットで、「タダでJavaの宣伝をしてくれる
かもしれないよね」とマクニーリ氏

あるいはスタジアムに、こんな名前が付くかもねと写したのは「Ultra SPARC」のロゴ付きの
スタジアム

ついにアップルのiPhoneにJavaを載せる話を付けてくれるかもしれないじゃないかとジョーク

夢がひろがりんぐ wwww
0940名無しさん＠お腹いっぱい。2009/06/06(土) 01:02:56
> cacheのプロトコルとかAPICの拡張とかがある。

cache coherenceでよく使われるのは、snoopとdirectory-basedだが、directory-basedだと遅い上に
ccNUMAのように一様でなくなってしまうので、性能が劣化する。現実はsnoopが一番早いのだが、
バス飽和がある。64CPU以上でバス飽和させないためには、M-seriesのようにsuper computerの技術を
転用したバス飽和しない帯域を持つバスを展開するしかないが、これができるのは基本的にFujitsu。
IBMはCPU数を少なく（だが1 CPUは速い）して、たかだが64CPUに留めることで対応しているようだ。
その他の64CPU以上のものは、NUMAになってしまう（ので、性能が劣化する）。

それと、IBMは、Power7を開発中のはずで、8 core, 45nm processのこのCPUは、１つで256GFLOPSを
達成すると言われている。Power/SPARC/Xeon/Itaniumは当分性能争いするはず。

0941名無しさん＠お腹いっぱい。2009/06/06(土) 02:10:45
↑典型的flops厨
>Power/SPARC/Xeon/Itaniumは当分性能争いするはず。
なんねーよ
既になってねーし、Gflopsなんてサーバじゃ殆ど関係ねーよ、バーカ
0942名無しさん＠お腹いっぱい。2009/06/06(土) 02:15:09
富士通のSPARCは流石にSunのよりは格段に速いが、
x86やPOWER6には遠く及んでない。実装の規模からして違う。
Itaniumも将来性ないし、もう比較の対象じゃない。
とっくにわかりきったことだが、現実を受け入れられない珍比較が蔓延しているところが
このスレの見所だなw
0943名無しさん＠お腹いっぱい。2009/06/06(土) 02:48:50
本当にSPARCのスケーラビリティが素晴らしいのならばHPCで一世を風靡していても
よさそうなものだが、TOP500をみるともう嫌になるほどIBMやx86陣営ばっかり。
実はSunも6位にランクしているのだが、CPUはやっぱりOpteronであってSPARCではない。
ここ1, 2年だけみてもx86とIBMのハイエンド一色化がどんどん進行してるだけなんだが。
このスレのSPARCマンセーさん達も恐れずに現実の世界に少しは足を踏み出してみようよ。
http://www.top500.org/list/2008/11/100
0944名無しさん＠お腹いっぱい。2009/06/06(土) 04:01:56
TOP500(笑)

HPCでメシが食える人はそれでもいいんじゃないの？
0945名無しさん＠お腹いっぱい。2009/06/06(土) 07:20:51
> バス飽和しない帯域を持つバスを展開するしかない

もう１つの理由は、cross barが作れないこと。cross barで接続するのが理想であることは既知だったが、
cross barはCPU数が増えれば指数関数的にpathの数が増加するために、従来より大規模コンピュータでは
事実上不可能と言われていた。事実、Tanenbaumは、その著書で64CPUがUMAとしての上限としているのは、
ここの理由から来ているようだ。また、AMDのHT Link数をみれば現実として如何にそれが容易なことでは
ないのかが分かる。(そのため、CPU数が増えればNUMAによる性能劣化をみる)

従来のSupercomputerではcross barを必要としたため、path数を押さえてcross barを製造する特許を
幾つか持つFujitsuでは、M-Seriesなどで64CPU以上をcross barで接続しているが、これを行えるのも、
今のところFujitsuだけのようである。そのため、他社はCPU数を64以下にするか、NUMAにせざるを
得ない。結局のところ、snoop/cross barを越えるものはないが、実際製造できないため、CPU数を
押さえたり（その代わりMulti Core）、他の方式にせざるを得ないというのが実際のところ。
0946名無しさん＠お腹いっぱい。2009/06/06(土) 08:47:44
>>935
京速スパコンで使うのは、コアやキャッシュが全て良品で、所定のクロックで動作するものだけだろう。
ダイは決して小さくないので、かなりの数の不良が出るはず。

コアやキャッシュを部分的にdisableにしたり、クロックを落したもの・・・富士通は外に出さないんだっけ?
SunのNiagaraのように、出してくれれば・・・。
0947名無しさん＠お腹いっぱい。2009/06/06(土) 08:58:10
>>940
Sunはsnoopとdirectory-basedの両方ともやったけど、どちらも一長一短だったね。
前者は実効帯域幅が足りないし、後者はレイテンシが大きくて。
富士通は偉いよね、見かけ倒しにならないように、ちゃんとしたものを作ってる。
0948名無しさん＠お腹いっぱい。2009/06/06(土) 09:02:18
>>943
HPCを大規模SMPでやるのはコストパフォーマンス的に、小規模SMPのクラスタに勝てない。

>>945
HPCだと、地球シミュレータもクロスバーだよ。
0949名無しさん＠お腹いっぱい。2009/06/06(土) 09:08:31
Sunが提唱するスループット・コンピューティング
なんか言い訳くさいんだが、現実に即したアプローチは大切だ

問題は、Sunのプロセッサの開発力

レイテンシが大きいなら1コアで多数のスレッドを実行しよう、というのは良い
でも、それをNiagara系でしか、やっていないのがダメだ
SMPできないT1、T2、SMPできるがUltraSPARC IV+と交換できないT2+

Rockなんて複雑なものはいらないから、UltraSPARC V を出すべきだった。
IV+ に 4スレッドくらいのマルチスレッドを実装するだけで十分だったはずだ。

それをやらなかったのは、Fireplaneがネックだったんだろうな。
0950名無しさん＠お腹いっぱい。2009/06/06(土) 09:44:49
UltraSPARC Vはより高度な実装を目指していたが
何年も完成のめどが立たず破棄されたな
0951名無しさん＠お腹いっぱい。2009/06/06(土) 09:47:21
次スレ

Sun Microsystems 最大の企業売春
http://pc12.2ch.net/test/read.cgi/unix/1242037807/
0952名無しさん＠お腹いっぱい。2009/06/06(土) 10:21:06
fireplaneな製品ラインは、どーなるの?

生き残っているのはNetra 1290だけだよな。
Rockが完成しても、それを乗せるサーバが4Uサイズ以下じゃ・・・
0953名無しさん＠お腹いっぱい。2009/06/06(土) 10:23:20
Rockを廃棄すればOK
0954名無しさん＠お腹いっぱい。2009/06/06(土) 10:51:50
Rockは死んだのか？
0955名無しさん＠お腹いっぱい。2009/06/06(土) 11:00:55
Niagara2に釣り合うパフォーマンスのバックプレーンすら、Sunには作れなかったのですよ。

Niagara2の64CPU、4096スレッド、リニアにスケールしたら素晴らしいと思いませんか?
しかし、Sunには作れなかったのです。

もしRockに見合うバックプレーンが並行して開発されていれば、Rockが遅れているのだから、
バックプレーンはすでに完成しているはずです。そのバックプレーンにNiagara2を組み合わせた
システムをリリースしないのは、なぜか。・・・ 考えれば考えるほど、富士通に一本化すべきでしょう。
0956名無しさん＠お腹いっぱい。2009/06/06(土) 11:06:37
Niagaraの先行きもよくわからん
予定の性能は出たけどリリース遅れて陳腐化しちゃいましたはカンベンな
0957名無しさん＠お腹いっぱい。2009/06/06(土) 11:10:30
そういえばNiagara3について何も聞かなくなったな
0958名無しさん＠お腹いっぱい。2009/06/06(土) 11:17:33
Sun Microsystems 末期の珈琲
0959名無しさん＠お腹いっぱい。2009/06/06(土) 11:29:24
Sun Microsystems 死亡遊戯
0960名無しさん＠お腹いっぱい。2009/06/06(土) 11:48:46
最後のTシャツ投げ
0961名無しさん＠お腹いっぱい。2009/06/06(土) 11:51:17
SunとQualcomm、Snapdragon向けJava SE 6を発表
http://www.itmedia.co.jp/promobile/articles/0906/05/news043.html
両社は1年以上かけ、完全に最適化したJava SEをSnapdragonに移植した。
Java仮想マシン（JVM）は従来のARMベースのチップセットに移植された
Java SEのものよりも32倍以上高速になったという。
0962名無しさん＠お腹いっぱい。2009/06/06(土) 11:54:10
>>956
ていうか、1ソケットonlyという縛りは、スケールしないから2ソケット以上は必要ないという、割り切りにも見えた。
T2+で4ソケットまで拡張されたけど、LDom使わずにシングルOSイメージで256スレッドは厳しいだろう。
0963名無しさん＠お腹いっぱい。2009/06/06(土) 12:00:35
T1は買収で手に入れた物だということを忘れちゃいけないぞ
ベンチャーなら割り切れるところはすっぱり割り切って迅速に提供しないとな
0964名無しさん＠お腹いっぱい。2009/06/06(土) 13:13:24
え? T1ってSun開発じゃないの?
0965名無しさん＠お腹いっぱい。2009/06/06(土) 13:17:06
開発が進んでるのを会社ごと買ってきたんじゃなかった？
0966名無しさん＠お腹いっぱい。2009/06/06(土) 14:07:10
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20090602_212130.html

マルチプロセッサ構成では、キャッシュ間のコヒーレンシのために、
他のCPUのキャッシュをチェックするProbeを行なう。
HT Assistでは、CPUがシステム上のキャッシュのディレクトリを持ち、
それによって不要なProbeトラフィックを削減する。

　このアプローチ自体は、既存の技術で、AMDはこれまでも実装をアナウンスして来た。
今回は、キャッシュディレクトリがL3を1MB消費して実装されることが明らかになった。
また、HT AssistによってProbeトラフィックを軽減した結果、
プロセッサ間のメモリ転送の帯域が最大60%アップすることも明らかにされた
0967名無しさん＠お腹いっぱい。2009/06/06(土) 14:12:08
Fujitsu工作員宣伝必死だな(笑)
0968名無しさん＠お腹いっぱい。2009/06/06(土) 14:22:46
>>965
いいなぁ資本力のあるところは。
リスキーな開発はベンチャーにやらせて、
それが必要になったら買収ってのはよぉ。

ぶっちゃけ、Niagaraで4096スレッドとかやっても、スケールしねーだろ。
64スレッド程度が分相応だ。
0969名無しさん＠お腹いっぱい。2009/06/06(土) 14:23:34
SPARC信者ってよくもまあなんのデータも提示できないくせに
脳内理論でガセネタ放出の現実逃避ばかりで恥ずかしくもなく書き込みできるよな。
スループットコンピューティングの現実。
http://www.anandtech.com/printarticle.aspx?i=2772
Sun's T2000 server and it's 32 thread T1 CPU turned out very variable results. I
t is not the best choice for open source databases. PostGreSQL and MySQL scale
better on Solaris than they do on Linux, but both RDBMS have trouble scaling over
multiple cores. It is likely that the DB2 and Sybase results will be much better on
the T2000. The SAMP web performance of the T2000 was good when we cached
the PHP pages and we had few accesses to the MySQL database. When PHP
pages had to regenerated with every access and the query cache of MySQL
was used, performance was pretty bad compared to the x86 competition.
The best purpose for the T2000 is a JSP server with SSL authentication.
0970名無しさん＠お腹いっぱい。2009/06/06(土) 14:24:17
Sun Microsystems 富士通の工作員
0971名無しさん＠お腹いっぱい。2009/06/06(土) 14:25:50
少数構成でもHPCのような多数構成でも信者の馬鹿にする安物x86に完全に水を空けられている。
こんなのもう何年も前から常識。Sunが何故x86ベンダーなのか頭を一度リセットしてもう一度
見直して欲しいモノだ。
0972名無しさん＠お腹いっぱい。2009/06/06(土) 14:31:15
とっくにSunはx86に軸足を移してるよね。
Sunのx86サーバは、それなりに美味しい部分がある。
一方SPARCは、レガシー案件用。

>>969
T1の性能が低いのは有名。
せめてT2とOracleで。
0973名無しさん＠お腹いっぱい。2009/06/06(土) 14:34:37
>>972
悪いけど、Woodcrestも旧式だし、当時30万で一式買えた代物だぜ。
当時の比較としては別に悪くない。
できればT2以降も見てみたいがね。
0974名無しさん＠お腹いっぱい。2009/06/06(土) 14:44:23
Date: Jun 7, 2006
0975名無しさん＠お腹いっぱい。2009/06/06(土) 14:48:40
ありがとうマクニーリ
レス数が950を超えています。1000を超えると書き込みができなくなります。