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

Sun Microsystems IPF採用撤回は大失策

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2006/02/25(土) 19:39:56
かつてSunもIPFの採用を表明していたが、後になって撤回。

もしIPF版のSolarisを出していれば、
日本メーカーのIPFマシンがHP-UXやLinuxではなく、
hpのOEMマシン以外はSolaris一色になっていただろうに。

【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0120名無しさん@お腹いっぱい。2006/03/13(月) 12:01:49
>>118
いや、だから、それが安直だと言ってるんだが... そんな話なら Ita は他社に負けまくりww
0121名無しさん@お腹いっぱい。2006/03/13(月) 12:19:08
HP UX11.iv2
BEA 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:24
っていうかさ、AMDでいいじゃん。
Itaniumより安いんだし、速いんだし。

X86系では、ItaniumはAMDが出てきたのでいらないよ。
01251062006/03/13(月) 14:49:45
/etc/ethersに"MACアドレス ホスト名"
/etc/hostname.dmfe0に"ether MACアドレス"という行を追加
とかやったらMACアドレスを変えることができました
とりあえず違うセグメントなのでeri0と同じにして、今のところ順調
さとうさんの所に使えなかったって書いてあったから意外だ
0126名無しさん@お腹いっぱい。2006/03/13(月) 18:11:03
>>121
> 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
>>123
ちまたのitaniumマシンは、みんな1FSBあたり2ソケット
667Mhzバスを、2ソケット4コアで共有するんならまずまずと
いったところでは
0128名無しさん@お腹いっぱい。2006/03/13(月) 19:42:20
>>126
スレッド数の話は>>114に聞いてくれ。
0129名無しさん@お腹いっぱい。2006/03/13(月) 22:54:34
>>119
足回りは日本のメーカー様にお願いします
ということでは?

そうやって、わざとらしく日本のメーカに入り込む余地を与えているのかも。
0130名無しさん@お腹いっぱい。2006/03/13(月) 23:13:36
>>119ではないが、やっぱりスケールは自分で無理では…
0131名無しさん@お腹いっぱい。2006/03/13(月) 23:22:14
>>129
まだわかんないのか... ヘッポコ日本企業連合にすがるしかもう道がなくなってしまったんだってば。
x86 を置き換えるはずだったんだぞ。方針変更どころか、チョー不得意分野で
かろうじてキノコってんだよ。
0132名無しさん@お腹いっぱい。2006/03/13(月) 23:34:11
でもまあ、PA-RISC から来た連中は今のジャンルが自分らの畑なワケだし。
単に PA-RISC 軍団に Intel がかつがれた、先のメド立たなくなってた PA-RISC 後継の
開発資金をまんまとせしめられた、ってことなのかも知れんな。
0133名無しさん@お腹いっぱい。2006/03/13(月) 23:36:26
Sun もへっぽこ日本企業頼みだしな。
0134名無しさん@お腹いっぱい。2006/03/13(月) 23:41:08
>>131
まあ、それは分かるんだが、
日本のメーカーのスケベ心をくすぐるのはうまいと思うんだよなぁ。
0135名無しさん@お腹いっぱい。2006/03/13(月) 23:59:16
>>133
RISC ならどれだろうが、あれだけ金と時間かければずっとマシなもんができると思うが。
違うか?
0136名無しさん@お腹いっぱい。2006/03/14(火) 01:16:11
あれだけ金と時間をかけた割には
従来品(x86,POWER,SPARC)と同程度に競うレベルでしかないよな

特にその予算の半分も要らないから Alpha に行っていれば…
0137名無しさん@お腹いっぱい。2006/03/14(火) 01:23:20
IntelがAlphaをやるといっても迫力なかったでしょう
独自アーキだったから皆RISC CPUから撤退しちゃったわけで
0138名無しさん@お腹いっぱい。2006/03/14(火) 01:26:27
つかPA続けとけば良かったんじゃね?
0139名無しさん@お腹いっぱい。2006/03/14(火) 01:42:29
PA-RISCもAlphaも結構いい性能出てたからね。

> ヘッポコ日本企業

