[表示 : 全て 最新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/


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++ って感じだったもんなw

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 じゃん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実行するのであれば、
ィレイスロットにある命令は、直前の分岐命令の結果に依存していないって意味でしかない。

727 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 08:22:57 ]
>>725
当然知ってるがAlpha版NTはトランスレータ入れても成功しなかったわけで
むしろx64製品へ移行を促す方向に圧力がかかりそうだ

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

728 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 08:36:10 ]
>>725
Transitive社はIBMに買収されQuickTransit製品を終了しました

729 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 09:22:14 ]
>>727
それは昔の話でさ、最近だと、MacOSが、PPCからx86への移行に成功してるよね。
Alphaの場合、x86との性能差が縮まったのが、失敗の最大の原因だと思う。
その点、SPARCは違う。

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

730 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 09:39:02 ]
ttp://www.networld.co.jp/transitive/news_over.htm
これか。

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




731 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 10:15:34 ]
きっとSunを買収してSolarisに載せるつもりだった



732 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 12:51:15 ]
>>729
Macはトランスレータだけで何とかしたと思ってるのか?
オーバヘッドを吸収するPowerPCと最新Coreアーキテクチャの性能差と
Universal Binary化の強要を忘れるな

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

733 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 13:20:01 ]
MacOS Xは PowerPCから Intelへの移行どころか、10.4→10.5なんてレベルで
動かんもん続出だし、開発環境に至っては(タダになったのはいいことだが)
OS最新版じゃないと話にもならん。
トランスレーターは話題にはなったけど、使ってるやつなんてほとんど皆無だろw

734 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 13:32:57 ]
>>730
まさに人類の敵
いい仕事してますね〜♪

735 名前:名無しさん@お腹いっぱい。 [2009/06/01(月) 15:18:50 ]
CPU単体での性能なら現行x86が上だが、64CPU以上の構成だと現行Sparcが上に
なるっていう解釈でいいのかな?
でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージ
があるんだが。
趣味でSparcワークステーションあるがサーバなんて使ったことないからそこら辺
わからない。


736 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 15:26:18 ]
>>735
>でも、そうなる理由は?単体性能が高ければ64CPU構成でも性能が出るというイメージがあるんだが。

その認識は・・・・

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

737 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 15:49:25 ]
信者乙

738 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 16:44:40 ]
x86は 8ソケットで既にまともに動かんよ。
QPIなら 8コア以上でも性能出る、って話らしいが、実際リニアに性能あがってる
記事どっかにあるか?
SPECrate は要らんからな。あれだけが高い石はエンプラ方面じゃ全く使えんから。

739 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 16:58:13 ]
SPARCにはそれしか残ってないもんな
逆に1ソケや2ソケのお手頃価格でそこそこの性能ならSPARCマシンに新規需要はない

740 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 16:58:52 ]
SparcのOracleベンチはまだですか?

741 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 17:55:10 ]
>>739
だから、WSをx86に奪われた。



742 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 18:21:37 ]
サーバもな

743 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 19:02:25 ]
というか、WSってもう必要ないじゃん
UNIXアプリのWindowsへの移植が終わったんだから
そこら辺のショップブランドのパチョコンで十分

744 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 19:07:04 ]
>>738
Opteronは性能上がるみたいだけど
ttp://connexitor.com/blog/pivot/entry.php?id=191

745 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/06/01(月) 20:22:21 ]
ZFSでファイルサーバ作るためだけにSolarisってよくあるよなー

746 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/01(月) 21:02:57 ]
1万いくらの安鯖にHDD突っ込んでファイル鯖みたいな用途に使うと怖いくらいに似合う。
UPSなしでの突然の電源断でも割と平気だし。


747 名前:名無しさん@お腹いっぱい。 [2009/06/01(月) 21:03:06 ]
>>743
今のWS=ハイエンドx86のPCにOpenGLの高額VGA搭載したもの。


748 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:02:20 ]
普通にゲーム用グラボで間に合うことも多い罠

