トップページ⇒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/
0038名無しさん＠お腹いっぱい。2005/12/14(水) 21:07:42
Webフロントエンドサーバでは、SSLの性能が大事なので、
たしかNiagaraは暗号用の回路を内蔵していた筈。
だから、暗号化に関しては大丈夫じゃないかな。
マルチメディア系には、あまり向かないだろうってのは同意。
0039名無しさん＠お腹いっぱい。2005/12/14(水) 21:40:44
はにわ？
0040名無しさん＠お腹いっぱい。2005/12/14(水) 22:09:58
ttp://www.unixuser.org/~euske/doc/niwatori/
0041名無しさん＠お腹いっぱい。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.
0042名無しさん＠お腹いっぱい。2005/12/14(水) 22:41:39
あれ、Rockはどうしたんだ？
0043名無しさん＠お腹いっぱい。2005/12/14(水) 23:03:08
the future "Rock" massively multithreaded chips due in 2008
0044名無しさん＠お腹いっぱい。2005/12/14(水) 23:30:59
Rockはあと3~4年先と考えていいな。
どーせ遅れる。
0045名無しさん＠お腹いっぱい。2005/12/14(水) 23:39:10
こともなげに「Niagara3と統合した」とRock開発破棄を言い出すに\10万賭けてもいい
0046名無しさん＠お腹いっぱい。2005/12/14(水) 23:57:11
めちゃありそう
技術的なウンタラ…で実際は資金難でｗ
0047名無しさん＠お腹いっぱい。2005/12/15(木) 00:13:37
SSLて実数演算あんのか？
整数演算じゃないのか？
0048名無しさん＠お腹いっぱい。2005/12/15(木) 00:28:28
SSLなど暗号関係は、ふつう整数だけでしょうね。
ちなみに Niagara の暗号用ハードウェア (modular
arithmetic unit) は、コア毎に1つ、チップ上に8つ
載ってるそうです。
0049名無しさん＠お腹いっぱい。2005/12/15(木) 00:41:39
よし、じゃマルチメディアの話はまた来年。とりあえず SSL と Java と Web の話だ。きゅー。
0050名無しさん＠お腹いっぱい。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
0051名無しさん＠お腹いっぱい。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 も同じくらいかな？
0052名無しさん＠お腹いっぱい。2005/12/15(木) 16:22:00
>>36
暗号化も圧縮もFPU使わないっす。
0053名無しさん＠お腹いっぱい。2005/12/15(木) 22:25:34
T1000ってHDDを1個しか積めないってのはどうなのよ
Web/アプリ用のサーバだってミラーくらいするもんなんじゃねーの？
0054名無しさん＠お腹いっぱい。2005/12/15(木) 22:57:18
OSドライブに冗長性が必要な場合はNASからブートさせるとか
ライブドアもそうしてるみたいよ
Tシリーズは箱としてのHAを求める用途には向かないと思う
そういう向きにはIV+ドゾーみたいな
0055名無しさん＠お腹いっぱい。2005/12/15(木) 23:37:17
RAID 組むんじゃなくて、2台入れて、それぞれがお互いの
バックアップサーバとして動くようにトラフィックを
振り分けるって感じかねえ。
0056名無しさん＠お腹いっぱい。2005/12/16(金) 00:41:07
いや、ファイバーで繋いだNASのディスクからブート。
0057名無しさん＠お腹いっぱい。2005/12/16(金) 01:20:43
え゛ー、SAS じゃなくて? もうフィブレシャネルは終わりだろ。
0058名無しさん＠お腹いっぱい。2005/12/16(金) 02:27:23
>>55
3wareあたりがやってるRAID1からストライプで読み出すってやつ？
0059名無しさん＠お腹いっぱい。2005/12/16(金) 10:27:10
>>58
T1000を2台買えってはなしじゃね？>>55のいっているのは。
0060名無しさん＠お腹いっぱい。2005/12/16(金) 14:55:16
たくさん並べて分散処理する鯖なら、
ローカルのストレージは、
ノードとして動くのに必要なものしか置かない。
0061名無しさん＠お腹いっぱい。2005/12/16(金) 23:51:09
>>59
そしたら何か賢い箱を2台の前に置くか賢いソフトでミラーしてやるしかないよね
0062名無しさん＠お腹いっぱい。2005/12/17(土) 02:42:27
Web サーバやアプリケーションサーバの場合、ローカルに書き込む
ファイルなんてログファイルぐらいなので、複数台用意して冗長性
を確保する状況なら、RAID もバックアップも要らないのでは？
0063名無しさん＠お腹いっぱい。2005/12/17(土) 02:46:40
ログが消えるのはまずい
0064名無しさん＠お腹いっぱい。2005/12/17(土) 03:01:04
じゃ、ログもネットワークに投げとけば？
0065名無しさん＠お腹いっぱい。2005/12/17(土) 15:02:51
niagaraですけど、ちまちましたことを平行していっぺんに、って、
デスクトップにも良いんではないかと思うのですが、ワークステーションは
出ないんでしょうか??
0066名無しさん＠お腹いっぱい。2005/12/17(土) 15:46:56
SunはもうSPARC積んだWS出す気はあまりないだろ。
niagaraですけど、ちまちましたことを平行していっぺんに
俺としてはそれもありかなぁとは思う。
どーせ、SPARC積んだWSなんて、単体運用より端末として使われる方が多いだろうし。
0067名無しさん＠お腹いっぱい。2005/12/17(土) 15:52:00
>niagaraですけど、ちまちましたことを平行していっぺんに、って、
>デスクトップにも良いんではないかと思うのですが

どのへんが？全然良くないと思うケド
0068名無しさん＠お腹いっぱい。2005/12/17(土) 16:02:39
Niagalaはどうみても Webサーバとか Oracleみたいなスレッドを
たくさん作って、がーっとやるジョブ向けのCPUじゃん

