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

Sun Microsystems 最上川上流

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001名無しさん@お腹いっぱい。2009/04/09(木) 15:39:23
五月雨を集めて早し最上川

【意訳】五月雨のように断続的に数々のIT企業を買収して集めても、
業績の下落ぶりはまるで急流のように早く、あとには何も残らない。
【補足】
スレッドタイトルは、一説に最上川上流に不法投棄のゴミが溜まって
いる惨状を某企業の内情なぞらえて詠んだ哀歌とも。詠人不知。

【前スレ】
Sun Microsystems 最大の超新星
http://pc12.2ch.net/test/read.cgi/unix/1233928036/
0836名無しさん@お腹いっぱい。2009/05/09(土) 08:53:26
>>821
Symfowareは、Powergresは、どないすんねん!w
0837名無しさん@お腹いっぱい。2009/05/09(土) 10:06:16
>>835
Rockはスケジュール遅延して、タイムリーに市場に投入できなかったので、ダメぽ。
Itaniumと同じように、現物がユーザーの手に渡る前に、過去のものになるだろう。

> シングルスレッド性能が必要なアプリケーションは存在する

といっても、Oracleにとって重要でなければ、
莫大なコストとリスクがある野心的なプロセッサの開発なんて、
やりたくないだろう。
0838名無しさん@お腹いっぱい。2009/05/09(土) 11:39:42
Rockはもうだめだね。
一応ハイエンドCPUという位置づけだから、今からプロセス変更させようとすると、また設計からやり直しになる。
Niagaraのようなローエンドなら、設計変更を最小限にして、ただシュリンクする戦略でもいけるけど。
0839名無しさん@お腹いっぱい。2009/05/09(土) 11:50:53
OracleDBのベンチマークをとるとT2+の4ソケで、十分な性能が出るんじゃね?
それでも足りないっていうユーザーには、M9000の最大構成でも売っとけばいいんだよ。
0840名無しさん@お腹いっぱい。2009/05/09(土) 12:03:55
Symfoware(笑)
0841名無しさん@お腹いっぱい。2009/05/09(土) 12:37:43
順風満帆というわけでもなさそう

Sun shareholders act to block Oracle deal
http://www.theregister.co.uk/2009/05/08/sun_oracle_court_action/

まあ、ゴネ得を狙ってるだけかもしれんが
0842名無しさん@お腹いっぱい。2009/05/09(土) 12:47:17
まじめに読んでないんで良く分からんけど、こんな記事も

Sun Micro may have violated U.S. bribery law
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=217400083
0843名無しさん@お腹いっぱい。2009/05/09(土) 13:46:43
>>837
Itaは出た結果遅かったんだろが。Rockは遅延しただけでまだ出てないだろ。
ぜんぜんちゃうわい。
そもそも新アーキで遅延せずに出る CPUなんかほとんど皆無だし。
どこのドしろーとだよ。ぬぁ〜にが gdgdだ、おまえが gdgdなんだよ。ゐんで寝とけボケw
0844名無しさん@お腹いっぱい。2009/05/09(土) 13:48:27
>>831
趣旨はわからんでもないが、ピザボックスはもう要らんだろ。CRTなくなったんだから。
iMacと Mac miniにしかならんと思うけど。
0845名無しさん@お腹いっぱい。2009/05/09(土) 13:51:34
>>839
> OracleDBのベンチマークをとるとT2+の4ソケで、十分な性能が出るんじゃね?

