Sun Microsystems 最大の岩望

**名無しさん＠お腹いっぱい。** · 2009/07/10(金) 19:13:24

Rockは出るのか!?

【前スレ】
Sun Microsystems 最期の落日
http://pc12.2ch.net/test/read.cgi/unix/1244286002/

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:20:36

RISC のクロックが伸び悩んでたのはスーパースカラのための命令の依存性のチェックに
手間取るためで、その辺割り切るとクロックは CISC よりあげやすい。Alpha しかり。
Power は 4, 5GHz で x86 より高クロックだと思うが。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:22:20

>>238
昔話をしているんで。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 19:50:48

>>236
g0～g7にしとけよ

あとその例だとレジスタウィンドウ万歳じゃねーの？
今はそういう流れじゃないよ、残念ながら

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:08:24

そのときはそう思ってたんだよ！

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:21:51

>>241
んー、SPARCのレジスタ・ウィンドウよりはIA-64のレジスタ・スタックだな。

まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。
にもかかわらず、IA-64がレジスタ・ウィンドウの発展形を実装したのは、どういうことなんだろうね。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:24:40

レジスタ本数の少ないx86では、スタック操作を高速に行う必要があってさ。
その延長線上で考えると、スタックの先頭をレジスタに割りつけてしまえ、ってなるのさ。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 21:01:14

今夜の官僚たちの夏は「電算機」話だよｗ

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 21:09:18

テレビドラマで勉強しちゃいかんよ。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 10:19:24

>>243
> まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。

実証されてねーよ。実例示してみろ。
レジスタウィンドウが不利な状況があり得る、ということに過ぎん。
状況は時代の変遷でコロコロ変わる。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:22:15

>>247
MIPS

MIPSはレジスタウィンドウを持たないが、しかし、レジスタウィンドウを持つプロセッサよりも速かった。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:29:48

>>248
...でさ、その速ぁ～い MIPSが出た後で、レジスタウィンドウを持つプロセッサーが
出てないのか?
オマエ真性だなwwww

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:31:13

MIPS MIPS言ってるバカは、MIPSをおとしめるためにやってるんだろうな。
技術的な話なんか一切ないしな。セコいやつだな。恥しくないんかね、人として。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:32:47

>>249
それは、SPARCにバイナリ互換を切れと言ってるのか?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:33:38

>>250
はいはい、ファビョらない、ファビョらない。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:34:20

>>249
レジスタウィンドウを持つプロセッサーで最新なのは・・・痛ニウムだな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:40:56

現存でレジスタウィンドウを持つもの
SPARC
IA64

持たないもの
ARM
x86

レジスタウィンドウを持たないほうが主流だね。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:42:58

SPARCやi960のレジスタウィンドウには欠点があり、am29kはそれを解決していた。
しかしSPARCのレジスタウィンドウは、am29kのようなものに改善されなかった。
なぜか。バイナリ互換が損なわれるから。

SPARCのアーキテクチャがイマイチだっていうのは、もう明らかなんだよ。
でも、バイナリ互換のために、使い続けているんだよ。
それはx86も一緒だな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:15:32

なんの証左にもなっとらん。MIPS使うやつって、アホやねんな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:18:16

>>255
MIPSの後で Alpha出たよな? で、その技術構成要素の差は全て「劣悪」て
ことになるのかよ。幼稚園児かおまえは。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:25:30

レジスタウィンドウの話は繰り返し繰り返し出てるが、具体的な問題点は
一度も明示されたことはない。
今回のは特に、話にならん。
ない、ってことだな、要するに。
「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。
そんなもん初期の設計時点からわかりきったことで、トレードオフ検討した上で
メリットありと判断してるから盛り込んである。

おいアホ、少しはまともな理由付けをしてみろ。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:36:35

>>258
ねえねえ、>>254が見えてないの?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:38:54

>>256
>>257
アホだの幼稚園児だのとレッテル貼りしなきゃならんほど、ぐうの音もでないのか。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:40:56

>>257
意味不明。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:43:21

>>258
> 「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。

あんたが認めたくなくてアホ話と言ってるだけで、それが具体的な問題点だよ。

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

こういう FUDのたぐいって、やればやるほど自分が支持するものの評価が
下がって行くんだけど、わかんないのかね?
どうせ「おつむよわい」ってここでさんざん言われてるやつだと思うけど。

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

>>262
それは技術の一側面を表してるだけで、問題点の実証でもなんでもない。
第一、それを上回る手続き呼出しの高速化というメリットがある。

ほかに何もあげられないんだな、問題点。みじめなこった。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:34:25

>>264
現実に、SPARCがベンチマークで遅いのは、どう説明するの? 実証ではないと?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:35:51

エンタープr

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:36:41

>>265
...おまえがバカだということばかりが、実証されまくり。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:48:17

昔ならともかく今のソフトウェアはプロシージャコールのネストが深い
8レベル程度では頻繁にトラップが発生する
トラップハンドラ自体は短いのだが、その移行のコストが馬鹿にならん
かといってレジスタを増やすわけにもいかない
レジスタウィンドウの行き詰まりである

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 14:20:12

>>268
あのー.. レジスタウィンドウだとウィンドウ数は実装で好きなように
増減できるんだけど。手続きからの見かけ上のレジスター増やすんじゃなくて。
で、ウィンドウ数増やすのがモロに対策なんだけど。

> レジスタウィンドウの行き詰まりである

何も行き詰まらないんだけど。
そもそも、「8レベル程度では」って、v7とかの頃の話?

＃レベル低～。本気か?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 14:27:22

もうひとつ言っておくと、短に呼出しのネストが深いだけなのが問題じゃなくて、
ウィンドウ数超える深さの行き来が頻繁に起こる場合メリットが相殺されるので
あって、深い段階に行ってもその時のウィンドウ数の範囲内で留まるのであれば
高速化の効果を十分に享受できる。

短い手続き呼出しが瀕出するプログラムにおいても、一概に不利とは言えない。

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

>>270
ウィンドウレジスタがうまく働く場合はたしかにそうなんだけど
平坦にたくさんレジスタ使えるほうがやりやすいよね、
てのがその後の方向性かと

むかしの貧弱なハードでは資源節約のため
細かい関数コールが多かったんだけどね…

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 19:35:36

>>271
> 平坦にたくさんレジスタ使えるほうがやりやすいよね、

ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、
例えばどんな方法?

> てのがその後の方向性かと

そんなことないと思うね。Itaniumは?
むしろ舞い戻ってきつつあるのがトレンド。>247に書いたとおり、
どういう手法が有利かは状況によって変わっていく。

> むかしの貧弱なハードでは資源節約のため
> 細かい関数コールが多かったんだけどね…

またそんな適当なことを。
オブジェクト指向言語が普及して手続き呼出しのネスト具合は深くなる傾向だろ。
昔は資源節約で細かい関数コールだぁ? ウソこけ。C言語でそんな配慮して
書いてたなんていう事実はない。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 22:43:45

突っ込んでほしいのか

Itaniumがトレンドって、どこのトレンドだよ！

多段にネストした手続きって、ウィンドウレジスタ有利前提かよ！！

つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ！！！

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 22:49:20

そんな時代に生まれなくって良かったと
心からそう思う今日このごろです

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 00:00:13

今はビットフィールドなんてほとんど使わなくなったしな。
本当にいい時代になった。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 00:12:23

レジスタウィンドウだからOoO実装しにくいの？
それともSunの実装が悪いの？

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 08:24:56

SPARC64はOoOだよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 08:40:48

富士通の実装にはあって、Sunの実装にはない理由はなんでしょう？

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:00:40

>>273
> 多段にネストした手続きって、ウィンドウレジスタ有利前提かよ！！

なるほど。手続きを多段にネストさせないわけだな? そいつはすごい。

...ところで、MIPSの取ってる手法をご披露いただけるかと思ったんだが、
違うんだなww 知らないわけ?プ

> つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ！！！

わはははははははははは。アセンブラで? 商用 RISC以降で? 知識ないんだねw

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:06:27

>>273
> Itaniumがトレンドって、どこのトレンドだよ！

Itanium以降で新しい ISAって、あんまりないと思うけど。
SHくらいじゃない? あとはマイナーなやつしかないでしょ。

そんなにレジスタウィンドウが問題なら、レジスタウィンドウなくした
ISAが新規提案されて意味があるだろうしね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:22:03

>>275
ジャンルによるよね。OSやネットワークプログラミングだと使いまくりだよ。今でも。
ふつーのアプリだと確かに皆無。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 10:14:52

>>280
SH1が 1992年、SH3でも 1995年出荷。
Itaniumは 1994年共同開発を発表、詳細の発表が 1999年だから
SHの方が古いね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:01:53

ちなみに、i960は非常に優秀で売行きも堅調だったが、
DECから StrongARMを入手したことで部隊を PenProに移し、打ち切られる。
Am29kも優秀なアーキで多数出荷されており、後継にスーパースカラーや OoOを
計画されていたが、K5を開発（中身は結構 Am29k）するために打ち切り。

レジスタウィンドウの CPUで自滅したのは正味 Itaだけ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:14:11

米Appleは8月3日（米国時間）、
米GoogleのCEO、Eric Schmidt氏が自社の取締役を辞任すると発表した。
Googleの事業領域拡大でAppleとの競合関係が強まっているためという。
Schmidt氏は2006年8月からAppleの取締役を務めていた。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:52:19

>>272
>　そんなことないと思うね。Itaniumは?

普段はItaniumを貶しておいて、こういうときだけ持ち出すのは卑怯だな。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:04:47

>>269
>　レジスタウィンドウだとウィンドウ数は実装で好きなように増減できる
>　ウィンドウ数増やすのがモロに対策なんだけど。

SPARCの名前のスケーラブルというのは、まさにそれなんだが、
ウィンドウ数を増やすのは性能を上げるためではなく、性能低下を防ぐため。
ソフトウェアに合ったウィンドウ数が「必要」なのであって、誇るポイントじゃない。

> そもそも、「8レベル程度では」って、v7とかの頃の話?

いま13レベルだっけ? どんどんレジスタを増やさないといけないね。

128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
しかも、用途が限られていて、自由に使えるわけじゃない。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:09:57

>>272
> ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、例えばどんな方法?

具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
俺はIEEEの会員じゃないんで、当れない。

で、結論だけは周知なわけで、
MIPSは、そんなに多数のレジスタは必要ない、そこそこの数のレジスタを使いませば良いという話。
同時期のSPARCよりもMIPSのほうがレジスタの数が少ないのは、そういうこと。

> Itaniumは?

あれはレジスタウィンドウというよりはスタックのレベル0キャッシュのようなものだよ。
それを操作する命令は、スタック操作そのものだよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:11:40

>>277
SPARC64のOOO実行は、何か無理をしているって話をどこかで読んだ。

そもそも、RISCにOOOは邪道だ。
1命令を1クロックで実行するのだから、コンパイラが上手に命令を並べれば、OOOは必要ない。
それに、OOOはトランジスタと電力を浪費するので、マルチコア時代には不適切な技術だろう。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:16:19

>>283
> ちなみに、i960は非常に優秀で売行きも堅調だったが、

嘘を付くな。

i960は本来の用途がポシャって、しかたなくI/Oプロセッサとして再利用されたのよ。
メインプロセッサとしてi960が積まれたシステムなんて、ないに等しい。

Am29kが優れていたのは、その通り。x86のために打ち切られたのも、その通り。
そのAm29kよりも劣っていたSPARCが現在まで残っているのは、Sunが固執したからだね。

ていうかさー、ここSunスレなんだよ。i960とかAm29k、少し前にはARMの優秀さを主張していたが、
それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:24:30

ttp://slashdot.jp/comments.pl?sid=78200&cid=271537
レジスタウィンドウとOOOは排他ではないが、しかし、実装が難しい
SunはOOOによる性能向上よりも、クロックを上げることを選択 (OOOはクロックが下がるか、上げにくくなる)
レジスタウィンドウとCMTも排他ではないが、しかし、実装が難しくクロックを上げられない

ってことらしい。
事実、Niagaraシリーズはクロックが低いよね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:30:13

SPARC64 VIはレジスタ128本ではなく156本×2セット
で、デカいです

ttp://journal.mycom.co.jp/articles/2006/12/11/sparc64/index.html
andoさんいわく、
> 富士通のSPARC64 V/VIは、
> IntelのCoreアーキテクチャのプロセサと、概略、同程度の複雑さのプロセサである。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:56:16

>>290

「クロックを上げることを選択」したくせに、富士通がSPARC64で実現したクロックにさえ
追いつけていないが…

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:19:28

>>292
それはSunがダメダメだから。

最先端のプロセッサは、その製造を他社に委託してちゃ、クロックは上げられんのですよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:21:25

>>285
はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?

>>286
はぁ... めんどくさ。仕様上は 32セットまでいけるわな。

> しかも、用途が限られていて、自由に使えるわけじゃない。

意味不明だな。レジスタ足りないの?

>>287
> 具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
> 俺はIEEEの会員じゃないんで、当れない。

