SunMicrosystems 最大の探検

SunMicrosystems 最大 ..

2:名無しさん＠お腹いっぱい。
08/04/10 02:20:07
【過去スレ_1of3】
Sun Microsystem最大の失態
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems最大の敗退
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems最大の反省
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems最大の虚勢
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems最後の航海
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems最後の晩餐
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems ラストダンス
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後の反撃
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後の一葉
ｽﾚﾘﾝｸ(unix板)
だまれ小僧！お前にサンが救えるか
ｽﾚﾘﾝｸ(unix板)

3:名無しさん＠お腹いっぱい。
08/04/10 02:20:52
【過去スレ_2of3】
Sun Microsystems 最後の理不尽
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後の量産
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後の遺産
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後から二番目の真実
ｽﾚﾘﾝｸ(unix板)
Sun Microsystem 最大の遊撃
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最大の滝壷
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最大の重複
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最大のリストラ
ｽﾚﾘﾝｸ(unix板)
Sun Microsystem 最大の夜長
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最大の移行
ｽﾚﾘﾝｸ(unix板)

4:名無しさん＠お腹いっぱい。
08/04/10 02:21:17
【過去スレ_3of3】
Sun Microsystems 最大の回復
ｽﾚﾘﾝｸ(unix板)
Sun Microsystems 最後の提携
ｽﾚﾘﾝｸ(unix板)

【公式サイト】
Sun Microsystems
URLﾘﾝｸ(www.sun.com)
サン・マイクロシステムズ
URLﾘﾝｸ(jp.sun.com)

blogs.sun.com
URLﾘﾝｸ(blogs.sun.com)
サン・マイクロシステムズ - 公式ブログ
URLﾘﾝｸ(jp.sun.com)

5:名無しさん＠お腹いっぱい。
08/04/10 06:34:10
URLﾘﾝｸ(www.anandtech.com)
古いが、T1のレビュー記事

6:名無しさん＠お腹いっぱい。
08/04/10 11:33:09
UltraSPQARC T2のベンチマークテストデータ

アンケート答えないとデータもらえないみたいだけど。
URLﾘﾝｸ(www.itmedia.co.jp)

7:名無しさん＠お腹いっぱい。
08/04/10 11:37:09
>>6
>提供：サン・マイクロシステムズ株式会社

8:名無しさん＠お腹いっぱい。
08/04/10 13:10:14
UltraSPQARC って新しいチップかとおもたｗ

9:名無しさん＠お腹いっぱい。
08/04/10 13:12:15
>>6
それ広告だぞ。

たとえ広告でなくても、その手の雑誌やWebサイトの記事は、
メーカーやベンダーの広告で成りたっているので、実質的に広告だ。

10:名無しさん＠お腹いっぱい。
08/04/10 13:34:56
ここだって実質広告みたいなもんだしな

11:名無しさん＠お腹いっぱい。
08/04/10 15:23:57
Ultara SPARK
UltraSPQARC

12:名無しさん＠お腹いっぱい。
08/04/10 15:30:22
>>5
T1の性能は低いな。

13:名無しさん＠お腹いっぱい。
08/04/10 16:17:32
広告だけど、貴重なベンチマークデータじゃん

14:名無しさん＠お腹いっぱい。
08/04/10 16:19:26
T5140/T5240リリース
URLﾘﾝｸ(jp.sun.com)
URLﾘﾝｸ(jp.sun.com)

ベンチマークでも2CPU機でNo.1
URLﾘﾝｸ(www.sun.com)

15:名無しさん＠お腹いっぱい。
08/04/10 16:19:52
ベンチマークと実際のパフォーマンスが違うといえば、Itanium2

16:名無しさん＠お腹いっぱい。
08/04/10 16:22:25
> サーバ毎に128、ラック毎で5,120スレッドという32倍の演算密度を実現

インチキな言い方だな。

17:名無しさん＠お腹いっぱい。
08/04/10 16:31:01
>>15
Niagaraの場合は、そんなにイメージ変わらない。
WebやDBのマルチプロセス処理、マルチスレッド処理やらせるCPUだから。
アーキテクチャー的に、そうした分野で性能出るのは当たり前なわけで。
Webじゃ無敵ですよ。
シングルスレッドは相変わらず1.2-1.4GHzなんで、遅いけどな。
T2000 T1 1.0GHz×8Coreの場合、SunRayサーバとしては向いていなかった。
シングルスレッド遅すぎで、アプリ起動の待ち時間が。。。
ユーザ数増えても性能変わらないんだが、みんな遅いと言う。。。

T2はT1よりはマシそうなんで、いつか試してみたいけど。

18:名無しさん＠お腹いっぱい。
08/04/10 16:32:46
>みんな遅いと言う。。。
可哀想に...おもちゃの実験台になって。

19:名無しさん＠お腹いっぱい。
08/04/10 16:36:39
えーと。君の会社は導入前に性能評価試験しないの？

20:名無しさん＠お腹いっぱい。
08/04/10 16:38:44
>>17
基本性能が出てないからってタダでＴ２に変えてもらえばいいじゃん？ｗ

21:名無しさん＠お腹いっぱい。
08/04/10 16:39:29
Niagaraのコアのスレッドは強制ラウンドロビン?

22:名無しさん＠お腹いっぱい。
08/04/10 18:15:28
>>17
> シングルスレッド遅すぎで、アプリ起動の待ち時間が。。。
なんのアプリ?

23:名無しさん＠お腹いっぱい。
08/04/10 21:33:56
開発ツール

24:名無しさん＠お腹いっぱい。
08/04/10 22:00:31
サン MySQLの日本語による有償サポートを開始
URLﾘﾝｸ(www.nikkeibp.co.jp)

25:名無しさん＠お腹いっぱい。
08/04/10 22:58:49
Web系のシステムが対象だと圧倒的だね。

SPECjAppServer2004
　3331 Sun T5240 UltraSPARC T2 Plus 1.4GHz×8core×2CPU
　2056 HP BL460c Xeon X5460 3.16GHz×4core×2CPU
　2001 Sun T5220 UltraSPARC T2 1.4GHz×8core
　1198 IBM p570 Power6 4.7GHz×4core×2CPU
　874 HP rx2660 Itanium2 1.6GHz×4core×2CPU

26:名無しさん＠お腹いっぱい。
08/04/10 23:06:23
1CPU→2CPUで1.66倍か。
スケールしているんだか、していないんだか。

27:名無しさん＠お腹いっぱい。
08/04/10 23:45:18
64GB入って700マソかぁ

