トップページ⇒unix
1001コメント280KB

Sun Microsystems 最富の庇護

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2009/10/07(水) 15:05:21
考えようによっては強力なパトロンを得た SPARC & Solaris OPENな魂は野獣どもの歯牙をググりぬけられるのか?! 秘密兵器 Rockの登場はいつ?! 【前スレ】 Sun Microsystems 最大の岩望 http://pc12.2ch.net/test/read.cgi/unix/1247220804/
0120名無しさん＠お腹いっぱい。2009/10/12(月) 09:39:59
>>112
実証されたのは x86の「まともさ」では、ないだろ?
x86である必要は全くない。
転換もできないんだから技術力もない。
0121名無しさん＠お腹いっぱい。2009/10/12(月) 09:45:27
>>120
x86には将来がないという話、
転換もできないインテルの発言だから信憑性ないんじゃない?
0122名無しさん＠お腹いっぱい。2009/10/12(月) 09:49:50
>>119
Sunが十分な待遇と仕事を与えなかったのが悪い。
Rockに十分な予算を与え、キャンセルせずに製品化していれば、いまもSunに残っていた可能性あるよ。

あと、マイクロソフトが優秀な人材を引き抜きまくって死蔵しているというのは誤解でしょう。
C#が3.0でラムダ式を導入してるから、死蔵ではないよ。
0123名無しさん＠お腹いっぱい。2009/10/12(月) 10:17:27
>>121
x86に将来がないと言わなかった会社は、当の Intelを含め、ひとつもない。
0124名無しさん＠お腹いっぱい。2009/10/12(月) 10:25:41
無知もはなはだしいな。それ願望か?wwww
0125名無しさん＠お腹いっぱい。2009/10/12(月) 11:09:07
>>123
じゃぁ、お前さんが技術力ないと切り捨ててるインテルではなく、他の会社の発言を引っ張ってきなよ。
0126名無しさん＠お腹いっぱい。2009/10/12(月) 13:18:44
>>122
おまえが1000億単位でSunに投資しなかったのが悪い。
以上、
0127名無しさん＠お腹いっぱい。2009/10/12(月) 14:35:59
[速報]サンの27年間の歴史にさよなら。SPARC、Java、MySQLはオラクルが引き継ぐ。米Oracle OpenWorld基調講演
http://www.publickey.jp/blog/09/27sparcjavamysqloracle_openworld.html

＼(^o^)／ｵﾜﾀ
0128名無しさん＠お腹いっぱい。2009/10/12(月) 14:42:45
現 Oracleに今後もしっかり残していかないといけないような技術ネタはないからね。
実際存続するのは今 Sunにある技術。
オープンにやってくれるのかという点は心配だが、元々オープンでもなんでもない
会社の取り巻きが騒ぐのはまったくバカげてて白けるばかり。
0129名無しさん＠お腹いっぱい。2009/10/12(月) 15:31:04
> ハードウェアとソフトウェアのすべてのピースを1つの会社で対応できることは、
> どの企業も提供できていない大きな価値だ

あれ、IBMは・・・何が足りないのかな。
0130名無しさん＠お腹いっぱい。2009/10/12(月) 17:12:58
信用。
0131名無しさん＠お腹いっぱい。2009/10/12(月) 18:39:15
どっかのコラムにあったが、1つのプロセッサーに膨大な数のトランジスタ素子を
詰め込めるようになったおかげでx86のように汚いISAでも関係ない状態になったと。
0132名無しさん＠お腹いっぱい。2009/10/12(月) 19:28:02
適当なこと書いてるコラムだな
0133名無しさん＠お腹いっぱい。2009/10/12(月) 21:42:22
>>132
「適当」の意味知ってる？
0134名無しさん＠お腹いっぱい。2009/10/12(月) 22:24:32
英語でいうと take it too
0135名無しさん＠お腹いっぱい。2009/10/13(火) 02:41:11
>>133
本来の意味で使う人は滅多にいない、
慣例的に使われている意味で解釈しろよ。
0136名無しさん＠お腹いっぱい。2009/10/13(火) 09:04:08
>>122
> C#が3.0でラムダ式を導入してるから、死蔵ではないよ。

