Sun Microsystem 最大の夜長

**名無しさん＠お腹いっぱい。** · 2006/10/01(日) 14:44:01

日々肌寒くなるも、その先に本格的な冬がじわじわと忍び寄る
秋の頃合…。

そんな季節感の経営状態だが、秋こそ、秋刀魚イクラの季節！

【前スレ】
Sun Microsystems 最大のリストラ
http://pc8.2ch.net/test/read.cgi/unix/1149485579/

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 21:48:39

>>354
うひーひひひ。せっかく >>352 が警告してくれたのにww てか、本人かw?
Itanium うくくく、あれは 20 年は笑えるな。

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 22:15:20

20年後にはSunが…困った笑いのネタが１つ減ってしまう

**354** · 2006/11/03(金) 22:22:28

>>355
CPU2006とかTPC-CにMontecitoのスコア来てますよ。

>>356
個人的には「たったの1億ドル？」と思った。(チラ裏

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:17:16

>>359 でもXeonに負けているじゃん。
TPC-Hを見るとOpteronサーバに負けている。

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:22:24

IntegrityよりProLiantの方が支持されていると思う。
X64もDual-Core、Quad-Coreと進化しているので4CPU 16Coreのラインでは
Itanium2の出る幕は無いのでは？なぜItanium2に固執するのか良く分から
ない。公平に見てItaniumはintelの失策だと思う。最近、ようやく採算が
合うようになってきたとは言え、X64の伸張を考えると将来も怪しいのでは？

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:22:40

全社サーバ出荷金額500億ドル
Sunサーバ出荷金額50億ドル

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:25:55

>>361
IntegrityはHP9000の後継シリーズ
パチョコンサーバとは求められてるものが違う

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:50:47

>>361
> ない。公平に見てItaniumはintelの失策だと思う。最近、ようやく採算が
失策どころか... Intel 以外だったら会社終わってますわ。IBM ぐらいかな、
こんなドちょんぼに耐えれるの。
で、まぁ、しがみついて墜落してくれw

**名無しさん＠お腹いっぱい。** · 2006/11/03(金) 23:55:18

>>360
OK.確かにItanicのintはCoreに負けている。
>Itanium2はFPは速いけどINTは速くないよね。
でもこれは語弊があるよね？OpteronやPentiumEEより速いわけだし。
それにTPC-H@3000GBはRISC勢の不戦勝ですよ。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:00:44

そうだな、当初の予定通り、さっさとメインストリーム Itanium にして、
x86 打ち切っちゃえよ? それがいいじゃんww?

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:10:43

HP-UXってどうなの？瑞ｶき残れるOSなｂｾろうか？
Itanium2陣営においてHP-UXはそれなりの勢力を誇っているけど、
将来的にはLinuxに駆逐されるんではないのと思う？
AIXとSolarisは残るような気はしているんだが。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:12:54

>>363 Sunもそう思っていたが、hpやdellのPCサーバに食われた。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:14:01

えっとですねぇ、Itanium、売れてるののほとんどが PA-RISC（つまり HP-UX）の
リプレースです。
で、Itanium もうすぐ消えるので、HP-UX も消えます。
けど、完全には消えないですよ。今でも Multics や 2.11BSD が稼働してるのと同じでwww

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:18:23

状況によっては IBM が POWER に Solaris のせる、ってのはありえると思うよ。
このまま SPARC が弱ったままの状況が続いて、IBM が常時優位に立てればね。
それでも IBM はハードウェアで儲かるから。OS が AIX だからというシバリで
儲けてる分と天秤できるくらいのメドが立てば採用はありえると思う。
SPARC が復権して、ハードでライバルになったら、AIX のままでいくだろうね。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:22:18

>>368
Sunのローエンドはパチョコンサーバ同等の機能と信頼性しかなかったから
いわゆる「DELLより安い！DELLより安い！DELLより安い！」

値段が同じでも負けるに決まってる

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:24:16

>>367
HP-UXは文字コードにShift_JISを使ってた記憶が。
Winで開発、HP-UXで運用みたいなときに相性がいいみたいね。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:28:15

>>372
ｿﾗﾘﾝは Code Set Independent だよ

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:28:19

>>372
いやデフォルトがS_JISなだけ。EUCも選択できる。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:33:20

女神の盾システムのプラットフォームはHP-UX

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 00:34:05

文字コードはいろいろ使えた方がいいけど... Shift_JIS はやめとけ。もう終わったw
C 言語以前の遺物だ。

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

Shift_JIS よりまともだ、と思えば UTF-8 も使えるなw 代償も大きいが。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 01:08:07

>>372
Unix も昔はほとんどが Shift_JIS だったろ。NEWS とか。EUC は少数派だったはず。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 02:11:25

UTF-8は負けた気がする

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 02:36:00

HP-UXはItaniumと共に消えると。
Solarisもそうならないようにがんばろう

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 02:36:00

はぁ? 批判は多々あれどひとり勝ち状態ですが。対抗としては ISO-2022-JP2 くらいしか
ないでしょ?

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 03:00:43

Shift JISとCP932の区別がついてない人がいるようですね。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 03:03:18

うーん、今回は簡単だとぼくは思っていた。だって、Intel MultiCoreProcessorは高発熱のプロセッサだもんね。
これからも当分抜かれることのない消費電力のはずなのだ。この質問のこたえなんて考えるまでもない。
けれど、Intel MultiCoreProcessorを、みんながどんなふうに感じているのか、それが探りたくてこのテーマにしたのだ。
するとあらら、不思議。寄せられたのは親Intel MultiCoreProcessorのメールばかりだった。
なぜなのかしらん？　というわけで、今回は多数を占める「Intel MultiCoreProcessorは優れた製品」派からいってみよう。

「プロセッサの消費電力の低さは、普及価格帯ですら、『望ましい』ことであって、ましてやエンスージアスト向けならば、『なすべき』ことではない」（住所不明・匿名さん）
「競合する他社製品と同等の発熱で二倍の能力があるから。」（住所不明・匿名さん）
「消費電力は低いほうがいいに決まっているが、パフォーマンスを大きくさげてまで低くする必要はない」（海外在住・匿名さん）。
「低発熱低性能なXE向け製品ならいらない。必要があれば省電力化し、なければパフォーマンスに振り分けるくらいでちょうどいい」（北海道旭川市・優子さん）。

ふー、びっくりした。でも、擁護派の意見はほぼ一点に集中している。
相対的な観点から見ると優れた製品だから、特に発熱だけを問題視する必要はないというもの。
それほんとなのかなあ。今回の答えは数字の上では「しなくていい」派が圧倒的だったけれど、
応募しなかった多数のサイレントマジョリティを考慮にいれて決定させてもらいます。
発熱は低いほうがいい、だからIntel MultiCoreProcessorは失敗作。あたりまえの話だよね。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 03:05:21

CP932 になったからって C のソースでさえ手を入れずに扱えない、
C 言語普及以前の遺物って点は何もかわらないがww
MS-DOS が ME でやっと退場したのになんでまだ残ってんだろなずうずうしいwwww

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 11:52:23

> 今のSunはローエンドからミドルで数売って稼ぐモデル。

ハイエンドは、来年に出るSPARC64のAPLでカバーするって話だったじゃん。
APLが遅れているだけで、ビジネスモデルはしっかりできてるよ。

後はストレッジとバックアップ(テープ)のとこがしっかりすれば、完璧。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 12:20:41

机上の空論や計画が立派でも実現できてなけりゃ、絵に描いた餅のままだぞ。

ビジネスモデルだ何だのと表だって言うようになったら斜陽だよ。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 12:27:54

ストレージはだめだろ、もうｗ

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 13:41:24

いや、実際数字に出始めてるんですが。不良債権処理始めたころの
にっぽんこくの銀行とは大違いでw

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 15:53:15

>>387 SPARCstorageArrayの頃から、Sunのストレージは設計が変で、ユーザの
評価を得られずに来た。T3もパートナーグループなどと言う訳の分からん仕組み
を採用したものだから、後継のT4も泣かず飛ばず。ドットヒルの3510FCに食われ
る情けなさだ。NAS市場への参入も中途半端だったので、ストレージの分野では
注目を浴びることは全く無かった。売り上げの数字がでかいので、一見すると
ストレージがんばっているじゃんと勘違いする向きも多いが、単にSunのサーバと
セットで売れただけで、ストレージを評価して購入したものではない。
StorageTek買収で、彼らの資産をうまく生かして展開していくのかなと期待
していたのだが、ロードマップを見る限り、Tape以外生かすつもり無いみたいね。
同様に買収した製品でSAM-FSやQFSと言う良い製品があるんだけど、こちらも
死んだようなもの。Sunって本当に商売下手。
Sunのサーバとストレージ、Tapeライブラリを買ってくれたら、SAM-FSもQFSも
超格安でバンドルしますくらいの手を打って欲しいものだ。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 16:38:13

Sun Fire15K買ってくれたら、もれなくストレージ（hitachiOEMのやつ）付いてきますってのはやってたな。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 21:27:05

> SPARCstorageArrayの頃から、Sunのストレージは設計が変で、ユーザの

なぁーに、かえって免疫がつく。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 00:31:19

マルチスレッドを今より簡単に扱えるようになる時代はやってくるのかね。

コンパイラによる並列化はあまり期待できない、設計は面倒、デバッグは大変だし、
開発者にとってはシングルスレッドの処理が速くなるほうがうれしいと思うのだが。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 00:56:48

たぶん、よほど売れてるアプリじゃなきゃ無理だね。
オーダーメイドみたいな開発なら絶望的。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 01:27:24

Niagara のスレッドをきれいに埋めて走った最初のプログラムは JavaVM だったでしょ?
そんな特殊なもんじゃないけど。C と Pthread でガリガリ書くのは確かに
難しいけどね。だけど必要があれば自然と出てくるもんだよ、違うものがね。
そのためのハードウェアは Niagara で提示されたわけだし。
Bill Joy はパラダイムシフトは言語から起きるだろう、ってずっと前に言ってたね。

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

Pthreadなんて捨ててOpenMP

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 02:45:02

>>392
諦めたらそこで試合終了ですよ
http://journal.mycom.co.jp/articles/2006/10/12/idf1/images/Photo74l.jpg

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 02:47:11

また陰℡の妄想プレゼンか

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:23:14

どの辺が妄想？

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:34:21

儲の思考は摩訶不思議
Intelは妄想でｻｿは妄想じゃない

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:52:57

淫はクライアントで、惨はサーバーだから
淫のは妄想で、惨のは妄想ではない

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 10:25:26

>淫はクライアントで、惨はサーバーだから
この驕りがNiagaraの悲惨な性能の原因なのですが。。。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 10:34:04

>>400は妄想そのものだが、>>401も負けてないな。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 11:00:25

性能について触れてはいけないらしい。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 11:16:49

淫telのスレッドは汚いスレッド、Sunのスレッドは綺麗なスレッド

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 14:13:33

どっちも糞

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 15:18:36

>>405
IBMとAMDはもっと糞♪

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 17:16:22

SUNはAMDの子会社じゃないか

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 18:14:14

Kentsfield(1P4C) vs Woodcrest(2P4C)
http://www.hardwarezone.com/articles/view.php?id=2102&cid=2&pg=4
Opteronサーバー死んだな…
Clovertown 1.60GHz $455*2 >>> Opteron 2220 SE $786*2
Clovertown 2.33GHz $851*2 >>> Opteron 8220 SE $2149*4

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 18:21:33

ｳﾋｮｰ

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:13:18

>>407
影のボスはFASL LLCの非公開部門ですｗ

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:13:51

インテルがNetBurstやってたのは、
堅実なアーキテクチャを選ばなくてもやっていける余裕があった
ということなのだと思う。
シェアNo.1なのだから、積極的にブレークスルーにチャレンジする責任があるわけで。

AMDに追い上げられた結果、インテルは余裕かましていられなくなって、
堅実なアーキテクチャを選択して引き離しにかかる、と。
ある程度距離が取れたら、また、堅実ではないアーキテクチャに移行すると思われ。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:19:00

あれは積極的にブレークスルーにチャレンジした結果じゃないけどな。
シェアを持っていたから、クロック神話から抜け出せなかっただけ。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:20:46

ニコイチは堅実なアプローチとはいえませんｗ
前回の似非デュアルのときと状況が違うのは、Core2がそれなりに優れているってだけだな。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:46:12

>>408
これさ、Win XP x64 Edition を使ってないって事は 32bit でテストしてるんだよね。
Core MA は 64bit だと性能出ないって話だけど（AMD は 64bit の方が速い）、
そこら辺どうなの?

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:23:24

>>414
これ聞く場所間違えると激しく罵倒される質問だから注意。
スレ荒らすための煽りレスとかに使っちゃ駄目だからね？
絶対だぞ。
閑話休題。IA32eだと性能は10%程度「しか」向上しないよ。
ベンチによっては30%以上ブーストするNetburstがどう見ても最強です。
絶対性能では勝てないんだけどね。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:27:38

>>415
日本語でおk

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:33:41

>>416
だが断る(えげれす語)
http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit.html

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 23:08:24

>>417
FP と SIMD が速いのは（どうでも）いいんだけど、サーバ用途なら整数演算、マルチスレッド性能、
メモりアクセス性能のベンチは無いの?

そこにも書いてあるけど、EM64T で Macro-Fusion が無いのと LCP の問題がどれだけ性能に
影響するのか知りたい。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 08:01:46

なんで最近の若者はSPEC見ないんだろう。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 11:29:36

HP-UXは消えるのか！？という質問に答えとして。

Itanium系はLinuxが多いだろうし、PA系は縮退しているから・・・減る。
ただし、Itanuim系でもHAを考慮したものなら、HP-UXは以前、残るでしょう。

HP-UXの利点としては、LVMがLinuxのLVMと仕様互換なので、汎用性は高い。
SolarisのSVMと比較して、IBM/HPのLVMはEnterprise Volume Management System
との親和性も高いので、乗り換え易い。
VxVMの真の機能は、HP-UXに実装したものなので。

中規模以上のシステムを考慮した場合、HP－UXはまだまだ残る。

大規模：AIXかHP-UX
中規模：AIX/HP-UX/Linux/Solaris
小規模：Solaris/Linux

中規模以上において、次期LVMとしてのEVMSの使用を考慮するなら、
Solarisは使っちゃいけない。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 12:59:28

同時走行スレッド数が多い=スループットが稼げるってのがSUNの主張。
ところで、CPUキャッシュのサイズが数十～数百Kのコアを並べて、そこに載るプログラム
って一体・・・

現実、JVM上のスレッドは載るとしても、そこにデプロイされて動作するアプリのデータ構造
や実際のプログラムのサイズを考えれば、SUNが主張するほど効率よく動けない。

実際にある程度のキャッシュサイズを持った上、個々のシングルスレッド処理能力もまとも
でないと、各スレッド間の調整やらも含め、オーバヘッドが大きいんじゃないのかな？！

まともなコア(Power4レベル）のマルチコアチップが出てくるまで、多くのユーザは様子見。
で、SUNにはまともなコアが無いので・・・・終わってるって結論でおｋ？？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:00:32

ZFS は?

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:06:10

>>419
SUNのSPECによる見積もりツールの精度の荒さを見れば、誰も信じなくなるわな。
Oracleの性能をSPECで見積もったシステムを知っているが、悲惨。

SUNがSPECしかベンチマークを出さない（出せない）から、余計、信用が・・・・

OASとかでも、SPEC見積もりツールをOracleコンサルが全否定してるしな。
SUNユーザの前でHPならこう見積もるって力説してたから。

少々、CPUが遅くても、まともな見積もりが出せるような基準をSUN営業が用意しないと
商売にならないよな。

ま、まともな見積もりツールで見積もったら、HP/IBMとかのサーバ台数と勝負できない
のがモロバレで余計まずいのか！？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:13:03

LVMなんて使いにくいやん。
特にミラーリングのところ。
LV単位でのミラーリングってアホですか？なんでいちいちPVとLVの位置関係を確認せんといかんｗ
その点はVxVMやZFSの場合は、ディスクボリューム（ディスクグループやプール）に対してミラーなりストライプなりを指定するから、
物理デバイスの配置はよきに計らってくれる。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:54:11

そのため、ミラーリングに関しては、HP-UXではMirror/UXで別にしてんじゃねーの？！
しかも、LVMを使ったミラーの場合、VG単位でミラー化するのが普通。
#RAID１なんかは玉単位だろ。

逆にストライプ単位の設定の方が訳判らん。
エンタープライズ環境では、PV単位(玉）で考えるだろ。
ストライプとかLV単位でミラーなんて、せこい事はしないよ。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:00:11

ぷららのSunサーバで玉交換間違えてシステムダウンさせたのはどこの会社だっけ？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:05:25

>>426
CTCか新日鉄あたり？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:24:35

LVMはMirrorDisk/UX使わなきゃミラーリングできないんだから。
＞VG単位でミラー化するのが普通。
コマンドわからん。そんなのあったっけ？

通常ミラーリングするときって、lvextend -mじゃないの？
当然、このコマンドで実行すると、同じPV上にあるLV同士でもミラーリング出来てしまうから、
レイアウトを意識する必要がある。

ミラーリングに関しては、SDSやVxVMの方が圧倒的に使いやすいしわかりやすい。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:45:28

>>428
LinuxのLVM1&2及びAIXのLVMではLVMでミラー化できまする。

んで、HP-UXなら”無い”。
管理考えるならVxVMだろうね。

LVMなんて、あと2年の命なんだから。
EVMSに置き換わって、終わりですよ。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 16:14:25

volume manager だけ見て OS の選定するのは何か間違ってる気がする。
俺が使いやすいからこれにしたい、って言うなら、そうですか、って感じなんだけど。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 16:35:42

そうだね。
ただし、エンタープライズの分野なら信頼性のある、且つ、汎用性の高い
VMを選択すべき。

なぜなら、それを”自分”や部下が設定・メンテするとは限らないから。
外注や他社のエンジニアが行う可能性が高いんですから。

そういう点を考慮して、OSってのは選ぶべきですね。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 17:08:50

互いのLVMのパーティションが読めても、大概FSは読めないし。
全てのOSでVxVM/FSに統一すれば読めるけど。
結局WindowsサーバはEVMSになんか対応するはず無いので、あまり意味なし。
イメージレベルでバックアップやスナップショットくらいなら取れるんだろうけど、
そんなのストレージレベルでも出来るしな。

あくまで、非機能要件のひとつに過ぎないから、アプリケーションやミドルの要件より優先度は低いしな。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 18:03:11

>>432
いや、VMの抽象化概念すら違う（SVM）ものがあると、そのための
概念から揃えるのが大変。

ヘテロジニアスな環境で、膨大なデータを相手にするようなシステムだと
当然、VMの選択=OSの選択となる。
DWH系なんかは、VMの比重も大きいよ。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 21:36:20

> SUNにはまともなコアが無いので・・・・終わってるって結論でおｋ？？

今のCPUはISAやアーキ以前に、キャッシュとメモリシステムの実装で性能が決まるんだろ？
まともなコアとか、いってんのはキャッシュ、メモリシステムのことかい？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 22:55:22

>>433
そらまたごたいそうなことで。Multics みたいな状況ですか?

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 22:58:43

ふと思ったんだが、Oracle10gのASMってwindows、Linux、Unix間でデータファイルをそのままやり取りできるんかな？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:48:36

>>436 CPUによるエンディアンの影響があるのでは？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:52:19

Solarisならば今後はZFSだろ。
次期versionで待望のdual parity、hot spareがサポート。記憶が怪しいが
SunClusterの共有diskとしても使えるようになるんじゃなかったかな？
system disk(root filesystem)対応も近いと聞いている。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:56:30

>>422 をかるくすっとばしてるから、たぶん知らないんだろw

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 01:17:35

まだ出てない技術は検討の対象外

Sun営業は予定の技術ばかり売り物にする

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 01:26:26

ZFS悪くは無いんだが、SunCluster以外にサポートしているクラスターソフトはあるの？

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 01:37:13

カタログスペックはいいけどアプリ動かすと遅かったのは HP の方だったけどねぇ。
今は違って、ずいぶん優秀になったんだね。
PA-RISC のバイナリはアホみたいに巨大だった（で、起動に時間がかかった）。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 02:05:36

たぬきの皮を数えてるまぬけなスレはここですか？

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 02:29:50

いいえ死児の歳を数える悲しいスレです

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 03:54:01

>>418
LCPってx86の盲腸だよね。
性能出す必要あるの?
IntelのCPUはx87も遅いし、必要ないところはばっさり切り捨ててるだけでは。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 07:12:04

本当に必要無いのなら最初から気にしないんですがね...

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 07:56:37

x86_64では
1. 16bitコードは動かない(LCP使われない)
2. x87は傍系(SSEが主流)
http://www.intel.co.jp/jp/developer/technology/magazine/computing/Core-programming-0606.htm

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 12:39:27

>>447
x86_64ではREXバイトが追加され拡張されたレジスタにアクセスする場合や
オペランドが64bitの場合には必ず使用される
REXバイトがあるとCoreMAの実行速度は遅くなる

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 13:19:47

66H 67HとREX Prefixesは別物

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 14:28:22

>>441
SUN儲にはSUNClusterがあればなにもいらないとさ。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 14:29:53

ZFSがどうしたって！？いまさらの投入って感じがするけど。
普通のユーザにおいて、SUNは選択肢から除外されてるし。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:00:41

>>449
REXとLCPは別物だがこれらの前置バイトが付いてるとCoreMAでは遅くなるというのは同じ
だからCoreMAでは64bitモードで遅くなる
REX前置バイトは拡張されたレジスタへのアクセスが発生する命令や
オペランドサイズが64bitの命令には必ず付く前置バイト
64bitモードでは多用される前置バイトが付くと遅くなるのは致命的

パソコン用途では64bitモードはまだほとんど使われてないが
サーバー用途では今後ますます64bitモードでの動作が重要になるはず

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:38:23

>>452
遅くなるといっても、Opteronほど遅くはならない

というベンチマーク結果を見たことがあるけど、あれは提灯だったのだろうか。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:49:08

逆だろ。
Core2の方がOpteronに比べて、64bitモードでの性能の落ち方が大きいんだろ。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:54:46

それでも性能は、Core2 の方が良いケースが多かったと思うけど。

ちなみに Opteron も 64bit バイナリの方が遅くなるケースもあるらしい。
64bit コードは大きいからキャッシュから溢れているだけだと思うけど。

**453** · 2006/11/07(火) 22:15:52

日本語が不明瞭で誤解を招いたようで恐縮です

CoreMAの32→64での性能低下割合が、Opteronの32→64での性能低下割合ほどではない
という意図ではなく、
32→64で性能低下したCoreMAの速度は、Opteronの64での速度ほどは遅くない
という意図でした。

Opteronと同等か、それ以上なら「致命的」というほどではないかと。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 22:31:26

もうすぐUlraSPARC-IV+ 2.1GHzが出るんじゃなかったっけ？予定では今月か来月。
同様に数ヶ月以内にUltraSPARC T1の1.4GHzが。IIIiが1.3GHz-1.6GHzだから
T1000/T2000でかなりの領域をカバーしそう。たまたまFPやVISを使っているアプリ
以外はT1で行っとけと。
ただT1000、内蔵ディスク2台入るようになったのは嬉しいんだが、CD/DVDが載ら
ないのは悲しいね。是非とも改良して欲しい。