しかし日本企業がOEMやライセンスしている所は生き残る可能性高いような…
純潔主義のDECはいっちゃったし
0140名無しさん@お腹いっぱい。2006/03/14(火) 01:52:38
>>137
皆って HP だけだけど。sgi は後継とは違うしなぁ。
0141名無しさん@お腹いっぱい。2006/03/14(火) 02:02:40
>>137
RISC 撤退? 寝ぼけまくりですね。
0142名無しさん@お腹いっぱい。2006/03/14(火) 02:14:36
>>136
どう考えても余分なトランジスタの要る x86 や、いくら工夫しても性能のでない Ita なんかに
ばっかり大量にリソース消費されて、こいつらがまともな RISC の2 つ 3 つへ
あてがわれてたら今システムはずっと高性能だろうし、CPU 単価ももっとずっと低いかもね。
無駄の見本として後世あざ笑われること必定。
0143名無しさん@お腹いっぱい。2006/03/14(火) 07:47:05
1.6GHzでFSB400MHzでPOWER5 1.9GHzと互角だから、2.0GHzでFSB667MHzが
出せてたら、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
Itanium連合を組んだところでどうせ一番儲かるところはIBMに持ってかれるんだろ
長年続く企業システムのトップ企業にかなうわけない
同じ価格なら顧客はIBMを選択するだろうし価格を下げれば利益が少なくなるのは当然
PCサーバーなど低価格のシステムならIntelでも信用されるだろうがItaniumの目指してる
ハイエンドサーバーは億を超える価格だからな
0145名無しさん@お腹いっぱい。2006/03/14(火) 08:44:02
>>142
そりはもまいの考えであって、Intelとしては基本設計が古いRISCじゃ性能の向上に
限界があるので、EPICに切替えた訳だろ。
x86についてはNetBurstの後継としてIntel Coreが発表されてる。

>>144
POWERの頑張り次第だね。
0146名無しさん@お腹いっぱい。2006/03/14(火) 09:46:25
>145
そういうこと言う人がよくいるけど
結局 EPIC のどの辺が "基本設計が新しい" の?

VLIW を現代マーケティング用語で言い換えただけじゃん?
0147名無しさん@お腹いっぱい。2006/03/14(火) 10:02:51
http://ja.wikipedia.org/wiki/EPIC%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

> Itaniumの創始者であるヒューレット・パッカード社は
> 2004年9月にアーキテクチャを強調するのをやめた。
0148名無しさん@お腹いっぱい。2006/03/14(火) 10:02:53
>>145
技術的なことよりも営業的な合理性を追求した結果が現状だとおもうけど。
0149名無しさん@お腹いっぱい。2006/03/14(火) 11:24:06
>>145
業界こぞって ILP より TLP と叫んでる現状は無視ですか?
0150名無しさん@お腹いっぱい。2006/03/14(火) 12:29:04
>>145
RISC が古い、って証明しそこなったのが Itanium。かっこ悪すぎ。
0151名無しさん@お腹いっぱい。2006/03/14(火) 12:39:02
>>145
限界があると誰もが踏んでるのが x86。コンロだろうがダンロだろうがもうすぐ終わり。
果敢に挑戦した EPIC ももう失敗という結論が出ている。
どの道 Intel も今ある RISC のどれかを採用するしか道はないと思うがな。AMD もな。
0152名無しさん@お腹いっぱい。2006/03/14(火) 13:21:09
x86 のどの部分に限界があるの? amd64化でも全然ダメ?