移籍前ですが？
0137名無しさん＠お腹いっぱい。2009/10/13(火) 12:03:16
>>131
関係ないことにしないと誰も x86買わなくなるだろ?
0138名無しさん＠お腹いっぱい。2009/10/13(火) 13:18:29
そんなにx86のISAって汚いの?
そんなにSPARCのISAって綺麗なの?
0139名無しさん＠お腹いっぱい。2009/10/13(火) 13:53:51
もちろん。だってそういう主旨でそれを目的に作り直したのが
（いわゆる当時の商用）RISCだから。
x86だけが莫大なリソースを注ぎ込んで延命されたが、他は全滅した。
0140名無しさん＠お腹いっぱい。2009/10/13(火) 14:49:58
あるぇ、商用RISCが目の敵にしたCISCって、x86ではなく68kだろ。
0141名無しさん＠お腹いっぱい。2009/10/13(火) 14:58:38
当時 32bit機で Workstationが対抗してたのはミニコンだな。専用 CPUの。
VAX他、多数。
もちろん 68kもだけど、特に特別視はしてないと思う。既に速くなかったから。
0142名無しさん＠お腹いっぱい。2009/10/13(火) 15:06:07
いまだに CISC vs RISC とか言ってるのかよ

CISCはRISCを取り込み、
RISCはCISCを取り込み、
境界線がなくなったというのに

そもそもRISCってのは、
パイプラインの各段を1クロックで通過できる命令だけにしよう
という考え方であって、「単純な命令だけにしよう」じゃないのよ

昔は、加算に1クロックというのは妥当だったが、
今では、乗算が1クロックで済むので、加算のみの命令は単純過ぎて効率が悪い

SPARCのISAは、乗算が1クロックで出来ない時代の最適解かもしれないが、今の最適解じゃない。
0143名無しさん＠お腹いっぱい。2009/10/13(火) 15:18:36
CISC vs RISCはともかく、話の内容が古すぎる。
>142 が言ってるような比較はそれこそ 15年前くらいの話だし、
そもそもがそんな商用 RISCは存在してない。
乗算搭載してない商用 RISC CPUって、いつの話やねん、と。すり替えも甚だしい。
0144名無しさん＠お腹いっぱい。2009/10/13(火) 15:19:58
競争導入は弱者切捨て、ってお題目無限ループと同類w
0145名無しさん＠お腹いっぱい。2009/10/13(火) 15:22:34
>>143
今の商用RISCって、
A+B*Cのアドレスからロードして、なおかつCをポストインクリメント
なんていう命令を持ってたりするのか?
0146名無しさん＠お腹いっぱい。2009/10/13(火) 15:29:52
>>145
RISC CISCという命名が適切だったかどうかはともかく、
境界線がなくなってなんかないな。
そういうふうに取って欲しいという x86サイドの「願望」に過ぎん。
設計古すぎ。x86 ISA。
0147名無しさん＠お腹いっぱい。2009/10/13(火) 15:31:11
莫大なリソースを投下してもスケールアップもスケールダウンもできない
かわいそうさ加減がそれを象徴してる。
0148名無しさん＠お腹いっぱい。2009/10/13(火) 15:48:03
富士通とSun、SPARC64 VII搭載の新SPARC Enterpriseを発表
http://www.itmedia.co.jp/enterprise/articles/0910/13/news082.html
0149名無しさん＠お腹いっぱい。2009/10/13(火) 15:54:44
>>147
その割りには、x86は広範囲で使われてますな。
0150名無しさん＠お腹いっぱい。2009/10/13(火) 15:55:48
>>146
SPARCも同様に古すぎるんですが。

x86がアレだったのは286までで、386以降は整理されて、x64で盲腸が切り捨てられ、だいぶスッキリよ。
0151名無しさん＠お腹いっぱい。2009/10/13(火) 16:00:37
>>149
いいえ、ぜんぜん。
>>150
これも、いいえ、ぜんぜん。デコード回路が小さくできませんね。
後方互換性切って足枷になる命令捨てるまでムリ。Coldfireみたいにね。
0152名無しさん＠お腹いっぱい。2009/10/13(火) 16:04:54
今日も絶賛負け犬の遠吠えちぅだお…
0153名無しさん＠お腹いっぱい。2009/10/13(火) 16:09:37
x86 ISAはインターロック不得意だから本当に並列で性能比較されるようになると
すぐ馬脚が現れるだろ。
0154名無しさん＠お腹いっぱい。2009/10/13(火) 16:31:04
で、それはいつ〜〜〜？？？
マチクタビレターマチクタビレター
0155名無しさん＠お腹いっぱい。2009/10/13(火) 16:49:23
>>153
たとえば、どんなベンチマークで、それが現われてる?
0156名無しさん＠お腹いっぱい。2009/10/13(火) 17:02:21
>>153
メモリバリアのこと言ってる?

