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

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

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。NGNG
まあね、JAVAとかいろいろあったし
サーバーも最近はIBMに押され気味だし・・・
0261名無しさん＠お腹いっぱい。05/02/12 05:58:11
3MBとは等分して一コアあたり375kbということなのかな？
0262名無しさん＠お腹いっぱい。05/02/12 06:07:53
> コアごとに別々に持つわけでしょ？

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

共用すると、レイテンシの点では不利になるけど、
そのために コアあたり4スレッド用意していて、
L1 をはずした場合には他のスレッドを動かして
レイテンシを隠蔽するっていう戦略。
合理的でしょ？
026324705/02/12 06:09:46
>>259
ありがとう。
これでやっと眠れます (つ∀-)ｵﾔｽﾐｰ
0264名無しさん＠お腹いっぱい。05/02/12 06:15:45
>>262　なるほど
スレッド間で共有＝L1
コア間で共有＝L2
なるほど、こういう感じですか。
0265名無しさん＠お腹いっぱい。05/02/12 06:26:04
要約するとSolarisの時代が必ず来ると言うことですね？
0266名無しさん＠お腹いっぱい。05/02/12 07:17:09
ﾝﾅﾜｹﾈｰﾀﾞﾛ
0267名無しさん＠お腹いっぱい。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
0268名無しさん＠お腹いっぱい。05/02/12 19:32:04
Solarsi最強
0269名無しさん＠お腹いっぱい05/02/12 19:39:15
問題は、httpやアプリケーションサーバに特化したniagaraやrockをユーザが
受け入れるかどうかだ。単体テストでの応答時間は絶対に遅いぞ＞niagara/rock。
同じスループットを出すIAサーバよりも安くなければ誰も買わない。
勝算はあるのか？＞サン
0270名無しさん＠お腹いっぱい。05/02/12 19:48:57
Sun Network ComputingでのNiagaraチップ搭載サーバ
のデモの結果が気になる気になる
0271名無しさん＠お腹いっぱい。05/02/12 20:07:24
>>269
httpやアプリケーションサーバだけならブレードサーバでもいい訳だしなー
0272名無しさん＠お腹いっぱい。 05/02/12 21:47:24
>>271
専用プロセッサって、話題性はあるけど生き延びた試しがない。
AIプロセッサ、ファジープロセッサ、lispにprolog、推論エンジン。
RDBプロセッサにjavaプロセッサ、PostScriptプロセッサ。
Altoマシンに、Lirith、スタックマシン（これは専用ではないが）。
i432にi860。。。
Niagara/Rockの話を聞いてすぐ思い出したのがコネクションマシン
だったYO。そいや、SP2も消えたよね。
0273名無しさん＠お腹いっぱい。05/02/12 23:27:02
>>271
Niagara はそもそもブレードサーバ向けだよ。
で、ブレードでは熱が結構問題になるので、熱効率の良い
Niagara にアドバンテージが出ると。