28:名無しさん＠お腹いっぱい。
08/04/11 00:05:47
>>26
SPECint_rate2006 は、きれいに2倍だけど？
・T5220 78.5
・T5240 157

SPECfp_rate2006 は、1.91倍だけど？
・T52２0 62.3
・T5240 119

X5460 3.166GHz×4coreの場合
int_rate
・2CPU 139
・1CPU 78.5
1.77倍

fp_rate
・2CPU 79.2
・1CPU 48.5
1.63倍

T2 Plusの性能悪くなさそうだよ？

29:名無しさん＠お腹いっぱい。
08/04/11 00:07:45
x86 がこのあたりのスケール具合「悪い」ってことすら知らずにほざいてるわけだな。笑止。

30:名無しさん＠お腹いっぱい。
08/04/11 01:18:42
>>29
それはお前の妄想の中だけ。

Xeonは2CPUになってもメモリコントローラが増えないから、サチって当然。
比べるならOpteronの2P構成と。

31:名無しさん＠お腹いっぱい。
08/04/11 01:31:15
>>25
価格性能比にするとビミョーだな。

けど、ようやく Sun もベンチマークの結果を堂々と公表できるようになるなんて
長生きしてみるもんだな w

32:名無しさん＠お腹いっぱい。
08/04/11 01:35:07
T1の頃はOpteron 2Pに負けてたからな。
性能も消費電力も。

33:名無しさん＠お腹いっぱい。
08/04/11 01:35:26
ちょっとSunへの批判ね。これね、2つあるんですよ。1つは21世紀になってUnixはないでしょって。
これはね、SolarisがとうとかLinuxがどうとかというレベルじゃないですよ。
もうひとつ上のレベル。
OSという本質的な意味ね。IBMとかが「Linuxで！」なんて聞くと「え～っ！」て思うもん。
「あなたたち、IBMでしょ。それはないんじゃないですか？」って。
そりゃMulticsの時代にMulticsってヤバイからUnixねって、それって何10年も前の話でしょ。
URLﾘﾝｸ(sdc.sun.co.jp)

34:名無しさん＠お腹いっぱい。
08/04/11 08:25:20
はあ。1980年代終り頃によくそういう話があったね。
それとね、「Multics ってヤバイ」てのは脚色だよ。そんなもん本気にしちゃダメ。
まあ、Linux が粗悪な代用品だということには同意。

35:名無しさん＠お腹いっぱい。
08/04/11 11:31:10
Linuxがまともになるのを待つよりもMacの環境が整備されるのを待つのが早いような気がしてきた

36:名無しさん＠お腹いっぱい。
08/04/11 12:02:02
3億年待ってもデスクトップOSはサーバOSにはならんぞ

37:名無しさん＠お腹いっぱい。
08/04/11 12:14:57
URLﾘﾝｸ(online.plathome.co.jp)
Sun SPARC Enterprise T5240(8HDD)_ 6core/1.2GHz US T2+ x2_ 8GB_ 146GB x2_ CD-RW/DVD-RW_ AC x2
2,209,300円

URLﾘﾝｸ(h50146.www5.hp.com)
HP DL380 G5 Xeon X5460x2(3.16GHz 2x6MB L2 Quad Core), 16GB, 146GBx2
1,577,100円

T2が生きる用途ならバカみたいに高くはないな。
まあ俺が今いるのはSC440買ってるような会社なので無縁の話だが……

38:名無しさん＠お腹いっぱい。
08/04/11 14:08:01
パソコンしか使ったことないやつって x86 でもいわゆるサーバー機は
高いの知らないんだよね。

39:名無しさん＠お腹いっぱい。
08/04/11 14:38:40
x86サーバはピンキリだ。

タワー型の数万円のものから、
ラック2本丸々の数億円のものまで。

40:名無しさん＠お腹いっぱい。
08/04/11 15:52:35
じゃ、全員数万円の買えばいいのにな。高いやつ買うやつはバカだなww

41:名無しさん＠お腹いっぱい。
08/04/11 19:46:58
>>38だけだろ、知らないと思い込んでいるのは。

42:名無しさん＠お腹いっぱい。
08/04/11 20:06:34
＞まあ、Linux が粗悪な代用品だということには同意。
だーかーらー、そういうレベルの話じゃないでしょうが。

43:名無しさん＠お腹いっぱい。
08/04/11 23:14:08
>>30
Opteronはfp意外は速くない。
とりあえず、26のバカが何も調べずにT2 Plusはスケールしないと
口走っていた事だけは分かった

44:名無しさん＠お腹いっぱい。
08/04/11 23:36:02
>>42
えっ... 「粗悪な代用品」以下だ、ってそう言うのか?? ....そうかもなww

45:名無しさん＠お腹いっぱい。
08/04/12 00:33:32
時代はUbuntu！

46:名無しさん＠お腹いっぱい。
08/04/12 10:39:43
T2 Plusもfpを速く計算できるようにしてください！

47:名無しさん＠お腹いっぱい。
08/04/12 11:39:23
>>43
26のどこにスケールしないと書いてあるんだ?
これだから頭が狂っている信者は困る。

Niagara2のアーキテクチャからすれば、1.66倍というのは変だね。
たぶんメモリのチャンネル数を増やしていないので、そこがネックなのだろう。
1コアから8コアまでリニアにスケールするのだから、9コア以降もリニアに行くはず。

48:名無しさん＠お腹いっぱい。
08/04/12 11:46:59
T5220→T5240で、メモリスロットは16→32に増えてる。
スロットが増えているだけでチャンネルが増えてない、なんてことはないだろう。

ディスクかネットワークか、あるいは、OSにボトルネックがあるんだろう。
Solarisはマルチスレッドでスケールするといっても、128スレッドもあれば
オーバーヘッドは無視できないだろう。

>>5なんかは、クライアント数が増加するとT1だけが性能が落ちてるんだな。
同じSolarisでもOpteronは性能が落ちないのだから、明らかにスレッド数が
多くなるとオーバーヘッドが無視できないということだろう。

49:名無しさん＠お腹いっぱい。
08/04/12 12:00:30
> ないだろう。
> ないだろう。
> ことだろう。

50:名無しさん＠お腹いっぱい。
08/04/12 12:40:34
そんなところにしか突っ込めないのか。
これだから信者は。

51:名無しさん＠お腹いっぱい。
08/04/12 14:07:46
nスレッドまでスケールしたからって、n+1スレッドでもスケールするとは限らない。
MTはそんなに簡単じゃない。

52:名無しさん＠お腹いっぱい。
08/04/12 14:41:37
T2+の2U鯖を入れるくらいなら、T2の1U鯖を2台入れたほうが、トータルのスループットは高いってことだな。

53:名無しさん＠お腹いっぱい。
08/04/12 16:40:44
うまく分割できるような対象ならそれでいいね

54:名無しさん＠お腹いっぱい。
08/04/12 17:22:16
どうせコア毎にパーティション切って使うし。

55:名無しさん＠お腹いっぱい。
08/04/12 17:52:41
痛ニウム鯖をもらってきたんだが
あまりに部屋が暑くなるので使ってらんない
速攻で返した
こんど何かもらうときはNiagara鯖にする

56:名無しさん＠お腹いっぱい。
08/04/13 09:38:20
>>55
それ暑い暑くない以前に、他人事ながら電気代が心配になるような話だな。

57:名無しさん＠お腹いっぱい。
08/04/13 10:13:43
先週末、帰宅後に自室にあるOpteron機(2Ghz)のfirefox 3.0bが暴走して、
週明けに出勤したら部屋が異常高温になっていた…

58:名無しさん＠お腹いっぱい。
08/04/13 11:39:12
>>48
> スロットが増えているだけでチャンネルが増えてない、なんてことはないだろう。

ところがどっこい。
スロットは倍に増えたが、チャンネルは増えてないんだな。

T2 → T2+ での変更点
消費電力 95W → 123W
FB-DIMMチャンネル数およびバンド幅半減
10GbE 内蔵2個 → なし

>>47の予想が当たり。

59:名無しさん＠お腹いっぱい。
08/04/14 09:59:48
>>57
すわ、チャイナシンドロームww

60:名無しさん＠お腹いっぱい。
08/04/14 10:45:55
CPU廃熱アップ→室温アップ→ファン回転数アップ→ファン消費電力アップ→室温アップ

ファンの消費電力は馬鹿にできない。

61:名無しさん＠お腹いっぱい。
08/04/14 11:50:28
10GbE なくなってんのか。ちょっと残念だな。まあ電気喰うわな。

62:名無しさん＠お腹いっぱい。
08/04/14 13:05:01
10GbEを内蔵しなくなった代わりに、PCI Expressの口が増えてる。

T1とT2は、システムをワンチップに押し込む方針
T2 Plusは、複数チップを使ってシステムを構成する方針
ということなのだろう。

メモリの口が半減しているのは、
他のプロセッサとのメモリ共有を行うSSIのためだと思うが、
Sunは、
T2は設計ミスで無駄に倍のチャンネル数を持たせてしまった
T2 Plusのチャンネル数が適正な設計である
と言ってるそうな。

63:名無しさん＠お腹いっぱい。
08/04/14 20:56:25
T2 Plus速いからいいじゃん。
T2 2台の方が速いんだろうけど、お金もスペースも電気もかかるから。
T2 Plusはリーズナブルじゃね？

64:名無しさん＠お腹いっぱい。
08/04/14 22:07:19
なんか笑う。

26 名前：名無しさん＠お腹いっぱい。 [sage] 投稿日： 2008/04/10(木) 23:06:23
1CPU→2CPUで1.66倍か。
スケールしているんだか、していないんだか。

28 名前：名無しさん＠お腹いっぱい。投稿日： 2008/04/11(金) 00:05:47
>>26
SPECint_rate2006 は、きれいに2倍だけど？
・T5220 78.5
・T5240 157

SPECfp_rate2006 は、1.91倍だけど？
・T52２0 62.3
・T5240 119

X5460 3.166GHz×4coreの場合
int_rate
・2CPU 139
・1CPU 78.5
1.77倍

fp_rate
・2CPU 79.2
・1CPU 48.5
1.63倍

T2 Plusの性能悪くなさそうだよ？

65:名無しさん＠お腹いっぱい。
08/04/14 22:35:49
そうだね
消費電力・発熱量・お値段
そのあたりが気になるね
正味のところ

66:名無しさん＠お腹いっぱい。
08/04/14 23:03:31
>>64
しつこいな。
馬鹿をからかって面白がるのは悪趣味だぞ。

67:名無しさん＠お腹いっぱい。
08/04/15 13:45:37
サーバファームというと思いつくのはまずGoogleだけど、
彼らはどこのベンダのハードウェア使ってるの?
IAなのはまあ当然として、T2よりももっと安い価格帯のを並べてるんじゃないかと
思ってるんだけど。

何がいいたいかというと、Niagaraのもっと安いのも作ってください。

68:名無しさん＠お腹いっぱい。
08/04/15 13:59:06
ボリュームディスカウントは当然やってるだろうけど、それでも全体の台数が
めちゃ多いからね。各社から買ってるんでない?
SPARC も大量に買ってるはず。

69:名無しさん＠お腹いっぱい。
08/04/15 14:29:19
昔のGoogleは、
でっかい平屋建ての倉庫の床に、
デスクトップPCを並べてたらしいぞ。

各ノードが保持している、
Webページのコピーやインデックスを失っても、また再取得・再構築すればいいし、
一時的に検索から外れるページが生じても気にしないので、
信頼性が低くても、HDDが多重化されていなくても、あまり問題ではなかった模様。

いまは違うだろうけれどもね。

70:名無しさん＠お腹いっぱい。
08/04/15 14:44:52
Googleの昔のHDD箱
URLﾘﾝｸ(infolab.stanford.edu)

初期のサーバ
URLﾘﾝｸ(en.wikipedia.org)

Googleのサーバの概要
URLﾘﾝｸ(en.wikipedia.org)

71:名無しさん＠お腹いっぱい。
08/04/15 14:48:32
床置きではなく、
URLﾘﾝｸ(www.aoky.net)
こういう自作サーバ

72:名無しさん＠お腹いっぱい。
08/04/15 14:49:48
いまのGoogleのサーバの写真
URLﾘﾝｸ(www.anticlockwise.com)

73:名無しさん＠お腹いっぱい。
08/04/15 15:11:08
> SPARC も大量に買ってるはず。

Sun信者www

74:名無しさん＠お腹いっぱい。
08/04/15 15:31:23
>>70
1998年にスタンフォード大に置かれていたときはSunも使われていたらしい。
まあそりゃありそうだ。

今は電力性能比で選んでいるようだから、SPARCの採用もまるきり夢物語
というわけでもないだろう。というか、それくらいの勢いがほしいよな。

75:名無しさん＠お腹いっぱい。
08/04/15 15:45:34
おいおい、ある程度のボリューム調達してるって記事があったよ。
つか、エリックシュミットだぜ?

76:名無しさん＠お腹いっぱい。
08/04/15 15:47:36
てか、Google が単一のメーカーから計算機仕入れてると思ってる方がどうかしてる。

77:名無しさん＠お腹いっぱい。
08/04/15 15:52:40
CEOがEric Schmidtだからって理由でSPARCが入るなら
NovellもJavaも使ってる事になるが。

>>76
当然ベンダは複数だろうが、アーキティクチャがx86以外に複数混在してたら俺は驚く。

78:名無しさん＠お腹いっぱい。
08/04/15 15:54:50
単一のシステムじゃないよ。Linux 好きなやつは Linux 使ってるし、
FreeBSD 得意なやつは FreeBSD 使ってる。だから Solaris/SPARC も当然居る。

79:名無しさん＠お腹いっぱい。
08/04/15 16:25:52
サーバファームの話をしているわけだが。

80:名無しさん＠お腹いっぱい。
08/04/15 16:28:31
>>71のような記事を探していた
ありがとう

81:名無しさん＠お腹いっぱい。
08/04/15 16:43:56
> そして彼らは今も1999年の頃と変わらず、コモディティクラスのx86 PCをカスタムビルドしているのだ。

この記述は信じ難いものが。工場で大量生産するからコモディティなんであって、
手作りしたらコモデティじゃねえじゃん。

82:名無しさん＠お腹いっぱい。
08/04/15 16:52:36
>>75
会長が現場の合理的な選択を覆せるわけがない。

>>76
Googleはメーカー製のサーバは一部にしか使ってないと思うぞ。

Googleの凄いところは、
DIYパソコン的にサーバを自作していた段階から更に進んで、
いまでは電源ユニットやマザーボードがGoogle専用仕様だということ。

エンタープライズ向けとかHPC向けの既存のサーバ製品は、
Googleの要求仕様に対して余計な機能・消費電力が多いのだろう。

たぶん、OrionのDT-12やDS-96に使われているような高密度なサーバだろう。

83:名無しさん＠お腹いっぱい。
08/04/15 16:57:57
>>81
「コモディティクラス」というのは日本でいうところの「ローエンドPC」というやつだと思う。

サーバ向けのCPUではなく、ローエンドPC向けのCPUを使う(当然、CPUは1台に1つ)
サーバ向けのHDDではなく、ローエンドPC向けのHDDを使う(当然、IDEやSATA)
ということだと思うよ。

84:名無しさん＠お腹いっぱい。
08/04/15 16:58:07
え? そういう話ならいわゆるキャリアグレード仕様が有効な気がするけど。

85:名無しさん＠お腹いっぱい。
08/04/15 16:59:34
つーか、goole は公表してないし、なんとか Sun 使ってないことにしたいアンチあわれww
てか、も少しひねった面白いこと言えよ低能wwww

86:名無しさん＠お腹いっぱい。
08/04/15 17:08:48
SPARCの話じゃないけどOpenSolaris自体はGoogleで使ってるよね。
Google規模からしてみればたったの数百台だけど。
URLﾘﾝｸ(blogs.sun.com)

87:名無しさん＠お腹いっぱい。
08/04/15 17:09:22
>>84
冗長機能とか冷却ファンの消費電力が無駄じゃん。

>>85
まったく公表されていないわけではないぞ。
Googleは取材に対して口を閉ざしているが、
インテルが受注したとか、そういう話は出てる。

ま、SPARCを全く使っていないわけではないだろうが、
Niagara以前のSPARCの性能対消費電力では論外だろう。
Niagaraにしてもプロセッサの消費電力は低くても他の部分の
消費電力が大きいので採用されていないと思うぞ。

88:名無しさん＠お腹いっぱい。
08/04/15 17:33:44
2005年12月の資料
URLﾘﾝｸ(www.strassmann.com)

ラック1本に88台のサーバ。
そのサーバの仕様は、2GHzのCPUを2個、2GBのメモリ、80GBのハードディスク1台
信頼性はハードウェアではなくソフトウェアによって実現する

89:名無しさん＠お腹いっぱい。
08/04/15 18:17:38
GoogleのサーバはCPUが特注っていう話もあるぞ。

特定ユーザのために開発したものが一般に出まわることもあって、
Opteronの低消費電力版はGoogleのために開発されたのかもな。

ちなみにPentiumPro用のODPは、アメリカのASCI Redのために開発されたらしい。

90:名無しさん＠お腹いっぱい。
08/04/15 19:12:10
TransmetaでCrusoe作った人は、SunでSPARC開発してた人らしいな。

あれはItaniumよりも酷いCPUだった。

省電力といってもアイドル時だけで、
コードモーフィングのために電力とサイクルを食い、
パソコンとして使うと消費電力がちっとも削減されなかった。

91:名無しさん＠お腹いっぱい。
08/04/15 19:12:49
CMSバージョンアップするする詐欺か。

92:名無しさん＠お腹いっぱい。
08/04/15 20:09:43
IBM社、水冷式のスーパーコンピュータを発表
URLﾘﾝｸ(www.ednjapan.com)

IBM社は、「Power575は1ラック当たりプロセッサコアを448個搭載でき、
従来のシステムの5倍以上のパフォーマンスを実現する。
また、この水冷方式とPower6を採用するによって、
ラック当たりのエネルギ効率は3倍高められる」と説明する。

93:名無しさん＠お腹いっぱい。
08/04/15 20:20:16
>>90
ハイパフォーマンス一辺倒から現在の低消費電力志向へとシフトする
先駆けはPowerPC750だと思うが、x86PC界で初めて低消費電力本位
のCPUを製品化したのがCrusoeで、ノートPCメーカー各社が採用した
ので危機感を煽られたIntelが結果としてPentiumM系統に注力をして、
現在のCore系CPUが出来るに至ったと考えれば、

「踏み台として充分に役に立った」

と言えるので、踏み台にもならないItaniumよりは価値があっただろうw

94:名無しさん＠お腹いっぱい。
08/04/15 20:42:10
IA-64はAMD64の踏み台になったんだが。

IA-64の失敗が明るみに出るまでは、
みな、
もうx86は駄目だABIを変えるべきだという話だった。

IA-64が失敗したからこそ、
ABIを変えないことに対する批判がなくなり、
AMD64が歓迎された。

95:名無しさん＠お腹いっぱい。
08/04/15 20:50:12
Transmeta は死ぬ程優秀だよ。SuperSPARC 以降の汚名を注いだと言える。
バカにはわからんだろうが、ここへ来るなよ。x86 使ってうれしがってりゃいいだろが。

96:名無しさん＠お腹いっぱい。
08/04/15 20:50:58
汚名を注ぐのですね！

97:名無しさん＠お腹いっぱい。
08/04/15 20:51:11
つーか、Itanium はクソだ。未だに見捨てられない企業群あわれ。終ってる。

98:名無しさん＠お腹いっぱい。
08/04/15 20:53:01
>>93
> x86PC界で初めて低消費電力本位のCPUを製品化したのがCrusoe

カタログスペックだけ、な。

Crusoe登場で各社から最初の採用モデルが出た時がピークで、
あっという間にCrusoeは売れなくなった。
Crusoeの不振は自滅であり、インテルは関係ない。

Crusoeの600MHz動作時のパフォーマンスと消費電力は、
それぞれCeleron 600MHzを300MHz動作させた時と同じくらいで、
コードモーフィングのペナルティがあるので、
Celeron 600MHzの300MHz動作のほうが使用感は良かった。

99:名無しさん＠お腹いっぱい。
08/04/15 22:31:09
>>67
マザボかってきて自分で並べている

100:名無しさん＠お腹いっぱい。
08/04/15 22:32:26
あんなクズ命令セットを疑似ること自体にムリがあるという点は認めざるを得んな。
けどあそこまで健闘した意義は大きい。Intel がいかにクズ作ってたかを浮き彫りにした。
NetBurst な。
もういいから来んな。x86使ってヨダレたらしてろw

101:名無しさん＠お腹いっぱい。
08/04/15 23:11:55
信者の発言は面白いな

102:名無しさん＠お腹いっぱい。
08/04/15 23:22:01
> あんなクズ命令セットを疑似ること自体にムリがあるという点は認めざるを得んな。

・疑似ること自体にムリがある
・あんなクズ命令セットだから疑似ることにムリがある

どっち?

> けどあそこまで健闘した意義は大きい。

健闘? Transmetaは大赤字だったぞ。

> Intel がいかにクズ作ってたかを浮き彫りにした。

同時期のインテルのモバイルCPUのほうが、優れていたのだが。
Crusoeを手にした人の多くが、そのあまりの鈍足モッサリぶりに騙されたと感じてたぞ。

> NetBurst な。

唐突にどうした?

NetBurstは、当時、事務アプリと動画処理をバランスよく処理できるCPUだった。
消費電力は大きかったが、リアルタイムに処理できなければ、いくら省電力でも意味がない。

103:名無しさん＠お腹いっぱい。
08/04/15 23:33:56
あえて時期の違うCPUを比較してみよう。

Pentium4 2.4BGHz
TDP 57.8W (設計上の最大消費電力は74.7W)
実際のアプリケーションではVRMを含めて50W程度。

AthlonXP 2400+
TDP typ 62W、max 68W
実際のアプリケーションではVRMを含めて60W程度。

動画エンコードではPentium4のほうが高速。
事務アプリではAthlonXPのほうが高速だが、かなりの過剰性能。

デスクトップCPUとしてはPentium4は良くできてる。

サーバ用としてはNetBurstダメだったな。
XeonMP 1.4GHz Quadのマシンの性能は、
それはもう酷い代物だった。

PentiumIII-S 1.4GHz Dualのほうが速かった。

104:名無しさん＠お腹いっぱい。
08/04/16 01:37:43
> 動画エンコードではPentium4のほうが高速。
> 事務アプリではAthlonXPのほうが高速だが、かなりの過剰性能。
こんなクソバカぶりは、どうぞよそでやってください。迷惑です。

105:名無しさん＠お腹いっぱい。
08/04/16 09:22:23
売れる → 優秀
独禁法不要ですね。ファシストかなんかの方ですか?

106:名無しさん＠お腹いっぱい。
08/04/16 09:34:47
>>96
あってると思うけど。

107:名無しさん＠お腹いっぱい。
08/04/16 10:13:28
フィルタ複数使うと、Pen4遅くなったような
AthlonXPはidol時の省電力性に疑問があった

108:名無しさん＠お腹いっぱい。
08/04/16 10:20:15
Idleや

109:名無しさん＠お腹いっぱい。
08/04/16 10:29:37
信者には真実が見えないらしいな。

両方を使い比べずに、
思い込みだけでPentium4を叩けば、
それで常識派を気取れると思っているようだが。

インテルのP6系よりもUltraSPARCのほうが速いと
信じていた人たちもいたなぁ。
両方を使い比べて見れば、簡単にわかることなのに。

110:名無しさん＠お腹いっぱい。
08/04/16 10:30:19
>idol時の省電力性に疑問
Perfumeのことか？

111:名無しさん＠お腹いっぱい。
08/04/16 10:56:05
>>110
悪くないで砂

112:名無しさん＠お腹いっぱい。
08/04/16 11:23:21
>>109
比べまくりだけど。SuperSPARC と PenPro の時から。
「信じていた」とか意味不明なんだよ。SPARC 使ってもないのにこんなとこへ
ノコノコやってくる馬鹿者はおまえぐらいだって言ってんだろ何べん言えば(以下略)

113:名無しさん＠お腹いっぱい。
08/04/16 11:30:19
PenPro ターニングポイントだとかってえらい持ち上げられてるけど、
キャッシュ溢れるとパフォーマンスがた落ち（素Pen 以下）のひどい CPU だったけどなww

114:名無しさん＠お腹いっぱい。
08/04/16 11:32:03
そのあとの「スロットＸ」も、笑えたよな。いったいありゃなんだったんだwwww

115:名無しさん＠お腹いっぱい。
08/04/16 11:46:14
適材適所で使い分ければいいだけのことなのだが、
信者はどこでもx86、どこでもSPARCといった具合に、
使い分けができないのですよ。

ASCIのスパコン
Intel PentiumPro
IBM POWER5
IBM PowerPC 604e
AMD Opteron

あれ? SPARCは?

116:名無しさん＠お腹いっぱい。
08/04/16 12:01:17
痛ニウムもないじゃん

117:名無しさん＠お腹いっぱい。
08/04/16 12:01:53
痛ニウムなんか、なくて当然。

118:名無しさん＠お腹いっぱい。
08/04/16 12:05:27
地球シミュレータをトップの座から引きずり下ろしたのは、Itanium2×1万個のSGIのスパコンだったと思う。

119:名無しさん＠お腹いっぱい。
08/04/16 13:49:27
>>90
最初の製品であれだけのものを作ったのにはびっくりした。
商売的にうまくいかずに特許ライセンス会社になってしまって残念。

Java bytecode用のCMSもあったらしいが、
顧客が全く見向きしなかったとか。
今やコードモーフィング(JIT/Hotspot)前提のJVMの方が、
x86よりはいい市場かと思ったが。

120:名無しさん＠お腹いっぱい。
08/04/16 14:00:17
Transmetaの失敗はVLIWの欠点によるもので、技術的なものだろう。

121:名無しさん＠お腹いっぱい。
08/04/16 14:15:01
だからさー、VLIW 失敗してたら x86 並の速度なんて出てないんだってば。
Transmeta の 2種はちゃんと性能が出た。ひきかえ初Ita の x86 エミュは悲惨。
VLIW は内部実装としては十分有効。
次元低すぎ来るんじゃねー!!!!!!

122:名無しさん＠お腹いっぱい。
08/04/16 15:00:22
要約すると、わたしはIntelが嫌いです、という意味?

Itaniumの32ビットモードはパフォーマンスを指向した設計じゃないから
別に性能出なくていいんだけど、
VLIW採用してもハードウェアの複雑さを軽減できなかったItanium、
VLIWの欠点を乗り越えるためにx86 ISAを採用したものの、ネイティブx86チップに
パフォーマンスでも電力性能比でも負けたCrusoe/Efficeonを以て、
CPUにおけるVLIWの実験は終了した、と思っていいんじゃないかな。

まだGPGPU方面では続いてるけど。

123:名無しさん＠お腹いっぱい。
08/04/16 15:18:23
>>119
> 最初の製品であれだけのものを作った

最初ゴタゴタして延期したり型番変ったりスペック変ったりしてたんだがな。

一度採用して走り出したらすぐには止まれない日本の大手メーカーが
こぞって採用して搭載モデルを出したからこそ何とかなったのであって、
モノが良かったわけではない。

各メーカーとも薄型モバイルのフラッグシップ的モデルには採用せず、
廉価で中途半端なモデルだけの採用に留まったことが、
モノが悪かったことの証しだろう。

ま、日本メーカーの風土のために延命というのはItaniumと一緒だな。

>>120
もしVLIWの欠点が原因で失敗したのなら、
それはVLIWを採用したTransmetaが悪い。
VLIWしか採用できないという縛りがないのに、
VLIWを選んだのだから。

>>121
> 次元低すぎ来るんじゃねー!!!!!!

お前が低すぎ。

124:名無しさん＠お腹いっぱい。
08/04/16 15:19:01
いいえ。終ったのは i860 と Itanium だけです。

125:名無しさん＠お腹いっぱい。
08/04/16 15:21:01
>>122
ItaniumはVLIWではなくEPIC

EPICだから複雑になる。

126:名無しさん＠お腹いっぱい。
08/04/16 15:31:07
こんなレベルだとさすがに Intel でも迷惑だろうなwwww

127:名無しさん＠お腹いっぱい。
08/04/16 15:33:51
>>123
狂う象は延命してないじゃん
日本のメーカはもっと良くなる期待があったんだろうけど、
x86互換性問題に加えて、なかなか向上が見られなかったから切り捨てた。

128:名無しさん＠お腹いっぱい。
08/04/16 15:48:54
>>127
延命ってのは、それなりに一時代を築いたものに対して、言うことだな。

ItaniumとCrusoeいずれも、
最初で躓いて即死するような代物だったのだが、
アホな日本メーカーが支えちゃった。

129:名無しさん＠お腹いっぱい。
08/04/16 15:53:08
>>125
投機実行どころか、
とりあえず全部実行しておいてから後で結果を捨てる
なんていうアーキテクチャだからな。
そりゃあ消費電力が馬鹿デカくなるのも当然だ。

130:名無しさん＠お腹いっぱい。
08/04/16 15:54:42
二つとも既存システムとの互換性の問題が大きかったと思う。
食い込める市場じゃなかったというか。

131:名無しさん＠お腹いっぱい。
08/04/16 15:55:22
>>129
投機ですやん！

132:名無しさん＠お腹いっぱい。
08/04/16 15:56:24
VLIWの欠点が受け入れられるものではなかったから
拡張してEPICを名乗ったわけで、
複雑さをEPICのせいにしても、VLIWは助からんよ。

133:名無しさん＠お腹いっぱい。
08/04/16 16:43:20
いや、だから、VLIW って全然死んでないって何度言えば...
Intel ホメ殺しキャンペーンですか?wwww

134:名無しさん＠お腹いっぱい。
08/04/16 16:48:43
>>128
Transmeta の、特に Efficeon は実際パフォーマンス出てたけど、
資源が尽きるまでに商業的に間に合わなかった。技術的には大成功の部類。

ひきかえ Itanium は....... 死ぬ程資源投入してこれでもかってコネクリ回して
時間もかけて（外見上はまだ終らないww）ダメが証明された技術的大失敗。
正反対。

あんまりはずかしーこと言わんといてくれww

135:名無しさん＠お腹いっぱい。
08/04/16 17:00:29
Crusoe→Efficeon
初代Itanium→初代Itanium2

クロック・消費電力は僅かな上昇だが、
そのパフォーマンスは倍に跳ね上がった。

似てるね。

136:名無しさん＠お腹いっぱい。
08/04/16 17:09:33
>>134
EfficeonはULV版のPentiumIII-Mに、
速度でも消費電力でも負けてたから、
売れなかった。

売れていれば継続できてたと思うぞ。

137:名無しさん＠お腹いっぱい。
08/04/16 17:14:27
つけ加えると、価格も。

138:名無しさん＠お腹いっぱい。
08/04/16 17:15:54
だから、だれが「売れてたら」なんて話してんだよ。
そんな話わざわざしないとあんた以外理解できないとでも思ってるのか? ガイコツ開けるぞ?!

139:名無しさん＠お腹いっぱい。
08/04/16 17:33:00
>>138

っ >>134

140:名無しさん＠お腹いっぱい。
08/04/16 17:54:48
（パカッ）

141:名無しさん＠お腹いっぱい。
08/04/16 17:57:51
>>138
お前、ちょっと行間とか読めるようになれ

142:名無しさん＠お腹いっぱい。
08/04/16 18:30:33
ゴミ記事に行間見えるようになったらおしまいだろ。
ただの垂れ流しじゃねーか(#

143:名無しさん＠お腹いっぱい。
08/04/16 18:34:02
>>142
何をそんなにムキになってるんだ?

144:名無しさん＠お腹いっぱい。
08/04/16 18:49:01
>>134
>技術的には大成功の部類。

「SPARC64 VI」も技術的には大成功なのに商売的には不振だったね…

145:名無しさん＠お腹いっぱい。
08/04/16 23:53:07
商業的に成功しているCPUなんて、
x86, PowerPC, ARMくらいじゃね?

146:名無しさん＠お腹いっぱい。
08/04/17 02:57:32
なんでSunはNiagaraのx86版を出さないんだ?

147:名無しさん＠お腹いっぱい。
08/04/17 10:22:02
はぁ??? なんで x86 の携帯電話がないかとか考えてみな。
なんで x86 の大型機がないか（商品としては何度も出てるがなww）も、
なんで MS の OS がマルチプラットフォームをろくに維持できないか、もな。

148:名無しさん＠お腹いっぱい。
08/04/17 12:59:27
>>147
関係ない話だな。

SunはOpteronサーバを作って売っているのだから、
その延長線上に、
x86版Niagaraサーバがあってもいいだろう。

x86にはできないSPARCでなければならない需要があるのだから、
x86サーバの性能を飛躍的に向上させても共食いにはならないでしょう。

149:名無しさん＠お腹いっぱい。
08/04/17 14:07:04
?? あんた、何言ってんの? おつむだいじょうぶ?

150:名無しさん＠お腹いっぱい。
08/04/17 14:16:24
>>149
言うに事欠いて、それか。

151:名無しさん＠お腹いっぱい。
08/04/17 14:29:10
事欠くもなにも、意味がわからんぞ。「SPARCでなければならない」んなら、
コアは SPARC なんだよな? それのどこらへんが「x86版」なんだよ。
おまえ小学生なのか?

152:名無しさん＠お腹いっぱい。
08/04/17 15:36:40
>>151
x86版のNiagaraは、SPARCと競合しない
ってことだろ。

153:名無しさん＠お腹いっぱい。
08/04/17 15:43:47
だから、具体的になんなんだよ x86版Niagara ってよ。阿呆かおまえ? 阿呆確定。

154:名無しさん＠お腹いっぱい。
08/04/17 16:12:40
>>153って読解力なさすぎ

155:名無しさん＠お腹いっぱい。
08/04/17 16:55:52
x86でナイアガラに似たCPUを作る能力はSunにはないと思われ
作ったところで誰もうれしくないだろ
ニッチ向けだからNiagaraの価値があるのに

156:名無しさん＠お腹いっぱい。
08/04/17 17:02:48
SPARCだからNiagaraを選ぶのではなく、
NiagaraだからSPARCを選んでいる客は
いるだろう。x86版を作ったら競合する。

157:名無しさん＠お腹いっぱい。
08/04/17 17:28:03
もしインテルのNehalemの8コア×8CPU構成が1Uラックに入ったら脅威だろうな。
ま、そんなことは、ありえないと思うが。

158:名無しさん＠お腹いっぱい。
08/04/17 17:30:07
SPARCは乗りかかった船だから続けてるだけで、
新たにx86に参入するぐらいなら、さっさと半導体から撤退するわなあ。

まあ、市場の要求があるならSun以外がやってもおかしくはないけどね。

159:名無しさん＠お腹いっぱい。
08/04/17 19:57:09
x86なNiagaraみたいなのをSunが作れる可能性ってどれくらいあるんだろう。

160:名無しさん＠お腹いっぱい。
08/04/17 20:18:35
インテルよりも技術力のあるSunに作れないわけがない。

161:名無しさん＠お腹いっぱい。
08/04/17 20:20:15
x86が組込みで使われていないと思ったら大間違い。
俺が使っている液晶モニタのコントローラはx86だぞ。

162:名無しさん＠お腹いっぱい。
08/04/18 00:25:14
URLﾘﾝｸ(pc.watch.impress.co.jp)
> 例えば、Intelにやる気があれば、Silverthorneコアを16個載せた、
> エッジサーバー向けCPUをSunに対抗して作ることもできる。

163:名無しさん＠お腹いっぱい。
08/04/18 09:51:14
OSはどうするんだろうな
Windowsでエッジサーバやりたいという奇特なお客様向けだろうか

164:名無しさん＠お腹いっぱい。
08/04/18 10:15:22
Windows HPC Server 2008 はクラスタだけだっけ？

165:名無しさん＠お腹いっぱい。
08/04/18 10:39:02
>>159
そういう意味かよ。ほんっっっっっっっっっーーーーーーーーーーーとぉーに、バカ?
Sun じゃなくて、誰にも作れねーよそんなもん。作れりゃ Intel がとっくに作ってる。
本気で小学生か? 来るんじゃない。ゴミ回収しておうちへ帰れ。

166:名無しさん＠お腹いっぱい。
08/04/18 12:51:01
>>163
Solaris x86使っちゃいなYO!

ってのはともかくとして、x86ならFreeBSDでもなんでもいいよね。
まさにNiagaraのおかげで、マルチコア環境下でのパフォーマンス検証が容易になったし、
OS側は準備できてるんじゃないかな。

167:名無しさん＠お腹いっぱい。
08/04/18 12:56:17
>>163
インテルのロードマップには、
8コア×8CPU×2スレッドで128スレッドの構成が可能なCPUが載ってるんだわ。

インテルはLinux向けにコンパイラやライブラリなどを提供しているくらいなので、
x86版Solarisがサポートしないなら、インテルがLinuxカーネルの改良にも手を出すだろう。

168:名無しさん＠お腹いっぱい。
08/04/18 13:13:41
>>165
インテルが32コア128スレッドのチップを開発中だな。
浮動小数点演算を強化してあって特殊用途向けだが。

169:名無しさん＠お腹いっぱい。
08/04/18 14:03:19
Intelが参入するぐらい、
スループットコンピューティングのパイが大きくなったら万々歳なのだが。

170:名無しさん＠お腹いっぱい。
08/04/18 14:06:17
インテルのロードマップには、10GHzのCPUが出荷されているはずなんだが
あそこのロードマップとやらは単に現行のCPUを高く売るための見せ玉ではないか

171:名無しさん＠お腹いっぱい。
08/04/18 14:07:09
×インテルのロードマップには
○インテルのロードマップどおりなら

172:名無しさん＠お腹いっぱい。
08/04/18 14:45:55
URLﾘﾝｸ(pc.watch.impress.co.jp)
> ●2007年には10GHzと予告するIntel

実際には2004年後半にPrescott 3.8GHzを発売し、結局それが最高周波数となる。

Intelの最近のロードマップはおとなしい。
URLﾘﾝｸ(pc.watch.impress.co.jp)

173:名無しさん＠お腹いっぱい。
08/04/18 14:56:07
失敗確実なロードマップだな
情報工学の知識が少しでもあれば
多コアでの性能向上が一部のアプリケーションに留まるというのは論をまたない

174:名無しさん＠お腹いっぱい。
08/04/18 15:00:35
>>172
命令セットをボリボリ拡張するのは勘弁してほしいな。
x86の利点である、バイナリ互換を損なう。

175:名無しさん＠お腹いっぱい。
08/04/18 15:05:01
> x86(IA-32/Intel 64)アーキテクチャでは、これまで命令の頭に「プリフィックス(Prefix)」を加えることで、
> 新命令を実現してきた。これは、あたかも、狭い家を次々に増築するようなもので、
> その結果、家(命令セット)は不格好でつぎはぎだらけになってしまった。
> こうした命令セットの複雑化と命令長の伸張は、x86 CPUのパフォーマンス向上の大きな壁になっている。
> そこで、AVXでは、従来の不格好なx86命令の拡張方式をやめる。
> その代わりに、より効率的で、CPUハードウェアが扱いやすく、将来の拡張も容易な命令フォーマットシステムを導入する。

言ってることが、IA-64のときと同じだな。

176:名無しさん＠お腹いっぱい。
08/04/18 15:23:05
追加命令をSIMDみたいに小出しにせず5年は安定して使えるアクセラレータにして欲しいね。
とりあえずMicrocodeでも何でもいいので実装してブラッシュアップは後付
性能出すためにマイナ番号を参照するかしないかはソフト任せって感じで

177:名無しさん＠お腹いっぱい。
08/04/18 15:28:48
RISCのSPARCよりも、CISCのx86のほうが
シングルスレッド性能を諦めマルチコア・マルチスレッド化が必要だと思う。

1クロックで6命令も実行しようとするから大変なことになるわけで、
そのために膨大なトランジスタと電力を使う代わりに、
1クロックで1命令しか実行しない単純なパイプラインを6本並べるべきだ。

1本のパイプラインで同時に1つのスレッドしか実行しないから、ストール対策で
分岐予測や投機ロード・投機実行、アウトオブオーダ実行が必要になるわけで、
それらに必要なトランジスタ数を、それらをやめてSMTに振り分けるべきだ。

ところが既存のシングルコア相当のトランジスタで、数十のスレッドを処理すると、
クアッドコアやSMPマシンでは、膨大なスレッドを処理することになって、
既存のOSではムリということになってくるので、誰もこんなものは作らないだろうな。

178:名無しさん＠お腹いっぱい。
08/04/18 15:30:31
日奈森あむダールの法則というのがあってだな……

179:名無しさん＠お腹いっぱい。
08/04/18 16:37:17
お前ら（って、たぶん一人だが。小学生w）、x86 がふつーの RISC みたいに
多コアにしてまともに稼働すると思ったら大間違いだぞ。大規模 SMP が
まともに作れないものをいくらチップに押し込めたってムダなんだよ。あれはゴミ。
Intel が OS 作る必要がありゃとっくに作ってんだよ。その方が
「次世代 IA64」なんて作るよりずっと安いんだからさ。
もう八方塞がってんだよ。わかったか、小学生!!www

180:名無しさん＠お腹いっぱい。
08/04/18 18:01:25
>>179
小学生並の煽りをするのは、いかがなものかと。

181:名無しさん＠お腹いっぱい。
08/04/18 18:04:56
　|人
　|___）
　|＿_）ｸｽｸｽ
　|∀・）
　￣￣￣￣

182:名無しさん＠お腹いっぱい。
08/04/18 18:14:14
幼稚だな

さておき。

インテルに大規模SMPでスケールするCPUを作る能力がなければ、
実績を持っているSunには大きな大きなビジネスチャンスだ。
SPARCと同じキャッシュ&メモリシステムで、x86命令セットを実行
するプロセッサを作ればいいんだからな。

183:名無しさん＠お腹いっぱい。
08/04/18 18:40:21
はぁ。まあがんばってくれや。でもよそでがんばってくれる?
なんぼなんでもレベル低すぎ。

184:名無しさん＠お腹いっぱい。
08/04/18 18:58:16
>>182
Athlon(K7)はAlphaのEV6バスを使っていたが、AlphaのようなSMP機は作られてないだろ。
x86で大規模SMPマシンが作られてこなかったのは、単に、32ビットだったからだろう。
(32ビットでも足りていた時代には、386とか486を使って30cpuのマシンが作られたりしてた。)

x86が64ビット拡張されたItanium2やOpteronでは、SGIが大規模SMPマシンを作ってる。
そこらのエンタープライズでは必要のない代物だから、スレ住人が見かけなくても当然だ。

x86系のCPUにビルトインされた機能では4～8CPUが上限で、しかも効率がいまひとつなのは、
その程度で十分な領域が主戦場だからだろう。

185:名無しさん＠お腹いっぱい。
08/04/18 19:25:37
>>184
> x86で大規模SMPマシンが作られてこなかったのは、単に、32ビットだったからだろう。

はあ？

186:名無しさん＠お腹いっぱい。
08/04/18 19:29:59
>>185
他の理由だというのなら、示してみ。

「はあ?」なんていうのは何も知らない幼稚園児でも言えるセリフだ。

187:名無しさん＠お腹いっぱい。
08/04/18 19:45:13
あんまり無知なんでびっくりしまして…

188:名無しさん＠お腹いっぱい。
08/04/18 19:46:32
はぁ

189:名無しさん＠お腹いっぱい。
08/04/18 19:48:16
ﾊｱ

190:名無しさん＠お腹いっぱい。
08/04/18 19:52:43
x86 がゴミだからだよ。SMP やったってまともに動かんの。
組込みにも使えないの。
MS-DOS 次元のバイナリ互換幻想のみでここまで持ってたわけ。
IA64 見て目をさませや。どこまでハダカで踊る気よ?

191:名無しさん＠お腹いっぱい。
08/04/18 20:09:48
それでも16から32コアぐらいまでは何とかなるんじゃないの

192:名無しさん＠お腹いっぱい。
08/04/18 20:13:02
SMP だと 8は無用の長物だったけど。せいぜい 4。

193:名無しさん＠お腹いっぱい。
08/04/18 20:20:15
だから戦場が違うと何度言えば

194:名無しさん＠お腹いっぱい。
08/04/18 20:20:50
じゃあ4コアのCPUが出てきたからx86は詰んだということか？

195:名無しさん＠お腹いっぱい。
08/04/18 20:55:17
ここのSun信者ってレベルが低すぎ。幼稚園児レベルの煽りと、ゴミ発言しかできない。

SPARCはかなりのシェアを、馬鹿にしまくったパソコン級のゴミCPUに、下から食われた。
それで、よっぽどパソコン級のCPUにコンプレックスを持ってる人がいるようだが。

ま、そろそろパソコンのCPUの性能向上は終わりだ。
膨大なユーザの需要に支えられて、ここまで来たが、
これ以上の性能向上を必要とするユーザは少ない。
何かキラーアプリケーションでも登場しない限り。
だから安心していい。

落ち着け、頭に血が上って幼稚な煽りはしなくていいのだ。

次ページ