x86のように並び順どおりにリタイアするならメモリバリアいらない。
その回路をケチって発行したらそれっきりで順不同に実行しちゃうのならメモリバリアが必要。

これ、キャッシュとかSMPとかとは、関係ない次元の話ですから。
0157名無しさん＠お腹いっぱい。2009/10/13(火) 17:41:50
メモリアクセスのある演算命令は時間かかるし並列性出せないんじゃないの?
0158名無しさん＠お腹いっぱい。2009/10/13(火) 18:34:05
「SPARCおよび Solarisのハードウェアスペシャリストおよび営業担当者を
Sunによる体制の 2倍以上に増やす」

ゴーゴーえりそん!w
0159名無しさん＠お腹いっぱい。2009/10/13(火) 19:35:45
それは日本サンもですか？
0160名無しさん＠お腹いっぱい。2009/10/13(火) 19:53:53
大分リストラしておいたので、元の水準にも達しません
0161名無しさん＠お腹いっぱい。2009/10/13(火) 20:15:11
Jupiter+ようやく来たか
SPARC64VII+にはしないんだな
0162名無しさん＠お腹いっぱい。2009/10/15(木) 05:04:15
Sun Storage F5100 Flash Array

昔のSunのサーバを思い出すわ。
一面のメモリモジュール
0163名無しさん＠お腹いっぱい。2009/10/15(木) 08:40:41
64bit即値使いたい
0164名無しさん＠お腹いっぱい。2009/10/15(木) 08:59:13
>>163
setx value,reg,reg_rd
0165名無しさん＠お腹いっぱい。2009/10/15(木) 12:38:58
setxって、V9の命令じゃないじゃん。
0166名無しさん＠お腹いっぱい。2009/10/15(木) 13:17:44
マクロだよ
V9の仕様書に載ってる
0167名無しさん＠お腹いっぱい。2009/10/15(木) 13:54:12
>>166
横レスすまん
マクロで16ビット×4個に分解して合成するのは、64ビットの即値が使える、とは言えないと思うんだ。

まぁ即値の制限はRISCの弱点かもね。
コードサイズは肥大するし、命令数は嵩張るし、しかも直前の命令の出力を入力にするから、並列実行できないし。
といっても、コード中の即値の大半は小さなビット数で表現できる値なので、普通は問題にならないでしょ。
暗号とかの処理くらいかな、大きな即値がゴロゴロ出てくるのは。


0168名無しさん＠お腹いっぱい。2009/10/15(木) 16:09:05
>>167
> マクロで16ビット×4個に分解して合成するのは、64ビットの即値が使える、とは言えないと思うんだ。

それは文脈によるだろ。

> まぁ即値の制限はRISCの弱点かもね。

命令長固定しちゃえば、当然の帰結。
0169名無しさん＠お腹いっぱい。2009/10/15(木) 18:20:10
http://jp.sun.com/sunnews/press/2009/091013.html

