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

Sun Microsystems 最大の字余り

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2008/06/22(日) 18:35:49
サン・マイクロシステムズや
ああサン・マイクロシステムズや
サン・マイクロシステムズや

(字余り過ぎ)


【前スレ】
SunMicrosystems 最大の探検
http://pc11.2ch.net/test/read.cgi/unix/1207761568/
0422名無しさん@お腹いっぱい。2008/07/10(木) 17:37:14
sparc Niagara の検索結果 約 344,000 件中 1 - 10 件目 (0.28 秒)
sparc LEON の検索結果 約 95,900 件中 1 - 10 件目 (0.08 秒)
0423名無しさん@お腹いっぱい。2008/07/10(木) 17:48:35
>>418
> CPU自体の優劣は、その売上や普及とは関係ない
> ということ。

そんなことわかってないやつがどっかにいるのか? おじぞうさん相手にでも
しゃべってんのか?
x86 はいっぱい売れてるけど、技術的に劣ってるわな。

あ、売上と普及さえ進んでれば、もっと売上と普及が進めばいい、って言ってんのか?
ゴミだろうがクズだろうが。

あんたバブリーなもんには手出すなよwwww
0424名無しさん@お腹いっぱい。2008/07/10(木) 18:46:18
>>421
LEONの採用例が少しあるからって、なぁ。

>>423
どうも>>416がわかってないようでさ。

> x86 はいっぱい売れてるけど、技術的に劣ってるわな。

そんなことは言わなくてもわかる。

SPARCの設計は素晴らしく、とくにNiagara2は秀逸だ。
トランジスタ数あたりの性能も、消費電力あたりの性能も、x86とは桁違いだ。
だが、そのせっかくの優秀さも、x86と同等のコストパフォーマンスで台無しだ。

同クラスのプロセス・ダイサイズのx86プロセッサと同じ価格で売らなければ、
その設計の優秀さは、価格が高いのだから性能が良くて当たり前ということになってしまう。
スケールメリットがないから高くなるという事情はわかるが、買う側にはどうでもいいことだ。
0425名無しさん@お腹いっぱい。2008/07/10(木) 19:36:50
組み込み用途からハイエンドのサーバ用途まで
全部カバーしてるアーキテクチャなんて今あるの?
power?
0426名無しさん@お腹いっぱい。2008/07/10(木) 19:40:12
>>424
> トランジスタ数あたりの性能も、消費電力あたりの性能も、x86とは桁違いだ。

ここにも事実誤認があるんだが... SPARC が秀逸なんじゃなくて、
RISC が秀逸なんだよ。言い方を変えれば、x86 だけがダメ ISA で、
あとはみなまとも。まともなコアを多数シュリンクしてちゃんと
パフォーマンスを出してる。他の RISC はまだそこに至れていない。
x86 は、そもそもコアがダメ。

> だが、そのせっかくの優秀さも、x86と同等のコストパフォーマンスで台無しだ。

で、「しかたがない」から「巻かれた」方がいい、わけだ。買う側にしたら。
オレにもそうしろって強制したいのか?
0427名無しさん@お腹いっぱい。2008/07/10(木) 20:05:17
>>426
そうだな。
SPARCよりもMIPSのほうが優秀だったな。
ISAも実装も。

ちなみにSPARCを多くのメーカーが実装するのをやめた後も、
MIPSは多くのメーカーが実装して売ってて、広範に使われた。
一時期は年間5千万個も製造されてたとか。
乾電池で動かすようなものまで、64ビットのR4000系のCPUを積んでた。

> で、「しかたがない」から「巻かれた」方がいい、わけだ。買う側にしたら。

宗教や主義主張の話じゃないんだから、巻かれるとかそういう次元じゃない。
0428名無しさん@お腹いっぱい。2008/07/10(木) 21:18:29
ほえ? MIPS 今でも大量に使われてるが。一時期みたいな勢いはないけど。
それこそプリンターとか。ネットワーク機器とか。PDA 方面で減ったか?
ARM の方がうまくやったなぁ、ここ数年だと。

