[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 15:12 / Filesize : 193 KB / Number-of Response : 809
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Sun Microsystems 最期の神託



1 名前:名無しさん@お腹いっぱい。 [2009/05/11(月) 19:40:54 ]
コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」


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


626 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 14:12:11 ]
誤用だとわかっているのなら、意図している意味もわかるだろう

627 名前:名無しさん@お腹いっぱい。 [2009/05/29(金) 14:51:16 ]
>>621
Ultra1 Creator の 200MHz くらいでちょっとマシになったけど、
最初の Ultra1/140MHz なんか TGX で 32bit じゃんw

> - Sun Ultra 1 Model 140 TurboGX 2,280,000 円 (税別) [1995年11月15日]
> (143MHz UltraSPARC、32MB メモリ、1.05GB ディスク、17 インチ・カラーモニタ)

> - Sun Ultra 1 Creator Model 200E  3,670,000 円 (税別) [1996年7月31日]
> (200MHz UltraSPARC、64MB メモリ、2.1GB ディスク、 20 インチ・カラーモニタ)


628 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 14:51:53 ]
卑下の使い方も知らないほど無教養なのにCPUの優劣を論じるなどおこがましい
と言いたいのでは?

629 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 14:53:57 ]
SuperSPARCは486で
HyperSPARCは5x86で
UltraSPARCはPentium

630 名前:名無しさん@お腹いっぱい。 [2009/05/29(金) 16:17:43 ]
サンからこんなメールが来たー!
いよいよ sun.co.jp は返上か?w

さて、サン・マイクロシステムズ本社において、メールアドレスのドメインの
統合を進めている関係で、これまでご利用いただいておりました、
SDCへのお問い合わせ用アドレスが使用できなくなりました。
恐れ入りますが、今後は新しいアドレスへご連絡をお願いします。

旧)sdc@sun.co.jp
    ↓
新)sdn-japan@sun.com

631 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 16:23:11 ]
>>616
SS20の遅いヤツとTurboSPARCのSS5ならわからんでもないが
microSPARC-IIがSuperSPARC+やhyperSPARCより速いなんてないな

>>620
あの致命的なエラッタって他のOSでは問題なかったの?

>>627
そうやって挙げてる製品をちゃんと使ったことあるのか?

632 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 16:24:34 ]
>>629
素Pen 266MHzと hyperSPARC 125MHz SS20が近い感じだったよ。
触ったことないんだろ?

SPARC 25MHz SS1+と i486DX2-66, SPARC 40MHz SS2と i486DX4 100MHzが
当時だいたい近い、という話だった。

633 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 16:30:37 ]
>>623
あんた一人で混乱してるだけだろ? Sun以外でもなんぼでもあるだろが。
パソコンしか使ったことないやつはこれだから...

>>627
だからさ、その後の UltraSPARC IIだろうが IIIだろうが、速い SS20だろうがよ。
DOS-Winが NT系になったりはしないんだよ、まともな計算機はさ。

TGXで 32bitとか、わけわからんww Sbus積んでりゃどれでも TGXは付くわい。

634 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 16:36:38 ]
>>631
> あの致命的なエラッタって他のOSでは問題なかったの?

OSに回避コードを入れるとパフォーマンスが落ちる。
Solarisが 64bit対応した時は既に UltraSPARC-I はかなり古い CPUに
なってたし、回避コード入れたのを導入されて「遅い」ってクレーム受けるより
入れずにサポート外した方がいいという判断と思うよ。



635 名前:名無しさん@お腹いっぱい。 [2009/05/29(金) 16:43:05 ]
>>631
SS5/170 だっけ?
あれが一番よかったなw

636 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 16:47:55 ]
なんだか一人必死なやつがいるな。

637 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 17:07:07 ]
SS2か
マヨネーズの中を泳いでるみたく遅かったな

638 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 17:20:20 ]
なあに、Sun3に比べりゃ天国よ。
一時期DECstation 3100に浮気したくらい、Sun3はトロかった。

