だまれ小僧！お前にサンが救えるか

**名無しさん＠お腹いっぱい。** · NG

まあね、JAVAとかいろいろあったし
サーバーも最近はIBMに押され気味だし・・・

**名無しさん＠お腹いっぱい。** · 05/02/11 20:10:25

Sunより先にHPの方が逝ってしまいそうな
ご時勢ですが、こっちの事実認定は
どうすればいいのでしょうか？

フィオリナおばさん、HPをあんなにしても
21億以上の退職金を貰えるんですね。
アメリカの社長さんは儲かりますね。

**名無しさん＠お腹いっぱい。** · 05/02/11 20:12:37

アメリカだって文系の国ですから

**名無しさん＠お腹いっぱい。** · 05/02/11 20:16:27

>>239
ありがと。
ってことはRockやNiagaraに金かけずに2006年からはFJにお任せ
でいいような気がする(まずはTIとバイバイしなきゃ)
Sunがそんなに余裕があるようには思えない…

**名無しさん＠お腹いっぱい。** · 05/02/11 20:32:04

>>240
退職金21億円以上か……。
牛丼なら何杯分だろう。

**名無しさん＠お腹いっぱい。** · 05/02/11 23:38:50

>>234
別にエロくはないが…
USIVはそんな感じ（USIII×2）だな
USIV+は、L2キャッシュがチップに載るから、TPCとかで
かなり数字が良くなるはず

**名無しさん＠お腹いっぱい。** · 05/02/11 23:47:31

>>239
TI自体は、90nmに移行してるはず。確か、世界初のGHz越えDSPとか出してた。
ただ、ハイエンドのMPU作るには、専用のプロセスが必要になりつつあるはずで、
SunがTIを使い続ける意味はあるのかなあって思ったりする。

**名無しさん＠お腹いっぱい。** · 05/02/12 01:17:09

今さっき、見てきました。
2ch閉鎖のflash。
感動したよ。涙が止まらない。

危機？

俺が愛しているjavaだもの。
きっとＵＮＩＸの方々が救うと。
信じてます。
Ｈｅｒｏ！it's in side！！

**名無しさん＠お腹いっぱい。** · 05/02/12 01:22:07

>>245
やっぱりSunが頑張って性能をあげるって感じではなく
半導体のプロセスとかにたよる性能向上ですか…
SuperSPARCの頃から思ってるんだけど、設計自体をなん
とかしてほしいなぁ。

**247** · 05/02/12 01:23:11

まちがえた。↑は>>245ではなく>>244でし…orz

**名無しさん＠お腹いっぱい。** · 05/02/12 01:33:44

>>247
Sunが頑張って性能あげようとしてたUSVは、キャンセルされちゃったからね。
で、そっちの方向は当面は富士通に任せて、Sun自身はNiagaraとかRockとか
別の方向で頑張ろうとしてるはず。
このスレだとNiagaraはあんまり人気ないみたいだけど、俺はけっこう面白い
んじゃないかなと思ってるよ。

**247** · 05/02/12 02:04:55

>>249
もう少しおいらに知恵をさずけてください。
よくマルチコア/マルチスレッドって聞くけどマルチスレッドって従来
Superscalarの延長ですか?
おいらが想像しているNiagaraって
・従来のSMPシステムのCPU部分を1チップにした(今回は8CPU?)
・1CPUコアでは4つの演算ユニットをもって並列処理
って感じですがあってます?

**名無しさん＠お腹いっぱい。** · 05/02/12 04:56:57

249じゃないが…
俺も Niagara と Rock は面白いと思う。

今の CPU がぶちあたっている大きな問題は2つある。

1つは熱。マイクロアーキテクチャで頑張ってトランジスタ
を2倍使っても、性能は1.4倍くらいしか増えない。(ポラック
の法則)。これに対して熱はトランジスタ数に比例するから、
2倍の熱を出すのに性能は1.4倍しか増えないことになる。
しかし、フロントエンド系のサーバー系は、もともとやる仕事
に並列性があるので、マルチコアでコア数をN倍にすれば、
性能もN倍に増える。とすると、熱を勘案した性能の最適点は、
現代的なマイクロアーキテクチャよりも、ずっと昔のシンプル
なマイクロアーキテクチャを沢山積んだものの方が遥かに上になる。
これを実際にやっているのが Niagara。
クライアント市場が本業のインテルやAMDでは、シングルスレッド
性能が下がるので、こんな大胆な計画はそもそも建てられない。
サーバー向けの Itanium や POWER でも、今のところこういう方向
の CPU は計画さえアナウンスされてない。現在名前が出ている
CPU の中で、これにやり方が一番近いのは CELL くらい。ただ、
CELL はCPU アーキテクチャが非対称なので、フロントエンド系
サーバーには向かない。