749 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:07:07 ]
IDC、2009年第1四半期国内サーバー市場動向を発表
www.idcjapan.co.jp/Press/Current/20090601Apr.html

750 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:46:45 ]
>>738
Nehalem-EXがまだ出てないからな。
Intelは今まで中堅以上のサーバはx86では力をいれてなかったんだが、
Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。
まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い
とは言い切れないことは既に明らか。

751 名前:,,・´∀`・,,)っ-○○○ mailto:sage [2009/06/02(火) 00:47:42 ]
Nehalem-EXなら128コア組めるんじゃなかったっけ



752 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:48:51 ]
64CPU以上の企業サーバは市場が小さくて、
そもそも主力だと考えているメーカーはない。

753 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:53:03 ]
サーバはCPU数が多い上位製品ほど、
システムにしめるCPUの部品コストの比重は小さくなる。
64Pや128Pなんて年に何台もでないジャンルなのにCPUメーカーとしては
儲けにならん。
故に、IntelのようなCPU専業のようなメーカーが少ないCPUで高付加価値を
出す方に力を入れてきたのは無理もない。

754 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 00:55:34 ]
SunのサーバのCPU数が多い製品が多いのは、
Solarisのおかげだ。ハードの問題じゃあない。

755 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:07:59 ]
>>751
64コアじゃね?
SMTで128スレッド

756 名前:OOO-⊂(´∀`旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:14:02 ]
hothardware.com/News/Intel-Unveils-NehalemEX-OctalCore-Server-CPU/
>Scalability beyond eight sockets, up to 32-socket implementations can be achieved.
QuickPathは最大32Sだぽ。
まあ、つってもNehalem-EXの実質的なターゲットは殆ど8S以下だと思うが。

757 名前:OOO-⊂(´∀`旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:17:24 ]
QuickPathでも純正は8Sまで、8S超はOEM。

758 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:22:51 ]
グルーレスなのは8Sまでだよ
それ以上はOEMの設計したスイッチが要る

759 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:29:58 ]
SSE速いのが嬉しければIntel買うけど、それ以外ではよー使いませんw

760 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:30:05 ]
8ソケット超はノードコントローラーがいるから
実質8ソケット以下って言っていいでしょ

761 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:33:01 ]
>>758
すまん、被った



762 名前:OOO-⊂(´∀`旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:37:03 ]
ほほ、スマン。
Nehalem-EXが32Sまで対応してるってだけで、QPIでは8Sまでだね。

