Sun Microsystems 最大の字余り

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

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

（字余り過ぎ）

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

**名無しさん＠お腹いっぱい。** · 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スレに出張して荒らしてる人か、相手しちまったよ。

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

逆にレジスタウィンドウの効果が出やすいベンチマークとかねえの？

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

そりゃあるさ。

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

>>461
馬鹿につける薬は無いとはこの事

928 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2008/07/11(金) 12:09:51
ばかだなぁ、カネもらったか?
まあがんばれw

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

何がうれしいんだか、このサルは。

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

>>465
ちゃんと Itaスレに解説しといてやったよ、この低能クズが。去ね。失せな。

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

>>467はItaスレを荒らしていることを白状しました。

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

>>467
おいおい、顔が真っ赤だよ。大丈夫か？

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

>>467
血圧には注意しないとダメだよ、おじいちゃん

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 01:47:41

CPUの性能はコンパイラ依存なんだから、GCCの開発チームに金払って
自社CPU用に早いコードを吐くようにしてもらったらどうよ？って思ったら
既にIntelもAppleもSunも金つぎ込みまくってるんだな

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 01:49:09

妄想激しすぎww

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

いまどき、どこでもgccよりマシなコンパイラくらい持ってるって。

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

IA64のバイナリ見たらnopだらけで吹いた

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

gccにすら勝てないコンパイラは生きていくことが出来ないということだったのさ

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 16:56:24

>>474
そういう話、意外と知られてないみたいだな。まあ、Itanium 自体に興味ある人が
少ないってこともあるだろうが。
低能アンチには意味もわからんだろうがなww なんせ「リッチな回路」だからなwwwwwwwwwww
IA-64 にも「リッチな回路」使えばいいのにーーww w ひーw

**474** · 2008/07/12(土) 17:06:24

>>476
リッチな回路って話は、SunのUltraSPARC T2のプレゼンのスライドに書かれている話なんだが。

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

IA-64のnopは、何もしないという命令ではなく、バンドルの余白を埋めるためのもの。

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

毎クロックに6命令を実行ユニットに送るようになっているので、
nopが原因で実行ユニットが遊ぶようなことにはなりにくい。
6命令も同時実行できるほど、現実のコードは甘くない。
(ひたすら直線的に計算する処理は別だが。)

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

>>477
「トランジスタ数が多い」とか「消費電力が大きい」って意味だろな。

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

>>478
> nopが原因で実行ユニットが遊ぶようなことにはなりにくい。
> 6命令も同時実行できるほど、現実のコードは甘くない。

はあ。つまらん言い訳だわな。そこが nop じゃない有意な命令で埋まって
はじめて当初の大言壮語が実現するはずだったわけだろ?
バンドルのうち 5つ nop が頻発するようじゃしょーがねーわなwww

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

なんだ、そんなことも知らんのかぁ...

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 18:01:52

>>479
トランジスタも、消費電力も、そして、開発費も、製造プロセスも、
あらゆる面で多量のリソースを注ぎ込むことで性能を無理やり上げてきたって話ね。

それを一言で「リッチな回路」と言っているのに対して、妙に噛みついてる人がいるんだわ。困るね。

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 18:05:23

>>480
ぷ。

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

1バンドルは3命令だから、1バンドルに5つもnopが入るのは、ありえねー。

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 18:28:50

> そういう話、意外と知られてないみたいだな。

知ったかぶりかよ。

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

>>482
x86の速さの根拠として「リッチな回路」と言ったバカがいたわけでな。
あんたなんかどうかは知らんがw まー、バカでな、これがww

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 18:39:54

>>483
> お前、コンパイラが出力したIA-64のコード見たことないだろ。
ない。
> 1バンドルは3命令だから、1バンドルに5つもnopが入るのは、ありえねー。
そうか。いまさら見る気もない。そこらじゅうに解説してあるから、
つっこんで調べる気もない。死んだ技術だし。本質はずしてなきゃ問題なし。

**名無しさん＠お腹いっぱい。** · 2008/07/12(土) 19:14:36

wwwwwwwwwwwww

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

>>485
遅いはずのx86が速い理由は、スケールメリットでライバルよりも金を注ぎ込んで作ってるからだろ?
それのどこがおかしいんだ?

>>486
少しは無知を恥じろよ、他人に無知だ馬鹿だと言った手前なら。