トップページ⇒unix
988コメント275KB

Sun Microsystems 最大の岩望

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2009/07/10(金) 19:13:24

Rockは出るのか!?

【前スレ】
Sun Microsystems 最期の落日
http://pc12.2ch.net/test/read.cgi/unix/1244286002/
0627名無しさん＠お腹いっぱい。2009/09/08(火) 20:03:55
Sunブランドで数出た結果、Fブランドの台数も伸びるのよ。そういうもん。
0628名無しさん＠お腹いっぱい。2009/09/08(火) 21:39:00
68000
不正コードを実行すると割り込みが発生するが、戻りアドレスを忘れるナイスなCPU。
なのでSUN1は68000を2つ使用していた (豆知識)
0629名無しさん＠お腹いっぱい。2009/09/08(火) 23:56:03
>>626
それは当たり前じゃないの？
今のSun/Fujitsuみたいな相互OEMな関係じゃなくても
0630名無しさん＠お腹いっぱい。2009/09/09(水) 01:23:38
>>629
富士通のシェアが低いって話だからさ。
0631名無しさん＠お腹いっぱい。2009/09/09(水) 09:02:37
>>628
ファミリーの特徴ならともかく、そんなアラあげたところでなんの役にもたたんがな。
そういうのは豆知識などとは言わないと思うな。
06326282009/09/09(水) 19:50:32
>>631
うろ覚えなので適当に書いておけば誰か訂正してくれると思ったが
そういうつっこみしか無いのは残念でした
0633名無しさん＠お腹いっぱい。2009/09/09(水) 20:56:34
ttp://ja.wikipedia.org/wiki/MC68000
に書いてあるようなことだから、スレで訂正とかいらないって。
興味を持った人間は、すぐに気がつくだろうから。
0634名無しさん＠お腹いっぱい。2009/09/09(水) 21:10:31
>>632
うろ覚えとかそういうことじゃなくて、『主旨』がダメ。
0635名無しさん＠お腹いっぱい。2009/09/09(水) 21:15:41
>>628
そう言えば、
「2つのCPUの片方を常に1クロック遅らせて実行していた」
という嘘情報がかなり広範囲に広まってたよね。

(正しくは、メインの1CPUが普通に稼働していて、
不正コードなどの例外が発生した時のみ2つ目のCPUが代理で処理をするというだけ)
0636名無しさん＠お腹いっぱい。2009/09/09(水) 21:16:46
Sun3以降しか使ったことないや

Sun3は普通〜のワークステーションだった。
その普通ってのが、どれだけ大変で価値のあるものだったのか、ってことだ。
0637名無しさん＠お腹いっぱい。2009/09/09(水) 21:20:35
68000で仮想記憶やるのは、
i860のパイプラインモード中の割り込みからの復帰処理なんかに比べれば、
えらく簡単だな。
0638名無しさん＠お腹いっぱい。2009/09/09(水) 22:02:20
2ちゃんで主旨とはおそれいった
0639名無しさん＠お腹いっぱい。2009/09/09(水) 23:41:02
おそれイリアのジューシーフルーツ
0640名無しさん＠お腹いっぱい。2009/09/10(木) 00:23:54
Sun1が68000を2個しか積まなかった理由は何だろう。

68000は非力だし、バスよりもMPUクロックがボトルネックだったのだから、
思い切って3個つんで、2プロセッサのSMPにすれば良かったのに。
0641名無しさん＠お腹いっぱい。2009/09/10(木) 07:01:12
当時のOSはSMPに対応してません。
0642名無しさん＠お腹いっぱい。2009/09/10(木) 11:44:44
>>638
クソ文書くなや。←こっちの方がいいか?
0643名無しさん＠お腹いっぱい。2009/09/10(木) 13:32:28
>>635
2個のCPUを使って常に1命令遅らせて実行、という都市伝説の起源ってどこなのかな。
複数の本や雑誌でそういう記述を見かけたことがあるけど。
0644名無しさん＠お腹いっぱい。2009/09/10(木) 13:35:56
オレオレ
0645名無しさん＠お腹いっぱい。2009/09/10(木) 13:50:35
初出かどうかはわからんが、1995年3月初版の256倍悪魔本25ページに
「SUN1では、2つのCPUが同時に少し前後にずれたところを走っていて、」
とあるな。
0646名無しさん＠お腹いっぱい。2009/09/10(木) 14:59:12
フォルトトレラントとか宇宙用とかといっしょくたにしてるな。
0647名無しさん＠お腹いっぱい。2009/09/10(木) 15:43:40
256倍悪魔本捨てちゃった…orz
また読みたいなー
0648名無しさん＠お腹いっぱい。2009/09/10(木) 16:07:43
>>635
アポロの Domain のが先だったのね。