だから、Infrant のやつが結構出てるちゅーに。NAS で。NETGEAR が買ったみたいだが。
富士通が SPARClite やめただけに過ぎん。
0429名無しさん@お腹いっぱい。2008/07/10(木) 21:24:29
>>427
> SPARCよりもMIPSのほうが優秀だったな。
> ISAも実装も。

おもしろそうだな。具体的に講釈してくれ。実装だと直交しそうだから ISA の。
0430名無しさん@お腹いっぱい。2008/07/10(木) 21:25:59
InfrantのNASの採用例を連呼するだけか。

組込みでもUnixが使われるようになった今では、どうでもいい話だが、
組込みでSPARCが嫌われていたのはレジスタウィンドウのせい。

まず、コンテキストスイッチが遅い。組込みだと、これだけで嫌われる。
次に、割り込みへの応答時間のバラツキが大きい。これは痛い。
そして、レジスタウィンドウは高度なデバッガがないと、デバッグが難しい。
0431名無しさん@お腹いっぱい。2008/07/10(木) 22:13:26
え? そんだけ? MIPS との比較は??? まさか、「レジスタウィンドがない」、...?
連呼はあんただよ。中身ゼロかいww
0432名無しさん@お腹いっぱい。2008/07/10(木) 22:14:03
ひょっとすると Am29k で食い下がってたバカと同一人?
0433名無しさん@お腹いっぱい。2008/07/10(木) 22:16:09
おいおい、アンチよぉ〜、きっちししたこと書けないんなら、
せめておもしろいことかけよぉ〜。先の展開考えるとかさぁ〜。
なんの役にもたたん無機質文バラまいてんじゃねーよ!
0434名無しさん@お腹いっぱい。2008/07/10(木) 22:25:43
3連投乙

同時期のSPARC 40MHzとR3000 33MHzで、後者のほうが速かった。
レジスタウィンドウによる性能向上よりも、レジスタウィンドウにトランジスタを食われないことのほうが重要。
0435名無しさん@お腹いっぱい。2008/07/10(木) 22:36:10
ttp://download.microsoft.com/download/5/f/9/5f9573a3-121e-400a-8d34-ce6d4382098e/NT_UNIX_on_Application_Development.doc
> UNIXベンダ数社はMercedへの対応計画を発表しましたが、
> そのためには現在のカーネル、デバイス ドライバ、およびツールのインプリメンテーションに大々的な変更
> を加える必要があります。
> 最近、Mercedの公開時期が遅れるという発表がありましたが、
> このために、これらのベンダはMercedへの移植作業を当初よりも遅れて開始せざるをえません。
> このため、アプリケーション開発者にとっては、Merced上のプロダクトを、競争力のあるタイム フレーム内に
> リリースすることがいっそう難しくなりました。

マイクロソフトの分析は当ったな。
その通りにIA-64をサポートしたUnixはHP-UXとLinuxだけになった。
0436名無しさん@お腹いっぱい。2008/07/10(木) 22:40:42
SPARCをサポートしたOSは?
0437名無しさん@お腹いっぱい。2008/07/10(木) 22:54:40
大丈夫だ。みんな、きっとJupiterがなんとかしてくれるさ。
0438名無しさん@お腹いっぱい。2008/07/10(木) 22:55:58
Jupiterなら…。
0439名無しさん@お腹いっぱい。2008/07/10(木) 23:00:59
今日もおじいちゃん大活躍か
0440名無しさん@お腹いっぱい。2008/07/10(木) 23:37:07
>>435
SunとSPARCは分析の対象にすらなってないな
0441名無しさん@お腹いっぱい。2008/07/11(金) 04:14:21
>>435
> その通りにIA-64をサポートしたUnixはHP-UXとLinuxだけになった。
そんなこと書いてないが?

その古文書は、
アプリケーションを Windows NT ベースで開発しておけば
別のプラットフォーム(含Merced)にもすぐ対応できる、
とMSが主張しているだけの内容。

>>440
Solarisのx86版とSPARC版との差異が大きいことが槍玉に挙がってるw
0442名無しさん@お腹いっぱい。2008/07/11(金) 08:25:54
>>441
> 競争力のあるタイム フレーム内にリリースすることがいっそう難しくなりました。

これは、各社はリリースを断念するでしょう、ってことだよ。
事実、IA-64サポートを発表していた各社は軒並み手を引いた。
0443名無しさん@お腹いっぱい。2008/07/11(金) 09:14:18
>>442
> > 競争力のあるタイム フレーム内にリリースすることがいっそう難しくなりました。
> これは、各社はリリースを断念するでしょう、ってことだよ。

その部分は「アプリケーション開発者にとっては」って書いてあるでしょ。
さらに前後も読めば、UNIX上でアプリケーションを開発する場合の話だとわかる。
Windows NT の利点の説明の一部。

> 事実、IA-64サポートを発表していた各社は軒並み手を引いた。

それは事実だが、その文書でそんなことは述べてない。
0444名無しさん@お腹いっぱい。2008/07/11(金) 09:36:37
Ita なんかどうでもいいから SPARC vs MIPS の話してよw
0445名無しさん@お腹いっぱい。2008/07/11(金) 10:18:13
>>443
行間を読め。

アプリ屋がタイムリーにリリースできないってことは、OSをリリースする価値がないってことだよ。
アプリのないOSなんてナンセンスだもの。
0446名無しさん@お腹いっぱい。2008/07/11(金) 10:41:21
>>444
MIPS R4000が、33MHz駆動で27MIPSを出していた。
SPARCは40MHz駆動で22MIPSしか出なかった。

これは、同じことをするのに、SPARCは約2倍の命令が必要ということを意味している。
それ自体は(命令コードが肥大化することを除けば)悪いことではない。
2倍の命令が必要でも、2倍のクロックで動作すればいいのだから。
しかしSPARCはR4000の2倍の周波数では動作しない。

動作周波数は、おおよそ、パイプラインの各ステージで通過するゲートの数できまる。
大雑把に、通過するゲート数が半分になれば、2倍のクロックで動作するようになる。
ステージで通過するゲート数は、1命令で行う処理の各ステージでの内容量によって
決まってくるが、それはISAのデザインによるところが大きい。

SPARCよりもR4000のほうが、RISCの考え方をうまく実現していた、ということだろう。
0447名無しさん@お腹いっぱい。2008/07/11(金) 10:58:01
ttp://www.ssken.gr.jp/lib/nl/2003/sci/2/doc31_1.pdf
6ページ目(スライド12枚目)

R3000、1987年、25MHz、SPECint 17.6、SPECfp 15.1、パイプライン5段、1issue
SPARC、1988年、25MHz、SPECint 12.3、SPECfp 11.6、パイプライン不明、1issue
R4000PC、1992年、100MHz、SPECint 39.7、SPECfp 46.8、パイプライン8段、1issue、1.35Mトランジスタ 184mm2、0.8umプロセス
R4000SC、1992年、100MHz、SPECint 54.5、SPECfp 68.5、パイプライン8段、1issue、1.35Mトランジスタ 184mm2、0.8umプロセス
SuperSPARC、1993年、40MHz、SPECint 52.6、SPECfp 64.7、パイプライン8段、3issue、3.1Mトランジスタ 256mm2、0.8umプロセス
Pentium、1993年、66MHz、SPECint 60、SPECfp 55、パイプライン5or8段、2issue、3.1Mトランジスタ 294mm2、0.8umプロセス

MIPSの後塵を拝するSPARCって構図だね。
しかもSuperSPARCはMIPSの2倍以上のトランジスタを使ったのに負けてる。
同じくトランジスタを多量に使った力任せのPentiumにもSPECintで負い越されてるし。
0448名無しさん@お腹いっぱい。2008/07/11(金) 10:58:49
CISCよりクロックの低いRISCなんて・・・存在価値ないだろ。
0449名無しさん@お腹いっぱい。2008/07/11(金) 11:23:48
そうするともはやPOWERくらいしか存在価値ないな
0450名無しさん@お腹いっぱい。2008/07/11(金) 12:07:17
>>447
> MIPSの後塵を拝するSPARCって構図だね。

おいおい... ベンチマークかよ、それじゃ具体性て観点じゃ後退しまくりだろ。
寝てんのか?
やっぱレジスタウィンドウ批判てただの「お題目」に過ぎんな。確信できたわ。根拠ゼロ。
0451名無しさん@お腹いっぱい。2008/07/11(金) 12:28:51
a
0452名無しさん@お腹いっぱい。2008/07/11(金) 12:37:49
>>447
Mips/SparcよりもPA-RISCの方がトランジスタ効率が良い。
0453名無しさん@お腹いっぱい。2008/07/11(金) 12:39:55
何でもかんでも引数をスタックに積むような下手くそな当時のコンパイラに対して、
SPARCは、レジスタウィンドウによってハードウェアで解決しようとした。

一方MIPSは、コンパイラが適切にレジスタ渡しを行うようにすることで解決しようとし、
レジスタウィンドウを採用しなかった。

そして性能比較したら>>447ということになったわけだ。
0454名無しさん@お腹いっぱい。2008/07/11(金) 12:42:39
つまり、SPARCにおけるレジスタウィンドウは盲腸である。
トランジスタを大量に食うし、コンテキストスイッチのコストを増大させている。

どうりでSunが真っ先にコアをマルチスレッド化したわけですよ。
0455名無しさん@お腹いっぱい。2008/07/11(金) 12:44:03
>>452
PA-RISCはコンパイラがズルしてるので除外すべき。
0456名無しさん@お腹いっぱい。2008/07/11(金) 14:28:53
>>454
そりゃ一面的な見方だな。レジスタウィンドウが効いてる範囲では
(もちろんそれ想定で設計されてるわけだが)、プロシジャーコールのコストは
激減する。で、それによるコスト軽減がコンテキストスイッチや
ウィンドウ溢れでのコスト増を上回るという判断の上で、採用されてる。
その判断が間違っていることを説明しなけりゃ、なんの批判にもならん。
自明だろ、まともなエンジニアならな。
車高の低い車は凹凸の多い道路には向いてない。そう言ってるに過ぎん。
もっかい言っとこう。『中身ゼロ』。少しはまともな書いてくれんか? 飽きたぞ。
0457名無しさん@お腹いっぱい。2008/07/11(金) 14:36:57
ここんとこは正解だろ?w

>どうりでSunが真っ先にコアをマルチスレッド化したわけですよ。
0458名無しさん@お腹いっぱい。2008/07/11(金) 14:40:34
>>456
453を読み直してよ。

SPARCは、そういう判断の上で、レジスタ・ウィンドウを採用した。
その判断が間違いだったのは、MIPSの成功によって証明された。
0459名無しさん@お腹いっぱい。2008/07/11(金) 15:00:42
Drystone MIPS なんぞでコンテキストスイッチやレジスタウィンドウ溢れの
判別できるとでも思ってるのか? 本気か? 前提知識欠落しまくりだよ。
MIPS が大迷惑してるぞ。

MIPS とは - インテル用語集
ttp://www.intel.co.jp/jp/business/glossary/5785812.htm

| ただし dhrystone プログラムはプロセッサーのキャッシュに入りきってしまう
| ほど小さく、またコンパイラーの最適化の程度によってはループの中身が
| ほとんど除去されてしまうなど、プロセッサー性能の客観的な指標として使うには
| 多くの問題があります。

