Sun Microsystem 最大の遊撃

**名無しさん＠お腹いっぱい。** · 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/

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 17:43:54

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 18:50:41

Sun get!!

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 21:30:32

　　　　　　　　　　　　　　　　　　　　　　γ　　　　γ
　　　　　∧__∧　もうﾀﾞﾒﾎﾟ・・・　　　　　　　　　　　　　γ
　　　　（::::::::::: ）　　　　　　　　　　　　　　　...................................
　　　　.（○::::::: ）　　　　　　　　　　　 .::::::::;;;;;;;;;::::........
　　　 ~"''"""゛"゛""''･、　　　　　　 ...:::;;;''　　　　 ';;;:::::.......
"゛""''""""゛゛""''' "j'　　　　　　　...::::;;;''　　　　　　 '';;;::::::........
::::ﾍ　:::::....ヽ :::;;;ﾉ　 ::(　　　　　　....::::::;;　　　　　　　　 '';;;::::::.......
:　ゝ　　:::::......ﾉ:;;..／　　~~^^~~~~~^^~^^　~~^^　~~~~~^~~~~^

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 22:20:23

Ultra５

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 22:50:49

今後スレタイはs/最後/最大/なのか？

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 22:52:11

最後のhogeにして立てなおす？
おまけに Sun Microsystems (s)抜けてるし

1 · 2005/12/09(金) 00:02:36

>>6-7
どうも1です。

初心に返って「最大」にしてみましたが、初代スレからコピペした時に
"s"が欠落したまま立ててしまいました。

立て直して頂けるのならば、まだ前スレが少し残っている今のうちに
お願いします。

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 00:27:54

欠落してないサンなんて嫌

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 00:36:20

いっそ単数形でしか現せないように、製品ラインナップを練り直せ

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 00:47:18

会長、ごケツ暖を!

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 00:50:29

いいよこのまんまで。

**スコット・マクネリ** · 2005/12/09(金) 01:22:51

このままでいいよ。
資源は大切に。時代はecoですよ。

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 01:32:21

もうナッツ食って冬眠したかと思ってた。

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 07:16:40

>>1
FATが笑うところ？

**名無しさん＠お腹いっぱい。** · 2005/12/09(金) 07:55:54

Ultra20

という重複したネーミングには、困ったね。

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 19:51:52

Sun、サッカーワールドカップで日本を北朝鮮と報道！

http://www.thesun.co.uk/article/0,,2002390000-2005570245,00.html

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 20:01:22

GROUP F
Brazil

Croatia

Australia

Korea Republic

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 20:36:46

Sun Microsystems 最大の皮肉

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 20:40:21

>>17
サンはサンでも、新聞屋の方のサンじゃねーか、おい

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 22:22:48

Sunは既に太陽じゃないし、"Micro"systemsでもない。

**名無しさん＠お腹いっぱい。** · 2005/12/10(土) 23:33:00

何を言ってる? 90nm だぞ?

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 01:41:05

90nmは、0.09micronですよ。

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 02:14:13

Sun Nanosystem 最大の遊撃

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 09:26:04

Sun Nanosystem 最大の邀撃

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 13:48:01

三枚黒

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 22:37:34

秋刀魚育露

**名無しさん＠お腹いっぱい。** · 2005/12/11(日) 22:43:18

秋刀魚イクラ寿司天むす。

**名無しさん＠お腹いっぱい。** · 2005/12/12(月) 09:45:26

3nm プロセスになったときこそ

**名無しさん＠お腹いっぱい。** · 2005/12/13(火) 18:06:49

3nm プロセスになったときこそ天むすを食うのか？

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 00:09:48

サンマイクロに落日なし

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 00:14:09

梅じゃないんだから

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 15:22:02

確かに落日は無いな。グリーンランドあたりで見かける白夜で
留まっているからな。

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 18:23:38

Niagara+Solaris って、DAW マルチメディア方面にすごく向いてるんじゃないか?
MacOS X や糞doze 向けのアプリばかりだが、あいつらでは多コアはまともに扱えん。
これチャンスなんでわ? CoreAudio と Xcode 移植しろ!
プラグイン音源とかエフェクトアホみたいに組み込んでも平気で稼働できる気がする。

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 19:59:04

いや、サンだからな。糞dozeの方が多コア扱えるの上手くなるよ。
そして再び落日へと

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 20:32:34

NiagaraにFPU が 1 コしか積んでない件はどうなのよ？

暗号化や圧縮処理が弱いのは明らかに不利だぞ

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 20:50:02

あ、そうだった、DAW も浮動小数点値計算だ、現 Niagara じゃダメだ。
Niagara2 の暁にわにわにわとりがはにわ。

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 21:07:42

Webフロントエンドサーバでは、SSLの性能が大事なので、
たしかNiagaraは暗号用の回路を内蔵していた筈。
だから、暗号化に関しては大丈夫じゃないかな。
マルチメディア系には、あまり向かないだろうってのは同意。

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 21:40:44

はにわ？

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 22:09:58

ttp://www.unixuser.org/~euske/doc/niwatori/

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 22:26:40

>>37
Niagara2 is targeted for launch, according to Yen, maybe some time in late 2006 or
early 2007 using 65 nanometer technologies, and Niagara3 is in development now.

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 22:41:39

あれ、Rockはどうしたんだ？

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 23:03:08

the future "Rock" massively multithreaded chips due in 2008

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 23:30:59

Rockはあと3~4年先と考えていいな。
どーせ遅れる。

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 23:39:10

こともなげに「Niagara3と統合した」とRock開発破棄を言い出すに\10万賭けてもいい

**名無しさん＠お腹いっぱい。** · 2005/12/14(水) 23:57:11

めちゃありそう
技術的なウンタラ…で実際は資金難でｗ

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 00:13:37

SSLて実数演算あんのか？
整数演算じゃないのか？

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 00:28:28

SSLなど暗号関係は、ふつう整数だけでしょうね。
ちなみに Niagara の暗号用ハードウェア (modular
arithmetic unit) は、コア毎に1つ、チップ上に8つ
載ってるそうです。

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 00:41:39

よし、じゃマルチメディアの話はまた来年。とりあえず SSL と Java と Web の話だ。きゅー。

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 00:58:37

fmovs %f0,%f0をnopの変りに使っていたけど、
一個を共有しているから、
$(OPENSSL)/crypto/aes/asm/aes-sparcv9.pl
で、$code =~ s/fmovs.*$//gem; してます。

# fmovs instructions substituting for FP nops were originally added
# to meet specific instruction alignment requirements to maximize ILP.
# As UltraSPARC T1, a.k.a. Niagara, has shared FPU, FP nops can have
# undesired effect, so just omit them and sacrifice some portion of
# percent in performance...

ここしか使ってない。> FPU

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 01:00:27

ここら辺によると、
http://blogs.sun.com/roller/page/chichang1?entry=rsa_performance_of_sun_fire
http://blogs.sun.com/roller/page/bmseer?entry=secret_performance
SSL ハンドシェイクで使われる RSA の処理で、
Dell PowerEdge 2850 (3.6GHz Xeon × 2) に比べて、
Niagara は 6～7倍速いらしい。

もっとも、Sun Fire V210/V240 に Sun Crypto 500 SSL accelerator を
つければ、Niagara のさらに数倍速いっぽいけど。
Big-IP あたりの SSL accelerator も同じくらいかな？

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 16:22:00

>>36
暗号化も圧縮もFPU使わないっす。

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 22:25:34

T1000ってHDDを1個しか積めないってのはどうなのよ
Web/アプリ用のサーバだってミラーくらいするもんなんじゃねーの？

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 22:57:18

OSドライブに冗長性が必要な場合はNASからブートさせるとか
ライブドアもそうしてるみたいよ
Tシリーズは箱としてのHAを求める用途には向かないと思う
そういう向きにはIV+ドゾーみたいな

**名無しさん＠お腹いっぱい。** · 2005/12/15(木) 23:37:17

RAID 組むんじゃなくて、2台入れて、それぞれがお互いの
バックアップサーバとして動くようにトラフィックを
振り分けるって感じかねえ。

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 00:41:07

いや、ファイバーで繋いだNASのディスクからブート。

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 01:20:43

え゛ー、SAS じゃなくて? もうフィブレシャネルは終わりだろ。

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 02:27:23

>>55
3wareあたりがやってるRAID1からストライプで読み出すってやつ？

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 10:27:10

>>58
T1000を2台買えってはなしじゃね？>>55のいっているのは。

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 14:55:16

たくさん並べて分散処理する鯖なら、
ローカルのストレージは、
ノードとして動くのに必要なものしか置かない。

**名無しさん＠お腹いっぱい。** · 2005/12/16(金) 23:51:09

>>59
そしたら何か賢い箱を2台の前に置くか賢いソフトでミラーしてやるしかないよね

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 02:42:27

Web サーバやアプリケーションサーバの場合、ローカルに書き込む
ファイルなんてログファイルぐらいなので、複数台用意して冗長性
を確保する状況なら、RAID もバックアップも要らないのでは？

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 02:46:40

ログが消えるのはまずい

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 03:01:04

じゃ、ログもネットワークに投げとけば？

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 15:02:51

niagaraですけど、ちまちましたことを平行していっぺんに、って、
デスクトップにも良いんではないかと思うのですが、ワークステーションは
出ないんでしょうか??

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 15:46:56

SunはもうSPARC積んだWS出す気はあまりないだろ。
niagaraですけど、ちまちましたことを平行していっぺんに
俺としてはそれもありかなぁとは思う。
どーせ、SPARC積んだWSなんて、単体運用より端末として使われる方が多いだろうし。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 15:52:00

>niagaraですけど、ちまちましたことを平行していっぺんに、って、
>デスクトップにも良いんではないかと思うのですが

どのへんが？全然良くないと思うケド

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 16:02:39

Niagalaはどうみても Webサーバとか Oracleみたいなスレッドを
たくさん作って、がーっとやるジョブ向けのCPUじゃん

メールとワードを同時に動かすとか、そういうの向けじゃないよ

68 · 2005/12/17(土) 16:04:00

日本人だから L と R　を間違えるのは仕方ない

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 16:34:19

>>65
個人のワークステーションで、ロードアベレージが32に達する
状況なんてないでしょ。つまり Niagara の性能はワークステー
ションでは全然生きないってこと。
今のところ、ワークステーションではシングルスレッド性能が
大事だから、Opteron の方がいいよ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:30:08

うーん、メールとワードじゃ、いっしょだと思うが。FPU 付きの Niagara2 になったら
マルチメディアで並列も期待できるし、値段いっしょだったら Niagara2 取るけど。オレは。
そもそも今 PowerPC G4 1.25GHz だけど、もっと速いの欲しいとかあんま思わんし。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:44:40

> そもそも今 PowerPC G4 1.25GHz だけど

G4 はスーパスカラでしょ。
Niagara はシングルイシューだから、シングルスレッドだと、
G4 1.25GHz よりも、さらに遅いよ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:57:44

うーーーーん、だとしても、メールとワードじゃいっしょでしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 19:02:56

>>65
その分野のWSではCellがあるからね
PS3が成功すれば少なくともPS3用ゲームの開発マシンとしてそれなりの台数は出るだろうし

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 19:09:38

WSはOpteron搭載でx86-64版 Solarisでいいんじゃないか

65 · 2005/12/17(土) 20:21:34

うーむ、目の前のデスクトップ見て、たいていのものはウィンドウ毎にプロセスが走ってて、
個々のウィンドウの中でもwebブラウザとかはいろんなこといっぺんにやってるよなぁ、
などとふと思ったのでしたが、
68 >>メールとワードを同時に動かすとか、そういうの向けじゃないよ
あ、そういうの向けじゃないんですか。
なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな
話を見た記憶でテキトーなこと書いてました。すんません。

>>74
CellのWS...欲しいです。SolarisでもLinuxでも良いです。出たらいいなぁ。

>>75
w1100使ってるんですけど、ふとしたときにカクカクして、そんときってやっぱり気持悪いんですよね。
w2100にしとけば良かったかなぁ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 20:27:55

T1000/T2000とRay serverの組み合わせってどうよ？

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:13:42

並列化といえばEPICのItanium2が来ましたよ。
先日のItanium Solutions AllianceのDeveloper Daysも
空席の目立つ湿っぽい開催で、Montecitoの発売も来年にズレ込み
相変わらず前途多難な模様でつ。
MontecitoからIA-32はソフトエミュレーションになるので、
VMが２段になるJavaの実行速度を上げる努力をするそうでつ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:24:21

>>70
GNU makeで -j 64すりゃいい。

シーケンシャルなディスクアクセスがぶつ切りになって、
かえって遅くなったりするかもしれないが・・・。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:24:59

>>76
> なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな

それはniceしていないからか、OSがヘボだから。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:35:39

> MontecitoからIA-32はソフトエミュレーションになるので、
> VMが２段になるJavaの実行速度を上げる努力をするそうでつ。

これって、どういう意味? IA64 ネイティブの Java VM がないって意味?
そりゃ Sun にはやる気がないだろうけど、Intel は金ならあるんだから、
Sun に金払って、自力で開発して検証通して JRE を配ればいいんじゃないの?

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:42:11

Intelの友達はSunじゃなくてMicrosoft。
Itaniumに関しては喧嘩別れだし。双方が非難する発表。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:45:11

> Intelの友達はSunじゃなくてMicrosoft。
> Itaniumに関しては喧嘩別れだし。双方が非難する発表。

あまりそういう一面的な見方は禁物かと。
Microsoft は IA32 の 64bit 化では、Intel じゃなくて AMD 側に
ついたし。
Java VM については、Intel が金さえ出せば、Sun は拒否しないんじゃ
ないの? それとも拒否してるって意味?

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:21:05

ttp://www.itmedia.co.jp/news/articles/0512/17/news008.html
IBM、AIXセンター開設

IBMって、Linux に集中してるのかと思ったら、まだ AIX を諦めて
なかったのか。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:24:41

MVSだってまだやってますけど。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:45:00

>>81
IA64 用 JavaVM は BEA がやってるって誰か書いとったやん。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:52:26

JavaのためにItaniumマシン買う人が果たしているのだろうか・・・

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 23:07:18

Itaniumマシンは秀吉が全て壊したので誰も買えなくなった。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 00:03:16

SunはJ2SE5からIA-64版を提供していないので、BEAが提供してる。

ttp://e-docs.bea.com/jrockit/docs50/install/install.html

HPもItaniumマシンではBEAのJDKを使う様勧めておる。

ttp://h50146.www5.hp.com/products/servers/integrity/document/pdfs/PDFHS05013-01.pdf

SunのJDKはガべコレのアルゴリズムがシングルスレッドなので
コアを増やそうがチップを増やそうがGCにかかる時間は短縮されない。
#GCの間はアプリが停止する
デカいApp鯖になるとこれが無視できなくなるので、JRockitではGCのアルゴリズムをマルチスレッド化して
極力アプリの停止時間が短くなる様にしてる。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 01:25:29

結局

> VMが２段になる

の意味は?
BEAのを使えば1段で済むわけだよねえ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 02:37:24

IA64winでX86winのjavaアプリを動かす。→1段。
しかしx86javaVMは今までX86命令を直に実行していたItaniumではなく、
Montecitoのエミュレーションx86環境で実行される。→2段
って言いたかったのかしら?とjavaって何?の俺が強引に解釈してみる。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 06:51:33

Niagara搭載WSを出さないのは、PC-UNIXヲタに実用的な多CPU環境を
安く提供してしまうことになるから。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 07:15:35

それのどこがまずいの？ハードが売れればSunとしては万々歳じゃん。
Solarisに対抗するOSが成長する環境を与えるのがまずいってことかしら？

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 09:09:30

>>89
>SunのJDKはガべコレのアルゴリズムがシングルスレッドなので
>コアを増やそうがチップを増やそうがGCにかかる時間は短縮されない。
>#GCの間はアプリが停止する

ダウト

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 09:19:26

http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 10:20:37

>>92
真のPC-UNIXオタなら鯖でも買うと思うよ
今のNiagaraは浮動少数が弱すぎてWS向きじゃないのが欠点でしょう

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 11:46:37

>>89
今は、new/old世代両方とも平行でいける。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 17:01:23

>>91
それでOK。

>>97
スループットコンピューティングの石を出すにあたり、
さすがにそれはマズいだろうという事になった訳ですね。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:16:22

実行状態のスレッドが32個にもなると、ストレージまわりが大変そうよ。

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

ワークステーションみたいに、HDDが1台、という環境では辛そう。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:23:33

そんなタコい作りのカーネルなんてあるの？UNIXにはなさそうだ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:35:14

標準だとT1000でHDDは1台T2000でHDDは2台しか積んでいないよ。>>99

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 19:17:26

IOスレッドが多い状況だとIOを強化すべきでそれこそNASやファイルサーバ専用機の出番じゃないの

99 · 2005/12/18(日) 20:35:41

>>100
過信しすぎ。

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

>>101
だから、ローカルのストレージはOS用。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 20:45:41

時代はシリアル化へと。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:09:10

ケロッグの時代キター

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:14:39

ディスクI/Oのボトルネックで影響が大きいのはデータ転送時間ではなく、
シーク時間。古くはエレベータアルゴリズムでなんとかしていた分野だから、
特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。
シーケンシャルなアクセスでもバッファメモリ管理の領域だから、
やっぱりカーネルががんばるべき領域。
回転数とかバッテリバックアップとかは全然関係ないだろ。
まあ今はコマンドをタグ化して送っておいて、ディスクのコントローラが
自動的にヘッド移動を最適化してくれるわけだから、
「15000rpmも出せる高級なディスクではそういう高速動作も期待できる」という意味なら
分からないでもない。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:38:57

>>98
結構前からだよ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:42:38

>>106
> 特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。

いやディスク・クラスターの領域です。スパコンでは常識。
東工大の奴はCluster File Systemsの。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:48:16

>>108
その辺は Solaris 君は考慮済なんじゃねーの? 非同期 I/O ってやつ?

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 22:28:40

カーネルだけじゃどうにもならないという話です。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 22:33:26

>>108
>>99はT1000の話をしてたと思うんだけど。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 23:21:29

だから、T1000を何本ものラックにぎっしり詰めて、クラスタ処理する話でしょ?

ちなみに、整合性を確保するために、
書き込み順序を保証しろとか、ライトスルーしろとか、
そういうプログラムは、カーネルが手を出せない。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 00:15:35

いや32というのはT1000単体に乗っているNiagara一個が処理できるスレッドの最大数だから、
複数のT1000を前提にしなくても想定できるケース。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 01:37:22

まぁ、Windowsには絶対無理だな。

あっちは、P2PソフトでHDDの寿命が縮むくらい、カーネルがヘボいから。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 02:42:11

>>99
なんかソフトのスレッドとごっちゃになってないか。
Niagaraに出てくるスレッドはハードレベルの話なので、8コア4スレッドなら
ソフトからは32cpuに見えるはず。

ディスクアクセスはファイルシステム層で、UFSとかのレベルで
最適化されるし、Niagaraについて特別なことはないかと

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 07:32:27

IBMのワンワンだから

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 09:47:10

SGIは頑張れ。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 10:05:18

>>116
こんなボクちゃんのタワゴトで大勢してあっち向いたりこっち向いたり... sigh。
IPF って Ita Processor Family の略? やめてよねこんなしょーーもない略語作るの。

**名無しさん＠お腹いっぱい。** · 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/

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 13:46:00

>>116
そりゃ、Linuxはgccにおんぶにだっこだから。
gccが出力するIA-64コードは、とても遅いのよ。

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

でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 15:19:09

IPFならIntelのコンパイラ使えばいいやん
gccにこだわりがあるのかネェ

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 15:27:25

IntelがIPF専用Linuxディストリをつくればいいんだ

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 16:25:32

Linuxカーネルはpatchあてないとgccしかコンパイルできない。
http://www.pyrillion.org/index.html?showframe=linuxkernelpatch.html

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 17:05:15

>>121
> でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。
ああ、昔からアセンブラの方が速いとかシステムコールのパラメーターはチェックしなくていいとか
シェアードライブラリは固定数値使ってていいとか仮想記憶をオーバーコミットできないように
する必要はないとか、いろいろ言ってるよ、彼は。
関係ないけど、「氏」つけるんなら Family Name の方じゃないか普通?

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 19:49:29

だれかリーナスをシメてこい

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:11:38

　　 ∩＿＿＿∩
　　 | ノ　　　　　ヽ
　　/　　●　　　● |　
　 |　　　　( _●_)　ミ　　　俺がやるクマー
　彡､　　　|∪|　　､｀＼
/　＿＿　ヽノ　/´>　 ) 　　
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　（　＼
　　　　　　＼＿)

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:15:07

　　　　　　　　　　　　　　　　　　　　　　＿／-　イ､_
　　　　　　　　　　＿＿　　　　　　　／: : : : : : : : : : : (
　　　　　　　　　〈〈〈〈　ヽ　　　　　/: : : : ::;:;: ;: ;:;: ; : : : ::ゝ
　　　　　　　　　　〈⊃　　}　　　　　{:: : : :ノ　--‐'　､_＼: : ::｝
　　 ∩＿＿＿∩　 |　　 |　　　　　 {:: : :ノ ,_;:;:;ノ､ェｪヾ: :::}　　
　　 | ノ　　　　　ヽ !　　 !　　　、　　ｌ: :ﾉ　／二―-､　|: ::ﾉ
　　/　　●　　　● |　　/　　　，,･_　　|　/／　￣7/ /::ノ
　 |　　　　( _●_)　ミ／　, ’,∴ ･　¨　〉(_二─-┘{／
　彡､　　　|∪|　　／　　､･∵ ’　　／､／/|　￣￣ヽ ←Linus
/　＿＿　ヽノ　/　　　　　　　　／　　 //　|／／＼〉
(＿＿＿）　　　/　　　　　　　　/　　　 //　　 /＼／

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:31:59

カーネルをgccでコンパイルしてても、それでアプリケーションの動作が
遅くなるもんなのかな。minixのコードくらいしか知らないで言うのもの
なんだが、コンパイラの最適化によってOSの性能が大きく変わるような
とこって何？ファイルシステムのマルチリストの扱いとか？

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 23:38:32

いまさらだが…
なぜItaniumの話に？

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 00:04:34

>>116 に訊け

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 00:12:29

>>129
gcc で -O0 してできたカーネルと比べてみればいいのでは。C で書いてあって
頻繁に使われるとこは効くと思うよ。ファイルシステムとかネットワークとか。
メモリ割当もかな? Linux じゃ DTrace できんが。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 05:37:35

gccはGenericなコンパイラなので、Itaniumに特化したプリディケーションやスペキュレーション
みたいな機能をうまく使いこなす様にできてないんじゃないの?
リーナス自身がソフトでごちゃごちゃやるより、IBMみたくハードでなんでもやっちゃう方が好きだとか。

>>132
つttp://sources.redhat.com/systemtap/

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 17:30:21

IA64やEM64TのJavaは、
MicrosoftがAMDと天秤にかけて、
サポートを弱くするようIntelに迫ったという噂がある。
http://pc.watch.impress.co.jp/docs/2004/0218/intel.htm

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 17:57:26

>>134
参照張ってある記事と言ってることになんの関係もないようだが。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 18:18:51

>>129
Itaniumは他のCPUと比べてコンパイラでの最適化の効果が大きいというか
最適化しないと遅くて性能が発揮できないということじゃないか？

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 20:15:19

今時のCPUがハードで頑張ってる先読みやリオーダリングを
コンバイラにやらせて、ハードは楽をしようっていうCPUだからね

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 20:36:39

米グーグル、時価総額でＩＢＭ抜く－ＡＯＬへの出資合意を好感
http://www.bloomberg.com/apps/news?pid=90003017&sid=a.Zn8c4L_13g

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 21:50:05

IBMの技術者は、苦労してハード側で匠な実装を施してるのに、
分岐パターンを始めから全部実行しといて、分岐条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのアイテニアムは許せんらしい。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 21:59:39

Sunのユーザーは、苦労して社内で匠な実装を施してるのに、
ヒトもモノも始めから全部用意しといて、リストラ条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのIBMグローバルサービスは許せんらしい。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 22:35:31

なんかイカス

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 00:05:20

>>136
結構肝心な部分はアセンブラで書いてあるから、「そんなに効き目あるのか?」ってことだと
思うよ。スケジューラーや割り込み扱いあたりはアセンブラだからね。
アセンブラで書いてあるからにはコンパイラは関係ないけど、そもそもそのアセンブラの
記述自体で EPIC 活かすのは大変だ（≒不可能?）ってことでしょ。
＃アセンブラで書く... アセンブリ言語で書く、が正しい?

**134** · 2005/12/21(水) 00:30:02

>>135
↓これと間違えた…
http://pc.watch.impress.co.jp/docs/2004/0130/kaigai059.htm

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 21:55:09

システム設計ではハードで実装する機能とソフトで実装する機能の切り分けを行なう訳だが
今後益々複雑化する機能の実装を、限界が近付いたプロセスや製造コストの高く付くハード側に振らないで
ソフトに振るというのもアリだと思うのだが。

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 22:23:32

? 主旨が不明だが、分担がハードヘ行ったりソフトへ戻ったりってのは常に繰り返されてるよ。
グラフィックスや外部記憶 I/O とかでもね。
それと、ただただクロックアップだけここ数年やってきた特定の某企業が自分とこが
行き詰まったからってどこも同じだと言ってるけど、これはわかんないよ。
クロックアップと構造の工夫の両方をやりつつこれまでも「限界」と言われてたところを
乗り越えてきてるわけで、ここ数年はライバルがあらわれたことでナリフリかまわず
クロックアップだけやってきてるから、まじめに工夫しながら今 2GHz すぎあたりの
グループ（某系以外全部だけどね）が 3GHz 越えるくらいにはまた限界が先へ延びるかも知れない。

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 23:49:17

Gate長が狭すぎてVthのコントロールが難しいとか言ってた今までの限界とはもう次元が違うよ。
30nm、15nmといったら分子サイズだから、これを越えるともう歩留りを保つだけのリソグラフィ技術が
ついてこれないと思うよ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 10:07:36

>>146のようにとやかく予言していた学者たちは皆シリコンバレーに敗退した。
1GHzは無理だとか言っていた人たち、どこいったんだろ。
熱雑音やショットノイズが問題になるくらいまではなんだかんだ言って
いくかもしれないじゃん？

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 10:57:39

IA64は、幾らEPICっていっても、ベースがVLIWだから
命令セットの互換性での性能の犠牲がいや。

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

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

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:07:21

プロセッサが変わったらコンパイルしなおし。GentooLinuxや*BSDなら常識。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:23:35

> この頃は、pipelineすらなく

おいおい、pipeline はあるぞ。6段と、今どきのプロセッサとしては短めだが。
Itanium 2 も pipeline はかなり短い方だけど、それでも8段ある。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:33:20

OS/360に戻りなさい。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 15:38:04

>>147
そんでもって、Intel は特定の条件下で 9GHz を現実に動かしてるわけで、
今自分で言ってる「限界」を越える可能性が一番高い位置にいる。そのうち
「ついに限界打破、ぶれいくするー!!」とか発表するわけだ。まさにマッチポンプ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 18:44:30

>>152

動作してても、電子垂れ流し状態じゃないの？
現実には意味ないでしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 19:19:04

>>153
現在において意味がないことと、将来にわたって意味がないことが
同値であることを証明せよ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 20:05:12

>>154

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

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

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

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:22:38

笑っちゃうなぁ、量子レベルの問題とは。従来の物理理論ってなによ？
古典電磁気学のこと？マクスウェル方程式は（今のところ）正しいぜ？

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:27:25

なるほど、Intel は全く意味もないのに巨大なリソースつぎこんで環境作って 9GHz 動作してみたんだ、
へぇ～そこまで気が狂ってたのか気の毒に。だって意味ないのに..w

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:43:26

>>155=157
自演乙。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:44:31

>>156

量子物理学

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:47:31

なにもそんなに自分の無知をさらさなくても・・・

**157** · 2005/12/22(木) 21:47:52

>>158
いやいや、155 さんは Intel & Itanium 擁護したい人ですよ。別人です。

**157** · 2005/12/22(木) 22:11:43

あっ、ちがうな、Intel & NetBurst(Pentium4) 擁護したい人か?

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 23:22:20

何だこのアホ臭い展開は…

**157** · 2005/12/22(木) 23:26:44

>>163 この人が 155 でしょう。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 23:35:04

Itanium、これから伸びると思う？

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 00:34:32

おまいら散毎苦濾の話を汁

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 00:48:58

>>164
何故そう思ったのかわからんが，とりあえず違う

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 01:00:50

>>165
HP次第だけど多分NO

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 08:33:03

Itaniumの目的は自分の市場を小さくすることです。

1 · 2005/12/23(金) 09:10:13

>>170
製造技術に飽き足らず、市場までシュリンクしているのかw

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 09:25:21

Montecito が当初の予定通り2004年に、予定通りのクロックで出てればねえ…
2年遅延して、クロックが予定以下だからな。Xeon とのプラットフォーム統一
も延期になっちゃったし…

2005年にMontecito用のサーバを用意してﾜｸﾜｸして待ってたメーカー、ｶﾜｲｿｽ

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 10:14:39

せめて倍ぐらいの性能出ないとね。四苦八苦してみようかという気がしないってことでしょ、
RISC 登場したときと違って。x86 から大挙して移行が起こって価格が下がる、ってシナリオが
消えてなくなった今ハイエンド向けチップを Intel が維持する意味があるのか??
やめるんなら早いうち、って意見も内部で出てんじゃね?

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 13:18:19

V100系の低価格ラインナップは消え行く運命？？

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 13:41:39

AMD64がブレイクしているからねぇ。
もうItaniumはいらね。

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

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 14:41:46

まあ将来性という点では x86 拡張より IA-64 の方がブがあるんだろうけど、
そもそもがぶっちぎりの性能とそれをアテにした最速 x86 とハれる
x86 エミュレーションつーのが大前提だからね。かなり昔に崩れ去ってるんだけど、
全リソースを注ぐことも（やってたら会社終わってたかもね）、バッサリ切ることも
しなかった。大企業病だろうね。

**名無しさん＠お腹いっぱい。** · 2005/12/23(金) 15:03:47

ｈｐはもう終わりってことかね？
SUNおいしいな。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 13:10:23

VLIWなら高い並列性を安価に実現できるのは事実だが、
所詮、普通のアプリケーションでは、演算命令を同時
に２－３個も発行できれば十分で、それ以上は無用の
長物というのもsuper scalarの時点でわかっていた
こと。現実を無視した技術論にユーザ含めて踊らされた
ってことだ。このツケは結局intel製品の価格に跳ね
返ってくるのだから、エンドユーザが支払っている。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 13:32:07

プロセスまたいで命令がパック出来れば面白いんだけどね。
TransmetaのCMSってこういうの出来るのかな。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 13:35:15

別プロセスだと、アドレス空間も分けなきゃいかんから無理でしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 16:45:02

Itaniumがヘボイんじゃなくて、コンパイラがまだまだということなんじゃないの？
ハードが非現実的なソフトウェアの課題を要求してるという意味じゃハード側にも
責任がありそうだけど。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 17:07:35

Itanium支持者が多いのかItaniumがこけると困る人が多いのか知らないが
ここはSUNのスレでItaniumはスレ違い

Itaniumの話はここでどうぞ
http://pc8.2ch.net/test/read.cgi/hard/1126713905/

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 17:51:17

SPARC の敵はもはや Itanium と POWER しかいないのでここでいいやん。
敵を知るものは汁物であたたまろう。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 17:58:04

>>178
> ってことだ。このツケは結局intel製品の価格に跳ね
> 返ってくるのだから、エンドユーザが支払っている。
そうそう、x86 な CPU は安いっていうけど、もっと上品な RISC 2 つが健全な競争を
くりひろげてればコストパフォーマンスは今よりずっと高い可能性がある。
自然とそこへ行き着かないのは業界の構造に問題があるんだよ。法律で誘導すべきだね。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 21:18:11

>>プロセスまたいで命令がパック出来れば面白いんだけどね。
プロセスまたいで空いた演算器を有効利用するって発想は
SMT技術じゃん。itanium は niagaraに滅ぼされるのかもね。

**178** · 2005/12/24(土) 21:26:25

>>Itaniumがヘボイんじゃなくて、コンパイラがまだまだということなんじゃないの？
現実のアプリケーションでの演算の並列度が２－３なので、それ以上いくらコンパイラ
ががんばって命令を並び換えても４つ以上の演算器を使いきるための並列度を引き出せ
ないのですよ。
だからitaniumの高速性の宣伝に使われるのは、暗号化など、本質的に演算の並列度の
高い一部のアプリケーションだけでしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/24(土) 23:33:21

わかった、じゃ Itanium 機は世界に 5 台だけ残して、暗号演算は全部そいつらにやらせよう。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 00:00:04

特定の暗号計算のアルゴリズムなら、CPUにやらせるよりも専用回路に
やらせた方が速い。Niagara は実際、そういう回路を積んでるしね。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 00:49:41

えええっ?? それじゃ Itanium の居場所はほんとにないじゃーーんww

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 01:02:25

SPARC64V の演算器が６つもある件について

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 02:58:50

>>179
分岐命令が来たらどーすんの。

そういった問題点を1つずつ解決していくと、
気がついたら、既存のマルチスレッド技術と同じものになってる。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 04:18:37

>>190
整数演算系2セット、浮動小数点系2セットだけど？

**178** · 2005/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構成を思いますね。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 11:36:45

>>193
同時issueと演算器複数は、ぶっちゃけcacheアクセスのlatencyをカバーするためで
その並列性は関係ないんじゃないの？

**名無しさん＠お腹いっぱい。** · 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/

**178** · 2005/12/25(日) 22:37:34

>>194
load/storeでのキャッシュレイテンシによる性能低下を同時に動か
す演算命令の数で改善しようとしても、プログラムそのものの持っ
ているセマンティカルな並列性を越えることはできない。itanium
はこの並列性の上限をコンパイラーで越えられるとしたが、錬金術
に過ぎなかった訳。
　また、本来VLIWは簡素なＨＷが信条のはずなのだが、お化けＨＷ
になって、結局、周波数もあがらず、品質も悪く、予定期間内で設
計できなかったんだよね。これ本末転倒。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 22:41:57

メモリアクセスのレイテンシを覆い隠すだけなら、sparc v9のプリフェッチ
命令でいいじゃん。演算器いらね。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 22:45:04

>>196
いやだから、SPARCなんだから、SPARC64Vで演算器を複数積んでるのは
VLIWみたいな並列性じゃなくて、シングルスレッドの性能を上げるためだってこと

>>197
メモリじゃなくてcacheのlatency

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 22:45:40

>>197
プリフェッチ命令だけですべてうまくいくなら、SMTはいらない訳だ。
だがそうならずNiagaraの登場となった。

**名無しさん＠お腹いっぱい。** · 2005/12/25(日) 22:46:05

Javaだと、JIT/Hotspotで、関数インライン展開、ループアンローリング、分岐予測を、
hotspotにダイナミックに実施できるから、VLIWの特性をより活かせるはずだったのにな。
# 非VLIWに打ち勝てないまでも。
Sunとは喧嘩別れしたからな。

Crusoeも死亡寸前だし、VLIWは復活ならずだな。