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

Sun Microsystems 最大のリストラ

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/06/05(月) 14:32:59
11%-13%の人員削減だが、栗鼠似の会長は栗鼠トラ対象外。

【前スレ】
Sun Microsystems 最大の重複
http://pc8.2ch.net/test/read.cgi/unix/1141840635/
0012名無しさん＠お腹いっぱい。2006/06/05(月) 19:26:00
このスレが後継でいいです
Itaniumにこじつけたタイトル、過去スレの再利用はお引取り願いたい
0013名無しさん＠お腹いっぱい。2006/06/05(月) 19:34:29
>>11
そのスレは「Linuxﾀﾝ萎え」について語るスレです。別物。
0014名無しさん＠お腹いっぱい。2006/06/07(水) 00:13:49
最大のリスが良かった
0015名無しさん＠お腹いっぱい。2006/06/07(水) 11:21:45
SunRay2 って、CPU は SPARC?
0016名無しさん＠お腹いっぱい。2006/06/07(水) 12:04:48
11%-13%の人員削減って全世界でしょう？
日本ではどうなんだろう？
0017名無しさん＠お腹いっぱい。2006/06/07(水) 12:22:36
日本は、撤退したりして。
そんなことはない。
0018名無しさん＠お腹いっぱい。2006/06/07(水) 17:19:09
>>17
それ、まだ発表しちゃだめって言われてるよね？
0019名無しさん＠お腹いっぱい。2006/06/07(水) 19:36:32
フライングしちゃったね
0020名無しさん＠お腹いっぱい。2006/06/07(水) 20:56:44
Sun travels to 'Andromeda' for blade server return
http://www.theregister.co.uk/2006/06/07/sun_andromeda_blade/

アンドロメダきたー
0021名無しさん＠お腹いっぱい。2006/06/07(水) 21:03:31
>>15
旧SunRayはたしかMicroSPARCだったと思うけど、
SunRay2 は AMD Alchemy。カタログの最後のページに書いていてある。
http://jp.sun.com/products/catalog/pdf/FY06Q4/SunRay2_2FS.pdf
0022名無しさん＠お腹いっぱい。2006/06/07(水) 21:30:52
AMDべったりだな
0023名無しさん＠お腹いっぱい。2006/06/07(水) 22:54:59
>>21
おおおおーー、MIPSー。びっくり。サーバー機の管理用に PowerPC も使ってるし。
開発外部なんかな? SPARClite じゃダメなんかよー?
0024名無しさん＠お腹いっぱい。2006/06/07(水) 23:20:04
>>20
SPARC はもういらない子になりそうな悪寒。
0025名無しさん＠お腹いっぱい。2006/06/07(水) 23:44:30
これからはSPteron
0026名無しさん＠お腹いっぱい。2006/06/07(水) 23:54:44
>>24
もうOpteronでいいよ
0027名無しさん＠お腹いっぱい。2006/06/08(木) 00:04:17
Transmeta と AMD も近づいてるだろ。Ditzel が AMD へ行く可能性もあるぞ。
0028名無しさん＠お腹いっぱい。2006/06/08(木) 00:14:56
トラメタはLR2のIPで食ってきゃいいし、Ditzelタソ移籍あるかもな
0029名無しさん＠お腹いっぱい。2006/06/08(木) 00:18:29
SunRayは昔からCPU問わない流儀でしょ。
メーカーさん、みんな参加してくれよ、Javaだからよって戦略だから。
0030名無しさん＠お腹いっぱい。2006/06/08(木) 00:56:12
アンドロメダと言えば拡散波動砲だね
0031名無しさん＠お腹いっぱい。2006/06/08(木) 01:12:08
そういえば最近龍角散の CM やってないな。
0032名無しさん＠お腹いっぱい。2006/06/08(木) 01:16:23
ところで、Java chip が失敗したのはなぜ? プロトタイプぐらいまでは行ったんだよね、
そうすると勝算があった、ってことでしょ? 何が原因だったか、誰か知らない?
0033名無しさん＠お腹いっぱい。2006/06/08(木) 06:06:23
>>32
プロトタイプまでいくとなぜ勝算があるのか？
プロトタイプぐらいまでしかいかなくて、結局実用的にみて付加価値は何もなかったって事。

