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

Sun Microsystems 最期の神託

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2009/05/11(月) 19:40:54
コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」


【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/
0697名無しさん＠お腹いっぱい。2009/05/30(土) 23:49:18
変態emacsなどの出る幕ではない。
0698名無しさん＠お腹いっぱい。2009/05/30(土) 23:59:11
>>696
そんなもんEmacs18やVim3の頃が、良かったって話にしかならねぇよ
0699名無しさん＠お腹いっぱい。2009/05/31(日) 01:11:47
>>696
viの圧勝で結論出てるじゃん。emacs使ってる奴なんて馬鹿ばっかだろ。
0700名無しさん＠お腹いっぱい。2009/05/31(日) 01:43:35
利用シェルならさらに対立が見られそうな気がする
0701名無しさん＠お腹いっぱい。2009/05/31(日) 01:46:50
>>698
そこでなぜvimが出てくる
0702名無しさん＠お腹いっぱい。2009/05/31(日) 07:47:42
>>687
RISCってのは、
・コンパイラを前提にする
・定量的なアプローチ
この2つが命。

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

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

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

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

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

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

ワークステーションとWebサーバの分野でシェアをx86にまるごと持ってかれた
その原因が傲慢にあることを、とっとと反省して、方針を切り換えるべきだね。
0703名無しさん＠お腹いっぱい。2009/05/31(日) 07:54:16
>>689
お前さ、
Intelの10年後くらいの先の希望的な話
を持ち出してばかりだけどさ、
俺達、
現実の話してるんだよ。

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

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

もちろん、スケールしないってことには、
変りが無いが。
0704名無しさん＠お腹いっぱい。2009/05/31(日) 07:57:51
>>692
遅延スロットは素晴らしいアイデアで、実際に役に立ってるじゃないか。

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

遅延スロットをどんどん適用していけば、
Out-of-order実行なんて必要ないぜ。
In-Orderでもキッチリ性能でるぜ。
0705名無しさん＠お腹いっぱい。2009/05/31(日) 08:42:38
終わっちゃったことなのにむなしくないですか？
0706602009/05/31(日) 09:34:08
>>702
> とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

強引とかバカか？
そのための命令セットアーキテクチャなんだから当たり前じゃないか。
そのためにわざわざ整理したんだよ。
0707名無しさん＠お腹いっぱい。2009/05/31(日) 12:56:44
>>702
バイナリ互換無視したら、コード資産が無駄になる。
x86と最も差があった時点で5倍ぐらい。
486以降Risc手法を取り込んできたx86に対しバイナリ互換無視でも
どこまで性能差を付けれたかのかな?
0708名無しさん＠お腹いっぱい。2009/05/31(日) 13:27:40
>>706が何を言いたいのか、わからん。
だれかエスパーで解説してくれ。
0709名無しさん＠お腹いっぱい。2009/05/31(日) 13:28:44
>>707
コード資産?
x86信者みたいなこと言うなよ。

unixなんだから移植性あるコーディングして当然。
DOSでしか動かないとかWindowsでしか動かないとか
そういうコードしか書けない馬鹿と一緒にすんな。
0710名無しさん＠お腹いっぱい。2009/05/31(日) 13:30:52
>>707
スケーラビリティのあるアーキテクチャなら、
使えるトランジスタが増えた分を、キャッシュではなく、マルチコアに振り向けられるだろ。

x86がヒーヒー言いながらIPCを上げようと効率の悪いことやってたんだから、
シンプルなコアなら4コアくらい余裕で実装できただろう。
それだけで性能4倍だぞ。
0711,,・´∀｀・,,）っ-○○○2009/05/31(日) 13:52:07
>>709
そうだな、そういう出来るプログラマのおかげでローエンドはSPARCからIntel CPUへの移行が
すんなりうまくいったわけだ。
0712,,・´∀｀・,,）っ-○○○2009/05/31(日) 13:58:04
つまりSPARCもまたバイナリ互換が捨てられない出来損ないプログラマの為に存在するんだなｗｗｗｗ
0713名無しさん＠お腹いっぱい。2009/05/31(日) 15:13:08
手元にコードがあるものばかりじゃないでしょ
0714,,・´∀｀・,,）っ-○○○2009/05/31(日) 19:01:50
もちろん皮肉

