Sun Microsystems 最期の神託

1 名前：名無しさん＠お腹いっぱい。 [2009/05/11(月) 19:40:54 ] コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、 いよいよ神託(oracle)によって最期を迎える。 「汝自身を知れ」 【前スレ】 Sun Microsystems 最上川上流 pc12.2ch.net/test/read.cgi/unix/1239259163/ 703 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 07:54:16 ] >>689 お前さ、 Intelの10年後くらいの先の希望的な話 を持ち出してばかりだけどさ、 俺達、 現実の話してるんだよ。 Sunのスケールしないサーバな。 どうやって使うか知ってるか? パーティション区切って使うんだよ。 実質的に 少ないCPU数のSMP機が複数台ある っていう使い方をすれば、性能はでる。 もちろん、スケールしないってことには、 変りが無いが。 704 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 07:57:51 ] >>692 遅延スロットは素晴らしいアイデアで、実際に役に立ってるじゃないか。 ただ、分岐命令だけってのが手ぬるいな。 剰余算命令にも遅延スロットがあるべき。 遅延スロットをどんどん適用していけば、 Out-of-order実行なんて必要ないぜ。 In-Orderでもキッチリ性能でるぜ。 705 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 08:42:38 ] 終わっちゃったことなのにむなしくないですか？ 706 名前：60 mailto:sage [2009/05/31(日) 09:34:08 ] >>702 > とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。 強引とかバカか？ そのための命令セットアーキテクチャなんだから当たり前じゃないか。 そのためにわざわざ整理したんだよ。 707 名前：名無しさん＠お腹いっぱい。 [2009/05/31(日) 12:56:44 ] >>702 バイナリ互換無視したら、コード資産が無駄になる。 x86と最も差があった時点で5倍ぐらい。 486以降Risc手法を取り込んできたx86に対しバイナリ互換無視でも どこまで性能差を付けれたかのかな? 708 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 13:27:40 ] >>706が何を言いたいのか、わからん。 だれかエスパーで解説してくれ。 709 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 13:28:44 ] >>707 コード資産? x86信者みたいなこと言うなよ。 unixなんだから移植性あるコーディングして当然。 DOSでしか動かないとかWindowsでしか動かないとか そういうコードしか書けない馬鹿と一緒にすんな。 710 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 13:30:52 ] >>707 スケーラビリティのあるアーキテクチャなら、 使えるトランジスタが増えた分を、キャッシュではなく、マルチコアに振り向けられるだろ。 x86がヒーヒー言いながらIPCを上げようと効率の悪いことやってたんだから、 シンプルなコアなら4コアくらい余裕で実装できただろう。 それだけで性能4倍だぞ。 711 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/05/31(日) 13:52:07 ] >>709 そうだな、そういう出来るプログラマのおかげでローエンドはSPARCからIntel CPUへの移行が すんなりうまくいったわけだ。 712 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/05/31(日) 13:58:04 ] つまりSPARCもまたバイナリ互換が捨てられない出来損ないプログラマの為に存在するんだなｗｗｗｗ 713 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 15:13:08 ] 手元にコードがあるものばかりじゃないでしょ 714 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/05/31(日) 19:01:50 ] もちろん皮肉 手元にコードがあって再コンパイルすれば動くってのはSolarisじゃなくてDebianだろう 715 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 20:21:40 ] 禿げ、デブ、共産主義の三重苦 もちろん皮肉 716 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 20:22:35 ] 共産主義よかバイナリ非互換の方が良かったか？ｗ 717 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 22:13:05 ] >>709 SPARCが生き残ってる最大の理由はコード資産。 過去のプログラムが移植性の有無に関わらず、そのまま、あるいは 一定の手間で動くということが重要。 移植性があるコーディングとか、そういうのはどうでもいい 718 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 22:35:58 ] >>717 >過去のプログラムが移植性の有無に関わらず、そのまま、あるいは >一定の手間で動くということが重要。 そういう必要性も年々減って、いずれ無くなってしまうでしょうね。 SPARCが将来的に生き残るには、コストパフォーマンスでぶっちぎる ような真剣勝負で戦い抜かないと。富士通は勝っていけるかな。 719 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 22:52:21 ] Nehalem EXが出ればSPARC終了だよ 後はメインフレームみたいにニッチ市場で細々売ってくだけ それもいつまで続くことやら 720 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/31(日) 23:17:28 ] >>718 世の中フリーソフトだけで成り立ってると思ってるの？ 721 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/06/01(月) 00:38:18 ] ディレイスロットってそれ自体がパイプライン段数縛りになるだろ。 クロックを上げるためにステージ細分化するとかのアプローチも採れないし 722 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 01:39:11 ] Nehalem EXのページの動画デモを見てる時にサーバ側からの送信が止まったのが受けた Sunのページの製品CM見てる時は止まったことないのに 723 名前：名無しさん＠お腹いっぱい。 [2009/06/01(月) 01:47:21 ] >>719 そうねえ　北朝鮮がつぶれるぐらいまで続くんじゃない？ 724 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 07:07:36 ] >>717 そうだよな。 x86の汚い囲い込みと同じ戦術でSPARCは生き残ってる。 725 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 07:09:52 ] >>720 QuickTransitのように、 SPARCバイナリをx86上で動作させる ってなシロモノが商品化されてるんですよ。 ていうか、OracleはQuickTransit作ってる会社を買収して、Solarisに標準装備させるべき。 x86版SolarisでもSPARCバイナリが走り、SPARC版Solarisでもx86バイナリが走れば、 むしろ逆にSPARCの拡販になりますぜ。 726 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 07:12:16 ] >>721 そうでもないよ。 ISAとパイプラインは一対一対応している必要はない。 OOO実行するのであれば、 ィレイスロットにある命令は、直前の分岐命令の結果に依存していないって意味でしかない。 727 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 08:22:57 ] >>725 当然知ってるがAlpha版NTはトランスレータ入れても成功しなかったわけで むしろx64製品へ移行を促す方向に圧力がかかりそうだ あと、トランスレータはアプリケーションを動かすだけであって ホストがサポートできないハードウェアなどはどうしようもない 728 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 08:36:10 ] >>725 Transitive社はIBMに買収されQuickTransit製品を終了しました 729 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 09:22:14 ] >>727 それは昔の話でさ、最近だと、MacOSが、PPCからx86への移行に成功してるよね。 Alphaの場合、x86との性能差が縮まったのが、失敗の最大の原因だと思う。 その点、SPARCは違う。 x86で64CPUはスケールしないが、SPARCなら64CPUでもスケールするから、 そこには比較できないほどの大きな性能差があるわけで。 730 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 09:39:02 ] ttp://www.networld.co.jp/transitive/news_over.htm これか。 品質チェックによる一時休止が本当なのか、 その会社がSPARCの次にPOWERを相手にする可能性を恐れて潰したのか・・・. 731 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 10:15:34 ] きっとSunを買収してSolarisに載せるつもりだった 732 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 12:51:15 ] >>729 Macはトランスレータだけで何とかしたと思ってるのか？ オーバヘッドを吸収するPowerPCと最新Coreアーキテクチャの性能差と Universal Binary化の強要を忘れるな それに高速な64コアを必要とするアプリケーションがどれだけある？ あっても最初からSPARCや他の大規模サーバを選択しているだろう そこにx64からの移行というマーケットを想定する意味はあるのか？ 733 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 13:20:01 ] MacOS Xは PowerPCから Intelへの移行どころか、10.4→10.5なんてレベルで 動かんもん続出だし、開発環境に至っては（タダになったのはいいことだが） OS最新版じゃないと話にもならん。 トランスレーターは話題にはなったけど、使ってるやつなんてほとんど皆無だろw 734 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 13:32:57 ] >>730 まさに人類の敵 いい仕事してますね〜♪ 735 名前：名無しさん＠お腹いっぱい。 [2009/06/01(月) 15:18:50 ] CPU単体での性能なら現行x86が上だが、64CPU以上の構成だと現行Sparcが上に なるっていう解釈でいいのかな? でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージ があるんだが。 趣味でSparcワークステーションあるがサーバなんて使ったことないからそこら辺 わからない。 736 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 15:26:18 ] >>735 ＞でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージがあるんだが。 その認識は・・・・ ちょっと、お前64人65脚やってきてみろ 737 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 15:49:25 ] 信者乙 738 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 16:44:40 ] x86は 8ソケットで既にまともに動かんよ。 QPIなら 8コア以上でも性能出る、って話らしいが、実際リニアに性能あがってる 記事どっかにあるか? SPECrate は要らんからな。あれだけが高い石はエンプラ方面じゃ全く使えんから。 739 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 16:58:13 ] SPARCにはそれしか残ってないもんな 逆に1ソケや2ソケのお手頃価格でそこそこの性能ならSPARCマシンに新規需要はない 740 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 16:58:52 ] SparcのOracleベンチはまだですか？ 741 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 17:55:10 ] >>739 だから、WSをx86に奪われた。 742 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 18:21:37 ] サーバもな 743 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 19:02:25 ] というか、WSってもう必要ないじゃん UNIXアプリのWindowsへの移植が終わったんだから そこら辺のショップブランドのパチョコンで十分 744 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 19:07:04 ] >>738 Opteronは性能上がるみたいだけど ttp://connexitor.com/blog/pivot/entry.php?id=191 745 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/06/01(月) 20:22:21 ] ZFSでファイルサーバ作るためだけにSolarisってよくあるよなー 746 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/01(月) 21:02:57 ] 1万いくらの安鯖にHDD突っ込んでファイル鯖みたいな用途に使うと怖いくらいに似合う。 UPSなしでの突然の電源断でも割と平気だし。 747 名前：名無しさん＠お腹いっぱい。 [2009/06/01(月) 21:03:06 ] >>743 今のWS=ハイエンドx86のPCにOpenGLの高額VGA搭載したもの。 748 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:02:20 ] 普通にゲーム用グラボで間に合うことも多い罠 749 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:07:07 ] IDC、2009年第1四半期国内サーバー市場動向を発表 www.idcjapan.co.jp/Press/Current/20090601Apr.html 750 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:46:45 ] >>738 Nehalem-EXがまだ出てないからな。 Intelは今まで中堅以上のサーバはx86では力をいれてなかったんだが、 Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。 まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い とは言い切れないことは既に明らか。 751 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/06/02(火) 00:47:42 ] Nehalem-EXなら128コア組めるんじゃなかったっけ 752 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:48:51 ] 64CPU以上の企業サーバは市場が小さくて、 そもそも主力だと考えているメーカーはない。 753 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:53:03 ] サーバはCPU数が多い上位製品ほど、 システムにしめるCPUの部品コストの比重は小さくなる。 64Pや128Pなんて年に何台もでないジャンルなのにCPUメーカーとしては 儲けにならん。 故に、IntelのようなCPU専業のようなメーカーが少ないCPUで高付加価値を 出す方に力を入れてきたのは無理もない。 754 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 00:55:34 ] SunのサーバのCPU数が多い製品が多いのは、 Solarisのおかげだ。ハードの問題じゃあない。 755 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:07:59 ] >>751 64コアじゃね？ SMTで128スレッド 756 名前：OOO-⊂(´∀｀旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:14:02 ] 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以下だと思うが。 757 名前：OOO-⊂(´∀｀旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:17:24 ] QuickPathでも純正は8Sまで、8S超はOEM。 758 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:22:51 ] グルーレスなのは8Sまでだよ それ以上はOEMの設計したスイッチが要る 759 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:29:58 ] SSE速いのが嬉しければIntel買うけど、それ以外ではよー使いませんｗ 760 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:30:05 ] 8ソケット超はノードコントローラーがいるから 実質8ソケット以下って言っていいでしょ 761 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:33:01 ] >>758 すまん、被った 762 名前：OOO-⊂(´∀｀旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:37:03 ] ほほ、スマン。 Nehalem-EXが32Sまで対応してるってだけで、QPIでは8Sまでだね。 763 名前：OOO-⊂(´∀｀旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:56:41 ] >>743 PCアーキテクチャ使い回しのWorkstaion 汎用スカラプロセッサ使い回しのSupercomputer 既に中身の終わったものが言葉だけ残ったんだよ 764 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:58:03 ] 757 名前： 不明なデバイスさん [sage] 投稿日： 2009/06/02(火) 01:34:54 ID:W/lj3Mzf どなたか、ここのGraphic Media Acceratorダウンロードできた方いらっしゃいますか？ 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 downloadcenter.intel.com and choose your product to find your download. と、ファイルがなくなっている様なのですが･･･ 765 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 01:59:20 ] 758 名前： 不明なデバイスさん [sage] 投稿日： 2009/06/02(火) 01:38:18 ID:VI3z+Aag 英語ページから行っても同じだな ぬぁーにがNehalem-EXだぁ？ｗ テメーのところの鯖をまともに管理できるようになってから寝言言いやがれｗｗｗ 766 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 02:34:16 ] 頭が悪い人による言いがかりの典型例だな 767 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 02:40:19 ] 先日MSDNのサーバーが落ちたわけだが ぬぁーにがWindows Server 2008 R2だぁ？ｗ テメーのところの鯖をまともに管理できるようになってから寝言言いやがれｗｗｗ とは思わなかったなつまり マイクロソフトとインテルのクライアント信頼度は違いすぎた 768 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 02:55:22 ] Win鯖は落ちるのがデフォなので別格だな MSの鯖を管理してるのはHPだろ？ しかしWin鯖はプリンタ鯖止まりのOS ぬゎーにがなんてMSに対して怒るとIT技術に対して無知なのかと思われる 769 名前：新米 mailto:sage [2009/06/02(火) 03:01:38 ] ファイルがない場合のエラー処理も完ぺき 流石Intel 770 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 03:18:39 ] Intel+MSで鯖とか信頼とかムリッす こっちからそんなの言いだせません 771 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 03:18:58 ] また老害たちが集まってきた 772 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 03:24:04 ] 若いコはいい罠 上が許可したとか言い出すんでしょ？ 773 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 03:35:21 ] 古いままの知識や見当違いのことを力説する年寄りって・・・ 774 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 03:39:07 ] 新しいと思ってるみたいだけど掴まされてるだけの若い子を見ると… 775 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 05:21:08 ] >>732 データベース。 最初はx86サーバでスタートして、 スケールアップが必要になったらIA64サーバがありますよ って。 まぁ実際には、サーバの強化が必要になるペースよりも、 x86の性能向上・スケーラビリティ向上のペースのほうが速くて、 x86のままリプレースで桶 776 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 05:26:40 ] >>735 x86とSPARCで、CPUソケット1つあたりの性能が違うので、 x86の64CPU構成と、SPARCの64CPU構成を比較すること自体に意味があるかどうか・・・。 >>738 へー、Sunは「まともに動かない」ものを製品化して売ってるんだ。ひどいね。 > 実際リニアに性能あがってる記事 へー、SPARCはリニアに性能が上がるんだ。 あんたSPECしか知らんのな。 777 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 05:47:14 ] >>754 ちゃうちゃう。 UltraSPARCの性能向上が鈍ったので、代替手段としてCPUをたくさん積むしかなかったのさ。 それもSPARC64で解決したので、過去の話。 >>755 Nehalem-EXは8コアだよ。SMTで16スレッド。 >>768 Linuxや*BSDなんかよりは、Windows鯖は、よっぽどスケールするんですがね。 778 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 05:59:55 ] 日本のエンタープライズってさ、 既存のものを上手に組み合わせて自分たちで賢く運用するのではなく、 やたら特注で作らせる。 だから、あんまりWindows鯖の評価が高くない。 ちゃんと使いこなせる技術者がほとんどいない。 なんでも特注で作らせるのは、たぶん、勉強するのが嫌なんだろうな。 そんな日本でも、 ttp://www.kabu.com/feature/system/ こういう会社もあるんだわ。 当初は勘定系のデータベースもWindowsでSQL Serverだったんだが、 ある時期からOracleに変更になったらしい。 社外に作らせるために仕様書を書いたり、検収したりするくらいなら、 自分たちで、VisualBasicで書いちゃったほうが早いよっていう。 ここでVisualBasicを笑った人は、不勉強が過ぎるので反省するように。 779 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 06:16:37 ] うざ 780 名前：名無しさん＠お腹いっぱい。 [2009/06/02(火) 08:00:30 ] ヴァカめ！！ 挨拶が遅れたな。私がエクスカリバーーである！何？「ヴァカめ！！」では無くて「バカめ！！」では無いのか？だと？ ヴァカめ！！ 私の伝説は12世紀から始まった。私の伝説を聞きたいか？武勇伝が聞きたいのか？君達はどこから来た？ ヴァカめ！！ 誰がコックと言った。 私の職人になるにあたり、守ってもらいたい1000の項目がある。レポート用紙にまとめておいた。しっかりと目を通しておくように。特に452番目の私の5時間に及ぶ朗読会にはぜひ参加願いたい。 私の伝説は12世紀から始まったのだ。私の朝は一杯のコーヒーから始まる。私の午後はアフタヌーンティーにて始まる。そして夜は、パジャマになるに決まっておろう。何故か判るか？ ヴァカめ！！ これだから田舎者は困るのだ。守って貰いたい1000の項目その1「私の朝は一杯のコーヒーから始まる」忘れるで無いぞ。私の伝説は12世紀から始まったのだ。・・・・・ ・・・ ・・ ・ ヴァカめ！！ 思考の時間は必要なのだよ。何をするにも、ものを考えずに飛び出すなど愚の骨頂。そう、あれは私が若かった頃の頃だ。一人のスナイパーがいた。詳しくは以下の作品に描かれているので、全て読んでもらいたい。 781 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 09:37:26 ] >>776 あのなー... x86+MS-Winや x86+Linuxが頭打ちで SPARC+Solarisがリニアに スケールする、なんて記事は何年も前から数え切れないくらい出てるよ。 馬脚をあらわしたなwww > あんたSPECしか知らんのな。 どの SPECだよ。SPARCがトップだった SPECか? オレは覚えがないよ。 馬脚 2本めwwwww 782 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 09:40:32 ] >>778 Basic.. もう死んでたのに、むりやりライブラリーゴテゴテにくっつけて、 Bolandから引き抜いた Pascalの天才張り付けて蘇生させたゾンビのことか? めちゃ迷惑だよあんな汚ねー言語。 783 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 09:47:17 ] >>750 > Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。 あははははは。そうだな、面食らってみたいわ、期待してるぜ。 ところで、今 MAXで積めるコア数のマシンのスケーラビリティは記事になって ないのかよ? 教えてくれよ。性能出てねーんじゃねーのw? まあ、力入れてなかったのを入れたらすぐ性能出ると思ってるとこが おいたわしいわ。SunOS 4当時に SMP方面力入れるって方針出してから、 実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。 特定の用途には割と早い段階で性能出せてるけど。 > まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い まだ HPCとか言ってんのかよ.. 支離滅裂なんだよ。反論の体裁になってりゃ なんでもいいのかよ?wwwwww 784 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 09:51:21 ] やあ、朝から元気がいいね。 785 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 10:30:13 ] 起きるのおせ−よ 786 名前：名無しさん＠お腹いっぱい。 mailto:sage [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の話ばかりするじゃないか、お前は。 787 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 10:41:00 ] >>782 俺はVBが大嫌いだし、VB使いも大嫌いだ。 大勢いるVB使いが「勉強したくない!」ってゴネたおかげで、VB.NETで一掃されるはずのものが、一掃されなかったことは、いまでも恨んでる。 だが、だからといってVBが実際に多く使われているという現実から、目を背けることはできない。 788 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 10:52:29 ] >>783 > SunOS 4当時に SMP方面力入れるって方針出してから、 > 実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。 > 特定の用途には割と早い段階で性能出せてるけど。 SunのSMP機で性能が満遍なく出るようになったのって、かなり後になってからだよ。 とにかくシステム全体の実効帯域幅がネックでな。評価してた連中が、顔真っ青だったな。 もっとも、評価せずに導入決めちゃったところよりは、遥かにマシだが。 789 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 12:32:36 ] で、今は十分に最大構成までスケールする立派な機械ちうわけだｗ 790 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 12:35:51 ] 需要がないけどな。 791 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 12:59:52 ] Windows Home Server で十分だよｗ 792 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:13:40 ] Home Serverかｗ お前んとこって凄い会社だなｗｗｗ 793 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:17:26 ] 請負の常駐先の話と比較されても・・・ 794 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:20:20 ] >>778 なんでWindowsでSQL Server使ってVBじゃないの？ そこでリプレース先のOSを語らずOracle+VBと出てくることに恣意的なものを感じる 795 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:23:18 ] >>788 ところが、用途限れば Solaris2.1(SunOS 5.1)あたりから性能出してた。 SunOS 4.1のジャイアントロックがボトルネックになってたところには、 1990年代入ってすぐくらいから性能を出してた。NTTの研究所とかな。 Solaris2.4までは、通常の開発環境としてはめちゃ苦痛なプラットフォームだった けどね。 796 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:28:24 ] またNTT研の中の人ですか。営業と仲の悪い。 797 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:29:22 ] >>786 > もちろん、Sunや、Sunを担いでいる企業が広告を一切出していない媒体のもので。 ぷっ。そんな条件付けるのは、Sun関連ならたくさん見つかるという裏返しだなww で、ぜんぶインチキベンチなんだな? ほほおー..ww Sunじゃなくても、そんな指標自分とこ以外から出してるとこなんか ほとんどないよ。 > なにかとSPECの話ばかりするじゃないか、お前は。 はぁ? HPCがどーのとか言ってるバカと混同してるだろ?www パラノイア症状だなw 798 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:30:40 ] HPCはハードウェア板のスパコンスレが適当だろ 799 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:32:37 ] >>796 研究所の人達と営業はなんの関係もないよ。 ひょっとして事業部と仲が悪いと言ってるのか? それも外しまくりだな。 たしかに仕事のやり方はまるで違うが、そもそも接点がない。仲が悪いも何もない。 つーか、その程度の言葉知らんようでは HP関係者ですらない、マタマタマタ聞きの さらに昔話だろ? もういいよ、とっくに飽きたから。 800 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:33:42 ] おーーい、QPIでリニアにスケール、って記事はまだかーー?w 801 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:34:34 ] >>793 比較されたら困るくらいカスいの使ってんのか？あ？ 802 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:35:18 ] こっちは Intelのでも MSのでも Linux/x86のでもいいぞーー コスい条件は付けんぞー。 さっさと提示しろーwww 803 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:35:35 ] >>800 パチョコン使いをいじめてやるなってｗｗｗ 804 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:43:09 ] ミジンコQPI相手に強がってもしゃーないっすわ Intel強いのEDAぐらいでしょ 805 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:43:50 ] >>744 確かに、4コアで完全に頭打っちゃう Xeon5345よりは数値が上がってるけど、 この湾曲ぶりは「リニア」というにはいまひとつだねぇ。 0.9とか 0.8xな係数でほぼ直線でいくぜ、SPARC+Solarisの場合。 このベンチマークってマシン持ってる人やれないのかな? 806 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 13:45:46 ] >>805 鯖向けに設計したOpteronですらこのレベルなんですわ x86とSPARCをガチで比較するのは勘弁してやってクリｗ 807 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 14:06:33 ] いちいち探すのめんどくさいから、広告でも何でもいいので SPARCがスケールする記事のリンクをテンプレに入れてくれや。 SPECrate以外で。 808 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/06/02(火) 14:51:21 ] Try and buyでもなんでもやればいいだろ 他人に探してもらいたいならもっと丁寧にお願いしろや

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef