Sun Microsystems 最大の字余り

**名無しさん＠お腹いっぱい。** · 2008/06/22(日) 18:35:49

サン・マイクロシステムズや
ああサン・マイクロシステムズや
サン・マイクロシステムズや

（字余り過ぎ）

【前スレ】
SunMicrosystems 最大の探検
http://pc11.2ch.net/test/read.cgi/unix/1207761568/

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 16:17:36

利用者にとっては収めた箱よりもアプリケーション、OSがキモ
アーキテクチャや箱が気になるのは開発者やマニアだけ

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

>>362,363
>>359
> 見れば判ることをいちいち書くな。
該当しますな。サルかとw

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 17:23:10

> 悪貨が良貨を駆逐した好例だね。
SPARC が MIPS を駆逐したなんて初めて聞いたよ。どうしようもない事実誤認ですねw

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 17:32:39

x86 以外の CISC は RISC に駆逐されたと言ってもいいかもね。
x86 も駆逐されればよかったのにw

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 18:25:16

>>365
SPARC搭載のUnix機が、MIPS搭載のUnix機を駆逐した。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 19:31:22

そんな説ないです。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 19:34:50

日本には、EWS4800とかNEWSとか、MIPS搭載機があったろ。
にもかかわらず、Sunのを選ぶのが普通だったろ。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 19:44:24

はぁ... あの、何言ってんですか?

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 19:51:22

Solaris信者がいっぱいいたからな。
Solarisしか使ったことないんでSolarisを選びましょう、そんな話が通用していた時代。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 20:01:36

また偽装ですか? もういいですよ。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 20:07:33

なんでSun信者は、SPARCが奇形だってことを認めようとしないんだ?

そもそもRISCと言えるのか? SPARCは。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 21:03:58

もういいですよ。

**名無しさん＠お腹いっぱい。** · 2008/07/08(火) 21:15:19

>>371
Solaris信者というよりSunOS4信者だな

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 00:58:15

SPARCが奇形ならx86は動くキメラだな
複雑な現実に対応するためにはこちらも複雑にならざるを得ないんだよ
美しいMIPS32が死んだようにね

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 03:14:33

詳しいソースはないんだけど、ITバブル以前までのSUNのシェアはそんな高くない
90年代半ばくらいだと各社乱立
80年代だとVAXのほうが多分多い

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 03:20:29

>>366
RISCに駆逐されたCISCって何？
680x0はどう考えても自滅だし。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 03:29:40

VAX→Alpha
とか

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 08:50:54

>>376
そうやってことあるごとにx86を持ち出すのは恥ずかしいから、やめたほうがいいよ。

x86は酷い代物だかスケールメリットだけで生き残ってると言うのなら、
SPARC vs MIPSもまた、しかり。

>>377
金額ベースだとね。
そもそもUnixが力不足と思われていた時代だし。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 13:22:39

オレは >>376 じゃないけど、SPARC の ISA としての具体的欠点て
明確には何も上がってないぞ。レジスタウィンドウはサードのコンパイラ
（要はGCC）がうまく扱うコードをずっと吐けなかったのと、
某 F社 SPARC64屋（の一部）が「あれのせいでインプリ大変」と言っていたという
状況が提示されてるだけ。実際 Sun のコンパイラだとそこそこ性能出るし、
SPARC64 実装周辺て出がメインフレーム方面で単に RISC ノリに慣れてない
だけかも知んない。それに、メニーコアでレジスタウィンドウが活かせるような
工夫も可能だろうし。

MIPS とでよく比較にあがる遅延スロットの話だけど、確かに今ではあまり
性能的な効き目はないが、実装の負担も相対的にたいしたことないはず。
MIPS は「見越してた」という書き方がされてるが、遅延スロット実装した側だって
効果もないけど実装の手間もたいしたことないのを見越せてなかったわけじゃ
ないと思うが、どうかね?

で、x86 の生き残りがスケールメリット「だけ」とまではさすがに言えないけど、
ISA としての評価は現在では間違いなく「クズ」、だろ。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 13:31:49

MIPSがきれいなのはMIPS IIIまで

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 13:41:47

IA64, SPARC, Am29k
一番成功したのはどれ?

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 13:45:19

