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

Sun Microsystem 最大の遊撃

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2005/12/08(木) 17:43:05
今更「オープンソース」とか言い出したり、
　…でも「OpenSolaris-Closed-Bins」って一体…（´Д`;）

今更「Ultra20」とか言い出したり、
　…でも「"Ultra"SPARCではなくOpteron」って一体…（´Д`;）

Fujitsu製造のSPARC64V,
AMD製造のOpteron,
TI製造のNiagara(UltraSPARC T1)などと矢継ぎ早にCPUを模索しているが、
これは縦読みで、製品群が"FAT"になる暗示か？w

【前スレ】
Sun Microsystems 最後から二番目の真実
http://pc8.2ch.net/test/read.cgi/unix/1127872934/
0090名無しさん＠お腹いっぱい。2005/12/18(日) 01:25:29
結局

> VMが２段になる

の意味は?
BEAのを使えば1段で済むわけだよねえ。
0091名無しさん＠お腹いっぱい。2005/12/18(日) 02:37:24
IA64winでX86winのjavaアプリを動かす。→1段。
しかしx86javaVMは今までX86命令を直に実行していたItaniumではなく、
Montecitoのエミュレーションx86環境で実行される。→2段
って言いたかったのかしら?とjavaって何?の俺が強引に解釈してみる。
0092名無しさん＠お腹いっぱい。2005/12/18(日) 06:51:33
Niagara搭載WSを出さないのは、PC-UNIXヲタに実用的な多CPU環境を
安く提供してしまうことになるから。
0093名無しさん＠お腹いっぱい。2005/12/18(日) 07:15:35
それのどこがまずいの？ハードが売れればSunとしては万々歳じゃん。
Solarisに対抗するOSが成長する環境を与えるのがまずいってことかしら？
0094名無しさん＠お腹いっぱい。2005/12/18(日) 09:09:30
>>89
>SunのJDKはガべコレのアルゴリズムがシングルスレッドなので
>コアを増やそうがチップを増やそうがGCにかかる時間は短縮されない。
>#GCの間はアプリが停止する

ダウト
0095名無しさん＠お腹いっぱい。2005/12/18(日) 09:19:26
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
0096名無しさん＠お腹いっぱい。2005/12/18(日) 10:20:37
>>92
真のPC-UNIXオタなら鯖でも買うと思うよ
今のNiagaraは浮動少数が弱すぎてWS向きじゃないのが欠点でしょう
0097名無しさん＠お腹いっぱい。2005/12/18(日) 11:46:37
>>89
今は、new/old世代両方とも平行でいける。
0098名無しさん＠お腹いっぱい。2005/12/18(日) 17:01:23
>>91
それでOK。

>>97
スループットコンピューティングの石を出すにあたり、
さすがにそれはマズいだろうという事になった訳ですね。
0099名無しさん＠お腹いっぱい。2005/12/18(日) 18:16:22
実行状態のスレッドが32個にもなると、ストレージまわりが大変そうよ。

1つずつ順番にやっていけば、シーケンシャルアクセスになるのに、
32個も同時にやったら、ランダムアクセスになってしまう。

ワークステーションみたいに、HDDが1台、という環境では辛そう。
0100名無しさん＠お腹いっぱい。2005/12/18(日) 18:23:33
そんなタコい作りのカーネルなんてあるの？UNIXにはなさそうだ。
0101名無しさん＠お腹いっぱい。2005/12/18(日) 18:35:14
標準だとT1000でHDDは1台T2000でHDDは2台しか積んでいないよ。>>99
0102名無しさん＠お腹いっぱい。2005/12/18(日) 19:17:26
IOスレッドが多い状況だとIOを強化すべきでそれこそNASやファイルサーバ専用機の出番じゃないの
0103992005/12/18(日) 20:35:41
>>100
過信しすぎ。

もしカーネルがなんとかしてくれるなら、
15,000rpmのHDDは不要
バッテリーバックアップ付きのRAIDコントローラ不要
ってことになるぞ。