IA-64 も「新規に始めるほどではない」って感じじゃないの?
(始めちゃったら「普通」程度)
0153名無しさん@お腹いっぱい。2006/03/14(火) 13:53:18
レジスタ数とか
x86の命令セットでも、もっと大量のレジスタが同時に使えれば
アプリの速度とコードサイズは改善されるんじゃない?
0154名無しさん@お腹いっぱい。2006/03/14(火) 13:54:23
レジスタ数ならamd64化で倍増したわけだが
0155名無しさん@お腹いっぱい。2006/03/14(火) 14:08:00
>>152
トランジスタ数が減らせない。内部 RISC への変換部分が必要。つまり、
プログラミングインターフェースが非 RISC だから。メニーコアでは掛算で不利。
0156名無しさん@お腹いっぱい。2006/03/14(火) 14:10:50
>>152
Itanium が現存してるのは、四苦八苦したのが Intel だったから。
普通の企業なら消え去ってる。この先も続ければ Intel でもわからんかも。
0157名無しさん@お腹いっぱい。2006/03/14(火) 14:37:51
amd64化でレジスタはとりあえず増えるし、
FPUも使わなくなるから(少なくともWindowsでは)
延命にはなるよね。
0158名無しさん@お腹いっぱい。2006/03/14(火) 14:41:12
>155
その点は確かにあるみたいだけど
VIA C7 みたいな路線のコアを
many core 化するような設計でもダメなのかな?
0159名無しさん@お腹いっぱい。2006/03/14(火) 14:58:34
>>155
けどEPICはどっちかというと、同じように、
デコードしてから演算するまでに一手間かける流儀じゃない。

EPICってVLIWである必要あるの?
バンドル辺りも含めてRISCでもいけそうだけど。
0160名無しさん@お腹いっぱい。2006/03/14(火) 16:27:57
AMD64の、RISCのMIPSのような引数のレジスタ渡しが大きい。

Intelは死ぬだろうが、AMD64は残ると思う。
0161名無しさん@お腹いっぱい。2006/03/14(火) 16:58:11
Intel も amd64 パクったじゃん
0162名無しさん@お腹いっぱい。2006/03/14(火) 17:49:37
IntelのアーキはX86, Itaniumとも死ぬが、AMD64アーキは残る、かな?
0163名無しさん@お腹いっぱい。2006/03/14(火) 19:04:52
P6コアのトランジスタ数は550万
単純計算なら、現状の技術で50コアぐらいまではいける
0164名無しさん@お腹いっぱい。2006/03/14(火) 19:15:47
>>163
よし、それでいこ。
0165名無しさん@お腹いっぱい。2006/03/14(火) 19:54:30
クロスバをどうすんねん。
CELL みたいにリング?

っとここから先は i386/amd64 とか以前の
マルチコア一般論か。
0166名無しさん@お腹いっぱい。2006/03/14(火) 22:11:36
>>163
4 コや 8 コでまともに動かんのに、50 コ並べてもムダ。
0167名無しさん@お腹いっぱい。2006/03/14(火) 23:02:37
>>163
あれだ、むかしOh!XでやっていたZ80を256個つかったコンピュータの話だ。
0168名無しさん@お腹いっぱい。2006/03/15(水) 00:03:24
ISA バスと VGA チップとキーボードとモニタも 50 個つなげて MS-DOS 50 個動かすとか。
0169名無しさん@お腹いっぱい。2006/03/15(水) 00:21:19
>>159
> けどEPICはどっちかというと、同じように、
> デコードしてから演算するまでに一手間かける流儀じゃない。

いや、どの演算ユニット(の組み合わせ)を使うかを調べているだけで、
一手間かけているという程ではないだろう。

x86 の、デコードして、μOPに変換して、依存関係調べて並べ替えたりしてから
演算するのと比べればね。
0170名無しさん@お腹いっぱい。2006/03/15(水) 00:51:10
このスレを見ていると Spark は蚊帳の外で既に死んでいるようだな。
0171名無しさん@お腹いっぱい。2006/03/15(水) 00:53:34
洗剤?
0172名無しさん@お腹いっぱい。2006/03/15(水) 01:05:58
良く落ちるSPARK?w
洗剤ならアタックのがいいぞ
0173名無しさん@お腹いっぱい。2006/03/15(水) 01:10:22
漏れはライオンのトップを使ってる
限定品の詰め替えタイプ
安かったので箱買いした
0174名無しさん@お腹いっぱい。2006/03/15(水) 01:18:43
>>170
ここは隔離スレだから。まぁ、釣り堀の方が盛り上がってるのはどうかと思うが。
0175名無しさん@お腹いっぱい。2006/03/15(水) 02:56:03
アリエールだっての
他はみんな、アリエールの物まねだろうが
0176名無しさん@お腹いっぱい。2006/03/15(水) 03:28:45
P&G
0177名無しさん@お腹いっぱい。2006/03/15(水) 04:50:21
>>149
それは今の話なわけで、
当時は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
>x64つっても、x86を延命しただけに過ぎないよ。
>"AMDが"ということにコダワリがあるようだけど、
>あんなのお蔵入りになったインテルの64ビット拡張と大差ないだろう。