>>378
68k はワークステーション用途では RISC に置き換えられた。ほとんど全て。
一部 RISC に移行しようとして果たせず消えたのがあるけど。NeXT とか。
MOT社の後継としての 88k は自滅と言えるかも知れんが、68k は置き換え。
さらに、組込み方面のことまるでご存じないようだが、Z80 はじめほとんどの
CISC CPU は ARM, MIPS, PowerPC, SH 等の RISC に置き換わっている。まさに駆逐。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 13:55:57

>>383
Am29k はプリンターエンジンとして大量に売れた。

SPARC は、ここで説明するまでもないが、Unix WS 用に 20年にわたって
10社以上が製造し出荷されてる。富士通の SPARClite はプリンターやデジカメに
かなり使われた。また、LEON は欧州の宇宙方面、最近では NAS で相当の数が
出ている。

IA64 は... 腕力でゴリ押ししたらこうなってしまうという見本として後世まで
語り継がれるだろう。悲しい。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:03:02

>>381
> 某 F社 SPARC64屋（の一部）が「あれのせいでインプリ大変」と言っていた
> SPARC64 実装周辺て出がメインフレーム方面で単に RISC ノリに慣れてないだけかも知んない。

富士通の技術者を馬鹿にすんな。

SunのSPARCはイン・オーダ実行
富士通のSPARC64はアウト・オブ・オーダ実行

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:07:36

>>384
そーいや８８Ｋなんてのがあったなｗ

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:10:19

>>385
それはAdobeのPostScriptが、Am29k用のバイナリコードで、プリンタメーカーに提供されてたから。

SPARCのレジスタウィンドウの問題点は、
1. グローバルの8本が少ない
2. イン・アウトの8本が多い
3. レジスタウィンドウとメインメモリとの間のやりとりが自動ではない

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:11:07

>>387
モトローラは、68kと88kの両面作戦をやって、どちらも開発が遅れた。
68kだけやってりゃ、もうちょっと延命できたのにな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:21:28

>>384
68kに関して言えば、68040でつまづいて68050がコケて68060は手遅れ。
RISCに駆逐されたというより自滅。原因は >>389 かな。
結果として68kワークステーション後継がRISCになったってのは正しいけど。

8bit組み込みに関して言えば、CPUとして目に見えることがなくなっただけ。
そもそもZ80とARM, MIPSの類を一緒にしてCISC/RISCで区分するのがナンセンス。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:29:03

OpenSPARC (T1?) のコア1個だけのやつってどっかの製品に採用されたりしてないのかねえ。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:29:39

レジスタウィンドウはいいんだけど、ウィンドウをズラすのが8本固定というのが、どうもね。
プロシージャコールの時に任意の本数を即値で与えられるようにすればよかったに。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:57:26

>>390
> そもそもZ80とARM, MIPSの類を一緒にしてCISC/RISCで区分するのがナンセンス。
はぁ? それなら最初からそう言えやすり替え野郎。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 15:59:24

>>390
> RISCに駆逐されたというより自滅。原因は >>389 かな。
88k で両面作戦という判断をさせたのは RISC の台頭。したがって駆逐。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 16:03:26

>>388
> 1. グローバルの8本が少ない
> 2. イン・アウトの8本が多い

それがまさにコンパイラの実装で左右されるとこ。

> 3. レジスタウィンドウとメインメモリとの間のやりとりが自動ではない

...自動にする、ってハード実装ってこと? コアが複雑になるじゃん。
つーか、それ ISA と関係ないのでは? 後付けでもやれるんじゃないの?

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 16:15:37

>>388
> それはAdobeのPostScriptが、Am29k用のバイナリコードで、プリンタメーカーに提供されてたから。

んでは、Adobe は PostScript エンジンをなぜ Am29k に実装したの?

...なんか都合のいいとこだけハショるな。ムリありすぎなんだよ、「捏造」工程にw

RISC でレジスタウィンドウはスタック言語向きなんだなこれが。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 17:01:21

>>396
Am29kのレジスタウィンドウは、SPARCのそれとは大違いだからな。一緒にするな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 17:20:42

>>397
ほえ? 例えばちょっと前までのブラザーの PS 互換プリンターが SPARClite で
非常に優秀な性能だったわけだが。
つーか、PostScript エンジンあたりだとレジスタウィンドウ様様効きまくり、って
感じだと思うが。
レジスタウィンドウの、本数可変とか言うけど、例えば C だとコンパイラが
必要な本数を数えるわけで、それなら SPARC でアウトが 8本固定でも
必要本数以外はローカルレジスタと同等に使えるわけだから、工夫の余地は
あるわけよ。
主記憶への退避も自動化されると却ってソフトウェア側で性能チューニングの
自由度がなくなる。
つーか、そんなに違いが出るなら他の CPU でバンバン採用されてるわな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 17:34:44