そうなるだろな。旧プロセスかつ低いクロックで競争力あるんだから、
そのままシングルスレッド性能がある程度上がるだけでかなりの値が出ると
予想できる。先の性能向上も期待できる。
0846名無しさん@お腹いっぱい。2009/05/09(土) 13:57:18
で、Nehalemに勝てるのか?
0847名無しさん@お腹いっぱい。2009/05/09(土) 14:40:48
その心配は大丈夫
0848名無しさん@お腹いっぱい。2009/05/09(土) 14:41:30
えっ
0849名無しさん@お腹いっぱい。2009/05/09(土) 14:46:13
>>846
たとえ性能でNehalemに勝てなくってもSPARC/Solarisを欲しがる客が
すぐにいなくなるわけじゃないよ
これまでと同様、だんだんと置き換わっていくだけ
0850名無しさん@お腹いっぱい。2009/05/09(土) 14:55:50
次は Fab買うべ。
0851名無しさん@お腹いっぱい。2009/05/09(土) 14:58:01
既にマルチスレッドで性能出るようになってるソフトほど、sun4v + Solarisが有利。
0852名無しさん@お腹いっぱい。2009/05/09(土) 15:08:03
>>846
Bridgeシリーズで SIMD主体に移行するから、旧来の x86なだけのソフトウェアの
性能は停滞する。ソフトウェアが SIMD方面へ移行しなければもう amd64のような
逃げ道もない。
0853名無しさん@お腹いっぱい。2009/05/09(土) 15:10:49
お前まだ居たのかw
0854名無しさん@お腹いっぱい。2009/05/09(土) 15:18:53
Sunに用ないなら来んなよカス
0855名無しさん@お腹いっぱい。2009/05/09(土) 15:35:49
>>852
なんでもかんでもSIMD化できるわけじゃないからSIMD化で
増やした演算器でSMTを強化したりしないかね?
で、命令のデコードがネックになるから、余ったスレッドは
スカウトスレッドとか投機的実行で使うと
0856名無しさん@お腹いっぱい。2009/05/09(土) 15:42:14
>>843
予想通りの書き込みだな。

遅延するのが普通
ゆえに
遅延しても問題ない

っていうのは、いくらなんでも論理的におかしい。

遅延を想定して先を見越したスペックで開発しているので、遅延も予定内
ゆえに
予定内の遅延なら問題ない

っていうのなら、わかるんだが、しかし、Rockは予定外の遅延してるんで。
Rockが出る頃には、他のプロセッサの性能も上がっているし、
たとえ出た瞬間には勝っていても、すぐに追い越されるだろ。
矢継ぎ早に新製品を投入するIntelやAMDに、Sunは対抗できないでしょう。

ちなみに、Itaniumは出た結果遅かったが、それは遅延が酷かったから。
当初の予定から普通に遅れての1999年の早い時期での出荷も無謀に見えた。
新しいアーキ、最新の0.18ミクロンで設計、恐ろしく巨大なダイ、
130Wもの消費電力(P6系の倍)、800MHzという高い動作クロック(P6系は500MHz)、
133MHz DDRバス(P6系は100MHz SDRバス)、などなど。
あまりに最新のものを詰め込みすぎた。
0857名無しさん@お腹いっぱい。2009/05/09(土) 15:46:06
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
0858名無しさん@お腹いっぱい。2009/05/09(土) 15:47:20
出てないもんの問題もクソもないだろ。本気でバカなんだな。
x86うれしがって使ってるやつはやっぱりこの程度。
0859名無しさん@お腹いっぱい。2009/05/09(土) 15:49:16
>>845
どうだろう。

T1は90nmで1.4GHz、T2は65nmで1.4GHzっしょ。
45nmで作っても、それほどクロックは上がらないと思う。

クロックが低いのはプロセス云々ではなく、
1クロックで通らないといけないゲートの数が多いからだろう。
パイプラインの段数が少ないからね。

>>852
おまえ、人に指摘されても、聞く耳もってないようだな。

AVXは、当分はSSE2のベクトル長を倍にしたものに毛が生えた程度だ。
ゲームや科学技術計算ではない、エンタープライズのアプリはSIMD化できんよ。
x64命令についてはコア数増加で、性能向上は続くだろうね。
0860名無しさん@お腹いっぱい。2009/05/09(土) 15:50:30
>>858
貴方の目には、
> x86うれしがって使ってる
に見えるんだ。

自分の勝手な誤解に基づいて相手を罵倒するのは、恥ずかしいぞ。
0861名無しさん@お腹いっぱい。2009/05/09(土) 15:59:56
> ゲームや科学技術計算ではない、エンタープライズのアプリはSIMD化できんよ。
「ベクトル化」はゲームや科学技術計算以外に使えないと思ってるんだな。
それだと後藤さんの記事は一切理解できないだろ?

「聞く耳もってない」とはなんともトホホな....w
0862名無しさん@お腹いっぱい。2009/05/09(土) 16:06:26
>>859
これの、「●ベクタライゼーションを支援する SSE4命令」のとこ読んでみれ。

ttp://pc.watch.impress.co.jp/docs/2006/1004/kaigai307.htm

ああ、かわいそかわいそ。

Intelの CPUアーキテクトが何言ってるか理解できたか?

