トップページ⇒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/
000812005/12/09(金) 00:02:36
>>6-7
どうも1です。

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

立て直して頂けるのならば、まだ前スレが少し残っている今のうちに
お願いします。
0009名無しさん＠お腹いっぱい。2005/12/09(金) 00:27:54
欠落してないサンなんて嫌
0010名無しさん＠お腹いっぱい。2005/12/09(金) 00:36:20
いっそ単数形でしか現せないように、製品ラインナップを練り直せ
0011名無しさん＠お腹いっぱい。2005/12/09(金) 00:47:18
会長、ごケツ暖を!
0012名無しさん＠お腹いっぱい。2005/12/09(金) 00:50:29
いいよこのまんまで。
0013スコット・マクネリ 2005/12/09(金) 01:22:51
このままでいいよ。
資源は大切に。時代はecoですよ。
0014名無しさん＠お腹いっぱい。2005/12/09(金) 01:32:21
もうナッツ食って冬眠したかと思ってた。
0015名無しさん＠お腹いっぱい。2005/12/09(金) 07:16:40
>>1
FATが笑うところ？
0016名無しさん＠お腹いっぱい。2005/12/09(金) 07:55:54
Ultra20

という重複したネーミングには、困ったね。
0017名無しさん＠お腹いっぱい。2005/12/10(土) 19:51:52
Sun、サッカーワールドカップで日本を北朝鮮と報道！

http://www.thesun.co.uk/article/0,,2002390000-2005570245,00.html
0018名無しさん＠お腹いっぱい。2005/12/10(土) 20:01:22
GROUP F
Brazil

Croatia

Australia

Korea Republic
0019名無しさん＠お腹いっぱい。2005/12/10(土) 20:36:46
Sun Microsystems 最大の皮肉
0020名無しさん＠お腹いっぱい。2005/12/10(土) 20:40:21
>>17
サンはサンでも、新聞屋の方のサンじゃねーか、おい
0021名無しさん＠お腹いっぱい。2005/12/10(土) 22:22:48
Sunは既に太陽じゃないし、"Micro"systemsでもない。
0022名無しさん＠お腹いっぱい。2005/12/10(土) 23:33:00
何を言ってる? 90nm だぞ?
0023名無しさん＠お腹いっぱい。2005/12/11(日) 01:41:05
90nmは、0.09micronですよ。
0024名無しさん＠お腹いっぱい。2005/12/11(日) 02:14:13
Sun Nanosystem 最大の遊撃
0025名無しさん＠お腹いっぱい。2005/12/11(日) 09:26:04
Sun Nanosystem 最大の邀撃
0026名無しさん＠お腹いっぱい。2005/12/11(日) 13:48:01
三枚黒
0027名無しさん＠お腹いっぱい。2005/12/11(日) 22:37:34
秋刀魚育露
0028名無しさん＠お腹いっぱい。2005/12/11(日) 22:43:18
秋刀魚イクラ寿司天むす。
0029名無しさん＠お腹いっぱい。2005/12/12(月) 09:45:26
3nm プロセスになったときこそ
0030名無しさん＠お腹いっぱい。2005/12/13(火) 18:06:49
3nm プロセスになったときこそ天むすを食うのか？
0031名無しさん＠お腹いっぱい。2005/12/14(水) 00:09:48
サンマイクロに落日なし
0032名無しさん＠お腹いっぱい。2005/12/14(水) 00:14:09
梅じゃないんだから
0033名無しさん＠お腹いっぱい。2005/12/14(水) 15:22:02
確かに落日は無いな。グリーンランドあたりで見かける白夜で
留まっているからな。
0034名無しさん＠お腹いっぱい。2005/12/14(水) 18:23:38
Niagara+Solaris って、DAW マルチメディア方面にすごく向いてるんじゃないか?
MacOS X や糞doze 向けのアプリばかりだが、あいつらでは多コアはまともに扱えん。
これチャンスなんでわ? CoreAudio と Xcode 移植しろ!
プラグイン音源とかエフェクトアホみたいに組み込んでも平気で稼働できる気がする。
0035名無しさん＠お腹いっぱい。2005/12/14(水) 19:59:04
いや、サンだからな。糞dozeの方が多コア扱えるの上手くなるよ。
そして再び落日へと
0036名無しさん＠お腹いっぱい。2005/12/14(水) 20:32:34
NiagaraにFPU が 1 コしか積んでない件はどうなのよ？

暗号化や圧縮処理が弱いのは明らかに不利だぞ
0037名無しさん＠お腹いっぱい。2005/12/14(水) 20:50:02
あ、そうだった、DAW も浮動小数点値計算だ、現 Niagara じゃダメだ。
Niagara2 の暁にわにわにわとりがはにわ。
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
結構前からだよ。
■ このスレッドは過去ログ倉庫に格納されています