>>398
Am29kが終わった後の機種の話をされてもな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 17:40:45

SPARCってどのへんことをスケーラブルって言ってるの?

レジスタを増やしてもバイナリコンパチだってのはいいけどさ、
レジスタを増やすことで性能向上するというのは、
レジスタウィンドウからのトラップ処理に時間を食われまくる
という前提があってのこと。

トラップ処理に要する時間を大幅に短縮してしまえば、
レジスタを増やすことでの性能向上は小さくなってしまう。

で、SPARCはUltraが付くようになってから、
トラップ処理を高速化した。

そこまでやるなら、レジスタウィンドウやめてハードウェアスタックにしちまえよ、と。
ま、中身はハードウェアスタックそのものなんだろうが。

膨大な本数のレジスタがマルチプレクサ経由で演算器に繋がってるとは思えないもん。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 17:54:15

>>399
つまり、同じ ISA のまま改善できた、ってことだろ?
単に最初の頃の実装に改善の余地があった、って話だわな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 18:00:47

>>400
前提が大間違いだな。レジスタウィンドウが溢れない（あるいはほとんど溢れない）
範囲のシステムを想定している。
プログラム規模の小さいシステムには少ないトランジスタ数で、
大きいシステムには深い呼出しのためにウィンドウ数を増やす（＝トランジスタ数も増）。
単純明解。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 18:27:12

>>401
Am29kが終わってから作られたものと、Am29kとを比較するのは、
無印SPARCと今のx86を比較するようなもん。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 18:34:16

>>402
その割りには、SPARCのレジスタファイルの大きさは128本から変ってないな。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:05:55

>>403
いやに食い下がるなww だから、v7 から ISA 変わってないつーにw
なんつーか、わざとやってる?

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:15:58

ISAは変らなくても実装は変ってるな。いろいろと。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:20:55

だから、最初から実装の話なんかしてないだろ。
なんでそんなに Am29k vs 初期 SPARC やりたいわけ? 病気?

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:30:07

同時期で比較しなきゃ意味ないだろ。

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:33:25

ISA って、意味わかる? わざとやってんの? お金もらってんの?

**名無しさん＠お腹いっぱい。** · 2008/07/09(水) 19:55:09

それぞれのISAに対して同時期の技術で実装したものを性能比較しないとな。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 09:29:13

>>386
技術者はいいのかも知れんが、上の判断はどうしようもねーな。
Ita機はフェイクでコケたとこで SPARCでロケットダッシュ、だろうがよ。
いっしょにコケててどーすんだ..
どーすんだ..
どーすんだ..
どーすんだ..
どーすんだ.......

OpenSPARC も富士通あたりが本腰入れてくれなきゃ商業的な立ち上げはなかなか
難しいだろな。せっかくいろいろ持ってんだから資源を活かせよな。
FM-R 諦めたあたりからすっかり弱腰になっちまったな。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 11:44:24

プリンタが優秀かどうかなんてまさに実装の話

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 13:35:30

国際宇宙ステーションの制御ユニットは LEON の 4重化ユニットだそうな。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 13:59:04

CISC/RISC の区別はナンセンス、とか言うけど、>>373,390 みたいに
「原理主義的 RISC」と現実主義的（修正主義的?w）RISC を区別したがる方が
よっぽどナンセンスと思うが。
「原理主義的」で脳内でだけで「美しい」CPU に存在価値なんかないし。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 14:38:18

x86の例を見れば明らかなように、CPU自体の優劣は問題ではない。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 15:28:32

大問題。粗悪な規格の欠点を埋め合わせるために多方面にわたって莫大な資源が
浪費され続けている。
IA-64 を出すにあたり Intel がまさにそう言っていた。x86 は捨て去るべき。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 16:41:15

いくら金つぎ込んでもまるで応用範囲の広がらない駄作 ISA には即退場いただきたい。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:03:09

>>416
そういう話ではなくてさ、
CPU自体の優劣は、その売上や普及とは関係ない
ということ。

SPARCがx86よりも桁違いに性能が良ければ、
かつて生産性を求めてパソコンからUNIX WSへ乗り換えが発生したように、
x86からSPARCへの移行が発生するだろう。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:05:03