「LinuxってなんでWindowsより使われないかだれか知らない？」って質問と等しい。
0034名無しさん＠お腹いっぱい。2006/06/08(木) 06:32:34
勝算がありそうだから、プロトタイプまで行ったと言いたいとみた。
JavaOSもあったね。

MAJCってどうなったの?
0035名無しさん＠お腹いっぱい。2006/06/08(木) 06:45:57
>>32
JITやHotSpotの方が効率が良かったから。

JavaOSはいまでもある。
NC向けは停滞しているけど、JavaCardの方が活発。
0036名無しさん＠お腹いっぱい。2006/06/08(木) 08:16:50
java chipは失敗したというかazulみたいなサーバアプライアンスに使われるようになったと
理解してるんですけど
もし今後活躍の場があるとすればFPGA上に実装されたコプロとしてじゃないかな
0037名無しさん＠お腹いっぱい。2006/06/08(木) 08:51:41
azul
0038名無しさん＠お腹いっぱい。2006/06/08(木) 11:20:14
んと、当然、汎用 CPU 上の JIT や HotSpot より十分高い性能が出せなかったというのは
予想がつくんだけど、その先の理由を知りたい。具体的に、どんな点が
克服できなかったのか。
MAJC についても。あれは結構汎用 CPU 寄りになっちゃってるんだよね?
0039名無しさん＠お腹いっぱい。2006/06/08(木) 11:32:07
SPARC の ABI なんか見ても、スタック言語を高速に実行するための
配慮みたいなのがあったりして、そのあたりの「考えの足りなさ」が
Java chip の敗因じゃないんじゃないかと、思ってたりするんですよ。
実際モノ作ってみるまで問題点が発覚しなかったんなら、それはどんなことなのかと。
それとも改善を続ける体力がなくなっただけなの?
0040名無しさん＠お腹いっぱい。2006/06/08(木) 11:51:44
儲からないと判断したから。
0041名無しさん＠お腹いっぱい。2006/06/08(木) 13:19:18
>>38
x86を見ても、
数が出て投資されるchipが速いってことが分かるのでは?
0042名無しさん＠お腹いっぱい。2006/06/08(木) 13:54:06
逆に言うと、そんな理由でしかないんなら、状況が変わってくればモロ復権があり得るね。
0043名無しさん＠お腹いっぱい。2006/06/08(木) 14:00:31
CPUの性能向上は投入リソースに比例するんだから、復権なんてありえないだろ。
0044名無しさん＠お腹いっぱい。2006/06/08(木) 14:07:11
Java 言語周辺へのリソース投入状況の変化なんていくらでも考えられると思うが。
むしろ x86 にずっとリソースが投入され続けると考える方が変。
x86 じゃなくて Intel にリソースが投入され続けると考えた Intel は Itanium で
痛い目にあってるしw。
0045名無しさん＠お腹いっぱい。2006/06/08(木) 14:33:07
検索システムに力を入れるのかな。
0046名無しさん＠お腹いっぱい。2006/06/08(木) 15:48:25
汚い CISC のエミュレーションのために膨大なコストがかかり、それが商品に
転嫁されているということをもっと考慮すべきだよね。よいものが評価されない、
優れたものが残れないというのは市場経済が正常に機能していないということでしょ。
バイナリ互換性至上などという迷信による囲い込み商売は規制すべきだね。
0047名無しさん＠お腹いっぱい。2006/06/08(木) 15:53:17
CISCエミュレーションって何の話？
0048名無しさん＠お腹いっぱい。2006/06/08(木) 19:26:10
newsで検索システムと音楽検索システムとかあったけど、
ipodみたく、音楽配信に参入するのかな
0049名無しさん＠お腹いっぱい。2006/06/09(金) 14:37:38
>>46
そんな膨大なコストをかけて、それが価格に転嫁されようとも、
スケールメリットによって他よりもコストパフォーマンスに優れているものが生き残るのは、
まさに市場経済が正常に機能しているということだと思いますが。
0050名無しさん＠お腹いっぱい。2006/06/09(金) 17:23:27
何言ってるの? そのコスト分性能向上に回せるのよ? 現状がコストパフォーマンスに
優れてるわけがないから問題なんじゃない。
競争のない状態で市場経済なんて機能するわけがないでしょ。中学校で習わなかった?
0051名無しさん＠お腹いっぱい。2006/06/09(金) 17:29:05
ソフトウェアの流通量から考えてもx86系は有利だと思いますけどね
マシンのスループットと価格でコストパフォーマンスを考えてもしょうがないのでは
0052名無しさん＠お腹いっぱい。2006/06/09(金) 18:36:43
「ソフトウェアの流通量」という阻害要因によって競争が妨げられている。
しかもそれが参入障壁として機能するように恣意的に維持されている。
寡占は産業の衰退を招く。品質の悪いゴミばかりが残る。
0053名無しさん＠お腹いっぱい。2006/06/09(金) 19:07:04
InteropのSunのブースのおねーちゃんは、
割とかわいい感じのひとが多かった。
CISCOの方が上だったが。
0054名無しさん＠お腹いっぱい。2006/06/09(金) 19:14:25
>>50
> そのコスト分性能向上に回せる