豚に真珠とはまさにこのことだ。
0460名無しさん@お腹いっぱい。2008/07/11(金) 15:08:58
>>459
思ってねーよ。

むしろ、コンテキスト・スイッチもレジスタ・ウィンドウ・オーバーフローも発生しないので、SPARCに有利。
ま、関数呼出しがインライン展開されるのでプロシージャ・コールのコストが現われないので、MIPSにも有利だが。
0461名無しさん@お腹いっぱい。2008/07/11(金) 15:29:56
じゃやっぱ『中身ゼロ』ってことだな。いい加減にしろ。
お前ほんとに金もらってやってるだろ。ふざけんな。
0462名無しさん@お腹いっぱい。2008/07/11(金) 15:35:58
>>461
お前、Itaniumスレに出張して荒らしてる人か、相手しちまったよ。
0463名無しさん@お腹いっぱい。2008/07/11(金) 19:16:43
逆にレジスタウィンドウの効果が出やすいベンチマークとかねえの?
0464名無しさん@お腹いっぱい。2008/07/11(金) 19:32:01
そりゃあるさ。
0465名無しさん@お腹いっぱい。2008/07/11(金) 20:14:11
>>461
馬鹿につける薬は無いとはこの事

928 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2008/07/11(金) 12:09:51
ばかだなぁ、カネもらったか?
まあがんばれw
0466名無しさん@お腹いっぱい。2008/07/11(金) 20:18:47
何がうれしいんだか、このサルは。
0467名無しさん@お腹いっぱい。2008/07/11(金) 20:26:31
>>465
ちゃんと Itaスレに解説しといてやったよ、この低能クズが。去ね。失せな。
0468名無しさん@お腹いっぱい。2008/07/11(金) 20:35:16
>>467はItaスレを荒らしていることを白状しました。
0469名無しさん@お腹いっぱい。2008/07/11(金) 20:49:07
>>467
おいおい、顔が真っ赤だよ。大丈夫か?
0470名無しさん@お腹いっぱい。2008/07/11(金) 22:09:44
>>467
血圧には注意しないとダメだよ、おじいちゃん
0471名無しさん@お腹いっぱい。2008/07/12(土) 01:47:41
CPUの性能はコンパイラ依存なんだから、GCCの開発チームに金払って
自社CPU用に早いコードを吐くようにしてもらったらどうよ?って思ったら
既にIntelもAppleもSunも金つぎ込みまくってるんだな
0472名無しさん@お腹いっぱい。2008/07/12(土) 01:49:09
妄想激しすぎww
0473名無しさん@お腹いっぱい。2008/07/12(土) 11:21:36
いまどき、どこでもgccよりマシなコンパイラくらい持ってるって。
0474名無しさん@お腹いっぱい。2008/07/12(土) 12:27:47
IA64のバイナリ見たらnopだらけで吹いた
0475名無しさん@お腹いっぱい。2008/07/12(土) 12:46:39
gccにすら勝てないコンパイラは生きていくことが出来ないということだったのさ
0476名無しさん@お腹いっぱい。2008/07/12(土) 16:56:24
>>474
そういう話、意外と知られてないみたいだな。まあ、Itanium 自体に興味ある人が
少ないってこともあるだろうが。
低能アンチには意味もわからんだろうがなww なんせ「リッチな回路」だからなwwwwwwwwwww
IA-64 にも「リッチな回路」使えばいいのにーーww w ひーw
04774742008/07/12(土) 17:06:24
>>476
リッチな回路って話は、SunのUltraSPARC T2のプレゼンのスライドに書かれている話なんだが。
0478名無しさん@お腹いっぱい。2008/07/12(土) 17:23:22
IA-64のnopは、何もしないという命令ではなく、バンドルの余白を埋めるためのもの。