>>101
だから、ローカルのストレージはOS用。
0104名無しさん＠お腹いっぱい。2005/12/18(日) 20:45:41
時代はシリアル化へと。
0105名無しさん＠お腹いっぱい。2005/12/18(日) 21:09:10
ケロッグの時代キター
0106名無しさん＠お腹いっぱい。2005/12/18(日) 21:14:39
ディスクI/Oのボトルネックで影響が大きいのはデータ転送時間ではなく、
シーク時間。古くはエレベータアルゴリズムでなんとかしていた分野だから、
特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。
シーケンシャルなアクセスでもバッファメモリ管理の領域だから、
やっぱりカーネルががんばるべき領域。
回転数とかバッテリバックアップとかは全然関係ないだろ。
まあ今はコマンドをタグ化して送っておいて、ディスクのコントローラが
自動的にヘッド移動を最適化してくれるわけだから、
「15000rpmも出せる高級なディスクではそういう高速動作も期待できる」という意味なら
分からないでもない。
0107名無しさん＠お腹いっぱい。2005/12/18(日) 21:38:57
>>98
結構前からだよ。
0108名無しさん＠お腹いっぱい。2005/12/18(日) 21:42:38
>>106
> 特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。

いやディスク・クラスターの領域です。スパコンでは常識。
東工大の奴はCluster File Systemsの。
0109名無しさん＠お腹いっぱい。2005/12/18(日) 21:48:16
>>108
その辺は Solaris 君は考慮済なんじゃねーの? 非同期 I/O ってやつ?
0110名無しさん＠お腹いっぱい。2005/12/18(日) 22:28:40
カーネルだけじゃどうにもならないという話です。
0111名無しさん＠お腹いっぱい。2005/12/18(日) 22:33:26
>>108
>>99はT1000の話をしてたと思うんだけど。
0112名無しさん＠お腹いっぱい。2005/12/18(日) 23:21:29
だから、T1000を何本ものラックにぎっしり詰めて、クラスタ処理する話でしょ?

ちなみに、整合性を確保するために、
書き込み順序を保証しろとか、ライトスルーしろとか、
そういうプログラムは、カーネルが手を出せない。
0113名無しさん＠お腹いっぱい。2005/12/19(月) 00:15:35
いや32というのはT1000単体に乗っているNiagara一個が処理できるスレッドの最大数だから、
複数のT1000を前提にしなくても想定できるケース。
0114名無しさん＠お腹いっぱい。2005/12/19(月) 01:37:22
まぁ、Windowsには絶対無理だな。

あっちは、P2PソフトでHDDの寿命が縮むくらい、カーネルがヘボいから。
0115名無しさん＠お腹いっぱい。2005/12/19(月) 02:42:11
>>99
なんかソフトのスレッドとごっちゃになってないか。
Niagaraに出てくるスレッドはハードレベルの話なので、8コア4スレッドなら
ソフトからは32cpuに見えるはず。

ディスクアクセスはファイルシステム層で、UFSとかのレベルで
最適化されるし、Niagaraについて特別なことはないかと
0116名無しさん＠お腹いっぱい。2005/12/19(月) 07:22:32
Linus様が anti-IPF 宣言を…
Ita上の UNIX系 OS では Linux が唯一の希望なのに…
ttp://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=3941&Thread=68&entryID=60298&roomID=11
0117名無しさん＠お腹いっぱい。2005/12/19(月) 07:32:27
IBMのワンワンだから
0118名無しさん＠お腹いっぱい。2005/12/19(月) 09:47:10
SGIは頑張れ。
0119名無しさん＠お腹いっぱい。2005/12/19(月) 10:05:18
>>116
こんなボクちゃんのタワゴトで大勢してあっち向いたりこっち向いたり... sigh。
IPF って Ita Processor Family の略? やめてよねこんなしょーーもない略語作るの。
0120名無しさん＠お腹いっぱい。2005/12/19(月) 11:43:25
最近の PostgreSQL ってすげーなぁ。
T2000 で MP 活かせない 8.0 と改善されてる 8.1 の比較やったら
Niagara のありがたさもキワダツんじゃね? キョーミあるぜ。