それは微々たるものでしょう。
SPARCでもバイナリ互換のために色々やっていて、膨大なトランジスタ数を注ぎ込んでいますよ。

性能向上のためにはスケールメリットによって莫大な開発費を投入する必要があり、
スケールメリットを得るためには、x86という古い命令セットとの互換性を保つ必要がある。

スケールメリットによって投入できるようになる開発費が、
互換性のために必要なコストを、上まわっていれば問題ない。

DELLはx86なローエンドサーバを3万円で売ってるけど、
SunはSPARC系のローエンドサーバを3万円で売ってる?
ローエンドではSPARCのコストパフォーマンスは、x86には到底かなわないよ。
0055名無しさん＠お腹いっぱい。2006/06/09(金) 19:25:06
>>54
> それは微々たるものでしょう。
Wintel 関係者ですか?
> DELLはx86なローエンドサーバを3万円で売ってるけど、
> SunはSPARC系のローエンドサーバを3万円で売ってる?
まっとうな競争がされていればコストパフォーマンスは今よりずっと上だという
主旨なんだけど... そんなに難しいかな?
> ローエンドではSPARCのコストパフォーマンスは、x86には到底かなわないよ。
はるかに改善されるでしょう、と言っています。今の x86 はリソースを
ほぼ独占しているのにたいした性能じゃない。
0056名無しさん＠お腹いっぱい。2006/06/09(金) 20:50:13
>はるかに改善されるでしょう、と言っています。
仮定のお話だわな
もしかして漏れ釣られ（ｒｙ
0057名無しさん＠お腹いっぱい。2006/06/09(金) 21:01:51
何を期待してるのかがわからん。
高性能独自アーキテクチャが乱立しているような状況を望んでるのか？
0058名無しさん＠お腹いっぱい。2006/06/09(金) 21:06:35
まあ、SPARCは3万円サーバどころか、
40万円以上のクラスしか残ってないわけですが。
0059名無しさん＠お腹いっぱい。2006/06/09(金) 21:49:57
>>55
RISC vs CISCの論争は、
それぞれ性能向上に向かって突き進んでいったら同じところに到達してしまい、
大した違いがなくなってしまったので、終わりましたよ。
マルチコア・マルチスレッド時代になって再燃するかな? という感じはあるけどね。

