Sun Microsystems 最期の神託

**名無しさん＠お腹いっぱい。** · 2009/05/11(月) 19:40:54

コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」

【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 14:27:04

お、例の人きたねえ
団子ちゃんは相手してくれるかな？

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 14:48:29

コネクションマシンはどこへ逝った。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 15:46:46

>>678
並列化には、アムダールの法則という壁があるんですよ。

ちなみにSPARCがリニアにスケールするのは、限られた状況だけよ。
大きなメモリバンド幅を必要とするアプリを走らせるとサチって話にならない製品もあったぞ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:13:14

この文脈で「アムダールの法則」は外しまくりだって、さっさと気づけよ...

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:17:37

Xeon最強！
SPARCイラネ！

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:38:38

>>682
SPARCとて例外ではありませんぞ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:40:09

>>683,674
ほらみろ、火花とケムリが吹き出しまくってるぞww もうすぐ爆発するなw

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:49:31

草を生やしてる人は、団子さんの意図がわかってないんじゃないか?

エンプラ向けのサーバに使われるようなCPUでは、SPARCは適切ではなくなってる、ってことよ。
まぁ、ロード命令にポストインクリメントが付いていて、それが即値どころかレジスタだっていうのは、やりすぎだと思うが。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 17:31:36

>>686
そりゃ違うだろ。>671 の

> もちろんRISCの設計思想に反してます。

は原理主義的な RISC思想は現在のトレンドに沿ってない、って言ってるだけで、
そもそも商用 RISCは最初の登場時点で RISC原理主義などではないし
（そんな商品はこの世に一度も存在してない）、より「RISC化」することに
よって性能を向上してきたのかというと全くその逆で「RISCらしく」ない
ことを次々と取込んで改良を重ねてきている。
もちろん、RISCであることの利点を損ねない方法によってだけどね。

「RISC原理主義」なんてのは CISCと言われてくやしくてしょうがない連中が
商用 RISCをなんとか攻撃したくて作り上げたタワゴトに過ぎんよ。
そんなのを標榜してる会社も人もどこにも存在しない。

で、今の改良を重ねた商用 RISCが、「RISC原理主義」からみたら RISCらしく
ないからと言って、じゃあ RISC以前の CISCと変わらないかと言ったら、
そんなワケがないんだが、そこはアイマイにしといてって低レベルな批判は
うんざりなんだよ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 17:47:51

俺らはCISCと言って馬鹿にするけど
俺らを攻撃するのは反則だし許せない
ってことですねｗ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 18:04:21

>>681,684
こんなバカネタが真剣に論じられるほど、x86の世界は腐りきってるわけだな..
なるほどな..

「アムダールの法則を巡る Intelと AMDの戦い」
ttp://pc.watch.impress.co.jp/docs/2005/0112/kaigai147.htm

こんなもん、わかり切ったことじゃないか.. そんなリクツが単純適用できるんなら
64CPU機なんか一台も売れるわけがないだろ。アホくさ。

おい、Intelがなんて主張してるか、よく読んどけよ!?
オマエの話と正反対だぞ!!wwww

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 18:41:31

今更SPARCなの？(笑)

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:02:31

つまんない
おもしろいネタないの～？

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:11:29

じゃあ、SPARCのブランチ命令のディレイスロットについて語ろうぜ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:15:58

>>689
どうでもいいけどコンマ区切りの引用は対応していない2chリーダーもあるので
>>681
>>684
としてほしいです

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 22:22:34

今どき RISC vs CIS Cかよw
思い出を語るスレだから、いいのか・・

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:09:37

通夜だからね

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:30:29

じゃあ、emacs vs viとかもあり？w

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:49:18

変態emacsなどの出る幕ではない。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:59:11

>>696
そんなもんEmacs18やVim3の頃が、良かったって話にしかならねぇよ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:11:47

>>696
viの圧勝で結論出てるじゃん。emacs使ってる奴なんて馬鹿ばっかだろ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:43:35

利用シェルならさらに対立が見られそうな気がする

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:46:50

>>698
そこでなぜvimが出てくる

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:47:42

>>687
RISCってのは、
・コンパイラを前提にする
・定量的なアプローチ
この2つが命。