1981年 DN100
1982年 SUN-1
0649名無しさん＠お腹いっぱい。2009/09/10(木) 17:26:53
もちろん。
0650名無しさん＠お腹いっぱい。2009/09/10(木) 20:04:00
しかもApolloは、ページフォルト処理だけでなくグラフィックス処理も、2個目の68000にやらせてた。
仮想メモリが必要ない、物理アドレスで動作するデバイスドライバ関係は、ページフォルトしないもんな。
0651名無しさん＠お腹いっぱい。2009/09/10(木) 22:57:50
Sun Costomers
http://www.oracle.com/features/suncustomers.html
0652名無しさん＠お腹いっぱい。2009/09/10(木) 23:03:58
>>651
エリソン正気か?
0653名無しさん＠お腹いっぱい。2009/09/10(木) 23:09:42
なんか体が熱くなってきた
0654名無しさん＠お腹いっぱい。2009/09/10(木) 23:11:08
We're in it to win it.
0655名無しさん＠お腹いっぱい。2009/09/10(木) 23:22:21
上で、Sun-1が2つの68K使って交互に動いてるってあったけど、
どうやってアドレスとかレジスタとかの情報交換してるんだろう？

と思ってググってみたけど、このスレとスラッシュドットの
ヨタ話ぐらいしか見つからない。
2つ使ってるって本当？

ちょっと詳しそうな文章が見つかったけど、68Kを2つ使ってるとは書かれてない。
http://www.bitsavers.org/pdf/sun/sun1/SUN_68000_Board_1982.pdf

例外から必ずしも戻れないので頑張ってる的なことは書いてある
0656名無しさん＠お腹いっぱい。2009/09/10(木) 23:59:07
>>655
どうもSun-1は68000は1つのようだね。

Sun-1は数百台未満しか出荷されていないし、後に68010にアップグレードされたそうだから、
コンパイラがメモリアクセスの命令を、例外から戻れるタイプのものだけに制限して回避してたのかもね。

その文書でも、後に出るであろう68010とコンパチだから置き換えできるぞっていうようなこと書いてあるし。




> どうやってアドレスとかレジスタとかの情報交換してるんだろう？

メインのMPUにとっては透過的に処理されるので、情報交換必要ない。
サブのMPUはMMUから、メインMPUがアクセスしようとした論理アドレスを受け取る。
0657名無しさん＠お腹いっぱい。2009/09/11(金) 06:50:35
サブのCPUはMMUにアクセスしてフォールトしたページにメモリを割当することさえ
できれば良いので、68000以外のCPUでもいいんだよね。
メインとサブが違うCPUなら、2つのCPUが命令をずらして同時に実行していたという説は
完全に否定される。
0658名無しさん＠お腹いっぱい。2009/09/11(金) 07:09:26
オラクルの交戦的な所は流石だな。これでソフトウェア世界二位の会社だもんな。

でもラリーも遠くない将来ジョブズみたいによぼよぼになっちゃうと思うと、さびしいな。

IT業界は普通の業界になっちゃうんだろうな。
0659名無しさん＠お腹いっぱい。2009/09/11(金) 08:00:44
>>655-657
Sun1のボードを見たことがあるけれど、68Kは1個しか見あたらなかったよ。
ボード2つ積んでいるのでないなら、別のプロセッサが例外処理してるのかもね。
0660名無しさん＠お腹いっぱい。2009/09/11(金) 09:17:44
>>652
だから、最初っからそう言ってるじゃねーか。
「征服」のために、ハードと OSを入手したんだよ。やつは完全に「その気」。
0661名無しさん＠お腹いっぱい。2009/09/11(金) 13:13:30
>>651
Customers だろ？　何かと思ったｗ
http://www.oracle.com/features/images/sun_customers_lg.gif
0662名無しさん＠お腹いっぱい。2009/09/11(金) 16:18:33
誰か Andy が生きてるうちに Sun-1 の真相を聞いといてくれｗ
0663名無しさん＠お腹いっぱい。2009/09/11(金) 17:40:27
ああ、Andyだが。68000? 使ってないよ。Sun-1はディスクリート。
0664名無しさん＠お腹いっぱい。2009/09/11(金) 17:41:48
コーラ缶とマリリンモンローは傑作だったろ?w
0665名無しさん＠お腹いっぱい。2009/09/11(金) 17:44:52
スティングはボーカル集中しちゃうとベースがお留守でさ。
0666名無しさん＠お腹いっぱい。2009/09/11(金) 18:01:35
>>659
他社と違ってSunは、68000でちゃんと仮想記憶をやろうとはせず
68010が出たら差し替えることを前提に、暫定で68000を積んでいた。