あなたのいう、まっとうな競争というのをやった場合、スケールメリットを享受することができません。
プロセッサ開発には莫大な費用がかかる以上、
スケールメリットなしではCPUの価格を下げることも、高性能なCPUを作ることもできません。
0060名無しさん＠お腹いっぱい。2006/06/09(金) 22:06:17
まぁ CISC の方がバイナリを小さくできてメモりや HDD を節約できるってメリットはあるけどね。
0061名無しさん＠お腹いっぱい。2006/06/09(金) 22:10:11
>>59
> それぞれ性能向上に向かって突き進んでいったら同じところに到達してしまい、
性能の落ちない CISC はあり得ると思うけど、x86 は違うよ。特にレジスタ数。
> あなたのいう、まっとうな競争というのをやった場合、スケールメリットを享受することができません。
それはない。Intel が AMD より性能出せないのはどう説明する?
スケールメリットが本当に聞いているのなら Intel はぶっちぎりで速くてしかも
今の数分の 1 の価格のはず。
0062名無しさん＠お腹いっぱい。2006/06/09(金) 22:19:15
みんなありがたがり過ぎ乗せられ過ぎ。
0063名無しさん＠お腹いっぱい。2006/06/09(金) 23:26:03
UltraSPARCわぁ〜めぇちゃメチャ高いからぁ〜♪
みんな絶対買うなよ〜ぉ♪
雪国もや　しｗ
0064名無しさん＠お腹いっぱい。2006/06/09(金) 23:39:17
で、具体的にどうすればいいんだ
インテルとAMDにテロでもするのか？
あほらし、一生ほえてろ
0065名無しさん＠お腹いっぱい。2006/06/09(金) 23:44:15
Transmetaの中の人頑張って！
0066名無しさん＠お腹いっぱい。2006/06/09(金) 23:44:24
スルーすればいいと思うよ
0067名無しさん＠お腹いっぱい。2006/06/09(金) 23:44:43
>>61
> 性能の落ちない CISC はあり得ると思うけど、x86 は違うよ。特にレジスタ数。
AMD64でレジスタ本数が倍になったけど、
レジスタ本数が倍になっただけでは劇的に速くなってはいない。
x86互換というスケールメリットを捨ててまでして、レジスタ数を増やして性能を向上させるのは割りに合わない。
だからこそ、32ビットの時にはレジスタを増やしたりはせず、64ビットのモードを追加するタイミングで同時にレジスタを増やしたわけで。

> それはない。Intel が AMD より性能出せないのはどう説明する?
スケールメリットは必要条件ではあるものの十分条件ではないから。

現にAMDがインテルを上まわる性能のCPUを安価に提供しているのは、
x86互換とすることで得られるスケールメリットによって可能になったわけで。

年間100万個製造するのと、5000万個製造するのとでは、
CPU 1個に乗せるべきCPUの開発費が50倍も違うのですよ。
0068名無しさん＠お腹いっぱい。2006/06/09(金) 23:46:12
>>65
Transmetaは緩やかにAMDの傘下に入りましたが、なにか?

新しいEfficeonは、
Transmetaが設計し、富士通が製造し、AMDが販売するのですよ。
0069名無しさん＠お腹いっぱい。2006/06/09(金) 23:49:45
>>63
高いよ☆

SgiがWoodcrestを採用するんだけど、これだって安いからじゃないし〜
最終製品だって（ｒｙ
0070名無しさん＠お腹いっぱい。2006/06/10(土) 04:09:34
VLIW(笑)
0071名無しさん＠お腹いっぱい。2006/06/10(土) 09:49:45
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060608/240425/
Itanium2にRedHatですか。。

