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/
0070名無しさん＠お腹いっぱい。
2006/03/02(木) 16:26:40SPARCzen
wasabiSPARC
geishaSPARC
SPARCfuji
harakiriSPARC
SPARCchonmage
SPARCshogun
sadoSPARC
hanaSPARC
SPARCsamurai
tofuSPARC
0071名無しさん＠お腹いっぱい。
2006/03/02(木) 17:17:23おまいはこれが出たら使うんだろうな?
>SPARCwashable
微妙に惹かれる…
0072名無しさん＠お腹いっぱい。
2006/03/02(木) 17:21:550073名無しさん＠お腹いっぱい。
2006/03/02(木) 19:29:520074名無しさん＠お腹いっぱい。
2006/03/02(木) 22:47:09蛇足だが、NEXTSTEPはHyperSPARCとMicroSPARC IIでしか動かん。
どっちもどっちだな。
0075名無しさん＠お腹いっぱい。
2006/03/02(木) 22:57:40Solaris ported to Itanium?
http://www.theregister.co.uk/2006/03/02/sun_solaris_itanium/
0076名無しさん＠お腹いっぱい。
2006/03/02(木) 23:02:54ただしHP-UXを捨てさせるのが条件だナ
0077名無しさん＠お腹いっぱい。
2006/03/02(木) 23:08:420078名無しさん＠お腹いっぱい。
2006/03/02(木) 23:12:48俺はPolarisの方がいい
0079名無しさん＠お腹いっぱい。
2006/03/02(木) 23:42:26丁度今 Oracle World だかなにかやってない？
街宣車に乗って東京フォーラムに突入してくれｗ
〜３日(金) Oracle OpenWorld Tokyo 2006
米国サン・マイクロシステムズ社から
【元米国ジョージア州CIO（最高情報責任者）】ラリー・シンガーが来日講演！
主催：日本オラクル(株)／オラクル・コーポレーション
後援：日本OAUG 会場：東京国際フォーラム
0080名無しさん＠お腹いっぱい。
2006/03/03(金) 00:13:45DECの日本語ドキュメントを超える者無し。
0081名無しさん＠お腹いっぱい。
2006/03/03(金) 03:06:00おお
情報thx
そういえはjpサイトにも広告出てたね…
蟹NIC持ってうろうろしてるやや長髪のキモオタが居たらそれ漏れだからｗ
フリーのOracleってSolaris上ではあんま需要無いかなぁ？
現状はpgsqlかバンドルされてるmysql使えっちゅーことになるンだろうけど
0082名無しさん＠お腹いっぱい。
2006/03/03(金) 03:47:34SolarisをPOWERに移植しているとも書かれているよ。
0083名無しさん＠お腹いっぱい。
2006/03/03(金) 04:09:56ただSgiもPCで遊んでないでIRIXをItaniumに移植していればもう少し
ダメになるのを遅くできたかもしれないと思うので
体力のあるうちにマルチプラットフォームで
いろいろやっておくのは悪くないと思われ
0084名無しさん＠お腹いっぱい。
2006/03/03(金) 23:22:43それがPolaris
0085名無しさん＠お腹いっぱい。
2006/03/04(土) 00:28:13Solaris 2.4/2.5.1 for PowerPC作っていたな。
0086名無しさん＠お腹いっぱい。
2006/03/04(土) 00:52:100087名無しさん＠お腹いっぱい。
2006/03/04(土) 05:53:11CHRPかと。
PRePは、IBMやMotorolaが製造していたPowerPC搭載マシンで、
「WindowsNT4.0PPC版」は動かせるが、Macとの互換性は無い。
CHRPは、PRePとPowerMacを統合する計画で作られたもので、
計画は頓挫したが、OpenFirmwareを採用した第二世代以降の
PowerMacやIBM RS/6000などはCHRPマシン。結局、Appleの
路線変更でMacOSは自社製マシンでしか動作しないように開発
されることになり、それがCHRP構想に決定的な幕引きをした。
昔々のお話。めでたし、めでたし。
0088名無しさん＠お腹いっぱい。
2006/03/04(土) 10:19:400089名無しさん＠お腹いっぱい。
2006/03/04(土) 10:32:46StarSuites, OpenOffice.orgに少し味方ができるくらいの話じゃないかと。
ジャストシステムとか、コーレルとか。
むしろ喜んでいるのは、IBMとかHPとかロータスとか、
ビジネス向けのソリューションを提供している会社じゃないだろうか。
生成するドキュメント形式のもう一つの大きな可能性が出てきたことで、
Desktop Officeスーツに食い込んでいける可能性がある。
0090名無しさん＠お腹いっぱい。
2006/03/04(土) 12:10:20ODFっていうとワープロっていうかViewer?大昔INTAPが補助金ばらまいて各社に作らせたよね。
第五世代計算機プロジェクトの一環だったかと。
その当時のISOのODFとは関係ないだろうか？
0091名無しさん＠お腹いっぱい。
2006/03/07(火) 01:51:12うーん，この組み合わせでは，もはや共同戦線にはならないような気がする．
HPが得るものがほとんど無いので，一方的なボランティアになっちゃうな．
IPFも最近思ったほど悪くないみたいだし，ProLiant との日本柱でHPはどうにかなりそうな予感．
Sunは，ProLiant っていう，x86 Solaris が動く広大なプラットフォームが欲しいだけなんだろうなあ．
0092名無しさん＠お腹いっぱい。
2006/03/07(火) 02:10:14HPをからかってるだけだろ？
0093名無しさん＠お腹いっぱい。
2006/03/07(火) 04:17:182000年前後売れに売れた、ローエンド〜ミドルレンジsparc機の
リプレイスメント市場ってのがあるから、HPにも悪くない話だと思う
0094名無しさん＠お腹いっぱい。
2006/03/07(火) 06:11:22> IPFも最近思ったほど悪くないみたいだし
ぉぃぉぃ
Itanium2はMcKinleyからほとんど変っていないぞ。
ちょっとコアのクロックが高くなったとか、
ちょっとバスのクロックが高くなったとか、
ちょっとキャッシュのサイズが大きくなったとか、
それくらいで、ほとんど進歩していない。
0095名無しさん＠お腹いっぱい。
2006/03/07(火) 10:54:520096名無しさん＠お腹いっぱい。
2006/03/08(水) 01:10:32どこが？
0097名無しさん＠お腹いっぱい。
2006/03/09(木) 03:14:13立ててみました。
Sun Microsystems 最大の重複
http://pc8.2ch.net/test/read.cgi/unix/1141840635/
0098名無しさん＠お腹いっぱい。
2006/03/10(金) 12:11:080099名無しさん＠お腹いっぱい。
2006/03/11(土) 09:36:380100名無しさん＠お腹いっぱい。
2006/03/11(土) 09:59:490101名無しさん＠お腹いっぱい。
2006/03/11(土) 11:33:380102名無しさん＠お腹いっぱい。
2006/03/11(土) 11:43:58McKinleyの2倍性能のmadisonが安定供給できているものの、
春からのmontecitoはmadisonの２倍程度にしか性能向上していないしな。
来年のmontvalでもさらに２倍程度の向上しか望めないダメアーキテクチャ。
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:10
■ このスレッドは過去ログ倉庫に格納されています