> 当該の話は、AVXについてではなく、もっともっと先の将来についての話。

とか、わけわからんこと言ってないで勉強しろよ?
0863名無しさん@お腹いっぱい。2009/05/09(土) 16:07:25
>>860
もう恥しくて恥しくて。 ...え? 誤解って? なにが?
0864名無しさん@お腹いっぱい。2009/05/09(土) 16:30:40
なんか、「リッチな回路」思い出したよ、あまりのバカさ加減にw
0865名無しさん@お腹いっぱい。2009/05/09(土) 16:55:49
勘定系 基幹系 情報系 でSIMDなんて糞の約にもたたんだろ
0866名無しさん@お腹いっぱい。2009/05/09(土) 17:08:28
SIMD拡張もメニーコア化もシングルスレッド性能の増強もIntelは全部やるだろ
アホか?
0867名無しさん@お腹いっぱい。2009/05/09(土) 17:10:07
>>865
たとえばこんな話
ttp://knight.dip.jp/index.php?p=256

勘定系 基幹系 情報系 は memcpy()使わないんだっけかw?

# どこまでアホなんだ。とどまるところを知らんwwww
0868名無しさん@お腹いっぱい。2009/05/09(土) 17:11:22
>>866
はぁ。さあねw やっぱり「リッチな回路」、で?
0869名無しさん@お腹いっぱい。2009/05/09(土) 17:15:55
何のために命令セット拡張するのか、Intelは2004年にはその理由を明かしていたのだが・・・・
Intel大嫌いIntelなんかシラネーヨってスタンスなら黙っていれば馬鹿にされずに済むのにね
かわいそう
0870名無しさん@お腹いっぱい。2009/05/09(土) 17:30:06
まだ AVXの意味がわからんらしい.. 後藤さんも Intelも気の毒なこった。
0871名無しさん@お腹いっぱい。2009/05/09(土) 17:44:03
Bridgeシリーズで SIMD主体に移行するから、旧来の x86なだけのソフトウェアの性能は停滞する。(キリッ
0872名無しさん@お腹いっぱい。2009/05/09(土) 17:49:47
現状 x86のキタナイ不定長命令フォーマットから逃れて、デコード回路の
消費電力増を回避するためには、完全に AVXに移行して

> "伝統的x86"を脱する

他に方法はナイノヨ。

ttp://pc.watch.impress.co.jp/docs/2008/0407/kaigai434.htm

つまり、Sandy Bridge以降では AVX以前の命令を使ったソフトウェアは
相対的にだんだん遅くなっていく。
というか、上記記事によれば、Nehalemで既にデコード回路の改善を
見送っている。

で、「RISCになる」とは書いてないが、ほぼそういうことだよ。残念だったねwwwwww
0873名無しさん@お腹いっぱい。2009/05/09(土) 17:55:49
つまり、Sandy Bridge以降では AVX以前の命令を使ったソフトウェアは相対的にだんだん遅くなっていく。(キリッ
0874名無しさん@お腹いっぱい。2009/05/09(土) 18:04:40
ISAなんてもう関係ない、ハズだったのに、おかしいなぁ〜〜〜
0875名無しさん@お腹いっぱい。2009/05/09(土) 18:07:08
ア、ア、アイ、
アイ、アイ、、、

アイテニアムソリューションアライアンス!!
0876名無しさん@お腹いっぱい。2009/05/09(土) 18:07:19
>>861-862
例の記事でIntelのアーキテクトが言ってるのは、

SIMD化による性能向上で進めていくと、いずれ、現状でSIMD化しようがない命令までをもSIMD化するためのブレイクスルー発明が必要だ
つまり、SIMD化だけではダメだから、メニーコアなど他のアプローチも必要よ

ってことだろ。

そりゃ多少はSIMDで処理できる部分もあるが、微々たるものだね。
0877名無しさん@お腹いっぱい。2009/05/09(土) 18:08:27
>>861から>>864まで4連投か。
よほど悔しいと見える。

「リッチな回路」ってのはSunの人がIntel批判として言ったことなんだが、
いまだに理解できないらしい。

いちど先入観で染まってしまうと、もうダメね。
0878名無しさん@お腹いっぱい。2009/05/09(土) 18:11:35
頭悪くてすまん
結局、この議論(?)の争点って何?
0879名無しさん@お腹いっぱい。2009/05/09(土) 18:11:41
>>876
> ってことだろ。

違うよ。印刷して拡大コピーして百回読んだら?
0880名無しさん@お腹いっぱい。2009/05/09(土) 18:13:34
>>877
> よほど悔しいと見える。

...なんで、オレが「悔しい」んだ? 誰か教えてくれ!!

> 「リッチな回路」ってのはSunの人がIntel批判として言ったことなんだが、

うは。そんなこと知ってるわけないわな、「本人」以外に。
Sunの人だぁ?? 死ねば? マジで。
0881名無しさん@お腹いっぱい。2009/05/09(土) 18:14:36
ということで、図星ズボシ図星... でした。「リッチな回路」 ........kkkkkppppppw
0882名無しさん@お腹いっぱい。2009/05/09(土) 18:17:05
>>867
コンパイラが用意したmemcpy()の実装が遅くて自作したことがあるんだが、
memcpyの高速化のポイントはSIMD演算なんかじゃないよ。

拡張命令は使うが、それは、キャッシュのプリフェッチ制御と、
幅が広いという理由でSIMD用のレジスタにロード/ストアするだけ。
SIMD演算なんか、しない。
つまり、128bitのスカラー処理なんだよ。

拡張命令がなかった頃は、
FPUのレジスタが64bit幅だったんで、
浮動小数点でもないのに、FPUのレジスタを使ってコピーしてたなぁ。
0883名無しさん@お腹いっぱい。2009/05/09(土) 18:19:24
>>882
はあ。またズレた話ですね。なんのすり替えですか?
だれか本気にしてるとでも思ってるのかこの「リッチな回路」が
0884名無しさん@お腹いっぱい。2009/05/09(土) 18:21:27
>>872
それ、SIMDの話な。

>>879
おまえが記事を誤解しているんじゃないか?

>>880
スレを読み進めていくと、その後も連投しまくりだな、おい。

>>881
「リッチな回路」の話に噛みついていた、おかしな人「本人」ですか?
0885名無しさん@お腹いっぱい。2009/05/09(土) 18:22:30
>>883
自動ベクトル化できる部分は少ないってことくらい、すでに既出のレスを読んで理解しろよ。
0886名無しさん@お腹いっぱい。2009/05/09(土) 18:23:42
でさ、エンタープライズのアプリまでSIMD化率が100%に到達するとして、SPARCは、どーなん?
0887名無しさん@お腹いっぱい。2009/05/09(土) 18:23:51
キモいんだよ。しつけー。
0888名無しさん@お腹いっぱい。2009/05/09(土) 18:26:51
そもそも>>846の「(SPARCは)Nehalemに勝てるのか?」が発端なんだよな?
なんでアンチSIMDとSIMDマンセーの戦いになってるんだ???
0889名無しさん@お腹いっぱい。2009/05/09(土) 18:33:09
>>885
正味無知なんだな。標準ライブラリの SIMD使った高速化とか、枚挙にいとまがないぞ。
後藤さんも、Intelも、その他の誰も、おまえみたいなことは言ってないぞ。
すこしは勉強して知識つけろよ。性格も直せよ。最悪だぞw
0890名無しさん@お腹いっぱい。2009/05/09(土) 18:35:21
>>888
ちがうよ。「x86 ISAはクズである」という、周知の事実に対して、
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
仕方がないけど知識の足りない人が必死にすり替えを繰り返してるだけ。
0891名無しさん@お腹いっぱい。2009/05/09(土) 18:38:05
>>890さんは、アンチSIMDの人?SIMDマンセーの人?
0892名無しさん@お腹いっぱい。2009/05/09(土) 18:47:16
なんだろう?>>890が一番何かを悔いていそうな感じなのだが
0893名無しさん@お腹いっぱい。2009/05/09(土) 18:54:31
>>889
SIMD化率は50%もいってないんだが。
0894名無しさん@お腹いっぱい。2009/05/09(土) 18:55:34

1. AVXはこれまでの SIMD拡張と大差ない
2. SIMD拡張はゲームや科学技術計算にしか効果がない
3. x86命令は今後も安泰
4. x86の速さの決め手は「リッチな回路」

全部間違い。いや〜笑かすww
0895名無しさん@お腹いっぱい。2009/05/09(土) 18:56:54
CISC vs RISC論争なんて過去の話だから、いまさら言ってもなんだが、
SIMD命令を使って高速化ってのはさ、RISC的じゃないよな。
どんどん便利な命令を追加してくんだもの。
0896名無しさん@お腹いっぱい。2009/05/09(土) 18:59:04
>4. x86の速さの決め手は「リッチな回路」
なんだか自分で火を付けて煽ってるようなのだがw


【レス抽出】
対象スレ:Sun Microsystems 最上川上流
キーワード:リッチな回路


864 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/05/09(土) 16:30:40
なんか、「リッチな回路」思い出したよ、あまりのバカさ加減にw

868 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/05/09(土) 17:11:22
>>866
はぁ。さあねw やっぱり「リッチな回路」、で?

//以下略
0897名無しさん@お腹いっぱい。2009/05/09(土) 19:01:14
>>894
1. *当分の*AVXはこれまでの SIMD拡張と大差ない
2. SIMD拡張はゲームや科学技術計算にしか*大きな*効果がない
3. x86命令は今後も*使わざるをえない*
4. x86の速さの決め手は*スケールメリットによって強引に実現した*「リッチな回路」

ちゃんと理解しようぜ。

Intelが莫大な投資をしてる最先端プロセスと開発力でSPARCを実装したら、
Sunのそれよりも、かなり高速なものができると思うぞ。アーキテクチャだけでなく論理設計が一緒でも。
0898名無しさん@お腹いっぱい。2009/05/09(土) 19:02:19
自分じゃ反論にでもなってると思ってんのかね? あの低レベルな「すり替え」でww
0899名無しさん@お腹いっぱい。2009/05/09(土) 19:03:54
IntelのCPUが速いのはx86のアーキテクチャが優れているからではなく、金に物を言わせて大量生産してるから。
これがSunの人の「リッチな回路」が指すことだろ。

Intel厨が、そんなことはない、x86アーキテクチャは効率的なんだ、って言ってたようだが・・・。


なんかさ、相手をちゃんと見よう是。
0900名無しさん@お腹いっぱい。2009/05/09(土) 19:05:57
>>897
いいから後藤さんの記事ひゃっぺん読んでこいや。アホか。
0901名無しさん@お腹いっぱい。2009/05/09(土) 19:06:52
>>900にとっては後藤さんの記事はバイブルだそうです。
0902名無しさん@お腹いっぱい。2009/05/09(土) 19:17:50
ところで次から Oracle スレ?
0903名無しさん@お腹いっぱい。2009/05/09(土) 19:25:16
命令長が長いからプレフィックス群を刷新するって記事が
どうしてSIMDの話になってるんだろう
0904名無しさん@お腹いっぱい。2009/05/09(土) 19:27:09
後藤さん、後藤さん、後藤さん
0905名無しさん@お腹いっぱい。2009/05/09(土) 19:38:56
>>903
そりゃ、
「SIMD命令の」命令長が長いから・・・
っていう話だからさ。

でさ、AVXもまた広義のx86に含まれるわけです。
8086にあった命令がまったく使われなくなっても、x86なんですよ。
0906名無しさん@お腹いっぱい。2009/05/09(土) 19:39:48
もしItaniumが成功していたら、Itaniumもx86と呼ばれただろうな。
0907名無しさん@お腹いっぱい。2009/05/09(土) 19:43:22
いやそれはない
0908名無しさん@お腹いっぱい。2009/05/09(土) 19:45:16
AMDが採用したらx86と認めてもいい
それまでは淫拡張
0909名無しさん@お腹いっぱい。2009/05/09(土) 19:46:04
Larrabeeの可能性やREXプリフィックスをわざわざ例に上げて書いてるのに
0910名無しさん@お腹いっぱい。2009/05/09(土) 19:48:52
>>908
AMDはSSE5をやめてAVXを実装するよ
0911名無しさん@お腹いっぱい。2009/05/09(土) 19:49:28
クロックなんて飾りですよ
0912名無しさん@お腹いっぱい。2009/05/09(土) 20:11:54
なんだか流れ早いから、そろそろ次スレタイトル案を
0913名無しさん@お腹いっぱい。2009/05/09(土) 20:13:24
Sun Microsystems 最後のアンチスレ
0914名無しさん@お腹いっぱい。2009/05/09(土) 20:13:47
結局、AVXがx86かx86じゃないかなんてどうでも良くって
AVXでXeonがSPARCをぶっち切れればSPARCの死期が早まって
ぶっち切れなかったらSPARCの死期が先に伸びるってことじゃないの?

なんで煽り合いになってるのかようわからんわ
0915名無しさん@お腹いっぱい。2009/05/09(土) 20:17:17
今だと「最期の〜」って様相だなw
0916名無しさん@お腹いっぱい。2009/05/09(土) 20:19:30
Sun Microsystems 最期の罵り合い
0917名無しさん@お腹いっぱい。2009/05/09(土) 20:21:07
話を戻すけどランチボックスは欲しいよね(*´Д`)ハァハァ
0918名無しさん@お腹いっぱい。2009/05/09(土) 20:28:10
Sun Microsystems 最期の買収
でいいんじゃね?
0919名無しさん@お腹いっぱい。2009/05/09(土) 20:29:07
>>917
っ Mac Mini

ワークステーションOSとしては、SolarisよりもMacOS Xのほうが、ずっと使いやすいと思う。
0920名無しさん@お腹いっぱい。2009/05/09(土) 20:29:36
>>917
Mac miniでも買ってろ
0921名無しさん@お腹いっぱい。2009/05/09(土) 20:36:45
Sun Microsystems 最期の輝き
0922名無しさん@お腹いっぱい。2009/05/09(土) 21:09:06
>>919
ワークステーションOSとしては、Windows以外は死んだと思う
Solaris上で動いてるshellやGUIが欲しいだけなら、ネットワーク越しに
Windows上に引っ張ってこれるし
0923名無しさん@お腹いっぱい。2009/05/09(土) 21:10:34
Sun Microsystems 最期の灯火
0924名無しさん@お腹いっぱい。2009/05/09(土) 21:12:26
>>914
SPARCに引導を渡すのが x86 なのが耐えられないから
0925名無しさん@お腹いっぱい。2009/05/09(土) 21:15:02
実はSPARC以外のRISCチップは生きてるように見えて、とっくに死んでるんだよ
レガシーアプリが動いて、それが生きているように見えてるだけ
0926名無しさん@お腹いっぱい。2009/05/09(土) 21:17:40
POWERもヤバそうだしな。
RISCで生き残るのはARMだけかもしれん。
0927名無しさん@お腹いっぱい。2009/05/09(土) 21:32:53
POWERはともかく、PowerPCは組込みでは使われつづけてるよ。
SPARCliteとは、まるで違うレベルで。
とはいえ、ARMのようにIPコアとして使えるものには、数では勝てないな。
0928名無しさん@お腹いっぱい。2009/05/09(土) 22:17:26
Software Design 2009年5月号に UltraSPAC設計者のインタビューが載ってる
0929名無しさん@お腹いっぱい。2009/05/09(土) 22:27:37
10進演算のできるzプロセッサ最強
0930名無しさん@お腹いっぱい。2009/05/09(土) 22:27:48
「UltraSPARCは人生最大の失敗だった」
0931名無しさん@お腹いっぱい。2009/05/09(土) 22:57:45
>>927
組込みも厳しいみたいよ>PowerPC
ゲーム機も次の世代はPOWER系を採用しないという話もあるし
0932名無しさん@お腹いっぱい。2009/05/09(土) 23:40:28
何かSPARCのISAは良いと思い込んでx86を腐しまくっている人が居る
ようだけど、SPARCもたいがい筋悪ISAだろ。
妄想で語ってるだけの連中とは違うエロい人の寸評でも、
SPARCの酷評っぷりはずば抜けている。x86よりはマシ判定だけどな。

ttp://www.nminoru.jp/~nminoru/programming/arch/arch_features.html

ただ、何やかんや言いつつ、この人は変態ISAを愛している様に思える。
0933名無しさん@お腹いっぱい。2009/05/09(土) 23:55:04
SPARCはSPARCだから良いのであって
何か現世御利益があるから良いわけではないのであって
つまり根拠無く信じるという所にSPARCの本質があるのであって
そういう感情というか魂の働きは無神論では決して説明されないのであって
0934名無しさん@お腹いっぱい。2009/05/10(日) 00:15:48
SolarisとSPARCの曖昧模糊とした渾然一体たるITのナニがおんどれらを襲う
0935名無しさん@お腹いっぱい。2009/05/10(日) 00:25:23
Sun Microsystems 余命3ヶ月
レス数が900を超えています。1000を超えると表示できなくなるよ。