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の性能向上は終わりだ。
膨大なユーザの需要に支えられて、ここまで来たが、
これ以上の性能向上を必要とするユーザは少ない。
何かキラーアプリケーションでも登場しない限り。
だから安心していい。
落ち着け、頭に血が上って幼稚な煽りはしなくていいのだ。
196:名無しさん＠お腹いっぱい。
08/04/18 20:59:47
Sunがしっかりしてれば、ラックマウントのx86サーバなんて商品は、成立しなかったはず。
インターネットのサーバでも、企業内のメールサーバでも、
Sunのワークステーションやサーバを使うのが常識だった時代があったんだ。
SPARCの性能向上を怠ったり、サーバの低廉モデルを出さなかったり、
SolarisやUnix技術者だけを相手にした商売やったり、そういうことの積み重ねで、
じわじわとx86に侵蝕されちまった。
197:名無しさん＠お腹いっぱい。
08/04/18 21:05:23
SPARCじゃないけれど、POWERなんかはどうなん？
198:名無しさん＠お腹いっぱい。
08/04/18 21:11:02
SPARCとPOWERでは畑が違うぞ。
たとえば、
日本で一般人向けのインターネットサービスが始まったころ、
WebサーバにPOWER使ってたサイトなんて滅多になかったろ。
IBMとSunでは商売が違うので同列には比較できない。
ぶっちゃけIBMはPOWERを持っていなくても同じ商売ができるだろう。
199:名無しさん＠お腹いっぱい。
08/04/18 21:14:03
建設業で言うなら、
IBM → 大手ゼネコン
Sun → 建築資材メーカー
200:名無しさん＠お腹いっぱい。
08/04/18 23:19:51
>>196
無茶言いすぎ
パソコン遊びに走ったSgiは結局IRIX OSすら捨てさせられたじゃないか
みながWindowsが動くものを欲しがってる時に
SPARCしか持ってなければどうするよ
201:名無しさん＠お腹いっぱい。
08/04/18 23:42:17
>>200
Windowsサーバよりも、
安く・管理しやすく・高性能なサーバをタイムリーに出してれば、
ここまでシェアを奪われることもなかっただろう。
何も好き好んでx86でLinuxや、なんとかBSDを使ったわけじゃない。
Sunよりも安上がりだから、しかたなく使ったんだ。
あるいは、WindowsNTのRISC版に、
MIPS、PowerPC、Alphaと一緒に
SPARCを並べてもらったら、よかったのかもしれない。
202:名無しさん＠お腹いっぱい。
08/04/18 23:52:15
LDOMS使っている人いる？
203:名無しさん＠お腹いっぱい。
08/04/18 23:53:08
そいやWABIなんてのがあったな。
204:名無しさん＠お腹いっぱい。
08/04/19 01:19:42
連中、12コアぐらいまでは増やすつもりでいるようだよ
これだけ足の速い商品、新しいもの売ってかないと会社が死ぬから
性能上がった振りしてコア倍増してくんだろうな
URLﾘﾝｸ(northwood.blog60.fc2.com)
205:名無しさん＠お腹いっぱい。
08/04/19 02:15:15
メモリアクセスがコアのローカルのキャッシュにヒットしていて、
なおかつ、コア間でキャッシュラインを共有していない状況に
なるように、使う側が配慮しているようなプログラムでは、
コアを増やせば、それなりに性能アップするだろう。
たとえばVMware ESXで、1コア1仮想マシンで使うとか。
206:名無しさん＠お腹いっぱい。
08/04/19 03:20:43
>>204
よだれたらしてうれしがって買うやつが大量にいるからな。Pen4 で証明されてる。
207:名無しさん＠お腹いっぱい。
08/04/19 03:31:12
実際、目的のアプリのパフォーマンスが上がって、
できなかったことが、できるようになるのなら買う
という人がいてもおかしくないぞ。
リアルタイムで何かを処理する場合、
たった1割の性能アップでも、
不可能を可能にすることがあるんだ。
208:名無しさん＠お腹いっぱい。
08/04/19 03:50:52
黒目がちですね。
209:名無しさん＠お腹いっぱい。
08/04/19 05:03:27
家庭用のビデオカメラがHDになった今、
HD解像度の動画をパソコンで編集して
MPEG4-AVCで圧縮しようと思ったら、
そりゃぁもう湯水のごとくプロセッサパワーが
必要になるわけで。
210:名無しさん＠お腹いっぱい。
08/04/19 15:11:37
それを担うのはハードウェアエンコードチップかもしれんし、GPUかもしれん。
211:名無しさん＠お腹いっぱい。
08/04/19 16:17:49
古い記事で申し訳ないがシンクライアント、かなり導入進んできてるんだね
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
212:名無しさん＠お腹いっぱい。
08/04/19 16:34:40
ハードウェア・エンコードチップやGPUは、
複数のコーデックのサポートや、バグ修正や機能向上、そして短期開発を考慮して、
マルチメディア命令を装備した汎用CPUに近づいてきてる。
富士通のFR-Vとかは汎用プロセッサに近い。
URLﾘﾝｸ(journal.mycom.co.jp)
こんな活用事例もある。
213:名無しさん＠お腹いっぱい。
08/04/19 17:35:38
FR-Vなんてもう作ってないだろ？
214:名無しさん＠お腹いっぱい。
08/04/19 17:50:52
>>213
知ったか乙
215:名無しさん＠お腹いっぱい。
08/04/19 18:12:43
電デバの人？
まだ作ってんだ
216:名無しさん＠お腹いっぱい。
08/04/19 22:00:19
メディアプロセッサと呼んじゃうと死亡フラグだ
実装は汎用コアでも、あくまでハードウェアエンコーダであるべき
217:名無しさん＠お腹いっぱい。
08/04/21 11:19:47
>>212
汎用プロセッサの使い方に「近い」ってのは、実際命令セット維持しなきゃならない
こととはまた違うし。
218:名無しさん＠お腹いっぱい。
08/04/21 15:06:07
だがしかし、専用ハードウェアが必要だったことが、
プロセッサの性能向上と特殊命令の実装により、
1つ、また1つと、ソフトウェアで可能になってる。
電力効率が悪いものの自由度は大切だ。
219:名無しさん＠お腹いっぱい。
08/04/21 18:31:02
つまり、x86 の行き詰まりは間近。IA64 当初に Intel が予言した通り。
220:名無しさん＠お腹いっぱい。
08/04/21 18:38:18
x86というか、パソコンのCPUの行き詰まりな。
ワープロ・表計算・Webブラウザなどを使うだけという、
用途が停滞すれば、
x86だろうとSPARCだろうと、性能向上が必要なくなり、行き詰まる。
パソコンだけでなくサーバーも同じで、
やることが同じなら、コンパクトにする方向に進み、つまり、売上減となる。
221:名無しさん＠お腹いっぱい。
08/04/21 21:54:08
サーバは集約の要求があるから、電力性能比を上げれば上げるほど売れる。
222:名無しさん＠お腹いっぱい。
08/04/21 22:44:53
保守契約が切れる度に、どんどんラックの本数が減っていく。
これ、ヤバいと思うよ。
223:名無しさん＠お腹いっぱい。
08/04/21 22:57:14
そりゃ仕事が増えない会社はヤバイわな
224:名無しさん＠お腹いっぱい。
08/04/21 22:59:25
SUNの入ったラックという意味だろう、JK
225:名無しさん＠お腹いっぱい。
08/04/22 09:36:43
>>222
それをヤバいと思う連中は、マジやばいだろなwww
商機と思えなければ、消え去るのみだ。
226:名無しさん＠お腹いっぱい。
08/04/22 10:19:50
x86のコアが増えていけば、Sun Rayサーバとしては
便利に使えそうだがどうだろ
227:名無しさん＠お腹いっぱい。
08/04/22 10:43:05
コアの増えた x86 が有用ならもうとっくに市場に出回ってるよ。
なんべん書かすん?
228:名無しさん＠お腹いっぱい。
08/04/22 11:59:04
>>227
すでに4コア製品が出まわってますが?
ダイ面積と歩留まりの関係から、そう簡単に8コアにはできん。
どんなに有用でも、4コアx2CPUよりもトータルで高く付くなら、
製品として成りたたない。
これでも理解できない小学生には、こう言えばいいかな。
Rockが有用ならもうとっくに市場に出まわってるよ。
あるいは
コアを更に増やしたUltraSPARC T2+が有用ならもうとっくに市場に出まわってるよ。
229:名無しさん＠お腹いっぱい。
08/04/22 13:12:42
Rock有用なので8コアでいいからさっさと発売してくれ。
てか16コア250Wは、無理だろう。空冷的に考えて。
230:名無しさん＠お腹いっぱい。
08/04/22 13:13:49
カタログに載ってるだけだったら、別に
いくら熱くなろうが問題はない。
231:名無しさん＠お腹いっぱい。
08/04/22 13:50:10
MSのSQL Serverが7.0の頃、
SQL Serverじゃ将来スケールアップできない
と言われると、
大丈夫です、Itaniumがありますから
といって客を納得させてた。
そういう将来の心配をする客って、
急激な規模拡大はしないんだよね。
Itaniumはカタログにあるだけで十分に役に立った。
急激に規模拡大する場合は、
短い期間で開発してはシステム更新を繰り返すので、
SQL ServerでダメとなったらOracleに変えればいいだけで、
別にどーってことないんだわ。
232:名無しさん＠お腹いっぱい。
08/04/22 15:49:56
>>228
4コアとそれ以上の区別がつかんアホがコアの数や SMP の何を語ろうがムダだ。
それ以前にこんなとこには用はねーだろ? 来るなゴミ!
> Rockが有用ならもうとっくに市場に出まわってるよ。
Sun は x86屋みたいに CPU 開発に金かけれないの。そんなことさえ踏まえずに
垂れ流してんのか消えろや。失せろ。
233:名無しさん＠お腹いっぱい。
08/04/22 15:51:26
>>231
> Itaniumはカタログにあるだけで十分に役に立った。
なるほど。じゃあまた別の考え出してカタログ作りゃいいじゃん。
234:名無しさん＠お腹いっぱい。
08/04/22 16:11:11
>>232
幼稚園児並の煽りしかできないのか?
> Sun は x86屋みたいに CPU 開発に金かけれないの。
インテルと同じだけの開発費を使っても、
ダイサイズや消費電力が大きすぎてムリなんだが。
235:名無しさん＠お腹いっぱい。
08/04/22 16:12:27
>>233
暗にSunのRockのことを揶揄してるんだろ。
236:名無しさん＠お腹いっぱい。
08/04/22 19:05:26
>>234
お前の知識は XDBus や MBus 以前なんだよ。1990年代初頭なんだよ。
わかったら勉強しとけ。来んなゴミまくな。私物化すんじゃない!!!!!
237:名無しさん＠お腹いっぱい。
08/04/22 19:29:15
>>236
とうとう赤ん坊並の喚きよう。
238:名無しさん＠お腹いっぱい。
08/04/22 19:49:54
>>237
234はXDBusやMBusを知っている歴戦の勇者。それが見抜けぬようでは。
昔のSunは良く落ちたよねぇ。
>>236
SBus以前だったりして
239:名無しさん＠お腹いっぱい。
08/04/22 19:51:06
一人二役ですかwww
240:名無しさん＠お腹いっぱい。
08/04/22 20:59:20
スクールバスとマイクロバスか、なにもかも懐かしい…
241:名無しさん＠お腹いっぱい。
08/04/22 21:20:25
トリビア
Sunの最初のワークステーションのバスはインテルだった。
242:名無しさん＠お腹いっぱい。
08/04/22 22:57:01
>>241
その頃はCPUもMotorolaの68000で、まだCPUの自社開発はしてないな。
243:名無しさん＠お腹いっぱい。
08/04/22 23:10:57
はあ。そうだと x86 のメニーコアができるのかよ。アホか。寝言もたいがいにしてくれ。付き合いきれんわ。
244:名無しさん＠お腹いっぱい。
08/04/22 23:32:07
>>243
何言ってんだ?
どっから電波を受信してるんだ?
245:名無しさん＠お腹いっぱい。
08/04/22 23:32:24
誰も言ってないことが見える>>243は病気だと思います。
246:名無しさん＠お腹いっぱい。
08/04/22 23:33:49
SUNを否定されると、己れのアイデンティティーが否定される
からそっとしておいてあげて。
247:名無しさん＠お腹いっぱい。
08/04/23 00:32:14
x86サーバはデュアルコア以上のものしか売っていない
Sun Fireはデュアルコア以上となると\500万を超えるものしか売っていない
248:名無しさん＠お腹いっぱい。
08/04/23 01:20:25
>>247
Sun Fire T1000とSun Fire T2000
SPARC EnterpriseもありならT5000シリーズも
V490の一番しょぼい構成のやつも500万切ってるね
SPARC Ⅳだから今から買うやつはほとんどいないだろうけど
249:名無しさん＠お腹いっぱい。
08/04/23 11:19:49
はぁ。低次元な上に、つまらなさ過ぎなんだよな... ほんとに相手する気が起きんのだが。
も少しヒネれよ。さらし場じゃねーての。
250:名無しさん＠お腹いっぱい。
08/04/23 14:52:14
>>249
相手する気が起きないと言いつつも、幼稚園児なみの発言を繰り返す
どういうこと?
251:名無しさん＠お腹いっぱい。
08/04/23 20:59:22
>>249
一番スレを荒らしてるように見えるんだけど。
しばらく書き込まないでいれば、平和なスレに戻るんじゃね？
252:名無しさん＠お腹いっぱい。
08/04/24 12:48:58
URLﾘﾝｸ(pc.watch.impress.co.jp)
> 4命令を実行するより、4命令をデコードする方が難しいだろう
x86がILPで躓いてるのにお前らもTLPか。
RISCなら8命令同時実行ぐらい可能なんじゃね?
コア間で実行ユニット共有して、ILPとTLPを同時に追求とかできんの?
253:名無しさん＠お腹いっぱい。
08/04/24 15:56:03
Intel が Am29000 64bit 拡張したのでも出せば面白いかもな。
x86 64bit化のクロス攻撃でw
254:名無しさん＠お腹いっぱい。
08/04/24 16:11:07
x86って以前は6命令同時実行じゃなかったか?
255:名無しさん＠お腹いっぱい。
08/04/24 16:13:53
これだけペナルティを背負ってるx86に、下からシェアを侵蝕されたSPARCって、どんだけ・・・
256:名無しさん＠お腹いっぱい。
08/04/24 16:53:11
>>252
> RISCなら8命令同時実行ぐらい可能なんじゃね?
残念、意味がないようだ。
URLﾘﾝｸ(www.watch.impress.co.jp)
> 5命令/サイクル以上は難しい。
> IPCが上がらなくなる原因のひとつは、ILPにしても、ひとつのインストラク
> ションフロー(プログラム中の命令の流れ)の中で命令スケジューリングをす
> る点は変わらないからだ。そのため、データのディペンデンシが壁となって
> どうしてもIPCをある程度以上は上げられない。
> コア間で実行ユニット共有して、ILPとTLPを同時に追求とかできんの?
Alphaはそれを目指していたようだ。
> EV8のSMTでは，CPUは仮想的に4つの「TPU(Thread Processing Unit)」を持
> ち、それぞれが異なるスレッドを並列に実行する。各TPUは、それぞれ個別
> のプログラムカウンタとレジスタマップを持つが、実行ユニットや物理レジ
> スタといったCPUのハードウェアリソースのほとんどは各TPUで共有される。
257:名無しさん＠お腹いっぱい。
08/04/24 19:41:24
そこで出来たのがItaniumですよ
258:名無しさん＠お腹いっぱい。
08/04/24 19:57:28
> コア間で実行ユニット共有して、ILPとTLPを同時に追求とかできんの?
それがNiagaraシリーズだろ。
259:名無しさん＠お腹いっぱい。
08/04/24 20:07:02
Out of orderすらないNiagaraのどこにILP追求があるのかと小一時間
260:名無しさん＠お腹いっぱい。
08/04/24 23:09:53
Niagaraはぎったんばったん方式。
261:名無しさん＠お腹いっぱい。
08/04/25 12:05:00
>>255
そのペナルティを厚塗りしてカバーするためにどれだけのリソースが無駄に
投入されてるかよく考えるべきなんだよ。地球温暖化なんかよりはるかに
深刻な問題。
262:名無しさん＠お腹いっぱい。
08/04/25 20:29:58
誰の問題なんだよ w
263:名無しさん＠お腹いっぱい。
08/04/26 00:01:28
Update: Sun confirms it's buying Montalvo
URLﾘﾝｸ(www.news.com)
結局買収したみたい
264:名無しさん＠お腹いっぱい。
08/04/26 11:51:24
Jupiter Processor (SPARC64-VII) for Sun SPARC Enterprise M-Class Servers
URLﾘﾝｸ(blogs.sun.com)
SPARC64VIIまだー？
265:名無しさん＠お腹いっぱい。
08/04/26 13:14:02
富士通の期待
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
> 消息筋は「沈みかかっている船から降りるのが技術者たちの常。サンに
> Rockを開発できる力が残っているかどうか疑問だ」と見ており、サンが今後、
> 大型サーバーの開発製造を富士通に委託し、ソフトに投資を振り向ける可能
> 性が強いと見ている。
現実
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
> Rockはサンの現行最上位である「UltraSPARC IV+」の16倍という桁外れの性
> 能が見込まれるため、仮に富士通SPARC64 VIIIや同IXがあったとしても敵わ
> ない。APL（SPARC Enterprise）は、Rock登場後数年を待たずに命運が尽き
> る。Jupiter後の富士通は、APL提携時の約束に従いRockを売ることになるは
> ずである。
そして伝説へ…
URLﾘﾝｸ(mainichi.jp)
> 富士通が半導体事業を分社化し先月設立したばかりの「富士通マイクロエレ
> クトロニクス」で、社長がいきなり交代するという異例の事態になっている。
266:名無しさん＠お腹いっぱい。
08/04/26 14:34:26
SPARC にせよ Efficeon にせよ、やるんならもっときっちり力入れりゃいいのに、
中途半端な感じだよねぇ。なんで Itanium なんかやってんだか...
オレはてっきりブラフだと思ってたんだけど、マジだったとは。あきれた。
やっぱその辺ちゃんと分ってる人達が F社内で少数派なんだろうな。
上も理解できてないし。
267:名無しさん＠お腹いっぱい。
08/04/26 15:02:15
その文脈でEfficeonが出てくる理由がわからない
トランスメタ会社ごと買っちゃえば良かったとかそういう話か？
268:名無しさん＠お腹いっぱい。
08/04/26 15:11:31
そういう意味じゃ>>263のMontalvoも富士通のプロセス使ってたらしいけどな
269:名無しさん＠お腹いっぱい。
08/04/26 23:16:31
>>261
それほどのリソースを無駄に投入しているということは、それだけ、原価が高いということだろ。
それにも負けるSPARCアーキテクチャって、実は、大したことないんじゃないか?
270:名無しさん＠お腹いっぱい。
08/04/27 00:08:15
SPARCに優位性があるなんて考えてる奴は誰もおらんよ。
アーキティクチャもISAも、CPUの興亡とはまるで関係がない。
271:名無しさん＠お腹いっぱい。
08/04/27 03:01:31
>>269
それぐらい競争力に差がついてしまってるということ。
その原因が「MS-DOS 資産の継承」というとてつもない幻想が根本にあるということ。
272:名無しさん＠お腹いっぱい。
08/04/27 03:05:15
>>270
それは単に Intel の言い分。ISA が x86 以外なら現存のどれにしても、
大きなメリットがある。x86 じゃいつまで経ってもトランジスタ数は多いし、
プロセス世代あたりじゃ性能よくない。
273:名無しさん＠お腹いっぱい。
08/04/27 03:49:46
>>272
SuperSPARCあたりから言われていたSunの設計が糞！ってことですよねｗ
274:名無しさん＠お腹いっぱい。
08/04/27 16:26:05
SPARCじゃいつまで経っても……
まあPowerも苦しいし、ニッチから出られないのは
Sunに限った話ではないけれど。
275:名無しさん＠お腹いっぱい。
08/04/28 00:33:40
>>269
どんだけ馬鹿なんだ
SPARCは確かに大した事ないが根拠が馬鹿すぎるw
276:名無しさん＠お腹いっぱい。
08/04/28 01:22:31
Amazon EC2に採用されるぐらいのインパクトが欲しいねえ。
277:名無しさん＠お腹いっぱい。
08/04/28 07:10:54
x86Solarisが出てきた時点で、もうおわった
278:名無しさん＠お腹いっぱい。
08/04/28 09:24:46
ずいぶん昔に終わってたことになるが
279:名無しさん＠お腹いっぱい。
08/04/28 10:32:14
でしょ
280:名無しさん＠お腹いっぱい。
08/04/28 21:13:29
Alpha版のWindowsNTで、FX!32とか使う
なんていう選択肢も昔はあったんだぞ。
なぜSPARCは同じアプローチをせず、
WABIとか、裁判とかやってたんだ?
281:名無しさん＠お腹いっぱい。
08/04/28 22:25:41
x86のソフトエミュレーションに手出したとこはみんな潰れてるじゃんよ……
282:名無しさん＠お腹いっぱい。
08/04/28 23:56:04
最終的には Intel 自身が同じテツを踏んだね。まったくもってギャグ。呪いの類いだなww
283:名無しさん＠お腹いっぱい。
08/04/28 23:57:37
>>277
Niagara 以降、UltraSPARC IV+ までばんばん売れちゃってるのに、何が終わりなんだ?
あ、x86 のダメさ加減が証明されて x86 が終了? まあ、Intel もそう言ってたしそうかもねw
284:名無しさん＠お腹いっぱい。
08/04/29 00:02:49
あいかわらず病的だのう
285:名無しさん＠お腹いっぱい。
08/04/29 00:35:25
しかも、必死すぎで笑えるよな
286:名無しさん＠お腹いっぱい。
08/04/29 00:59:52
ローエンドもSPARCを売ってくりゃれ
287:名無しさん＠お腹いっぱい。
08/04/29 04:56:57
>>281
SunはWABIで手を出したけど潰れてないじゃん。
>>283
ローエンドからx86にシェアをかなり奪われた後で、
少し挽回したくらいで「ばんばん売れちゃってる」と言われてもな。
昔はTCP/IPを喋るサーバはSunを使うのが常識だったわけで、
そのシェアを維持してx86の下からの侵攻を防いでいたら、
世界中のWebサーバはSunでSolarisだっただろう。
288:名無しさん＠お腹いっぱい。
08/04/29 05:21:28
x86の下から侵攻を防ぎたくても、SuperSPARCの性能と価格じゃ無理だったんです＞＜
289:名無しさん＠お腹いっぱい。
08/04/29 05:32:12
なんで性能が低かったの?
なんで価格が高かったの?
複雑怪奇なx86よりも遥かに有利なハズなのに。
290:名無しさん＠お腹いっぱい。
08/04/29 06:26:01
DECのAlphaは速かった。
SunのSPARCは遅かった。
買収されなければAlphaは今も生き続けていただろう。
291:名無しさん＠お腹いっぱい。
08/04/29 11:15:36
Sunの詣って、かなりIntelに粘着するよなw
292:名無しさん＠お腹いっぱい。
08/04/29 11:18:35
詣？
293:名無しさん＠お腹いっぱい。
08/04/29 12:08:51
儲(もうけ)と入力しようとして詣(もうで)としてしまったに一票
294:名無しさん＠お腹いっぱい。
08/04/29 14:02:19
x86より遥かに有利なハズのプロセッサがいくつ現われては消えたことか
295:名無しさん＠お腹いっぱい。
08/04/29 15:18:12
アーキティクチャによる利といっても、パフォーマンスで1.5倍分くらい(超適当)が限度なんだろう。
それは規模の経済による設計・生産面での不利で簡単に覆されてしまう。
逆に言えば、x86より数が出ないのに喰らいつけていける程度には優秀なアーキティクチャ
なのだ。
296:名無しさん＠お腹いっぱい。
08/04/29 19:32:05
x86はWindowsアプリ大量に抱えてるからな
それに今、PCでCPUパワーを大量に消費するソフトを言えば
ゲームや動画関連、画像処理、音楽などのマルチメディア系
それ以外はCPUパワーあまりまくり
性能よりも過去の資産の方が重要な時代
それにIntelのx86は製造プロセスで優位に立っているので消費電力の面でも優秀
297:名無しさん＠お腹いっぱい。
08/04/29 21:58:43
SunOSマシンがx86にシェアを食われはじめた頃のx86って、
インテル、AMD、Cyrix(IBM、SGSトムソン)、IDT、TI、UMC、NexGen(IBM)
けっこうな数のメーカーが参入してたと思う。
298:名無しさん＠お腹いっぱい。
08/04/29 22:01:24
>>295
CPUを単体売りせず、
CPUとは桁違いの価格のサーバやワークステーション、そしてOSと抱き合わせで売るから、
存続してるんだろ。
299:名無しさん＠お腹いっぱい。
08/04/29 22:04:06
壊れたら箱ごと交換して、直前のバックアップまで戻る
それでも構わないようなWebサーバに使うには、
Sunのワークステーションは高価すぎた。1桁高かった。
300:名無しさん＠お腹いっぱい。
08/04/30 00:05:57
しかも高くてもいいから壊れちゃいけない用途にはイマイチで……
SPARCの優劣をどうこういう以前の話ですな
301:名無しさん＠お腹いっぱい。
08/04/30 01:34:24
このところスレが盛り上がってるみたいなので、ちょっとお願いしておきますが
「次スレのタイトル候補」は早めに決めて置いて下さいね。
毎度ギリギリになってからとっさに考えて立てるのも結構大変なんですw
302:名無しさん＠お腹いっぱい。
08/04/30 04:12:25
Rockが出れば、
最大の電力
なんだがなぁ。
303:名無しさん＠お腹いっぱい。
08/04/30 05:39:35
高くてトロいといえばSuperSPARCよりmicroSPARCだろう。
あれこそx86とぶつかるべき位置だったと思うがあまりにクソだった。
TSUNAMIのように押し寄せるつもりが逆に押し流されたな。
304:名無しさん＠お腹いっぱい。
08/04/30 05:55:10
>>299
SS5の安いのは実売50万くらいだったろ。
HDDに貧相な冷却ファンしか付いてなくて、
サーバとして使うのは心配な代物だったが。
305:名無しさん＠お腹いっぱい。
08/04/30 06:21:43
x86とぶつかる位置は、やっぱりSuperSPARCでしょ
microSPARCはぶつかる前にこけてる感じｗ
306:名無しさん＠お腹いっぱい。
08/04/30 06:39:22
>>305
LX/classicの登場時期にSuperSPARCはかなり高価だったから、
ちょっと違うように思ったんだが？
307:名無しさん＠お腹いっぱい。
08/04/30 06:52:16
その高価なSuperSPARCのとき、x86はPentiumで追いつけ追い越せだったでしょ
価格だけが着目点なら話がかみ合わないね
308:名無しさん＠お腹いっぱい。
08/04/30 07:07:14
>>296
> 性能よりも過去の資産の方が重要な時代
それはSunとSPARCにも言えることなんだが。
人はSPARCを使いたくてSunのワークステーションを買ったのではない。
SunOS あるいは Solaris を使いたくてSunのワークステーションを買ったんだ。
309:名無しさん＠お腹いっぱい。
08/04/30 12:03:01
SPARC T2にマルチプロセッサが登場したということは、
64スレッドあっても1個じゃバスもI/Oも飽和せんの?
310:名無しさん＠お腹いっぱい。
08/04/30 15:00:09
主記憶アクセスが飽和した結果があの構成。
311:名無しさん＠お腹いっぱい。
08/04/30 15:01:20
>>296
製造プロセスの面「のみ」優位。あとは非互換の恐怖。宗教。
312:名無しさん＠お腹いっぱい。
08/04/30 15:12:06
バイナリ互換はSPARCの特徴の1つ。
313:名無しさん＠お腹いっぱい。
08/05/01 00:39:39
>>309
T2のメモリ帯域はかなり広い。
でも電力効率を追求してるのにFB-DIMMってちぐはぐだよな。
314:名無しさん＠お腹いっぱい。
08/05/01 13:39:53
>>313
スレで既出だが、T2は設計ミスで倍の帯域幅を持ってる。
315:名無しさん＠お腹いっぱい。
08/05/02 12:01:32
別に設計ミスじゃないよなあ。
チップ間インターコネクトの分の帯域を
メモリアクセス増強に流用しちゃいけないなんて法はない。
コアあたりのメモリ帯域が重要ならシングルT2、
コア数が必要ならデュアルT2 plusってことでいいじゃん。
316:名無しさん＠お腹いっぱい。
08/05/02 13:13:31
URLﾘﾝｸ(pc.watch.impress.co.jp)
> 1GHz駆動のMIPS64コアが16個搭載されたOCTEON Plusなども昨年発表されて
> おり、このあたりは確実にUltraSPARC T2の性能を超えていると思われる
こんなこと言ってますぜダンナ
317:名無しさん＠お腹いっぱい。
08/05/02 14:22:56
SGI がマシン作って IRIX が載ってる、てんならちょっと興味あるけど。違うよね。
特定用途向けでしょ? T2 は汎用だし。
318:名無しさん＠お腹いっぱい。
08/05/02 14:57:07
Sunが減収・赤字転落、米経済の減速が影響
URLﾘﾝｸ(www.itmedia.co.jp)
319:名無しさん＠お腹いっぱい。
08/05/02 15:36:41
>>316
その記事の、Sunのところの写真いちばん右、普通のサーバのメインボードじゃないか。
320:名無しさん＠お腹いっぱい。
08/05/02 15:45:51
>>317
SunはNiagaraシリーズを、組込み向けに外販してんのよ。
その分野で、おもいっきり競合してるし、
MIPSの実績に比べればSPARCの実績なんて、ないに等しい。
321:名無しさん＠お腹いっぱい。
08/05/02 16:59:17
ああ、そう。
まあ LEON がんばってるし NAS で。あとは OpenSPARC 待ちだな。
そんなとこ具体的な製品で Sun ががんばる必要ないし。
つまんねーネタw
322:名無しさん＠お腹いっぱい。
08/05/02 17:05:21
>>321は頭悪い信者? そういう反応するから馬鹿にされるのに。
323:名無しさん＠お腹いっぱい。
08/05/02 17:18:55
え? >>320 が ＝＝＝＝バカ＝＝＝＝ なんだけど。
324:名無しさん＠お腹いっぱい。
08/05/02 17:19:53
まあ、>>322 も『『寒い自演』』、だけどさwwwww
325:名無しさん＠お腹いっぱい。
08/05/02 17:31:23
>>317は 組込みのことを特定用途向け、ふつうのUnix鯖を汎用と言ってるようだな。
326:名無しさん＠お腹いっぱい。
08/05/02 17:40:34
>>321
> まあ LEON がんばってるし NAS で。
家庭用のDVDレコーダに積まれて大量に出てるMIPSとは桁違いに小さい市場だな。
327:名無しさん＠お腹いっぱい。
08/05/02 18:29:21
DVDレコの2/3はMIPSらしいな。
328:名無しさん＠お腹いっぱい。
08/05/02 19:12:57
うーん、何をいまさら... MIPS が大量に出てるのってもう何年も前からだけど。
てか、なんかこれあおってるつもりなのか幼稚だなさすが GWwwwwwww
329:名無しさん＠お腹いっぱい。
08/05/02 19:17:46
そういうの書くなら、最近の SunRay が Alchemy だとかさ。
サーバー機の管理プロセッサ（LOM だっけ?）が PowerPC だとか。
まあ低脳だなww
330:名無しさん＠お腹いっぱい。
08/05/02 19:18:40
ああ、Alchemy って MIPS な。べんきょーしろよーーw
331:名無しさん＠お腹いっぱい。
08/05/02 22:14:07
サン、第3四半期で赤字転落--人員削減を計画
URLﾘﾝｸ(japan.cnet.com)
332:名無しさん＠お腹いっぱい。
08/05/02 22:20:48
信者も大変だねぇ
333:名無しさん＠お腹いっぱい。
08/05/03 00:04:11
>>331
Sunって人員削減のニュースが多い気がするんだけど、こまごまと買収している内に無駄に
人員が増えていくから時々削減するのというサイクルなのか？
334:名無しさん＠お腹いっぱい。
08/05/03 05:10:26
>>328
煽られてると思うほうが、オカシイ。
煽りではなくてただのツッコミだし。
>>329-330
知らないと思ってるのは、お前だけだろ。
335:名無しさん＠お腹いっぱい。
08/05/03 05:12:18
>>333
あっちの国では、赤字決算とともに人員削減計画を発表するのが、ビジネスマナー。
人員削減計画を発表しないと株主が怒りだす。
336:名無しさん＠お腹いっぱい。
08/05/03 09:14:13
基本給15％カットのIBM従業員、株主総会で抗議デモを計画
URLﾘﾝｸ(www.itmedia.co.jp)
337:名無しさん＠お腹いっぱい。
08/05/03 20:10:12
わろたw、株価かなりさげてんのなw
計算してみたら、15%くらいさげてるw
Sunおわた
338:名無しさん＠お腹いっぱい。
08/05/04 00:59:04
>>334
へ～ぇ。あおってさえ、ないわけ? 何それwwww 「晒し」?
339:名無しさん＠お腹いっぱい。
08/05/04 06:39:26
>>338
そういう考え方をする時点で、イカレ信者だろうな。
340:名無しさん＠お腹いっぱい。
08/05/05 00:50:11
アンチなら少しは面白いことでも書けよカス
341:名無しさん＠お腹いっぱい。
08/05/05 04:10:42
アンチにネタ振りを求めるなんて、どんだけ終わってるんだ?
342:名無しさん＠お腹いっぱい。
08/05/05 23:58:17
おまえ... 絞りカスみたいなやつだなww
ネタも出ないのにアンチやってんのかww ププププp
343:名無しさん＠お腹いっぱい。
08/05/06 05:50:36
図星らしい。
344:名無しさん＠お腹いっぱい。
08/05/06 18:27:56
でもさ、1CPU～2CPUのUNIXサーバの中じゃ、Sunが一番まともだろ？
Oracle EEのライセンス的には不利だけどさ。
Oracle SE One、SEだと無敵だ。
345:名無しさん＠お腹いっぱい。
08/05/06 20:02:40
1CPU～2CPUならPCサーバで十分
346:名無しさん＠お腹いっぱい。
08/05/07 20:20:46
>>345
それ禁句。
347:名無しさん＠お腹いっぱい。
08/05/07 20:48:23
あんたには Intel で十分。
スレも隔離されたので十分。
ここに来たら邪魔ww
348:名無しさん＠お腹いっぱい。
08/05/07 21:04:03
>>347
そういうこと言ってるから、どんどんシェアを失うわけですよ。
349:名無しさん＠お腹いっぱい。
08/05/08 00:17:21
>>344
どこらへんがまとも？
350:名無しさん＠お腹いっぱい。
08/05/08 01:00:07
>>347
核心を突かれて悔しいんですね (^_^)
351:名無しさん＠お腹いっぱい。
08/05/08 10:16:31
>>348
シェアに日和る人間なんか気にしても仕方がないわけでww
352:名無しさん＠お腹いっぱい。
08/05/08 10:17:12
>>350
はぁ。連投見苦しいですが。プ。
353:名無しさん＠お腹いっぱい。
08/05/08 10:53:27
どーみても連投してるのは>>351、>>352だな。
354:名無しさん＠お腹いっぱい。
08/05/08 11:13:51
うんうん
355:名無しさん＠お腹いっぱい。
08/05/08 11:19:35
intelへのねたみがはじまって
Sunおたわ
356:名無しさん＠お腹いっぱい。
08/05/08 12:42:59
Sunがかつて(比較的)低価格なワークステーションを投入して大型コンピュータ市場を食って
言ったのと同じように、今ではSunの市場がPCに食われるのは歴史の必然。盛者必衰の理。
問題は、そのPCの後に再び返り咲けるかどうかで、PCも携帯端末やシンクライアントなどに
食われて先細ると反対にサーバーの役割が巨大化してSPARCの存在価値も高まるだろう。
今こそSPARCを維持しつづければ「レコード針を作りつづける最後の一社」のように独占的な
地位に立てるチャンスがあると思う。
357:名無しさん＠お腹いっぱい。
08/05/08 12:50:35
SPARCは手段にすぎない。
手段が目的になるのは信者。
シンクライアントのサーバなんて、巨大SMPマシンでやる必要はないので、
それこそ、安価なx86サーバを並べて適当に負荷分散させりゃあいい。
これから重要なのはプロセッサではなくストレージのシステムだ。
358:名無しさん＠お腹いっぱい。
08/05/08 13:14:48
まあ、紋切りじゃないと理解できない人間は多いが、それを利用するやつは
どうにもいただんけんね。クズかと。
359:名無しさん＠お腹いっぱい。
08/05/08 13:44:29
しかも興味引くようなアオリもできん低能だしww
360:名無しさん＠お腹いっぱい。
08/05/08 13:54:07
>>359はカマッテチャンなので放置よろ
361:名無しさん＠お腹いっぱい。
08/05/08 15:58:31
よくいうよwwww おまえだろうがp
362:名無しさん＠お腹いっぱい。
08/05/08 16:11:05
シュワルツCEOの比較的最近のコメント
URLﾘﾝｸ(www.itmedia.co.jp)
「水平的に拡張するものはすべて、いずれ垂直的に拡張する」
うまくいくといいなと思うのですよ
363:名無しさん＠お腹いっぱい。
08/05/08 16:32:05
進路の方向性はあってると思うよ。
うまくいかないとしたら、それはSunの頑張りが足りないのだよ。
いまのSunに足りないピースは、Googleが活用しているような、
コモディティクラスのCoolThreadsサーバだ。
364:名無しさん＠お腹いっぱい。
08/05/08 16:34:21
リスは元気かなぁ..
365:名無しさん＠お腹いっぱい。
08/05/08 16:44:09
>>361はカマッテチャンなので黙ることをしません
366:名無しさん＠お腹いっぱい。
08/05/08 16:47:26
>>362
> Sunの8コアのUltraSPARC T1およびT2プロセッサを4ウェイプラットフォーム上で動作させれば
T1の4ソケット対応版なんて開発予定にないだろｺﾞﾙｧ。
367:名無しさん＠お腹いっぱい。
08/05/08 16:55:39
だから少しはヒネれよ低能www 存在意義ねぇだろがこのバカwpwpwpw
368:名無しさん＠お腹いっぱい。
08/05/08 16:58:01
Sunに必要なのは、SunおよびSPARCに極めて有利な応用を開発することだ。
同じことをx86でやると10倍のコストがかかってしまうような、そういうもの。
Sunはプロセッサの開発までやっているのだから、それを生かさないとね。
369:名無しさん＠お腹いっぱい。
08/05/08 16:58:35
4wayにコア増やすのはいいが、スレッドが256とか512とかあったら
先にI/Oかバスが飽和しないか?
T2の場合、足すべきなのはコアじゃないんじゃないか?
370:名無しさん＠お腹いっぱい。
08/05/08 16:58:39
>>367は頭に血がのぼっている文しか書けないのか。
371:名無しさん＠お腹いっぱい。
08/05/08 17:03:24
>>369
T2の場合、メモリバスやI/Oバスはプロセッサの数に比例して増えるので、飽和しない。
ソフトウェア的にも、Solarisは馬鹿ではないので、いくらスレッドがあっても
適切にディスクI/Oを処理するのでネックにはならないだろう。
LinuxやWindowsのようなスケールしないファイルシステムとは、わけがちがう。
372:名無しさん＠お腹いっぱい。
08/05/08 17:04:48
>>369
メモリアクセスが飽和した結果があの構成。何度書かすか..
>>368
まさにそれが SMP、MT。まあ、時間の問題。
373:名無しさん＠お腹いっぱい。
08/05/08 17:06:23
>>370
おもしろいこと書けないんなら出てこなくていいから。じゃまだから。
374:名無しさん＠お腹いっぱい。
08/05/08 17:16:20
何度もかかせて悪いが、あの構成とはどの構成のことを言っている?
375:名無しさん＠お腹いっぱい。
08/05/08 17:20:55
>>373がそうやって構うから、カマッテチャンは図に乗ってるんじゃないか?
376:名無しさん＠お腹いっぱい。
08/05/08 17:25:33
>>372
> まさにそれが SMP、MT。まあ、時間の問題。
それは応用ではなく、実装だろ。
しかも、x86に対して桁違いの低コストを実現してないし。
377:名無しさん＠お腹いっぱい。
08/05/08 17:36:00
SUN2の時代から生きてれば、そりゃ時間の問題だ罠
378:名無しさん＠お腹いっぱい。
08/05/08 17:51:41
OS、プロセッサ、サーバ箱、ストレージ
この4つをすべて自社で揃えておきながら、
それぞれが他社の競合品と似ていたり、
ボリュームゾーンにDELLなんかの土俵入りを
許してしまっているんだから、情けない。
379:名無しさん＠お腹いっぱい。
08/05/08 18:11:51
アンディがデザインしてるとこはそうじゃないけどな。
380:名無しさん＠お腹いっぱい。
08/05/08 18:48:28
上から下まで作っていることの利点を生かしきれてない希ガス。
381:名無しさん＠お腹いっぱい。
08/05/08 21:54:31
SUNはもともと規制の部品を組み合わせて
低価格なワークステーションを作ってたメーカー
原点に立ち返ってx86に力を入れるべきなんだよ
ただ、パソコン市場は既に終わってるからPCサーバとx86 Solarisに力を注ぐべき
x86 Solarisも中小企業のような専任のシステム担当者不在の状態でも
簡単に使えるように改良すべき
382:名無しさん＠お腹いっぱい。
08/05/08 21:55:13
変換ミス
×規制
○既成
383:名無しさん＠お腹いっぱい。
08/05/08 22:07:26
部品だったら既成じゃなくて既製じゃね？
384:名無しさん＠お腹いっぱい。
08/05/08 22:18:47
>>381
だから、x86のワークステーションやサーバを出してるじゃないか。
筐体デザインを気に入ってSunのx86ワークステーションを買って、
普通にWindowsで使っているような連中もいるぞ。
385:名無しさん＠お腹いっぱい。
08/05/08 22:28:58
URLﾘﾝｸ(www.atmarkit.co.jp)
ソフトの値札で許されるのは「無料」だけ、シュワルツCEO
386:名無しさん＠お腹いっぱい。
08/05/09 00:06:20
Xeonと比較すりゃ、どのUNIXサーバも負けるだろ。
比較するなら、IBM PowerやHP Itaniumと比較しれ。
387:名無しさん＠お腹いっぱい。
08/05/09 01:41:23
SDC障害から回復せんな。
時間かけすぎじゃないか。
388:名無しさん＠お腹いっぱい。
08/05/09 04:43:37
おいらがSunに望むこと
ランチボックスやピザボックスのx86 M/B用ケースをだせ！
389:名無しさん＠お腹いっぱい。
08/05/09 07:39:29
>>388
Mac miniでも買えば？
既に手に入るという事と、Sunが出すよりは安く買えるだろうという点で、良い選択肢。
390:名無しさん＠お腹いっぱい。
08/05/09 08:20:48
液晶モニタ時代なのに、ピザボックス?
適当な場所に積み重ねて使おうと?
391:名無しさん＠お腹いっぱい。
08/05/09 09:02:02
いや、x86 なんて賭けるべきプラットフォームじゃないんだよ。
注射で延命してるだけだし。Itanium 紹介した時 Intel がなんて言ったか調べてみな。
392:名無しさん＠お腹いっぱい。
08/05/09 09:11:24
その時の未来予想はハズレなので。
393:名無しさん＠お腹いっぱい。
08/05/09 09:13:15
いや。もう終るよ。
394:名無しさん＠お腹いっぱい。
08/05/09 09:28:47
これまでの失地を回復できるのか?
395:名無しさん＠お腹いっぱい。
08/05/09 15:13:53
>>389
安いけど2.5インチHDDがイヤだ。
放熱もノートPCのノリで悪そうだし。
396:名無しさん＠お腹いっぱい。
08/05/09 15:35:08
>>388
HDDの冷却が悪いダメな詰め込み筐体だよ、あれは。
397:名無しさん＠お腹いっぱい。
08/05/09 15:39:29
Shuttle のキューブでいいよｗ
398:名無しさん＠お腹いっぱい。
08/05/09 16:03:58
今更 3.5inch かよ? そりゃ SS1 買ってないわなあの時代に。ダメw
399:名無しさん＠お腹いっぱい。
08/05/09 16:16:37
こういう電源ファンレスがいい
URLﾘﾝｸ(www.watch.impress.co.jp)
400:名無しさん＠お腹いっぱい。
08/05/09 17:08:49
>>399
シンクライアントでも使いなされ。
401:名無しさん＠お腹いっぱい。
08/05/09 17:37:35
>>398
なにが今更3.5インチなの？
SS1がうんたらとか何が言いたいのかさっぱりわからない。
SCSI/SAS 2.5インチで高くて速くて容量小さいならともかく、
ノート用2.5インチは高くて遅くて容量小さいのが困るのさ。
消費電力が少なくて小さいだけ。
402:名無しさん＠お腹いっぱい。
08/05/09 17:48:10
>>401
近頃のノートPC向け2.5"HDDは結構速いよ。
まあまあ速くて、ほどほどに安くて、消費電力が少ない。
403:名無しさん＠お腹いっぱい。
08/05/09 18:04:30
>>401
それのどこが SS1 の頃に 5inch にしがみ付いてたやつの言うことと違うのよwww
404:名無しさん＠お腹いっぱい。
08/05/09 18:57:39
>>400
シンクラだとサーバの設定が必要やん
OS入れてすぐ動くのがいい
405:名無しさん＠お腹いっぱい。
08/05/09 19:16:11
>>402
ノートPCではいつも7200rpmモノに交換するから知ってるよ。
でも3.5インチものに比べたらやっぱり遅いと感じる。
ランダムアクセス性能の悪さがネック。5400rpmなんて論外。
ベンチマーク結果だけで速いと信じてるバカはいるが。
消費電力と占有スペースにメリットがあるのは判っているけど、
それをワークステーションや小規模サーバで求めてはいないんだ。
>>403
ああそういう手合いのバカか。
自分だけわかったつもりで意味不明の文章を書くタイプは困る。
ProDrive 105Sならクソすぎて速攻捨てたがなにか？
早々に導入した外付け5インチの快適さと言ったらなかったぞ。
ガリガリガリうるさかったけどな。
3.5インチだと500MBあたりからじゃないか？評価できるのは。
それならSS2以降の世代を例示しないとダメだろ。
406:名無しさん＠お腹いっぱい。
08/05/09 20:59:01
2.5inch云々って >>388-389 からの流れだよな？
旧SS＋外付け5inchが快適で良かったって話なら、
MacMini + 外付け3.5inch でもいいわけで。
まあ別に MacMini を勧めるわけではないが。
407:名無しさん＠お腹いっぱい。
08/05/09 21:31:23
今のMac miniだとUSBやFireWireになるじゃまいか。
それこそ遅くなって意味がねえ。
408:名無しさん＠お腹いっぱい。
08/05/10 12:13:10
>>405
ぷ。まるで反論になってないがなwwww
409:名無しさん＠お腹いっぱい。
08/05/10 12:14:16
低能な煽りはやめろよ。恥ずかしい。
410:名無しさん＠お腹いっぱい。
08/05/10 13:07:55
え? オレ煽ってたのかそりゃ気づかんかったwwww
411:名無しさん＠お腹いっぱい。
08/05/10 13:48:20
>>410は低能な煽りの典型
412:名無しさん＠お腹いっぱい。
08/05/10 14:14:56
いや～、3.5inch 最高! オレも次買うんなら 3.5inch にするよ。もちろん 3.5inch だよな?!w
413:名無しさん＠お腹いっぱい。
08/05/10 14:32:46
毎度頭が悪くて面白いなぁ
414:名無しさん＠お腹いっぱい。
08/05/10 15:49:50
>>411
そんなに甘やかすなよ
415:名無しさん＠お腹いっぱい。
08/05/10 16:07:05
3.5inch 君て呼んであげるよ今後はw
416:名無しさん＠お腹いっぱい。
08/05/10 16:14:56
ちっちゃーい（クスクス
417:名無しさん＠お腹いっぱい。
08/05/10 19:48:08
T2+でメモリのチャネル数が減ったのはT2ではメモリ帯域がオーバースペックだったからということだが、
メモリが予想外に実効帯域が高かったかT2のCPUコアの要求するメモリ帯域が予想外に少なかったか、
どっちなのだろう。
418:名無しさん＠お腹いっぱい。
08/05/10 19:57:19
それは建前の言い訳で、
チップ間の接続のために必要なダイ面積と消費電力が大きくて、しかたなく、10GbEとメモリを削った
あるいは
もっと高いクロックを狙っていたが、製造してみたら歩留まりが悪すぎてクロックを落した結果、メモリの帯域幅が余りまくった
というのが本当のところだろうな。
419:名無しさん＠お腹いっぱい。
08/05/10 20:50:32
URLﾘﾝｸ(hpc.sun.com)
> we opted to shift the 10 GbE interfaces off-chip in the UltraSPARC
> T2plus to make room for the 50 GB/s of coherency logic we added to
> allow two T2plus sockets
まあdualならCPUに10GbEが付いてきても無駄なのは確か。
420:名無しさん＠お腹いっぱい。
08/05/10 22:52:56
T2/T2+、Web用途なら最速だからいいじゃん。
421:名無しさん＠お腹いっぱい。
08/05/11 00:44:46
2chのWebサーバは、x86だがな・・・
422:名無しさん＠お腹いっぱい。
08/05/11 01:50:56
それを言ったら大体のとこはx86だろ
いいとこ探ししようぜ
423:名無しさん＠お腹いっぱい。
08/05/11 02:18:27
>>420
最速？
424:名無しさん＠お腹いっぱい。
08/05/11 02:30:21
T2とか、シングルスレッドの性能もいいの？
425:名無しさん＠お腹いっぱい。
08/05/11 02:46:25
Suｎは2chにTシリーズを提供をすればいいのに
426:名無しさん＠お腹いっぱい。
08/05/11 03:56:06
ダウンタイムが増えそうだからヤダ
427:名無しさん＠お腹いっぱい。
08/05/11 04:02:10
2ちゃんねるはC2DとFreeBSDでやりたいんじゃない？
428:名無しさん＠お腹いっぱい。
08/05/11 04:37:38
それが一番安くて速いしな。
429:名無しさん＠お腹いっぱい。
08/05/11 04:44:34
なんでAMD使わないんだ？と思ったら
MicroATXで8GBメモリ載せられて
FreeBSD使ってNICがまともに動きそうな板って
なさげなのな
3wareのRAIDカードとの互換性もどうかなって感じ
430:名無しさん＠お腹いっぱい。
08/05/11 09:11:20
AMD使ってた事もあったが、時代なんじゃないの？
431:名無しさん＠お腹いっぱい。
08/05/11 12:00:08
なんじゃ時代って？ｗ
2ちゃんの技術者はもっと合理的理由で選んでると思うが
432:名無しさん＠お腹いっぱい。
08/05/11 12:04:14
AMDじゃなくてIntelが優勢になったのが時代って言ってんだろ
K8じゃなくてCore2の方が性能出るようになったから
433:名無しさん＠お腹いっぱい。
08/05/11 12:11:29
そもそもCore2の方が性能出てるかどうか知らん
俺は中の人じゃないから彼らがどういう理由で選んでるかどうか分からん
そもそも彼らがCPU等部品の選択権あるのかどうかも不明だし
434:名無しさん＠お腹いっぱい。
08/05/11 14:21:01
たまたまいまはC2Dってだけだな
ちょっと前はopteronだったわけだし
435:名無しさん＠お腹いっぱい。
08/05/11 14:36:34
FreeBSDはSPARCはTier1なんだから、
SunがFreeBSDのマルチスレッド性能をSolaris並にすべく、
ソースコードを寄贈すればいいんだよ。
あるいはFreeBSDから派生したものを作るとか。
436:名無しさん＠お腹いっぱい。
08/05/11 14:42:27
Solaris使えばいいやん
PCでも動くんやから
437:名無しさん＠お腹いっぱい。
08/05/11 15:33:01
2chはBig-server.comのプロモーション用だからなあ
ほかの販売しているホストも全部Solarisにするってことでもないかぎり
Solaris採用ってことに意味は無いってことになるね