あははははははははっははははははははははははははははははははははははははははははははははははははははははははははは

IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー

> で、結論だけは周知なわけで、

とんでもない押しつけ論だな。そういうの「結論ありき」つって常識ある人からは
気嫌いされるんだけど、知らないの?

>>289
いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
i960はきわめて優秀だった。典型的な戦略ミス。

> それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。

レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?

アホ過ぎて話にならんわ。最初から勉強してこいや。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:28:53

>>290
そうだよ。性能上のトレードオフでその都度選択してるだけ。
レジスタウィンドウのメリットを取れば共存の難しい手法を見送る、
別になんの変わったこともない。
他の手法のメリットを取って、レジスタウィンドウの実装にシワよせが来たところで、
わかってやるんならそれもまたいいだろうし。

最初の UltraSPARCは SuperSPARC IIまでの反省をいろいろ盛り込んで
設計されたが、コアのシンプルさを損なうものはできるだけ避けている。

レジスタウィンドウを悪者にしたくてしょうがないバカが 1名いるが、
とてもそんなことを理解できるレベルではない、ということがここまでで
はっきりした。
あまりにバカ話でレベル低すぎるのでもう相手はしない。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:29:54

> あまりにバカ話でレベル低すぎるのでもう相手はしない。

約束を守れよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:31:51

>>294
> はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?

SPARC > Itanium > SPARC
ほら、何かオカシイだろ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:44:26

>>294
> はぁ... めんどくさ。仕様上は 32セットまでいけるわな。

32セットだとレジスタ何本だ? 280本か? 多いな、とてつもなく多いな。

> 意味不明だな。レジスタ足りないの?

その前の行の
> 128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
ってのがあるんだから、レジスタが無駄に余るって話をしてることくらい、わかれよ。

1回のプロシージャコールで、入力8本出力8本ってのは、多すぎるんだよ。
それに、何でもかんでもレジスタ変数にできるわけじゃないしな。

> IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー

その手の論文の投稿先は、たいていIEEEなんだよ。

> いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
> i960はきわめて優秀だった。典型的な戦略ミス。

売れ行きが堅調だってのが嘘なんだよ。
敗者復活戦のI/Oプロセッサ転向前に、いったいどれだけ売れたというのだ?

i860のunixワークステーションはクボタの製品を見たことがあるが、
i960のunixワークステーションなんて見たことないぞ。

> レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?

Am29kのようなレジスタウィンドウが優れているのであって、SPARCのそれはイマイチだって話だ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 15:46:39

>>298
わかった。じゃ、あとは IEEEに出しとくから、IEEEからもらって読んでくれ。

...ぷ .kkkkkkkひーーひーーwwwwwwwww

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:13:23

IEEEって、会長志村けん?

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:53:29

ACM じゃだめかよｗ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:54:55

いえええ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 18:41:02

IEEEれカス

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 21:54:41

自社で半導体工場を持たないメーカーがサーバー向けCPUを開発するのは無理
成功してるメーカーはもう残ってない
SUNはSPARCの開発をやめて富士通に一任すべきだよな

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 22:11:39

富士通も半導体工場持つの止めるよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:02:06

「ムーアの法則の前に投資規模が..」云々いうやつは、Intelでさえ軽く
耐えられないから、何も心配ないよ。
だいいち、サーバー向け CPU作ってる会社が既に数社しかないのに、
以前の方法論当てはめてみたって意味なんかないし。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:09:56

>>299
査読のあるやつに投稿しろな。
査読が通ったら知らせてくれや。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:37:22

IEEEって、論争になった時、卑怯な手に使えるんだね。知らんかった。これは便利

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:48:31

いいかげん見苦しいぞ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 03:01:21

次はセグメント方式ではじまりそうだ。

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 03:37:25

>>310
お前が見苦しいって言われてるの、わかってないでしょ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 08:52:43

>>309
理由は IEEEから入手してくれや。

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 09:00:26

>>310
セグメントは IEEEで禁止されている。作った CPUは回収命令w

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 12:59:35

>>312
>>313
見苦しい連投やめなよ
キチガイだと思われるぞ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 13:25:50

キチガイって、すぐ IEEE言うやつだろ?w

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 13:36:28

連投がなぜ見苦しいのか、
具体的な理由を知りたければ、しかるべき論文に当たるべきだろう。
俺はIEEEの会員じゃないんで、当れない。