**名無しさん＠お腹いっぱい。** · 05/02/12 04:59:22

2つ目はCPU とメモリの性能の不均衡の増加。
今では、キャッシュにヒットしなかった場合、CPU は数百命令分
の時間を無駄に待つことになる。Niagara は 4スレッドと、
コアあたりのスレッド数が大きいが、これはこのメモリアクセス
に必要なレイテンシを隠蔽するため。

少なくとも熱問題に対しては、Niagara のアプローチは完全に
正しい。メモリのレイテンシに関しては、スレッド数が増えると
キャッシュのヒット率も下がるため、本当にうまくいくかどうか
断言はできない。しかし、Niagara のデザイン時には当然シミュ
レーションを行なって、スレッド数の最適点を求めている筈だ。

**名無しさん＠お腹いっぱい。** · 05/02/12 05:03:58

32個もコアを積んだマルチコア化の時代に生きのこれるOSは
WindowsとSolarisだけ。他のUNIXはカーネルの基本的設計の
変更を迫られるぐらいのインパクトがあるよ、これは。

**251,252** · 05/02/12 05:07:59

このように、Niagara のデザインには、技術的な
合理性があって、しかも他の CPU ベンダーには
今のところ似たようなものがない。
実際にできあがったものが、当初の目論みどおりの
スループットを達成できるかどうか、CPU業界の人間
はみんな興味津津なんじゃないか？
(注:俺自身はCPUとは何の関係もない単なるソフト屋)

**名無しさん＠お腹いっぱい。** · 05/02/12 05:14:39

>>253

コアは32じゃなくて8だよ。
8コア×4スレッド=トータル32スレッド。

**名無しさん＠お腹いっぱい。** · 05/02/12 05:25:35

結局キャッシュ容量勝負になって
アーキテクチャ的にはたいした進歩を見られないに
23ガバス

**247=250** · 05/02/12 05:42:49

結局マルチスレッドを実現している技術はSuperscalarの延長(並列性を
最大限にしたもの)? それとも全く別の技術?
気になって眠れないんで、教えてください

**名無しさん＠お腹いっぱい。** · 05/02/12 05:46:54

オナニして寝ろ

**名無しさん＠お腹いっぱい。** · 05/02/12 05:47:35

>>250
> ・1CPUコアでは4つの演算ユニットをもって並列処理
>>257
> 結局マルチスレッドを実現している技術はSuperscalarの延長(並列性を
> 最大限にしたもの)?

Niagara は in-order, single issue らしいよ。
つまり OoO どころか、スーパースカラーでもない。
当然演算ユニットはコアあたり1つ。
これは、SMT の目的が、メモリアクセスレイテンシの
の隠蔽だから。
251にあるように、必要とするトランジスタと性能の比からすると、
スーパースカラーは非効率だから。

>>256
> 結局キャッシュ容量勝負になって

3MB の L2 キャッシュをオンダイで積んでいるらしいよ。

**名無しさん＠お腹いっぱい。** · 05/02/12 05:52:41

>3MB の L2 キャッシュをオンダイで積んでいるらしいよ。

3MBとといっても、コアごとに別々に持つわけでしょ？
で、キャッシュの利用効率もやっぱり落ちるんじゃないの？

**名無しさん＠お腹いっぱい。** · 05/02/12 05:58:11

3MBとは等分して一コアあたり375kbということなのかな？

**名無しさん＠お腹いっぱい。** · 05/02/12 06:07:53

> コアごとに別々に持つわけでしょ？

L1 はコアあたりに持つけど、L2 は全コアで共用。
だから、利用効率は別々に持つよりも上。

共用すると、レイテンシの点では不利になるけど、
そのためにコアあたり4スレッド用意していて、
L1 をはずした場合には他のスレッドを動かして
レイテンシを隠蔽するっていう戦略。
合理的でしょ？