手元にコードがあって再コンパイルすれば動くってのはSolarisじゃなくてDebianだろう
0715名無しさん＠お腹いっぱい。2009/05/31(日) 20:21:40
禿げ、デブ、共産主義の三重苦

もちろん皮肉
0716名無しさん＠お腹いっぱい。2009/05/31(日) 20:22:35
共産主義よかバイナリ非互換の方が良かったか？ｗ
0717名無しさん＠お腹いっぱい。2009/05/31(日) 22:13:05
>>709
SPARCが生き残ってる最大の理由はコード資産。
過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
一定の手間で動くということが重要。

移植性があるコーディングとか、そういうのはどうでもいい
0718名無しさん＠お腹いっぱい。2009/05/31(日) 22:35:58
>>717
>過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
>一定の手間で動くということが重要。

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

SPARCが将来的に生き残るには、コストパフォーマンスでぶっちぎる
ような真剣勝負で戦い抜かないと。富士通は勝っていけるかな。
0719名無しさん＠お腹いっぱい。2009/05/31(日) 22:52:21
Nehalem EXが出ればSPARC終了だよ
後はメインフレームみたいにニッチ市場で細々売ってくだけ
それもいつまで続くことやら
0720名無しさん＠お腹いっぱい。2009/05/31(日) 23:17:28
>>718
世の中フリーソフトだけで成り立ってると思ってるの？
0721,,・´∀｀・,,）っ-○○○2009/06/01(月) 00:38:18
ディレイスロットってそれ自体がパイプライン段数縛りになるだろ。
クロックを上げるためにステージ細分化するとかのアプローチも採れないし
0722名無しさん＠お腹いっぱい。2009/06/01(月) 01:39:11
Nehalem EXのページの動画デモを見てる時にサーバ側からの送信が止まったのが受けた
Sunのページの製品CM見てる時は止まったことないのに
0723名無しさん＠お腹いっぱい。2009/06/01(月) 01:47:21
>>719

そうねえ　北朝鮮がつぶれるぐらいまで続くんじゃない？
0724名無しさん＠お腹いっぱい。2009/06/01(月) 07:07:36
>>717
そうだよな。

x86の汚い囲い込みと同じ戦術でSPARCは生き残ってる。
0725名無しさん＠お腹いっぱい。2009/06/01(月) 07:09:52
>>720
QuickTransitのように、
SPARCバイナリをx86上で動作させる
ってなシロモノが商品化されてるんですよ。

ていうか、OracleはQuickTransit作ってる会社を買収して、Solarisに標準装備させるべき。
x86版SolarisでもSPARCバイナリが走り、SPARC版Solarisでもx86バイナリが走れば、
むしろ逆にSPARCの拡販になりますぜ。
0726名無しさん＠お腹いっぱい。2009/06/01(月) 07:12:16
>>721
そうでもないよ。
ISAとパイプラインは一対一対応している必要はない。

OOO実行するのであれば、
ィレイスロットにある命令は、直前の分岐命令の結果に依存していないって意味でしかない。
0727名無しさん＠お腹いっぱい。2009/06/01(月) 08:22:57
>>725
当然知ってるがAlpha版NTはトランスレータ入れても成功しなかったわけで
むしろx64製品へ移行を促す方向に圧力がかかりそうだ

あと、トランスレータはアプリケーションを動かすだけであって
ホストがサポートできないハードウェアなどはどうしようもない
0728名無しさん＠お腹いっぱい。2009/06/01(月) 08:36:10
>>725
Transitive社はIBMに買収されQuickTransit製品を終了しました
0729名無しさん＠お腹いっぱい。2009/06/01(月) 09:22:14
>>727
それは昔の話でさ、最近だと、MacOSが、PPCからx86への移行に成功してるよね。
Alphaの場合、x86との性能差が縮まったのが、失敗の最大の原因だと思う。
その点、SPARCは違う。

x86で64CPUはスケールしないが、SPARCなら64CPUでもスケールするから、
そこには比較できないほどの大きな性能差があるわけで。
0730名無しさん＠お腹いっぱい。2009/06/01(月) 09:39:02
ttp://www.networld.co.jp/transitive/news_over.htm
これか。

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