【PostgreSQLウォッチ】第23回 本当に速いPostgreSQL 8.1
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051213/226148/
0121名無しさん＠お腹いっぱい。2005/12/19(月) 13:46:00
>>116
そりゃ、Linuxはgccにおんぶにだっこだから。
gccが出力するIA-64コードは、とても遅いのよ。

それに加えて、IA-64はx86ほど昔の技術ではない、というのもあるかも。
RISC以上にハードからソフトにお仕事の比重が移っているし、
高可用性やプラットフォームの違いを吸収することを前提としたアーキテクチャで、
そのためのレイヤや処理が必要だったりもするし。

でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。
0122名無しさん＠お腹いっぱい。2005/12/19(月) 15:19:09
IPFならIntelのコンパイラ使えばいいやん
gccにこだわりがあるのかネェ
0123名無しさん＠お腹いっぱい。2005/12/19(月) 15:27:25
IntelがIPF専用Linuxディストリをつくればいいんだ
0124名無しさん＠お腹いっぱい。2005/12/19(月) 16:25:32
Linuxカーネルはpatchあてないとgccしかコンパイルできない。
http://www.pyrillion.org/index.html?showframe=linuxkernelpatch.html
0125名無しさん＠お腹いっぱい。2005/12/19(月) 17:05:15
>>121
> でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。
ああ、昔からアセンブラの方が速いとかシステムコールのパラメーターはチェックしなくていいとか
シェアードライブラリは固定数値使ってていいとか仮想記憶をオーバーコミットできないように
する必要はないとか、いろいろ言ってるよ、彼は。
関係ないけど、「氏」つけるんなら Family Name の方じゃないか普通?
0126名無しさん＠お腹いっぱい。2005/12/19(月) 19:49:29
だれかリーナスをシメてこい
0127名無しさん＠お腹いっぱい。2005/12/19(月) 22:11:38
　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ
　　/　　●　　　● |　
　 |　　　　( _●_)　 ミ 　　　俺がやるクマー
　彡､　　　|∪|　　､｀＼
/　＿＿　 ヽノ　/´>　 ) 　　
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　 （　 ＼
　　　　　　 ＼＿)

0128名無しさん＠お腹いっぱい。2005/12/19(月) 22:15:07
　　　　　　　　　　　　　　　　　　　　　　＿ ／-　イ､_
　　　　　　　　　　 ＿＿　　　　　 　　／: : : : : : : : : : : (
　　　　　　　　　 〈〈〈〈　ヽ　　　　　/: : : : ::;:;: ;: ;:;: ; : : : ::ゝ
　　　　　　　　　　〈⊃　　}　　　　　{:: : : :ノ　--‐'　､_＼: : ::｝
　　 ∩＿＿＿∩　 |　　 |　　　　　 {:: : :ノ ,_;:;:;ノ､ ェｪ ヾ: :::}　　
　　 | ノ　　　　　 ヽ !　　 !　　　、　　ｌ: :ﾉ　／二―-､　|: ::ﾉ
　　/　　●　　　● |　　/　　　，,･_　　|　/／　 ￣7/ /::ノ
　 |　　　　( _●_)　 ミ／　, ’,∴ ･　¨　 〉(_二─-┘{／
　彡､　　　|∪|　　／　　､･∵ ’　　／､／/|　￣￣ヽ ←Linus
/　＿＿　 ヽノ　/　　　　　　　　 ／　　 //　|／／＼ 〉
(＿＿＿）　　　/　　　　　　　 　/　　　 //　　 /＼ ／
0129名無しさん＠お腹いっぱい。2005/12/19(月) 22:31:59
カーネルをgccでコンパイルしてても、それでアプリケーションの動作が
遅くなるもんなのかな。minixのコードくらいしか知らないで言うのもの
なんだが、コンパイラの最適化によってOSの性能が大きく変わるような
とこって何？ファイルシステムのマルチリストの扱いとか？
0130名無しさん＠お腹いっぱい。2005/12/19(月) 23:38:32
いまさらだが…
なぜItaniumの話に？
0131名無しさん＠お腹いっぱい。2005/12/20(火) 00:04:34
>>116 に訊け
0132名無しさん＠お腹いっぱい。2005/12/20(火) 00:12:29
>>129
gcc で -O0 してできたカーネルと比べてみればいいのでは。C で書いてあって
頻繁に使われるとこは効くと思うよ。ファイルシステムとかネットワークとか。
メモリ割当もかな? Linux じゃ DTrace できんが。
0133名無しさん＠お腹いっぱい。2005/12/20(火) 05:37:35
gccはGenericなコンパイラなので、Itaniumに特化したプリディケーションやスペキュレーション
みたいな機能をうまく使いこなす様にできてないんじゃないの?
リーナス自身がソフトでごちゃごちゃやるより、IBMみたくハードでなんでもやっちゃう方が好きだとか。

>>132
つttp://sources.redhat.com/systemtap/
0134名無しさん＠お腹いっぱい。2005/12/20(火) 17:30:21
IA64やEM64TのJavaは、
MicrosoftがAMDと天秤にかけて、
サポートを弱くするようIntelに迫ったという噂がある。
http://pc.watch.impress.co.jp/docs/2004/0218/intel.htm
0135名無しさん＠お腹いっぱい。2005/12/20(火) 17:57:26
>>134
参照張ってある記事と言ってることになんの関係もないようだが。
0136名無しさん＠お腹いっぱい。2005/12/20(火) 18:18:51
>>129
Itaniumは他のCPUと比べてコンパイラでの最適化の効果が大きいというか
最適化しないと遅くて性能が発揮できないということじゃないか？
0137名無しさん＠お腹いっぱい。2005/12/20(火) 20:15:19
今時のCPUがハードで頑張ってる先読みやリオーダリングを
コンバイラにやらせて、ハードは楽をしようっていうCPUだからね
0138名無しさん＠お腹いっぱい。2005/12/20(火) 20:36:39
米グーグル、時価総額でＩＢＭ抜く−ＡＯＬへの出資合意を好感
http://www.bloomberg.com/apps/news?pid=90003017&sid=a.Zn8c4L_13g
0139名無しさん＠お腹いっぱい。2005/12/20(火) 21:50:05
IBMの技術者は、苦労してハード側で匠な実装を施してるのに、
分岐パターンを始めから全部実行しといて、分岐条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのアイテニアムは許せんらしい。
0140名無しさん＠お腹いっぱい。2005/12/20(火) 21:59:39
Sunのユーザーは、苦労して社内で匠な実装を施してるのに、
ヒトもモノも始めから全部用意しといて、リストラ条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのIBMグローバルサービスは許せんらしい。
0141名無しさん＠お腹いっぱい。2005/12/20(火) 22:35:31
なんかイカス
0142名無しさん＠お腹いっぱい。2005/12/21(水) 00:05:20
>>136
結構肝心な部分はアセンブラで書いてあるから、「そんなに効き目あるのか?」ってことだと
思うよ。スケジューラーや割り込み扱いあたりはアセンブラだからね。
アセンブラで書いてあるからにはコンパイラは関係ないけど、そもそもそのアセンブラの
記述自体で EPIC 活かすのは大変だ（≒不可能?）ってことでしょ。
＃ アセンブラで書く... アセンブリ言語で書く、が正しい?
01431342005/12/21(水) 00:30:02
>>135
↓これと間違えた…
http://pc.watch.impress.co.jp/docs/2004/0130/kaigai059.htm
0144名無しさん＠お腹いっぱい。2005/12/21(水) 21:55:09
システム設計ではハードで実装する機能とソフトで実装する機能の切り分けを行なう訳だが
今後益々複雑化する機能の実装を、限界が近付いたプロセスや製造コストの高く付くハード側に振らないで
ソフトに振るというのもアリだと思うのだが。
0145名無しさん＠お腹いっぱい。2005/12/21(水) 22:23:32
? 主旨が不明だが、分担がハードヘ行ったりソフトへ戻ったりってのは常に繰り返されてるよ。
グラフィックスや外部記憶 I/O とかでもね。
それと、ただただクロックアップだけここ数年やってきた特定の某企業が自分とこが
行き詰まったからってどこも同じだと言ってるけど、これはわかんないよ。
クロックアップと構造の工夫の両方をやりつつこれまでも「限界」と言われてたところを
乗り越えてきてるわけで、ここ数年はライバルがあらわれたことでナリフリかまわず
クロックアップだけやってきてるから、まじめに工夫しながら今 2GHz すぎあたりの
グループ（某系以外全部だけどね）が 3GHz 越えるくらいにはまた限界が先へ延びるかも知れない。
0146名無しさん＠お腹いっぱい。2005/12/21(水) 23:49:17
Gate長が狭すぎてVthのコントロールが難しいとか言ってた今までの限界とはもう次元が違うよ。
30nm、15nmといったら分子サイズだから、これを越えるともう歩留りを保つだけのリソグラフィ技術が
ついてこれないと思うよ。
0147名無しさん＠お腹いっぱい。2005/12/22(木) 10:07:36
>>146のようにとやかく予言していた学者たちは皆シリコンバレーに敗退した。
1GHzは無理だとか言っていた人たち、どこいったんだろ。
熱雑音やショットノイズが問題になるくらいまではなんだかんだ言って
いくかもしれないじゃん？
0148名無しさん＠お腹いっぱい。2005/12/22(木) 10:57:39
IA64は、幾らEPICっていっても、ベースがVLIWだから
命令セットの互換性での性能の犠牲がいや。

ISAを拡張するならまだしも、互換性のためにEPICの
ようなことをしなきゃいけないのが、不自然。

この頃は、pipelineすらなくcoreとthreadをswitch
することでmemory latencyをカバーしようとする
Niagaraが眩しくなってきまつた。。。


0149名無しさん＠お腹いっぱい。2005/12/22(木) 11:07:21
プロセッサが変わったらコンパイルしなおし。GentooLinuxや*BSDなら常識。
0150名無しさん＠お腹いっぱい。2005/12/22(木) 11:23:35
> この頃は、pipelineすらなく

おいおい、pipeline はあるぞ。6段と、今どきのプロセッサとしては短めだが。
Itanium 2 も pipeline はかなり短い方だけど、それでも8段ある。
0151名無しさん＠お腹いっぱい。2005/12/22(木) 11:33:20
OS/360に戻りなさい。
0152名無しさん＠お腹いっぱい。2005/12/22(木) 15:38:04
>>147
そんでもって、Intel は特定の条件下で 9GHz を現実に動かしてるわけで、
今自分で言ってる「限界」を越える可能性が一番高い位置にいる。そのうち
「ついに限界打破、ぶれいくするー!!」とか発表するわけだ。まさにマッチポンプ。
0153名無しさん＠お腹いっぱい。2005/12/22(木) 18:44:30
>>152

動作してても、電子垂れ流し状態じゃないの？
現実には意味ないでしょ。
0154名無しさん＠お腹いっぱい。2005/12/22(木) 19:19:04
>>153
現在において意味がないことと、将来にわたって意味がないことが
同値であることを証明せよ。
0155名無しさん＠お腹いっぱい。2005/12/22(木) 20:05:12
>>154

製造／工学的な改良では、現在のレベルからは前に進めないでしょ。

でも、今までは、従来の物理理論に立脚する製造／工学的な改良による
進歩でムーアの法則があったわけだけど、量子レベルで干渉するところ
まで来ると、物理理論から出直す必要があるわけで、それは今やっている
ことと直接のつながりがない。

だから、発想の転換でNiagaraのようなMulti coreなものが出て来るわけで、
これだと、従来の発想の延長でよいので、今までの製造技術がそのまま
使える。


0156名無しさん＠お腹いっぱい。2005/12/22(木) 21:22:38
笑っちゃうなぁ、量子レベルの問題とは。従来の物理理論ってなによ？
古典電磁気学のこと？マクスウェル方程式は（今のところ）正しいぜ？
0157名無しさん＠お腹いっぱい。2005/12/22(木) 21:27:25
なるほど、Intel は全く意味もないのに巨大なリソースつぎこんで環境作って 9GHz 動作してみたんだ、
へぇ〜そこまで気が狂ってたのか気の毒に。だって意味ないのに..w
0158名無しさん＠お腹いっぱい。2005/12/22(木) 21:43:26
>>155=157
自演乙。
0159名無しさん＠お腹いっぱい。2005/12/22(木) 21:44:31
>>156

量子物理学
0160名無しさん＠お腹いっぱい。2005/12/22(木) 21:47:31
なにもそんなに自分の無知をさらさなくても・・・
01611572005/12/22(木) 21:47:52
>>158
いやいや、155 さんは Intel & Itanium 擁護したい人ですよ。別人です。
01621572005/12/22(木) 22:11:43
あっ、ちがうな、Intel & NetBurst(Pentium4) 擁護したい人か?
0163名無しさん＠お腹いっぱい。2005/12/22(木) 23:22:20
何だこのアホ臭い展開は…
01641572005/12/22(木) 23:26:44
>>163 この人が 155 でしょう。
0165名無しさん＠お腹いっぱい。2005/12/22(木) 23:35:04
Itanium、これから伸びると思う？
0166名無しさん＠お腹いっぱい。2005/12/23(金) 00:19:38
そういえばIBMは3年前にゲート長6nmのトランジスタ開発してますな

米IBM、現在の10分の1となるゲート長6nmのトランジスタを開発
http://pcweb.mycom.co.jp/news/2002/12/10/18.html
【IEDM2002レポート】IBM、ゲート長6nmのトランジスタの詳細を発表
http://pcweb.mycom.co.jp/news/2002/12/12/19.html
0167名無しさん＠お腹いっぱい。2005/12/23(金) 00:34:32
おまいら散毎苦濾の話を汁
0168名無しさん＠お腹いっぱい。2005/12/23(金) 00:48:58
>>164
何故そう思ったのかわからんが，とりあえず違う
0169名無しさん＠お腹いっぱい。2005/12/23(金) 01:00:50
>>165
HP次第だけど多分NO
0170名無しさん＠お腹いっぱい。2005/12/23(金) 08:33:03
Itaniumの目的は自分の市場を小さくすることです。
017112005/12/23(金) 09:10:13
>>170
製造技術に飽き足らず、市場までシュリンクしているのかw
0172名無しさん＠お腹いっぱい。2005/12/23(金) 09:25:21
Montecito が当初の予定通り2004年に、予定通りのクロックで出てればねえ…
2年遅延して、クロックが予定以下だからな。Xeon とのプラットフォーム統一
も延期になっちゃったし…

2005年にMontecito用のサーバを用意してﾜｸﾜｸして待ってたメーカー、ｶﾜｲｿｽ
0173名無しさん＠お腹いっぱい。2005/12/23(金) 10:14:39
せめて倍ぐらいの性能出ないとね。四苦八苦してみようかという気がしないってことでしょ、
RISC 登場したときと違って。x86 から大挙して移行が起こって価格が下がる、ってシナリオが
消えてなくなった今ハイエンド向けチップを Intel が維持する意味があるのか??
やめるんなら早いうち、って意見も内部で出てんじゃね?
0174名無しさん＠お腹いっぱい。2005/12/23(金) 13:18:19
V100系の低価格ラインナップは消え行く運命？？
0175名無しさん＠お腹いっぱい。2005/12/23(金) 13:41:39
AMD64がブレイクしているからねぇ。
もうItaniumはいらね。

AMD64でスパコン組めるんだったら、
Itanium使うより全然安いじゃん。

0176名無しさん＠お腹いっぱい。2005/12/23(金) 14:41:46
まあ将来性という点では x86 拡張より IA-64 の方がブがあるんだろうけど、
そもそもがぶっちぎりの性能とそれをアテにした最速 x86 とハれる
x86 エミュレーションつーのが大前提だからね。かなり昔に崩れ去ってるんだけど、
全リソースを注ぐことも（やってたら会社終わってたかもね）、バッサリ切ることも
しなかった。大企業病だろうね。
0177名無しさん＠お腹いっぱい。2005/12/23(金) 15:03:47
ｈｐはもう終わりってことかね？
SUNおいしいな。
0178名無しさん＠お腹いっぱい。2005/12/24(土) 13:10:23
VLIWなら高い並列性を安価に実現できるのは事実だが、
所詮、普通のアプリケーションでは、演算命令を同時
に２−３個も発行できれば十分で、それ以上は無用の
長物というのもsuper scalarの時点でわかっていた
こと。現実を無視した技術論にユーザ含めて踊らされた
ってことだ。このツケは結局intel製品の価格に跳ね
返ってくるのだから、エンドユーザが支払っている。
0179名無しさん＠お腹いっぱい。2005/12/24(土) 13:32:07
プロセスまたいで命令がパック出来れば面白いんだけどね。
TransmetaのCMSってこういうの出来るのかな。
0180名無しさん＠お腹いっぱい。2005/12/24(土) 13:35:15
別プロセスだと、アドレス空間も分けなきゃいかんから無理でしょ。
0181名無しさん＠お腹いっぱい。2005/12/24(土) 16:45:02
Itaniumがヘボイんじゃなくて、コンパイラがまだまだということなんじゃないの？
ハードが非現実的なソフトウェアの課題を要求してるという意味じゃハード側にも
責任がありそうだけど。
0182名無しさん＠お腹いっぱい。2005/12/24(土) 17:07:35
Itanium支持者が多いのかItaniumがこけると困る人が多いのか知らないが
ここはSUNのスレでItaniumはスレ違い

Itaniumの話はここでどうぞ
http://pc8.2ch.net/test/read.cgi/hard/1126713905/
0183名無しさん＠お腹いっぱい。2005/12/24(土) 17:51:17
SPARC の敵はもはや Itanium と POWER しかいないのでここでいいやん。
敵を知るものは汁物であたたまろう。
0184名無しさん＠お腹いっぱい。2005/12/24(土) 17:58:04
>>178
> ってことだ。このツケは結局intel製品の価格に跳ね
> 返ってくるのだから、エンドユーザが支払っている。
そうそう、x86 な CPU は安いっていうけど、もっと上品な RISC 2 つが健全な競争を
くりひろげてればコストパフォーマンスは今よりずっと高い可能性がある。
自然とそこへ行き着かないのは業界の構造に問題があるんだよ。法律で誘導すべきだね。
0185名無しさん＠お腹いっぱい。2005/12/24(土) 21:18:11
>>プロセスまたいで命令がパック出来れば面白いんだけどね。
プロセスまたいで空いた演算器を有効利用するって発想は
SMT技術じゃん。itanium は niagaraに滅ぼされるのかもね。
01861782005/12/24(土) 21:26:25
>>Itaniumがヘボイんじゃなくて、コンパイラがまだまだということなんじゃないの？
現実のアプリケーションでの演算の並列度が２−３なので、それ以上いくらコンパイラ
ががんばって命令を並び換えても４つ以上の演算器を使いきるための並列度を引き出せ
ないのですよ。
だからitaniumの高速性の宣伝に使われるのは、暗号化など、本質的に演算の並列度の
高い一部のアプリケーションだけでしょ。
0187名無しさん＠お腹いっぱい。2005/12/24(土) 23:33:21
わかった、じゃ Itanium 機は世界に 5 台だけ残して、暗号演算は全部そいつらにやらせよう。
0188名無しさん＠お腹いっぱい。2005/12/25(日) 00:00:04
特定の暗号計算のアルゴリズムなら、CPUにやらせるよりも専用回路に
やらせた方が速い。Niagara は実際、そういう回路を積んでるしね。
0189名無しさん＠お腹いっぱい。2005/12/25(日) 00:49:41
えええっ?? それじゃ Itanium の居場所はほんとにないじゃーーんww
■ このスレッドは過去ログ倉庫に格納されています