ただでさえレアなSun1のユーザで、68010に差し替えなかったユーザは、極めて希だと思う。
0667名無しさん＠お腹いっぱい。2009/09/11(金) 18:05:38
ググれば即座に出てくるソース

ttp://jp.sun.com/communities/0512/feature01.html
Sun1は当初BSD UNIXが動作していなかった
68010登場で、交換されてSun1.5となった。
0668名無しさん＠お腹いっぱい。2009/09/11(金) 18:21:01
じゃ、例外処理の問題で68000を2台積んだって、別のマシンの
話なのかねぇ？
0669名無しさん＠お腹いっぱい。2009/09/11(金) 19:02:53
だから Sun-1 神話はどこからでてきたんだろうって話ｗ
0670名無しさん＠お腹いっぱい。2009/09/11(金) 19:11:21
英語と日本語で若干記述が違うな＞ Wiki

The Sun-1 systems ran SunOS 0.9, a port of UniSoft's UniPlus V7
port of Seventh Edition UNIX to the Motorola 68000 microprocessor,
with no window system.

Sun-1のシステムでは、Seventh Edition Unix の移植である UniSoft の UniPlus V7 が動作した。
これは、時には Sun UNIX 0.7 とも呼ばれている。
0671名無しさん＠お腹いっぱい。2009/09/11(金) 19:17:31
>>668
68000を 2コって機械は、複数あったって読んだ覚えがある。
>>669
Sun-1は違うようだね。
0672名無しさん＠お腹いっぱい。2009/09/11(金) 19:40:19
オレ的には Sun-1でどうだったかはあまり問題じゃなくて、
M68k x 2コのCPUを、命令クロックをずらして同時に走らせた、という伝説の出どころが
知りたい。
0673名無しさん＠お腹いっぱい。2009/09/11(金) 19:46:25
>>672
2つに実行させると、サブの方の CPUにデータぶっこわされないように
ある程度のメモリも余分に必要になるから、メモリが安くなかった当時では
ちょっとありえない構成だと思うけど。

>646 が妥当かと。
0674名無しさん＠お腹いっぱい。2009/09/11(金) 20:07:06
>>661
すまん、打ち間違えた　orz
0675名無しさん＠お腹いっぱい。2009/09/11(金) 20:19:04
ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html
ここにあるように、どんな応用にしたって「命令クロックをずらして同時に走らせる」
ってのは想像できない。
フォールトトレーラントや宇宙用だと、同時に走らせるのはあるかもしれないが。
0676名無しさん＠お腹いっぱい。2009/09/11(金) 23:01:11
I/Oもメモリアクセスも同期も取らないフォールトトレラントや宇宙用ってどんなの？
0677名無しさん＠お腹いっぱい。2009/09/12(土) 00:57:59
もしかしたら
2個の6809を位相をズラしたクロックで駆動させて、互いにサイクルスチールさせる
っていう話と混同してるのかもな。
0678名無しさん＠お腹いっぱい。2009/09/12(土) 07:05:39
>>457のネタだが、
ttp://www.geocities.jp/andosprocinfo/wadai09/20090905.htm
によると、>>462や>>463の通り、T5440のクラスタらしい。
0679名無しさん＠お腹いっぱい。2009/09/12(土) 11:15:48
ロードマップきたよー

Sun's Sparc server roadmap revealed
http://www.theregister.co.uk/2009/09/11/sun_sparc_roadmap_revealed/
http://regmedia.co.uk/2009/09/11/sun_sparc_roadmap.jpg
0680名無しさん＠お腹いっぱい。2009/09/12(土) 11:31:55
>>677 それって何てマシン？
0681名無しさん＠お腹いっぱい。2009/09/12(土) 13:19:46
Rockはどれ？
0682名無しさん＠お腹いっぱい。2009/09/12(土) 13:27:54
ありません
0683名無しさん＠お腹いっぱい。2009/09/12(土) 13:36:54
本当にRockないんだ
なんなんだ
0684名無しさん＠お腹いっぱい。2009/09/12(土) 13:47:06
Rock is dead!
0685名無しさん＠お腹いっぱい。2009/09/12(土) 14:07:06
えらく現実的な選択だな。
つまらん。
0686名無しさん＠お腹いっぱい。2009/09/12(土) 14:39:57
New VT Coreの3つは十分野心的なスペックだと思うがなあ