えーと... 満載すぎて...
どう突っ込んで欲しいんだ?

知らないなら素直にそういえば教えてもらえるのにね
0179名無しさん@お腹いっぱい。2006/03/15(水) 12:31:40
> ところが、RISCだってバイナリ互換を確保するために、結局は同じくらいコストかかってる。

SPARCは最初からアプリはバイナリ互換。
アプリの命令セットは完全キープ。

0180名無しさん@お腹いっぱい。2006/03/15(水) 12:42:16
>>179
彼はそういうことを言いたいんじゃないと思うが
0181名無しさん@お腹いっぱい。2006/03/15(水) 13:06:02
彼が言いたいのはSPARC でいえば、例えばレジスタウィンドウ
0182名無しさん@お腹いっぱい。2006/03/15(水) 13:10:43
新しいCPUでもISAの互換性を維持するのにコストが掛かる、ってことが言いたいんじゃないの?
0183名無しさん@お腹いっぱい。2006/03/15(水) 13:42:18
Niagara のコア 1 個あたりトランジスタ何個よ?
0184名無しさん@お腹いっぱい。2006/03/15(水) 13:43:52
>>178
AMDの64ビット拡張とインテルのお蔵入りになった64ビット拡張を、
どこが同じでどこが違うのか、比較して突っ込んでください。
0185ウヒョッ2006/03/15(水) 14:16:24
>184=>177 本人かな?
0186名無しさん@お腹いっぱい。2006/03/15(水) 21:08:02
SPARCにARMのThumb命令みたいなのって入れてくれないかな?
相当速くなりそうだが。
0187名無しさん@お腹いっぱい。2006/03/15(水) 22:13:36
遅いのはSunの設計とTIの力の入れ方がまずいからだよ。
けっしてSPARCが悪いわけではない!と思い鯛
0188名無しさん@お腹いっぱい。2006/03/15(水) 23:50:53
TIは能力不足だろうな。あれが限界。
0189名無しさん@お腹いっぱい。2006/03/15(水) 23:54:49
なんか眉唾だが
http://www.theregister.co.uk/2006/03/14/sun_rock_deets/
0190名無しさん@お腹いっぱい。2006/03/16(木) 05:29:21
命令長が短くなるだけで、そんなに速くなるの?
0191名無しさん@お腹いっぱい。2006/03/16(木) 07:12:42
Thumbのこと?
あれは組み込み向けでしょ?
0192名無しさん@お腹いっぱい。2006/03/16(木) 10:55:50
>>191
実行イメージのサイズが小さくなるから、ディスクからロードする時間が減らせるんだよね、確か。
HP-PA や Alpha が実行ファイルでかすぎてベンチマーク値ほど速い感じがしない、という
話はあった。
0193名無しさん@お腹いっぱい。2006/03/24(金) 18:53:11
Sun’s T2000 “Coolthreads” Server: First Impressions and Experiences
http://www.anandtech.com/systems/showdoc.aspx?i=2727

Niagaraシボンヌ?
0194名無しさん@お腹いっぱい。2006/03/25(土) 17:16:02
シボンヌっつーほど悪くない気が。
0195名無しさん@お腹いっぱい。2006/04/12(水) 22:47:17
今からia64とSPARC、勉強するならどっち?
0196名無しさん@お腹いっぱい。2006/04/12(水) 22:57:12
実機にアクセスせずに勉強しても虚しいので、実機にアクセス
できる方。
SPARC の方は数千円〜数万円もあれば、中古機が手に入るが、
IA64 の方は…
0197名無しさん@お腹いっぱい。2006/04/12(水) 23:22:17
オレも SPARC がいいと思うが、IA64 もシミュレーターならあるぞ。
ski ってやつ。
# ま、釣りだろうがw。
0198名無しさん@お腹いっぱい。2006/04/13(木) 09:49:22
> 今からia64とSPARC、勉強するならどっち?