>>417
それは具体的には何のことかな。

ちなみにx86の応用範囲は、電卓に毛が生えたパソコンから、かなり拡大してきたと思う。
しかも元々のパソコンの領域では莫大な売上を維持しつつ。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:06:39

応用範囲が広がるどころか縮小しているのがSPARC

デジカメやプリンタ、ワークステーションからは姿を消した。
サーバでもx86に大幅にシェアを食われて姿を消すのも時間の問題か。
メインフレーム置き換え方向に活路を見いだしているが、そこでどこまで頑張れるか。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:32:58

はあ。上に書いたの少しは調べたら? LEON ね。
まあ、反応もだいたい予想つくがな。あんた、ほんっとーにつまんねーな。
まともなアンチはおらんのか?

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:37:14

sparc Niagara の検索結果約 344,000 件中 1 - 10 件目 (0.28 秒)
sparc LEON の検索結果約 95,900 件中 1 - 10 件目 (0.08 秒)

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 17:48:35

>>418
> CPU自体の優劣は、その売上や普及とは関係ない
> ということ。

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

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

あんたバブリーなもんには手出すなよwwww

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 18:46:18

>>421
LEONの採用例が少しあるからって、なぁ。

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

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

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

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

同クラスのプロセス・ダイサイズのx86プロセッサと同じ価格で売らなければ、
その設計の優秀さは、価格が高いのだから性能が良くて当たり前ということになってしまう。
スケールメリットがないから高くなるという事情はわかるが、買う側にはどうでもいいことだ。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 19:36:50

組み込み用途からハイエンドのサーバ用途まで
全部カバーしてるアーキテクチャなんて今あるの？
power?

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 19:40:12

>>424
> トランジスタ数あたりの性能も、消費電力あたりの性能も、x86とは桁違いだ。

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

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

で、「しかたがない」から「巻かれた」方がいい、わけだ。買う側にしたら。
オレにもそうしろって強制したいのか?

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 20:05:17

>>426
そうだな。
SPARCよりもMIPSのほうが優秀だったな。
ISAも実装も。

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

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

宗教や主義主張の話じゃないんだから、巻かれるとかそういう次元じゃない。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 21:18:29

ほえ? MIPS 今でも大量に使われてるが。一時期みたいな勢いはないけど。
それこそプリンターとか。ネットワーク機器とか。PDA 方面で減ったか?
ARM の方がうまくやったなぁ、ここ数年だと。

だから、Infrant のやつが結構出てるちゅーに。NAS で。NETGEAR が買ったみたいだが。
富士通が SPARClite やめただけに過ぎん。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 21:24:29

>>427
> SPARCよりもMIPSのほうが優秀だったな。
> ISAも実装も。

おもしろそうだな。具体的に講釈してくれ。実装だと直交しそうだから ISA の。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 21:25:59

InfrantのNASの採用例を連呼するだけか。

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

まず、コンテキストスイッチが遅い。組込みだと、これだけで嫌われる。
次に、割り込みへの応答時間のバラツキが大きい。これは痛い。
そして、レジスタウィンドウは高度なデバッガがないと、デバッグが難しい。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:13:26

え? そんだけ? MIPS との比較は??? まさか、「レジスタウィンドがない」、...?
連呼はあんただよ。中身ゼロかいww

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:14:03

ひょっとすると Am29k で食い下がってたバカと同一人?

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:16:09

おいおい、アンチよぉ～、きっちししたこと書けないんなら、
せめておもしろいことかけよぉ～。先の展開考えるとかさぁ～。
なんの役にもたたん無機質文バラまいてんじゃねーよ!

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:25:43

3連投乙

同時期のSPARC 40MHzとR3000 33MHzで、後者のほうが速かった。
レジスタウィンドウによる性能向上よりも、レジスタウィンドウにトランジスタを食われないことのほうが重要。

**名無しさん＠お腹いっぱい。** · 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だけになった。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:40:42

SPARCをサポートしたOSは？

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:54:40

大丈夫だ。みんな、きっとJupiterがなんとかしてくれるさ。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 22:55:58

Jupiterなら…。

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 23:00:59

今日もおじいちゃん大活躍か

**名無しさん＠お腹いっぱい。** · 2008/07/10(木) 23:37:07

>>435
SunとSPARCは分析の対象にすらなってないな

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 04:14:21