クソワロタｗｗｗ
ここまでするかおいｗｗｗ
つーかこれが必要な機関なんてあんのかよｗｗｗ
0170名無しさん＠お腹いっぱい。2009/10/15(木) 18:23:46
>>169
既出
0171名無しさん＠お腹いっぱい。2009/10/15(木) 19:44:18
>>169
おまえ、PC使っとけ。脳が許容してないから、ムリするな。ケムリ出るぞ?w
0172名無しさん＠お腹いっぱい。2009/10/16(金) 00:27:30
>>169
それが必要な機関はあるけど、そんな機関でSunを選ぶことはないと思う
0173名無しさん＠お腹いっぱい。2009/10/16(金) 01:37:38
>>172
でも、そんな機関でもOracleは選ぶだろ。
F5100はOracleのインデックス専用ストレージ。
Oracleががんがん売り込むだろう。もうじき自社製品になるんだからな。
0174名無しさん＠お腹いっぱい。2009/10/16(金) 05:14:53
既存の用途に使ったら、ただのダウンサイジングで、ジリ貧ですぞ。
従来とは桁違いのIOPsを得られるのだから、従来は出来なかった・無謀と言われていた用途に使うべきでしょう。
たとえば2chのサーバのストレージ、とかな。
0175名無しさん＠お腹いっぱい。2009/10/16(金) 10:06:52
prestoserve思い出したの、オレだけ? Sunこういうの好きだよね。
0176名無しさん＠お腹いっぱい。2009/10/16(金) 11:49:51
ジョナサンがモジュール持ってニコニコしていたのが懐かしい
日の目を見ただけrockより幸せ
0177名無しさん＠お腹いっぱい。2009/10/16(金) 12:04:11
Rockはまだわからんぞ ..w
0178名無しさん＠お腹いっぱい。2009/10/16(金) 12:33:33
Rockを製品化するなら、そろそろ発表しないと。
発表から出荷まで1年くらい見るとして、来年の今ごろには出荷しないと、性能的に寿命すぎてる。
0179名無しさん＠お腹いっぱい。2009/10/16(金) 12:42:43
現実みろって
0180名無しさん＠お腹いっぱい。2009/10/16(金) 13:47:18
あれ? ちょっと前に出てたロードマップの、片方のタイプは Rock継承だろ?
0181名無しさん＠お腹いっぱい。2009/10/16(金) 14:34:52
Rockそれ自体はキャンセルしておきながら、それをアップデートしたものを提供予定・・・
・・・それって、IntelがItaniumでやらかしている延期に継ぐ延期と一緒のスタイルだな。
0182名無しさん＠お腹いっぱい。2009/10/16(金) 17:23:17
だから、遅れない CPU開発の方が少ないっていってんだろ。どんだけ無知なんだ。
確かに Niagaraは特筆するほど速かったが、あれは特例。
0183名無しさん＠お腹いっぱい。2009/10/16(金) 17:31:34
で、Rockは、「あと」どれだけ遅れるんだ?
0184名無しさん＠お腹いっぱい。2009/10/16(金) 20:01:50
Rock is dead!
0185名無しさん＠お腹いっぱい。2009/10/17(土) 04:23:15
永遠の開発中CPUか・・・
0186名無しさん＠お腹いっぱい。2009/10/17(土) 11:36:38
ROCKはアウトラン3Dとムーンストーンと同時発売です
0187名無しさん＠お腹いっぱい。2009/10/17(土) 15:54:33
(´；ω；｀)ﾌﾞﾜｯ
0188名無しさん＠お腹いっぱい。2009/10/17(土) 22:49:13
まあ、エリソンが言葉通りやる限りは、Sun製品の販売としては最高の時代が
訪れることになるね。脳無しアンチが焦って意味不明を繰り返すのも
わからないではない。
技術的におもしろいもんが今後も続けて出るのかは未知だけど、
今ある商品を改良しつつ売るには、いい期間になるだろう。
0189名無しさん＠お腹いっぱい。2009/10/18(日) 07:19:49
アングロサクソンのえげつなさ・・・
0190名無しさん＠お腹いっぱい。2009/10/18(日) 08:28:36
>>188
Sun 4が出た頃より、良くなることなんてあるのかなあ。
Javaが全然商売になってないしなあ。
0191名無しさん＠お腹いっぱい。2009/10/18(日) 11:40:04
ないだろ
0192名無しさん＠お腹いっぱい。2009/10/18(日) 19:35:16
8コア64スレッドのCPUをダバダバ積んだOracleマシンを
山ほど売れるかどうか
0193名無しさん＠お腹いっぱい。2009/10/18(日) 19:43:47
大規模DBはこれから結構な量がMapReduceに移行していく可能性があるし、
Oracleもうかうかしてられんよ。

まぁSunはともかくOracle滅びろと思ってる俺なんかはニヨニヨしながら見てられますが
0194名無しさん＠お腹いっぱい。2009/10/18(日) 19:56:21
>>193
同意。しかし Oracleの追随もきっとすごいと思う。TimesTen DBみたいに初めは別製品として
出しておいて、次のメジャーリリースで本体に取り込むんじゃないかな。想像だけどね。
0195名無しさん＠お腹いっぱい。2009/10/18(日) 20:30:02
>>194
おいおい、Times TenはOracle出身じゃないんだが。
0196名無しさん＠お腹いっぱい。2009/10/18(日) 21:20:04
TIMES TEN って 「oracleの10倍速い」っていうふれこみの製品だったんだけど。
oracle に買収されたのは皮肉というかなんというか。
0197名無しさん＠お腹いっぱい。2009/10/18(日) 21:45:52
TIMES TEMは更新時のジャーナルを取らないってきいたことがある。
それでもデータベースって名乗っているところが怖い。
最近のＩＴは嘘つき商品ばっかになってきた。red hatのリアルタイム
linuxとかねー。割り込み応答時間の保証をしないのにリアルタイム
OSって名乗っていいのか？それだったらよほどsolarisのほうがリアル
タイム。まあ、株のトレーダーは名前だけでだませるから商売になる
んだろうが。。。
0198名無しさん＠お腹いっぱい。2009/10/18(日) 23:50:25
メモリ・データベースってこと、忘れてないか?
0199名無しさん＠お腹いっぱい。2009/10/19(月) 01:09:25
TimeTenはジャーナル取るよ。ただし基本的に非同期。