状況をみると、SPARCの方が存続しそう。。Niagara2とかROCKとかOPLとか、、。
IA64はHPの周辺で終りそう。。



0199名無しさん@お腹いっぱい。2006/04/13(木) 22:05:38
Naiagara2が出るまで会社持ちませんよ?
0200名無しさん@お腹いっぱい。2006/04/13(木) 22:45:10
Intel つぶれちゃうの?
0201名無しさん@お腹いっぱい。2006/04/13(木) 22:57:03
SPARC64最高!!って富士通もやばいかw
0202名無しさん@お腹いっぱい。2006/04/14(金) 02:32:48
ここのところのSUNの株価が上がってたのはどうして?
他のコンピュータメーカーやIntelやAMDなどと比べても上がってた
最近下がってきてるけどまだ$5くらい
2月のころは$4.5を下回ってたのに
0203名無しさん@お腹いっぱい。2006/04/14(金) 12:32:10
>>195
何を勉強するの?
0204名無しさん@お腹いっぱい。2006/04/14(金) 13:13:25
引っ越しの〜サカイ
0205名無しさん@お腹いっぱい。2006/04/15(土) 09:52:15
誰か>>204に突っ込んでやれよ
0206名無しさん@お腹いっぱい。2006/04/15(土) 15:19:07
放置こそ最高のツッコミ
0207名無しさん@お腹いっぱい。2006/04/15(土) 16:43:53
関西だと、>>204 はつっこんでもらえる可能性があるが、>>206 はどうにも
つっこみようがないな。
0208名無しさん@お腹いっぱい。2006/04/15(土) 22:46:26
ないですか
0209名無しさん@お腹いっぱい。2006/04/16(日) 05:31:42
亀岡山田木材
よいしょ
どんどん
0210名無しさん@お腹いっぱい。2006/04/16(日) 10:40:48
>>209
> 亀岡山田木材
"経営団地"が抜けてないか?
0211名無しさん@お腹いっぱい。2006/04/21(金) 15:32:22
420Rとかを移設するとき
「よいしょ」の台詞で「どんどん」と突っ込みを入れる香具師
関西生まれ確定w
0212名無しさん@お腹いっぱい。2006/04/22(土) 08:58:04
誰が河馬やねん
0213名無しさん@お腹いっぱい。2006/04/28(金) 16:23:28
ぢつは、OpenSolaris の Itanium 対応コードは某社内でバリバリにメンテされてて、
Itanium 開発打ち切りで間髪置かず発表されることになっている。 ......かも知れない。
0214名無しさん@お腹いっぱい。2006/05/09(火) 00:50:30
sgiがオワタ。
0215名無しさん@お腹いっぱい。2006/05/09(火) 11:57:00
ふーん... SMP 技術や IRIX、もちろんグラフィック処理もだけど、会社ごと買ってやろうと
いうとこはないのか? Ita 解決同盟は助けてやらないのか?
MIPS ってもう傘下じゃないんだっけ?
Sun がもらってこれそうな部品は... 特にない?
0216名無しさん@お腹いっぱい。2006/05/09(火) 12:27:37
Wintel へすりよったものは血ィ吸い取られてポイって感じだな。
その点 HP は PA-RISC 後継で Intel をうまい具合に利用したからすごいかも。
0217名無しさん@お腹いっぱい。2006/05/09(火) 13:18:46
HPとSGIじゃ母体の強さが全然違うでしょ。
>>215
CPUにこだわる人が買うとは思えない。
0218名無しさん@お腹いっぱい。2006/05/09(火) 13:50:27
なるほど。母体が強いと Intel をうまいように利用できるのか。つまらんはなしだな。
0219名無しさん@お腹いっぱい。2006/05/09(火) 14:17:44
沖や住友はなんとかしてやれないのか。
■ このスレッドは過去ログ倉庫に格納されています