Sun Microsystems 最期の神託

**名無しさん＠お腹いっぱい。** · 2009/05/11(月) 19:40:54

コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」

【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 17:37:52

ﾊ-ﾄﾞﾃﾞｨｽｸが普及しはじめたころか
当時は、40MBでWin95とLinuxを余裕でデュアルブートで使えてた
今となっては不思議

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 17:49:39

9801RXは 12MHzだな。MS-DOS 3.3。米国だと当時もう MS-DOS 4.0が出てるが。
16bit www

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 18:00:41

>>639
チョウの写真や北斎の波がウィンドウの中をナナメにスライドしまくるデモ見て
心底感動したよ、当時。NeWSのデモ。

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 19:04:26

昔話は盛り上がるねぇ。今の話はさっぱりだけど。

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 19:15:33

>>638
Sun-3 → Sun-4 → SS1 → SS1+ → SS2 だからな。あいだ空きすぎ。

DECstation 3100は Sun-4と SS1のあいだ。
Sun-3も遅いマシンじゃないよ。m68kだから他も似たようなもんだけど。
Sun-3/80なら話は別。あれは後方互換用で、旗艦じゃない。

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 19:42:24

世界征服を企むエリソンは 2つのことをやると思うよ。

1. IBMハイエンドサーバーの対抗機を出す
これは Rockなのかはたまた SPARC64なのか..

2. iPhone対抗デバイスを出す
T2ベースで Solaris+Android、OraStore開店

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 19:59:26

まずはMySQLをOraSQLに改名すると思う

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 20:02:40

>>645
3. Appleを買収して Macを SPARCベースにして MacOSのコアを Solarisに置換る

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 20:24:03

>>643
そりゃ、お通夜だからな

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 20:31:00

ご焼香はこちらです

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 21:03:25

>>647
お弁当箱再びってことでSPARCminiがでたら買うｗ

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 21:44:29