かつて昔の最適点で設計されたSPARCは、
バイナリ互換を保ちつつ発展したがゆえに、
いまでは最適点から、だいぶ遠ざかっている。

そんなSPARCを担ぎ上げるからには、
バイナリ互換のために醜悪なまま進んだ
x86を馬鹿にできる立場にはないんだ。
同じ土俵に、自分で下りていったのだから。

x86に追い付かれ、シェアを下から食われるのは、
当然の結果なわけで、自業自得なんですよ。

じゃぁSPARCは、どうすればよかったか。
バイナリ互換を犠牲にしてでも最適点を
追い続けるべきだった。

そうすれば、圧倒的な性能差を維持できた。

よくIntelは製造によるゴリ押しで性能を絞り出しているという批判を目にするけど、
巨大なキャッシュを積むなどの強引なことをやってきたのは、RISC勢だって同じことだ。
とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

ワークステーションとWebサーバの分野でシェアをx86にまるごと持ってかれた
その原因が傲慢にあることを、とっとと反省して、方針を切り換えるべきだね。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:54:16

>>689
お前さ、
Intelの10年後くらいの先の希望的な話
を持ち出してばかりだけどさ、
俺達、
現実の話してるんだよ。

Sunのスケールしないサーバな。
どうやって使うか知ってるか?
パーティション区切って使うんだよ。

実質的に
少ないCPU数のSMP機が複数台ある
っていう使い方をすれば、性能はでる。

もちろん、スケールしないってことには、
変りが無いが。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:57:51

>>692
遅延スロットは素晴らしいアイデアで、実際に役に立ってるじゃないか。

ただ、分岐命令だけってのが手ぬるいな。
剰余算命令にも遅延スロットがあるべき。

遅延スロットをどんどん適用していけば、
Out-of-order実行なんて必要ないぜ。
In-Orderでもキッチリ性能でるぜ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 08:42:38

終わっちゃったことなのにむなしくないですか？

60 · 2009/05/31(日) 09:34:08

>>702
> とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

強引とかバカか？
そのための命令セットアーキテクチャなんだから当たり前じゃないか。
そのためにわざわざ整理したんだよ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 12:56:44

>>702
バイナリ互換無視したら、コード資産が無駄になる。
x86と最も差があった時点で5倍ぐらい。
486以降Risc手法を取り込んできたx86に対しバイナリ互換無視でも
どこまで性能差を付けれたかのかな?

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:27:40

>>706が何を言いたいのか、わからん。
だれかエスパーで解説してくれ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:28:44

>>707
コード資産?
x86信者みたいなこと言うなよ。

unixなんだから移植性あるコーディングして当然。
DOSでしか動かないとかWindowsでしか動かないとか
そういうコードしか書けない馬鹿と一緒にすんな。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:30:52

>>707
スケーラビリティのあるアーキテクチャなら、
使えるトランジスタが増えた分を、キャッシュではなく、マルチコアに振り向けられるだろ。

x86がヒーヒー言いながらIPCを上げようと効率の悪いことやってたんだから、
シンプルなコアなら4コアくらい余裕で実装できただろう。
それだけで性能4倍だぞ。

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 13:52:07

>>709
そうだな、そういう出来るプログラマのおかげでローエンドはSPARCからIntel CPUへの移行が
すんなりうまくいったわけだ。

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 13:58:04

つまりSPARCもまたバイナリ互換が捨てられない出来損ないプログラマの為に存在するんだなｗｗｗｗ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 15:13:08

手元にコードがあるものばかりじゃないでしょ

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 19:01:50

もちろん皮肉

手元にコードがあって再コンパイルすれば動くってのはSolarisじゃなくてDebianだろう

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 20:21:40

禿げ、デブ、共産主義の三重苦

もちろん皮肉

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 20:22:35

共産主義よかバイナリ非互換の方が良かったか？ｗ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:13:05

>>709
SPARCが生き残ってる最大の理由はコード資産。
過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
一定の手間で動くということが重要。

移植性があるコーディングとか、そういうのはどうでもいい

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:35:58

>>717
>過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
>一定の手間で動くということが重要。

そういう必要性も年々減って、いずれ無くなってしまうでしょうね。