MapReduceっぽいことは今でもOracle Coherenceでできるはず。
まあこれも買収製品ですけど
0200名無しさん＠お腹いっぱい。2009/10/19(月) 10:17:12
もちろん、ORACLE DBMSの先行きはわからん、ということが含まれてるよ、この買収は。
だからこそ Sun製品に力入れるとあれほど念をを押す。
0201名無しさん＠お腹いっぱい。2009/10/19(月) 15:59:09
>>175
いつの時代だよｗｗｗ
0202名無しさん＠お腹いっぱい。2009/10/19(月) 22:02:33
なつかしいね
0203名無しさん＠お腹いっぱい。2009/10/21(水) 21:19:48
http://blogwatcher.pi.titech.ac.jp/nandemorss/index.cgi?url=http%3A%2F%2Fpc12.2ch.net%2Ftest%2Fread.cgi%2Funix%2F1254895521%2F
0204名無しさん＠お腹いっぱい。2009/10/21(水) 22:19:29
titechですか？
そういえばそろそろ4年経ちますね。次はきまったのかな？
0205名無しさん＠お腹いっぱい。2009/10/22(木) 05:03:18
>>199
TimeTenはジャーナル取るよ。ただし基本的に非同期

トンクス。でもサーバが落ちたらデータ修復できないじゃん。
0206名無しさん＠お腹いっぱい。2009/10/22(木) 18:36:29
なのでレプリケーションをとって二重化するのが定番＞TimesTen
そしてレプリケーションも同期と非同期が選べます。これまた基本は非同期ですが
0207名無しさん＠お腹いっぱい。2009/10/22(木) 23:39:43
なるほどね。サーバー２重化ね。FT機がいるわけね。
0208名無しさん＠お腹いっぱい。2009/10/25(日) 17:01:12
ttp://www.theregister.co.uk/2009/10/25/apple_drops_zfs/
0209名無しさん＠お腹いっぱい。2009/10/25(日) 18:15:30
やっぱり
0210名無しさん＠お腹いっぱい。2009/10/26(月) 01:28:18
UFSもだ。
0211名無しさん＠お腹いっぱい。2009/10/26(月) 23:11:45
Oracleが巨人IBMに“宣戦布告”−誰のための競争？
http://enterprise.watch.impress.co.jp/docs/series/infostand/20091026_324389.html
0212名無しさん＠お腹いっぱい。2009/10/27(火) 02:35:43
>>誰のための競争？

絶滅危惧種たる儲のためのリップサービス
0213名無しさん＠お腹いっぱい。2009/10/27(火) 06:51:55
買収計画の停滞によりサンは毎月約1億ドルの赤字が発生
0214名無しさん＠お腹いっぱい。2009/10/27(火) 09:11:24
>>211
すくなくとも、Oracleに対してハードウェアで協力してた連中の「ため」では、
ないわなww HPと DELLだっけ?
0215名無しさん＠お腹いっぱい。2009/10/28(水) 13:34:40
OracleのExadata V2って中身はSunのXeon鯖にSunFlashFireCardを刺したものだけど
CPUも新しくなってる割にはこんなチート噛ましても性能は
前モデルHP Oracle Database Machineのたった2倍程度でしかないのね
0216名無しさん＠お腹いっぱい。2009/10/28(水) 16:12:54
そうだな、HPもチート噛ましてさっさと追いつけばいいのにな。
まあ、元々がチートなら難しいんだろうがwww
0217名無しさん＠お腹いっぱい。2009/10/29(木) 00:52:16
いやXeonって世代が変わってFlashFireCardで下駄を履かせても
2倍程度にしか速くならないパチモンだなって言いたかったのだが
はっきり書けば良かったな
0218名無しさん＠お腹いっぱい。2009/10/29(木) 08:09:28
何だこいつ
プギャって欲しいのか
0219名無しさん＠お腹いっぱい。2009/10/29(木) 09:20:14
もともと、
ランダムアクセス性能の低いHDDでも何とか性能を出そうと様々な努力をする
っていうシステムじゃん、データベースって。

フラッシュメモリ使ってランダムアクセスを高速化して、性能が2倍になったのなら、けっこういい線いってると思うよ。
■ このスレッドは過去ログ倉庫に格納されています