トップページ⇒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/
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
0190名無しさん＠お腹いっぱい。2005/12/25(日) 01:02:25
SPARC64V の演算器が６つもある件について
0191名無しさん＠お腹いっぱい。2005/12/25(日) 02:58:50
>>179
分岐命令が来たらどーすんの。

そういった問題点を1つずつ解決していくと、
気がついたら、既存のマルチスレッド技術と同じものになってる。
0192名無しさん＠お腹いっぱい。2005/12/25(日) 04:18:37
>>190
整数演算系2セット、浮動小数点系2セットだけど？
01931782005/12/25(日) 04:49:48
>>190
こんなものを見つけました。
ttp://primeserver.fujitsu.com/primepower/catalog/data/pdf/sparc64_v_j.pdf
同時実行４命令、並列に動作するのは整数の算術論理演算２つ(EXA, EXB)、load/store
命令２つ（アドレス生成用にAGA,AGBを使うらしい）、浮動小数点命令２つですね。
load/storeが２つ同時に動くというのはrisc系cpuとしては凄いと思いますが、
やはり演算（科学技術系は考えていませんので念のため）の並列性は２−３までで、それ
以上演算器を用意しても意味がないことを知ったHW構成を思いますね。
0194名無しさん＠お腹いっぱい。2005/12/25(日) 11:36:45
>>193
同時issueと演算器複数は、ぶっちゃけcacheアクセスのlatencyをカバーするためで
その並列性は関係ないんじゃないの？
0195名無しさん＠お腹いっぱい。2005/12/25(日) 13:38:13
お前ら知ってる？今日の１５：２５分からだけど
　
　
第50回有馬記念（Ｇ１＝12月25日(日曜)・中山競馬場）　
　
史上最強の"無敗"三冠馬ディープインパクト（ジョッキーは武豊）が
史上初の無敗での四冠達成に挑戦する
　
《有馬記念スタートは１５時２５分》　フジテレビ拡大放送（14:35〜16:00）
　
超人気スーパーホースの歴史的瞬間じゃん
時代の目撃者って感じでさ　
　
　
　
もち彼女と見るよな？(・３・)
　
☆↓祭り会場↓☆ ディープインパクト〜The 74th impact〜
http://ex14.2ch.net/test/read.cgi/keiba/1135438167/
01961782005/12/25(日) 22:37:34
>>194
load/storeでのキャッシュレイテンシによる性能低下を同時に動か
す演算命令の数で改善しようとしても、プログラムそのものの持っ
ているセマンティカルな並列性を越えることはできない。itanium
はこの並列性の上限をコンパイラーで越えられるとしたが、錬金術
に過ぎなかった訳。
　また、本来VLIWは簡素なＨＷが信条のはずなのだが、お化けＨＷ
になって、結局、周波数もあがらず、品質も悪く、予定期間内で設
計できなかったんだよね。これ本末転倒。
0197名無しさん＠お腹いっぱい。2005/12/25(日) 22:41:57
メモリアクセスのレイテンシを覆い隠すだけなら、sparc v9のプリフェッチ
命令でいいじゃん。演算器いらね。
0198名無しさん＠お腹いっぱい。2005/12/25(日) 22:45:04
>>196
いやだから、SPARCなんだから、SPARC64Vで演算器を複数積んでるのは
VLIWみたいな並列性じゃなくて、シングルスレッドの性能を上げるためだってこと

>>197
メモリじゃなくてcacheのlatency
0199名無しさん＠お腹いっぱい。2005/12/25(日) 22:45:40
>>197
プリフェッチ命令だけですべてうまくいくなら、SMTはいらない訳だ。
だがそうならずNiagaraの登場となった。
0200名無しさん＠お腹いっぱい。2005/12/25(日) 22:46:05
Javaだと、JIT/Hotspotで、関数インライン展開、ループアンローリング、分岐予測を、
hotspotにダイナミックに実施できるから、VLIWの特性をより活かせるはずだったのにな。
# 非VLIWに打ち勝てないまでも。
Sunとは喧嘩別れしたからな。

Crusoeも死亡寸前だし、VLIWは復活ならずだな。
0201名無しさん＠お腹いっぱい。2005/12/25(日) 22:52:19
Transmeta のやつは内部実装に使ってるだけだからね。改善のメドがたつんならいくらでも変更可能。
外部に見せてるやつはそうはいかない。
02021872005/12/25(日) 22:54:32
>>198
VLIWもsuper scalarも、シーケンシャルな機械語の並びとしての
プログラムが持っている局所的な命令の並列性をうまく取り出す
手段にすぎないんだよ。元の命令の列に並列性がなければVLIWで
もsuper scalarでも1サイクルに１命令しか実行できないよ。

メモリのレイテンシもキャッシュのレイテンシもプロセッサ内の
load/storeパイプがストールするという点では同じと思うが。。。
0203名無しさん＠お腹いっぱい。2005/12/25(日) 22:55:49
(´-`).｡ｏO(なんで Itanium の話のほうが SPARC より盛り上がるんだろうか・・・
0204名無しさん＠お腹いっぱい。2005/12/25(日) 22:58:22
>>203
危機感の表れ。
0205名無しさん＠お腹いっぱい。2005/12/25(日) 23:05:10
SPARC は次の暁が Niagara2 なのでだいぶ先なんだなこれが。
0206名無しさん＠お腹いっぱい。2005/12/25(日) 23:05:11
>>202
VLIWが取り出すのは局所的な命令の並列性だけではないだろ。
投機的実行やトレーススケジューリングはどうなった？
020712005/12/26(月) 01:20:27
>>203
敵を知り己を知れば百戦危うからず
0208名無しさん＠お腹いっぱい。2005/12/26(月) 01:22:51
いちおうIntelもJavaやってはいるんだが…
http://www.intel.com/technology/computing/sw04031.htm
http://orp.sourceforge.net/
0209名無しさん＠お腹いっぱい。2005/12/26(月) 05:01:33
米Sun、「Sun Fire T2000」の無料お試しキャンペーンを開始
http://enterprise.watch.impress.co.jp/cda/foreign/2005/12/22/6917.html
0210名無しさん＠お腹いっぱい。2005/12/26(月) 05:51:42
> 投機的実行やトレーススケジューリングはどうなった？

別にVLIWだけでなく、投機的実行なんて、大抵のCPUはやってる。
たとえば、SPARC64なんて、OoOやspeculative executionしまくりでは？
それに、memory latencyやcache latencyによるストールをカバーするために
別命令を実行するっしょ。
0211名無しさん＠お腹いっぱい。2005/12/26(月) 06:26:50
>>206の言っているのは、コンパイラに任せることで、
それを例えば関数単位くらいの大域性を持たせることができるということでしょう?

まあ現実にはあまり効果がなかったみたいだが…
0212名無しさん＠お腹いっぱい。2005/12/26(月) 09:24:54
Itanium2(w のこれついに導入開始みたい。
http://www.nikkei.co.jp/news/sangyo/20051224AT1D2400Y24122005.html
http://www.itmedia.co.jp/enterprise/articles/0412/09/news033.html
■ このスレッドは過去ログ倉庫に格納されています