Sun Microsystems 最上川上流
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001名無しさん＠お腹いっぱい。
2009/04/09(木) 15:39:23【意訳】五月雨のように断続的に数々のIT企業を買収して集めても、
業績の下落ぶりはまるで急流のように早く、あとには何も残らない。
【補足】
スレッドタイトルは、一説に最上川上流に不法投棄のゴミが溜まって
いる惨状を某企業の内情なぞらえて詠んだ哀歌とも。詠人不知。
【前スレ】
Sun Microsystems 最大の超新星
http://pc12.2ch.net/test/read.cgi/unix/1233928036/
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> ってことだろ。
違うよ。印刷して拡大コピーして百回読んだら?
0880名無しさん＠お腹いっぱい。
2009/05/09(土) 18:13:34> よほど悔しいと見える。
...なんで、オレが「悔しい」んだ? 誰か教えてくれ!!
> 「リッチな回路」ってのはSunの人がIntel批判として言ったことなんだが、
うは。そんなこと知ってるわけないわな、「本人」以外に。
Sunの人だぁ?? 死ねば? マジで。
0881名無しさん＠お腹いっぱい。
2009/05/09(土) 18:14:360882名無しさん＠お腹いっぱい。
2009/05/09(土) 18:17:05コンパイラが用意したmemcpy()の実装が遅くて自作したことがあるんだが、
memcpyの高速化のポイントはSIMD演算なんかじゃないよ。
拡張命令は使うが、それは、キャッシュのプリフェッチ制御と、
幅が広いという理由でSIMD用のレジスタにロード/ストアするだけ。
SIMD演算なんか、しない。
つまり、128bitのスカラー処理なんだよ。
拡張命令がなかった頃は、
FPUのレジスタが64bit幅だったんで、
浮動小数点でもないのに、FPUのレジスタを使ってコピーしてたなぁ。
0883名無しさん＠お腹いっぱい。
2009/05/09(土) 18:19:24はあ。またズレた話ですね。なんのすり替えですか?
だれか本気にしてるとでも思ってるのかこの「リッチな回路」が
0884名無しさん＠お腹いっぱい。
2009/05/09(土) 18:21:27それ、SIMDの話な。
>>879
おまえが記事を誤解しているんじゃないか?
>>880
スレを読み進めていくと、その後も連投しまくりだな、おい。
>>881
「リッチな回路」の話に噛みついていた、おかしな人「本人」ですか?
0885名無しさん＠お腹いっぱい。
2009/05/09(土) 18:22:30自動ベクトル化できる部分は少ないってことくらい、すでに既出のレスを読んで理解しろよ。
0886名無しさん＠お腹いっぱい。
2009/05/09(土) 18:23:420887名無しさん＠お腹いっぱい。
2009/05/09(土) 18:23:510888名無しさん＠お腹いっぱい。
2009/05/09(土) 18:26:51なんでアンチSIMDとSIMDマンセーの戦いになってるんだ？？？
0889名無しさん＠お腹いっぱい。
2009/05/09(土) 18:33:09正味無知なんだな。標準ライブラリの SIMD使った高速化とか、枚挙にいとまがないぞ。
後藤さんも、Intelも、その他の誰も、おまえみたいなことは言ってないぞ。
すこしは勉強して知識つけろよ。性格も直せよ。最悪だぞw
0890名無しさん＠お腹いっぱい。
2009/05/09(土) 18:35:21ちがうよ。「x86 ISAはクズである」という、周知の事実に対して、
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
くやしくてくやしくてくやしくてくやしくてくやしくてくやしくてくやしくて
仕方がないけど知識の足りない人が必死にすり替えを繰り返してるだけ。
0891名無しさん＠お腹いっぱい。
2009/05/09(土) 18:38:050892名無しさん＠お腹いっぱい。
2009/05/09(土) 18:47:160893名無しさん＠お腹いっぱい。
2009/05/09(土) 18:54:31SIMD化率は50%もいってないんだが。
0894名無しさん＠お腹いっぱい。
2009/05/09(土) 18:55:341. AVXはこれまでの SIMD拡張と大差ない
2. SIMD拡張はゲームや科学技術計算にしか効果がない
3. x86命令は今後も安泰
4. x86の速さの決め手は「リッチな回路」
全部間違い。いや〜笑かすww
0895名無しさん＠お腹いっぱい。
2009/05/09(土) 18:56:54SIMD命令を使って高速化ってのはさ、RISC的じゃないよな。
どんどん便利な命令を追加してくんだもの。
0896名無しさん＠お腹いっぱい。
2009/05/09(土) 18:59:04なんだか自分で火を付けて煽ってるようなのだがｗ
【レス抽出】
対象スレ：Sun Microsystems 最上川上流
キーワード：リッチな回路
864 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/05/09(土) 16:30:40
なんか、「リッチな回路」思い出したよ、あまりのバカさ加減にw
868 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/05/09(土) 17:11:22
>>866
はぁ。さあねw やっぱり「リッチな回路」、で?
//以下略
0897名無しさん＠お腹いっぱい。
2009/05/09(土) 19:01:141. *当分の*AVXはこれまでの SIMD拡張と大差ない
2. SIMD拡張はゲームや科学技術計算にしか*大きな*効果がない
3. x86命令は今後も*使わざるをえない*
4. x86の速さの決め手は*スケールメリットによって強引に実現した*「リッチな回路」
ちゃんと理解しようぜ。
Intelが莫大な投資をしてる最先端プロセスと開発力でSPARCを実装したら、
Sunのそれよりも、かなり高速なものができると思うぞ。アーキテクチャだけでなく論理設計が一緒でも。
0898名無しさん＠お腹いっぱい。
2009/05/09(土) 19:02:190899名無しさん＠お腹いっぱい。
2009/05/09(土) 19:03:54これがSunの人の「リッチな回路」が指すことだろ。
Intel厨が、そんなことはない、x86アーキテクチャは効率的なんだ、って言ってたようだが・・・。
なんかさ、相手をちゃんと見よう是。
0900名無しさん＠お腹いっぱい。
2009/05/09(土) 19:05:57いいから後藤さんの記事ひゃっぺん読んでこいや。アホか。
0901名無しさん＠お腹いっぱい。
2009/05/09(土) 19:06:520902名無しさん＠お腹いっぱい。
2009/05/09(土) 19:17:500903名無しさん＠お腹いっぱい。
2009/05/09(土) 19:25:16どうしてSIMDの話になってるんだろう
0904名無しさん＠お腹いっぱい。
2009/05/09(土) 19:27:090905名無しさん＠お腹いっぱい。
2009/05/09(土) 19:38:56そりゃ、
「SIMD命令の」命令長が長いから・・・
っていう話だからさ。
でさ、AVXもまた広義のx86に含まれるわけです。
8086にあった命令がまったく使われなくなっても、x86なんですよ。
0906名無しさん＠お腹いっぱい。
2009/05/09(土) 19:39:480907名無しさん＠お腹いっぱい。
2009/05/09(土) 19:43:220908名無しさん＠お腹いっぱい。
2009/05/09(土) 19:45:16それまでは淫拡張
レス数が900を超えています。1000を超えると表示できなくなるよ。