0731名無しさん＠お腹いっぱい。2009/06/01(月) 10:15:34
きっとSunを買収してSolarisに載せるつもりだった
0732名無しさん＠お腹いっぱい。2009/06/01(月) 12:51:15
>>729
Macはトランスレータだけで何とかしたと思ってるのか？
オーバヘッドを吸収するPowerPCと最新Coreアーキテクチャの性能差と
Universal Binary化の強要を忘れるな

それに高速な64コアを必要とするアプリケーションがどれだけある？
あっても最初からSPARCや他の大規模サーバを選択しているだろう
そこにx64からの移行というマーケットを想定する意味はあるのか？
0733名無しさん＠お腹いっぱい。2009/06/01(月) 13:20:01
MacOS Xは PowerPCから Intelへの移行どころか、10.4→10.5なんてレベルで
動かんもん続出だし、開発環境に至っては（タダになったのはいいことだが）
OS最新版じゃないと話にもならん。
トランスレーターは話題にはなったけど、使ってるやつなんてほとんど皆無だろw
0734名無しさん＠お腹いっぱい。2009/06/01(月) 13:32:57
>>730
まさに人類の敵
いい仕事してますね〜♪
0735名無しさん＠お腹いっぱい。2009/06/01(月) 15:18:50
CPU単体での性能なら現行x86が上だが、64CPU以上の構成だと現行Sparcが上に
なるっていう解釈でいいのかな?
でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージ
があるんだが。
趣味でSparcワークステーションあるがサーバなんて使ったことないからそこら辺
わからない。
0736名無しさん＠お腹いっぱい。2009/06/01(月) 15:26:18
>>735
＞でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージがあるんだが。

その認識は・・・・