>>435
> その通りにIA-64をサポートしたUnixはHP-UXとLinuxだけになった。
そんなこと書いてないが？

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

>>440
Solarisのx86版とSPARC版との差異が大きいことが槍玉に挙がってるｗ

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 08:25:54

>>441
> 競争力のあるタイムフレーム内にリリースすることがいっそう難しくなりました。

これは、各社はリリースを断念するでしょう、ってことだよ。
事実、IA-64サポートを発表していた各社は軒並み手を引いた。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 09:14:18

>>442
> > 競争力のあるタイムフレーム内にリリースすることがいっそう難しくなりました。
> これは、各社はリリースを断念するでしょう、ってことだよ。

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

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

それは事実だが、その文書でそんなことは述べてない。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 09:36:37

Ita なんかどうでもいいから SPARC vs MIPS の話してよｗ

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 10:18:13

>>443
行間を読め。

アプリ屋がタイムリーにリリースできないってことは、OSをリリースする価値がないってことだよ。
アプリのないOSなんてナンセンスだもの。

**名無しさん＠お腹いっぱい。** · 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の考え方をうまく実現していた、ということだろう。

**名無しさん＠お腹いっぱい。** · 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で負い越されてるし。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 10:58:49

CISCよりクロックの低いRISCなんて・・・存在価値ないだろ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 11:23:48

そうするともはやPOWERくらいしか存在価値ないな

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:07:17

>>447
> MIPSの後塵を拝するSPARCって構図だね。

おいおい... ベンチマークかよ、それじゃ具体性て観点じゃ後退しまくりだろ。
寝てんのか?
やっぱレジスタウィンドウ批判てただの「お題目」に過ぎんな。確信できたわ。根拠ゼロ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:28:51

a

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:37:49

>>447
Mips/SparcよりもPA-RISCの方がトランジスタ効率が良い。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:39:55

何でもかんでも引数をスタックに積むような下手くそな当時のコンパイラに対して、
SPARCは、レジスタウィンドウによってハードウェアで解決しようとした。

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

そして性能比較したら>>447ということになったわけだ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:42:39

つまり、SPARCにおけるレジスタウィンドウは盲腸である。
トランジスタを大量に食うし、コンテキストスイッチのコストを増大させている。

どうりでSunが真っ先にコアをマルチスレッド化したわけですよ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 12:44:03

>>452
PA-RISCはコンパイラがズルしてるので除外すべき。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 14:28:53

>>454
そりゃ一面的な見方だな。レジスタウィンドウが効いてる範囲では
（もちろんそれ想定で設計されてるわけだが）、プロシジャーコールのコストは
激減する。で、それによるコスト軽減がコンテキストスイッチや
ウィンドウ溢れでのコスト増を上回るという判断の上で、採用されてる。
その判断が間違っていることを説明しなけりゃ、なんの批判にもならん。
自明だろ、まともなエンジニアならな。
車高の低い車は凹凸の多い道路には向いてない。そう言ってるに過ぎん。
もっかい言っとこう。『中身ゼロ』。少しはまともな書いてくれんか? 飽きたぞ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 14:36:57

ここんとこは正解だろ？ｗ

＞どうりでSunが真っ先にコアをマルチスレッド化したわけですよ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 14:40:34

>>456
453を読み直してよ。

SPARCは、そういう判断の上で、レジスタ・ウィンドウを採用した。
その判断が間違いだったのは、MIPSの成功によって証明された。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 15:00:42

Drystone MIPS なんぞでコンテキストスイッチやレジスタウィンドウ溢れの
判別できるとでも思ってるのか? 本気か? 前提知識欠落しまくりだよ。
MIPS が大迷惑してるぞ。

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

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

豚に真珠とはまさにこのことだ。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 15:08:58

>>459
思ってねーよ。

むしろ、コンテキスト・スイッチもレジスタ・ウィンドウ・オーバーフローも発生しないので、SPARCに有利。
ま、関数呼出しがインライン展開されるのでプロシージャ・コールのコストが現われないので、MIPSにも有利だが。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 15:29:56

じゃやっぱ『中身ゼロ』ってことだな。いい加減にしろ。
お前ほんとに金もらってやってるだろ。ふざけんな。

**名無しさん＠お腹いっぱい。** · 2008/07/11(金) 15:35:58

>>461
お前、Itaniumスレに出張して荒らしてる人か、相手しちまったよ。