ｱﾎﾟｰを買収するためにはｼﾞｮﾌﾞｽﾞを暗s(ry

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 22:48:49

>>651
ジョブスとエリソンは親友じゃなかったか？

NeXTとAppleが合併してジョブスが復帰した時、エリソンもApple役員
に加わったし、OracleもApple株をかなり持ってたはず。

一時はOracleが友好的にAppleを買収するかどうかという話もあった。

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 22:56:15

これでAppleも一緒になったら勝てる・・・かな・・・

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 23:03:56

Appleと一緒になったら俺は見限る

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 23:06:10

勝つる！

**名無しさん＠お腹いっぱい。** · 2009/05/29(金) 23:15:12

暗黒面に飲まれちゃだめだ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 00:51:19

>>639
98なんかと比較するなよ。
比較するならMacにしろよ。

> そんな賞味期限とっくに過ぎてジャンク屋から買って来た時の話されたってな。

その発想はなかったわ。

>>644
なぜかSSじゃないSun4は見たことないわ。

>>645
T2ベース? ありえねー。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 09:46:50

NVIDIAに買收される
それが幸せだ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:04:10

>>657
Macと比較するとそんなに違うか? IIfxとか IIcxあたりかな。68030。
SS2の方がブッチギリで速いよ。

> なぜかSSじゃないSun4は見たことないわ。
ピザボックスがないから。それか、初もん過ぎて買わなかったのかもね。
数値的には DECstation 3100と同等ぐらいのはず。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:07:07

>>659
> Macと比較するとそんなに違うか?

たいして違わないね。>>657がキモマカか何かなんだろう。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:24:43

>>659
IIfxなんぞで 20inch級モニターとそれなりの装備したら SS2よりずっと
高かったよな。まあ、日本だけなんだろうがw

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:27:13

当時の98なんて、

マルチタスクできない
たった640KBのメモリ、しかも64KBセグメント
16bit

Unixワークステーションとは住む世界が違いすぎる。

Macなら、
いちおうマルチタスクっぽい
それなりに広いメモリ、もちろんフラット
32bit

ってことで、Unixワークステーションと比較してOK

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:40:07

だけど「x86の技術的優位性」>603 とか言うバカに言って聞かせてやってる
わけだから、x86じゃないとな。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:43:30

>>662
OKじゃねえーよw
XENIX on PC98-FAとか、A/UXなら比較していいけど。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:44:04

>>662
もちろん、「住む世界が違いすぎる」のを示すのが目的なわけでw

けどさ、PC-UX（だっけか?）もあったし。マルチタスク。
MINIXにもみんなカンドーした。OS/2もあった。

> Macなら、
日本では、死ぬ程高かったよ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 10:53:10

あのころのMacの日本価格は当時のレートを考えても高かった。

＞いちおうマルチタスクっぽい

いや当時のあれは本当に「っぽい」というのもはばかられるような・・・
当時としてはそれでもアレだったけど・・・

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 11:29:07

>>663
おいおい60レスも前じゃないか。

まぁ、
今のx86になったMacの御先祖様の話
ってことで、理解しとけよ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 11:30:27

>>664
PC98-FAってなんだ?

まさかPC-9801FAのことじゃないよな。年代違うし。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 11:31:35

XENIXとかPC-UXとかOS/2とか、そんなマイナーなものを持ち出してもなぁ。

当時、98ならDOSだったろ。ほとんど。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 11:35:21

勝てば官軍、負ければ賊軍 w

**,,・´∀｀・,,）っ-○○○** · 2009/05/30(土) 11:57:03

>>622
逆に言うと、トランジスタを大量に詰め込めるのに、1つの命令が単純すぎると
無駄が多くなるという問題が生じるわけですな。
アウトオブオーダ実行とか複雑なアクセラレータとか使えるようにすると
相対的に命令デコーダの負担の差は小さくなるのです。

同じリッチなパイプラインなら、1命令あたりの密度が高い方が有利というわけです。
まあ、x86がRISCと比較して1命令当たりの密度が高いって感じるのは
base + scale*index + offsetで指定したメモリオペランドを第2引数に使えたりするときかと思いますが

1スレッドの性能をひたすら稼ぐには命令セットをどんどんリッチにしていく必要があります。
POWERがいまさらBCDの演算に特化した命令と演算ユニットを搭載してるけどあんな感じかな。
もちろんRISCの設計思想に反してます。

逆に、1コアあたりの実効性能はある程度諦めて組み込みに特化する（ARMやSH）とか
また大量のコアで並列処理して性能を稼ぐというアプローチには未だにRISCは有効ですよ。
それがCellとかNiagaraですな。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 12:00:55

その昔、SUNのSparc-WSを欲しいと思っていた。速いし物めずらしいから
しかし、なんだかんだ言って自作PCで満足してしまい去年の末中古で
Sparcマシンを買ったが「こんなもんか、、、」という感じで拍子抜け
した。
PCがDOSの頃に無理してでも、Sparc-WS所有していたらその違いに
感動したかもしれない。

**,,・´∀｀・,,）っ-○○○** · 2009/05/30(土) 12:05:05

ただ、組み込み向けだと2バイト命令長のほうがコード密度的に都合がいいかなと

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 13:39:01

>>671,673
無理無理ww 「盲信」以外に彼には何もできませんので。
ましてや「トレードオフ」なんて言ったらアタマから火花とケムリが飛び散りますww

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 13:42:54

SPARCマシンは自宅で使うには消費電力が高すぎる
UltraSPARC IIですらAthlonXPの2倍近い品

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 13:52:04

>>671
問題はだ、命令密度を上げるという観点で RISCに改良を加えたものと、
RISC以前の観点で設計された x86の ISAが同等なものなのか、ということだね。
高速化に邪魔な命令をコンパイラーが使わなくなってくれるんなら近いところへ
行けるんだろうが、今までの「資産」を全面にうたってるからには
そうも言ってられない、と。
どうしてもスヌープが必要な場合が多かったり、アトミックに排他する期間が
長かったり、いろいろ不利だと思うが。

> base + scale*index + offsetで指定したメモリオペランドを第2引数に使えたりするときかと思いますが

> 逆に、1コアあたりの実効性能はある程度諦めて組み込みに特化する（ARMやSH）とか
> また大量のコアで並列処理して性能を稼ぐというアプローチには未だにRISCは有効ですよ。
> それがCellとかNiagaraですな。

今後の市場構成を考えると、ほとんどそれで占まるんじゃねーの?

**,,・´∀｀・,,）っ-○○○** · 2009/05/30(土) 14:00:51

コアを増やしても同期のオーバーヘッドなんかもあるし、それほどうまくは性能上がらないでしょ
CPUに対してメモリやストレージはボトルネックになるし

ある程度は1スレッド当たりの性能向上に費やすことは必要になる。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 14:17:43

>>677
> ..、それほどうまくは性能上がらないでしょ

それはごく最近本気で MPのことを考えるようになった（昔から話だけは
あったけどww）x86の状況であって、Mbusからはじまり SPARCcenter2000で既に
XDbus 20CPUを実現していた SPARCにはあてはまらないのだよ明智くん。
BSDベースを捨てて SVR4を作ったのもまさにそこにあったわけで、
ちゃんとリニアに性能が上がるのは周知の事実。
もちろんソフトウェアの作りが適したものになる必要があって、OSまで含めて
考えた場合 SPARCはかなり優位な位置にいる。 ...んだからちゃんと売れよな。

> ある程度は1スレッド当たりの性能向上に費やすことは必要になる。

ある程度はね。けど用途的には減って行くでしょ。特殊な場合だけになる。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 14:27:04

お、例の人きたねえ
団子ちゃんは相手してくれるかな？

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 14:48:29

コネクションマシンはどこへ逝った。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 15:46:46

>>678
並列化には、アムダールの法則という壁があるんですよ。

ちなみにSPARCがリニアにスケールするのは、限られた状況だけよ。
大きなメモリバンド幅を必要とするアプリを走らせるとサチって話にならない製品もあったぞ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:13:14

この文脈で「アムダールの法則」は外しまくりだって、さっさと気づけよ...

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:17:37

Xeon最強！
SPARCイラネ！

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:38:38

>>682
SPARCとて例外ではありませんぞ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:40:09

>>683,674
ほらみろ、火花とケムリが吹き出しまくってるぞww もうすぐ爆発するなw

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 16:49:31

草を生やしてる人は、団子さんの意図がわかってないんじゃないか?

エンプラ向けのサーバに使われるようなCPUでは、SPARCは適切ではなくなってる、ってことよ。
まぁ、ロード命令にポストインクリメントが付いていて、それが即値どころかレジスタだっていうのは、やりすぎだと思うが。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 17:31:36

>>686
そりゃ違うだろ。>671 の

> もちろんRISCの設計思想に反してます。

は原理主義的な RISC思想は現在のトレンドに沿ってない、って言ってるだけで、
そもそも商用 RISCは最初の登場時点で RISC原理主義などではないし
（そんな商品はこの世に一度も存在してない）、より「RISC化」することに
よって性能を向上してきたのかというと全くその逆で「RISCらしく」ない
ことを次々と取込んで改良を重ねてきている。
もちろん、RISCであることの利点を損ねない方法によってだけどね。

「RISC原理主義」なんてのは CISCと言われてくやしくてしょうがない連中が
商用 RISCをなんとか攻撃したくて作り上げたタワゴトに過ぎんよ。
そんなのを標榜してる会社も人もどこにも存在しない。

で、今の改良を重ねた商用 RISCが、「RISC原理主義」からみたら RISCらしく
ないからと言って、じゃあ RISC以前の CISCと変わらないかと言ったら、
そんなワケがないんだが、そこはアイマイにしといてって低レベルな批判は
うんざりなんだよ。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 17:47:51

俺らはCISCと言って馬鹿にするけど
俺らを攻撃するのは反則だし許せない
ってことですねｗ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 18:04:21

>>681,684
こんなバカネタが真剣に論じられるほど、x86の世界は腐りきってるわけだな..
なるほどな..

「アムダールの法則を巡る Intelと AMDの戦い」
ttp://pc.watch.impress.co.jp/docs/2005/0112/kaigai147.htm

こんなもん、わかり切ったことじゃないか.. そんなリクツが単純適用できるんなら
64CPU機なんか一台も売れるわけがないだろ。アホくさ。

おい、Intelがなんて主張してるか、よく読んどけよ!?
オマエの話と正反対だぞ!!wwww

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 18:41:31

今更SPARCなの？(笑)

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:02:31

つまんない
おもしろいネタないの～？

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:11:29

じゃあ、SPARCのブランチ命令のディレイスロットについて語ろうぜ

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 19:15:58

>>689
どうでもいいけどコンマ区切りの引用は対応していない2chリーダーもあるので
>>681
>>684
としてほしいです

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 22:22:34

今どき RISC vs CIS Cかよw
思い出を語るスレだから、いいのか・・

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:09:37

通夜だからね

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:30:29

じゃあ、emacs vs viとかもあり？w

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:49:18

変態emacsなどの出る幕ではない。

**名無しさん＠お腹いっぱい。** · 2009/05/30(土) 23:59:11

>>696
そんなもんEmacs18やVim3の頃が、良かったって話にしかならねぇよ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:11:47

>>696
viの圧勝で結論出てるじゃん。emacs使ってる奴なんて馬鹿ばっかだろ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:43:35

利用シェルならさらに対立が見られそうな気がする

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 01:46:50

>>698
そこでなぜvimが出てくる

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:47:42

>>687
RISCってのは、
・コンパイラを前提にする
・定量的なアプローチ
この2つが命。

かつて昔の最適点で設計されたSPARCは、
バイナリ互換を保ちつつ発展したがゆえに、
いまでは最適点から、だいぶ遠ざかっている。

そんなSPARCを担ぎ上げるからには、
バイナリ互換のために醜悪なまま進んだ
x86を馬鹿にできる立場にはないんだ。
同じ土俵に、自分で下りていったのだから。

x86に追い付かれ、シェアを下から食われるのは、
当然の結果なわけで、自業自得なんですよ。

じゃぁSPARCは、どうすればよかったか。
バイナリ互換を犠牲にしてでも最適点を
追い続けるべきだった。

そうすれば、圧倒的な性能差を維持できた。

よくIntelは製造によるゴリ押しで性能を絞り出しているという批判を目にするけど、
巨大なキャッシュを積むなどの強引なことをやってきたのは、RISC勢だって同じことだ。
とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

ワークステーションとWebサーバの分野でシェアをx86にまるごと持ってかれた
その原因が傲慢にあることを、とっとと反省して、方針を切り換えるべきだね。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:54:16

>>689
お前さ、
Intelの10年後くらいの先の希望的な話
を持ち出してばかりだけどさ、
俺達、
現実の話してるんだよ。

Sunのスケールしないサーバな。
どうやって使うか知ってるか?
パーティション区切って使うんだよ。

実質的に
少ないCPU数のSMP機が複数台ある
っていう使い方をすれば、性能はでる。

もちろん、スケールしないってことには、
変りが無いが。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 07:57:51

>>692
遅延スロットは素晴らしいアイデアで、実際に役に立ってるじゃないか。

ただ、分岐命令だけってのが手ぬるいな。
剰余算命令にも遅延スロットがあるべき。

遅延スロットをどんどん適用していけば、
Out-of-order実行なんて必要ないぜ。
In-Orderでもキッチリ性能でるぜ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 08:42:38

終わっちゃったことなのにむなしくないですか？

60 · 2009/05/31(日) 09:34:08

>>702
> とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

強引とかバカか？
そのための命令セットアーキテクチャなんだから当たり前じゃないか。
そのためにわざわざ整理したんだよ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 12:56:44

>>702
バイナリ互換無視したら、コード資産が無駄になる。
x86と最も差があった時点で5倍ぐらい。
486以降Risc手法を取り込んできたx86に対しバイナリ互換無視でも
どこまで性能差を付けれたかのかな?

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:27:40

>>706が何を言いたいのか、わからん。
だれかエスパーで解説してくれ。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:28:44

>>707
コード資産?
x86信者みたいなこと言うなよ。

unixなんだから移植性あるコーディングして当然。
DOSでしか動かないとかWindowsでしか動かないとか
そういうコードしか書けない馬鹿と一緒にすんな。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 13:30:52

>>707
スケーラビリティのあるアーキテクチャなら、
使えるトランジスタが増えた分を、キャッシュではなく、マルチコアに振り向けられるだろ。

x86がヒーヒー言いながらIPCを上げようと効率の悪いことやってたんだから、
シンプルなコアなら4コアくらい余裕で実装できただろう。
それだけで性能4倍だぞ。

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 13:52:07

>>709
そうだな、そういう出来るプログラマのおかげでローエンドはSPARCからIntel CPUへの移行が
すんなりうまくいったわけだ。

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 13:58:04

つまりSPARCもまたバイナリ互換が捨てられない出来損ないプログラマの為に存在するんだなｗｗｗｗ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 15:13:08

手元にコードがあるものばかりじゃないでしょ

**,,・´∀｀・,,）っ-○○○** · 2009/05/31(日) 19:01:50

もちろん皮肉

手元にコードがあって再コンパイルすれば動くってのはSolarisじゃなくてDebianだろう

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 20:21:40

禿げ、デブ、共産主義の三重苦

もちろん皮肉

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 20:22:35

共産主義よかバイナリ非互換の方が良かったか？ｗ

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:13:05

>>709
SPARCが生き残ってる最大の理由はコード資産。
過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
一定の手間で動くということが重要。

移植性があるコーディングとか、そういうのはどうでもいい

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:35:58

>>717
>過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
>一定の手間で動くということが重要。

そういう必要性も年々減って、いずれ無くなってしまうでしょうね。

SPARCが将来的に生き残るには、コストパフォーマンスでぶっちぎる
ような真剣勝負で戦い抜かないと。富士通は勝っていけるかな。

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 22:52:21

Nehalem EXが出ればSPARC終了だよ
後はメインフレームみたいにニッチ市場で細々売ってくだけ
それもいつまで続くことやら

**名無しさん＠お腹いっぱい。** · 2009/05/31(日) 23:17:28

>>718
世の中フリーソフトだけで成り立ってると思ってるの？

**,,・´∀｀・,,）っ-○○○** · 2009/06/01(月) 00:38:18

ディレイスロットってそれ自体がパイプライン段数縛りになるだろ。
クロックを上げるためにステージ細分化するとかのアプローチも採れないし

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 01:39:11

Nehalem EXのページの動画デモを見てる時にサーバ側からの送信が止まったのが受けた
Sunのページの製品CM見てる時は止まったことないのに

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 01:47:21

>>719

そうねえ　北朝鮮がつぶれるぐらいまで続くんじゃない？

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:07:36

>>717
そうだよな。

x86の汚い囲い込みと同じ戦術でSPARCは生き残ってる。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:09:52

>>720
QuickTransitのように、
SPARCバイナリをx86上で動作させる
ってなシロモノが商品化されてるんですよ。

ていうか、OracleはQuickTransit作ってる会社を買収して、Solarisに標準装備させるべき。
x86版SolarisでもSPARCバイナリが走り、SPARC版Solarisでもx86バイナリが走れば、
むしろ逆にSPARCの拡販になりますぜ。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 07:12:16

>>721
そうでもないよ。
ISAとパイプラインは一対一対応している必要はない。

OOO実行するのであれば、
ィレイスロットにある命令は、直前の分岐命令の結果に依存していないって意味でしかない。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 08:22:57

>>725
当然知ってるがAlpha版NTはトランスレータ入れても成功しなかったわけで
むしろx64製品へ移行を促す方向に圧力がかかりそうだ

あと、トランスレータはアプリケーションを動かすだけであって
ホストがサポートできないハードウェアなどはどうしようもない

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 08:36:10

>>725
Transitive社はIBMに買収されQuickTransit製品を終了しました

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 09:22:14

>>727
それは昔の話でさ、最近だと、MacOSが、PPCからx86への移行に成功してるよね。
Alphaの場合、x86との性能差が縮まったのが、失敗の最大の原因だと思う。
その点、SPARCは違う。

x86で64CPUはスケールしないが、SPARCなら64CPUでもスケールするから、
そこには比較できないほどの大きな性能差があるわけで。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 09:39:02

ttp://www.networld.co.jp/transitive/news_over.htm
これか。

品質チェックによる一時休止が本当なのか、
その会社がSPARCの次にPOWERを相手にする可能性を恐れて潰したのか・・・.

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 10:15:34

きっとSunを買収してSolarisに載せるつもりだった

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 12:51:15

>>729
Macはトランスレータだけで何とかしたと思ってるのか？
オーバヘッドを吸収するPowerPCと最新Coreアーキテクチャの性能差と
Universal Binary化の強要を忘れるな

それに高速な64コアを必要とするアプリケーションがどれだけある？
あっても最初からSPARCや他の大規模サーバを選択しているだろう
そこにx64からの移行というマーケットを想定する意味はあるのか？

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 13:20:01

MacOS Xは PowerPCから Intelへの移行どころか、10.4→10.5なんてレベルで
動かんもん続出だし、開発環境に至っては（タダになったのはいいことだが）
OS最新版じゃないと話にもならん。
トランスレーターは話題にはなったけど、使ってるやつなんてほとんど皆無だろw

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 13:32:57

>>730
まさに人類の敵
いい仕事してますね～♪

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:18:50

CPU単体での性能なら現行x86が上だが、64CPU以上の構成だと現行Sparcが上に
なるっていう解釈でいいのかな?
でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージ
があるんだが。
趣味でSparcワークステーションあるがサーバなんて使ったことないからそこら辺
わからない。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:26:18

>>735
＞でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージがあるんだが。

その認識は・・・・

ちょっと、お前64人65脚やってきてみろ

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 15:49:25

信者乙

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 16:44:40

x86は 8ソケットで既にまともに動かんよ。
QPIなら 8コア以上でも性能出る、って話らしいが、実際リニアに性能あがってる
記事どっかにあるか?
SPECrate は要らんからな。あれだけが高い石はエンプラ方面じゃ全く使えんから。

**名無しさん＠お腹いっぱい。** · 2009/06/01(月) 16:58:13

SPARCにはそれしか残ってないもんな
逆に1ソケや2ソケのお手頃価格でそこそこの性能ならSPARCマシンに新規需要はない