特に後ろの2つ、4コアで192ソケット対応のチップと
16コアで8ソケット対応のチップを同じような時期に
リリースするだなんて、ちょっと信じられない
0687名無しさん＠お腹いっぱい。2009/09/12(土) 14:48:51
あ、Cascade FallsはYellowstone Fallsを4つMCMに載せたやつだったりして
0688名無しさん＠お腹いっぱい。2009/09/12(土) 15:11:59
コア数の増加を抑えて高クロック化を狙っている辺りにSPARC64イラネって気持ちを感じる
0689名無しさん＠お腹いっぱい。2009/09/12(土) 15:20:15
DEC Alphaだってロードマップはあった。
0690名無しさん＠お腹いっぱい。2009/09/12(土) 15:28:00
>>687
それだと消費電力も4倍になるぞ
0691名無しさん＠お腹いっぱい。2009/09/12(土) 15:40:32
>>689
Itaniumだってロードマップはある。
0692名無しさん＠お腹いっぱい。2009/09/12(土) 18:49:16
>>688
このロードマップなら、SPARC64もういらねえだろ
0693名無しさん＠お腹いっぱい。2009/09/12(土) 19:14:14
SPARC64イラネ
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20070509/270354/
0694名無しさん＠お腹いっぱい。2009/09/12(土) 19:14:15
>>1
出ません
0695名無しさん＠お腹いっぱい。2009/09/12(土) 19:23:39
>>693
> 富士通はサンのCPU開発力を甘く見ていた節があり、
> 16コアで、1コア当たり16あるいは32スレッドとされる
> Rockの開発がうまくいかないだろうと踏んでいた。

結局これは当たってたわけか
0696名無しさん＠お腹いっぱい。2009/09/12(土) 19:30:16
> Jupiter後の富士通は、APL提携時の約束に従い
> Rockを売ることになるはずである。

おかげでAPL2は出そうにも2012年まで出せませんと
SunのSPARC部隊は見事に生き残りに成功したわけだ
0697名無しさん＠お腹いっぱい。2009/09/12(土) 19:57:42
どっちみちNehalem EXが出ればSPARCいらなくなるんだし
富士通ももうやる気ないんじゃないの？
0698名無しさん＠お腹いっぱい。2009/09/12(土) 20:10:31
エンタープライズ用途で1割程度のクロック向上って、やる価値あるの?
0699名無しさん＠お腹いっぱい。2009/09/12(土) 20:22:04
少しはあるから、やるんじゃないの？
0700名無しさん＠お腹いっぱい。2009/09/12(土) 20:24:28
漸進は一度きりじゃないですから
0701名無しさん＠お腹いっぱい。2009/09/12(土) 21:54:54
2年もかけて、やることなの?
0702名無しさん＠お腹いっぱい。2009/09/12(土) 22:05:40
2年？
0703名無しさん＠お腹いっぱい。2009/09/12(土) 23:12:08
また自分の世界に入ってる様です
0704名無しさん＠お腹いっぱい。2009/09/13(日) 00:00:18
また？
0705名無しさん＠お腹いっぱい。2009/09/13(日) 00:41:44
早く買ったお客さんにはさっさとそれ使って儲けてもらう
遅く来たお客さんには少し速いのを渡してやる
Sunはどっちのお客さんも喜ばせることができる
0706名無しさん＠お腹いっぱい。2009/09/13(日) 02:11:04
つか、Jupiter-EってRock潰れたときのBプランぽくね？
US-Vに続きRockでもケツ持ってもらって、自分たちは
新コアで新しいチップ作りますんでAPL2はいりません
だったとしたら、ちょっとひどくね？
0707名無しさん＠お腹いっぱい。2009/09/13(日) 02:36:24
Sunなんかと組んだのが運の尽き！
0708名無しさん＠お腹いっぱい。2009/09/13(日) 03:03:02
Sun側がAPL2イラネと言ってるのか、
それとも
富士通側がAPL2なんて作るもんか
と言ってるのか。