**247** · 05/02/12 06:09:46

>>259
ありがとう。
これでやっと眠れます (つ∀-)ｵﾔｽﾐｰ

**名無しさん＠お腹いっぱい。** · 05/02/12 06:15:45

>>262　なるほど
スレッド間で共有＝L1
コア間で共有＝L2
なるほど、こういう感じですか。

**名無しさん＠お腹いっぱい。** · 05/02/12 06:26:04

要約するとSolarisの時代が必ず来ると言うことですね？

**名無しさん＠お腹いっぱい。** · 05/02/12 07:17:09

ﾝﾅﾜｹﾈｰﾀﾞﾛ

**名無しさん＠お腹いっぱい。** · 05/02/12 08:49:24

後藤弘茂のWeekly海外ニュース
Cellのパワーの源「SPE」の正体
http://pc.watch.impress.co.jp/docs/2005/0212/kaigai156.htm

コンテンツ保護機能を備えたCellのCPUコア
http://pc.watch.impress.co.jp/docs/2005/0212/kaigai157.htm

**名無しさん＠お腹いっぱい。** · 05/02/12 19:32:04

Solarsi最強

**名無しさん＠お腹いっぱい** · 05/02/12 19:39:15

問題は、httpやアプリケーションサーバに特化したniagaraやrockをユーザが
受け入れるかどうかだ。単体テストでの応答時間は絶対に遅いぞ＞niagara/rock。
同じスループットを出すIAサーバよりも安くなければ誰も買わない。
勝算はあるのか？＞サン

**名無しさん＠お腹いっぱい。** · 05/02/12 19:48:57

Sun Network ComputingでのNiagaraチップ搭載サーバ
のデモの結果が気になる気になる

**名無しさん＠お腹いっぱい。** · 05/02/12 20:07:24

>>269
httpやアプリケーションサーバだけならブレードサーバでもいい訳だしなー

**名無しさん＠お腹いっぱい。** · 05/02/12 21:47:24

>>271
専用プロセッサって、話題性はあるけど生き延びた試しがない。
AIプロセッサ、ファジープロセッサ、lispにprolog、推論エンジン。
RDBプロセッサにjavaプロセッサ、PostScriptプロセッサ。
Altoマシンに、Lirith、スタックマシン（これは専用ではないが）。
i432にi860。。。
Niagara/Rockの話を聞いてすぐ思い出したのがコネクションマシン
だったYO。そいや、SP2も消えたよね。

**名無しさん＠お腹いっぱい。** · 05/02/12 23:27:02

>>271
Niagara はそもそもブレードサーバ向けだよ。
で、ブレードでは熱が結構問題になるので、熱効率の良い
Niagara にアドバンテージが出ると。

>>272
Niagara は SPARCv9 ベースの汎用命令セットを備え、
従来の SPARC 用アプリケーションが全て動くという
点で、その種の専用プロセッサとは全く違うよ。

**名無しさん＠お腹いっぱい。** · 05/02/12 23:45:30

Niagaraが出荷される頃にSPARC用Solarisが特殊OS扱いされていなければ正しい

**272** · 05/02/12 23:57:49

>>273
用途がブレード専用なら、やっぱり専用プロセッサと考えるべきでしょう。

**名無しさん＠お腹いっぱい。** · 05/02/13 00:06:22