バンドルのテンプレートの制約と、
分岐先がバンドルの先頭でなければならないという制約のために、
どうしてもnopが多数挿入される。

毎クロックに6命令を実行ユニットに送るようになっているので、
nopが原因で実行ユニットが遊ぶようなことにはなりにくい。
6命令も同時実行できるほど、現実のコードは甘くない。
(ひたすら直線的に計算する処理は別だが。)
0479名無しさん@お腹いっぱい。2008/07/12(土) 17:27:16
>>477
「トランジスタ数が多い」とか「消費電力が大きい」って意味だろな。
0480名無しさん@お腹いっぱい。2008/07/12(土) 17:32:40
>>478
> nopが原因で実行ユニットが遊ぶようなことにはなりにくい。
> 6命令も同時実行できるほど、現実のコードは甘くない。

はあ。つまらん言い訳だわな。そこが nop じゃない有意な命令で埋まって
はじめて当初の大言壮語が実現するはずだったわけだろ?
バンドルのうち 5つ nop が頻発するようじゃしょーがねーわなwww
0481名無しさん@お腹いっぱい。2008/07/12(土) 17:48:41
なんだ、そんなことも知らんのかぁ...
0482名無しさん@お腹いっぱい。2008/07/12(土) 18:01:52
>>479
トランジスタも、消費電力も、そして、開発費も、製造プロセスも、
あらゆる面で多量のリソースを注ぎ込むことで性能を無理やり上げてきたって話ね。

それを一言で「リッチな回路」と言っているのに対して、妙に噛みついてる人がいるんだわ。困るね。
0483名無しさん@お腹いっぱい。2008/07/12(土) 18:05:23
>>480
ぷ。

他人に低能とか無知とか言っておきながら、お前が無知なんじゃねーか。
お前、コンパイラが出力したIA-64のコード見たことないだろ。

1バンドルは3命令だから、1バンドルに5つもnopが入るのは、ありえねー。
0484名無しさん@お腹いっぱい。2008/07/12(土) 18:28:50
> そういう話、意外と知られてないみたいだな。

知ったかぶりかよ。
0485名無しさん@お腹いっぱい。2008/07/12(土) 18:38:09
>>482
x86の速さの根拠として「リッチな回路」と言ったバカがいたわけでな。
あんたなんかどうかは知らんがw まー、バカでな、これがww
0486名無しさん@お腹いっぱい。2008/07/12(土) 18:39:54
>>483
> お前、コンパイラが出力したIA-64のコード見たことないだろ。
ない。
> 1バンドルは3命令だから、1バンドルに5つもnopが入るのは、ありえねー。
そうか。いまさら見る気もない。そこらじゅうに解説してあるから、
つっこんで調べる気もない。死んだ技術だし。本質はずしてなきゃ問題なし。
0487名無しさん@お腹いっぱい。2008/07/12(土) 19:14:36
wwwwwwwwwwwww
0488名無しさん@お腹いっぱい。2008/07/12(土) 19:43:55
>>485
遅いはずのx86が速い理由は、スケールメリットでライバルよりも金を注ぎ込んで作ってるからだろ?
それのどこがおかしいんだ?