2度も同じ手口で痛めつけられるほど富士通はバカじゃないよ。
0709名無しさん＠お腹いっぱい。2009/09/13(日) 03:09:39
Jupiterを2.5GHz→3.0GHzでバックアッププランになりますか、と。
バックアッププランならVenusのfxの付かないモデルだろう。
0710名無しさん＠お腹いっぱい。2009/09/13(日) 09:49:50
Yellowstone Falls があれば APL2 イラネ
ってのが妄想でしかないわけでして
0711名無しさん＠お腹いっぱい。2009/09/13(日) 10:20:07
4コア×8スレッド192ソケット対応で3GHzならAPL2いらないんじゃね？
0712名無しさん＠お腹いっぱい。2009/09/13(日) 10:32:26
>>708-709
なるほど、もう富士通側が冷めちゃってるのか
0713名無しさん＠お腹いっぱい。2009/09/13(日) 17:03:28
ってことは富士通にそっぽ向かれて慌ててベーパーウェアを用意した可能性もあるわけだな
0714名無しさん＠お腹いっぱい。2009/09/13(日) 18:37:29
APLだってイラネとか言ってたが、APLべったり依存ですよ?
0715名無しさん＠お腹いっぱい。2009/09/13(日) 21:42:29
3GHz 4-192ソケット 4コア8スレッド Yellowstone Falls は、メモリ大盛り向け
3GHz 1-8ソケット 16コア8スレッド Cascade Fallsは、CPU大盛り向け
ってことかな

Yellowstone Fallsが最低4ソケットから、というあたりからして、
どちらも同一のコアで、
Yellowstoneを4チップMCMしたのがCascade Fallsかな

もはやボトルネックはパッケージのピンカウントって感じだな。
0716名無しさん＠お腹いっぱい。2009/09/13(日) 21:48:56
ボトルネックは製造
0717名無しさん＠お腹いっぱい。2009/09/13(日) 22:43:55
ボトルネックは「机上の空論」
0718名無しさん＠お腹いっぱい。2009/09/13(日) 22:48:30
>>715
> Yellowstoneを4チップMCMしたのがCascade Fallsかな

それだと消費電力も4倍になるぞ
0719名無しさん＠お腹いっぱい。2009/09/13(日) 22:53:50
元が低ければ4倍になっても許容範囲内だと思う
0720名無しさん＠お腹いっぱい。2009/09/13(日) 23:11:13
元が低いって、Yellowstoneがたとえば50W未満で出せるってことか？
28nmで4コアとは言え、3GHzだぞ？ちょっと信じられないなあ
0721名無しさん＠お腹いっぱい。2009/09/13(日) 23:57:28
Yosemite以降は絵に描いた餅
0722名無しさん＠お腹いっぱい。2009/09/14(月) 00:35:48
怪文書レベル
0723名無しさん＠お腹いっぱい。2009/09/14(月) 00:59:53
>>720
コア半分→電力半分
クロック倍→電力倍
微細化2段階→電力半分

さらに、電力食いなのはメモリコントローラやSMPバスなどの、外部との通信。
4チップMCMした場合に、チップ上のメモリコントローラを全部使ったらピンカウントが足りなくなるので、そこで削減される。
SMPバスも、プリント基板上を隣のソケットまで走るのに比べれば、MCM基板上の配線のほうが短くて軽いので、そこで削減されよう。

というわけで、200Wくらいで収まると思う。
0724名無しさん＠お腹いっぱい。2009/09/14(月) 01:35:14
> コア半分→電力半分

コアあたりのトランジスタ数を増やさずにクロックを倍にできるかな？

> クロック倍→電力倍

高クロックを実現するために低Vthのトランジスタを使ったりするだろうから
倍で済むとは思えない

> 微細化2段階→電力半分

微細化するとリーク電流が増えるんだよね
TSMCもHKMGを導入するようだけど
微細化だけで電力を半分にできるとは思えないな

> さらに、電力食いなのはメモリコントローラやSMPバスなどの、外部との通信。

通常の使い方だと、なんだかんだ言って一番の電力食いはコアの部分だよ
非コア領域殺すことで可能な電力削減なんてたかが知れてると思う

というわけで、Rock以上に爆熱の悪寒
0725名無しさん＠お腹いっぱい。2009/09/14(月) 01:59:56
>>724
> コアあたりのトランジスタ数を増やさずにクロックを倍にできるかな？
> 高クロックを実現するために低Vthのトランジスタを使ったりするだろうから倍で済むとは思えない

同一プロセスでクロックを倍にしようとすれば、そういう話になるだろうね。


0726名無しさん＠お腹いっぱい。2009/09/14(月) 02:24:11
戦争末期の大日本帝国やナチスドイツの妄想兵器レベル
■ このスレッドは過去ログ倉庫に格納されています