- 1 名前：名無しさん＠お腹いっぱい。 [2009/05/11(月) 19:40:54 ]
- コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。
「汝自身を知れ」
【前スレ】
Sun Microsystems 最上川上流
pc12.2ch.net/test/read.cgi/unix/1239259163/
- 603 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 18:22:06 ]
- x86の技術的優位性を理解できないほどマヌケだから
会社が他人の手に渡るんだよ
- 604 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 20:10:02 ]
- >>602
↑↑ ほらほら、コイツに向かって。うは、あわれ〜w
- 605 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 20:20:38 ]
- 平日は工作員さんでいっぱいですね。
- 606 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 20:28:04 ]
- 俺ニートだけどむしろ週末に工作員が増える傾向がある
- 607 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 20:45:17 ]
- 飛んで火に入るサル低脳。まさに...
- 608 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/28(木) 22:20:38 ]
- ｳｾﾞｰよ
- 609 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 03:21:33 ]
- >>603
x86の優位性は、Intel工場による製造上の優位性でしょ？
もし、x86とSPARCのアーキテクチャが逆だったら、x86がSunと共に衰退し、
SPARCがIntelの大資本の下で強化されて速く、安く、普及していたはず。
- 610 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 05:52:34 ]
- >>609
ダウト
AMDはIntel工場で生産していないが、しかし、Opteronはそれなりの優位性がある。
- 611 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 09:15:45 ]
- hyperSPARCは順調にクロックを上げつつあったんだな。
それが、SPARCv9 64bitへの移行ということで 200MHzでやめてしまった。
自ら引いたのか横から圧力があったのか宣伝に負けたのかは知らん。
初期の UltraSPARCは確かに競争力あったが、300MHzあたりでクロックが
パッタリあがらなくなった。hyperSPARC共存させて 32bitクロックゲームに
参加してたらどうなってたかというとこ興味あるんだが.. どう思う?
- 612 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 09:20:08 ]
- >>609,610
投下リソースの規模（ケタ）の違いであって、x86アーキ自体は
RISC登場以降はクズでしょ。
>>602
こいつずーーーっとここに貼り着いてるよ? おメメ節穴ですか?w
- 613 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 09:42:38 ]
- >>612だろ、スレに貼り付いてるのは。
Intelと違ってAMDの工場は、数も規模も、それほど大きくはない。
にもかかわらず、K8という優れたCPUを世に送り出してIA64を抹殺し、
Sunにx86採用を決意させたのは、素晴らしいことだと思う。
- 614 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 09:45:32 ]
- >>611
UltraSPARC初代って、当時、64bitはあまり必要とされてなくて、32bitで使ってた。
それでSunがhyperSPARCを潰したのだと思うよ。
UltraSPARCよりもhyperSPARCが売れたら困る、と。
- 615 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 10:00:20 ]
- hyperSPARCはSunではなくRoss→Fujitsuだ。
HAL→FujitsuのSPARC64と競合するので潰されたんだろ
- 616 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 10:08:06 ]
- いま思うと
・Pentiumとの性能比較で微妙だった
・SPARCstationのナンバリングと、性能序列がわかりにくかった
ってこともあって、よく知らない人への訴求力が弱かった。
え? SS20よりSS5のほうが速いの? なんで? とか。
- 617 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 12:04:50 ]
- そもそも初期のUltraSPARCは64bitはアレだったし
- 618 名前：名無しさん＠お腹いっぱい。 [2009/05/29(金) 13:19:17 ]
- Ultra1 の最初のモデルなんかほとんど SPARCstation20++ って感じだったもんなｗ
- 619 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 13:41:09 ]
- >>616
Pentium比では 400MHzくらいまでは UltraSPARCの方が上だったよ。
Slot1とかやってた頃は「やっぱ Intelってダメ会社なんだ」って思ってたし、
PenProはキャッシュ外れると悲惨なデキ損ないだったし。
FC-PGAに戻って、Athlonとクロック競争し出してからだね、性能がよくなったのは。
> え? SS20よりSS5のほうが速いの? なんで? とか。
一般論だと SS20の方が速いけど。何が言いたいの?
積んでる CPUで逆転があるのは別に Sunに限らずそこらじゅうにあるでしょ?
- 620 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 13:44:16 ]
- >>617
バグがあった、というだけ。後の Solarisがそれ嫌ってサポート外しただけ。
他の OSは 64bitで動くよ。Solarisももっと早い段階で 64bit対応できてれば
サポートしてたでしょ。
- 621 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 13:45:01 ]
- >>618
へぇ。後の方のモデルだとそうじゃなくなったの? Solaris使ったこと、ある?
- 622 名前：名無しさん＠お腹いっぱい。 [2009/05/29(金) 14:01:07 ]
- トランジスタ素子を大量に詰め込めるようになったおかげで、命令セットが汚くても
大丈夫になったのどっかのコラムにあったな。
- 623 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 14:01:46 ]
- >>619
> 積んでる CPUで逆転がある
まさに、それが問題だった。
- 624 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 14:02:32 ]
- いくらx86を卑下したところでSPARCの未来は明るくなりませんが
- 625 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 14:09:42 ]
- 卑下というのは自分に対する態度です。
- 626 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/05/29(金) 14:12:11 ]
- 誤用だとわかっているのなら、意図している意味もわかるだろう
- 627 名前：名無しさん＠お腹いっぱい。 [2009/05/29(金) 14:51:16 ]
- >>621
Ultra1 Creator の 200MHz くらいでちょっとマシになったけど、
最初の Ultra1/140MHz なんか TGX で 32bit じゃんｗ
> - Sun Ultra 1 Model 140 TurboGX 2,280,000 円 (税別) [１９９５年１１月１５日]
> （143MHz UltraSPARC、32MB メモリ、1.05GB ディスク、17 インチ・カラーモニタ）
> - Sun Ultra 1 Creator Model 200E 3,670,000 円 (税別) [１９９６年７月３１日]
> （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 は返上か？ｗ
さて、サン・マイクロシステムズ本社において、メールアドレスのドメインの
統合を進めている関係で、これまでご利用いただいておりました、
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 だっけ？
あれが一番よかったなｗ
- 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がでたら買うｗ
- 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と言って馬鹿にするけど
俺らを攻撃するのは反則だし許せない
ってことですねｗ
- 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機が複数台ある
っていう使い方をすれば、性能はでる。
もちろん、スケールしないってことには、
変りが無いが。
|
 |