639 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 17:28:55 ]
SS2っつったら、般人が 80286 16MHz の PC-9801RXで EMSで拡張ドライブして
バグバグの一太郎4使ってた時代だからな。80386の 9801RAも出てたが、
高い機種だった。
めちゃ速かったよ。そんな賞味期限とっくに過ぎてジャンク屋から買って来た時の
話されたってな。

640 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 17:37:52 ]
ハ-ドディスクが普及しはじめたころか
当時は、40MBでWin95とLinuxを余裕でデュアルブートで使えてた
今となっては不思議

641 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 17:49:39 ]
9801RXは 12MHzだな。MS-DOS 3.3。米国だと当時もう MS-DOS 4.0が出てるが。
16bit www

642 名前:名無しさん@お腹いっぱい。 [2009/05/29(金) 18:00:41 ]
>>639
チョウの写真や北斎の波がウィンドウの中をナナメにスライドしまくるデモ見て
心底感動したよ、当時。NeWSのデモ。

643 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 19:04:26 ]
昔話は盛り上がるねぇ。今の話はさっぱりだけど。

644 名前:名無しさん@お腹いっぱい。 mailto:sage [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なら話は別。あれは後方互換用で、旗艦じゃない。



645 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 19:42:24 ]
世界征服を企むエリソンは 2つのことをやると思うよ。

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

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

646 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 19:59:26 ]
まずはMySQLをOraSQLに改名すると思う

647 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 20:02:40 ]
>>645
3. Appleを買収して Macを SPARCベースにして MacOSのコアを Solarisに置換る

648 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 20:24:03 ]
>>643
そりゃ、お通夜だからな

649 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 20:31:00 ]
ご焼香はこちらです

650 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 21:03:25 ]
>>647
お弁当箱再びってことでSPARCminiがでたら買うw

651 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 21:44:29 ]
アポーを買収するためにはジョブズを暗s(ry

652 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 22:48:49 ]
>>651
ジョブスとエリソンは親友じゃなかったか?

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

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

653 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 22:56:15 ]
これでAppleも一緒になったら勝てる・・・かな・・・

654 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 23:03:56 ]
Appleと一緒になったら俺は見限る



655 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 23:06:10 ]
勝つる!

656 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/29(金) 23:15:12 ]
暗黒面に飲まれちゃだめだ

657 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 00:51:19 ]
>>639
98なんかと比較するなよ。
比較するならMacにしろよ。

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

その発想はなかったわ。

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

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



658 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 09:46:50 ]
NVIDIAに買收される
それが幸せだ


659 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:04:10 ]
>>657
Macと比較するとそんなに違うか? IIfxとか IIcxあたりかな。68030。
SS2の方がブッチギリで速いよ。

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

660 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:07:07 ]
>>659
> Macと比較するとそんなに違うか?

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

661 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:24:43 ]
>>659
IIfxなんぞで 20inch級モニターとそれなりの装備したら SS2よりずっと
高かったよな。まあ、日本だけなんだろうがw

662 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:27:13 ]
当時の98なんて、

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

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


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

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

663 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:40:07 ]
だけど「x86の技術的優位性」>603 とか言うバカに言って聞かせてやってる
わけだから、x86じゃないとな。

664 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:43:30 ]
>>662
OKじゃねえーよw
XENIX on PC98-FAとか、A/UXなら比較していいけど。



665 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:44:04 ]
>>662
もちろん、「住む世界が違いすぎる」のを示すのが目的なわけでw

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

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

666 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 10:53:10 ]
あのころのMacの日本価格は当時のレートを考えても高かった。

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

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

667 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 11:29:07 ]
>>663
おいおい60レスも前じゃないか。

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


668 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 11:30:27 ]
>>664
PC98-FAってなんだ?

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


669 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 11:31:35 ]
XENIXとかPC-UXとかOS/2とか、そんなマイナーなものを持ち出してもなぁ。

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