>>272
Niagara は SPARCv9 ベースの汎用命令セットを備え、
従来の SPARC 用アプリケーションが全て動くという
点で、その種の専用プロセッサとは全く違うよ。
0274名無しさん＠お腹いっぱい。05/02/12 23:45:30
Niagaraが出荷される頃にSPARC用Solarisが特殊OS扱いされていなければ正しい
027527205/02/12 23:57:49
>>273
用途がブレード専用なら、やっぱり専用プロセッサと考えるべきでしょう。
0276名無しさん＠お腹いっぱい。05/02/13 00:06:22
272の挙げる専用プロセッサの定義って、はっきり言って
めちゃめちゃでしょ。素人すぎ。
iAPX432 が専用プロセッサなんていったら、インテルの
人怒るよ。(w
0277名無しさん＠お腹いっぱい。05/02/13 00:13:09
おまいら、Niagara/Rockがという心配よりSun自体が
生き残れるか心配しろｗ
プロセッサの技術的なお話はどんどんお願い。
027827205/02/13 01:46:35
>>276
432の俗称はADAマシンです
027927205/02/13 01:49:52
>>276
432の俗称はADAマシンです
028027905/02/13 02:03:45
スマン　誤爆です。
どれが専用プロセッサかは自分の美意識で決めているので、あまり突っ込
まんでくれ。
それより、Niagara/Rockのコアとスレッドの違いを教えてくれんかのう？
どちらもOSからみたらlwpということで一緒じゃないのかぁ？
0281名無しさん＠お腹いっぱい。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/
0282名無しさん＠お腹いっぱい。05/02/13 06:13:45
> どちらもOSからみたらlwpということで一緒じゃないのかぁ？

区別しなくったて動くだろうが、区別した方が性能が出る。
P4/Xeon 系 SMP マシンで、CPUとHyperthreadを区別するか
しないかと全く同じ話。
0283名無しさん＠お腹いっぱい。05/02/13 07:24:19
マルチコアになったら、Windowsは昔みたいに
OSの機能をユーザー空間に出した方がパフォーマンスよくなるの？
028427905/02/13 09:56:05
>>281
こりゃスゴイかも。
0285名無しさん＠お腹いっぱい。05/02/14 07:19:12
>>283
ユーザー区間に出しても、あまりパフォーマンスが変わらない程度な気がする。

次のWindowsは画面まわりが、ユーザ側に戻るような事をみたけど。
0286名無しさん＠お腹いっぱい。05/02/16 20:59:33
SPARC系ワークステーションは消滅していくわけですね
x86-64へ切替え進めて
0287名無しさん＠お腹いっぱい。05/02/16 22:31:04
>>286
x86-64以前に linux for i386にリプレースされてますがな
0288名無しさん＠お腹いっぱい。05/02/16 23:16:06
SunPCiのSPARC版(仮称PCSuni) ﾁﾝ☆⌒ 凵＼(＼･∀･) まだぁ?
0289名無しさん＠お腹いっぱい。05/02/17 01:53:33
>>286
マルチコアが普及した場合x86はとっても不利だと思う
単純なRISC系CPUの方が有利だと思う
RISC CPUは命令セットはきわめて単純だから命令セットの違いはあまり関係ないだろうし、
SPARCが遅いのはTIの技術がIntel、AMD、IBMに比べてショボイのが影響してると思う
0290名無しさん＠お腹いっぱい。05/02/17 03:51:40
TIの技術がショボイのにいまだにTIを使うSunはアホ
0291名無しさん＠お腹いっぱい。05/02/17 05:35:19
かといって、TIを使わないで富士通とか言い出すのは、
韓国財閥の傘下に自分から入る日本企業と同じぐらい嫌われますよ。
0292名無しさん＠お腹いっぱい。05/02/17 06:47:24
x86と比べれば単純かもしれないけど、
もうRISCも単純じゃないような。

しかし、in-order, single issueだと、かなり単純化できるよね。
今までの進化は殆ど、いかに実行ユニット遊ばせないようにするかだし。
0293名無しさん＠お腹いっぱい。05/02/17 06:47:25
10年以上TIとつきあって駄目さ加減はわかってるんだから
いい加減なんとかしてほしい。
AMDなんてどうかな、いろいろ協力すればよさそうな気が…
ついでにTransmetaも仲間にしてCode Morphingで( ﾟДﾟ)ｳﾏｰ
0294名無しさん＠お腹いっぱい。05/02/17 07:15:20
アメリカにはアメリカの事情ってのがあるんだろう
0295名無しさん＠お腹いっぱい。05/02/17 07:38:56
>>286
マルチコアうんぬん以前に非x86系ワークステーションはとっても不利だと思う。
0296名無しさん＠お腹いっぱい。05/02/17 17:29:00
いまだにハードウェアで行くか、ソフトウェアで行くか、どっちつかずで
ﾌﾗﾌﾗしてる…。そうこうしてる間にどんどん客が逃げて行く…。
CTCはSolaris 10にチカラを入れないと明言してるし、どうすんだ？

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

ﾅﾑｱﾋﾞﾀﾞﾌﾞ。ﾅﾑｱﾋﾞﾀﾞﾌﾞ。。
0297名無しさん＠お腹いっぱい。05/02/17 20:43:44
>>290
>TIの技術がショボイ

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

「そこそこの性能」を格安に作るのが得意なのであって、
技術が無いのではなく、深追いしない方針だと思われ。
0298名無しさん＠お腹いっぱい。05/02/17 21:35:47
だな。TIはDSPで結構いい製品出してるし。
0299名無しさん＠お腹いっぱい。05/02/18 00:45:41
アンディたんキター！
http://www.itmedia.co.jp/enterprise/articles/0502/17/news026.html

もう、UltraSPARCイラネ
0300名無しさん＠お腹いっぱい。05/02/18 00:51:49
アンディたん( ´Д`)ﾊｧﾊｧ
0301名無しさん＠お腹いっぱい。05/02/18 01:05:17
TIのDSPは学部時代の講義で買ったよ。PCにシリアルで繋げるやつ。
まだ押し入れの奥にあるはず。
0302名無しさん＠お腹いっぱい。05/02/18 01:34:17
Opteron搭載の薄型ブレードサーバなんか出したら
Niagaraの意味がますますなくなるじゃないか
0303名無しさん＠お腹いっぱい。05/02/18 02:27:58
それでいいじゃない。
0304名無しさん＠お腹いっぱい。05/02/18 02:31:45
x86系CPUは今現在は高性能だけど、
今後も今の状態を維持できるとは限らないよ
特に、マルチコアの時代ではx86系CPUは不利だと思う
0305名無しさん＠お腹いっぱい。05/02/18 02:38:07
CISC vs RISC でその手の意見は聞き飽きた
0306名無しさん＠お腹いっぱい。05/02/18 06:57:25
>>304
かといって、現時点でPOWERやItaniumに劣るSPRACが有利とは思えない訳で
0307名無しさん＠お腹いっぱい。05/02/18 13:19:03
いや、劣るからこそ Niagara みたいな思い切ったことが
できるんじゃないの？ サーバー系ならどのベンダーでも
Niagara みたいに性能/電力比に舵を切った CPU を、
フロントエンド向けに出せる筈だけど、それが Sun に
しかできてないのは、なまじシングルスレッド性能が高い
せいで、思い切った戦略が出せないせいのような。

まあ、Niagara も元はベンチャー (Afara Websystems) の
アイディアを Sun が買収したものなんだが。
といっても Les Kohn その他の Afara の面子は、UltraSPARC I
の元設計者だから、単に出戻っただけとも言えるけどね。
0308名無しさん＠お腹いっぱい。05/02/18 15:02:57
出戻り多過ぎだ。
0309名無しさん＠お腹いっぱい。05/02/18 15:23:12
長期的な視野にたった実験的な投資は、株主利益重視の
米国企業ではできないから、すぐにベンチャーを建てて
実験的な開発はそこでやって、うまくいくようなら
大企業がそれを買い戻すってやり方が多いって聞いた
ことがあるな。
これに対し日本企業は社内で結構ベンチャー的な開発が
可能である…と。

しかし、最近の日本は利益重視で実験的開発なんて不可能
なのに、米国と違ってベンチャーを支える下地がない…
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0310名無しさん＠お腹いっぱい。05/02/18 20:52:00
>>305
x86系CPUの命令アーキテクチャの複雑さを考えれば、CISC vs RISCが無意味とは言えない
x86系CPUはタスク切り替えまでプロセッサが自動的に行うしね
こんなに複雑なアーキテクチャのCPUは他にないよ
あと、RISC CPUも複雑になったとか言うけど、x86系CPUに比べればシンプルそのもの
0311名無しさん＠お腹いっぱい。05/02/18 21:27:24
タスク切り替えを自動的に行うというよりタスク切り替えに必要な煩雑な処理を
CPUが自動的に行ってくれるということ
具体的にいうとTRレジスタのセレクタ値を変更するだけでタスク切り替え処理が
自動的に実行される
レジスタの退避や初期化などもすべて自動的に行われる

こんなことまでやるCPUはx86系以外に知らん
0312名無しさん＠お腹いっぱい。05/02/19 00:21:02
>>308
AppleなんてカリスマCEOが出戻りだぞ？

Mac OS X用のプログラムを書いてみると，NeXTSTEPであることがよくわかる…
0313名無しさん＠お腹いっぱい。05/02/19 07:08:45
>>312
あたりまえだ。
AppleがNeXTを買収した目的が、NeXTSTEPをMacの後継OSとして使いたいということだったから。
あんな廃れた会社に4億ドルもつぎ込んで買収したのに、使わないはずない。
0314名無しさん＠お腹いっぱい。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のシェアはその半分に過ぎないだろうとしていますが、



落ち目のシステムベンダーがほかの企業を買収しても、落ち目のシステムベンダーであることに変わりありません。
落ち目のシステムベンダーであることに変わりありません。
落ち目のシステムベンダー
落ち目のシステムベンダー
落ち目のシステムベンダー
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ /　＼　/　　＼ /　　＼ /　　＼ /　　＼
0315名無しさん＠お腹いっぱい。05/02/19 08:40:49
そういえばSunはまだDBもってなかったよな。
名前は Java SQL severか、Sun ONE SQL Serverか。
0316名無しさん＠お腹いっぱい。05/02/19 08:55:51
Java SQL severのほうが売れると思う。
0317名無しさん＠お腹いっぱい。05/02/19 10:49:11
>>314
POWERはともかく、まだItaniumとか言ってるのか？Gartnerは
まったく、Intelからいくら貰ってるんだろ
0318名無しさん＠お腹いっぱい。05/02/19 12:13:44
「2010年代末」だってー！？！？！？ それって、15年後じゃん。
今から15年前っていうと、1990年だぜ。その頃に今のCPUの
シェアを想像できたか？
ありえない。
今から15年後のシェアをそれなりの確度で予想できるか？
絶対無理。
Gartner は、どうせ誰も信じないと思って適当なこと言って
るだけだろ。
0319名無しさん＠お腹いっぱい。05/02/19 12:19:56
2019年: x86系が96%。
0320名無しさん＠お腹いっぱい。05/02/19 12:55:19
シュワルツ：将来を予想するのが好きなGartnerの連中について私が
　　　　　　どう思うか、というご質問ですね。彼らはブラウザ市場
　　　　　　の予測を誤りました。Solarisがリリース後最初の10日間で
　　　　　　50万本も配布されたことも予測できませんでした。また
　　　　　　彼らは、Microsoftが携帯電話分野で大成功を収めると
　　　　　　予想していました。私も彼らの予想を聞くのは好きですが、
　　　　　　必ずしも納得できるものばかりではありません。

この質問に関しては、シュワルツたんの勝利のようだが
0321名無しさん＠お腹いっぱい。05/02/19 13:21:21
>>319
POWERは生き残るんじゃね？
だから、POWERでSolaris動かそうよー
0322名無しさん＠お腹いっぱい。05/02/19 13:31:57
一時PowerPCでなら動いていたんだけどね。
Appleを買うという話がでる直前。IBMのブースでみた。
0323名無しさん＠お腹いっぱい。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売り始めたみたい
0324名無しさん＠お腹いっぱい。05/02/19 22:33:01
間違いなく勝てるSPARCシステムてのはSPRARC64のことか
0325名無しさん＠お腹いっぱい。05/02/19 23:52:38
そのための富士Sun系グループ
0326名無しさん＠お腹いっぱい。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の要件を付加するってのは中止？
0327名無しさん＠お腹いっぱい。05/02/20 11:17:45
IntelのEPICってどう思いますか?
分岐予測をCPUに入る前のソフトウェアに託すというのは結構大胆な発想だと思いますが。
現状ではコンパイラの性能が出なくて苦労してるみたいですが。
0328名無しさん＠お腹いっぱい。05/02/20 11:21:23
前からあったよ。
どこを投機実行すべきか指定するって発想は。
投機実行が１ブランチの時代から。
0329名無しさん＠お腹いっぱい。05/02/20 11:48:40
そうですか。
で、戦略的にはどうなんでしょ?
0330名無しさん＠お腹いっぱい。05/02/20 12:21:21
何についての戦略よ。
0331名無しさん＠お腹いっぱい。05/02/20 15:38:51
>>326
>Solaris10にTrusted OSの要件を付加するってのは中止？

Solaris 10 に含まれる Trusted の機能は一部だけなんでは？
0332名無しさん＠お腹いっぱい。05/02/20 15:46:42
>>328
発想だけ前からあって、今まで実現されなかったのは何故なんでしょ?
0333名無しさん＠お腹いっぱい。05/02/20 16:55:44
え？ 実現していた会社は昔から沢山あったよ。

EPIC が改善してる点は、VLIW のバイナリ互換性問題でしょ。これにつ
いても、別に発想がそんなに画期的なわけじゃなくて、これまでは集積
度の関係でスパコン系の会社しか VLIW をやってなくって、スパコンで
はバイナリ互換性はどうでもいいから面倒くさいので実装してなかったっ
てだけだと思うけど。
0334名無しさん＠お腹いっぱい。05/02/20 17:23:07
VLIW のバイナリ互換性問題については、Transmeta のような解
もあったな。結構いい解だと思うので、存続して欲しいんだが。
0335名無しさん＠お腹いっぱい。05/02/20 22:22:42
>>333
よくわからんのだが、EPICとVLIWのバイナリ互換は関係ないんじゃねーの?
0336名無しさん＠お腹いっぱい。05/02/20 22:48:25
VLIWの場合、複数の相互依存しない命令をコンパイラが探して、一つの巨大(Very Large)な命令にまとめる。
CPUの内部構成が変わると、同時発行命令数が変わるので、
単純なVLIWの場合は、CPUの世代ごとにバイナリ互換性がなくなるリスクがあった。
EPICでは依存関係もコードに持たせているので、
将来に渡ってコードの互換性を保証できる。

でも、CPUの最高性能を得るのにリコンパイルが必要なのは変わらない。
ItaniumとItanium2は同じ6命令同時発行だったので、この問題は顕在化しなかった。
0337名無しさん＠お腹いっぱい。05/02/20 23:05:30
確かにそういうメリットもあるのかもしれないけど、
漏れ的には、プロセッサがやる分岐判断を、その前段のソフトウェアで行っておく事で
処理速度を速めるのがEPICのウリだと理解しているんだが、間違い?
0338名無しさん＠お腹いっぱい。05/02/20 23:23:35
それはそもそも EPIC の売りじゃない。
分岐ヒントは EPIC じゃない普通のプロセッサにだって
あるぞ。
0339名無しさん＠お腹いっぱい。05/02/21 00:08:15
>>327
なんか、いろいろ参考になるから、別にこのまま続けてもかまわないけど、
なんでこのスレでEPICの話しようと思ったの？
0340名無しさん＠お腹いっぱい。05/02/21 00:10:58
分岐ヒントって?
コンパイラが可能な限り並列化して並べたたコードを、プロセッサはひたすら６命令同時実行で処理する
というイメージじゃなくて。
0341名無しさん＠お腹いっぱい。05/02/21 00:16:58
>>339
Niagaraの設計思想について、上の方で詳しく書かれてたから、
そういう方は他のCPUについてどう考えているいるかなと思ってカキコしますた。
迷惑だったらスマソ。
0342名無しさん＠お腹いっぱい。05/02/21 00:36:00
−直近20レス総括−
何事もシンプルイズベストにならない。
Sunの思惑はこれからも外れまくる。
0343名無しさん＠お腹いっぱい。05/02/21 00:52:35
>>340
なんだ、Itaniumの分岐命令の.spnt/.sptk/.dpnt/.dptk
コンプリータの話をしてるかと思ったら違ったのか。

君、実は>>336の書いた内容を全然理解してないね。

それ(コンパイラが並列実行可能な命令を並べる)は、
VLIWのアイディアそのもの。
並列実行可能な命令を、プロセッサがただ単に実行
するという点に関しては、VLIWとEPICには、何の
違いもない。

EPIC の VLIW との違いは、バイナリ互換性を保つよう
にした点。
0344名無しさん＠お腹いっぱい。05/02/21 00:58:28
Sunのお偉いさんの頭脳にこそEPICが必要である。
0345名無しさん＠お腹いっぱい。05/02/21 01:05:58
早々とItaniumを見切ってSolarisの移植を止めたSunの判断は間違っていなかった。
0346名無しさん＠お腹いっぱい。05/02/21 01:06:27
まぁ発言の互換性はとれててほしいな
0347名無しさん＠お腹いっぱい。05/02/21 01:14:04
俺は>>251(つまり一介のソフト屋、CPUは全然専門じゃない)
なんだが、Itaniumについては正直複雑な気持ち。

命令セットは、高速化に関して思いつくことは
全てやりましたって感じで頑張ってることは分かる。
1972年の8008の時代から延々と続く互換性だけがとりえの
x86(もっとも商売としては互換性が一番だいじだし、半導体
の世界では、一番沢山売れて一番沢山開発費が投入できれば、
必然的に一番速くなるので性能にも寄与する)に比べれば、
Itaniumの命令セットのほうが遥かに合理的だとは思う。
0348名無しさん＠お腹いっぱい。05/02/21 01:15:06
ただ、とにかく頑張ってるから非常に複雑なんだよなあ。
Intelって本流のプロセッサでは、iAPX432にしても80286の
セグメント機構にしても、なんかあさっての方向に無駄に
頑張ってしまう傾向があるように思う。
まあItaniumの場合はHPの方が大きく関わってるみたいだし、
セグメント機構とは違い、Itaniumのアーキテクチャは、
合理的な選択の積み重ねなんだが。

個人的にはAlphaみたいに、シンプルな命令セットが好きなん
だよ。初期のMIPSとか、今だとTransmetaのように、トータル
システムとしての最適点を考えて、インターフェースの境界面
を上下に移動するってやり方も好き。
POWERは全然シンプルじゃないのでどちらかというと嫌い。
0349名無しさん＠お腹いっぱい。05/02/21 01:21:41
Niagaraのような構成の方が解として最適点だと分かった場合、
Itaniumの複雑さが、むしろ足をひっぱることになるかもしれ
ないという気がするんだよなあ。
IPC向上の方向に過剰適応した恐竜というか。

現時点で、IPCで判断すれば最速なのは疑う余地はないんだが。
0350名無しさん＠お腹いっぱい。05/02/21 02:17:53
本格的にマルチコアマルチスレッド時代が到来せん事には分からんです。
でも到来したところでopteronのスケールメリットに圧倒されて鳴かず飛ばずって気がする。
マルチコア化とHT-Linkの拡張を同時にやってくるから、対抗するのは相当厳しいんじゃ？
向こうはコンシューマと共通のコアが使えるからスケールメリット効くし、
それに多少性能が優れていた所でクラスター化されたらCPでは太刀打しようがない。
0351名無しさん＠お腹いっぱい。05/02/21 16:17:21
Intel、CPUのI/O高速化技術「I/OAT」を発表
ttp://www.itmedia.co.jp/news/articles/0502/21/news009.html

こういうのってSunの市場にどれだけ影響あるんだろ…
0352名無しさん＠お腹いっぱい。05/02/21 17:06:35
TCP/IPのオフロードをNICに持たずにCPUに持たせることが
どういうメリットがあるのか書いてないような。

コンポーネント間の依存が強まってIntelプラットフォームを売りつけよう戦略
なだけ、というような話はないとは思うけど。
0353名無しさん＠お腹いっぱい。05/02/21 20:39:06
NICに対するCPU側の処理を行うために、
並列に動く専用のadd-onを増設したって事でしょう?

NICの仕事をCPUに持ってくるわけじゃない。
0354名無しさん＠お腹いっぱい。05/02/21 20:55:21
>>353
それを普通は(高価いNICでは)NICに持たせるんだけど。
0355名無しさん＠お腹いっぱい。05/02/21 20:57:13
じみだけどNiagaraに入れると(・∀・)ｲｲ!!とかにならない?
Niagaraを搭載するマシンだとI/O処理用CPUが別に載る(?)から意味無し?
0356名無しさん＠お腹いっぱい。05/02/21 21:00:35
Intelプラフォーム売りつけよう作戦でしょう。
SATAだってそうだし。
CPUに負荷がかからないようなのは出さない。
0357名無しさん＠お腹いっぱい。05/02/21 21:25:48
>>354
いや、NIC側には入らないCPU側の処理をadd-onにして、
CPU本体と並列処理するんでしょ?
ユーザ空間→カーネル空間→DMA辺りのコピーなど。
0358名無しさん＠お腹いっぱい。05/02/21 21:36:52
>>357
わかってない人は無理しなくていいよ。

0359名無しさん＠お腹いっぱい。05/02/21 22:03:43
intel製NICとセットじゃないと動かなそうだな
0360名無しさん＠お腹いっぱい。05/02/21 22:14:24
355のおいらもよくわかってない人です。
これって
・I/O専用CPUをメインCPU(or M/B)にいれようとしてるだけ
・NICのLSIに実装しているバスマスター機能をCPU(or M/B)に移動
って感じですか? それともまったく違う構成をとろうとしてる?
わかりやすく教えてください。
0361名無しさん＠お腹いっぱい。05/02/21 23:47:16
難しすぎてサパーリわからんのだが
少し前のレスを質問させて。
251>> 1つは熱。マイクロアーキテクチャで頑張ってトランジスタ
251>> を2倍使っても、性能は1.4倍くらいしか増えない。
ここでいうマイクロアーキテクチャって微細加工って意味ですか?
■ このスレッドは過去ログ倉庫に格納されています