Sun Microsystems 最富の庇護
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2009/10/07(水) 15:05:210072名無しさん＠お腹いっぱい。
2009/10/09(金) 20:07:140073名無しさん＠お腹いっぱい。
2009/10/09(金) 20:44:37http://www.google.co.jp/search?hl=ja&q=TSMC+40nm+%E6%AD%A9%E7%95%99%E3%81%BE%E3%82%8A
http://www.google.co.jp/search?hl=ja&q=%E5%B0%91%E9%87%8F+Radeon+4770+OR+5870
0074名無しさん＠お腹いっぱい。
2009/10/09(金) 20:59:34そういう次元の問題じゃないと思うんだがなぁ…
なんつーか存在意義自体があやしいと言うか。
0075名無しさん＠お腹いっぱい。
2009/10/09(金) 21:22:30秋葉原って、スポット市場っていうか、余りモノの処分地じゃないか。
そこに最新製品が出まわるのは、マーケティング目的の宣伝のため。
最近はGPUを活用しようっていう流れがあって、
最新製品は開発者やメーカー、特殊な企業ユーザなどに先に充当される。
たとえばAMDのCPUは、秋葉原に出る前に、スパコンに出荷されてたりする。
0076名無しさん＠お腹いっぱい。
2009/10/09(金) 21:31:050077名無しさん＠お腹いっぱい。
2009/10/09(金) 21:48:25>最新製品は開発者やメーカー、特殊な企業ユーザなどに先に充当される。
妄想で変なこと書かないほうがいいよ
0078名無しさん＠お腹いっぱい。
2009/10/09(金) 21:57:00TSMC40nmプロセスで生産されているGPU（今現在Radeonのみ）が
率先して充当される 特殊な企業 の具体的な名称を60分以内に複数羅列してちょ。
0079名無しさん＠お腹いっぱい。
2009/10/09(金) 22:19:16たとえばハリウッドの映画会社のCG部門。
具体的な社名は必要ないでしょう。
0080名無しさん＠お腹いっぱい。
2009/10/09(金) 22:23:360081名無しさん＠お腹いっぱい。
2009/10/09(金) 22:24:08http://journal.mycom.co.jp/articles/2009/10/06/gtc05/005.html
＞ 2005年時のレンダーファームはAMDのOpteron CPUベースで構築された事が分かっている。
~~~~~~~~~~~~~
0082名無しさん＠お腹いっぱい。
2009/10/09(金) 22:30:340083名無しさん＠お腹いっぱい。
2009/10/09(金) 22:36:523ds、Maya、XSI等のメジャーソフトは言うに及ばず（＊）
DreamworksやILMの内製ツールも全てCPUベースだってば。
＊一部pliuginでGPU処理に対応しているものもある。
0084名無しさん＠お腹いっぱい。
2009/10/09(金) 22:39:25ん、厨房？
企業のシステム入れ替えペースはだいたい3〜4年って決まってんだよ
0085名無しさん＠お腹いっぱい。
2009/10/09(金) 23:02:57ファーストシリコンが戻ってきてから、最終的な製品になるまで、年単位で時間がかかるから。
0086名無しさん＠お腹いっぱい。
2009/10/09(金) 23:06:560087名無しさん＠お腹いっぱい。
2009/10/09(金) 23:24:33そこへ至るまでにもたっぷり時間がかかるのを忘れてもらっちゃ困るなぁ
0088名無しさん＠お腹いっぱい。
2009/10/09(金) 23:28:31ただ、Victoria Fallsと違ってリーク情報のみで、Sunからの発表が皆無なんだよなー。
0089名無しさん＠お腹いっぱい。
2009/10/10(土) 00:36:32radeってゲロフォースと比べるとGPGPU対応度は低いのでは
0090名無しさん＠お腹いっぱい。
2009/10/10(土) 00:39:22ILMのOpteronマザーにサクサクGPUボードを刺すだけのような気もするんだけど
そんなに容易じゃないのかな
当時はnForce Professonal全盛だったから相性で困ることもないような
0091名無しさん＠お腹いっぱい。
2009/10/10(土) 01:28:52パソコンじゃないんだから。
低コストでより多くの計算力を得るために、
余分な電源容量も、余分な空きスロットも、余分な冷却能力も、持たない
1Uサーバあるいはブレードサーバをラックに詰め込んでるでしょう、たぶん。
0092名無しさん＠お腹いっぱい。
2009/10/10(土) 01:43:42ttp://www.angstrom.com/products/titan64_superblade.htm
0093名無しさん＠お腹いっぱい。
2009/10/10(土) 06:05:190094名無しさん＠お腹いっぱい。
2009/10/10(土) 08:41:43Blade使ったこと無い?
0095名無しさん＠お腹いっぱい。
2009/10/10(土) 09:35:30つーかPCI-X世代の製品ってこと言いたかったんだが
0096名無しさん＠お腹いっぱい。
2009/10/10(土) 12:16:41「そう思いたい」という願望を、ここで発表するのはやめてくれないかな?
付き合いきれんのだよ、そのバカさ加減に。
ジャンクに 5寸釘でも打てや。自分ちで。ここは迷惑。
0097名無しさん＠お腹いっぱい。
2009/10/10(土) 12:27:120098名無しさん＠お腹いっぱい。
2009/10/10(土) 12:57:410099名無しさん＠お腹いっぱい。
2009/10/10(土) 13:06:38x86とSPARCで何が違うのさ、Oracle使う上で。
二代目Exadata、SPARCではなく、x86だったでしょ?
0100名無しさん＠お腹いっぱい。
2009/10/10(土) 13:14:50最初のスレから 2万回読め。ボケ。
0101名無しさん＠お腹いっぱい。
2009/10/10(土) 13:29:14つまり、理由は説明できない、と。
0102名無しさん＠お腹いっぱい。
2009/10/10(土) 14:05:560103名無しさん＠お腹いっぱい。
2009/10/10(土) 15:57:08x86に将来がないと言ったのは Intelだけどね。
0104名無しさん＠お腹いっぱい。
2009/10/10(土) 16:30:370105名無しさん＠お腹いっぱい。
2009/10/10(土) 16:50:340106名無しさん＠お腹いっぱい。
2009/10/10(土) 17:01:51BIOSはもうカンベン。
EFIはギャグだった、ひどいもんだ。ほんと仕様まとめる能力ねーよな、Intelは。
0107名無しさん＠お腹いっぱい。
2009/10/10(土) 18:41:412006年
http://japan.cnet.com/news/ent/story/0,2000056022,20099350,00.htm
Itaniumサーバの売上は、「Sun Sparc」サーバの売上の半分以上
2009年
http://pc.watch.impress.co.jp/docs/news/event/20090924_317313.html
「Itaniumアーキテクチャはすでに重要な目標を達成した。
すでに数カ月前にSPARC系のシステムの売り上げを上回ったのだ」
0108名無しさん＠お腹いっぱい。
2009/10/10(土) 19:10:130109名無しさん＠お腹いっぱい。
2009/10/10(土) 19:27:38ベースにしたらよかったのに。i960という有望なのがあったのに。実績もあったのに。
ダメだねぇ。評価能力ないねぇ。
0110名無しさん＠お腹いっぱい。
2009/10/10(土) 21:35:13SPARCの売り上げが半分に落ちただけじゃ
0111名無しさん＠お腹いっぱい。
2009/10/10(土) 21:41:580112名無しさん＠お腹いっぱい。
2009/10/10(土) 22:18:50そのIntelは何度もx86からの転換を試みているじゃないか。
その上で、やっぱり当分はx86だねってことを実証してきた。
で、SPARCは?
0113名無しさん＠お腹いっぱい。
2009/10/10(土) 22:22:11i960にunixマシンのメインCPUの実績、あったっけ?
0114名無しさん＠お腹いっぱい。
2009/10/10(土) 22:30:420115名無しさん＠お腹いっぱい。
2009/10/11(日) 00:20:54HP+Intelの会社の規模をSunと比べると、
最低でも10倍以上は売れてないといけないんだけどな。
少なくとも現時点ではね。
0116名無しさん＠お腹いっぱい。
2009/10/11(日) 00:35:23なんでパソコンやプリンタまで含めちゃうの?
0117名無しさん＠お腹いっぱい。
2009/10/11(日) 13:12:16> Sunのプロセサ部門のCTOであったMarc Tremblay氏がMicrosoftに移った
> Rockのチーフアーキテクト
> 私の推測ですが，Rockが死んだか，生き残る見込みが無くなったのが，
> 彼がSunを辞めてMicrosoftに移った原因ではないでしょうか？
続報ないのかな。
0118名無しさん＠お腹いっぱい。
2009/10/11(日) 13:27:16大金をはたいて、キーパーソンを引き抜いたのでは?
Javaのラムダ式を仕様策定、実装していた人も引き抜いた。
0119名無しさん＠お腹いっぱい。
2009/10/12(月) 09:38:190120名無しさん＠お腹いっぱい。
2009/10/12(月) 09:39:59実証されたのは x86の「まともさ」では、ないだろ?
x86である必要は全くない。
転換もできないんだから技術力もない。
0121名無しさん＠お腹いっぱい。
2009/10/12(月) 09:45:27x86には将来がないという話、
転換もできないインテルの発言だから信憑性ないんじゃない?
0122名無しさん＠お腹いっぱい。
2009/10/12(月) 09:49:50Sunが十分な待遇と仕事を与えなかったのが悪い。
Rockに十分な予算を与え、キャンセルせずに製品化していれば、いまもSunに残っていた可能性あるよ。
あと、マイクロソフトが優秀な人材を引き抜きまくって死蔵しているというのは誤解でしょう。
C#が3.0でラムダ式を導入してるから、死蔵ではないよ。
0123名無しさん＠お腹いっぱい。
2009/10/12(月) 10:17:27x86に将来がないと言わなかった会社は、当の Intelを含め、ひとつもない。
0124名無しさん＠お腹いっぱい。
2009/10/12(月) 10:25:410125名無しさん＠お腹いっぱい。
2009/10/12(月) 11:09:07じゃぁ、お前さんが技術力ないと切り捨ててるインテルではなく、他の会社の発言を引っ張ってきなよ。
0126名無しさん＠お腹いっぱい。
2009/10/12(月) 13:18:44おまえが1000億単位でSunに投資しなかったのが悪い。
以上、
0127名無しさん＠お腹いっぱい。
2009/10/12(月) 14:35:59http://www.publickey.jp/blog/09/27sparcjavamysqloracle_openworld.html
＼(^o^)／ｵﾜﾀ
0128名無しさん＠お腹いっぱい。
2009/10/12(月) 14:42:45実際存続するのは今 Sunにある技術。
オープンにやってくれるのかという点は心配だが、元々オープンでもなんでもない
会社の取り巻きが騒ぐのはまったくバカげてて白けるばかり。
0129名無しさん＠お腹いっぱい。
2009/10/12(月) 15:31:04> どの企業も提供できていない大きな価値だ
あれ、IBMは・・・何が足りないのかな。
0130名無しさん＠お腹いっぱい。
2009/10/12(月) 17:12:580131名無しさん＠お腹いっぱい。
2009/10/12(月) 18:39:15詰め込めるようになったおかげでx86のように汚いISAでも関係ない状態になったと。
0132名無しさん＠お腹いっぱい。
2009/10/12(月) 19:28:020133名無しさん＠お腹いっぱい。
2009/10/12(月) 21:42:22「適当」の意味知ってる？
0134名無しさん＠お腹いっぱい。
2009/10/12(月) 22:24:320135名無しさん＠お腹いっぱい。
2009/10/13(火) 02:41:11本来の意味で使う人は滅多にいない、
慣例的に使われている意味で解釈しろよ。
0136名無しさん＠お腹いっぱい。
2009/10/13(火) 09:04:08> C#が3.0でラムダ式を導入してるから、死蔵ではないよ。
移籍前ですが？
0137名無しさん＠お腹いっぱい。
2009/10/13(火) 12:03:16関係ないことにしないと誰も x86買わなくなるだろ?
0138名無しさん＠お腹いっぱい。
2009/10/13(火) 13:18:29そんなにSPARCのISAって綺麗なの?
0139名無しさん＠お腹いっぱい。
2009/10/13(火) 13:53:51（いわゆる当時の商用）RISCだから。
x86だけが莫大なリソースを注ぎ込んで延命されたが、他は全滅した。
0140名無しさん＠お腹いっぱい。
2009/10/13(火) 14:49:580141名無しさん＠お腹いっぱい。
2009/10/13(火) 14:58:38VAX他、多数。
もちろん 68kもだけど、特に特別視はしてないと思う。既に速くなかったから。
0142名無しさん＠お腹いっぱい。
2009/10/13(火) 15:06:07CISCはRISCを取り込み、
RISCはCISCを取り込み、
境界線がなくなったというのに
そもそもRISCってのは、
パイプラインの各段を1クロックで通過できる命令だけにしよう
という考え方であって、「単純な命令だけにしよう」じゃないのよ
昔は、加算に1クロックというのは妥当だったが、
今では、乗算が1クロックで済むので、加算のみの命令は単純過ぎて効率が悪い
SPARCのISAは、乗算が1クロックで出来ない時代の最適解かもしれないが、今の最適解じゃない。
0143名無しさん＠お腹いっぱい。
2009/10/13(火) 15:18:36>142 が言ってるような比較はそれこそ 15年前くらいの話だし、
そもそもがそんな商用 RISCは存在してない。
乗算搭載してない商用 RISC CPUって、いつの話やねん、と。すり替えも甚だしい。
0144名無しさん＠お腹いっぱい。
2009/10/13(火) 15:19:580145名無しさん＠お腹いっぱい。
2009/10/13(火) 15:22:34今の商用RISCって、
A+B*Cのアドレスからロードして、なおかつCをポストインクリメント
なんていう命令を持ってたりするのか?
0146名無しさん＠お腹いっぱい。
2009/10/13(火) 15:29:52RISC CISCという命名が適切だったかどうかはともかく、
境界線がなくなってなんかないな。
そういうふうに取って欲しいという x86サイドの「願望」に過ぎん。
設計古すぎ。x86 ISA。
0147名無しさん＠お腹いっぱい。
2009/10/13(火) 15:31:11かわいそうさ加減がそれを象徴してる。
0148名無しさん＠お腹いっぱい。
2009/10/13(火) 15:48:03http://www.itmedia.co.jp/enterprise/articles/0910/13/news082.html
0149名無しさん＠お腹いっぱい。
2009/10/13(火) 15:54:44その割りには、x86は広範囲で使われてますな。
0150名無しさん＠お腹いっぱい。
2009/10/13(火) 15:55:48SPARCも同様に古すぎるんですが。
x86がアレだったのは286までで、386以降は整理されて、x64で盲腸が切り捨てられ、だいぶスッキリよ。
0151名無しさん＠お腹いっぱい。
2009/10/13(火) 16:00:37いいえ、ぜんぜん。
>>150
これも、いいえ、ぜんぜん。デコード回路が小さくできませんね。
後方互換性切って足枷になる命令捨てるまでムリ。Coldfireみたいにね。
0152名無しさん＠お腹いっぱい。
2009/10/13(火) 16:04:540153名無しさん＠お腹いっぱい。
2009/10/13(火) 16:09:37すぐ馬脚が現れるだろ。
0154名無しさん＠お腹いっぱい。
2009/10/13(火) 16:31:04マチクタビレターマチクタビレター
0155名無しさん＠お腹いっぱい。
2009/10/13(火) 16:49:23たとえば、どんなベンチマークで、それが現われてる?
0156名無しさん＠お腹いっぱい。
2009/10/13(火) 17:02:21メモリバリアのこと言ってる?
x86のように並び順どおりにリタイアするならメモリバリアいらない。
その回路をケチって発行したらそれっきりで順不同に実行しちゃうのならメモリバリアが必要。
これ、キャッシュとかSMPとかとは、関係ない次元の話ですから。
0157名無しさん＠お腹いっぱい。
2009/10/13(火) 17:41:500158名無しさん＠お腹いっぱい。
2009/10/13(火) 18:34:05Sunによる体制の 2倍以上に増やす」
ゴーゴーえりそん!w
0159名無しさん＠お腹いっぱい。
2009/10/13(火) 19:35:450160名無しさん＠お腹いっぱい。
2009/10/13(火) 19:53:530161名無しさん＠お腹いっぱい。
2009/10/13(火) 20:15:11SPARC64VII+にはしないんだな
0162名無しさん＠お腹いっぱい。
2009/10/15(木) 05:04:15昔のSunのサーバを思い出すわ。
一面のメモリモジュール
0163名無しさん＠お腹いっぱい。
2009/10/15(木) 08:40:410164名無しさん＠お腹いっぱい。
2009/10/15(木) 08:59:13setx value,reg,reg_rd
0165名無しさん＠お腹いっぱい。
2009/10/15(木) 12:38:580166名無しさん＠お腹いっぱい。
2009/10/15(木) 13:17:44V9の仕様書に載ってる
0167名無しさん＠お腹いっぱい。
2009/10/15(木) 13:54:12横レスすまん
マクロで16ビット×4個に分解して合成するのは、64ビットの即値が使える、とは言えないと思うんだ。
まぁ即値の制限はRISCの弱点かもね。
コードサイズは肥大するし、命令数は嵩張るし、しかも直前の命令の出力を入力にするから、並列実行できないし。
といっても、コード中の即値の大半は小さなビット数で表現できる値なので、普通は問題にならないでしょ。
暗号とかの処理くらいかな、大きな即値がゴロゴロ出てくるのは。
0168名無しさん＠お腹いっぱい。
2009/10/15(木) 16:09:05> マクロで16ビット×4個に分解して合成するのは、64ビットの即値が使える、とは言えないと思うんだ。
それは文脈によるだろ。
> まぁ即値の制限はRISCの弱点かもね。
命令長固定しちゃえば、当然の帰結。
0169名無しさん＠お腹いっぱい。
2009/10/15(木) 18:20:10クソワロタｗｗｗ
ここまでするかおいｗｗｗ
つーかこれが必要な機関なんてあんのかよｗｗｗ
0170名無しさん＠お腹いっぱい。
2009/10/15(木) 18:23:46既出
0171名無しさん＠お腹いっぱい。
2009/10/15(木) 19:44:18おまえ、PC使っとけ。脳が許容してないから、ムリするな。ケムリ出るぞ?w
0172名無しさん＠お腹いっぱい。
2009/10/16(金) 00:27:30それが必要な機関はあるけど、そんな機関でSunを選ぶことはないと思う
■ このスレッドは過去ログ倉庫に格納されています