SPARC64V使えよ。
0072名無しさん＠お腹いっぱい。2006/06/10(土) 10:04:28
Opteron使えよ。
0073名無しさん＠お腹いっぱい。2006/06/10(土) 12:22:06
>>71
「安価な」ってあるから廉価版のスパコンでしょ？
ハイエンドはAPLでSPARCかと
0074名無しさん＠お腹いっぱい。2006/06/10(土) 13:50:49
あ、ホントだ。
0075名無しさん＠お腹いっぱい。2006/06/10(土) 17:22:37
>>27,28
Mr. Ditzel って若いな。RISC 黎明期からの人だよね。何歳?
ttp://pc.watch.impress.co.jp/docs/2006/0609/gyokai164_01.jpg
0076名無しさん＠お腹いっぱい。2006/06/10(土) 17:42:30
英語キーボードのムラマサ欲しいかも。できれば MacOS X でw。
0077名無しさん＠お腹いっぱい。2006/06/10(土) 17:44:25
CrusoeのSunRayってのは出ないんだな。
相性良さそうなのにな。HotspotとCode Morphingは。
0078名無しさん＠お腹いっぱい。2006/06/10(土) 18:46:58
Crusoe だと Java が速い、なんて聞いたことないぞ。
技術的に似てそうな雰囲気はあるがw。
0079名無しさん＠お腹いっぱい。2006/06/10(土) 19:06:46
>>75
Efficeon 2 億個売れて富士通ボロもうけ財務改善→SPARC 開発絶好調→リス CEO 復帰
ttp://pc.watch.impress.co.jp/docs/2006/0609/gyokai164.htm
0080名無しさん＠お腹いっぱい。2006/06/10(土) 21:06:27
× リス CEO 復帰
○ 富士Sun 誕生
0081名無しさん＠お腹いっぱい。2006/06/10(土) 21:54:25
SunRayはアプリをサーバ側で実行するのになんでクライアントに(ry
0082名無しさん＠お腹いっぱい。2006/06/10(土) 22:14:10
>>79
すごいシナリオ。。
0083名無しさん＠お腹いっぱい。2006/06/10(土) 23:27:44
>>81
まあ Java がえらい高速で動けばまた端末側で Java のアプリ動かすこともあるかもだけど。
今の SunRay はまったくやめちゃってるのかな?
SunView っぽいアイコンがよかったけどなw
0084名無しさん＠お腹いっぱい。2006/06/11(日) 01:36:41
漏れはOpenVGを使って画像処理に手を入れた方がいいんじゃないかと思うんだけど
0085名無しさん＠お腹いっぱい。2006/06/11(日) 02:40:00
端末側でJavaアプリが動くSunRayなんてあったの？
0086名無しさん＠お腹いっぱい。2006/06/11(日) 09:04:21
WMやアプリのランチャーはJavaで書いてあったでしょう。
0087名無しさん＠お腹いっぱい。2006/06/11(日) 11:34:54
>>78
そういや、最初に日本に売り込みに来た時に、
いきなりVLIWに落すJREがあるって言っていたな。
けど顧客が見向かなかったらしい。
速いって言っていたけど、資料もないし、セールストークだからどうかなw

>>79
Microsoftに取り込まれちゃったか、Transmetaは。
0088名無しさん＠お腹いっぱい。2006/06/11(日) 22:05:50
>>85
JavaStation だな。
0089名無しさん＠お腹いっぱい。2006/06/12(月) 00:37:04
>>88なつかしい
0090名無しさん＠お腹いっぱい。2006/06/12(月) 01:26:01
人員削減対策ってもう何年やってんだよ。
0091名無しさん＠お腹いっぱい。2006/06/12(月) 09:56:21
でもさ、CPUの性能、消費電力っていうのは、CPUの製造能力に依存している、
って忘れていない？

Intelが強気なのは、ピカ一の製造能力を保持しているからだよ。
同じように、PowerやSPARC64が優秀なのは、IBMや富士通が優れた製造能力を持っている
ことだよ。

要は、設計や開発能力だけでなく、製造能力も必要。これらが維持できる
コンピュータ会社というのは、限られている。

MIPSやARM、SHでサーバを作る香具師はいないでしょ？ でも、組み込みでは、
これらのCPUは良く使われる。組み込みでMIPSやARM、SHが使われるのは、
程良くバランス（性能、消費電力、コスト）しているから。
裏を返して言うと、良い設計がされている。

絶対性能がでていない、または高周波数でないからといって、設計が悪いわけでも
ない。
0092名無しさん＠お腹いっぱい。2006/06/12(月) 10:01:20
まるで組み込み向けCPUには製造能力が要らないような言い方だな。
0093名無しさん＠お腹いっぱい。2006/06/12(月) 10:06:53
>>92

ではなくて、組み込み向けCPUには、Core2のような製造は適用されないと
言っているだけ。

そもそも、そういう製造技術を持っているのは、限られる。
0094名無しさん＠お腹いっぱい。2006/06/12(月) 10:09:17
・目的によってCPUは選ばれる。
・選択には種々の要因がある。
これだけで済む話では。
0095名無しさん＠お腹いっぱい。2006/06/12(月) 10:12:33
>>94

そうそう。そういうことなんだけど。

でも、巷では、高周波数＝素晴らしい設計、てな具合に丸のみなので、ちょっと。

洩れ的には、MIPSアーキが最高で、ISA的には、ARMが良いと思っててね。

0096名無しさん＠お腹いっぱい。2006/06/12(月) 10:27:15
ｇｄｇｄでウザイ奴がでてきたな
0097名無しさん＠お腹いっぱい。2006/06/12(月) 11:53:18
洩れ的最高とかどうでもいい。
0098名無しさん＠お腹いっぱい。2006/06/12(月) 13:02:32
NTT は物理的な架線網と接続サービスの両方を持っている。接続サービスには
競合がいるが、架線網は独占状態。接続サービス業界の競争を維持するため、
ダークファイバーや加入者線の使用を解放する義務がある。
プロセッサも、ある程度の数のアーキに対して同等に製造技術を利用できるようにしないと
競争が阻害される。逆に言えば、Intel が SPARC や MIPS を製造しても
x86 が優秀なら x86 の優位性は揺らがないが、そうでないなら不要なコストが
プロセッサを買う側に転嫁されているということになる。
つーか、こんな簡単なこと説明されないとわからないバカばっかりだというのが
すごく不思議。
0099名無しさん＠お腹いっぱい。2006/06/12(月) 13:39:52
>>98
名無しじゃないとこんな馬鹿なこと書けないなw
いや、名無しでもこんなことageてまで書けないww
0100名無しさん＠お腹いっぱい。2006/06/12(月) 13:59:30
Intelの話はこっちでやってね

Sun Microsystems 最大の敵はItanium
http://pc8.2ch.net/test/read.cgi/unix/1140886161/l50

って前のスレに書いてあった。
0101名無しさん＠お腹いっぱい。2006/06/12(月) 14:53:08
>>99
馬鹿だ、というだけの反論ならお前に言うことはひとつだけだ。「お前が馬鹿」。
0102名無しさん＠お腹いっぱい。2006/06/12(月) 16:00:38
>>100
それは Itanium 用だ。Itanium はもう終わった。今後は HP-Ita と呼べ。いや、HPium かw
0103名無しさん＠お腹いっぱい。2006/06/12(月) 16:02:43
いや、HiPanium ヒパニゥム、にしよう。
0104名無しさん＠お腹いっぱい。2006/06/12(月) 16:13:47
Alphaが最高である。
0105名無しさん＠お腹いっぱい。2006/06/12(月) 18:17:50
首斬り首斬り
0106名無しさん＠お腹いっぱい。2006/06/12(月) 18:47:47
首切りカウントダウン。。。。あと３週間。。。。
0107名無しさん＠お腹いっぱい。2006/06/12(月) 19:33:32
インテルがx86だけでなく、SPARCやMIPSを開発し
x86に費やしている製造能力をSPARCやMIPSにも平等に振り分けると
CPU一個あたりの開発費は三倍になる
なぜ、こんな簡単なことが分からないのかｗ
0108名無しさん＠お腹いっぱい。2006/06/12(月) 19:45:42
0 点。落第。「製造設備の共用」という観点から再考せよ。
0109名無しさん＠お腹いっぱい。2006/06/12(月) 19:47:25
はいはい、やっぱり脳みそとけてるのね
言うだけ無駄だわ
0110名無しさん＠お腹いっぱい。2006/06/12(月) 21:04:23
>>107
イソテルのItaniumのことは無視ですか？
0111名無しさん＠お腹いっぱい。2006/06/12(月) 21:07:37
>>108
0点。落第。「CPUはどれも fetch して issue して、たまに OoO して分岐予測して
実行してストアしてキャッシュしてメモリに書くだけ」という観点から再考せよ
■ このスレッドは過去ログ倉庫に格納されています