763 名前:OOO-⊂(´∀`旦⊂☆諫碕 mailto:sage [2009/06/02(火) 01:56:41 ]
>>743
PCアーキテクチャ使い回しのWorkstaion
汎用スカラプロセッサ使い回しのSupercomputer
既に中身の終わったものが言葉だけ残ったんだよ

764 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:58:03 ]
757 名前: 不明なデバイスさん [sage] 投稿日: 2009/06/02(火) 01:34:54 ID:W/lj3Mzf
どなたか、ここのGraphic Media Acceratorダウンロードできた方いらっしゃいますか?
downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=2930&OSFullName=Windows+Vista+32&lang=jpn&strOSs=164&submit=Go%21

Video: Intel? Graphics Media Accelerator Driver for Windows* Vista (22118KB)
15.13.3.1787 2009/05/28


The file that you are trying to download has either been moved, renamed or archived.
Please go to downloadcenter.intel.com and choose your product to find your download.

と、ファイルがなくなっている様なのですが・・・



765 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 01:59:20 ]
758 名前: 不明なデバイスさん [sage] 投稿日: 2009/06/02(火) 01:38:18 ID:VI3z+Aag
英語ページから行っても同じだな
ぬぁーにがNehalem-EXだぁ?w

テメーのところの鯖をまともに管理できるようになってから寝言言いやがれwww


766 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 02:34:16 ]
頭が悪い人による言いがかりの典型例だな

767 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 02:40:19 ]
先日MSDNのサーバーが落ちたわけだが


ぬぁーにがWindows Server 2008 R2だぁ?w

テメーのところの鯖をまともに管理できるようになってから寝言言いやがれwww


とは思わなかったなつまり
マイクロソフトとインテルのクライアント信頼度は違いすぎた

768 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 02:55:22 ]
Win鯖は落ちるのがデフォなので別格だな
MSの鯖を管理してるのはHPだろ?
しかしWin鯖はプリンタ鯖止まりのOS
ぬゎーにがなんてMSに対して怒るとIT技術に対して無知なのかと思われる

769 名前:新米 mailto:sage [2009/06/02(火) 03:01:38 ]
ファイルがない場合のエラー処理も完ぺき
流石Intel

770 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 03:18:39 ]
Intel+MSで鯖とか信頼とかムリッす
こっちからそんなの言いだせません

771 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 03:18:58 ]
また老害たちが集まってきた



772 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 03:24:04 ]
若いコはいい罠
上が許可したとか言い出すんでしょ?

773 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 03:35:21 ]
古いままの知識や見当違いのことを力説する年寄りって・・・

774 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 03:39:07 ]
新しいと思ってるみたいだけど掴まされてるだけの若い子を見ると…

775 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 05:21:08 ]
>>732
データベース。

最初はx86サーバでスタートして、
スケールアップが必要になったらIA64サーバがありますよ
って。

まぁ実際には、サーバの強化が必要になるペースよりも、
x86の性能向上・スケーラビリティ向上のペースのほうが速くて、
x86のままリプレースで桶

776 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 05:26:40 ]
>>735
x86とSPARCで、CPUソケット1つあたりの性能が違うので、
x86の64CPU構成と、SPARCの64CPU構成を比較すること自体に意味があるかどうか・・・。

>>738
へー、Sunは「まともに動かない」ものを製品化して売ってるんだ。ひどいね。

> 実際リニアに性能あがってる記事

へー、SPARCはリニアに性能が上がるんだ。

あんたSPECしか知らんのな。

777 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 05:47:14 ]
>>754
ちゃうちゃう。

UltraSPARCの性能向上が鈍ったので、代替手段としてCPUをたくさん積むしかなかったのさ。
それもSPARC64で解決したので、過去の話。

>>755
Nehalem-EXは8コアだよ。SMTで16スレッド。

>>768
Linuxや*BSDなんかよりは、Windows鯖は、よっぽどスケールするんですがね。


778 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 05:59:55 ]
日本のエンタープライズってさ、
既存のものを上手に組み合わせて自分たちで賢く運用するのではなく、
やたら特注で作らせる。

だから、あんまりWindows鯖の評価が高くない。
ちゃんと使いこなせる技術者がほとんどいない。
なんでも特注で作らせるのは、たぶん、勉強するのが嫌なんだろうな。

そんな日本でも、
ttp://www.kabu.com/feature/system/
こういう会社もあるんだわ。

当初は勘定系のデータベースもWindowsでSQL Serverだったんだが、
ある時期からOracleに変更になったらしい。

社外に作らせるために仕様書を書いたり、検収したりするくらいなら、
自分たちで、VisualBasicで書いちゃったほうが早いよっていう。

ここでVisualBasicを笑った人は、不勉強が過ぎるので反省するように。

779 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 06:16:37 ]
うざ

780 名前:名無しさん@お腹いっぱい。 [2009/06/02(火) 08:00:30 ]
ヴァカめ!!

挨拶が遅れたな。私がエクスカリバーーである!何?「ヴァカめ!!」では無くて「バカめ!!」では無いのか?だと?

ヴァカめ!!

私の伝説は12世紀から始まった。私の伝説を聞きたいか?武勇伝が聞きたいのか?君達はどこから来た?

ヴァカめ!!

誰がコックと言った。
私の職人になるにあたり、守ってもらいたい1000の項目がある。レポート用紙にまとめておいた。しっかりと目を通しておくように。特に452番目の私の5時間に及ぶ朗読会にはぜひ参加願いたい。
私の伝説は12世紀から始まったのだ。私の朝は一杯のコーヒーから始まる。私の午後はアフタヌーンティーにて始まる。そして夜は、パジャマになるに決まっておろう。何故か判るか?

ヴァカめ!!

これだから田舎者は困るのだ。守って貰いたい1000の項目その1「私の朝は一杯のコーヒーから始まる」忘れるで無いぞ。私の伝説は12世紀から始まったのだ。・・・・・ ・・・ ・・ ・

ヴァカめ!!

思考の時間は必要なのだよ。何をするにも、ものを考えずに飛び出すなど愚の骨頂。そう、あれは私が若かった頃の頃だ。一人のスナイパーがいた。詳しくは以下の作品に描かれているので、全て読んでもらいたい。

781 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 09:37:26 ]
>>776
あのなー... x86+MS-Winや x86+Linuxが頭打ちで SPARC+Solarisがリニアに
スケールする、なんて記事は何年も前から数え切れないくらい出てるよ。
馬脚をあらわしたなwww

> あんたSPECしか知らんのな。

どの SPECだよ。SPARCがトップだった SPECか? オレは覚えがないよ。
馬脚 2本めwwwww



782 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 09:40:32 ]
>>778
Basic.. もう死んでたのに、むりやりライブラリーゴテゴテにくっつけて、
Bolandから引き抜いた Pascalの天才張り付けて蘇生させたゾンビのことか?
めちゃ迷惑だよあんな汚ねー言語。

783 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 09:47:17 ]
>>750
> Nehalem-EXからはかなり本気になるので今までの感覚でいると面食らうことになるぞ。

あははははは。そうだな、面食らってみたいわ、期待してるぜ。
ところで、今 MAXで積めるコア数のマシンのスケーラビリティは記事になって
ないのかよ? 教えてくれよ。性能出てねーんじゃねーのw?

まあ、力入れてなかったのを入れたらすぐ性能出ると思ってるとこが
おいたわしいわ。SunOS 4当時に SMP方面力入れるって方針出してから、
実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。
特定の用途には割と早い段階で性能出せてるけど。

> まあ、64CPUなんてのはニッチだし、HPC分野をみればx86だからスケーラビリティが低い

まだ HPCとか言ってんのかよ.. 支離滅裂なんだよ。反論の体裁になってりゃ
なんでもいいのかよ?wwwwww

784 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 09:51:21 ]
やあ、朝から元気がいいね。

785 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 10:30:13 ]
起きるのおせ−よ

786 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 10:39:09 ]
>>781
> あのなー... x86+MS-Winや x86+Linuxが頭打ちで SPARC+Solarisがリニアに
> スケールする、なんて記事は何年も前から数え切れないくらい出てるよ。

そりゃSunの広告記事だからじゃねーの?

違うというのなら、とりあえず1つ例を。
もちろん、Sunや、Sunを担いでいる企業が広告を一切出していない媒体のもので。

そして、x86+Solarisと比較しないあたりが、なんだかなぁ。

> どの SPECだよ。SPARCがトップだった SPECか? オレは覚えがないよ。

SPEC以外のベンチマークの話さ。
なにかとSPECの話ばかりするじゃないか、お前は。

787 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 10:41:00 ]
>>782
俺はVBが大嫌いだし、VB使いも大嫌いだ。
大勢いるVB使いが「勉強したくない!」ってゴネたおかげで、VB.NETで一掃されるはずのものが、一掃されなかったことは、いまでも恨んでる。

だが、だからといってVBが実際に多く使われているという現実から、目を背けることはできない。

788 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 10:52:29 ]
>>783
> SunOS 4当時に SMP方面力入れるって方針出してから、
> 実際広い分野で性能認められるまでだいぶんかかってるけどな。Sunの場合は。
> 特定の用途には割と早い段階で性能出せてるけど。

SunのSMP機で性能が満遍なく出るようになったのって、かなり後になってからだよ。
とにかくシステム全体の実効帯域幅がネックでな。評価してた連中が、顔真っ青だったな。
もっとも、評価せずに導入決めちゃったところよりは、遥かにマシだが。

789 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 12:32:36 ]
で、今は十分に最大構成までスケールする立派な機械ちうわけだw

790 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 12:35:51 ]
需要がないけどな。

791 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 12:59:52 ]
Windows Home Server で十分だよw



792 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:13:40 ]
Home Serverかw
お前んとこって凄い会社だなwww

793 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:17:26 ]
請負の常駐先の話と比較されても・・・

794 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:20:20 ]
>>778
なんでWindowsでSQL Server使ってVBじゃないの?
そこでリプレース先のOSを語らずOracle+VBと出てくることに恣意的なものを感じる

795 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:23:18 ]
>>788
ところが、用途限れば Solaris2.1(SunOS 5.1)あたりから性能出してた。
SunOS 4.1のジャイアントロックがボトルネックになってたところには、
1990年代入ってすぐくらいから性能を出してた。NTTの研究所とかな。

Solaris2.4までは、通常の開発環境としてはめちゃ苦痛なプラットフォームだった
けどね。

796 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:28:24 ]
またNTT研の中の人ですか。営業と仲の悪い。

797 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:29:22 ]
>>786
> もちろん、Sunや、Sunを担いでいる企業が広告を一切出していない媒体のもので。

ぷっ。そんな条件付けるのは、Sun関連ならたくさん見つかるという裏返しだなww
で、ぜんぶインチキベンチなんだな? ほほおー..ww

Sunじゃなくても、そんな指標自分とこ以外から出してるとこなんか
ほとんどないよ。

> なにかとSPECの話ばかりするじゃないか、お前は。

はぁ? HPCがどーのとか言ってるバカと混同してるだろ?www パラノイア症状だなw


798 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:30:40 ]
HPCはハードウェア板のスパコンスレが適当だろ

799 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:32:37 ]
>>796
研究所の人達と営業はなんの関係もないよ。

ひょっとして事業部と仲が悪いと言ってるのか? それも外しまくりだな。
たしかに仕事のやり方はまるで違うが、そもそも接点がない。仲が悪いも何もない。
つーか、その程度の言葉知らんようでは HP関係者ですらない、マタマタマタ聞きの
さらに昔話だろ? もういいよ、とっくに飽きたから。

800 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:33:42 ]
おーーい、QPIでリニアにスケール、って記事はまだかーー?w

801 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:34:34 ]
>>793
比較されたら困るくらいカスいの使ってんのか?あ?



802 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:35:18 ]
こっちは Intelのでも MSのでも Linux/x86のでもいいぞーー
コスい条件は付けんぞー。
さっさと提示しろーwww

803 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:35:35 ]
>>800
パチョコン使いをいじめてやるなってwww

804 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:43:09 ]
ミジンコQPI相手に強がってもしゃーないっすわ
Intel強いのEDAぐらいでしょ

805 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:43:50 ]
>>744
確かに、4コアで完全に頭打っちゃう Xeon5345よりは数値が上がってるけど、
この湾曲ぶりは「リニア」というにはいまひとつだねぇ。
0.9とか 0.8xな係数でほぼ直線でいくぜ、SPARC+Solarisの場合。
このベンチマークってマシン持ってる人やれないのかな?

806 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 13:45:46 ]
>>805
鯖向けに設計したOpteronですらこのレベルなんですわ
x86とSPARCをガチで比較するのは勘弁してやってクリw

807 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 14:06:33 ]
いちいち探すのめんどくさいから、広告でも何でもいいので
SPARCがスケールする記事のリンクをテンプレに入れてくれや。
SPECrate以外で。

808 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/06/02(火) 14:51:21 ]
Try and buyでもなんでもやればいいだろ
他人に探してもらいたいならもっと丁寧にお願いしろや






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前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