>>486
少しは無知を恥じろよ、他人に無知だ馬鹿だと言った手前なら。
0489名無しさん@お腹いっぱい。2008/07/12(土) 20:23:35
そもそも「リッチな回路」という言葉を最初に使った人の説明は
速さの根拠でもなんでもなく、他の路線が止まってしまったから
こういう路線でも伸びてしまったという否定的な使い方だったと思うんだが。
0490名無しさん@お腹いっぱい。2008/07/12(土) 20:53:03
イカレ信者には、すべてが敵に見えるんだよ、たぶん。
0491名無しさん@お腹いっぱい。2008/07/13(日) 00:13:10
Shrinking Sun under the gun
http://www.theregister.co.uk/2008/07/10/sun_under_gun/
0492名無しさん@お腹いっぱい。2008/07/13(日) 15:43:42
中古辺りでSparcマシン買おうかと検討中だが、買っても単なるPCの代わりに
しかならなそうで迷ってる。
0493名無しさん@お腹いっぱい。2008/07/13(日) 15:47:19
単なるPCの代わりにつかえるならいいじゃないか
0494名無しさん@お腹いっぱい。2008/07/13(日) 15:52:20
>>492
下手すると、単なるPCの代わりにすら、ならんぞ。
0495名無しさん@お腹いっぱい。2008/07/13(日) 15:57:45
下手しなくてもならないよ。。
0496名無しさん@お腹いっぱい。2008/07/13(日) 16:00:23
PentiumII 400MHzくらいのパソコンをゴミ捨て場から拾ってきて、Solaris for x86を入れて使う

これで満足できるようなタイプの人は、産廃ワークステーションでも大丈夫。
0497名無しさん@お腹いっぱい。2008/07/13(日) 16:02:15
じゃあ、ナローバンドルーターの代わりにならなりますかねぇ
0498名無しさん@お腹いっぱい。2008/07/13(日) 16:21:17
なるよ
ブロードバンドルーターのかわりにもならなくもない
0499名無しさん@お腹いっぱい。2008/07/13(日) 16:28:15
>>497-498
動作音や消費電力の点で、代わりになるとは言えないと思う。

自分も最初は古いのをルーター代わりにしてたけど、もう、やろうとは思わない。
0500名無しさん@お腹いっぱい。2008/07/13(日) 16:33:27
492だけど
>>494
一応、Blade2000辺りを検討中
まあ、x86以外のコンピューターハードウェアが欲しいっていうのがあるね。
となると、UNIXワークステーションかPowerMACってことになるけど、ここ
はやっぱりUNIXマシンがいいかなと。

ちなみにUltraSparcV/1.5GhzクラスでSpecCPUベンチの値がPentium4/2.5Ghz
ぐらいと同格みたいだが、体感速度は違ってくるのかな?
例えば
PC⇒Pentium4/2.5Ghz MEM/1GB
Sparcマシン⇒UltraSparcV/1.5Ghz MEM/1GB
の構成で比較したらどうなのかな?


0501名無しさん@お腹いっぱい。2008/07/13(日) 16:39:26
まあ消費電力的には無理だな
0502名無しさん@お腹いっぱい。2008/07/13(日) 16:40:15
>>499
>動作音や消費電力の点で、代わりになるとは言えないと思う。
>自分も最初は古いのをルーター代わりにしてたけど、もう、やろうとは思わない。

動作音や消費電力はハイエンドパーツで組んだ自作PCと変わらないというイメージ
なんだが、まさか耳障りなほど五月蠅て電気を消費するとか?

現在の使用自作PC
CPU Core2Duo-E6750/2.66Ghz
MEM DDR2-6400/4GB
ビデオカード Geforce8800GT/VRAM-512MB

特に五月蠅いとか感じることはない。

0503名無しさん@お腹いっぱい。2008/07/13(日) 16:51:56
もしかして、初めてのUNIX箱?
0504名無しさん@お腹いっぱい。2008/07/13(日) 17:16:49
>>503
UNIXのハードウェア自体は今まで使用したことがない。
0505名無しさん@お腹いっぱい。2008/07/13(日) 17:36:54
>>504
kwsk
0506名無しさん@お腹いっぱい。2008/07/13(日) 17:48:03
>>505
UNIXワークステーション自体は以前から知っていたが、なんだ
かんだで、WindowsPCしか使ったことがない。
一応、高校時代にコンピューター雑誌でSparcStaionやIndyなど
を知ったのがきっかけ。
今まで買おうかと(単純なモノ珍しさで)思ってたが結局買わずに
現在に至る。


0507名無しさん@お腹いっぱい。2008/07/13(日) 17:56:10
そうか
じゃあとりあえず買ってみるのがいいかもね
勉強代勉強代
0508名無しさん@お腹いっぱい。2008/07/13(日) 18:04:04
>>506
自分も高校時代に、雑誌でAlpha登場の記事を読んで、憧れたクチなのだが、
その後に一線から退いた現物を触ったけど、
酢になってしまった酒みたいなもので、ゲンナリだったよ。

実装は汚いが速度と利便性を追求したWindowsのGUIに馴れていると、
ネットワーク透過や分離がしっかりしている代わりにオーバーヘッドで遅い X は、
なんでこんな簡単なことでも描画が遅いの? なんて思う代物かもしれない。

まずはVirtualPCやVMware上でSolaris for x86を使ってみても、いいと思うよ。

0509名無しさん@お腹いっぱい。2008/07/13(日) 18:06:14
>>508
DEC出身のカトラーに謝れ。

WindowsNTは先進的で洗練されてたんだぞ、最初は。
0510名無しさん@お腹いっぱい。2008/07/13(日) 18:42:17
まあAlphaは今でも楽しい64bit境界ライフがあるから
酢になった状態でそれが汲み取れなかったならしょうがないな
0511名無しさん@お腹いっぱい。2008/07/13(日) 18:50:39
>>508
使っていたAlphaマシンの性能はどのくらい?
PCがPentiumVの頃ならAlphaはCPU性能で3〜4倍は上だったはず。
0512名無しさん@お腹いっぱい。2008/07/13(日) 18:56:49
21264vsPIIIの場合、floatだと3倍以上速いけど、intだと倍も速くないはず
windows&x86だとハードウェアGDIアクセラーションで描画もさくさくなんで
Alpha orzだろ
0513名無しさん@お腹いっぱい。2008/07/13(日) 18:58:32
floatが速ければそれでいい
というお話だったのさ
0514名無しさん@お腹いっぱい。2008/07/13(日) 19:25:37
>>512 513
しかし、Alpha以外、、、はfloatさえもPCと大差ないという事態に
0515名無しさん@お腹いっぱい。2008/07/13(日) 19:29:56
>>511
21066Aの233MHz

DECのMultiaっていう小さなPCでね、
会社の廃棄PCのラックに並んでいるのを見つけたので
持ち主の部署の人に言って触らせてもらったんだけど、
ちょっとね・・・。

むかしAlphaServerを使った案件があって、
でも開発用に実機を買えなくて、
とりあえずMultiaで開発やって、最後に、
客に納める品物を検査といって引き止めて
それを使って仕上げるなんていうプロジェクトだったらしい。
0516名無しさん@お腹いっぱい。2008/07/13(日) 19:42:28
うん
Multiaは遅いね
でも233MHz版だからMultiaの中では最速なんだぜ?
でも遅いだろうなあと166MHz版を持っているおいらは思うのであった
0517名無しさん@お腹いっぱい。2008/07/13(日) 20:52:13
昔ATマザーサイズのボード、SPARCやAlphaであったよね
またそういうのでないかな…
0518名無しさん@お腹いっぱい。2008/07/13(日) 21:03:38
ttp://www.supermicro.com/products/motherboard/Itanium/E8870/i2DML-8G2.cfm
これで我慢しとけ
0519名無しさん@お腹いっぱい。2008/07/13(日) 22:52:00
痛ニウムか…OSの手配はどーすんだ
Solaris好きならOpteronで我慢しとくのが吉だよ
0520名無しさん@お腹いっぱい。2008/07/13(日) 23:09:17
LinuxやらWindowsやらFreeBSDやらでいいじゃない
0521名無しさん@お腹いっぱい。2008/07/13(日) 23:16:57
http://page3.auctions.yahoo.co.jp/jp/auction/c172492568

Blade2000のヤフオク
思わず、衝動買いしそうになった。

■ このスレッドは過去ログ倉庫に格納されています