Sun Microsystems 最上川上流
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2009/04/09(木) 15:39:23【意訳】五月雨のように断続的に数々のIT企業を買収して集めても、
業績の下落ぶりはまるで急流のように早く、あとには何も残らない。
【補足】
スレッドタイトルは、一説に最上川上流に不法投棄のゴミが溜まって
いる惨状を某企業の内情なぞらえて詠んだ哀歌とも。詠人不知。
【前スレ】
Sun Microsystems 最大の超新星
http://pc12.2ch.net/test/read.cgi/unix/1233928036/
0779名無しさん＠お腹いっぱい。
2009/05/08(金) 12:13:43そんな上等なもんじゃ、ないわなww
> もし建設的な話をしたいならね。
可能性ゼロ。
0780名無しさん＠お腹いっぱい。
2009/05/08(金) 12:59:44あるときUNIX鯖から乗り換えた客が、
負荷試験やったら
CPU使用率が高すぎたってクレームが。
客から来たメールには、
Windowsのタスクマネージャの画像が。
そんなので云々してほしくないのだが、
高いところでも30%くらいでしかない。
彼らには、たった30%でも、いつ飛ぶかヒヤヒヤなんだってさ。
こっちは100%貼り付きでも問題ないように作ってるんだけどな。
0781名無しさん＠お腹いっぱい。
2009/05/08(金) 14:07:3430%だとむしろ負荷かかってないと思う
0782名無しさん＠お腹いっぱい。
2009/05/08(金) 14:29:300783名無しさん＠お腹いっぱい。
2009/05/08(金) 16:22:05ことだ。やっぱ x86 ISAはカスだからな。やっと終るな。
0784名無しさん＠お腹いっぱい。
2009/05/08(金) 16:31:41AVXの命令エンコーディングみてゲンナリしたよ。
既存のSSE系列から変えるのに、命令長が少ししか縮まない。
もうね、アホかと。
いっそページディスクリプタにフラグを追加してだな、
ページ事に命令セットを変更できるようにしたらいいんだよ。
そしたら、同一プロセス内で複数の命令セットを混在できるっしょ。
0785名無しさん＠お腹いっぱい。
2009/05/08(金) 16:42:34> そしたら、同一プロセス内で複数の命令セットを混在できるっしょ。
なに言ってんだか.. 古い方（x86な）はとっとと葬るんだよ。
両方性能出るわけないじゃん。Itaの時と同じ。互換フォロー扱いで
「それじゃ性能出ませんよ?」。全書換えの時が来ましたw
0786名無しさん＠お腹いっぱい。
2009/05/08(金) 16:49:240787名無しさん＠お腹いっぱい。
2009/05/08(金) 16:50:21ttp://pc.watch.impress.co.jp/docs/2008/0410/kaigai435.htm
| AVX/FMAを例に取ると、SSEから、オペランドモデルを変える、（..中略..）
| 簡単に言えば、RISC風のモダンな命令に切り替える。
ソフトウェアをベクタ型浮動小数点演算を多用するように書き換える、のか、
シングルイシューの多コアがうまく効くように多スレッドに書き換える、のか。
どっちが有効だろうねぇ?
0788名無しさん＠お腹いっぱい。
2009/05/08(金) 16:53:53Itaniumにおけるx86バイナリの実行とは、まるで違うだろ。
0789名無しさん＠お腹いっぱい。
2009/05/08(金) 16:57:55とりあえずは前者だろう。
現実的に見て。
後者は、ゲームとかマルチメディアだけでなく、ワープロソフトなどにも影響を与えてしまう。
0790名無しさん＠お腹いっぱい。
2009/05/08(金) 17:46:29でも結局実質は x86から移行という点で Itaと同じだし、そっぽ向かれると
x86も終って Intelしゅーりょー、という目もあるわな。
Itaをもう一度くりかえす。
ただひとつだけ言えたことは、「x86 ISAはクソだった。」
おあとがよろしいようで。
0791名無しさん＠お腹いっぱい。
2009/05/08(金) 17:58:25ちげーよ。
MMXからSSE2への移行と似たようなもんだよ。
0792名無しさん＠お腹いっぱい。
2009/05/08(金) 18:00:20IA64も良いものじゃないが、Intelに向かってx86がクソだって言うのはお門違いだ。
0793名無しさん＠お腹いっぱい。
2009/05/08(金) 18:12:23? Intelはことあるごとに「x86はクソ」って言ってるよ。
ここらへんに巣食ってて後生大事にかばうバカがいるから、教えてやってんだよww
0794名無しさん＠お腹いっぱい。
2009/05/08(金) 18:17:140795名無しさん＠お腹いっぱい。
2009/05/08(金) 18:19:40ああ、ぜんぜん違いますよ、そんなのとは。
Intelの CPUアーキテクトが
| 今日、50%のコードがベクタライズされているとしたら、残りの 50%も
| ベクタライズしたい。（..中略..）ベクタ対応を進めて行く必要がある。
0796名無しさん＠お腹いっぱい。
2009/05/08(金) 18:44:49Intelが認めているのなら、なおさら、Intelに言って認めさせようという行為はナンセンスだね
0797名無しさん＠お腹いっぱい。
2009/05/08(金) 18:46:20それの分母は、
ベクタライズ可能な、ベクタライズによる性能向上が見込めるコード
だよ。
0798名無しさん＠お腹いっぱい。
2009/05/08(金) 18:52:30ちげーよ。
795がコピペした部分は、AVXについての発言ではない。
ベクトル化によって性能向上を目指すのなら、現在ではベクトル化不可能なものまでベクトル化する技術を発明しなくてはならない
っていう意味。
0799名無しさん＠お腹いっぱい。
2009/05/08(金) 19:03:23はぁ???? 何言ってんの? オツムだいじょーぶ? Intelになんて言ってないんだよ、
あんたに言ってんだってwwwwwwwwwwwwwwwww
0800名無しさん＠お腹いっぱい。
2009/05/08(金) 19:05:05おいおいーー。後半はそうだけど、AVXについてだよー。なんでそこ分離するかな。
ベクトル化して、AVXで面倒みるんじゃんよ。ちゃんと読んでね、後藤さんの記事。
0801名無しさん＠お腹いっぱい。
2009/05/08(金) 19:06:050802名無しさん＠お腹いっぱい。
2009/05/08(金) 19:34:14現時点でベクトル化できないものを、どうやってベクトル化するの? どうやってAVXで面倒みるの?
そもそも、すべてのx86命令をAVXで巻き取ったら、AVXは必要なくなる。
0803名無しさん＠お腹いっぱい。
2009/05/08(金) 19:37:11釣りだろ ほっとけ
0804名無しさん＠お腹いっぱい。
2009/05/08(金) 20:04:020805名無しさん＠お腹いっぱい。
2009/05/08(金) 20:06:30レッテル貼り乙
AVXの現物が、MMX→SSE2へのシフトと同類である以上、
AVX登場でx86と決別ということにはならんさ。
0806名無しさん＠お腹いっぱい。
2009/05/08(金) 20:08:05>現時点でベクトル化できないものを、どうやってベクトル化するの?
0808名無しさん＠お腹いっぱい。
2009/05/08(金) 20:22:46> そもそも、すべてのx86命令をAVXで巻き取ったら、AVXは必要なくなる。
必要なくなるのは x86命令。
念押しとくが、Intelがそう言ってるのよ、「x86 ISAはクズ」。
0809名無しさん＠お腹いっぱい。
2009/05/08(金) 20:25:03読んどけよ、時間無駄にしたな?wwww
0810名無しさん＠お腹いっぱい。
2009/05/08(金) 20:25:20AVX命令であることを示すプリフィクスが必要なくなるのよ。
そしたらそれはもう、AVXではない。
0811名無しさん＠お腹いっぱい。
2009/05/08(金) 20:31:39元記事の文章含めて一切してないですが。
都合の悪いことは理解しないフリする主義か?
0812名無しさん＠お腹いっぱい。
2009/05/08(金) 20:35:29すべての命令をAVXで巻き取るなんて話は、
元記事の文章のどこにもありませんが。
0813名無しさん＠お腹いっぱい。
2009/05/08(金) 20:38:460814名無しさん＠お腹いっぱい。
2009/05/08(金) 20:40:56当該の話は、AVXについてではなく、もっともっと先の将来についての話。
ベクトル化とメニーコア化どっちに進むの? っていう質問に対して、両方ヤル(どちらか片方だけでは済まない)よって話。
0815名無しさん＠お腹いっぱい。
2009/05/08(金) 20:41:49あなたの脳内にいる架空の人物だね、そりゃ。
かばっているわけでもないのに、かばっていると勝手に思い込んでるんだよ、チミは。
0816名無しさん＠お腹いっぱい。
2009/05/08(金) 21:26:090817名無しさん＠お腹いっぱい。
2009/05/08(金) 21:31:10っ 鏡
0818名無しさん＠お腹いっぱい。
2009/05/08(金) 22:17:32http://www.oracle.com/sun/lje-oracle-sun-faq.pdf
SPARCはやめへんで〜、だって
0819名無しさん＠お腹いっぱい。
2009/05/08(金) 23:15:01もうどうでもいい話じゃないのか？
0820名無しさん＠お腹いっぱい。
2009/05/08(金) 23:21:270821名無しさん＠お腹いっぱい。
2009/05/08(金) 23:45:03富士通にとっては嬉しいだろうね。
Oracleからすると、金の掛かるCPU開発は自前でやる必要が無く、
強力とはとても言えない富士通だけに自分たちの言い分は通しやすい
というおいしい関係。失敗しても、これまで通りHPと仲直りすればいい。
一方の富士通としては、鳴かず飛ばずの状況から一歩前に進む可能性の
ある千載一遇あるいは唯一のチャンスと言え、利用される立場とはいえ
乗る価値はある。
それでもドM体質の日本のベンダーのこれまでの例からすれば、
かなり有利といえるかと。
0822名無しさん＠お腹いっぱい。
2009/05/08(金) 23:55:410823名無しさん＠お腹いっぱい。
2009/05/08(金) 23:56:010824名無しさん＠お腹いっぱい。
2009/05/09(土) 00:04:47富士通のサーバ？
→そんなマイナー系、買う訳無いだろ。
これから）
Oracle（中身は富士通）のサーバ？
→OracleDB動かすのにOracle製なら安心だし買うか。
位の意味はある。
H*-UXがハイエンドでそれなりに強い理由としては、そのゾーンでは
Oracleが推してたって事情はあるからな。
0825名無しさん＠お腹いっぱい。
2009/05/09(土) 00:37:13なんかヤバいな。
> We want to work with Fujitsu
> to design advanced features into the SPARC microprocessor
> aimed at improving Oracle database performance.
Rock消えたか?
0826名無しさん＠お腹いっぱい。
2009/05/09(土) 00:56:310827名無しさん＠お腹いっぱい。
2009/05/09(土) 00:58:36>なんかヤバいな。
いや、むしろgdgdなRockをドサクサに紛れて「無かった事」にしてくれる
Oracleは救世主だろうw
0828名無しさん＠お腹いっぱい。
2009/05/09(土) 02:09:40今から新コア作り始めても出荷まで2-3年は必要
間を埋める玉はRockしかない
もしOracleがSunに完成させる能力がないと見切れば
富士通にRockの完成も手伝ってくれと言うに決まってる
0829名無しさん＠お腹いっぱい。
2009/05/09(土) 03:32:05富士通にやらせときゃえんちゃう？
0830名無しさん＠お腹いっぱい。
2009/05/09(土) 06:08:42Sun：Solaris 開発
Oracle：Oracle 開発
富士通：SPARC Server, Solaris, Oracle サポート
今までの業務提携がより密になるってことだから正に win-win な関係じゃない
0831名無しさん＠お腹いっぱい。
2009/05/09(土) 06:22:07Solarisとピザボックス, ランチボックスの開発だけしてくれｗ
0832名無しさん＠お腹いっぱい。
2009/05/09(土) 06:28:58実際に作るかどうかは関係ない
0833名無しさん＠お腹いっぱい。
2009/05/09(土) 08:06:29phase2: OracleはSPARC開発の投資を中止。代わりに開発リソースを富士通へ移管。
phase3: 富士通大赤字でCPUの開発から撤退。
0834名無しさん＠お腹いっぱい。
2009/05/09(土) 08:37:14んなこたーないだろう。
Oracleにとって存在価値があるのはNiagaraシリーズとSPARC64
前者は、Intelよりも省電力であること。
後者は、Intelよりも高信頼性であること。
Oracleのソフトはマルチスレッド処理に向いているので、
シングルスレッド追求のRockは必要ないだろう。
ていうか、RockがSPARC64よりも高い信頼性を確保できるとは思えない。
信頼性が中途半端で、消費電力がデカくて、スループットが低い
そんなの、Oracleには必要ないだろ。
0835名無しさん＠お腹いっぱい。
2009/05/09(土) 08:47:50新しいものが売れる業界なのだよ
シングルスレッド性能が必要なアプリケーションは存在する
要は売り方の問題だ
Oracleの子会社になってもOracle専用H/W屋になったわけではない
0836名無しさん＠お腹いっぱい。
2009/05/09(土) 08:53:26Symfowareは、Powergresは、どないすんねん!w
0837名無しさん＠お腹いっぱい。
2009/05/09(土) 10:06:16Rockはスケジュール遅延して、タイムリーに市場に投入できなかったので、ダメぽ。
Itaniumと同じように、現物がユーザーの手に渡る前に、過去のものになるだろう。
> シングルスレッド性能が必要なアプリケーションは存在する
といっても、Oracleにとって重要でなければ、
莫大なコストとリスクがある野心的なプロセッサの開発なんて、
やりたくないだろう。
0838名無しさん＠お腹いっぱい。
2009/05/09(土) 11:39:42一応ハイエンドCPUという位置づけだから、今からプロセス変更させようとすると、また設計からやり直しになる。
Niagaraのようなローエンドなら、設計変更を最小限にして、ただシュリンクする戦略でもいけるけど。
0839名無しさん＠お腹いっぱい。
2009/05/09(土) 11:50:53それでも足りないっていうユーザーには、M9000の最大構成でも売っとけばいいんだよ。
0840名無しさん＠お腹いっぱい。
2009/05/09(土) 12:03:550841名無しさん＠お腹いっぱい。
2009/05/09(土) 12:37:43Sun shareholders act to block Oracle deal
http://www.theregister.co.uk/2009/05/08/sun_oracle_court_action/
まあ、ゴネ得を狙ってるだけかもしれんが
0842名無しさん＠お腹いっぱい。
2009/05/09(土) 12:47:17Sun Micro may have violated U.S. bribery law
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=217400083
0843名無しさん＠お腹いっぱい。
2009/05/09(土) 13:46:43Itaは出た結果遅かったんだろが。Rockは遅延しただけでまだ出てないだろ。
ぜんぜんちゃうわい。
そもそも新アーキで遅延せずに出る CPUなんかほとんど皆無だし。
どこのドしろーとだよ。ぬぁ〜にが gdgdだ、おまえが gdgdなんだよ。ゐんで寝とけボケw
0844名無しさん＠お腹いっぱい。
2009/05/09(土) 13:48:27趣旨はわからんでもないが、ピザボックスはもう要らんだろ。CRTなくなったんだから。
iMacと Mac miniにしかならんと思うけど。
0845名無しさん＠お腹いっぱい。
2009/05/09(土) 13:51:34> OracleDBのベンチマークをとるとT2+の4ソケで、十分な性能が出るんじゃね?
そうなるだろな。旧プロセスかつ低いクロックで競争力あるんだから、
そのままシングルスレッド性能がある程度上がるだけでかなりの値が出ると
予想できる。先の性能向上も期待できる。
0846名無しさん＠お腹いっぱい。
2009/05/09(土) 13:57:180847名無しさん＠お腹いっぱい。
2009/05/09(土) 14:40:480848名無しさん＠お腹いっぱい。
2009/05/09(土) 14:41:300849名無しさん＠お腹いっぱい。
2009/05/09(土) 14:46:13たとえ性能でNehalemに勝てなくってもSPARC/Solarisを欲しがる客が
すぐにいなくなるわけじゃないよ
これまでと同様、だんだんと置き換わっていくだけ
0850名無しさん＠お腹いっぱい。
2009/05/09(土) 14:55:500851名無しさん＠お腹いっぱい。
2009/05/09(土) 14:58:010852名無しさん＠お腹いっぱい。
2009/05/09(土) 15:08:03Bridgeシリーズで SIMD主体に移行するから、旧来の x86なだけのソフトウェアの
性能は停滞する。ソフトウェアが SIMD方面へ移行しなければもう amd64のような
逃げ道もない。
0853名無しさん＠お腹いっぱい。
2009/05/09(土) 15:10:490854名無しさん＠お腹いっぱい。
2009/05/09(土) 15:18:530855名無しさん＠お腹いっぱい。
2009/05/09(土) 15:35:49なんでもかんでもSIMD化できるわけじゃないからSIMD化で
増やした演算器でSMTを強化したりしないかね？
で、命令のデコードがネックになるから、余ったスレッドは
スカウトスレッドとか投機的実行で使うと
0856名無しさん＠お腹いっぱい。
2009/05/09(土) 15:42:14予想通りの書き込みだな。
遅延するのが普通
ゆえに
遅延しても問題ない
っていうのは、いくらなんでも論理的におかしい。
遅延を想定して先を見越したスペックで開発しているので、遅延も予定内
ゆえに
予定内の遅延なら問題ない
っていうのなら、わかるんだが、しかし、Rockは予定外の遅延してるんで。
Rockが出る頃には、他のプロセッサの性能も上がっているし、
たとえ出た瞬間には勝っていても、すぐに追い越されるだろ。
矢継ぎ早に新製品を投入するIntelやAMDに、Sunは対抗できないでしょう。
ちなみに、Itaniumは出た結果遅かったが、それは遅延が酷かったから。
当初の予定から普通に遅れての1999年の早い時期での出荷も無謀に見えた。
新しいアーキ、最新の0.18ミクロンで設計、恐ろしく巨大なダイ、
130Wもの消費電力(P6系の倍)、800MHzという高い動作クロック(P6系は500MHz)、
133MHz DDRバス(P6系は100MHz SDRバス)、などなど。
あまりに最新のものを詰め込みすぎた。
0857名無しさん＠お腹いっぱい。
2009/05/09(土) 15:46:06> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
> 予想通りの書き込みだな。
0858名無しさん＠お腹いっぱい。
2009/05/09(土) 15:47:20x86うれしがって使ってるやつはやっぱりこの程度。
0859名無しさん＠お腹いっぱい。
2009/05/09(土) 15:49:16どうだろう。
T1は90nmで1.4GHz、T2は65nmで1.4GHzっしょ。
45nmで作っても、それほどクロックは上がらないと思う。
クロックが低いのはプロセス云々ではなく、
1クロックで通らないといけないゲートの数が多いからだろう。
パイプラインの段数が少ないからね。
>>852
おまえ、人に指摘されても、聞く耳もってないようだな。
AVXは、当分はSSE2のベクトル長を倍にしたものに毛が生えた程度だ。
ゲームや科学技術計算ではない、エンタープライズのアプリはSIMD化できんよ。
x64命令についてはコア数増加で、性能向上は続くだろうね。
0860名無しさん＠お腹いっぱい。
2009/05/09(土) 15:50:30貴方の目には、
> x86うれしがって使ってる
に見えるんだ。
自分の勝手な誤解に基づいて相手を罵倒するのは、恥ずかしいぞ。
0861名無しさん＠お腹いっぱい。
2009/05/09(土) 15:59:56「ベクトル化」はゲームや科学技術計算以外に使えないと思ってるんだな。
それだと後藤さんの記事は一切理解できないだろ?
「聞く耳もってない」とはなんともトホホな....w
0862名無しさん＠お腹いっぱい。
2009/05/09(土) 16:06:26これの、「●ベクタライゼーションを支援する SSE4命令」のとこ読んでみれ。
ttp://pc.watch.impress.co.jp/docs/2006/1004/kaigai307.htm
ああ、かわいそかわいそ。
Intelの CPUアーキテクトが何言ってるか理解できたか?
> 当該の話は、AVXについてではなく、もっともっと先の将来についての話。
とか、わけわからんこと言ってないで勉強しろよ?
0863名無しさん＠お腹いっぱい。
2009/05/09(土) 16:07:25もう恥しくて恥しくて。 ...え? 誤解って? なにが?
0864名無しさん＠お腹いっぱい。
2009/05/09(土) 16:30:400865名無しさん＠お腹いっぱい。
2009/05/09(土) 16:55:490866名無しさん＠お腹いっぱい。
2009/05/09(土) 17:08:28アホか？
0867名無しさん＠お腹いっぱい。
2009/05/09(土) 17:10:07たとえばこんな話
ttp://knight.dip.jp/index.php?p=256
勘定系 基幹系 情報系 は memcpy()使わないんだっけかw?
＃ どこまでアホなんだ。とどまるところを知らんwwww
0868名無しさん＠お腹いっぱい。
2009/05/09(土) 17:11:22はぁ。さあねw やっぱり「リッチな回路」、で?
0869名無しさん＠お腹いっぱい。
2009/05/09(土) 17:15:55Intel大嫌いIntelなんかシラネーヨってスタンスなら黙っていれば馬鹿にされずに済むのにね
かわいそう
0870名無しさん＠お腹いっぱい。
2009/05/09(土) 17:30:060871名無しさん＠お腹いっぱい。
2009/05/09(土) 17:44:030872名無しさん＠お腹いっぱい。
2009/05/09(土) 17:49:47消費電力増を回避するためには、完全に AVXに移行して
> "伝統的x86"を脱する
他に方法はナイノヨ。
ttp://pc.watch.impress.co.jp/docs/2008/0407/kaigai434.htm
つまり、Sandy Bridge以降では AVX以前の命令を使ったソフトウェアは
相対的にだんだん遅くなっていく。
というか、上記記事によれば、Nehalemで既にデコード回路の改善を
見送っている。
で、「RISCになる」とは書いてないが、ほぼそういうことだよ。残念だったねwwwwww
0873名無しさん＠お腹いっぱい。
2009/05/09(土) 17:55:490874名無しさん＠お腹いっぱい。
2009/05/09(土) 18:04:400875名無しさん＠お腹いっぱい。
2009/05/09(土) 18:07:08アイ、アイ、、、
アイテニアムソリューションアライアンス！！
0876名無しさん＠お腹いっぱい。
2009/05/09(土) 18:07:19例の記事でIntelのアーキテクトが言ってるのは、
SIMD化による性能向上で進めていくと、いずれ、現状でSIMD化しようがない命令までをもSIMD化するためのブレイクスルー発明が必要だ
つまり、SIMD化だけではダメだから、メニーコアなど他のアプローチも必要よ
ってことだろ。
そりゃ多少はSIMDで処理できる部分もあるが、微々たるものだね。
0877名無しさん＠お腹いっぱい。
2009/05/09(土) 18:08:27よほど悔しいと見える。
「リッチな回路」ってのはSunの人がIntel批判として言ったことなんだが、
いまだに理解できないらしい。
いちど先入観で染まってしまうと、もうダメね。
0878名無しさん＠お腹いっぱい。
2009/05/09(土) 18:11:35結局、この議論(?)の争点って何？
0879名無しさん＠お腹いっぱい。
2009/05/09(土) 18:11:41> ってことだろ。
違うよ。印刷して拡大コピーして百回読んだら?
■ このスレッドは過去ログ倉庫に格納されています