メールとワードを同時に動かすとか、そういうの向けじゃないよ
0069　682005/12/17(土) 16:04:00
日本人だから L と R　を間違えるのは仕方ない
0070名無しさん＠お腹いっぱい。2005/12/17(土) 16:34:19
>>65
個人のワークステーションで、ロードアベレージが32に達する
状況なんてないでしょ。つまり Niagara の性能はワークステー
ションでは全然生きないってこと。
今のところ、ワークステーションではシングルスレッド性能が
大事だから、Opteron の方がいいよ。
0071名無しさん＠お腹いっぱい。2005/12/17(土) 17:30:08
うーん、メールとワードじゃ、いっしょだと思うが。FPU 付きの Niagara2 になったら
マルチメディアで並列も期待できるし、値段いっしょだったら Niagara2 取るけど。オレは。
そもそも今 PowerPC G4 1.25GHz だけど、もっと速いの欲しいとかあんま思わんし。
0072名無しさん＠お腹いっぱい。2005/12/17(土) 17:44:40
> そもそも今 PowerPC G4 1.25GHz だけど

G4 はスーパスカラでしょ。
Niagara はシングルイシューだから、シングルスレッドだと、
G4 1.25GHz よりも、さらに遅いよ。
0073名無しさん＠お腹いっぱい。2005/12/17(土) 17:57:44
うーーーーん、だとしても、メールとワードじゃいっしょでしょ。
0074名無しさん＠お腹いっぱい。2005/12/17(土) 19:02:56
>>65
その分野のWSではCellがあるからね
PS3が成功すれば少なくともPS3用ゲームの開発マシンとしてそれなりの台数は出るだろうし
0075名無しさん＠お腹いっぱい。2005/12/17(土) 19:09:38
WSはOpteron搭載でx86-64版 Solarisでいいんじゃないか
0076652005/12/17(土) 20:21:34
うーむ、目の前のデスクトップ見て、たいていのものはウィンドウ毎にプロセスが走ってて、
個々のウィンドウの中でもwebブラウザとかはいろんなこといっぺんにやってるよなぁ、
などとふと思ったのでしたが、
68 >>メールとワードを同時に動かすとか、そういうの向けじゃないよ
あ、そういうの向けじゃないんですか。
なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな
話を見た記憶でテキトーなこと書いてました。すんません。

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

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



0077名無しさん＠お腹いっぱい。2005/12/17(土) 20:27:55
T1000/T2000とRay serverの組み合わせってどうよ？
0078名無しさん＠お腹いっぱい。2005/12/17(土) 21:13:42
並列化といえばEPICのItanium2が来ましたよ。
先日のItanium Solutions AllianceのDeveloper Daysも
空席の目立つ湿っぽい開催で、Montecitoの発売も来年にズレ込み
相変わらず前途多難な模様でつ。
MontecitoからIA-32はソフトエミュレーションになるので、
VMが２段になるJavaの実行速度を上げる努力をするそうでつ。
0079名無しさん＠お腹いっぱい。2005/12/17(土) 21:24:21
>>70
GNU makeで -j 64すりゃいい。

シーケンシャルなディスクアクセスがぶつ切りになって、
かえって遅くなったりするかもしれないが・・・。
0080名無しさん＠お腹いっぱい。2005/12/17(土) 21:24:59
>>76
> なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな

それはniceしていないからか、OSがヘボだから。
0081名無しさん＠お腹いっぱい。2005/12/17(土) 21:35:39
> MontecitoからIA-32はソフトエミュレーションになるので、
> VMが２段になるJavaの実行速度を上げる努力をするそうでつ。

これって、どういう意味? IA64 ネイティブの Java VM がないって意味?
そりゃ Sun にはやる気がないだろうけど、Intel は金ならあるんだから、
Sun に金払って、自力で開発して検証通して JRE を配ればいいんじゃないの?
0082名無しさん＠お腹いっぱい。2005/12/17(土) 21:42:11
Intelの友達はSunじゃなくてMicrosoft。
Itaniumに関しては喧嘩別れだし。双方が非難する発表。
0083名無しさん＠お腹いっぱい。2005/12/17(土) 21:45:11
> Intelの友達はSunじゃなくてMicrosoft。
> Itaniumに関しては喧嘩別れだし。双方が非難する発表。

あまりそういう一面的な見方は禁物かと。
Microsoft は IA32 の 64bit 化では、Intel じゃなくて AMD 側に
ついたし。
Java VM については、Intel が金さえ出せば、Sun は拒否しないんじゃ
ないの? それとも拒否してるって意味?
0084名無しさん＠お腹いっぱい。2005/12/17(土) 22:21:05
ttp://www.itmedia.co.jp/news/articles/0512/17/news008.html
IBM、AIXセンター開設

IBMって、Linux に集中してるのかと思ったら、まだ AIX を諦めて
なかったのか。
0085名無しさん＠お腹いっぱい。2005/12/17(土) 22:24:41
MVSだってまだやってますけど。
0086名無しさん＠お腹いっぱい。2005/12/17(土) 22:45:00
>>81
IA64 用 JavaVM は BEA がやってるって誰か書いとったやん。
0087名無しさん＠お腹いっぱい。2005/12/17(土) 22:52:26
JavaのためにItaniumマシン買う人が果たしているのだろうか・・・
0088名無しさん＠お腹いっぱい。2005/12/17(土) 23:07:18
Itaniumマシンは秀吉が全て壊したので誰も買えなくなった。
0089名無しさん＠お腹いっぱい。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のアルゴリズムをマルチスレッド化して
極力アプリの停止時間が短くなる様にしてる。
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だからね
■ このスレッドは過去ログ倉庫に格納されています