272の挙げる専用プロセッサの定義って、はっきり言って
めちゃめちゃでしょ。素人すぎ。
iAPX432 が専用プロセッサなんていったら、インテルの
人怒るよ。(w

**名無しさん＠お腹いっぱい。** · 05/02/13 00:13:09

おまいら、Niagara/Rockがという心配よりSun自体が
生き残れるか心配しろｗ
プロセッサの技術的なお話はどんどんお願い。

**272** · 05/02/13 01:46:35

>>276
432の俗称はADAマシンです

**272** · 05/02/13 01:49:52

>>276
432の俗称はADAマシンです

**279** · 05/02/13 02:03:45

スマン　誤爆です。
どれが専用プロセッサかは自分の美意識で決めているので、あまり突っ込
まんでくれ。
それより、Niagara/Rockのコアとスレッドの違いを教えてくれんかのう？
どちらもOSからみたらlwpということで一緒じゃないのかぁ？

**名無しさん＠お腹いっぱい。** · 05/02/13 05:37:02

ISSCC 2005 - デュアルコアのItanium 2プロセッサ"Montecito"の詳細が発表
ttp://pcweb.mycom.co.jp/articles/2005/02/11/isscc2/

ISSCC 2005 - MontecitoのL3キャッシュメモリは非同期式(Asynchronous)設計
ttp://pcweb.mycom.co.jp/articles/2005/02/11/isscc3/

**名無しさん＠お腹いっぱい。** · 05/02/13 06:13:45

> どちらもOSからみたらlwpということで一緒じゃないのかぁ？

区別しなくったて動くだろうが、区別した方が性能が出る。
P4/Xeon 系 SMP マシンで、CPUとHyperthreadを区別するか
しないかと全く同じ話。

**名無しさん＠お腹いっぱい。** · 05/02/13 07:24:19

マルチコアになったら、Windowsは昔みたいに
OSの機能をユーザー空間に出した方がパフォーマンスよくなるの？

**279** · 05/02/13 09:56:05

>>281
こりゃスゴイかも。

**名無しさん＠お腹いっぱい。** · 05/02/14 07:19:12

>>283
ユーザー区間に出しても、あまりパフォーマンスが変わらない程度な気がする。

次のWindowsは画面まわりが、ユーザ側に戻るような事をみたけど。

**名無しさん＠お腹いっぱい。** · 05/02/16 20:59:33

SPARC系ワークステーションは消滅していくわけですね
x86-64へ切替え進めて

**名無しさん＠お腹いっぱい。** · 05/02/16 22:31:04

>>286
x86-64以前に linux for i386にリプレースされてますがな

**名無しさん＠お腹いっぱい。** · 05/02/16 23:16:06

SunPCiのSPARC版(仮称PCSuni) ﾁﾝ☆⌒ 凵＼(＼･∀･) まだぁ?

**名無しさん＠お腹いっぱい。** · 05/02/17 01:53:33

>>286
マルチコアが普及した場合x86はとっても不利だと思う
単純なRISC系CPUの方が有利だと思う
RISC CPUは命令セットはきわめて単純だから命令セットの違いはあまり関係ないだろうし、
SPARCが遅いのはTIの技術がIntel、AMD、IBMに比べてショボイのが影響してると思う

**名無しさん＠お腹いっぱい。** · 05/02/17 03:51:40

TIの技術がショボイのにいまだにTIを使うSunはアホ

**名無しさん＠お腹いっぱい。** · 05/02/17 05:35:19

かといって、TIを使わないで富士通とか言い出すのは、
韓国財閥の傘下に自分から入る日本企業と同じぐらい嫌われますよ。

**名無しさん＠お腹いっぱい。** · 05/02/17 06:47:24

x86と比べれば単純かもしれないけど、
もうRISCも単純じゃないような。

しかし、in-order, single issueだと、かなり単純化できるよね。
今までの進化は殆ど、いかに実行ユニット遊ばせないようにするかだし。

**名無しさん＠お腹いっぱい。** · 05/02/17 06:47:25

10年以上TIとつきあって駄目さ加減はわかってるんだから
いい加減なんとかしてほしい。
AMDなんてどうかな、いろいろ協力すればよさそうな気が…
ついでにTransmetaも仲間にしてCode Morphingで( ﾟДﾟ)ｳﾏｰ

**名無しさん＠お腹いっぱい。** · 05/02/17 07:15:20

アメリカにはアメリカの事情ってのがあるんだろう

**名無しさん＠お腹いっぱい。** · 05/02/17 07:38:56

>>286
マルチコアうんぬん以前に非x86系ワークステーションはとっても不利だと思う。

**名無しさん＠お腹いっぱい。** · 05/02/17 17:29:00

いまだにハードウェアで行くか、ソフトウェアで行くか、どっちつかずで
ﾌﾗﾌﾗしてる…。そうこうしてる間にどんどん客が逃げて行く…。
CTCはSolaris 10にチカラを入れないと明言してるし、どうすんだ？

アメリカじゃUCだなって言ってるけど、日本は箱物をベンダーに売っても
らってナンボだったから、急に方向転換も出来んだろうし…。

ﾅﾑｱﾋﾞﾀﾞﾌﾞ。ﾅﾑｱﾋﾞﾀﾞﾌﾞ。。

**名無しさん＠お腹いっぱい。** · 05/02/17 20:43:44

>>290
>TIの技術がショボイ

TIとかMotorolaとかコスト意識にうるさい会社は、そもそも
ハイパフォーマンスCPUを作るのには向いていない。

「そこそこの性能」を格安に作るのが得意なのであって、
技術が無いのではなく、深追いしない方針だと思われ。

**名無しさん＠お腹いっぱい。** · 05/02/17 21:35:47

だな。TIはDSPで結構いい製品出してるし。

**名無しさん＠お腹いっぱい。** · 05/02/18 00:45:41

アンディたんキター！
http://www.itmedia.co.jp/enterprise/articles/0502/17/news026.html

もう、UltraSPARCイラネ

**名無しさん＠お腹いっぱい。** · 05/02/18 00:51:49

アンディたん( ´Д`)ﾊｧﾊｧ

**名無しさん＠お腹いっぱい。** · 05/02/18 01:05:17

TIのDSPは学部時代の講義で買ったよ。PCにシリアルで繋げるやつ。
まだ押し入れの奥にあるはず。

**名無しさん＠お腹いっぱい。** · 05/02/18 01:34:17

Opteron搭載の薄型ブレードサーバなんか出したら
Niagaraの意味がますますなくなるじゃないか

**名無しさん＠お腹いっぱい。** · 05/02/18 02:27:58

それでいいじゃない。

**名無しさん＠お腹いっぱい。** · 05/02/18 02:31:45

x86系CPUは今現在は高性能だけど、
今後も今の状態を維持できるとは限らないよ
特に、マルチコアの時代ではx86系CPUは不利だと思う

**名無しさん＠お腹いっぱい。** · 05/02/18 02:38:07

CISC vs RISC でその手の意見は聞き飽きた

**名無しさん＠お腹いっぱい。** · 05/02/18 06:57:25

>>304
かといって、現時点でPOWERやItaniumに劣るSPRACが有利とは思えない訳で

**名無しさん＠お腹いっぱい。** · 05/02/18 13:19:03

いや、劣るからこそ Niagara みたいな思い切ったことが
できるんじゃないの？サーバー系ならどのベンダーでも
Niagara みたいに性能/電力比に舵を切った CPU を、
フロントエンド向けに出せる筈だけど、それが Sun に
しかできてないのは、なまじシングルスレッド性能が高い
せいで、思い切った戦略が出せないせいのような。

まあ、Niagara も元はベンチャー (Afara Websystems) の
アイディアを Sun が買収したものなんだが。
といっても Les Kohn その他の Afara の面子は、UltraSPARC I
の元設計者だから、単に出戻っただけとも言えるけどね。

**名無しさん＠お腹いっぱい。** · 05/02/18 15:02:57

出戻り多過ぎだ。

**名無しさん＠お腹いっぱい。** · 05/02/18 15:23:12

長期的な視野にたった実験的な投資は、株主利益重視の
米国企業ではできないから、すぐにベンチャーを建てて
実験的な開発はそこでやって、うまくいくようなら
大企業がそれを買い戻すってやり方が多いって聞いた
ことがあるな。
これに対し日本企業は社内で結構ベンチャー的な開発が
可能である…と。

しかし、最近の日本は利益重視で実験的開発なんて不可能
なのに、米国と違ってベンチャーを支える下地がない…
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

**名無しさん＠お腹いっぱい。** · 05/02/18 20:52:00

>>305
x86系CPUの命令アーキテクチャの複雑さを考えれば、CISC vs RISCが無意味とは言えない
x86系CPUはタスク切り替えまでプロセッサが自動的に行うしね
こんなに複雑なアーキテクチャのCPUは他にないよ
あと、RISC CPUも複雑になったとか言うけど、x86系CPUに比べればシンプルそのもの

**名無しさん＠お腹いっぱい。** · 05/02/18 21:27:24

タスク切り替えを自動的に行うというよりタスク切り替えに必要な煩雑な処理を
CPUが自動的に行ってくれるということ
具体的にいうとTRレジスタのセレクタ値を変更するだけでタスク切り替え処理が
自動的に実行される
レジスタの退避や初期化などもすべて自動的に行われる

こんなことまでやるCPUはx86系以外に知らん

**名無しさん＠お腹いっぱい。** · 05/02/19 00:21:02

>>308
AppleなんてカリスマCEOが出戻りだぞ？

Mac OS X用のプログラムを書いてみると，NeXTSTEPであることがよくわかる…

**名無しさん＠お腹いっぱい。** · 05/02/19 07:08:45

>>312
あたりまえだ。
AppleがNeXTを買収した目的が、NeXTSTEPをMacの後継OSとして使いたいということだったから。
あんな廃れた会社に4億ドルもつぎ込んで買収したのに、使わないはずない。

**名無しさん＠お腹いっぱい。** · 05/02/19 07:31:14

Sunのシュワルツ社長、データベース計画、SPARC、HPを語る (2/3)
http://www.itmedia.co.jp/enterprise/articles/0502/18/news065_2.html

「64ウェイのSPARCシステムが、同クラスのIBM POWERシステムやItaniumシステムに勝てると思うか？」と聞かれれば、「間違いなく勝てる」というのが私の答えです。
「64ウェイのSPARCシステムが、同クラスのIBM POWERシステムやItaniumシステムに勝てると思うか？」と聞かれれば、「間違いなく勝てる」
「64ウェイのSPARCシステムが、同クラスのIBM POWERシステムやItaniumシステムに間違いなく勝てる」
「64ウェイのSPARCシステムが、間違いなく勝てる」
「間違いなく勝てる」
「間違いなく勝てる」
「間違いなく勝てる」
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ＼ /　＼　/　　＼ /　　＼ /　　＼ /　　＼

http://www.itmedia.co.jp/enterprise/articles/0502/18/news065_3.html
Gartnerの予測によれば、2010年代末までにItaniumとPOWERがそれぞれ、プロセッサ市場の売り上げの約15％を占めるようになり、SPARCのシェアはその半分に過ぎないだろうとしていますが、

落ち目のシステムベンダーがほかの企業を買収しても、落ち目のシステムベンダーであることに変わりありません。
落ち目のシステムベンダーであることに変わりありません。
落ち目のシステムベンダー
落ち目のシステムベンダー
落ち目のシステムベンダー
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ＼ /　＼　/　　＼ /　　＼ /　　＼ /　　＼

**名無しさん＠お腹いっぱい。** · 05/02/19 08:40:49

そういえばSunはまだDBもってなかったよな。
名前は Java SQL severか、Sun ONE SQL Serverか。

**名無しさん＠お腹いっぱい。** · 05/02/19 08:55:51

Java SQL severのほうが売れると思う。

**名無しさん＠お腹いっぱい。** · 05/02/19 10:49:11

>>314
POWERはともかく、まだItaniumとか言ってるのか？Gartnerは
まったく、Intelからいくら貰ってるんだろ

**名無しさん＠お腹いっぱい。** · 05/02/19 12:13:44

「2010年代末」だってー！？！？！？それって、15年後じゃん。
今から15年前っていうと、1990年だぜ。その頃に今のCPUの
シェアを想像できたか？
ありえない。
今から15年後のシェアをそれなりの確度で予想できるか？
絶対無理。
Gartner は、どうせ誰も信じないと思って適当なこと言って
るだけだろ。

**名無しさん＠お腹いっぱい。** · 05/02/19 12:19:56

2019年: x86系が96%。

**名無しさん＠お腹いっぱい。** · 05/02/19 12:55:19

シュワルツ：将来を予想するのが好きなGartnerの連中について私が
　　　　　　どう思うか、というご質問ですね。彼らはブラウザ市場
　　　　　　の予測を誤りました。Solarisがリリース後最初の10日間で
　　　　　　50万本も配布されたことも予測できませんでした。また
　　　　　　彼らは、Microsoftが携帯電話分野で大成功を収めると
　　　　　　予想していました。私も彼らの予想を聞くのは好きですが、
　　　　　　必ずしも納得できるものばかりではありません。

この質問に関しては、シュワルツたんの勝利のようだが

**名無しさん＠お腹いっぱい。** · 05/02/19 13:21:21

>>319
POWERは生き残るんじゃね？
だから、POWERでSolaris動かそうよー

**名無しさん＠お腹いっぱい。** · 05/02/19 13:31:57

一時PowerPCでなら動いていたんだけどね。
Appleを買うという話がでる直前。IBMのブースでみた。

**名無しさん＠お腹いっぱい。** · 05/02/19 13:32:21

Sun adds speed and Fujitsu to server line
http://www.theregister.co.uk/2005/02/18/sun_us4_fujitsu/

SunがPrimePower売り始めたみたい

**名無しさん＠お腹いっぱい。** · 05/02/19 22:33:01

間違いなく勝てるSPARCシステムてのはSPRARC64のことか

**名無しさん＠お腹いっぱい。** · 05/02/19 23:52:38

そのための富士Sun系グループ

**名無しさん＠お腹いっぱい。** · 05/02/20 01:40:09

Sun、年内に「Trusted Solaris 10」をリリースへ
http://www.itmedia.co.jp/enterprise/articles/0502/19/news010.html

Trusted Solaris 9は？
Solaris10にTrusted OSの要件を付加するってのは中止？

**名無しさん＠お腹いっぱい。** · 05/02/20 11:17:45

IntelのEPICってどう思いますか?
分岐予測をCPUに入る前のソフトウェアに託すというのは結構大胆な発想だと思いますが。
現状ではコンパイラの性能が出なくて苦労してるみたいですが。

**名無しさん＠お腹いっぱい。** · 05/02/20 11:21:23

前からあったよ。
どこを投機実行すべきか指定するって発想は。
投機実行が１ブランチの時代から。

**名無しさん＠お腹いっぱい。** · 05/02/20 11:48:40

そうですか。
で、戦略的にはどうなんでしょ?

**名無しさん＠お腹いっぱい。** · 05/02/20 12:21:21

何についての戦略よ。

**名無しさん＠お腹いっぱい。** · 05/02/20 15:38:51

>>326
>Solaris10にTrusted OSの要件を付加するってのは中止？

Solaris 10 に含まれる Trusted の機能は一部だけなんでは？

**名無しさん＠お腹いっぱい。** · 05/02/20 15:46:42

>>328
発想だけ前からあって、今まで実現されなかったのは何故なんでしょ?

**名無しさん＠お腹いっぱい。** · 05/02/20 16:55:44

え？実現していた会社は昔から沢山あったよ。

EPIC が改善してる点は、VLIW のバイナリ互換性問題でしょ。これにつ
いても、別に発想がそんなに画期的なわけじゃなくて、これまでは集積
度の関係でスパコン系の会社しか VLIW をやってなくって、スパコンで
はバイナリ互換性はどうでもいいから面倒くさいので実装してなかったっ
てだけだと思うけど。

**名無しさん＠お腹いっぱい。** · 05/02/20 17:23:07

VLIW のバイナリ互換性問題については、Transmeta のような解
もあったな。結構いい解だと思うので、存続して欲しいんだが。

**名無しさん＠お腹いっぱい。** · 05/02/20 22:22:42

>>333
よくわからんのだが、EPICとVLIWのバイナリ互換は関係ないんじゃねーの?

**名無しさん＠お腹いっぱい。** · 05/02/20 22:48:25

VLIWの場合、複数の相互依存しない命令をコンパイラが探して、一つの巨大(Very Large)な命令にまとめる。
CPUの内部構成が変わると、同時発行命令数が変わるので、
単純なVLIWの場合は、CPUの世代ごとにバイナリ互換性がなくなるリスクがあった。
EPICでは依存関係もコードに持たせているので、
将来に渡ってコードの互換性を保証できる。

でも、CPUの最高性能を得るのにリコンパイルが必要なのは変わらない。
ItaniumとItanium2は同じ6命令同時発行だったので、この問題は顕在化しなかった。

**名無しさん＠お腹いっぱい。** · 05/02/20 23:05:30

確かにそういうメリットもあるのかもしれないけど、
漏れ的には、プロセッサがやる分岐判断を、その前段のソフトウェアで行っておく事で
処理速度を速めるのがEPICのウリだと理解しているんだが、間違い?

**名無しさん＠お腹いっぱい。** · 05/02/20 23:23:35

それはそもそも EPIC の売りじゃない。
分岐ヒントは EPIC じゃない普通のプロセッサにだって
あるぞ。

**名無しさん＠お腹いっぱい。** · 05/02/21 00:08:15

>>327
なんか、いろいろ参考になるから、別にこのまま続けてもかまわないけど、
なんでこのスレでEPICの話しようと思ったの？