Sun Microsystems IPF採用撤回は大失策
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/02/25(土) 19:39:56もしIPF版のSolarisを出していれば、
日本メーカーのIPFマシンがHP-UXやLinuxではなく、
hpのOEMマシン以外はSolaris一色になっていただろうに。
【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0103名無しさん＠お腹いっぱい。
2006/03/11(土) 11:52:01一年で倍の性能になるってすごいことじゃないの？
0104名無しさん＠お腹いっぱい。
2006/03/11(土) 12:17:44新しいの出してないのに一年で倍になったらすごいけど。
0105名無しさん＠お腹いっぱい。
2006/03/11(土) 14:31:10んで後ろの 2 倍ってのが、来年の話だからね。結局最初のデキが悪くて
それの 2 倍で今まあなんとか首の皮一枚つながってます、ってことを言ってるだけに過ぎんなw
0106名無しさん＠お腹いっぱい。
2006/03/11(土) 19:13:03ifconfig -aするとether 0:0:0:0:0:0とかなってるんだけど
これまずい? 通信自体はできる。ドライバはSunのdmfe
0107名無しさん＠お腹いっぱい。
2006/03/11(土) 20:29:010108名無しさん＠お腹いっぱい。
2006/03/11(土) 21:21:53こっちにしたら表示も正常になった。arpどうなってたか忘れた、
0109名無しさん＠お腹いっぱい。
2006/03/12(日) 11:00:06TPC-Cベンチマーク結果みたけど、Montecitoすごいぞ。
Montecito 2CPUがMadison-9M 8CPUに迫ってる。
同クロックのMadison-9MからMontecitoで、約3倍の性能向上してる。
0110sage
2006/03/12(日) 18:39:350:0:0:0:0:0になってた。かぶらなきゃ大丈夫とかそういう事か?
プラネックスのNICもはずれの方だったし何か安定のNICはないのか...
0111名無しさん＠お腹いっぱい。
2006/03/12(日) 18:46:13SPARCの場合はEEPROMに書いてある。
後、めんどくさいんで↓
http://docs.sun.com/app/docs/doc/819-0380/6n2qfj0sn?a=view
0112名無しさん＠お腹いっぱい。
2006/03/12(日) 21:11:41というか、Madisonが遅いだけでは？
0113名無しさん＠お腹いっぱい。
2006/03/12(日) 21:31:33ありがとうございます。
# eeprom local-mac-address?=true
したけど変わらなかったのでhostname.dmfe0に設定する方法で
今度ためしてみます。
0114名無しさん＠お腹いっぱい。
2006/03/13(月) 00:48:13montecitoはDual Core x HTなので、 madison 8 soketにmontecito 2 soketで
同等というのは最低限の話。
最低限のところはなんとかなりましたってことにすぎないな。
来年の4Core化ではこんなにリニアに伸びそうもないし。もうだめだろ。
0115名無しさん＠お腹いっぱい。
2006/03/13(月) 01:18:20でも、約 3 倍ってのは安直すぎw。どっかのハゲが SPECint_rate で 4 倍って言うのと
同じオメデタさ。www
0116名無しさん＠お腹いっぱい。
2006/03/13(月) 01:33:01よく見ると性能比較ではなく、二倍になるはずの実際にはありえない条件の
不親切な説明にすぎないのだが。
montecitoはFSB 667MHz開発を断念した時点で終わってる。
128bit FSBで533MHzなんてIA32の数倍に過ぎない。
0117名無しさん＠お腹いっぱい。
2006/03/13(月) 01:48:06でも、元々 CPU 数にリニアに性能があがる実績もないんだから、4 コア対 4 コアで
新旧対決して、数値が 2 倍、ってのを提示してほしいもんだよな。
旧どうしの 4 コア対 8 コアが 1.3 倍とかだったらギャグだwwww
0118名無しさん＠お腹いっぱい。
2006/03/13(月) 11:11:58同じ8CPUで3倍の性能が出ないとしても、CPU1つあたりの処理能力は3倍になってるわけで。
0119名無しさん＠お腹いっぱい。
2006/03/13(月) 11:16:570120名無しさん＠お腹いっぱい。
2006/03/13(月) 12:01:49いや、だから、それが安直だと言ってるんだが... そんな話なら Ita は他社に負けまくりww
0121名無しさん＠お腹いっぱい。
2006/03/13(月) 12:19:08BEA Tuxedo 8.0
Oracle Database 10G Enterprise Edition
Itanium2 1.5GHz 64CPU 64threads→1,008,144 tpmC
Intel Dual-Core Itanium2 1.6 GHz 2CPU 8threads→200,829 tpmC
なんていうデータもありますが。
CPUのコンテキスト数を8倍にして、スループットが5倍なのだから、スケールしているほうでしょう。
同じItanium2 1.5GHzで、
Microsoft Windows Server 2003 Datacenter Edition 64-bit
Microsoft COM+
Microsoft SQL Server 2000 Enterprise Ed. 64-bit
Itanium2 1.6GHz 64CPU→1,082,203 tpmC
Itanium2 1.6GHz 16CPU→332,265 tpmC
なんていうデータもありますよ。
CPUの数が4倍になって、スループットが3倍なのだから、スケールしているでしょ。
0122名無しさん＠お腹いっぱい。
2006/03/13(月) 12:20:15> 同じItanium2 1.5GHzで、
この行、削除。
0123名無しさん＠お腹いっぱい。
2006/03/13(月) 12:23:16手ごろで簡単なFSBを4CPUで共有するマシンのMadison9Mを
Montecitoに差し替えても、FSBの帯域が足りなくて性能が出ない罠。
0124名無しさん＠お腹いっぱい。
2006/03/13(月) 13:15:24Itaniumより安いんだし、速いんだし。
X86系では、ItaniumはAMDが出てきたのでいらないよ。
0125106
2006/03/13(月) 14:49:45/etc/hostname.dmfe0に"ether MACアドレス"という行を追加
とかやったらMACアドレスを変えることができました
とりあえず違うセグメントなのでeri0と同じにして、今のところ順調
さとうさんの所に使えなかったって書いてあったから意外だ
0126名無しさん＠お腹いっぱい。
2006/03/13(月) 18:11:03> HP UX11.iv2
> Itanium2 1.5GHz 64CPU 64threads→1,008,144 tpmC
> Intel Dual-Core Itanium2 1.6 GHz 2CPU 8threads→200,829 tpmC
だからー、新旧のコア数違うのの比較なんか意味ないって。コア数ベースでいくと
64:4 なんだから。
ところで、そのスレッド数で比較って、なんの指標になんの? 聞いたことないけど。
> Itanium2 1.6GHz 64CPU→1,082,203 tpmC
> Itanium2 1.6GHz 16CPU→332,265 tpmC
こっちは意味ありそう。が、3.257 倍。微妙なとこだね。成績いいとは言えないと思うけど。
0127名無しさん＠お腹いっぱい。
2006/03/13(月) 19:31:24ちまたのitaniumマシンは、みんな1FSBあたり2ソケット
667Mhzバスを、2ソケット4コアで共有するんならまずまずと
いったところでは
0128名無しさん＠お腹いっぱい。
2006/03/13(月) 19:42:20スレッド数の話は>>114に聞いてくれ。
0129名無しさん＠お腹いっぱい。
2006/03/13(月) 22:54:34足回りは日本のメーカー様にお願いします
ということでは？
そうやって、わざとらしく日本のメーカに入り込む余地を与えているのかも。
0130名無しさん＠お腹いっぱい。
2006/03/13(月) 23:13:360131名無しさん＠お腹いっぱい。
2006/03/13(月) 23:22:14まだわかんないのか... ヘッポコ日本企業連合にすがるしかもう道がなくなってしまったんだってば。
x86 を置き換えるはずだったんだぞ。方針変更どころか、チョー不得意分野で
かろうじてキノコってんだよ。
0132名無しさん＠お腹いっぱい。
2006/03/13(月) 23:34:11単に PA-RISC 軍団に Intel がかつがれた、先のメド立たなくなってた PA-RISC 後継の
開発資金をまんまとせしめられた、ってことなのかも知れんな。
0133名無しさん＠お腹いっぱい。
2006/03/13(月) 23:36:260134名無しさん＠お腹いっぱい。
2006/03/13(月) 23:41:08まあ、それは分かるんだが、
日本のメーカーのスケベ心をくすぐるのはうまいと思うんだよなぁ。
0135名無しさん＠お腹いっぱい。
2006/03/13(月) 23:59:16RISC ならどれだろうが、あれだけ金と時間かければずっとマシなもんができると思うが。
違うか?
0136名無しさん＠お腹いっぱい。
2006/03/14(火) 01:16:11従来品(x86,POWER,SPARC)と同程度に競うレベルでしかないよな
特にその予算の半分も要らないから Alpha に行っていれば…
0137名無しさん＠お腹いっぱい。
2006/03/14(火) 01:23:20独自アーキだったから皆RISC CPUから撤退しちゃったわけで
0138名無しさん＠お腹いっぱい。
2006/03/14(火) 01:26:270139名無しさん＠お腹いっぱい。
2006/03/14(火) 01:42:29> ヘッポコ日本企業
しかし日本企業がOEMやライセンスしている所は生き残る可能性高いような…
純潔主義のDECはいっちゃったし
0140名無しさん＠お腹いっぱい。
2006/03/14(火) 01:52:38皆って HP だけだけど。sgi は後継とは違うしなぁ。
0141名無しさん＠お腹いっぱい。
2006/03/14(火) 02:02:40RISC 撤退? 寝ぼけまくりですね。
0142名無しさん＠お腹いっぱい。
2006/03/14(火) 02:14:36どう考えても余分なトランジスタの要る x86 や、いくら工夫しても性能のでない Ita なんかに
ばっかり大量にリソース消費されて、こいつらがまともな RISC の2 つ 3 つへ
あてがわれてたら今システムはずっと高性能だろうし、CPU 単価ももっとずっと低いかもね。
無駄の見本として後世あざ笑われること必定。
0143名無しさん＠お腹いっぱい。
2006/03/14(火) 07:47:05出せてたら、POWER5+ 2.2GHz なんかあっさり抜いてただろうに。Intelダメすぎ。
IBM p5 570 1.9GHz 4core, 203.439.87tpmC, AIX 5L 5.3, Oracle 10g
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=105101702
0144名無しさん＠お腹いっぱい。
2006/03/14(火) 08:01:04長年続く企業システムのトップ企業にかなうわけない
同じ価格なら顧客はIBMを選択するだろうし価格を下げれば利益が少なくなるのは当然
PCサーバーなど低価格のシステムならIntelでも信用されるだろうがItaniumの目指してる
ハイエンドサーバーは億を超える価格だからな
0145名無しさん＠お腹いっぱい。
2006/03/14(火) 08:44:02そりはもまいの考えであって、Intelとしては基本設計が古いRISCじゃ性能の向上に
限界があるので、EPICに切替えた訳だろ。
x86についてはNetBurstの後継としてIntel Coreが発表されてる。
>>144
POWERの頑張り次第だね。
0146名無しさん＠お腹いっぱい。
2006/03/14(火) 09:46:25そういうこと言う人がよくいるけど
結局 EPIC のどの辺が "基本設計が新しい" の?
VLIW を現代マーケティング用語で言い換えただけじゃん?
0147名無しさん＠お腹いっぱい。
2006/03/14(火) 10:02:51> Itaniumの創始者であるヒューレット・パッカード社は
> 2004年9月にアーキテクチャを強調するのをやめた。
0148名無しさん＠お腹いっぱい。
2006/03/14(火) 10:02:53技術的なことよりも営業的な合理性を追求した結果が現状だとおもうけど。
0149名無しさん＠お腹いっぱい。
2006/03/14(火) 11:24:06業界こぞって ILP より TLP と叫んでる現状は無視ですか?
0150名無しさん＠お腹いっぱい。
2006/03/14(火) 12:29:04RISC が古い、って証明しそこなったのが Itanium。かっこ悪すぎ。
0151名無しさん＠お腹いっぱい。
2006/03/14(火) 12:39:02限界があると誰もが踏んでるのが x86。コンロだろうがダンロだろうがもうすぐ終わり。
果敢に挑戦した EPIC ももう失敗という結論が出ている。
どの道 Intel も今ある RISC のどれかを採用するしか道はないと思うがな。AMD もな。
0152名無しさん＠お腹いっぱい。
2006/03/14(火) 13:21:09IA-64 も「新規に始めるほどではない」って感じじゃないの?
(始めちゃったら「普通」程度)
0153名無しさん＠お腹いっぱい。
2006/03/14(火) 13:53:18x86の命令セットでも、もっと大量のレジスタが同時に使えれば
アプリの速度とコードサイズは改善されるんじゃない？
0154名無しさん＠お腹いっぱい。
2006/03/14(火) 13:54:230155名無しさん＠お腹いっぱい。
2006/03/14(火) 14:08:00トランジスタ数が減らせない。内部 RISC への変換部分が必要。つまり、
プログラミングインターフェースが非 RISC だから。メニーコアでは掛算で不利。
0156名無しさん＠お腹いっぱい。
2006/03/14(火) 14:10:50Itanium が現存してるのは、四苦八苦したのが Intel だったから。
普通の企業なら消え去ってる。この先も続ければ Intel でもわからんかも。
0157名無しさん＠お腹いっぱい。
2006/03/14(火) 14:37:51FPUも使わなくなるから(少なくともWindowsでは)
延命にはなるよね。
0158名無しさん＠お腹いっぱい。
2006/03/14(火) 14:41:12その点は確かにあるみたいだけど
VIA C7 みたいな路線のコアを
many core 化するような設計でもダメなのかな?
0159名無しさん＠お腹いっぱい。
2006/03/14(火) 14:58:34けどEPICはどっちかというと、同じように、
デコードしてから演算するまでに一手間かける流儀じゃない。
EPICってVLIWである必要あるの?
バンドル辺りも含めてRISCでもいけそうだけど。
0160名無しさん＠お腹いっぱい。
2006/03/14(火) 16:27:57Intelは死ぬだろうが、AMD64は残ると思う。
0161名無しさん＠お腹いっぱい。
2006/03/14(火) 16:58:110162名無しさん＠お腹いっぱい。
2006/03/14(火) 17:49:370163名無しさん＠お腹いっぱい。
2006/03/14(火) 19:04:52単純計算なら、現状の技術で50コアぐらいまではいける
0164名無しさん＠お腹いっぱい。
2006/03/14(火) 19:15:47よし、それでいこ。
0165名無しさん＠お腹いっぱい。
2006/03/14(火) 19:54:30CELL みたいにリング?
っとここから先は i386/amd64 とか以前の
マルチコア一般論か。
0166名無しさん＠お腹いっぱい。
2006/03/14(火) 22:11:364 コや 8 コでまともに動かんのに、50 コ並べてもムダ。
0167名無しさん＠お腹いっぱい。
2006/03/14(火) 23:02:37あれだ、むかしOｈ！XでやっていたZ80を256個つかったコンピュータの話だ。
0168名無しさん＠お腹いっぱい。
2006/03/15(水) 00:03:240169名無しさん＠お腹いっぱい。
2006/03/15(水) 00:21:19> けどEPICはどっちかというと、同じように、
> デコードしてから演算するまでに一手間かける流儀じゃない。
いや、どの演算ユニット(の組み合わせ)を使うかを調べているだけで、
一手間かけているという程ではないだろう。
x86 の、デコードして、μOPに変換して、依存関係調べて並べ替えたりしてから
演算するのと比べればね。
0170名無しさん＠お腹いっぱい。
2006/03/15(水) 00:51:100171名無しさん＠お腹いっぱい。
2006/03/15(水) 00:53:340172名無しさん＠お腹いっぱい。
2006/03/15(水) 01:05:58洗剤ならアタックのがいいぞ
0173名無しさん＠お腹いっぱい。
2006/03/15(水) 01:10:22限定品の詰め替えタイプ
安かったので箱買いした
0174名無しさん＠お腹いっぱい。
2006/03/15(水) 01:18:43ここは隔離スレだから。まぁ、釣り堀の方が盛り上がってるのはどうかと思うが。
0175名無しさん＠お腹いっぱい。
2006/03/15(水) 02:56:03他はみんな、アリエールの物まねだろうが
0176名無しさん＠お腹いっぱい。
2006/03/15(水) 03:28:450177名無しさん＠お腹いっぱい。
2006/03/15(水) 04:50:21それは今の話なわけで、
当時はx86はもうダメ、という状況だったじゃないか。
RISCへの対抗でしかたなく出したIA-64だけど、
RISCがｼﾎﾞﾝﾇしたので、IA-64も一緒にｼﾎﾞﾝﾇ。
>>152
x64つっても、x86を延命しただけに過ぎないよ。
"AMDが"ということにコダワリがあるようだけど、
あんなのお蔵入りになったインテルの64ビット拡張と大差ないだろう。
>>155
ところが、RISCだってバイナリ互換を確保するために、結局は同じくらいコストかかってる。
長いスパンでのバイナリ互換を前提とすると、大差なくなる。
もちろん、バイナリ互換が必要のない分野では、無駄だけどね。
>>160-162
はいはいAMD厨ですね。
>>169
どのみちパイプラインを1段消費するわけで、
ならば、もう少し詰め込んでもいいような希ガス。
0178ウホッ
2006/03/15(水) 09:22:43>"AMDが"ということにコダワリがあるようだけど、
>あんなのお蔵入りになったインテルの64ビット拡張と大差ないだろう。
えーと... 満載すぎて...
どう突っ込んで欲しいんだ?
知らないなら素直にそういえば教えてもらえるのにね
0179名無しさん＠お腹いっぱい。
2006/03/15(水) 12:31:40SPARCは最初からアプリはバイナリ互換。
アプリの命令セットは完全キープ。
0180名無しさん＠お腹いっぱい。
2006/03/15(水) 12:42:16彼はそういうことを言いたいんじゃないと思うが
0181名無しさん＠お腹いっぱい。
2006/03/15(水) 13:06:020182名無しさん＠お腹いっぱい。
2006/03/15(水) 13:10:430183名無しさん＠お腹いっぱい。
2006/03/15(水) 13:42:180184名無しさん＠お腹いっぱい。
2006/03/15(水) 13:43:52AMDの64ビット拡張とインテルのお蔵入りになった64ビット拡張を、
どこが同じでどこが違うのか、比較して突っ込んでください。
0185ウヒョッ
2006/03/15(水) 14:16:240186名無しさん＠お腹いっぱい。
2006/03/15(水) 21:08:02相当速くなりそうだが。
0187名無しさん＠お腹いっぱい。
2006/03/15(水) 22:13:36けっしてSPARCが悪いわけではない！と思い鯛
0188名無しさん＠お腹いっぱい。
2006/03/15(水) 23:50:530189名無しさん＠お腹いっぱい。
2006/03/15(水) 23:54:49http://www.theregister.co.uk/2006/03/14/sun_rock_deets/
0190名無しさん＠お腹いっぱい。
2006/03/16(木) 05:29:210191名無しさん＠お腹いっぱい。
2006/03/16(木) 07:12:42あれは組み込み向けでしょ?
0192名無しさん＠お腹いっぱい。
2006/03/16(木) 10:55:50実行イメージのサイズが小さくなるから、ディスクからロードする時間が減らせるんだよね、確か。
HP-PA や Alpha が実行ファイルでかすぎてベンチマーク値ほど速い感じがしない、という
話はあった。
0193名無しさん＠お腹いっぱい。
2006/03/24(金) 18:53:11http://www.anandtech.com/systems/showdoc.aspx?i=2727
Niagaraｼﾎﾞﾝﾇ?
0194名無しさん＠お腹いっぱい。
2006/03/25(土) 17:16:020195名無しさん＠お腹いっぱい。
2006/04/12(水) 22:47:170196名無しさん＠お腹いっぱい。
2006/04/12(水) 22:57:12できる方。
SPARC の方は数千円〜数万円もあれば、中古機が手に入るが、
IA64 の方は…
0197名無しさん＠お腹いっぱい。
2006/04/12(水) 23:22:17ski ってやつ。
＃ ま、釣りだろうがw。
0198名無しさん＠お腹いっぱい。
2006/04/13(木) 09:49:22状況をみると、SPARCの方が存続しそう。。Niagara2とかROCKとかOPLとか、、。
IA64はHPの周辺で終りそう。。
0199名無しさん＠お腹いっぱい。
2006/04/13(木) 22:05:380200名無しさん＠お腹いっぱい。
2006/04/13(木) 22:45:100201名無しさん＠お腹いっぱい。
2006/04/13(木) 22:57:030202名無しさん＠お腹いっぱい。
2006/04/14(金) 02:32:48他のコンピュータメーカーやIntelやAMDなどと比べても上がってた
最近下がってきてるけどまだ$5くらい
2月のころは$4.5を下回ってたのに
■ このスレッドは過去ログ倉庫に格納されています