で、結論だけは周知なわけで、
連投は見苦しいので、
そんなに多数の投稿は必要ない、そこそこの数の投稿を使いませば良いという話。
オマエよりオレのほうが投稿数が少ないのは、そういうこと。

**名無しさん＠お腹いっぱい。** · 2009/08/07(金) 17:59:08

ノベルと日本IBM、SolarisからLinuxへのサーバ移行プログラムで協業
http://sourceforge.jp/magazine/09/08/06/107206

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

すっかり過疎化しましたな

**名無しさん＠お腹いっぱい。** · 2009/08/18(火) 11:29:05

Software Design 5月号の Les Kohn氏の UltraSPARC, Niagara開発記事、
やっと入手して読んだよ。面白かった、参考になった。
なんで PDF DVD付きの号に載せるかな。一瞬で入手難やんけww

**名無しさん＠お腹いっぱい。** · 2009/08/18(火) 17:09:17

まあ、Afaraが起業時に SPARC選んでる時点でアーキへのイチャモンは却下だな。
IBMで RS/6000やったおっさんが HAL起業した時も SPARCを選んでる。
最も当時オープンな RISCアーキは SPARCしかなかったそうだが。

**名無しさん＠お腹いっぱい。** · 2009/08/18(火) 17:43:04

Cobaltも SPARCつっこみゃよかったのにな。

**名無しさん＠お腹いっぱい。** · 2009/08/18(火) 20:44:46

SPARCは価格競争が進んでおらず、高くても売れる = 参入する価値あり、だろう。
Cobaltは安いプロセッサを使わなきゃならんかったので、SPARCは採用できんかっただろう。

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 09:13:15

「SPARCが」価格競争するの? おつむだいじょうぶ?

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 09:43:06

商用UNIX向けとしては一番安い。というか安っぽいと思う

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 19:12:28

Jupiter+まだー？

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 20:11:32

そのまえに Rock まだー、でしょ。

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 20:28:07

もうRockのことは忘れろよ…

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 22:17:49

Rock死すともSPARC死なず

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 23:33:22

「死せず」の方がいいんじゃないか？

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 23:54:05

>>323は曖昧な日本語が通じないようです。

プロセッサ開発には莫大な費用がかかるわけで、
x86のように薄利多売状態になっているところには、
後発の参入は不可能。

SPARCはプロセッサ自体の薄利多売は行われておらず、
用途によって住み分けも行われており、後発の参入が可能。

**名無しさん＠お腹いっぱい。** · 2009/08/19(水) 23:57:55

世界一売れてるCPUはi8051とそのコンパチ

最近みた例だとデジタルのVRMコントローラに入ってた。
8051だけど、処理能力は50MIPSとか書いてあったな。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 09:49:25

>>330
SPARCが高かったら、他のアーキの CPU使うだろ。
SPARC内での競争が起こるなんて想定は滑稽。

例えば、Sunが hyperSPARC採用する以前の富士通や、当時の互換機メーカーは
複数社の SPARCを選ぶ状況にあったが、SPARCが高けりゃ SPARC機をやめるという
選択肢があった。

曖昧な日本語? ご都合主義もたいがいにしてくれ。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 11:45:48

>>332
あなた、日本語がわからないか、相手の発言を読む気がないのね。

x86ほどの熾烈な価格競争がない = 高い
って読めるだろ、ふつう。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 13:23:59

>>333
そりゃこっちのセリフだ。
そんな比較に意味がない、「SPARC内（という壁の中）での価格競争」など
ありえない、と言ってる。
そんな概念捏造して誘導しようなんざ最低の人間のすることだ。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 13:50:50

あれ、SPARCが高くて価格競争もないから、新規参入しやすいって話じゃなかったっけ。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 13:59:46

そうだよ。

SPARC内での価格競争がないなら、なおさら、参入しやすいね。
事実、富士通は(買収によるとはいえ)SPARC64に後発で参入したしね。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 14:01:53

SPARCが高いからSPARCやめるだと?
アホか。

人はプロセッサで選ぶんじゃない。
ワークステーションあるいはサーバのパッケージで選ぶんだよ。

SPARCが割高だろうと、
それを積んだワークステーションが魅力的ならば、
SPARCを積んだワークステーションが作られるんだよ。

**名無しさん＠お腹いっぱい。** · 2009/08/20(木) 14:04:14

> SPARCが高かったら、他のアーキの CPU使うだろ。

POWERはSPARCより高いけど?
あんたの言うことが正しければ、IBMはPOWER捨ててSPARC64に乗り換えてるだろ。