SPARCが将来的に生き残るには、コストパフォーマンスでぶっちぎる
ような真剣勝負で戦い抜かないと。富士通は勝っていけるかな。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:52:21

Nehalem EXが出ればSPARC終了だよ
後はメインフレームみたいにニッチ市場で細々売ってくだけ
それもいつまで続くことやら

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 23:17:28

>>718
世の中フリーソフトだけで成り立ってると思ってるの？

**,,・´∀｀・,,）っ-○○○** · 2009/06/01(月) 00:38:18

ディレイスロットってそれ自体がパイプライン段数縛りになるだろ。
クロックを上げるためにステージ細分化するとかのアプローチも採れないし

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 01:39:11

Nehalem EXのページの動画デモを見てる時にサーバ側からの送信が止まったのが受けた
Sunのページの製品CM見てる時は止まったことないのに

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 01:47:21

>>719

そうねえ　北朝鮮がつぶれるぐらいまで続くんじゃない？

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:07:36

>>717
そうだよな。

x86の汚い囲い込みと同じ戦術でSPARCは生き残ってる。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:09:52

>>720
QuickTransitのように、
SPARCバイナリをx86上で動作させる
ってなシロモノが商品化されてるんですよ。

ていうか、OracleはQuickTransit作ってる会社を買収して、Solarisに標準装備させるべき。
x86版SolarisでもSPARCバイナリが走り、SPARC版Solarisでもx86バイナリが走れば、
むしろ逆にSPARCの拡販になりますぜ。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:12:16

>>721
そうでもないよ。
ISAとパイプラインは一対一対応している必要はない。

OOO実行するのであれば、
ィレイスロットにある命令は、直前の分岐命令の結果に依存していないって意味でしかない。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 08:22:57

>>725
当然知ってるがAlpha版NTはトランスレータ入れても成功しなかったわけで
むしろx64製品へ移行を促す方向に圧力がかかりそうだ

あと、トランスレータはアプリケーションを動かすだけであって
ホストがサポートできないハードウェアなどはどうしようもない

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 08:36:10

>>725
Transitive社はIBMに買収されQuickTransit製品を終了しました

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 09:22:14

>>727
それは昔の話でさ、最近だと、MacOSが、PPCからx86への移行に成功してるよね。
Alphaの場合、x86との性能差が縮まったのが、失敗の最大の原因だと思う。
その点、SPARCは違う。

x86で64CPUはスケールしないが、SPARCなら64CPUでもスケールするから、
そこには比較できないほどの大きな性能差があるわけで。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 09:39:02

ttp://www.networld.co.jp/transitive/news_over.htm
これか。

品質チェックによる一時休止が本当なのか、
その会社がSPARCの次にPOWERを相手にする可能性を恐れて潰したのか・・・.

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 10:15:34

きっとSunを買収してSolarisに載せるつもりだった

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 12:51:15

>>729
Macはトランスレータだけで何とかしたと思ってるのか？
オーバヘッドを吸収するPowerPCと最新Coreアーキテクチャの性能差と
Universal Binary化の強要を忘れるな

それに高速な64コアを必要とするアプリケーションがどれだけある？
あっても最初からSPARCや他の大規模サーバを選択しているだろう
そこにx64からの移行というマーケットを想定する意味はあるのか？

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 13:20:01

MacOS Xは PowerPCから Intelへの移行どころか、10.4→10.5なんてレベルで
動かんもん続出だし、開発環境に至っては（タダになったのはいいことだが）
OS最新版じゃないと話にもならん。
トランスレーターは話題にはなったけど、使ってるやつなんてほとんど皆無だろw

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 13:32:57

>>730
まさに人類の敵
いい仕事してますね～♪

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:18:50

CPU単体での性能なら現行x86が上だが、64CPU以上の構成だと現行Sparcが上に
なるっていう解釈でいいのかな?
でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージ
があるんだが。
趣味でSparcワークステーションあるがサーバなんて使ったことないからそこら辺
わからない。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:26:18

>>735
＞でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージがあるんだが。

その認識は・・・・

ちょっと、お前64人65脚やってきてみろ

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:49:25

信者乙

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 16:44:40

x86は 8ソケットで既にまともに動かんよ。
QPIなら 8コア以上でも性能出る、って話らしいが、実際リニアに性能あがってる
記事どっかにあるか?
SPECrate は要らんからな。あれだけが高い石はエンプラ方面じゃ全く使えんから。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 16:58:13

SPARCにはそれしか残ってないもんな
逆に1ソケや2ソケのお手頃価格でそこそこの性能ならSPARCマシンに新規需要はない

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 16:58:52

SparcのOracleベンチはまだですか？

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 17:55:10

>>739
だから、WSをx86に奪われた。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 18:21:37

サーバもな

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 19:02:25

というか、WSってもう必要ないじゃん
UNIXアプリのWindowsへの移植が終わったんだから
そこら辺のショップブランドのパチョコンで十分

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 19:07:04

>>738
Opteronは性能上がるみたいだけど
ttp://connexitor.com/blog/pivot/entry.php?id=191

**,,・´∀｀・,,）っ-○○○** · 2009/06/01(月) 20:22:21

ZFSでファイルサーバ作るためだけにSolarisってよくあるよなー

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 21:02:57

1万いくらの安鯖にHDD突っ込んでファイル鯖みたいな用途に使うと怖いくらいに似合う。
UPSなしでの突然の電源断でも割と平気だし。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 21:03:06

>>743
今のWS=ハイエンドx86のPCにOpenGLの高額VGA搭載したもの。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:02:20

普通にゲーム用グラボで間に合うことも多い罠

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:07:07

IDC、2009年第1四半期国内サーバー市場動向を発表
http://www.idcjapan.co.jp/Press/Current/20090601Apr.html

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:46:45

>>738
Nehalem-EXがまだ出てないからな。
Intelは今まで中堅以上のサーバはx86では力をいれてなかったんだが、
Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。
まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い
とは言い切れないことは既に明らか。

**,,・´∀｀・,,）っ-○○○** · 2009/06/02(火) 00:47:42

Nehalem-EXなら128コア組めるんじゃなかったっけ

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:48:51

64CPU以上の企業サーバは市場が小さくて、
そもそも主力だと考えているメーカーはない。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:53:03

サーバはCPU数が多い上位製品ほど、
システムにしめるCPUの部品コストの比重は小さくなる。
64Pや128Pなんて年に何台もでないジャンルなのにCPUメーカーとしては
儲けにならん。
故に、IntelのようなCPU専業のようなメーカーが少ないCPUで高付加価値を
出す方に力を入れてきたのは無理もない。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 00:55:34

SunのサーバのCPU数が多い製品が多いのは、
Solarisのおかげだ。ハードの問題じゃあない。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:07:59

>>751
64コアじゃね？
SMTで128スレッド

**OOO-⊂(´∀｀旦⊂☆諫碕** · 2009/06/02(火) 01:14:02

http://hothardware.com/News/Intel-Unveils-NehalemEX-OctalCore-Server-CPU/
>Scalability beyond eight sockets, up to 32-socket implementations can be achieved.
QuickPathは最大32Sだぽ。
まあ、つってもNehalem-EXの実質的なターゲットは殆ど8S以下だと思うが。

**OOO-⊂(´∀｀旦⊂☆諫碕** · 2009/06/02(火) 01:17:24

QuickPathでも純正は8Sまで、8S超はOEM。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:22:51

グルーレスなのは8Sまでだよ
それ以上はOEMの設計したスイッチが要る

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:29:58

SSE速いのが嬉しければIntel買うけど、それ以外ではよー使いませんｗ

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:30:05

8ソケット超はノードコントローラーがいるから
実質8ソケット以下って言っていいでしょ

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:33:01

>>758
すまん、被った

**OOO-⊂(´∀｀旦⊂☆諫碕** · 2009/06/02(火) 01:37:03

ほほ、スマン。
Nehalem-EXが32Sまで対応してるってだけで、QPIでは8Sまでだね。

**OOO-⊂(´∀｀旦⊂☆諫碕** · 2009/06/02(火) 01:56:41

>>743
PCアーキテクチャ使い回しのWorkstaion
汎用スカラプロセッサ使い回しのSupercomputer
既に中身の終わったものが言葉だけ残ったんだよ

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:58:03

757 名前：不明なデバイスさん [sage] 投稿日： 2009/06/02(火) 01:34:54 ID:W/lj3Mzf
どなたか、ここのGraphic Media Acceratorダウンロードできた方いらっしゃいますか？
http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=2930&OSFullName=Windows+Vista+32&lang=jpn&strOSs=164&submit=Go%21

Video: Intel？ Graphics Media Accelerator Driver for Windows* Vista (22118KB)
15.13.3.1787 2009/05/28

The file that you are trying to download has either been moved, renamed or archived.
Please go to http://downloadcenter.intel.com and choose your product to find your download.

と、ファイルがなくなっている様なのですが･･･

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 01:59:20

758 名前：不明なデバイスさん [sage] 投稿日： 2009/06/02(火) 01:38:18 ID:VI3z+Aag
英語ページから行っても同じだな
ぬぁーにがNehalem-EXだぁ？ｗ

テメーのところの鯖をまともに管理できるようになってから寝言言いやがれｗｗｗ

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 02:34:16

頭が悪い人による言いがかりの典型例だな

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 02:40:19

先日MSDNのサーバーが落ちたわけだが

ぬぁーにがWindows Server 2008 R2だぁ？ｗ

テメーのところの鯖をまともに管理できるようになってから寝言言いやがれｗｗｗ

とは思わなかったなつまり
マイクロソフトとインテルのクライアント信頼度は違いすぎた

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 02:55:22

Win鯖は落ちるのがデフォなので別格だな
MSの鯖を管理してるのはHPだろ？
しかしWin鯖はプリンタ鯖止まりのOS
ぬゎーにがなんてMSに対して怒るとIT技術に対して無知なのかと思われる

新米 · 2009/06/02(火) 03:01:38

ファイルがない場合のエラー処理も完ぺき
流石Intel

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 03:18:39

Intel+MSで鯖とか信頼とかムリッす
こっちからそんなの言いだせません

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 03:18:58

また老害たちが集まってきた

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 03:24:04

若いコはいい罠
上が許可したとか言い出すんでしょ？

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 03:35:21

古いままの知識や見当違いのことを力説する年寄りって・・・

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 03:39:07

新しいと思ってるみたいだけど掴まされてるだけの若い子を見ると…

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 05:21:08

>>732
データベース。

最初はx86サーバでスタートして、
スケールアップが必要になったらIA64サーバがありますよ
って。

まぁ実際には、サーバの強化が必要になるペースよりも、
x86の性能向上・スケーラビリティ向上のペースのほうが速くて、
x86のままリプレースで桶

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 05:26:40

>>735
x86とSPARCで、CPUソケット1つあたりの性能が違うので、
x86の64CPU構成と、SPARCの64CPU構成を比較すること自体に意味があるかどうか・・・。

>>738
へー、Sunは「まともに動かない」ものを製品化して売ってるんだ。ひどいね。

> 実際リニアに性能あがってる記事

へー、SPARCはリニアに性能が上がるんだ。

あんたSPECしか知らんのな。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 05:47:14

>>754
ちゃうちゃう。

UltraSPARCの性能向上が鈍ったので、代替手段としてCPUをたくさん積むしかなかったのさ。
それもSPARC64で解決したので、過去の話。

>>755
Nehalem-EXは8コアだよ。SMTで16スレッド。

>>768
Linuxや*BSDなんかよりは、Windows鯖は、よっぽどスケールするんですがね。

**名無しさん＠お腹いっぱい。** · 2009/06/02(火) 05:59:55

日本のエンタープライズってさ、
既存のものを上手に組み合わせて自分たちで賢く運用するのではなく、
やたら特注で作らせる。

だから、あんまりWindows鯖の評価が高くない。
ちゃんと使いこなせる技術者がほとんどいない。
なんでも特注で作らせるのは、たぶん、勉強するのが嫌なんだろうな。

そんな日本でも、
ttp://www.kabu.com/feature/system/
こういう会社もあるんだわ。

当初は勘定系のデータベースもWindowsでSQL Serverだったんだが、
ある時期からOracleに変更になったらしい。

社外に作らせるために仕様書を書いたり、検収したりするくらいなら、
自分たちで、VisualBasicで書いちゃったほうが早いよっていう。

ここでVisualBasicを笑った人は、不勉強が過ぎるので反省するように。