ちょっと、お前64人65脚やってきてみろ
0737名無しさん＠お腹いっぱい。2009/06/01(月) 15:49:25
信者乙
0738名無しさん＠お腹いっぱい。2009/06/01(月) 16:44:40
x86は 8ソケットで既にまともに動かんよ。
QPIなら 8コア以上でも性能出る、って話らしいが、実際リニアに性能あがってる
記事どっかにあるか?
SPECrate は要らんからな。あれだけが高い石はエンプラ方面じゃ全く使えんから。
0739名無しさん＠お腹いっぱい。2009/06/01(月) 16:58:13
SPARCにはそれしか残ってないもんな
逆に1ソケや2ソケのお手頃価格でそこそこの性能ならSPARCマシンに新規需要はない
0740名無しさん＠お腹いっぱい。2009/06/01(月) 16:58:52
SparcのOracleベンチはまだですか？
0741名無しさん＠お腹いっぱい。2009/06/01(月) 17:55:10
>>739
だから、WSをx86に奪われた。
0742名無しさん＠お腹いっぱい。2009/06/01(月) 18:21:37
サーバもな
0743名無しさん＠お腹いっぱい。2009/06/01(月) 19:02:25
というか、WSってもう必要ないじゃん
UNIXアプリのWindowsへの移植が終わったんだから
そこら辺のショップブランドのパチョコンで十分
0744名無しさん＠お腹いっぱい。2009/06/01(月) 19:07:04
>>738
Opteronは性能上がるみたいだけど
ttp://connexitor.com/blog/pivot/entry.php?id=191
0745,,・´∀｀・,,）っ-○○○2009/06/01(月) 20:22:21
ZFSでファイルサーバ作るためだけにSolarisってよくあるよなー
0746名無しさん＠お腹いっぱい。2009/06/01(月) 21:02:57
1万いくらの安鯖にHDD突っ込んでファイル鯖みたいな用途に使うと怖いくらいに似合う。
UPSなしでの突然の電源断でも割と平気だし。
0747名無しさん＠お腹いっぱい。2009/06/01(月) 21:03:06
>>743
今のWS=ハイエンドx86のPCにOpenGLの高額VGA搭載したもの。
0748名無しさん＠お腹いっぱい。2009/06/02(火) 00:02:20
普通にゲーム用グラボで間に合うことも多い罠
0749名無しさん＠お腹いっぱい。2009/06/02(火) 00:07:07
IDC、2009年第1四半期国内サーバー市場動向を発表
http://www.idcjapan.co.jp/Press/Current/20090601Apr.html
0750名無しさん＠お腹いっぱい。2009/06/02(火) 00:46:45
>>738
Nehalem-EXがまだ出てないからな。
Intelは今まで中堅以上のサーバはx86では力をいれてなかったんだが、
Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。
まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い
とは言い切れないことは既に明らか。
0751,,・´∀｀・,,）っ-○○○2009/06/02(火) 00:47:42
Nehalem-EXなら128コア組めるんじゃなかったっけ
0752名無しさん＠お腹いっぱい。2009/06/02(火) 00:48:51
64CPU以上の企業サーバは市場が小さくて、
そもそも主力だと考えているメーカーはない。
0753名無しさん＠お腹いっぱい。2009/06/02(火) 00:53:03
サーバはCPU数が多い上位製品ほど、
システムにしめるCPUの部品コストの比重は小さくなる。
64Pや128Pなんて年に何台もでないジャンルなのにCPUメーカーとしては
儲けにならん。
故に、IntelのようなCPU専業のようなメーカーが少ないCPUで高付加価値を
出す方に力を入れてきたのは無理もない。
0754名無しさん＠お腹いっぱい。2009/06/02(火) 00:55:34
SunのサーバのCPU数が多い製品が多いのは、
Solarisのおかげだ。ハードの問題じゃあない。
0755名無しさん＠お腹いっぱい。2009/06/02(火) 01:07:59
>>751
64コアじゃね？
SMTで128スレッド
0756OOO-⊂(´∀｀旦⊂☆諫碕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以下だと思うが。
0757OOO-⊂(´∀｀旦⊂☆諫碕2009/06/02(火) 01:17:24
QuickPathでも純正は8Sまで、8S超はOEM。
0758名無しさん＠お腹いっぱい。2009/06/02(火) 01:22:51
グルーレスなのは8Sまでだよ
それ以上はOEMの設計したスイッチが要る
0759名無しさん＠お腹いっぱい。2009/06/02(火) 01:29:58
SSE速いのが嬉しければIntel買うけど、それ以外ではよー使いませんｗ
0760名無しさん＠お腹いっぱい。2009/06/02(火) 01:30:05
8ソケット超はノードコントローラーがいるから
実質8ソケット以下って言っていいでしょ
0761名無しさん＠お腹いっぱい。2009/06/02(火) 01:33:01
>>758
すまん、被った
0762OOO-⊂(´∀｀旦⊂☆諫碕2009/06/02(火) 01:37:03
ほほ、スマン。
Nehalem-EXが32Sまで対応してるってだけで、QPIでは8Sまでだね。
0763OOO-⊂(´∀｀旦⊂☆諫碕2009/06/02(火) 01:56:41
>>743
PCアーキテクチャ使い回しのWorkstaion
汎用スカラプロセッサ使い回しのSupercomputer
既に中身の終わったものが言葉だけ残ったんだよ
0764名無しさん＠お腹いっぱい。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.

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

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

テメーのところの鯖をまともに管理できるようになってから寝言言いやがれｗｗｗ
0766名無しさん＠お腹いっぱい。2009/06/02(火) 02:34:16
頭が悪い人による言いがかりの典型例だな
0767名無しさん＠お腹いっぱい。2009/06/02(火) 02:40:19
先日MSDNのサーバーが落ちたわけだが


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

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


とは思わなかったなつまり
マイクロソフトとインテルのクライアント信頼度は違いすぎた
0768名無しさん＠お腹いっぱい。2009/06/02(火) 02:55:22
Win鯖は落ちるのがデフォなので別格だな
MSの鯖を管理してるのはHPだろ？
しかしWin鯖はプリンタ鯖止まりのOS
ぬゎーにがなんてMSに対して怒るとIT技術に対して無知なのかと思われる
0769新米2009/06/02(火) 03:01:38
ファイルがない場合のエラー処理も完ぺき
流石Intel
0770名無しさん＠お腹いっぱい。2009/06/02(火) 03:18:39
Intel+MSで鯖とか信頼とかムリッす
こっちからそんなの言いだせません
0771名無しさん＠お腹いっぱい。2009/06/02(火) 03:18:58
また老害たちが集まってきた
0772名無しさん＠お腹いっぱい。2009/06/02(火) 03:24:04
若いコはいい罠
上が許可したとか言い出すんでしょ？
0773名無しさん＠お腹いっぱい。2009/06/02(火) 03:35:21
古いままの知識や見当違いのことを力説する年寄りって・・・
0774名無しさん＠お腹いっぱい。2009/06/02(火) 03:39:07
新しいと思ってるみたいだけど掴まされてるだけの若い子を見ると…
0775名無しさん＠お腹いっぱい。2009/06/02(火) 05:21:08
>>732
データベース。

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

まぁ実際には、サーバの強化が必要になるペースよりも、
x86の性能向上・スケーラビリティ向上のペースのほうが速くて、
x86のままリプレースで桶
0776名無しさん＠お腹いっぱい。2009/06/02(火) 05:26:40
>>735
x86とSPARCで、CPUソケット1つあたりの性能が違うので、
x86の64CPU構成と、SPARCの64CPU構成を比較すること自体に意味があるかどうか・・・。

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

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

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

あんたSPECしか知らんのな。
0777名無しさん＠お腹いっぱい。2009/06/02(火) 05:47:14
>>754
ちゃうちゃう。

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

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

>>768
Linuxや*BSDなんかよりは、Windows鯖は、よっぽどスケールするんですがね。
0778名無しさん＠お腹いっぱい。2009/06/02(火) 05:59:55
日本のエンタープライズってさ、
既存のものを上手に組み合わせて自分たちで賢く運用するのではなく、
やたら特注で作らせる。

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

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

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

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

ここでVisualBasicを笑った人は、不勉強が過ぎるので反省するように。
0779名無しさん＠お腹いっぱい。2009/06/02(火) 06:16:37
うざ
0780名無しさん＠お腹いっぱい。2009/06/02(火) 08:00:30
ヴァカめ！！

挨拶が遅れたな。私がエクスカリバーーである！何？「ヴァカめ！！」では無くて「バカめ！！」では無いのか？だと？

ヴァカめ！！

私の伝説は12世紀から始まった。私の伝説を聞きたいか？武勇伝が聞きたいのか？君達はどこから来た？

ヴァカめ！！

誰がコックと言った。
私の職人になるにあたり、守ってもらいたい1000の項目がある。レポート用紙にまとめておいた。しっかりと目を通しておくように。特に452番目の私の5時間に及ぶ朗読会にはぜひ参加願いたい。
私の伝説は12世紀から始まったのだ。私の朝は一杯のコーヒーから始まる。私の午後はアフタヌーンティーにて始まる。そして夜は、パジャマになるに決まっておろう。何故か判るか？

ヴァカめ！！

これだから田舎者は困るのだ。守って貰いたい1000の項目その1「私の朝は一杯のコーヒーから始まる」忘れるで無いぞ。私の伝説は12世紀から始まったのだ。・・・・・ ・・・ ・・ ・

ヴァカめ！！

思考の時間は必要なのだよ。何をするにも、ものを考えずに飛び出すなど愚の骨頂。そう、あれは私が若かった頃の頃だ。一人のスナイパーがいた。詳しくは以下の作品に描かれているので、全て読んでもらいたい。
0781名無しさん＠お腹いっぱい。2009/06/02(火) 09:37:26
>>776
あのなー... x86+MS-Winや x86+Linuxが頭打ちで SPARC+Solarisがリニアに
スケールする、なんて記事は何年も前から数え切れないくらい出てるよ。
馬脚をあらわしたなwww

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

どの SPECだよ。SPARCがトップだった SPECか? オレは覚えがないよ。
馬脚 2本めwwwww
0782名無しさん＠お腹いっぱい。2009/06/02(火) 09:40:32
>>778
Basic.. もう死んでたのに、むりやりライブラリーゴテゴテにくっつけて、
Bolandから引き抜いた Pascalの天才張り付けて蘇生させたゾンビのことか?
めちゃ迷惑だよあんな汚ねー言語。
0783名無しさん＠お腹いっぱい。2009/06/02(火) 09:47:17
>>750
> Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。

あははははは。そうだな、面食らってみたいわ、期待してるぜ。
ところで、今 MAXで積めるコア数のマシンのスケーラビリティは記事になって
ないのかよ? 教えてくれよ。性能出てねーんじゃねーのw?

まあ、力入れてなかったのを入れたらすぐ性能出ると思ってるとこが
おいたわしいわ。SunOS 4当時に SMP方面力入れるって方針出してから、
実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。
特定の用途には割と早い段階で性能出せてるけど。

> まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い

まだ HPCとか言ってんのかよ.. 支離滅裂なんだよ。反論の体裁になってりゃ
なんでもいいのかよ?wwwwww
0784名無しさん＠お腹いっぱい。2009/06/02(火) 09:51:21
やあ、朝から元気がいいね。
0785名無しさん＠お腹いっぱい。2009/06/02(火) 10:30:13
起きるのおせ−よ
0786名無しさん＠お腹いっぱい。2009/06/02(火) 10:39:09
>>781
> あのなー... x86+MS-Winや x86+Linuxが頭打ちで SPARC+Solarisがリニアに
> スケールする、なんて記事は何年も前から数え切れないくらい出てるよ。

そりゃSunの広告記事だからじゃねーの?

違うというのなら、とりあえず1つ例を。
もちろん、Sunや、Sunを担いでいる企業が広告を一切出していない媒体のもので。

そして、x86+Solarisと比較しないあたりが、なんだかなぁ。

> どの SPECだよ。SPARCがトップだった SPECか? オレは覚えがないよ。

SPEC以外のベンチマークの話さ。
なにかとSPECの話ばかりするじゃないか、お前は。
0787名無しさん＠お腹いっぱい。2009/06/02(火) 10:41:00
>>782
俺はVBが大嫌いだし、VB使いも大嫌いだ。
大勢いるVB使いが「勉強したくない!」ってゴネたおかげで、VB.NETで一掃されるはずのものが、一掃されなかったことは、いまでも恨んでる。

だが、だからといってVBが実際に多く使われているという現実から、目を背けることはできない。
0788名無しさん＠お腹いっぱい。2009/06/02(火) 10:52:29
>>783
> SunOS 4当時に SMP方面力入れるって方針出してから、
> 実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。
> 特定の用途には割と早い段階で性能出せてるけど。

SunのSMP機で性能が満遍なく出るようになったのって、かなり後になってからだよ。
とにかくシステム全体の実効帯域幅がネックでな。評価してた連中が、顔真っ青だったな。
もっとも、評価せずに導入決めちゃったところよりは、遥かにマシだが。
0789名無しさん＠お腹いっぱい。2009/06/02(火) 12:32:36
で、今は十分に最大構成までスケールする立派な機械ちうわけだｗ
0790名無しさん＠お腹いっぱい。2009/06/02(火) 12:35:51
需要がないけどな。
0791名無しさん＠お腹いっぱい。2009/06/02(火) 12:59:52
Windows Home Server で十分だよｗ
0792名無しさん＠お腹いっぱい。2009/06/02(火) 13:13:40
Home Serverかｗ
お前んとこって凄い会社だなｗｗｗ
0793名無しさん＠お腹いっぱい。2009/06/02(火) 13:17:26
請負の常駐先の話と比較されても・・・
0794名無しさん＠お腹いっぱい。2009/06/02(火) 13:20:20
>>778
なんでWindowsでSQL Server使ってVBじゃないの？
そこでリプレース先のOSを語らずOracle+VBと出てくることに恣意的なものを感じる
0795名無しさん＠お腹いっぱい。2009/06/02(火) 13:23:18
>>788
ところが、用途限れば Solaris2.1(SunOS 5.1)あたりから性能出してた。
SunOS 4.1のジャイアントロックがボトルネックになってたところには、
1990年代入ってすぐくらいから性能を出してた。NTTの研究所とかな。

Solaris2.4までは、通常の開発環境としてはめちゃ苦痛なプラットフォームだった
けどね。
0796名無しさん＠お腹いっぱい。2009/06/02(火) 13:28:24
またNTT研の中の人ですか。営業と仲の悪い。
■ このスレッドは過去ログ倉庫に格納されています