670 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 11:35:21 ]
勝てば官軍、負ければ賊軍 w

671 名前:,,・´∀`・,,)っ-○○○ mailto:sage [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ですな。

672 名前:名無しさん@お腹いっぱい。 [2009/05/30(土) 12:00:55 ]
その昔、SUNのSparc-WSを欲しいと思っていた。速いし物めずらしいから
しかし、なんだかんだ言って自作PCで満足してしまい去年の末中古で
Sparcマシンを買ったが「こんなもんか、、、」という感じで拍子抜け
した。
PCがDOSの頃に無理してでも、Sparc-WS所有していたらその違いに
感動したかもしれない。

673 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/05/30(土) 12:05:05 ]
ただ、組み込み向けだと2バイト命令長のほうがコード密度的に都合がいいかなと

674 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 13:39:01 ]
>>671,673
無理無理ww 「盲信」以外に彼には何もできませんので。
ましてや「トレードオフ」なんて言ったらアタマから火花とケムリが飛び散りますww



675 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 13:42:54 ]
SPARCマシンは自宅で使うには消費電力が高すぎる
UltraSPARC IIですらAthlonXPの2倍近い品

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

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

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

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

677 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/05/30(土) 14:00:51 ]
コアを増やしても同期のオーバーヘッドなんかもあるし、それほどうまくは性能上がらないでしょ
CPUに対してメモリやストレージはボトルネックになるし

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

678 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 14:17:43 ]
>>677
> ..、それほどうまくは性能上がらないでしょ

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

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

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

679 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 14:27:04 ]
お、例の人きたねえ
団子ちゃんは相手してくれるかな?

680 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 14:48:29 ]
コネクションマシンはどこへ逝った。

681 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 15:46:46 ]
>>678
並列化には、アムダールの法則という壁があるんですよ。

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


682 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 16:13:14 ]
この文脈で「アムダールの法則」は外しまくりだって、さっさと気づけよ...

683 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 16:17:37 ]
Xeon最強!
SPARCイラネ!

684 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 16:38:38 ]
>>682
SPARCとて例外ではありませんぞ。



685 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 16:40:09 ]
>>683,674
ほらみろ、火花とケムリが吹き出しまくってるぞww もうすぐ爆発するなw

686 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 16:49:31 ]
草を生やしてる人は、団子さんの意図がわかってないんじゃないか?

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


687 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 17:31:36 ]
>>686
そりゃ違うだろ。>671 の

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

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

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

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

688 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 17:47:51 ]
俺らはCISCと言って馬鹿にするけど
俺らを攻撃するのは反則だし許せない
ってことですねw

689 名前:名無しさん@お腹いっぱい。 mailto:sage [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

690 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 18:41:31 ]
今更SPARCなの?(笑)

691 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 19:02:31 ]
つまんない
おもしろいネタないの〜?

692 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 19:11:29 ]
じゃあ、SPARCのブランチ命令のディレイスロットについて語ろうぜ

693 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 19:15:58 ]
>>689
どうでもいいけどコンマ区切りの引用は対応していない2chリーダーもあるので
>>681
>>684
としてほしいです


694 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 22:22:34 ]
今どき RISC vs CIS Cかよw
思い出を語るスレだから、いいのか・・



695 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 23:09:37 ]
通夜だからね

696 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 23:30:29 ]
じゃあ、emacs vs viとかもあり?w

697 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 23:49:18 ]
変態emacsなどの出る幕ではない。

698 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/30(土) 23:59:11 ]
>>696
そんなもんEmacs18やVim3の頃が、良かったって話にしかならねぇよ

699 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 01:11:47 ]
>>696
viの圧勝で結論出てるじゃん。emacs使ってる奴なんて馬鹿ばっかだろ。

700 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 01:43:35 ]
利用シェルならさらに対立が見られそうな気がする

701 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 01:46:50 ]
>>698
そこでなぜvimが出てくる

702 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 07:47:42 ]
>>687
RISCってのは、
・コンパイラを前提にする
・定量的なアプローチ
この2つが命。

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

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

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

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

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

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

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

703 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 07:54:16 ]
>>689
お前さ、
Intelの10年後くらいの先の希望的な話
を持ち出してばかりだけどさ、
俺達、
現実の話してるんだよ。

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

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

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

704 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 07:57:51 ]
>>692
遅延スロットは素晴らしいアイデアで、実際に役に立ってるじゃないか。

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

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



705 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 08:42:38 ]
終わっちゃったことなのにむなしくないですか?

706 名前:60 mailto:sage [2009/05/31(日) 09:34:08 ]
>>702
> とくに、一時期のクロック鈍化・キャッシュ増量のみの時代が、RISCにもあったよね。

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

707 名前:名無しさん@お腹いっぱい。 [2009/05/31(日) 12:56:44 ]
>>702
バイナリ互換無視したら、コード資産が無駄になる。
x86と最も差があった時点で5倍ぐらい。
486以降Risc手法を取り込んできたx86に対しバイナリ互換無視でも
どこまで性能差を付けれたかのかな?


708 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 13:27:40 ]
>>706が何を言いたいのか、わからん。
だれかエスパーで解説してくれ。

709 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 13:28:44 ]
>>707
コード資産?
x86信者みたいなこと言うなよ。

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

710 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 13:30:52 ]
>>707
スケーラビリティのあるアーキテクチャなら、
使えるトランジスタが増えた分を、キャッシュではなく、マルチコアに振り向けられるだろ。

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

711 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/05/31(日) 13:52:07 ]
>>709
そうだな、そういう出来るプログラマのおかげでローエンドはSPARCからIntel CPUへの移行が
すんなりうまくいったわけだ。

712 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/05/31(日) 13:58:04 ]
つまりSPARCもまたバイナリ互換が捨てられない出来損ないプログラマの為に存在するんだなwwww

713 名前:名無しさん@お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 15:13:08 ]
手元にコードがあるものばかりじゃないでしょ

714 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/05/31(日) 19:01:50 ]
もちろん皮肉

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



715 名前:名無しさん@お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 20:21:40 ]
禿げ、デブ、共産主義の三重苦

もちろん皮肉

716 名前:名無しさん@お腹いっぱい。 mailto:sage kani? [2009/05/31(日) 20:22:35 ]
共産主義よかバイナリ非互換の方が良かったか?w

717 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 22:13:05 ]
>>709
SPARCが生き残ってる最大の理由はコード資産。
過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
一定の手間で動くということが重要。

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

718 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 22:35:58 ]
>>717
>過去のプログラムが移植性の有無に関わらず、そのまま、あるいは
>一定の手間で動くということが重要。

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

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

719 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 22:52:21 ]
Nehalem EXが出ればSPARC終了だよ
後はメインフレームみたいにニッチ市場で細々売ってくだけ
それもいつまで続くことやら

720 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/05/31(日) 23:17:28 ]
>>718
世の中フリーソフトだけで成り立ってると思ってるの?

721 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/06/01(月) 00:38:18 ]
ディレイスロットってそれ自体がパイプライン段数縛りになるだろ。
クロックを上げるためにステージ細分化するとかのアプローチも採れないし

722 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 01:39:11 ]
Nehalem EXのページの動画デモを見てる時にサーバ側からの送信が止まったのが受けた
Sunのページの製品CM見てる時は止まったことないのに

723 名前:名無しさん@お腹いっぱい。 [2009/06/01(月) 01:47:21 ]
>>719

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

724 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 07:07:36 ]
>>717
そうだよな。

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




725 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 07:09:52 ]
>>720
QuickTransitのように、
SPARCバイナリをx86上で動作させる
ってなシロモノが商品化されてるんですよ。

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

726 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 07:12:16 ]
>>721
そうでもないよ。
ISAとパイプラインは一対一対応している必要はない。

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






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<193KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef