Sun Microsystems 最大の重複
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/03/09(木) 02:57:15巻き起こる「真の新スレ」待望論。結局は更なる重複を生むことに
他ならないという危険な気配を感じつつ、今、ここに新スレ登場！
【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0228名無しさん＠お腹いっぱい。
2006/03/25(土) 02:06:56別にスレッド苦手なスクリプト言語に焦点して作ってあるわけじゃないし。
そんな戦略ないだろ普通。より完成されたもんに焦点合わせて、完成されてないソフトは
完成に近づくようにうながす。
わざと歪んだものを作って囲い込む企業もあるけど、Sun はそういうことはやらないし。
0229名無しさん＠お腹いっぱい。
2006/03/25(土) 02:11:400230名無しさん＠お腹いっぱい。
2006/03/25(土) 05:17:39所詮、plain な web サーバ用途なのかな。
0231名無しさん＠お腹いっぱい。
2006/03/25(土) 11:16:56>
> 昨年末から出てるDual-Core Xeonだったら負けてると思お。
>
> ttp://www.intel.com/performance/server/xeon/platform.htm
これって、1 x Xeon 3.6GHzとDual-Core Xeonの比較でしょ？
2 x Xeon 3.6GHzとDual-Core Xeonとを比較するとどうなるの？
しかし、1GHz(でFPx1)>で Xeon 3.6GHz２つに勝てるというのは、
もう完全にXeonっていうのは終わっているのね。。
SPARCより遅いIntelも、終わっている。。?
時代はAMD64で一色なのでしょうか？
0232名無しさん＠お腹いっぱい。
2006/03/25(土) 11:38:170233名無しさん＠お腹いっぱい。
2006/03/25(土) 11:56:41IPMIという標準規格(HP, DELL, NEC, INTELのRAS仕様羅列だけど)がある。
遠隔操作、障害管理なんかができる。
>>128がもいってるけど、ちと補足。
IPMI Ver2.0だとIPMI Over LANが強化されててSerial port shareingと
Serial Over LANでリモートからBIOS画面までいじれる。
いまミドルレンジ以上のPCサーバにこれをサポートするBMCが標準的に
付き始めたところ。
専用の管理マネージャソフトから使わせるメーカが多いけど
freeでこんなのもある。
ttp://ipmitool.sourceforge.net/
ktermから使ってみたらANSIのcolor ESCシーケンスでBIOS画面の
色までそれなりに再現できてた。っていうかこのあたりはBIOS側の
つくりこみだけど。
専用のBMCチップ(ARM, H8Sとか)を作ってるメーカ数社、
IPMI Core firm作ってるメーカも数社あってそれぞれM/Bメーカに
売りこんでるので安い。
サーバメーカの細かい保守、運用ノウハウがちとダウングレード
しつつもお安くPCサーバに入ってきている今日この頃。
0234名無しさん＠お腹いっぱい。
2006/03/25(土) 12:06:37GalaxyにはILOMってのがあるよ。
BIOS設定もできる。
0235名無しさん＠お腹いっぱい。
2006/03/25(土) 12:29:49あのー、、、ILOM以外にって話してるんだが。。。。
0236名無しさん＠お腹いっぱい。
2006/03/25(土) 13:32:50> 2 x Xeon 3.6GHzとDual-Core Xeonとを比較するとどうなるの？
もれも知りたいが、たぶんT1は負けると思うよ。
クロックも2.8MHzより高いのが出てきたら完敗だよね。
> しかし、1GHz(でFPx1)>で Xeon 3.6GHz２つに勝てるというのは、
> もう完全にXeonっていうのは終わっているのね。。
完全64bitの8コアが、64bitメモリ拡張のsingle-coreに僅差で勝って嬉しいかい?
如何に貧粗なコアを積んでるのか証明してる様なものだよ。
0237名無しさん＠お腹いっぱい。
2006/03/25(土) 14:17:25なんでそんなに必死なの？
0238名無しさん＠お腹いっぱい。
2006/03/25(土) 14:38:37どっちかだと思うな。
カワイソウニ。
0239名無しさん＠お腹いっぱい。
2006/03/25(土) 14:44:28> クロックも2.8MHzより高いのが出てきたら完敗だよね。
出てきたら、なんて前提ならいろいろ言えるよね。ところで、Pen-M ベースで 64bit に
なったやつって、ほんとに今年中に出る? Niagara2 出ちゃうよ? ヘタすると
Rock より後になっちゃったりして。
> 完全64bitの8コアが、64bitメモリ拡張のsingle-coreに僅差で勝って嬉しいかい?
> 如何に貧粗なコアを積んでるのか証明してる様なものだよ。
それより、Niagara のスレッドが埋まりきらないあたりはシングルコアの方が
ぶっちぎりで速いはずなのに、そんなに差がないよね。そっちの方が興味あるなぁ。
Sun の人のブログだとスレッド数少ないと UltraSPARC3 の圧勝だったよ、たしか。
0240名無しさん＠お腹いっぱい。
2006/03/25(土) 15:17:47Anandtechのベンチは毎秒何個の要求を投入したとき、毎秒何個処理できるかだから、
負荷が低い（cpuに余裕がある）ときには、毎秒の要求数と処理数は同じになる。
前半は、どんなcpuを使っていても要求数＝処理数となる同じ線をたどる。
0241名無しさん＠お腹いっぱい。
2006/03/25(土) 15:23:210242名無しさん＠お腹いっぱい。
2006/03/25(土) 15:23:37現実というものを見てクダサーイ
0243名無しさん＠お腹いっぱい。
2006/03/25(土) 15:32:17圧倒的な性能差を実現してるだけでもNiagaraのコンセプトは正しいと思う
ただ、Dual Core Opteronの2プロセッサのシステムに負けてるのが問題
Niagaraも2プロセッサ構成の製品があればいいのにね
Niagaraは2プロセッサに対応してないのか2プロセッサの製品がないだけなのかは知らないけど
あと、Specjbb2005の結果に関してはNiagaraはDual Core Opteronの2プロセッサに
圧倒的な性能差を実現してるけどね
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2657&p=4
0244名無しさん＠お腹いっぱい。
2006/03/25(土) 15:43:37マルチプロセッサ構成にするくらいなら、1つの筐体に2台分を押し込むほうがマシ。
0245名無しさん＠お腹いっぱい。
2006/03/25(土) 16:01:07良くないと価格性能比が厳しくない？
0246名無しさん＠お腹いっぱい。
2006/03/25(土) 16:12:30Specjbb2005って圧倒的というほどでも。
単にコアの数の違いだけだし。
0247名無しさん＠お腹いっぱい。
2006/03/25(土) 16:37:05SUNのような下から突き上げられてるメーカーの悩ましいところだな
0248名無しさん＠お腹いっぱい。
2006/03/25(土) 16:51:30つまり、あれだ、「くやしかったら 8 コアやってみな、おしりぺーんぺん」っていう意味だろ。
0249名無しさん＠お腹いっぱい。
2006/03/25(土) 16:55:132 ソケットは Niagara2 で対応だったと思うよ。チップ間接続が、メモリだけ相手にしてれば
いい場合と比べるとコストかかるからね。
UltraSPARC IV+ 機とは、IO まわりやその他が全然違うから、たいていのケースでは
競合にならないと思うけど、まああんまりなことにもできないのも事実かな。
0250名無しさん＠お腹いっぱい。
2006/03/25(土) 16:58:53そりゃそうだろ
Dual Core Opteronの性能がSUNのSPARCサーバーとっては脅威的な性能だからな
Hewlett-Packard Company ProLiant DL385 (AMD Opteron (TM) 285) 4 cores, 2 chips, 2 cores/chip 79.1
Sun Microsystems Sun Fire V490 (4 processor) 8 cores, 4 chips, 2 cores/chip 87.4
0251名無しさん＠お腹いっぱい。
2006/03/25(土) 17:02:220252名無しさん＠お腹いっぱい。
2006/03/25(土) 17:22:50dualcore Opteronの結果はJVMが1つでの結果。複数JVMを並列動作したほうが
単一JVMを全部のコアで動かすよりも競合が少なくなり、性能が上がる。実際は、
キャッシュの競合とかがあるから、トレードオフ要素だとは思うけど。
Niagaraは8コアでJVMを4つ並列で動かしているから、dualcore Opteron4コアだと
JVMを2つ並列に動かしてやるだけでも、差は縮まると思う。各チップにJVMを張り
付けて、ローカリティを高めてやる感じ。
0253名無しさん＠お腹いっぱい。
2006/03/25(土) 17:46:53Dual-Core Opteronがよさげならばそっち、Niagaraがよければそっちと、
いずれもSunから買えるわけで。
Niagaraも今後はさらに拡張されていくから、Opteronと切磋琢磨していけば
いいよね。Rockもあることだし。
2 x Xeon 3.6GHzに 1 x Niagara 1GHzが勝っていることからも、Sun SPARCが
遅いなんてもう言えないよね。FJ SPARCは当然として。
Solarisも自社OSである以上、今後も改良が加えられていくだろうし、
何も今だけを見る必要はないよ。
以前と比較すれば、相当な進歩があるっていうことは、復活してきているという
ことだし、今後の発展が期待できるということだものね。
SolarisもSPARCも今後があるっていうことだよ。
0254名無しさん＠お腹いっぱい。
2006/03/25(土) 18:22:50あ、またいらんこと言ったかw。
0255名無しさん＠お腹いっぱい。
2006/03/25(土) 18:35:491 x Dual-Core Opteronには 1 x T1は勝っていることだし、上々の出来だよ。
0256名無しさん＠お腹いっぱい。
2006/03/25(土) 18:46:140257名無しさん＠お腹いっぱい。
2006/03/25(土) 19:37:28niagara 8way
opteron 2way
0258名無しさん＠お腹いっぱい。
2006/03/25(土) 20:10:11XeonはダメダメなCPUぽいけど。
そうなると、従来の手法とは違ったアプローチのNiagaraはひとまず成功と
言えそうだね。Niagara2などの後継CPUを用意しようとしている理由が分かるよ。
ほんの数年前まで周波数を上げることにやっきになっていたことを考えると、
ほんとうにエポックメーキングだね。
あっという間にIntelやXeonが過去の遺物、化石と化したね。
0259名無しさん＠お腹いっぱい。
2006/03/25(土) 21:12:33ttp://pc.watch.impress.co.jp/docs/2006/0224/kaigai244.htm
AMDは「顧客は、長期的にシングルスレッドパフォーマンスの向上にも価値を見いだし続けるだろう」
ttp://pc.watch.impress.co.jp/docs/2006/0202/kaigai238.htm
0260名無しさん＠お腹いっぱい。
2006/03/25(土) 22:00:48ネイティブスレッド化はやってる。
0261名無しさん＠お腹いっぱい。
2006/03/25(土) 22:22:18なら、NiagaraとDual core OpteronのデュアルCPU機を作れば周辺機器の消費電力も減らせて最強！
論理分割(?)でSPARC/SolarisとAMD64/SolarisまたはAMD64/Linuxを同時に実行可能！
これ！
0262名無しさん＠お腹いっぱい。
2006/03/25(土) 23:57:530263名無しさん＠お腹いっぱい。
2006/03/26(日) 00:13:49でx64/SolarisとSPARC/Solarisは統合の方向で。
0264名無しさん＠お腹いっぱい。
2006/03/26(日) 00:26:20まさかRockがUltraSPARC IVを2個並べただけなんて事はないよな?
0265名無しさん＠お腹いっぱい。
2006/03/26(日) 00:51:33Rock に関しては The Register の記事が安藤さんとこにある。
0266名無しさん＠お腹いっぱい。
2006/03/26(日) 01:14:470267名無しさん＠お腹いっぱい。
2006/03/26(日) 01:22:22どこ？おせーて。
0268名無しさん＠お腹いっぱい。
2006/03/26(日) 01:32:150269名無しさん＠お腹いっぱい。
2006/03/26(日) 01:35:414 スレッド 8 コア 128 チップで、OS からは計 4096 コの CPU が見える。
まあ、そういう用途もないことはないが、現状の Niagara の守備範囲ではなかろう。
具体的に、そういう環境で走らせたいアプリ想定してる?
0270名無しさん＠お腹いっぱい。
2006/03/26(日) 01:38:24> 活かせるソフトウェア技術とチップ間接続技術がないからだよ。
そんな技術よりSpMTを確立してから貧粗なコアを数並べた方が良くないか?
0271名無しさん＠お腹いっぱい。
2006/03/26(日) 01:47:10Sun は今 Niagara でいいんじゃんか。
ま、「これからは SMP だ」といって BSD ベースから Solaris 2 へ移り、
Sun4/600 や MBus へ行ったのが今ローエンドでも図に当たってるとも言える。
0272名無しさん＠お腹いっぱい。
2006/03/26(日) 01:49:28良かったのは、E10Kだけ
CRAYの技術だけど、あれは大成功だった
0273名無しさん＠お腹いっぱい。
2006/03/26(日) 01:59:340274名無しさん＠お腹いっぱい。
2006/03/26(日) 09:13:39CrayやFujitsuの方が、というよりFujitsuの方が長くやっているところだし。
問題はNUMAだな。昔からあるくせに、エポックメーキングな技術が開発されていない。
0275名無しさん＠お腹いっぱい。
2006/03/26(日) 14:40:20さすがに sun4d はもうサポートしてないだろｗ
0276名無しさん＠お腹いっぱい。
2006/03/26(日) 18:50:38パーティション沢山切ってみてはどうか。
0277名無しさん＠お腹いっぱい。
2006/03/26(日) 21:39:390278名無しさん＠お腹いっぱい。
2006/03/26(日) 21:42:480279名無しさん＠お腹いっぱい。
2006/03/26(日) 22:07:44新アーキってなーに？
ここ十年ぐらい新アーキなんてないじゃん？
Itaniumなんて40年ぐらいまえからあるVLIWを使っているわけだし。
0280名無しさん＠お腹いっぱい。
2006/03/26(日) 22:22:27細かいやつだな。
今年出る新マイクロアーキのことだろ。
0281名無しさん＠お腹いっぱい。
2006/03/26(日) 22:27:44だから、今年出る新マイクロアーキって、どういうのなの？
今年でるのって、数年以上前から開発されているので、もうアーキの技術情報は
でてるでしょ？
そんなに「新しい」やつなんて最近あったけ？
0282名無しさん＠お腹いっぱい。
2006/03/26(日) 22:28:06出た時には AMD に溝開けられてないといいがな。
0283名無しさん＠お腹いっぱい。
2006/03/26(日) 22:30:270284名無しさん＠お腹いっぱい。
2006/03/26(日) 23:03:550285名無しさん＠お腹いっぱい。
2006/03/27(月) 00:29:460286名無しさん＠お腹いっぱい。
2006/03/27(月) 00:30:23IntelのCore Microarchitecture
http://pcweb.mycom.co.jp/articles/2006/03/21/intelcore/
0287名無しさん＠お腹いっぱい。
2006/03/27(月) 00:54:13今年の後半にコンロー(Conroe)が出るじゃん
しかし、コードネームとはいえ日本語で見るとIntelのネーミングセンスはすごいや
Intelは逝ってるとかコンロとか
0288名無しさん＠お腹いっぱい。
2006/03/27(月) 00:56:01おまえ、、、、残念なヤツだな。
0289名無しさん＠お腹いっぱい。
2006/03/27(月) 02:06:33急遽有効にした。が、64bit 動作は性能悪いんだろ?
PenM は 64bit はとりあえず置いといて省電力を追求してたけど、Pen4 も Itanium も
将来性なしってわかってデスクトップもサーバーも全部受け持つことになった。急にだ。
あらかじめ 64bit 仕込んであったわけでもない。そんなもん急に 64bit だのなんだの
ロードマップ出してきたって、オレはマユツバだと思ってるけど。
今あるもんの焼き直しのチップがいくつか出たら、あとダンマリになっちゃうんじゃないかね。
そんな最近根底から設計し直したチップがそんなにすぐできるわけないと思うね。
ただ、イスラエルでやってるってのは、ちょっと気にはなるけど。
イスラム教徒は Intel 買わなくなりそう。
0290名無しさん＠お腹いっぱい。
2006/03/27(月) 03:20:44もともと仕込んだ64ビット命令セットを封印し、AMD64命令セットをデコードできるようにした。
どのみち命令はデコーダでμOPsに変換するので、デコーダとマイクロコードの変更で対応できたが・・・
Itaniumもx86命令をデコーダで変換して実行するけどパフォーマンス出ないのと同様、最適じゃないため遅い。
0291名無しさん＠お腹いっぱい。
2006/03/27(月) 08:21:48そんな話は噂レベルですらない
"独自版 Yamhill" は "検討" はされただろうが
製品レベルに封印つきで実装されたという話はない
結局 amd64 互換のものが採用されただけ
0292名無しさん＠お腹いっぱい。
2006/03/28(火) 00:57:36>64bit 動作は性能悪いんだろ?
性能が悪いといっても、32bitより遅いわけではない。64bitをターゲットにして
開発してきたAMDより数歩遅れてるだけだ。最初はメインストリームを
Itaniumの64bitに移行させるつもりだったが、随分前に路線変更して、
最終的には屈辱の「AMD互換仕様」というわけ
イスラエルチームはすごいみたいだよ。元々CPUのロードマップに穴を
開けないためのモバイル版開発チームだったのに(1チームがItaniumに
行っちゃったからね)、思ったより出来がいいもんだからどんどん出世してる
0293名無しさん＠お腹いっぱい。
2006/03/28(火) 19:26:06今まで散々x86を産み出した親として叩かれまくった。
あんなに醜くて非効率な命令セットを世の中に出した上に、
PC分野におけるシェアと金にものを言わせて力業で性能を上げている、と。
もしPCのCPUがx86でなかったら、もっともっと安価に高性能なPCを消費者が手にできたはずだ、と。
しかしこれからは違う。
AMD64を産み出した親として叩かれるのはAMDだ。
責任はすべてAMDに押しつけることができる。
何か言われたら、IA-64でx86の呪いを断ち切るべく努力したが、AMDが台無しにした、と言えばいいのだから。
0294名無しさん＠お腹いっぱい。
2006/03/28(火) 19:52:26POWERはサーバー以外にゲーム機などに採用されその汎用性を証明してるが
今のItaniumはハイエンドサーバー以外考えられない状態
そんなにすばらしいアーキテクチャならゲーム機や組み込み用に似たような設計のCPUが採用されてもいいはず
0295名無しさん＠お腹いっぱい。
2006/03/28(火) 23:38:06それはつまり
I A - 6 4 は 、 終 わ っ た
といいたいのだな
0296名無しさん＠お腹いっぱい。
2006/03/29(水) 00:54:40猫。
0297名無しさん＠お腹いっぱい。
2006/03/29(水) 02:11:12バイナリ互換が必要ないゲーム機や組み込みで、
バイナリ互換のために産み出されたEPICは、
オーバースペックに決まってるじゃないか。
0298名無しさん＠お腹いっぱい。
2006/03/29(水) 08:17:46うちで作るとこんなに凄いって言うのをやって欲しい。
0299名無しさん＠お腹いっぱい。
2006/03/29(水) 16:46:490300名無しさん＠お腹いっぱい。
2006/03/29(水) 19:27:48http://www.live-eclipse.org/
0301名無しさん＠お腹いっぱい。
2006/03/29(水) 22:43:240302名無しさん＠お腹いっぱい。
2006/03/29(水) 22:45:350303名無しさん＠お腹いっぱい。
2006/03/30(木) 15:48:37X86に比べると、AMD64アーキは遥かに綺麗だと思うのだが。。
0304名無しさん＠お腹いっぱい。
2006/03/30(木) 15:49:53Eclipseの場合は、日食でそ？
暫く経つと、がんがんにお日様が復活しまつ。
0305名無しさん＠お腹いっぱい。
2006/03/30(木) 16:07:31地動説未だに理解できん連中はこの世の終わりだとあわてふためくようだが。
0306名無しさん＠お腹いっぱい。
2006/03/30(木) 16:26:440307名無しさん＠お腹いっぱい。
2006/03/31(金) 11:46:43マシになっただけ。
0308名無しさん＠お腹いっぱい。
2006/03/31(金) 16:14:49ちゃんとCPUのスペックをみたか？
X86とAMD64じゃ、全然違うぞ？
Itaniumより全然綺麗な64bit。
0309名無しさん＠お腹いっぱい。
2006/03/31(金) 16:25:560310名無しさん＠お腹いっぱい。
2006/03/31(金) 16:30:30全然違うアーキだけど。
0311名無しさん＠お腹いっぱい。
2006/03/31(金) 17:07:28AMD64の方がIA64より綺麗だから、x86とAMD64は全然違うって
論理破綻してないか？
だいたい、x86とAMD64の差よりIA64とAMD64の差の方が大きいだろ
0312名無しさん＠お腹いっぱい。
2006/03/31(金) 18:32:42AMD64とX86は違うって。互換モードとAMD64アーキをまぜこぜにしてない？
例えば、AMD64はあの嫌だったX86のセグメントを無くしてフラットだけにしてたりする。
とにかく、AMD64の仕様は痛快。いやだったところをばっさりと遠慮無く削除してくれてる。
でも、必要なところ、性能上いれたいところは、きっちりとおさえてるし。
0313名無しさん＠お腹いっぱい。
2006/03/31(金) 18:38:170314名無しさん＠お腹いっぱい。
2006/03/31(金) 18:44:0232bitの互換を維持しながらも、64bitをサポートしたときに、
こんなにもアーキが違ってくるものなのかって、双方の仕様を比較すると
自然に感じるじゃない？
ソフト屋としては、Itaniumはやりたくない。もうAMD64があるなら。
仕事なら仕方がないけど、Itaniumのアーキは理解するのに時間がかかるし、
本当に複雑で嫌な気がする。まったく気が進まない。
WindowsもSolarisも降りてしまった気持が良く分かる。
0315名無しさん＠お腹いっぱい。
2006/03/31(金) 19:32:350316名無しさん＠お腹いっぱい。
2006/03/31(金) 19:47:00説明するのには>>312だけでよくて、>>314はいらないでしょ？
0317名無しさん＠お腹いっぱい。
2006/03/31(金) 20:28:17ソフト屋でＪａｖａやＣで作ってる連中なら
そんなＣＰＵのアーキの綺麗さは関係ないんじゃないの？
0318名無しさん＠お腹いっぱい。
2006/03/31(金) 20:35:08ドライバみたいにたまにみかけるところもあるし。ユーザ空間でも、システム
ライブラリのようにアセンブラを使わざるを得ないところもあれば、アプリの
ようにCやJavaのような高級言語で済んでしまうところもあるでしょ。
果ては、JavascriptやPHP, perlのようにスクリプト言語のようにコンピュータ言語
そのものも使わないところもあるし。
0319名無しさん＠お腹いっぱい。
2006/03/31(金) 20:40:05盲腸を削っただけだろ。
x86の32ビットのプロテクトモードで、ユーザランドでセグメントを意識することなんて、ないだろ。
>>314
> 32bitの互換を維持しながらも、64bitをサポートしたとき
その時点で間違ってますから。
> ソフト屋としては、Itaniumはやりたくない。もうAMD64があるなら。
これはわかるよ。2つのCPUでテストするのは手間が増えるからね。
> Itaniumのアーキは理解するのに時間がかかるし、本当に複雑で嫌な気がする。まったく気が進まない。
OSの根っこのほうとかコンパイラを作るとか、そういうのでない限り、理解する必要はないだろう。
たとえばApacheを作っている人たちが、それぞれのCPUのアーキテクチャを理解していると思うか?
0320名無しさん＠お腹いっぱい。
2006/03/31(金) 22:03:35確かにItaniumだろうがAMD64だろうが関係ないなあ。
つまり>>319みたいな人には。
0321名無しさん＠お腹いっぱい。
2006/03/31(金) 23:01:07みんなでItaniumをやっつけようよ
0322名無しさん＠お腹いっぱい。
2006/03/31(金) 23:07:430323名無しさん＠お腹いっぱい。
2006/03/32(土) 00:20:07http://www.itmedia.co.jp/enterprise/articles/0603/31/news020.html
0324名無しさん＠お腹いっぱい。
2006/03/32(土) 02:12:17世の中のプログラマの99%は、そうだな。
0325名無しさん＠お腹いっぱい。
2006/03/32(土) 04:29:110326名無しさん＠お腹いっぱい。
2006/03/32(土) 07:54:58ｴｲﾌﾟﾘﾙﾌｰﾙだと思われ
0327名無しさん＠お腹いっぱい。
2006/03/32(土) 09:33:04
■ このスレッドは過去ログ倉庫に格納されています