Sun Microsystems 最大の敵はItanium
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/02/26(日) 01:49:21【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0146名無しさん＠お腹いっぱい。
2006/03/10(金) 00:28:49SPARC64 V/2.16GHz/32CPU/32コア って32CPU(=32スロット)で32コアって言う意味？
要はシングルコアのSPARC64を32発ってこと？
0147名無しさん＠お腹いっぱい。
2006/03/10(金) 00:35:03UltraSPARC IV+はSunが2コア出しているけど。E6900とかで。
0148名無しさん＠お腹いっぱい。
2006/03/10(金) 00:36:56http://pr.fujitsu.com/jp/news/2006/02/2-1.html
0149名無しさん＠お腹いっぱい。
2006/03/10(金) 00:44:330150名無しさん＠お腹いっぱい。
2006/03/10(金) 00:46:140151名無しさん＠お腹いっぱい。
2006/03/10(金) 00:53:07http://pr.fujitsu.com/jp/news/2006/01/5.html
0152名無しさん＠お腹いっぱい。
2006/03/10(金) 02:20:54↓の本スレに移動してください
Sun Microsystems IPF採用撤回は大失策
http://pc8.2ch.net/test/read.cgi/unix/1140863996/
0153名無しさん＠お腹いっぱい。
2006/03/12(日) 09:10:39http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=106030901
4core同士だとMadison9M(161,217 tpmC)に比べて25%upでつ。
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=104110801
他のベンチマークはまだ無いようです。
0154名無しさん＠お腹いっぱい。
2006/03/12(日) 15:52:32過去に通って来た道だよ。
0155名無しさん＠お腹いっぱい。
2006/03/12(日) 17:00:05Montecito 2CPU、4コア、8スレッド
Madison9M 4CPU、4コア、4スレッド
0156名無しさん＠お腹いっぱい。
2006/03/12(日) 17:07:55コア数が同じでも、CMP の方が速いという事を書いたんだが。
なんちゃってヅアルだとあまり変わらないけどね。
0157名無しさん＠お腹いっぱい。
2006/03/12(日) 20:50:55だったら、そう書けば良かったのに。
しかし、性能向上分のどれだけがCMPによるもので、どれだけがCGMTによるものなのかな。
0158名無しさん＠お腹いっぱい。
2006/03/12(日) 21:04:07AMD Opteron 4CPUの方が、236,054 tpmCで速いぞ。
AMD 4coreが出たら、圧勝っぽい。
0159名無しさん＠お腹いっぱい。
2006/03/12(日) 21:06:47Montecito $3.25 US / tpmCに対して、
AMD Opteron $2.02 US / tmpCとなってる。
0160名無しさん＠お腹いっぱい。
2006/03/12(日) 22:09:370161名無しさん＠お腹いっぱい。
2006/03/12(日) 23:51:54TDPが若干下がってるからな
0162名無しさん＠お腹いっぱい。
2006/03/13(月) 00:27:50http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=105120501
これかな？
Opteron 2.4DC GHｚ
4Processors/8Cores/8Threads ってなってるぞ。
0163名無しさん＠お腹いっぱい。
2006/03/13(月) 00:57:32CPUが少なくても、トータルのコストが高いんじゃぁ・・・。
0164名無しさん＠お腹いっぱい。
2006/03/13(月) 01:21:11なんでもっと CPU 数の多いのでやらないんだろ。どうせ HP-UX なんだし。
0165名無しさん＠お腹いっぱい。
2006/03/14(火) 05:36:440166名無しさん＠お腹いっぱい。
2006/03/14(火) 20:36:250167名無しさん＠お腹いっぱい。
2006/03/15(水) 00:08:38Pen-M 系でもつまずく可能性は大。それに引き換え、POWER には弱点がない。やぱつおい。
0168名無しさん＠お腹いっぱい。
2006/03/15(水) 12:29:45Sun v.s. Intelはあっても、IBMは余裕。
Xeon, Opteronを使っても、一番はPowerという絶対の自信。
Cellのブレードサーバもあるし。
0169名無しさん＠お腹いっぱい。
2006/03/15(水) 12:39:120170名無しさん＠お腹いっぱい。
2006/03/15(水) 13:43:250171名無しさん＠お腹いっぱい。
2006/03/15(水) 16:50:54富士通の汎用機起源 SPARC64 は、やっぱ GS（だっけ?）への搭載をにらんだ作りに
なってるのかな?
0172名無しさん＠お腹いっぱい。
2006/03/15(水) 19:09:190173名無しさん＠お腹いっぱい。
2006/03/15(水) 21:07:00IBM厨の間違いだろう？
0174名無しさん＠お腹いっぱい。
2006/03/15(水) 22:14:49Powerなのは、旧AS/400のiSeries
zSeriesは、今も独自CISC
0175名無しさん＠お腹いっぱい。
2006/03/15(水) 22:25:310176名無しさん＠お腹いっぱい。
2006/03/16(木) 14:02:420177名無しさん＠お腹いっぱい。
2006/03/16(木) 21:27:08AMDは4年ぶりにまた暗黒時代に突入ですか。
0178名無しさん＠お腹いっぱい。
2006/03/16(木) 22:43:080179名無しさん＠お腹いっぱい。
2006/03/16(木) 23:11:580180名無しさん＠お腹いっぱい。
2006/03/16(木) 23:21:150181名無しさん＠お腹いっぱい。
2006/03/19(日) 02:02:22こうなったらtukiwlaでHyperTransportの真似ごとして挽回するしか
ないというのがIntelの本うわなにするｎ....
0182名無しさん＠お腹いっぱい。
2006/03/19(日) 02:45:27思ってたら、なななななんとと、32bit なのね。こんなもん出さなあかんちゅうのは、
やっぱ相当追い詰められてるで。終わるかもね。32bit って、ああた、いまどきサーバー用で 32bit...
0183名無しさん＠お腹いっぱい。
2006/03/19(日) 03:11:300184名無しさん＠お腹いっぱい。
2006/03/19(日) 03:16:19やっつけ仕事に見えるよね…
0185名無しさん＠お腹いっぱい。
2006/03/19(日) 13:06:08そのうち64bit版が出てくるだろうし。
0186名無しさん＠お腹いっぱい。
2006/03/19(日) 13:44:07メモリもFB-DIMMに、チップセットがBlackfordに変更になるようだしね
SossamanはLindenhurstのままでいけたけど
0187名無しさん＠お腹いっぱい
2006/03/19(日) 21:03:32俺も最初はそうおもったが、まだまだEM64Tが必須の64bitアプリなんて無い
のだから32bitcpuで十分。EM64T用の solarisだってlinuxだって一部のヲタ
が騒いでいるだけにすぎない。商売には関係なし。もっともwindows vista
がでるタイミングでこんなことをするのだから、intelにはEM64Tからふたたび
IA64の路線に切り替える重大決意があるのかもしれないが。
0188名無しさん＠お腹いっぱい。
2006/03/19(日) 21:18:510189名無しさん＠お腹いっぱい。
2006/03/19(日) 23:17:46AMD64対抗で開発していたものをお蔵入りにしてAMD64を採用する
という決定を下してからも、
続々と日の目をみなかった64ビット拡張を積みつつ、それを無効にしたCPUが登場するわけですよ。
Pentium4が素早く対応したので、簡単に見えるけど、そんなことはない。
あれは、AMD64命令を内部命令に変換する部分だけを変更したもので、
AMD64命令を実行できるというだけであって、パフォーマンスは悪い。
0190名無しさん＠お腹いっぱい。
2006/03/20(月) 00:54:31> EM64T用の solarisだってlinuxだって一部のヲタが騒いでいるだけにすぎない。商売には関係なし。
これは聞き捨てならないな。
64bitのSPARC/Solarisからの移行はAMD64/Linuxが出てやっと現実になった。
いまさら32bitなんてメモリ空間の制限厳しすぎて使ってらんねーよ。
0191名無しさん＠お腹いっぱい。
2006/03/20(月) 04:40:03メモリが小さい場合でもAMD64/EM64Tの恩恵がある。
0192名無しさん＠お腹いっぱい。
2006/03/20(月) 08:40:594GB 超はまたセグメントみたいなことやらないといかんのだから。
0193名無しさん＠お腹いっぱい。
2006/03/20(月) 08:41:43> がでるタイミングでこんなことをするのだから、intelにはEM64Tからふたたび
> IA64の路線に切り替える重大決意があるのかもしれないが。
ひどい飛躍と妄想。
0194名無しさん＠お腹いっぱい。
2006/03/20(月) 17:58:22うちも手元で開発→本番機(SPARC)って流れがずいぶんやりやすくなったよ。
0195名無しさん＠お腹いっぱい。
2006/03/20(月) 21:36:46ど素人さん、おぷてろんの物理アドレスのビット数を知ってる？
>> 4GB 超はまたセグメントみたいなことやらないといかんのだから。
0196名無しさん＠お腹いっぱい。
2006/03/20(月) 22:01:1532bitで十分だろ
ところで、yonahってPAE(32bitでメモリ32GBまで拡張)
ついてたんだな、以外
0197名無しさん＠お腹いっぱい。
2006/03/20(月) 22:12:240198名無しさん＠お腹いっぱい。
2006/03/20(月) 23:05:15呼んでない。
0199名無しさん＠お腹いっぱい。
2006/03/21(火) 02:31:200200名無しさん＠お腹いっぱい。
2006/03/21(火) 10:57:540201名無しさん＠お腹いっぱい。
2006/03/21(火) 15:01:42んなこたーない
0202名無しさん＠お腹いっぱい。
2006/03/21(火) 16:03:22どなたか、
IA32
IA64
AMD64==EM64T
SPARC V9
のlong doubleの精度教えてください。
0203名無しさん＠お腹いっぱい。
2006/03/21(火) 16:07:04お前は基本的なところを勉強してから出直したほうがいい
0204名無しさん＠お腹いっぱい。
2006/03/21(火) 20:37:46積和算命令を持つRISCと、誤差が変わるな
ちなみに、同じIA-32同士でも、xeonとopteronじゃ
精度が違う
グラフィックスだと同じアプリでも、xeonとopteronじゃ微妙に
色が違ったりするそうだ
0205名無しさん＠お腹いっぱい。
2006/03/21(火) 22:54:22IA32とSPARCの比較ならここにあるけど。
ttp://jp.sun.com/products/software/solaris/wp/Solaris_x86/chap3.html
x86(IA32)が12bytes = 96bit
SPARCが16bytes = 128bit
0206名無しさん＠お腹いっぱい。
2006/03/22(水) 01:06:04x87の拡張倍精度の80bitに
16bitパディングして、32bitアラインしてるのかな？
0207名無しさん＠お腹いっぱい。
2006/03/22(水) 01:10:56AMD64では、long doubleは16byte。
Solaris x64って、64bitバイナリでもFPUを普通に使えるんですかね?
SSE2って64bitしか使えないと思うんだけど、
どうやって拡張精度(80から128bit)を実現するのかな。
0208名無しさん＠お腹いっぱい。
2006/03/22(水) 09:19:350209名無しさん＠お腹いっぱい。
2006/03/22(水) 13:16:00さっぱり理解できん。バランス感覚のないデザイン。
0210名無しさん＠お腹いっぱい。
2006/03/22(水) 13:56:16そもそも、Intel X86のデザインって、めちゃくちゃじゃない？
Intelはデザインなんて考えてないよ。
デザインでいったら、AMD64の方がメチャ綺麗。
0211名無しさん＠お腹いっぱい。
2006/03/22(水) 19:13:42レジスタの値１つ変更するだけでレジスタの退避など全自動でタスクスイッチの処理をしてくれるようなCPU他にあるのか？
0212名無しさん＠お腹いっぱい。
2006/03/22(水) 19:16:14AMD厨は、こんなところにまで・・・
>>207
64ビットあれば十分で、コストをかけてまで拡張精度を用意する必要はない
という割り切りをしているんだろうね。
PAEについては、一部の例外的にメモリを多量に使うアプリのためのもので、
たとえば、DBMSのように、メモリアクセスにオーバーヘッドがあろうとも、
HDDにアクセスに行くよりは桁違いにマシ、という用途で使うことを想定してる。
0213名無しさん＠お腹いっぱい。
2006/03/22(水) 19:25:570214名無しさん＠お腹いっぱい。
2006/03/22(水) 22:55:59じゃあさ、CPUの仕様の違いを教えてよ。
みんな分かってるようであんまり良く分かってないんで無いの？
画像のエンコードとかやるならSS2の精度で十分だけどまともな数値計算するなら64bitじゃお話にならないし、
ソフトで他倍長計算するのってなんかやだ。
0215214
2006/03/22(水) 22:57:02○多倍長計算
0216名無しさん＠お腹いっぱい。
2006/03/22(水) 23:01:04全然知らんｗ
よく使われる精度が決まってないのなら、ソフトで実装するしかないのでは
0217名無しさん＠お腹いっぱい。
2006/03/22(水) 23:23:20多く使われるといえばIEEE754の倍精度(64bit)か拡張倍精度(80bit)なんじゃない？IA32でサポートしてるし。
でもSPARCやAlphaの4倍精度(128bit)で作ったプログラムを移植しようとしたらIA32じゃつらいよね。
IA64なら問題無いと思うけど、SSE2を推奨するx64はどうなんだろ？
0218名無しさん＠お腹いっぱい。
2006/03/23(木) 07:46:11めんどくさい手法で4GB以上使えると聞く。
どっかのDBが利用してるらしい。
0219名無しさん＠お腹いっぱい。
2006/03/23(木) 07:59:28もう、二十年来の不満だよｗ
0220名無しさん＠お腹いっぱい。
2006/03/23(木) 09:26:50SQLServerだっけ
0221名無しさん＠お腹いっぱい。
2006/03/23(木) 10:29:040222名無しさん＠お腹いっぱい。
2006/03/23(木) 21:50:08long double a, b, c;
c = a*b;
をコンパイルしたらこうなった
fldt -16(%rbp)
fldt -32(%rbp)
fmulp %st, %st(1)
fstpt -48(%rbp)
0223名無しさん＠お腹いっぱい。
2006/03/24(金) 15:13:09long doubleをdoubleにすると、xmm使うみたいですね。
gcc-4.1 amd64
デフォルト(-mfpmath=sse)
movlpd -24(%rbp), %xmm0
mulsd -16(%rbp), %xmm0
movsd %xmm0, -8(%rbp)
-mfpmath=387
fldl -24(%rbp)
fmull -16(%rbp)
fstpl -8(%rbp)
long doubleは必ずFPU使うのか。
0224名無しさん＠お腹いっぱい。
2006/03/24(金) 18:55:48http://www.anandtech.com/systems/showdoc.aspx?i=2727
Niagaraｼﾎﾞﾝﾇ?
0225ありがとう
2006/03/24(金) 21:31:27守ってください、本当にありがとうよかった・・・・・・
0226名無しさん＠お腹いっぱい。
2006/03/24(金) 22:24:19http://www.theinquirer.net/?article=30514
0227名無しさん＠お腹いっぱい。
2006/03/25(土) 20:16:050228名無しさん＠お腹いっぱい。
2006/03/25(土) 20:29:370229名無しさん＠お腹いっぱい。
2006/03/25(土) 20:32:38残念でした。Sun復活でつ。。。。
0230名無しさん＠お腹いっぱい。
2006/03/26(日) 14:37:44結局、痛 やってるのは日本の会社だけだから
インテルから切り離しちゃうんでしょ？ｗ
0231名無しさん＠お腹いっぱい。
2006/03/26(日) 17:04:40そりゃこのスレ的には『HP-UXを使ってるユーザなんて無視』でもいいけど
現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ
WindowsとかLinuxを使っているならx64に移れば桶だし
本当にエンタープライズシステムクォリティが必要なら
POWERに移ればいいのだから
だから痛を日本のメーカーがコントロールするようになっちゃうと
HPが黙っていないだろ
0232名無しさん＠お腹いっぱい。
2006/03/26(日) 18:20:01これだけで、Itaniumの数は伸びない...って感じがする。
HP-UXでも、PAからItaniumに移行しないで、IBM, Sunに移行していく
ユーザっていそうだし。PAユーザってまだ相当いそうだし。
HPがPAを止めたのは完全に失敗だったね。
0233名無しさん＠お腹いっぱい。
2006/03/26(日) 21:13:42Itaniumは技術的にもマーケティング的にもどう考えてもすべて90年代の発想です
0234名無しさん＠お腹いっぱい。
2006/03/26(日) 21:15:38hpは何やってもダメでしょ。必要ない。
0235名無しさん＠お腹いっぱい。
2006/03/26(日) 21:25:010236名無しさん＠お腹いっぱい。
2006/03/26(日) 21:32:290237名無しさん＠お腹いっぱい。
2006/03/26(日) 21:42:070238名無しさん＠お腹いっぱい。
2006/03/26(日) 21:47:120239名無しさん＠お腹いっぱい。
2006/03/26(日) 21:48:22売り払っちまったんでないの？
0240名無しさん＠お腹いっぱい。
2006/03/26(日) 21:57:14Alphaの技術はXeonの方にいっちゃったけど、CPUを使ったホストは
CompaqからHPへ。で、マシンが残っている以上、サポートしないといけないし。
そうなると、HPって、いつまでもAlphaとPA, VAXをサポートしていくのね。
Itaniumへの移行をすすめつつ。まぁ途中でサポートを切るんだろうけど、
今の感じだと、Itaniumへ移行すると、今度はItaniumのサポートが早々
うち切られそうな状況なので、Itaniumを使ったホストへの移行が進みそうにないね。
0241名無しさん＠お腹いっぱい。
2006/03/26(日) 22:05:16http://www.asahi.com/politics/update/0326/004.html
> 総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。
>
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。
確かにありがち！
0242名無しさん＠お腹いっぱい。
2006/03/26(日) 22:11:45この、「文部科学省以外の電子申請には...」って何？
全省庁、Javaで統一しろよ。そういうことしてるから、税金が無駄に使われる。
文部科学省も、Javaを使えよ。
0243名無しさん＠お腹いっぱい。
2006/03/26(日) 22:15:03これって、具体的にどういうこと？
新版で動く ==> 旧版で動かない っていうのは、アプリが新版で導入された新しい
インタフェース、関数を使っていて、旧版ではその呼び出しができないっていう
ことかなって思うけど、
旧版で動く ==> 新版で動かない っていうのは、どういう場合？
アプリが新版で廃止になるdeprecateな関数呼び出しを使っているってこと？
（つまりバグ？）
0244名無しさん＠お腹いっぱい。
2006/03/26(日) 22:32:24確かに基本的にはあり得そうもないが...
0245名無しさん＠お腹いっぱい。
2006/03/26(日) 22:35:02オレの経験上では、旧版でセキュリティ的にめちゃくちゃなことやってて、
新版では手動で JVM の設定緩めないと動かなくなって、全クライアント（Web ブラウザ）機で
そんなことやってらんない、ってやつ。JRE のせいにするか普通? って思うけど。
■ このスレッドは過去ログ倉庫に格納されています