08/10/02 14:09:34 .net
うん、で、今は? まだなってないの?
201:名無しさん＠お腹いっぱい。
08/10/02 14:10:19 .net
自分でマイクロソフトのサイトでも見たら?
202:名無しさん＠お腹いっぱい。
08/10/02 14:47:02 .net
なんでそんなに言いたくないわけ?wwww 恥しくて?w
203:名無しさん＠お腹いっぱい。
08/10/02 14:55:17 .net
いつもの粘着キチガイか
204:名無しさん＠お腹いっぱい。
08/10/02 16:10:24 .net
まあ、カトラーは最初っから Itaniumには批判的だったみたいだしね。
Athlonの部隊には DEC出の同僚がたくさん居るみたいだし。
最適化の手法が Alphaと同じでイケるとかなんとか。
仕方ないわな。
205:名無しさん＠お腹いっぱい。
08/10/03 05:20:03 .net
カトラーというかWindowsNTは最初の方針の中に、
マルチスレッド化してマルチプロセッサでスケールする
というのがあったので、
シングルスレッド性能を追求するあまりに効率の劇悪な
IA-64というのはアホらしかったのだろう。
206:名無しさん＠お腹いっぱい。
08/10/03 09:57:30 .net
そうかなぁ。オレは単なる同窓会趣味と、自分の過去の技術に対する
固執（よく言えば自負）なんじゃないかと思ってるがww
DECにはそういう社風あったそうだし。社外技術を見下す姿勢。
EPICは HPから出たもんだから。
207:名無しさん＠お腹いっぱい。
08/10/03 12:56:36 .net
レジスタウィンドウが嫌いなんだよ!!
208:名無しさん＠お腹いっぱい。
08/10/03 13:10:08 .net
レジスタウィンドウは使いにくいよね。
209:名無しさん＠お腹いっぱい。
08/10/03 16:16:26 .net
それは違うな。ハマれば高速。
210:名無しさん＠お腹いっぱい。
08/10/03 19:35:02 .net
実際のところ、ハマるのか?
211:名無しさん＠お腹いっぱい。
08/10/04 23:20:18 .net
おっ。いまちょうどハマったw
212:名無しさん＠お腹いっぱい。
08/10/16 13:29:39 .net
JR九州、NX7700iシリーズなど 16台に移行、って書いてあるな。
イマイチ図が小さすぎてよく見えんが。NX7700iが何台だろ?
213:名無しさん＠お腹いっぱい。
08/10/18 02:33:24 .net
メインは8CPU機を2台でクラスタ構成っぽい。
214:名無しさん＠お腹いっぱい。
08/11/16 11:11:57 .net
>>121
亀レスだが。
ネイティブだろうがエミュだろうが、同じバージョンである以上その中身が変わることは
まずいんでないの？特に商用利用では。
(パッチによるバグ修正は除く)
HP-UXに関しては、逆にパフォーマンスに関わる部分はネイティブ化してあるって
ことなんだろうさ。
215:名無しさん＠お腹いっぱい。
08/11/19 01:54:25 .net
top500の中でItaniumを使ってるのが 1.8%
EM64T, x86_64を合計すると85%
216:名無しさん＠お腹いっぱい。
08/11/19 11:18:06 .net
きゅーぴーIで x86の SMPがまともになったりしたら即死だね。
ま、その可能性は低いと思うがw
217:名無しさん＠お腹いっぱい。
08/11/27 09:37:41 .net
>>214
だから何?
むしろ1.8%も残っていることのほうが驚きだよ。
>>215
はいはい、Sunスレから出張で荒らしに来て、おつかれさん。
6コアXeonの4ソケットが出た時点で、速度面では、もう終わってるよ。
それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。
まぁ限られてると思いますけどね。
218:名無しさん＠お腹いっぱい。
08/11/27 10:30:57 .net
> 6コアXeonの4ソケットが出た時点で、速度面では、もう終わってるよ。
24コアを「バス」で主記憶に接続して、まともに性能出るわけがない。
キャッシュに収まる特殊用途除いて、な。あんた次元低すぎるんだよ。
なんでわざわざインターコネクトの名前あげてるかぐらい考えてよね。
考えても書かなくていいけどww
> それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。
そんな用途で実績のかけらもないアーキを使う意味なんかないでしょ。
企業判断的にチョンボして行き詰まってる「事情」があるとこ以外には
無価値と思うが。
219:名無しさん＠お腹いっぱい。
08/11/27 11:12:53 .net
やはりその口調、Sunスレから荒らしに来ている人か。
あなたの脳内では、まともに性能が出ないそうだが、
各社がサーバ作って出してるんだよねぇ。
220:名無しさん＠お腹いっぱい。
08/11/27 11:20:42 .net
Xeon 7400番台を採用した4Pサーバは、Sunもリリースしていたと思うが。
221:名無しさん＠お腹いっぱい。
08/11/27 18:55:12 .net
まあ、このへんにちょうどいい解説があるよ。3.な。
URLﾘﾝｸ(www.geocities.jp)
| コモンバス方式は追加のハードも少なく一番簡単ですが、
| ...多数のプロセサを使うシステムでは性能が飽和してしまいます。
超入門者向け 1980年代の基礎知識だけどな。MP評価する立場ならこんなん知らんと
話にならん。
222:名無しさん＠お腹いっぱい。
08/11/28 05:09:47 .net
>>217や>>220の脳内では、今もXeonは1つのバスに24コアが並列に繋がっていて、メモリも1chしかないらしい。
223:名無しさん＠お腹いっぱい。
08/11/28 09:38:14 .net
こういうお話しにならないアホウが x86の SMP機買ったりするんだろうなぁ..
ろくに検証もしないから問題にもならない、とw
224:名無しさん＠お腹いっぱい。
08/11/28 12:41:06 .net
いつも相手を馬鹿にした態度で書き込みをしている・・・そういう病人はスルーしましょう。
しかも現実が見えてないですからね。
225:名無しさん＠お腹いっぱい。
08/11/28 18:41:16 .net
よっぽど会社じゃ居場所ないんだろか(´・ω・｀)
226:名無しさん＠お腹いっぱい。
08/11/29 02:33:55 .net
> ろくに検証もしないから
あれれ、脳内妄想で評価している人が、そんなこと言いますか?
227:名無しさん＠お腹いっぱい。
08/11/29 07:01:00 .net
確かにマルチコアでの性能の上がり具合はx86の方が低そうだけど、
Opteron 8wayとItanium 4wayでOpteronの方が性能が上で価格も数分の一となれば
Opteron選ぶよねえ。うちでItanium入れたのなんてsuper domeくらいだ。
x86だとDL785の8CPUが上限だから、それ以上欲しいときはItanium/SPARCを
検討する。2CPUや4CPUで十分なサーバーにはx86しか入れない。
228:名無しさん＠お腹いっぱい。
08/11/29 07:36:58 .net
板違いになりますが、Windowsで仕事してます。
お客様は夢見がちで、現時点でWindows鯖で十分なことは理解していても、
将来の業務拡大にハードウェアのアップグレードで追い付けないことを心配されます。
そのときにItaniumにアップグレード可能だと説明すれば、だいたい納得されます。
実際にはx86ベースのシステムの性能向上のペースを上まわって成長した事例はなく、
Itaniumは見せ玉のまま終わっています。
x86 & Linuxの案件でも、Itaniumは見せ玉として使えませんか?
229:名無しさん＠お腹いっぱい。
08/11/29 07:59:50 .net
DB鯖以外はスケールアウトが可能になってるからサーバー単体の性能は
そんなに気にしない。台数少ないにこしたことはないけどね。管理も楽だし。
DBはOracle RACいれてとりあえずノード追加で対応できて将来はまた
新しいH/W出てますから、って言う。まあDBはOracleさえ走ればLinuxでも
Solarisでもhp-uxでもいいから見せ玉使う事もないけど。
230:名無しさん＠お腹いっぱい。
08/11/29 09:28:31 .net
Oracleはマルチプラットフォームでいいですね。
SQL ServerはWindowsのみなので、Itaniumには頭が上がりません。
231:名無しさん＠お腹いっぱい。
08/11/29 09:52:28 .net
キューぴーIは、少なくとも理屈の上ではリニアなスケールの可能性があるよね。
それ以前の「バス」はだめだよ「バス」は。お話にならん。
なんでこうおバカが多いのか。踊らされてほんとにアワレなこった。
232:名無しさん＠お腹いっぱい。
08/11/29 10:00:08 .net
>>230
妄想はいいから自分で実機で検証してからホザきなさい。
233:名無しさん＠お腹いっぱい。
08/11/29 10:06:27 .net
お前こそ 8コア超の x86サーバーがエンプラ用途でちゃんとリニアに
スケールするという記事でも探してこい。
「商品が出てる」で証明になんかなるかボケ。
ちなみにオレはクソおそい 80386のMP機�
234:ﾍ触ったことあるぞ。 単発の 80386パソコンの何倍も遅かったが、製品だった。 まーーーーったく売れなかったと聞いてるww
235:名無しさん＠お腹いっぱい。
08/11/29 10:11:29 .net
>>232
その他には経験がないわけですねw
誇らしい経験をお持ちで良かったです。
>>227
皺々なんで見せるの恥ずかしいです（＞＜）
236:名無しさん＠お腹いっぱい。
08/11/29 10:36:13 .net
ああ、あとは皆無だ。そんなもん買うバカにはとんとお目にかからん。
で、記事かなんか提示しろや。自分で買ってベンチしたのでもいいぞ。
ま、そんな知識じゃ SMPの評価なんてどうやったらいいかわからんだろうがなwwwwwww
237:名無しさん＠お腹いっぱい。
08/11/29 11:40:00 .net
>>227
Windows売るのにItaniumを見せ玉にってのは良く聞くな
でも、Becktonが出たらItaniumの役目も終わりだろ
Linuxで拡張性に不安って人は最初からUNIXに行くんじゃね？
238:名無しさん＠お腹いっぱい。
08/11/30 02:41:38 .net
その頃にはItaも少しは進化してるだろうし、32/64CPUクラスをXeonで
置き換えられるようになるのはまだまだかかるんじゃないかな
239:名無しさん＠お腹いっぱい。
08/11/30 04:51:36 .net
>>234
退場。
240:名無しさん＠お腹いっぱい。
08/12/01 10:28:18 .net
実績ないんだから、提示不能。そういうことだよな?ww
241:名無しさん＠お腹いっぱい。
08/12/01 14:40:06 .net
>>238
いいかげんにし
242:ろ。
243:名無しさん＠お腹いっぱい。
08/12/01 15:35:14 .net
お前がな。
244:名無しさん＠お腹いっぱい。
08/12/01 15:46:11 .net
x86けなされると、なんでそんなにくやしいの? どーでもいいんだけどさ..
245:名無しさん＠お腹いっぱい。
08/12/01 16:58:43 .net
どーでもいいなら聞く必要もあるまい。
自己矛盾君。
246:名無しさん＠お腹いっぱい。
08/12/01 17:15:46 .net
ゴミ撒かれるのはどーでもよくないわけで。
ま、もうゴミでも撒かなきゃ話題もないんだけどww
247:名無しさん＠お腹いっぱい。
08/12/01 17:32:53 .net
既に約 1年前に元麻布氏がこんなの書いてたんだね。
URLﾘﾝｸ(pc.watch.impress.co.jp)
| ...このアライアンスを母体に新しく事業会社を起こし、そこにIA-64の設計や
| 開発を分離するのはどうだろう。...Tukwilaが完成し、QPIベースの
| プラットフォームが確立したら、タイミング的には頃合いだと思うのだが。
248:名無しさん＠お腹いっぱい。
08/12/01 17:41:48 .net
じゃあそうします。
249:名無しさん＠お腹いっぱい。
08/12/01 17:43:51 .net
Itanium International
国際イタニウム株式会社
250:名無しさん＠お腹いっぱい。
08/12/02 07:46:30 .net
Xeon 7300や7400ってのは、1プロセッサに4コアあるいは6コア。これが同一のFSBを共有。
これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
そして、Xeon 7300や7400の4プロセッサ向けのチップセットではFSBが4本あり、
4つのプロセッサがFSBを共有せず、スヌープキャッシュによって、ほぼ独立している。
これらと2つの独立したメモリコントローラが、チップ上で密に結合されている。
これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
いまのXeonがSMPで性能が出ないというのなら、
かつてのSun FireのSMPも性能が出ないという話になる。
プロセッサ数あるいはコア数が倍になっても、性能は倍にはならないが、
それは、Sun Fireでも同じ。
251:名無しさん＠お腹いっぱい。
08/12/02 10:18:11 .net
Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、
バスなんか使ってないですが。直クロスバーですぜ。
んで、その Xeonの構成で、メインメモリはどこにつながってるの?
チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
んで、メインメモリへのアクセスは競合しないの?
バスが「飽和する」って、意味わかってる?
> これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
> これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
> かつてのSun FireのSMPも性能が出ないという話になる。
> それは、Sun Fireでも同じ。
まぁーーーーーーっったく、違いますが。いっしょにしないでくれる?w
んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
一体なんの関係があるわけ?
チャネル数増やして（見かけ上の）アクセス速度上げると、
バスは _余計に飽和_ しやすくなるけど?
バスが「飽和する」って、意味わかってる? （念の為 2回め）
252:名無しさん＠お腹いっぱい。
08/12/02 11:06:45 .net
Itaniumの話しようぜ
253:名無しさん＠お腹いっぱい。
08/12/02 11:35:16 .net
>>248
> Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、
> バスなんか使ってないですが。直クロスバーですぜ。
データはクロスバーだけど、アドレスは実質的にバスだよ。
> んで、その Xeonの構成で、メインメモリはどこにつながってるの?
> チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
バスですよ。
> んで、メインメモリへのアクセスは競合しないの?
競合するよ。
メモリアクセスを開始できるのは同時に2つまで。
アドレスが実質的にバスのSun Fireも同じだよ。
メモリアクセスを開始できるのは同時に1つだけ。
> バスが「飽和する」って、意味わかってる?
アイドルサイクルがない状態が飽和、でしょう。
> んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
> 一体なんの関係があるわけ?
独立して動作するメモリバスが2本あれば、
2つのコアのメモリアクセス要求を同時に処理できるので、
飽和した状態で処理できるメモリアクセスが増える。
254:名無しさん＠お腹いっぱい。
08/12/02 11:35:53 .net
じゃあ、Itaniumの話で。
いま自宅でRHEL3使ってるんだが、ぼちぼち入れ替えたい所。
ia64対応しているフリーのディストリで、今だったらどれがオススメ？
centosはいつまで経っても5系でないし、何かdebian位しかメンテされているのがない気がする。
255:名無しさん＠お腹いっぱい。
08/12/02 11:48:09 .net
>>250
> アドレスが実質的にバスのSun Fireも同じだよ。
おいおい。トンデモな言い訳はよしてくれや。
じゃ、バスに対するクロスバーの利点はなんだよ?
アドレスがバスだからクロスバーの利点は帳消しになるとでも? ふざけてんのか??
256:名無しさん＠お腹いっぱい。
08/12/02 12:10:34 .net
>>252
> おいおい。トンデモな言い訳はよしてくれや。
>>220のリンク先に書いてあることですが?
> じゃ、バスに対するクロスバーの利点はなんだよ?
クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
もしSun Fireをバスにした場合、512bit幅でバスを配線しなくてはいけない。
クロスバーなら、発着が別の場合に、1つ前のメモリアクセスで生じた転送が終わる前に
次のメモリアクセスで生じる転送を開始できるので、つまり、転送をゆっくり行うことができる。
そのためSun Fireは128bit幅で4クロックに分けて転送してる。
257:名無しさん＠お腹いっぱい。
08/12/02 12:11:40 .net
>>251
いっそFreeBSDいってくれ。
258:名無しさん＠お腹いっぱい。
08/12/02 12:19:26 .net
>>251
使うだけならそのままRHEL3をEOL迄使いつづけたら？
開発に参加するならFedora9を入れるとか。
URLﾘﾝｸ(fedoraproject.org)
259:名無しさん＠お腹いっぱい。
08/12/02 12:19:54 .net
>>254
FreeBSD/ia64だとXが使えないのが苦しい所だな。
260:名無しさん＠お腹いっぱい。
08/12/02 12:28:22 .net
>>255
まさに使うだけだったからRHEL3で間に合ってたのだけど、
作業環境としては要らなくなったので、気分転換しようかと。
実験環境としてはdebianだと保守的すぎてつまらないし、
Fedora9で良さそうね。
261:名無しさん＠お腹いっぱい。
08/12/02 13:18:51 .net
>>253
> クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
はぁ～。どーしよーもねーな。
まあ、その程度じゃなきゃ共有バスで SMP性能が出るなんて思わんわな。
Wikipedia の「バス（コンピューター）のとこでも読んでみれ。話にならん。
| ...スター型トポロジとなるクロスバースイッチ（クロスバーバス）が
| ワークステーション等に採用されている。これは複数のCPU・メモリ間で
| 多対多の転送（通信）を同時に行えるようにしたもので、...
多対多で同時ね。は～、疲れるわ。
262:名無しさん＠お腹いっぱい。
08/12/02 16:09:09 .net
>>258
こっちのほうが疲れるぞ。
思いっきり単純化して、スヌープとか調停とか端折りまくって説明するとだな。
■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
64バイトの転送を16バイトずつ4クロックに分けてもOK
ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードAのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードBのメモリの読み取りを要求
略
ステップ5) ノードCのメモリから、ノードAのCPUに向けてデータ転送開始
ステップ6) ノードDのメモリから、ノードBのCPUに向けてデータ転送開始
ステップ7) ノードAのメモリから、ノードCのCPUに向けてデータ転送開始
ステップ8) ノードBのメモリから、ノードDのCPUに向けてデータ転送開始
略
ステップ9) ノードCのメモリから、ノードAのCPUに向けてデータ転送終了
ステップ10) ノードDのメモリから、ノードBのCPUに向けてデータ転送終了
ステップ11) ノードAのメモリから、ノードCのCPUに向けてデータ転送終了
ステップ12) ノードBのメモリから、ノードDのCPUに向けてデータ転送終了
263:名無しさん＠お腹いっぱい。
08/12/02 16:10:44 .net
■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、
64バイトの転送を64バイトぜんぶまとめて1クロックで行わないといけない
ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードAのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードBのメモリの読み取りを要求
略
ステップ5) ノードCのメモリから、ノードAのCPUに向けてデータ転送
ステップ6) ノードDのメモリから、ノードBのCPUに向けてデータ転送
ステップ7) ノードAのメモリから、ノードCのCPUに向けてデータ転送
ステップ8) ノードBのメモリから、ノードDのCPUに向けてデータ転送
逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
264:名無しさん＠お腹いっぱい。
08/12/02 16:35:39 .net
>>260
> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
あのなぁ........................ そういう前提がまちがってるし。
今 6coreが 4ソケットって話してるんだが、コアが 24という前提でやってくれるか?
1:4クロックでノード数 4て、日頃からそいういうインチキ語って暮らしてるの?
逆に言えば、上の例だと 5CPU以上ダメじゃん。実際オーバーヘッド入れたら
共有バスだと 4CPUもキツイ、というのにモロ符合するけどなw
オレもヒマだなw
265:名無しさん＠お腹いっぱい。
08/12/02 16:47:29 .net
>>261
> 逆に言えば、上の例だと 5CPU以上ダメじゃん。
4ノードの時点で16CPUなんだが・・・
まぁいいや5ノードで書いてみる。
■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
64バイトの転送を16バイトずつ4クロックに分けてもOK
ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードEのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードAのメモリの読み取りを要求
ステップ5) ノードEのCPUがノードBのメモリの読み取りを要求
略
ステップ6) ノードCのメモリから、ノードAのCPUに向けてデータ転送開始
ステップ7) ノードDのメモリから、ノードBのCPUに向けてデータ転送開始
ステップ8) ノードEのメモリから、ノードCのCPUに向けてデータ転送開始
ステップ9) ノードAのメモリから、ノードDのCPUに向けてデータ転送開始
ステップ10) ノードBのメモリから、ノードEのCPUに向けてデータ転送開始
略
ステップ11) ノードCのメモリから、ノードAのCPUに向けてデータ転送終了
ステップ12) ノードDのメモリから、ノードBのCPUに向けてデータ転送終了
ステップ13) ノードEのメモリから、ノードCのCPUに向けてデータ転送終了
ステップ14) ノードAのメモリから、ノードDのCPUに向けてデータ転送終了
ステップ15) ノードBのメモリから、ノードEのCPUに向けてデータ転送終了
266:名無しさん＠お腹いっぱい。
08/12/02 16:48:34 .net
■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、
64バイトの転送を64バイトぜんぶまとめて1クロックで行わないといけない
ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードEのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードAのメモリの読み取りを要求
ステップ5) ノードEのCPUがノードBのメモリの読み取りを要求
略
ステップ6) ノードCのメモリから、ノードAのCPUに向けてデータ転送
ステップ7) ノードDのメモリから、ノードBのCPUに向けてデータ転送
ステップ8) ノードEのメモリから、ノードCのCPUに向けてデータ転送
ステップ9) ノードAのメモリから、ノードDのCPUに向けてデータ転送
ステップ10) ノードBのメモリから、ノードEのCPUに向けてデータ転送
ほらね、データバスの帯域幅は4ノードと5ノードで同じだよ?
267:名無しさん＠お腹いっぱい。
08/12/02 17:25:26 .net
>> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
> あのなぁ........................ そういう前提がまちがってるし。
クロックって言うからいけない
アドレスの1サイクルと同じ時間で終わるならって言えばいいのよ
268:名無しさん＠お腹いっぱい。
08/12/02 19:18:29 .net
>>258
転送は同時にできるが、その転送の要求は同時に出せない。
269:名無しさん＠お腹いっぱい。
08/12/02 20:01:36 .net
バスで 64バイトが 1クロックって、どういうことよ? 信号線 512本あるの?
270:名無しさん＠お腹いっぱい。
08/12/02 20:17:44 .net
信号線が512本もあったら実装が大変だし、
かといってクロックを上げるのも大変だから、
そこで、
クロスバーですよ。
271:名無しさん＠お腹いっぱい。
08/12/02 20:30:30 .net
LSI内なら512本もOK
Xeon用のチップセットは、データ部分8.5GB/secのFSBを4本と、
送受信あわせて8GB/secのFB-DIMMを4チャネル(2チャネルずつ束ねて使われることに注意)、
合計66GB/secを、
クロスバーかバスか知らないが、とにかく、コンカレント動作を妨げないように接続している。
272:名無しさん＠お腹いっぱい。
08/12/02 22:37:56 .net
そろそろクロスバー盲信者にトドメ、さしとくかな。
Sun Fire 3800 2～8プロセッサ 実効帯域幅9.6GB/sec
Sun Fire 4800 2～12プロセッサ 実効帯域幅9.6GB/sec
Sun Fire 6800 2～24プロセッサ 実効帯域幅9.6GB/sec
アドレスが実質的にバスなので、プロセッサが増えても9.6GB/secのまま。
273:名無しさん＠お腹いっぱい。
08/12/02 23:16:55 .net
16CPU超のシステムならアプリインストールしてベンチで評価するでしょ。
そりゃこの辺の知識があれば評価対象は絞り込みやすくていいけどさ、
いい加減お互いにけんか腰やめてくんないかな
274:名無しさん＠お腹いっぱい。
08/12/02 23:18:22 .net
Itanium機にRHEL3って人はhp-uxはもっとらんの？
保守入ってなきゃ新バージョンはもらえないのかな
275:251
08/12/02 23:57:25 .net
>>271
hp-uxは持ってないし、ドライバサポートに難があって、
確かVGAとSCSIボードを交換する必要があった。
シリアルコンソール＆ATA接続にすりゃ動く様だが、
それじゃあWSとは言えんわなｗ
ちなみにWindowsでもそのままの構成で動く。
276:名無しさん＠お腹いっぱい。
08/12/03 00:16:38 .net
> アドレスが実質的にバスなので
どこの田舎の言葉ですか?
277:名無しさん＠お腹いっぱい。
08/12/03 01:19:53 .net
続きは検証センターででもやればいいのに。
278:名無しさん＠お腹いっぱい。
08/12/03 09:37:01 .net
>>270
え? バスバス言ってんのは、なんか反論でもした気になってるのかよ? 笑止
小手先の付け焼き刃の延命処置をさもまっとうな対策みたいに語るのは
よくあることだけどな。
279:名無しさん＠お腹いっぱい。
08/12/03 09:41:18 .net
「バスを多段にして間にキャッシュ噛ますとあら不思議、クロスバーに対抗できます。」
まとめるとこういうことだな。
「なぜなら、クロスバーはアドレス指定がバスだからです。」
クロスバー導入したエンジニア達はそれに気付かなかったわけだw
280:名無しさん＠お腹いっぱい。
08/12/03 11:50:30 .net
Sun Fire 6800、アドレスが実質的にバスで飽和しまくり。
↓
「バスを多段にして間にキャッシュ噛ます」
アドレスのバスを細かく分割して、スヌープフィルタを介して相互接続することで、ボトルネック解消
↓
Sun Fire 15K、従来の10倍以上の高速化を実現!
Xeon、共有バスなので飽和しまくり。
↓
バスを分割して、スヌープフィルタを介して接続することで、ボトルネック改善
ね、一緒でしょ。
>>273
真実には逆らえず、レッテル貼りによる封じ込めに作戦変更ですか?
281:名無しさん＠お腹いっぱい。
08/12/03 11:54:51 .net
URLﾘﾝｸ(www.atmarkit.co.jp)
> 通常のバス・アーキテクチャでは全ての信号が1本のバスを通るため、
> CPUなどを増やして処理性能を上げようとしてもバス性能が性能向上のボトルネックとなった。
> バスを流れる「データ」「コントロール」「アドレス」の3種類の信号のうち、
> データだけがクロスバー・テクノロジによって高速化されていた。
アドレスはバスでした。
もっと詳しいことは↓でも読んでくれ。
URLﾘﾝｸ(jp.sun.com)
282:名無しさん＠お腹いっぱい。
08/12/03 12:03:16 .net
ちなみに日本語訳は誤訳とかアヤシイ部分があるので、原文に当ったほうがいいかも。
原文はこちら
URLﾘﾝｸ(www.sc2001.org)
283:名無しさん＠お腹いっぱい。
08/12/03 12:06:31 .net
>>278
> アドレスはバスでした。
お前の日本語をどうにかしろと
284:名無しさん＠お腹いっぱい。
08/12/03 12:11:16 .net
ていうか、すでに>>220のURLに書いてあることなんだよな。
自分で持ち出しといて、内容を読んでなかったのかな。
285:名無しさん＠お腹いっぱい。
08/12/03 12:11:28 .net
...Sun Fireのクロスバーが性能改善した事実がすなわち今の Xeon MP機の
性能がいいことを証明したことになる、のかよ? 無理あり過ぎだろw
実際そうなら 8コア超の Xeon MP機の評価記事がどんどん出てくるだろうし、
飛ぶように売れるだろうからそれでわかるんだろな。
じゃあ、QPIなんてやる必要はなかったわけだw
..どのみち Itaniumは-終了-なんだな。
286:名無しさん＠お腹いっぱい。
08/12/03 12:12:05 .net
>>280
アドレスは実質的にバス接続
これ、理解できないの?
287:名無しさん＠お腹いっぱい。
08/12/03 12:12:28 .net
>>281
あんた相手してるの元の人間と違うぞw
288:名無しさん＠お腹いっぱい。
08/12/03 12:14:41 .net
>>282
往生際が悪いぞ。
一部分でもバスだからダメというお前さんの主張を否定しただけだ。
289:名無しさん＠お腹いっぱい。
08/12/03 13:11:23 .net
はあ? 往生なんかしませんが。ひょっとして追い詰めたとでも思ってるのか?!
クロスバーにすぐついてこれなかった RISCベンダーが打った対策の
焼き直しじゃないか。もっともらしく持って回ってあるが。
そいつら結局全部クロスバー行ってるし。
で、QPIはどうなんだよ? それ以上に素晴らしいバラ色の新技術か?w
290:名無しさん＠お腹いっぱい。
08/12/03 13:16:23 .net
>>285
> 一部分でもバスだからダメというお前さんの主張を否定しただけだ。
ところで、バスを分割して切り替え（スイッチング）して使うのは、
それはクロスバースイッチとは明確に違うのか? 信号線も減るんだろ?
粒度の違いで区別する?
291:名無しさん＠お腹いっぱい。
08/12/03 13:45:00 .net
>>283
アドレスリクエストがシェアードバスに流れると言いたいのか？
クロスバースイッチだって「バス」だぜ？
292:名無しさん＠お腹いっぱい。
08/12/03 13:48:09 .net
>>286
すでにXeonはクロスバーになった、という話なんだがなぁ。
>>287
Sunは、
> バスを分割して切り替え（スイッチング）して使う
ことも、クロスバーと呼んでるようですよ。
293:名無しさん＠お腹いっぱい。
08/12/03 13:50:41 .net
270だけどなんでバスなんて一言も言ってない俺が突っ込まれなきゃならないわけ？
ItaniumもSPARCもCPU単体の能力が低すぎてどうでもいいんですけど。
何でインターコネクトの帯域にそんなにこだわるの？
OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？
294:名無しさん＠お腹いっぱい。
08/12/03 13:50:49 .net
>>288
そういう言葉の揚げ足取りするのやめなよ。
どういう意図でバスと言ってるのか理解できるだろ。
295:名無しさん＠お腹いっぱい。
08/12/03 13:53:46 .net
>>290
CPU単体の能力が低すぎる
↓
多数のCPUをSMPで動かす
↓
インターコネクトの性能で決まる
ってことかと。
Sunが真っ先にクロスバーを導入したとき、
そのCPU搭載数は競合他社の2倍だったと思う。
296:名無しさん＠お腹いっぱい。
08/12/03 13:57:18 .net
で、だ。
CPU単体の能力が高ければ、
多数のCPUをSMPで動かす必要もなく、
ゆえにインターコネクトの性能も必要ない
297:名無しさん＠お腹いっぱい。
08/12/03 13:59:53 .net
>>289
> すでにXeonはクロスバーになった、という話なんだがなぁ。
ほぉおふぉぉ、次はそう来るかよw んじゃ、QPIって、何?
オレって釣られまくり?
298:名無しさん＠お腹いっぱい。
08/12/03 14:00:48 .net
>>293
それはさすがにバカ丸だしwwww Itaniumサイコー!!!!!!w
299:名無しさん＠お腹いっぱい。
08/12/03 14:05:08 .net
>>290
> OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？
SPARCナメてもらっちゃ困るな。SPARC64はシングルスレッド性能でもトップクラス。
300:290
08/12/03 14:07:06 .net
いっとくけど俺は293じゃないからな。
ItaniumはSPARCより駄目だと思ってるし
301:名無しさん＠お腹いっぱい。
08/12/03 14:09:59 .net
盛り上がってきたなぁ...ww
今何人参加してんだろp
302:名無しさん＠お腹いっぱい。
08/12/03 14:14:18 .net
>>292
うちでOracle RAC使った実アプリで検証した結果は
SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい
速かった。OracleライセンスやSANを入れた構築費は1/5くらい。
DBの話だから計算屋さんとは全然違った判断だと思うけど。
Opteronだとインターコネクトの帯域でこだわってる話題に
そぐわなくてすまんな。
Opteron 8CPU x2(RACノードとして)を超える必要が無いと
SPARCやItaniumは要らない。超える規模だと評価機借りるのも大変で
ベンダーの力も借りないといけないから、ベンダーのおすすめで
supredome/Fire x0Kクラスを評価して納得のいく性能が出たらそれを買う、という
流れになる。帯域がどうこうとかはいろいろある検討科目の一つに過ぎなくて
どうしてそんなにこだわる人がいるのか逆に疑問だ
303:名無しさん＠お腹いっぱい。
08/12/03 14:17:31 .net
>>296
SPARC64ねえ、それは確かにいいかもしれない。
機会があったら評価してみたい。富士通には縁が無いんだけど。
やっぱSPARC IV+より全然いいの？つかItaniumスレでする
話じゃないな
304:名無しさん＠お腹いっぱい。
08/12/03 14:24:15 .net
CINT2006
ASUSTeK Computer Inc. Asus P6T Deluxe (Intel Core i7-965 Extreme Edition) 33.6 30.2
Fujitsu Limited Fujitsu SPARC Enterprise M3000 12.6 11.5
305:名無しさん＠お腹いっぱい。
08/12/03 14:35:09 .net
p5も評価してみたいなあ。
でもアレだよね、今から評価するならCore i7ベースのXeonも
楽しみだよね。そういやXeonとItaniumでソケット共通にするって
話はどこいったの？あれが完成してればItanium用サーバーに
Xeon差したりもできたの？ってできないと意味ないか。
チップセットとかいろいろ考えたらいっそのことXeonをエンタープライズまで
対応できるようにすりゃいいじゃんって思わないでもない
306:名無しさん＠お腹いっぱい。
08/12/03 14:39:16 .net
>>294
QPIは、次の手。
FSBを4本、スヌープキャッシュ、FB-DIMMをデュアルチャネル2系統
ここまでは1チップに押し込むことはできたが、それ以上は厳しい。
かといって、このままでは、8コアや8ソケットはスケールしない。
だからQPI
307:名無しさん＠お腹いっぱい。
08/12/03 14:39:55 .net
とりあえず両方とも QPIになって、その次。
それまで Itanium系の開発が今の勢いで続いてれば、の話だけどw
308:名無しさん＠お腹いっぱい。
08/12/03 14:45:07 .net
>>302
Itaniumとソケット共通化で開発されていたXeonはキャンセルされて、従来通りのFSBのものが市場投入されました。
その後どうなったのかは、知らない。
だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。
309:名無しさん＠お腹いっぱい。
08/12/03 14:45:44 .net
>>299
> SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい
Hypertransportは共通バスじゃない。
> ベンダーの力も借りないといけないから、ベンダーのおすすめで
その「ベンダー」に扱ってもらうには、そこそこの性能が必要。
310:名無しさん＠お腹いっぱい。
08/12/03 14:48:50 .net
>>303
それ見ろ。今の Xeonは付け焼き刃対策してあるだけで、クロスバーへの
移行が必至なんじゃんか。そっちこそ往生際悪いぞ。
311:名無しさん＠お腹いっぱい。
08/12/03 14:52:55 .net
>>305
> だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。
Itaniumが邪魔になってる Intelとしては、
（ちょっとムリあったけど、がんばって）ソケット共通化しました
↓
性能も近いし、あんまり差別化できる点もないので、もう 1種類でいいですよね?
という大義名分で Itaniumを葬り去る絶好のシナリオ。
312:名無しさん＠お腹いっぱい。
08/12/03 14:58:44 .net
葬り去るっていうかIPFにいっちゃったPentium開発チームを
メインストリームのCoreに戻す策略だろうか。
しかもhp(元Alpha)の開発者というおまけつきで
確か元々Pentium開発2チーム、モバイルがイスラエル1チーム�
313:ﾅ IPFに1チームとられて、イスラエルチームがメインも作るように なったんだよね？ まあうまいことAMDと競争してくれて価格性能比のいいCPUが バンバンでてくれば裏事情なんかどうでもいいけど
314:名無しさん＠お腹いっぱい。
08/12/03 15:05:31 .net
>>307
QPIはクロスバーじゃないだろ。
で、段階的な進歩を付け焼き刃と言うのなら、Sunの第5世代E15Kも付け焼き刃だった、ってことになるぞ。
第4世代の6800らと同じCPU&メモリボードのアドレスを直に繋がずにスヌープフィルタ入れたのだから。
Xeonでスヌープフィルタを導入したのと同じことだぞ。
付け焼き刃だとしても、その時々に必要な性能を実現していれば、それでいいと思う。
むしろ、付け焼き刃もできずに、その時々に必要な性能を提供できなければ市場から脱落するし。
315:名無しさん＠お腹いっぱい。
08/12/03 15:08:45 .net
Sunの第四世代までと、第五世代のCPUボード内は、アドレスがクロスバーではなく、帯域を共有している
これは理解してもらえたかな?
Sunは6800のセールストークとして、
24ものプロセッサがフラットにアドレスを共有して素晴らしく低レイテンシなのは他にはない
といってたけど、たしかにキャッシュのヒット率が高い用途では、それは素晴らしいことなのかも。
・・・って言うと、Intelの共有バスにも当てはまる褒め言葉になっちゃうな。
316:名無しさん＠お腹いっぱい。
08/12/03 15:08:59 .net
Sun で言えば Mbus→UPAの段階だろ。
そんなんといっしょくたにされてたまるかw
317:名無しさん＠お腹いっぱい。
08/12/03 15:15:11 .net
>>312
いや、違うな、UPAより前の、MBus+XDBusの段階だ。
URLﾘﾝｸ(jp.sun.com)
318:名無しさん＠お腹いっぱい。
08/12/03 15:52:53 .net
SUNスレでどうぞ
319:名無しさん＠お腹いっぱい。
08/12/03 15:53:54 .net
>>312-313
おいおい。
UPAはアドレスはブロードキャストだぞ。
SunでアドレスのブロードキャストしないのはFirePlaneにSSMを組み合わせた場合。
320:名無しさん＠お腹いっぱい。
08/12/03 15:59:42 .net
メモリは別として、
FirePlaneのボードにUltraSPARC IIIを4つ積んだもの → 4コアXeonのCPUに相当
それをアドレスをブロードキャストで繋いだSun Fire 6800 → 4コアXeonを同一FSBに4つぶら下げたものに相当
アドレスのブロードキャストドメインを分割してスヌープフィルタで繋いだSun Fire 15K → 4コアXeonを個別のFSBで接続する7300チップセットのシステムに相当
Intelは常に他社の後追いですね。
321:名無しさん＠お腹いっぱい。
08/12/03 16:01:37 .net
もひとつ、
AMDのHyperTransport → IntelのQPI
猿まねも、ここまでくると呆れるを通り越す。
しかし、素直に進化の王道を進んでいるだけ、あるいは、業界トレンド、っていう好意的な見方もできなくはない。
322:名無しさん＠お腹いっぱい。
08/12/03 16:07:01 .net
>>315
いやいや。MBusに CPU4発。これを XDBusバックプレーンに接続。
1990年代初頭の技術だな。
323:名無しさん＠お腹いっぱい。
08/12/03 19:23:54 .net
>>318
そいつはスヌープフィルタなんか持ってないんだが。
324:名無しさん＠お腹いっぱい。
08/12/03 19:26:06 .net
いまだにクロスバー信者は、キャッシュのスヌープを理解してないのか。
325:名無しさん＠お腹いっぱい。
08/12/04 09:32:17 .net
アホか。スヌープせずに MPがまともな性能で動くかwww んなもんクロスバーかどうかと
関係ないわい。
なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
話にはならんだろうが。いつまで詭弁を弄するつもりよ?
326:名無しさん＠お腹いっぱい。
08/12/04 10:46:56 .net
興奮してる
327:名無しさん＠お腹いっぱい。
08/12/04 11:02:50 .net
>>321
スヌープの意味、わかってないね?
スヌープしなかったらキャッシュのコヒーレンシを実現できない。
> なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
> 話にはならんだろうが。
SunのFirePlaneは、4プロセッサ単位でスヌープのドメイン(バスに相当)を構成し、
ドメイン間の通信をスヌープフィルタによってブロードキャストからポイントtoポイントに変えることで、
飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK
という話なんですよ。
328:名無しさん＠お腹いっぱい。
08/12/04 11:36:55 .net
もうループに入りました。
..スヌープの意味わからずに SMPの話ができるわけないだろ。
Intelの言うことなんでもありがたくご拝聴してるからそんな偏った知識になる。
MBusにはスヌープの仕掛けがないとでも思ってるのか?
329:名無しさん＠お腹いっぱい。
08/12/04 11:38:52 .net
>>323
そんでもも一回だけ。
> 飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK
それが「付け焼き刃」だ、といってる。クロスバーみたいな根本対処と
いっしょにすな、と。
330:名無しさん＠お腹いっぱい。
08/12/04 11:44:47 .net
クロスバーと１回発言すると、どこからかお金が貰えるの？
なら俺も書こうかな。
331:名無しさん＠お腹いっぱい。
08/12/04 12:12:35 .net
「スヌープフィルター」は、金貰えるのか?
332:名無しさん＠お腹いっぱい。
08/12/04 12:33:17 .net
>>324
なんかね、>>321はスヌープフィルタのつもりでスヌープと言ってるっぽいのよ。
>>325
つまり、SunのFireplaneは、
「クロスバーみたいな根本対処といっしょに」できない「付け焼き刃」だって言いたいのね。
333:名無しさん＠お腹いっぱい。
08/12/06 11:05:00 .net
328でFAだな
言葉が通じているようで通じていない人と話をすることほど無駄なものはない。
334:名無しさん＠お腹いっぱい。
08/12/08 12:04:28 .net
Sun信者が無知だってことが明らかになりました
335:名無しさん＠お腹いっぱい。
08/12/17 03:08:26 .net
このスレ久しぶりに来たけどこの話題何回繰り返すんだろうなｗ
336:名無しさん＠お腹いっぱい。
08/12/17 05:01:14 .net
>>331
それは構って欲しいですっていう意味か?
337:名無しさん＠お腹いっぱい。
08/12/17 09:41:45 .net
「そっとしといてほしい」みたいだぜ。たとえ話題皆無でもw
338:名無しさん＠お腹いっぱい。
08/12/17 12:44:29 .net
Sunの糞信者に荒らされるよりは、何も話題がないほうがマシ。
339:名無しさん＠お腹いっぱい。
08/12/17 13:37:33 .net
なんか話題ないの?
340:名無しさん＠お腹いっぱい。
08/12/18 00:55:53 .net
話題無いって言う話題ぐらいしかないねぇ。。。
341:名無しさん＠お腹いっぱい。
08/12/18 01:06:54 .net
Itaniumを仕事で使っているような人は、いまどき2chなんかやらんだろ。
昔は2chにプロがゴロゴロしていて有益な情報交換がなされていたようだが。
342:名無しさん＠お腹いっぱい。
08/12/18 01:17:34 .net
4Q08に発表するという話だったのにまた遅延かという話題ならある
343:名無しさん＠お腹いっぱい。
08/12/18 13:09:47 .net
夢がふくらまないな...w
344:名無しさん＠お腹いっぱい。
08/12/18 13:20:17 .net
>>337
「昔」には 2chなんて「ない」と思うがww
345:名無しさん＠お腹いっぱい。
08/12/18 17:06:44 .net
2chの昔な。
346:名無しさん＠お腹いっぱい。
08/12/18 18:24:58 .net
Itaniumってコンパイラがもっと進化すれば爆発的に早くなるはずじゃなかったの？
もしかして「早すぎたんだ・・・」っていうやつなの？
347:名無しさん＠お腹いっぱい。
08/12/18 19:00:16 .net
x86が爆発的に性能向上してしまったので霞んでしまっただけです。
とはいえ初代のMercedは遅かった。
1年後に出たMcKinleyはは速かった。
クロックはたったの1割しか速くなってないのだが、スピードがまるで違った。
348:名無しさん＠お腹いっぱい。
08/12/18 19:06:18 .net
i860の Wikipediaにはこう書いてある。
| ...i860のデザインはこういったことをコンパイラが効果的に行うことを
| 前提としていて、それは不可能だったことが実証されている。
EPICは、どうかなww
349:名無しさん＠お腹いっぱい。
08/12/18 19:33:37 .net
>>344
おまえ、i860のアーキテクチャを理解してないだろ。
Wikipediaのその説明はパイプラインモードについてのものだよ。
350:名無しさん＠お腹いっぱい。
08/12/18 21:41:38 .net
>>342
最近ではHP-UX 11iV3で結構速くなったよ。
ただCPUがMontecitoのままじゃねえ。。。
コンパイラが神の様に賢くても理論演算性能を超えることは決してないからさ。
351:名無しさん＠お腹いっぱい。
08/12/18 22:46:44 .net
HPはさ、PA-RISCもベンチマークだけは速いけど実際は・・・っていうシロモノだったから、
IA-64になってもショックが小さいと思うんだわ。
352:名無しさん＠お腹いっぱい。
08/12/18 23:33:40 .net
Tukwila最強！
353:名無しさん＠お腹いっぱい。
08/12/18 23:44:30 .net
SPARCはベンチマークは駄目だけど、実際は・・・だけどな。。
354:名無しさん＠お腹いっぱい。
08/12/18 23:52:03 .net
SPARC最弱！
355:名無しさん＠お腹いっぱい。
08/12/19 00:03:15 .net
Sun信者ウザイよ。Sunの話はSunスレでやれよ。
356:名無しさん＠お腹いっぱい。
08/12/19 00:23:02 .net
そうだ、そうだ！
357:名無しさん＠お腹いっぱい。
08/12/19 02:14:45 .net
TukwilaもRockに対抗して250Wバージョンを出すべき！
358:名無しさん＠お腹いっぱい。
08/12/19 04:22:52 .net
URLﾘﾝｸ(www.anandtech.com)
上の記事のせいで海外の掲示板に「Tukwilaも爆速なんじゃね?」とか言い出す厨房が氾濫しているから困る。
359:名無しさん＠お腹いっぱい。
08/12/19 11:08:15 .net
>351
あわれだなぁ.. ここは Sunのとこから派生してできたんだって何度言えば..
Itaネタで埋まるくらい書いたらどうよ?
360:名無しさん＠お腹いっぱい。
08/12/19 11:11:15 .net
>>98-102
361:名無しさん＠お腹いっぱい。
08/12/19 11:38:07 .net
>>344
i860は、Itaniumと比べると、
意図と結果がはっきりしたすがすがしいプロジェクトだった。
CPUは消えたが、多くの豊かな結果が残った。
362:名無しさん＠お腹いっぱい。
08/12/19 12:34:49 .net
>>355
お前がスレに参戦する前からItaniumスレあったと思ったが。
>>357
翻弄された人たちは多かったけどね。
363:名無しさん＠お腹いっぱい。
08/12/19 14:16:08 .net
> お前がスレに参戦する前からItaniumスレあったと思ったが。
Niagara発表されたとき意味全くわからなかったアホを隔離するための場所なんだが
ここはwwww
364:名無しさん＠お腹いっぱい。
08/12/19 14:20:45 .net
>>345,357
i860じゃなくても、iAPX432でもいいんだけどwwww
| 後の研究では、もっとも大きな問題はコンパイラに有ったと指摘されている。
| すなわち、コストの低い..
365:名無しさん＠お腹いっぱい。
08/12/19 14:35:10 .net
>>345
意味不明だな。パイプラインをうまく満たせない、すなわち性能出ない、て主旨だぞ。
他に前提としてなんか理解してないといかんのかw? ワケワカランp
366:名無しさん＠お腹いっぱい。
08/12/19 14:37:38 .net
結局SPARC馬鹿がいないとスレが盛り上がらないのか
367:名無しさん＠お腹いっぱい。
08/12/19 17:04:17 .net
>>359
少なくとも前スレの冒頭から見てるけど、Sun信者が乗っ取った形だな。
>>361
そりゃ、i860のパイプラインモードがどんなものか理解していなければ、意味不明だろうな。
そういう点で、日本語のwikipediaのi860の説明はダメだな。英語版にはちゃんと説明があったと思う。
368:名無しさん＠お腹いっぱい。
08/12/19 17:34:34 .net
SPARCとItaniumでどっちが先に死ぬか競争だな
x86に統合されて先にItaが死にそうな気がするけど
369:名無しさん＠お腹いっぱい。
08/12/19 17:36:04 .net
どっちもなかなか死なないと思うよ
370:名無しさん＠お腹いっぱい。
08/12/19 22:33:43 .net
敵どころか己が持ちあげている物すら知らなかったSun信者が、Sunスレで勝利宣言しててﾜﾛﾀ
371:名無しさん＠お腹いっぱい。
08/12/22 11:11:00 .net
誰か >>366 解説してやってくれ。それか、医者へ連れてってやってくれ。
372:名無しさん＠お腹いっぱい。
08/12/22 13:53:15 .net
>>367
人に頼るなよ。
373:名無しさん＠お腹いっぱい。
08/12/29 11:09:30 .net
>>367
しらないなら
いばるなよ
だめ
こんさる
374:名無しさん＠お腹いっぱい。
08/12/31 10:49:27 .net
知ったかインチキが偉そうに
375:名無しさん＠お腹いっぱい。
09/01/01 11:42:53 .net
Itaサーバの中古、どっかに安いのはないかな
376:名無しさん＠お腹いっぱい。
09/01/02 09:26:25 .net
506 名前：MACオタ＞502 さん[sage] 投稿日：2009/01/01(木) 23:29:46 ID:os1mREWn
>>502
--------------
Tukwilaはどうなったんだ？もう2009年ですよｗ
--------------
更に遅れて今年の第2四半期になった模様す。
URLﾘﾝｸ(server.it168.com)
==============
??英特?将在2009年的第二季度将Tukwila正式推向市?。
==============
508 名前：MACオタ＞507 さん[sage] 投稿日：2009/01/01(木) 23:44:46 ID:os1mREWn
>>507
私も英訳して読んでいるす。
Intelの営業のヒトの話なので、特にネガティブなことわ書いてないす。
URLﾘﾝｸ(translate.google.com)
----------------------
Gu who also disclosed that next-generation Itanium platform Tukwila testing machines
have been sent to OEM manufacturers and important ISV, the partners are currently on
the database, ERP, high-performance computing applications such as authentication and
running the program, Intel is expected to be the second quarter of 2009 will be formally
Tukwila market.
----------------------
377:名無しさん＠お腹いっぱい。
09/01/02 13:18:49 .net
CPUだけ出してもしょうがないので、Tukwila搭載マシンの開発と両輪で進んでいるのだろう。
378:名無しさん＠お腹いっぱい。
09/01/02 13:27:02 .net
Tukwilaってまだやっていたのか
379:名無しさん＠お腹いっぱい。
09/01/04 01:06:02 .net
>>373
つまり、以前のように本気でチップセット用意してくれる企業が減った（無くなった?）
ということか。
380:名無しさん＠お腹いっぱい。
09/01/04 01:17:49 .net
当たり前だがHPはItaniumが死ぬまで真剣にやる。脱落？したのはIBM？ユニシス？これは結構古い話だよな？
ああ、富士通か？PRIMEQUESTの新モデル出ないの？やるとおもってたが。
ま、Tukwila以降では4コアより純正チップセットの復活が大きいな。
アンチIBMの旗の下集まったISAがようやく本格的に動き出すと思う。
Dellみてればわかるが純正はとにかく安いからな。
381:名無しさん＠お腹いっぱい。
09/01/04 01:25:27 .net
連投だがチップセットに合わせて投入するとしたらHPのsx/zxシリーズかIntel純正のBoxboroだよな。
富士通に歩調を合わせるとは思えんし。
でBoxboroのスケジュールはXeonMP(Nehalem-EX, Beckton)の2009年半ばだからこっちは時期的には合う。
HPだけ半年早くTukwilaのサーバー売れるようにしたら不満たらたらだろうしな。
382:名無しさん＠お腹いっぱい。
09/01/04 01:29:26 .net
ユニシスはNECと組んだ時点ではまだやる(NECに作ってもらう)って言ってなかったっけ？
最近、NECとの提携の成果であるXeonサーバ発表した時にはもうやらねって言ってたが
383:名無しさん＠お腹いっぱい。
09/01/04 01:43:51 .net
テープアウトしたとかファーストシリコンとかいって
2008年に出す出す詐欺
結構な偉業だと思う
てかもう製品出来てるだろ
古いプロセスに古い設計
減らされたとは言え数百人規模の開発チーム
出来てないわけがない
もうねHPのMCサーバー部門ごと買い取ればよかったのに
プロセッサのデザインチームだけと言わずにさ
で、みんなでIntel OEM
健全でしょ
Sunに置ける富士通的ポジションだよ
やってやれないことはない
まーこれは冗談だけど
Itaniumはねー絶対健全化できる
POWERやSPARCも一時期は駄目だったけど復調した
必要なのは社内でリーダーシップとってくれる人
予算でも人的リソースでもない
384:名無しさん＠お腹いっぱい。
09/01/04 01:55:55 .net
そうなんだ
385:名無しさん＠お腹いっぱい。
09/01/04 02:45:44 .net
Itaniumが担う領域って水平分業型だと信頼性が確保しきれないところだからね
HPのIntegrity部門ごと買った方が良かったってのは、あながち冗談とも言えないかも
でも、世の中のほとんどの業務は実はXeonMPの信頼性で十分なはずなんだよね
誰も人柱になりたくないから、メインフレームとかMCサーバ買い続けてるってだけで
Intelの本音としては、もうItaniumは辞めたいんじゃないかなあ
下手に健全化なんかしたら辞める口実が無くなっちゃうじゃないの
386:名無しさん＠お腹いっぱい。
09/01/04 14:12:06 .net
>>375
そうじゃない。
サーバのメーカーがチップセットを開発して搭載機の受注を開始できる体制になってからでないと、
CPUの出荷開始を発表できないの。
387:名無しさん＠お腹いっぱい。
09/01/04 14:17:33 .net
サーバのメーカーが
チップセットを開発して
搭載機を開発して、
ソフトウェアを開発して、
テストが済んで、
受注を開始できる体制
だな。
初代Itaniumは、そういうのが揃っていなくて、CPUが塩漬け状態だった。
かなりのステッピングがあるので、CPU自体のエラッタも沢山あったのだろうが。
388:名無しさん＠お腹いっぱい。
09/01/04 16:50:26 .net
だんだん馬脚が現れてきたなww 苦しさ満点。まあ、がんばってくれやw
389:名無しさん＠お腹いっぱい。
09/01/04 17:12:48 .net
↑何を言いたいのかさっぱりわからない書き込みだな
390:名無しさん＠お腹いっぱい。
09/01/04 17:34:52 .net
まぁ、いつものことだ。気にするな
391:名無しさん＠お腹いっぱい。
09/01/05 09:45:32 .net
やっぱメーカー関係者だったんだな、てことさ。
他に道がない、ということを解らんでもないが、後世振り返ってそこに価値を
見い出せるかということも考えた方がいいと思うぞ。
392:名無しさん＠お腹いっぱい。
09/01/05 12:21:52 .net
Sun信者さん、こんなところで荒らしてないで。
393:名無しさん＠お腹いっぱい。
09/01/05 13:51:11 .net
>>381
x86が多少延命した、と言っても別の将来性を見い出した訳でもなんでもなくて、
「先がない」のは Ita発表した頃に Intel自身が言ってた通り、何も変わってない。
で、問題はその代替えとして Itaがダメだってことで、これも何も変わってなくて、
もう確定事項。後は、プロセスの改良と x86のチューニングしか残ってない。
ARMもよー扱わんかった。
やっぱ、i960改良するのが正しいんじゃね?w バークレーRISCだしさwwww
394:名無しさん＠お腹いっぱい。
09/01/05 14:38:37 .net
>>389
どう見てもSun信者です。お引き取りください。
395:名無しさん＠お腹いっぱい。
09/01/05 15:02:13 .net
>>389
おまえ未だRISCが高性能だと思ってんのか。
396:名無しさん＠お腹いっぱい。
09/01/05 15:08:27 .net
>>379
> Itaniumはねー絶対健全化できる
> 必要なのは社内でリーダーシップとってくれる人
2つ問題がある。
一、Intelにその気がない。
二、たとえ健全化しても単に「健全」というだけでは
わざわざ新規 ISAに移行する動機付けにならない。
200x年代初頭の Itaが今のポジションだったとしても、厳しいねぇ。
なんせ x86を「置き換える」はず、だったんだから。目標到達にはほど遠い。
397:名無しさん＠お腹いっぱい。
09/01/05 15:09:13 .net
いまどきプロセッサの性能を決めるのは、メインメモリへのアクセスのレイテンシと効率。
命令セットのうち、レジスタ間や即値との演算の命令なんて、どうでもいい。
肝心なのは、メモリアクセスのための命令。
398:名無しさん＠お腹いっぱい。
09/01/05 15:12:27 .net
>>392
最終的にはx86は他の命令セットに移行する可能性がある。
それがIA-64とは限らないが。
いままで何度も、
バイナリトランスレータによる事前変換あるいはや実行時変換が試みられてきた
これからも、そのような試みは続けられる
そして、いつか、その試みは成功するだろう。
399:名無しさん＠お腹いっぱい。
09/01/05 15:13:23 .net
あら人気スレ
400:名無しさん＠お腹いっぱい。
09/01/05 15:13:26 .net
>>391
このまま EPICを置き換える VLIWな ABIが出てこなければ、
長期にわたる後方互換性の必要な ISAとして VLIWはダメ、ということになるだろな。
ちなみに、Intelみたいなどこにもマネのできんリソースをつぎこむことなく
CISCアーキを維持できてる会社どっかあんのか? 全部 RISCだろ?
401:名無しさん＠お腹いっぱい。
09/01/05 15:13:33 .net
ていうかSunはx86バイナリをSPARC上で実行する試み、やめちゃったの?
昔はやってたよね。
NiagaraとかRockがそんなに素晴らしい、スケールするのであれば、
x86バイナリをSPARC上で実行するサーバを出せば売れるだろう。
402:名無しさん＠お腹いっぱい。
09/01/05 15:14:11 .net
RISCは高性能だね
それ以外のは生き残れなかった
403:名無しさん＠お腹いっぱい。
09/01/05 15:16:47 .net
>>393
まるで間違い。それなら組込み機器も大規模 SMPも全部 x86になってるはず。
ところが、x86は実際にはパチョコン以外ではまるで使えない、用途限定石。
404:名無しさん＠お腹いっぱい。
09/01/05 15:17:38 .net
>>396
VLIWって互換性を捨ててるアーキテクチャでしょ。
自分でmakeすりゃいいじゃんっていうオープンソース文化の人たちや、
互換性のために生の命令セットは見せないというアプローチ、
あるいは組込みなんだから、互換性とか関係ないねって分野でないと、
VLIWは難しい。
そのVLIWの問題点を解決した、VLIW風だがVLIWではないEPICは、
いまのところ長期にわたるバイナリ互換を確保できていると思う。
試していないが、現行のバイナリは初代Itaniumでも実行できるんじゃね?
バンドルの組み合わせが増えてる分は例外でエミュレーションで劇遅かもしれんが。
405:名無しさん＠お腹いっぱい。
09/01/05 15:21:08 .net
>>396
Centaur Technologyを忘れないでください。
>>399
あなたは偏見と罵倒前提で曇った目で他人の書き込みを読むから、意図が理解できないのですよ。
x86のメモリアクセスのための命令がネックで大規模SMPの効率が悪いって示唆してるんですがね。
ちなみに組込みではx86は目立たないけど使われ続けてます。
私の目の前に有るDELLの液晶モニタはOSDコントローラがx86ですよ。
406:名無しさん＠お腹いっぱい。
09/01/05 15:27:20 .net
そのケンタウロスは生きているのか死んでいるのか
407:名無しさん＠お腹いっぱい。
09/01/05 15:35
408::29 .net
409:名無しさん＠お腹いっぱい。
09/01/05 15:42:57 .net
そりゃ安いか速いか少なくともどっちかは満たさないとねえ
410:名無しさん＠お腹いっぱい。
09/01/05 15:55:38 .net
え? SunのNiagara2はXeonとは比べ物にならないほどコストパフォーマンスがいいんでしょ?
411:名無しさん＠お腹いっぱい。
09/01/05 15:57:21 .net
x86は命令セットがスケールしない仕様なので、たとえSPARCの命令セットに変換してもスケールしないだろ。
412:名無しさん＠お腹いっぱい。
09/01/05 16:09:32 .net
>>405
そういう意味ではない。あんたの思いつく程度のことは RISC WS陣営がとっくに
やったし、Itaもそれ以上のことはしていない。
当初 Intelが言ってた、「x86を置き換える」ことができなければ、
あまり存在意義があるとは思えない。
金持ってるから、今の位置付けのまま維持することは可能だろうけど。
株主につつかれなきゃ。
413:名無しさん＠お腹いっぱい。
09/01/05 16:19:09 .net
>>401,406
なるほど! じゃ、その効率の悪い「メモリアクセス命令」を禁止したサブセットを
定義して、コンパイラーにスイッチ付ければすべて解決じゃん!!
すげーな、スケールしまくりの新 x86アーキ! 期待してるよw
:
もちろん、RISCに似ちゃったり. ...しないよね?wwww
414:名無しさん＠お腹いっぱい。
09/01/05 16:28:24 .net
>>407
x86を置き換えれなかったからといって、存在意義がないとは言えん。
x86では届かない部分をカバーするという意味はあるし、
その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。
>>408
別にコンパイルするなら、x86である必要ないじゃん。
最初からSPARCをターゲットにコンパイルすりゃいい。
Sun信者はいつも、意図的に間違った方向に話を持っていくね。
415:名無しさん＠お腹いっぱい。
09/01/05 16:35:58 .net
>>409
> x86を置き換えれなかったからといって、存在意義がないとは言えん。
もちろん、「もう優秀な RISC ISAがたくさんあるんだから、」その上には
必要ない、という意味。
> x86では届かない部分をカバーするという意味はあるし、
> その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。
それも同じ。わざわざ Itaでやらんでもよい。もうたくさんある。
> Sun信者はいつも、意図的に間違った方向に話を持っていくね。
はっはっはっはっ。君、おもしろいね?w
416:名無しさん＠お腹いっぱい。
09/01/05 16:47:47 .net
>>410
Intelにとっては、というのは明記しなくても、読み取れるだろうが・・・
417:名無しさん＠お腹いっぱい。
09/01/05 16:50:19 .net
アホか。その前のを読み取ってないのはオマエじゃw ほんとにオモロイなk
418:名無しさん＠お腹いっぱい。
09/01/05 16:53:17 .net
はい>>412が誰かを煽ることを目的にスレに粘着していることを白状しました。以後スルー推奨。
419:名無しさん＠お腹いっぱい。
09/01/05 16:58:21 .net
「誰かを煽る」んじゃなくて、単にアホにアホと言ってるだけなんだが。
妄想ハゲしいねww
420:名無しさん＠お腹いっぱい。
09/01/05 16:59:09 .net
なんつーか、この苦し紛れさ加減はwwww
421:名無しさん＠お腹いっぱい。
09/01/05 17:09:36 .net
消費電力が少なくてやっすいのを一台なんとか
422:名無しさん＠お腹いっぱい。
09/01/05 17:12:10 .net
>>414-415
連投しないと気がすまない病?
423:名無しさん＠お腹いっぱい。
09/01/05 17:43:01 .net
>>417
偽・スルー みんなにスルーを呼びかける。実はスルーできてない。
失敗スルー 我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
疎開スルー 本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
3つはあてはまるなww
ここからスルーできるかな～?www おかしーw
424:名無しさん＠お腹いっぱい。
09/01/05 17:48:51 .net
うれしそうですね
425:名無しさん＠お腹いっぱい。
09/01/05 18:14:24 .net
>>399
>まるで間違い。それなら組込み機器も大規模 SMPも全部 x86になってるはず。
SMPサーバーで性能でないのはx86だからじゃないだろ・・・
Chip-to-Chip、あるいはBoard-to-BoardのInterconnectが安かったりネットワークのトポロジが不適切だからだ。
技術的にx86でやれないことはないんだよ。実際ItaniumとXeonMPでプロセッサバスとチップセットを互換にするしね。
競合のIBM POWERの強さや既に開拓したItanumの市場、そういった諸々の要素を勘案して見込みがないと判断したのだろう。
リスクとベネフィットを秤にかけたわけだ。
逆に組み込み向けではAtomで真剣に参入を始めたよ。儲かってたXScaleをも売却したのだから本気も本気さ。
達成できるか怪しいが目標は100億ドルの市場へ成長させることと言ってるよ。
SMPサーバー向けのCPUでこれだけの売り上げは見込めないよね。箱全部の値段ならともかくさ。
色々考えてから書き込もうよ。安易に「まるで間違い」とか言う前にさ。
426:名無しさん＠お腹いっぱい。
09/01/05 18:20:13 .net
SPARC liteが組込みに使われていた・・・ってのも過去の話だよね。
そのうちAtom採用のデジカメとか、個人向けプリンタ・スキャナ複合機が出てくるだろうね。
そんな無駄だろ? って思うかもしれないが、開発のしやすさがまるで違うんだわ。
427:名無しさん＠お腹いっぱい。
09/01/05 22:47:24 .net
おまえら仕事しろ
428:名無しさん＠お腹いっぱい。
09/01/06 09:53:30 .net
>>421
> 開発のしやすさがまるで違うんだわ。
そんなバカなww 「既存の xxがあるから」、だろ? そりゃ他知らんだけ。
429:名無しさん＠お腹いっぱい。
09/01/06 10:17:57 .net
>>423
じゃぁ何でx86が組込みに使われてると思ってんだ?
430:名無しさん＠お腹いっぱい。
09/01/06 13:31:40 .net
「使われてる」なんて言うほど使われてないよ。80186の類はいっぱい使われてるけどな。
431:名無しさん＠お腹いっぱい。
09/01/06 13:43:25 .net
SPARCとどっちが多い?
432:名無しさん＠お腹いっぱい。
09/01/06 13:44:16 .net
東芝のHD DVDレコーダーは、x86だったな。
80186とかそんな非力なのではなくて。
433:名無しさん＠お腹いっぱい。
09/01/06 13:44:46 .net
だから失敗したのか
434:名無しさん＠お腹いっぱい。
09/01/06 13:46:44 .net
そうだな。SPARCだったら大成功だったところだ。
435:名無しさん＠お腹いっぱい。
09/01/06 13:50:17 .net
HD DVDプレーヤーにMobile Pentium4 2.54GHzが積まれててﾜﾛﾀ。
436:名無しさん＠お腹いっぱい。
09/01/06 13:59:37 .net
そういうのはパソコンまるごとから削ったタイプのやつだな。
組込み全体から見たら僅かに過ぎんが.. もうひとくくりで語るべきじゃないだろな。
今後増えるだろし。
437:名無しさん＠お腹いっぱい。
09/01/06 14:34:37 .net
Itaniumの話をしてください
438:名無しさん＠お腹いっぱい。
09/01/06 16:19:03 .net
>>431
組込み全体の話なんかナンセンスだよ。
組込みのうちSPARCが使われている領域の話に限定しなよ。
NASなんかは、「パソコンまるごとから削ったタイプ」そのものだよ。
439:名無しさん＠お腹いっぱい。
09/01/06 17:21:52 .net
「x86に将来性なし」ってのは別にオレが言ったことでもなく、
ここの誰が言ったわけでもなく、Intelが言ったことなんだが。
なんでこう諦めが悪いかなww
んでもって、そんな x86の諦め悪いやつがなんでここにいるんだ?
amd64のデキがよかった、Meromのデキがよかった、Atomのデキがよかった、
そんなことが「x86の将来性」ないのを覆した、とか思ってるわけ?
先延ばししただけでしょ、どうヒイキ目に見ても。
440:名無しさん＠お腹いっぱい。
09/01/06 17:40:40 .net
Intelが間違わないという保証があるわけじゃないな
441:名無しさん＠お腹いっぱい。
09/01/06 17:52:44 .net
>>434
お前、なんで必死なんだ?
442:名無しさん＠お腹いっぱい。
09/01/06 18:19:52 .net
命令セットがどうこうってのは20年ほど前の議論だよな
結果から言えば当時の人たちはトレンドを読み外したということでFA
443:名無しさん＠お腹いっぱい。
09/01/06 18:43:40 .net
何の話してんの?
444:名無しさん＠お腹いっぱい。
09/01/06 18:46:11 .net
分からないなら黙ってればいいのに
445:名無しさん＠お腹いっぱい。
09/01/06 18:47:11 .net
なんでそんなに必死なの? ..w
446:432
09/01/06 19:22:22 .net
Itaniumのことだけ書いてください
447:名無しさん＠お腹いっぱい。
09/01/06 19:30:57 .net
Itaniumの話か。
AMDにIA-64を採用するように働きかけなかったIntel
IA-64を採用しようとしなかったAMD
この2社が、世界のパソコンの将来に大きな負債を残した
448:名無しさん＠お腹いっぱい。
09/01/06 19:49:43 .net
そうだな。その後 IA-64がコケたとしても、今とは別の展開があっただろう。
あんまり期待できんがw
「両者それぞれ am29k, i960を復活、バークレーRISC乱立の混迷へ」...w
449:名無しさん＠お腹いっぱい。
09/01/06 20:01:52 .net
IA-64の命令セットと、プロセッサの実装を、分けて考えないと。
技術力のないインテルの実装だからItaniumがアレなんであって、
技術力の優れたAMDが実装すればIA-64でありながら素晴らしい
プロセッサが出来あがっていたかもしれないぞ。
IA-64の、とりあえず実行して結果を捨てるのは消費電力的に無駄が多いが、
現状のx86の、複雑なデコードや、同時に実行できる命令を探したり・・・etcの消費電力も大きい。
IA-64の場合、実行ユニットを減らすことも可能で、SPARCのレジスタ数によるスケールよりは、よっぽどスケールする。
初代はともかくMckinley以降はさほど悪くない。
もしインテルがx86と同じだけのリソースを割いて最先端のプロセスで生産すれば、違ったことになってただろう
とはいえ、x86と同じだけのリソースを割くなんて、ありえない仮定だが。
450:名無しさん＠お腹いっぱい。
09/01/06 20:27:44 .net
Itaniumの一番ダメな点 = レジスタウィンドウもどきを実装していること。
451:名無しさん＠お腹いっぱい。
09/01/06 20:48:30 .net
Itaniumの一番ダメな点 = EPICじゃないの？
452:名無しさん＠お腹いっぱい。
09/01/06 20:49:26 .net
2001年頃にAMDが潰れてればx86からIA-64への強制的な移行が推進されたのかもな
今は”やっぱり命令セットは拡張できる方がイイヨネ！”って時代なのでありえない話
453:名無しさん＠お腹いっぱい。
09/01/06 21:09:40 .net
Intelが用意していた(AMD64ではない)x86の64ビット拡張は、IA-64とは違うものだったらしいですよ。
454:名無しさん＠お腹いっぱい。
09/01/06 21:10:51 .net
なんだかやる気のないやつね
455:名無しさん＠お腹いっぱい。
09/01/06 21:35:18 .net
どうせAMDにペースを握られたくないという理由だけで策定した間に合わせのものだろう
あるいはx86_64よりIA-64のほうがいいよねって流れに誘導したかったんじゃないかと
456:名無しさん＠お腹いっぱい。
09/01/06 21:40:39 .net
まあそれでもちゃんとキャッチアップしてCore2DuoとかCore i7出したんだから
結果的にはよかったんじゃないかな。
457:名無しさん＠お腹いっぱい。
09/01/06 21:50:34 .net
それにしたってAMD64は、ヤッツケ仕事すぎる。
命令セットを大きく拡張あるいは変更できるチャンスというのは、
16→32ビット、32→64ビットの次は、64→128ビット・・・はないだろう。
だから、16→32ビットの時よりも遥かに将来を見通して策定すべき。
にもかかわらず、目先のことだけ考えた安易な拡張。これはひどい。
レジスタをすべて等価にするのではなく、2段階のコストにした点は評価できる。
良く使うレジスタは速く、あまり使わないレジスタは遅くというのは、
RISCが旗印にしていた定量的アプローチ、だものね。
458:名無しさん＠お腹いっぱい。
09/01/06 21:54:06 .net
まあインテルさんがIA64とかにかまけてないでまじめに
x86の拡張をかんがえてればよかったんじゃないのかなー
まあ状況的に無理だけど
だから次善の策としてamd64はよかったんじゃないかな
459:名無しさん＠お腹いっぱい。
09/01/06 21:55:59 .net
>>451
なんかIntelやばいんじゃね？と思ったら常勝の帝国軍へ戻っていた
な、なにを言ってるのかわからねーとおもうが(ry
460:名無しさん＠お腹いっぱい。
09/01/06 22:03:21 .net
x64だっけ?
アセンブラのニーモニックのレベルではx64のそれでいいとしても、
せめてオペコードなどの割り当ては真っ新からやり直すべきだった。
32ビットと64ビットでデコーダを共用できなくなるが、
だがしかし、ここでキレイに整理しておけば、後々かなり楽になる。
461:名無しさん＠お腹いっぱい。
09/01/07 07:04:56 .net
オペコードが人間が綺麗と感じるように割り当てられてることにどんな意味があるの？
462:名無しさん＠お腹いっぱい。
09/01/07 10:43:16 .net
> オペコードが人間が綺麗と感じるように
はいはい、意図的に誤解して架空の話を叩いて喜んでないで仕事しようね。
463:名無しさん＠お腹いっぱい。
09/01/07 10:43:26 .net
デコーダがシンプルになる...いまどきどうでもよいが。
将来の拡張の余地が広がる。これは大きい。
464:名無しさん＠お腹いっぱい。
09/01/07 10:45:34 .net
AVXでおk
465:名無しさん＠お腹いっぱい。
09/01/07 10:54:44 .net
AVX?
あれ長いよ。
たった1バイトしか短くならない・・・1バイトでも短くなることは重要ではあるし、
その次の拡張で長くならないことも重要なのだが、グダグダっしょ。
466:名無しさん＠お腹いっぱい。
09/01/08 15:11:25 .net
ほれ見ろ。オレがネタ投下してやんないとなんも出んがなw
467:名無しさん＠お腹いっぱい。
09/01/08 15:13:49 .net
安くて消費電力の少ないIta2マシンどっかに落ちてないかな
中古でいいよ
468:名無しさん＠お腹いっぱい。
09/01/10 00:42:48 .net
そんな製品がないんだから中古なんてなおさらあるわけないw
複雑化の原因はコンパイラにまかせてコアは単純化されてるはずだから
キャッシュ減らしたら電力食わないんだろ、きっと。そうに違いないwww
469:名無しさん＠お腹いっぱい。
09/01/10 20:06:22 .net
キチガイはスルーで
470:名無しさん＠お腹いっぱい。
09/01/10 21:05:06 .net
>>433
NASとCPUと言えば、AuspexがSPARCでやっていたのを、
廉価NAS構成に対向しようとx86に移行しようとして失敗沈没してﾜﾛﾀ
コントローラはSolaris for x86で問題なかったけど、
独自ファームのエンジンがどうにもならなかったみたい。
やっぱCPU移行は慎重にやらないとね。
本当にメリットがあるのかどうか。どのCPUでも。
>>452
AMDはそういう路線だからしかたないんじゃ？
コストかけて研究部門維持するわけにもいかないし。
471:名無しさん＠お腹いっぱい。
09/01/10 21:23:58 .net
AMDを責めてもしかたないわな。
水先案内人としての責任は、牽引する立場のIntelにある
472:名無しさん＠お腹いっぱい。
09/01/10 21:28:21 .net
市場を完全に制圧してからやるべきだったね
その辺Microsoftは賢い
473:名無しさん＠お腹いっぱい。
09/01/10 21:33:14 .net
AMDはIntelの失敗を修正する役割があると
474:名無しさん＠お腹いっぱい。
09/01/10 21:36:05 .net
>>452
Intelの最適化まぬあるによると増えたレジスタは使うなというｗ
475:名無しさん＠お腹いっぱい。
09/01/10 21:38:25 .net
あはははは
476:名無しさん＠お腹いっぱい。
09/01/10 22:12:26 .net
>>467
そのほうが消費者の利益になったとしても、独占ってだけで叩かれるぞ。
個人的にはAMDのIA-64実装を見てみたかった。
>>468
Intelを牽制する役割、だろうな。
>>469
IntelのCPUだと増えたレジスタを使った場合に、ガクンと遅くなるんだよな。
そりゃ、使うなと書いて当然だ。
こういう新しい命令セットってのは、互換性が重要なのよ。
最初にインプリしたCPUでは、速く実行できる必要はなくて、とにかく、正常に実行できることが重要。
その命令セットを実行できるCPUが市場に十分に出まわった時点で、本格的にソフトが使いはじめる。
この時点で、その命令セットを高速に実行できるCPUを市場に投入すればいいの。
まったく実行できない
と
遅いけど実行できる
というのでは、まるでインパクトが違う。
うまく移行するためには、早くから種まきしておかないと。
477:名無しさん＠お腹いっぱい。
09/01/10 22:22:44 .net
命令長伸ばしてレジスタ拡張なんて最近流行の電力効率に反する実装だからだよ
AVXの目的もそういうことだ
478:名無しさん＠お腹いっぱい。
09/01/10 22:32:30 .net
やっぱり、64ビット拡張するときに、OPコードを大胆に整理すべきだったんだよ。
モードによって違うのはデコーダのコストが増えるが、
しかし、
命令長が長いのに比べたらマシだと思うんだわ。
もったいないよ。使わない命令が短くて、使う命令が長いのは。
479:名無しさん＠お腹いっぱい。
09/01/14 01:57:08 .net
なんか自作板にTukwilaはDDR3サポートに変更になったとか書き込みがあった。
480:名無しさん＠お腹いっぱい。
09/01/14 12:11:19 .net
そうなればそうなるわな
481:名無しさん＠お腹いっぱい。
09/01/14 12:58:33 .net
以前からDDR3系のFB-DIMM2も対応予定に入ってなかったっけ？
それともFB-DIMM1のサポート無くしたという意味かな。
482:名無しさん＠お腹いっぱい。
09/01/14 16:18:08 .net
え?
FBってのは、DRAMチップのI/Fが変ってもOKっていう柔軟性も兼ね備えているんじゃないの?
483:名無しさん＠お腹いっぱい。
09/01/14 16:39:30 .net
2007年の時点で、
DDR3を使ったFB-DIMMの提供予定はない
っていう話だった。
484:名無しさん＠お腹いっぱい。
09/01/14 16:40:48 .net
FB-DIMMやめて直にDDR3のメモリコントローラを積むって話では?
485:474
09/01/14 22:32:03 .net
>>478
そのあとFB-DIMMのバッファチップをマザーボードに置くとかいう話が出てきた。
そうするとスロットに挿すメモリはDDR3だけどMCHのインターフェースはFB-DIMMになる。
>>479
うん、そんな感じだった。
486:名無しさん＠お腹いっぱい。
09/01/14 23:08:59 .net
へー、直結にするんか。
まあ、その方がレイテンシ短くできるだろうし、やるかどうか怪しいけど
Xeon-MPとのプラットフォーム共通化も進めやすいだろうし。
それで発売が遅れてるんだったら、まあ建設的な理由だな。
487:名無しさん＠お腹いっぱい。
09/01/15 03:06:16 .net
そもそもFB-DIMMって、
メモリコントローラをチップセットに持たせた時に、
大量のメモリを積むためのもの。
チップセット1つから、メモリのバスを12本とか出せないんでね。
ところが
QPIを導入した時点で、
CPUの数だけメモリコントローラを増やすことができる。
メモリのバスを3本もつCPUを4ソケット構成にすれば、
無理なく12本のメモリバスが得られる。
488:名無しさん＠お腹いっぱい。
09/01/15 03:13:48 .net
DDRのままではコア数はどんどん増えるのに帯域はあまり稼げないしピン数も爆発的に増える。
シリアルメモリは絶対必要。なのにFB-DIMMは死んでDDR4はどんどん先送りされている。
Nehalemでは痛みに耐えて3chにしたけど1年後には6コアのWestmereが来る。焼け石に水。
高速なローカルメモリの使えるLarrabeeでどうにかなるという読みなのかね。
489:483
09/01/15 03:25:32 .net
忘れていたが。。。Sandy Bridgeでon-package memoryとかいう噂もあったね。。。
SandyBridgeもNehalem同様processor coreのmicroarchitectureの変更は控えめでmemory回りの強化が主眼になる予感。
それでも十分new-architectureなのだけど。。。
URLﾘﾝｸ(www.intel.com)
これ、ItaniumでもPoulsonで採用されるのかな。コスト的なハードルはItaniumの方が低いと思うが。
490:名無しさん＠お腹いっぱい。
09/01/15 09:06:15 .net
>>483
Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
>>484
それは大容量のL3やL4のキャッシュを乗せようという話だと思います。
491:483=484
09/01/15 22:37:30 .net
>>485
>Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
>少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
うん、それはわかっている。
帯域が必要な分野にはLarrabeeを充ててキャッシュでそこそこ何とかなるサーバー向けCPUはのんびりいくのかなと。
Montecitoなんか未だにFSB533MT/sだもんね。144bitバスとは言え。。。
>大容量のL3やL4のキャッシュを乗せようという話
IntelのスライドによるとSandyBridgeのon-package memoryの容量は512MBとかだから従来のキャッシュとは桁が違う感じ。
これだけ容量が大きくなると制御法も従来の延長では駄目で一工夫要ると思われる。。。要するにキャッシュになるのかわからない。
まあ古いスライドなので変更された可能性もあるんだが。。。
スレ違いなのでこの辺で。
492:名無しさん＠お腹いっぱい。
09/01/15 22:45:35 .net
FSBのデータバスの転送だけ速くしても、アドレスバスの処理能力が先にネックになったら無駄なわけで。
そのあたりは難しいよね。
データはとにかく転送すりゃいいんだけど、アドレスは処理しなきゃならないから。
493:名無しさん＠お腹いっぱい。
09/01/16 13:59:49 .net
NECのＡＣＯＳ使ってるけどやっぱ、古いよな？
494:名無しさん＠お腹いっぱい。
09/01/16 14:01:15 .net
それで済むならそれでいいじゃん
495:名無しさん＠お腹いっぱい。
09/01/16 19:56:37 .net
電気代考えると..
496:名無しさん＠お腹いっぱい。
09/01/16 20:01:13 .net
電気代の差額ｘこれからの使用年数 が導入費用と同じ桁になるなら考えてみれば
497:名無しさん＠お腹いっぱい。
09/01/16 20:58:10 .net
いや。所有者のコストじゃなくて地球のコスト。
498:名無しさん＠お腹いっぱい。
09/01/16 21:11:36 .net
新規導入しないほうがいい
499:名無しさん＠お腹いっぱい。
09/01/17 13:11:38 .net
移行に失敗したときのリスクも考えよう。
現状のランニングコストと導入コストが一緒だから、
タダでシステムが新しくなりますよ?
なんていうセールスはアヤシイ
500:名無しさん＠お腹いっぱい。
09/02/02 12:06:16 .net
「ＸＸなんていうセールスはアヤシイですよ」っていうやつがもっとアヤシイ。
501:名無しさん＠お腹いっぱい。
09/02/05 01:02:27 .net
Intel delays Itanium upgrade to add new capabilities
URLﾘﾝｸ(www.networkworld.com)
502:名無しさん＠お腹いっぱい。
09/02/09 04:41:33 .net
>>496
Sunの広告が表示されるページの内容なんて・・・
503:名無しさん＠お腹いっぱい。
09/02/09 07:03:05 .net
あははははは
広告って効果的だね！
504:名無しさん＠お腹いっぱい。
09/02/11 19:42:05 .net
Tukwila、もう出ないんｼﾞｬﾏｲｶ。
URLﾘﾝｸ(www.atmarkit.co.jp)
505:名無しさん＠お腹いっぱい。
09/02/12 10:51:40 .net
いよいよ i960が 64bit、QPIになって復活します。
506:名無しさん＠お腹いっぱい。
09/02/13 10:55:34 .net
次世代 ISAのために HPと組む、というのはもう失敗したので、
次どっかと組む必要ありだろうな。
ARMは捨てちゃったし。Alpha買ってくる、とかw
いずれにせよ、もう新しい ISAを定義する必要はない。
POWER対抗、という軸で考えると、SPARCという選択肢もあるかもw?
507:名無しさん＠お腹いっぱい。
09/02/13 11:07:16 .net
SPARCみたいな変態アーキ使うくらいだったら、
素直にそのままIA64で続行してても大して変わらないし、
SPARCのインストールベースを狙いたいんだったら、
x86でItaniumクラスのCPU作る方が遙かに良いだろ。
508:名無しさん＠お腹いっぱい。
09/02/13 11:56:34 .net
IA-64はオープンソース方面がぜんぜん関心示さないのが致命的でしょ。
性能出せるコンパイラーが CPU開発してる近辺からしか入手できないという
ことだと、利用が拡がらない。
509:名無しさん＠お腹いっぱい。
09/02/13 12:27:42 .net
しかし、それを言い出すとやっぱりx86 ISA最強になってしまうだろう。
それにこのクラスのCPU使う所って、そんなにオープンソース使うか？
エンプラに限らず、ハイエンドから組み込みまで狙うっていう話だったら
別だけどね。
そのエンプラでさえIA64が流行らない最大の理由はintelのやる気の
なさにつきるだろう。
POWERだって一時はイマイチだったけど、POWER4あたりからの
IBMの気合いの入れっぷりを見て皆ついて行って、成功したんだし。
2～3年に1回、ライバルに対して半世代遅れな性能の製品しか出て
こない様では誰もついて行かないよ。
510:名無しさん＠お腹いっぱい。
09/02/13 12:30:06 .net
>>501
AlphaってHPじゃんw
そもそもItaniumみたいなVLIWならともかく、
古典的なISAをまた始める意味は全くないでしょ。
箱ごと売っているSPARCとPOWER以外は死滅したわけだし。
511:名無しさん＠お腹いっぱい。
09/02/13 12:32:05 .net
>>504
やる気はあったけど、うまくいかなかったんだよね。
なにしろSunまでItanium Solaris出してたんだから。
512:504
09/02/13 12:40:26 .net
>>506
Solaris/ia64は計画段階でやめたんじゃ無かった？
intelもMadisonだした直後くらいまではやる気あったと思うけど、
その頃からx86でAMDに押されまくって、IA64なんて言ってる
騒ぎじゃなくなってからの放置っぷりが酷すぎる。
んで、Core MA出てからは、もうサーバーもこれで良いんじゃないという
流れになって、ますますやる気ナッシングに。
そして、今度出るNehalem-EXとか見るとRASもかなり意識していて、
もうIA64やる気無いだろうと思ってしまう訳で。
513:504
09/02/13 12:45:20 .net
あとは個人的妄想だけど、NECと共同出資で富士通あたりが引き取れば
いいのにとか思ってしまう。
レジスタウィンドウもどき持っている辺り、SPARC 64と同じ変態系だしなｗ
514:名無しさん＠お腹いっぱい。
09/02/13 13:10:24 .net
>>503
オープンソースな人たちはgccを使うわけだが、そのgccの生成するIA-64のコードが酷かった。
さらに人間がバイナリレベルでデバッグするのが難しく、さらに、マシンチェック回りはアマチュアには無理。
つーわけで、オープンソース方面ではIA-64バッシングが激しかったんだよ。
515:名無しさん＠お腹いっぱい。
09/02/13 13:15:59 .net
>>505
> そもそもItaniumみたいなVLIWならともかく、
いやいや、VLIWがやっぱり長期互換性の必要な ISAとしてはダメってことを
証明したんでしょ、Itaniumがさ。
> 古典的なISAをまた始める意味は全くないでしょ。
RISC最強w
516:名無しさん＠お腹いっぱい。
09/02/13 13:17:17 .net
>>509
つまりそれは「バッシング」じゃなくて、「正しい見解」、じゃんか。
しごくまっとうな言い分だと思うけど。
517:名無しさん＠お腹いっぱい。
09/02/13 13:19:12 .net
>>509
最後の一行は君の妄想だと思うw
518:名無しさん＠お腹いっぱい。
09/02/13 13:23:17 .net
>>510
いえいえ、x86最強でしょう。
ARM - x86 - POWER(SPARC)の棲み分けでいいんじゃないでしょうか。
しかしIntelは、x86の省消費電力で出遅れたり、
経営戦略の方がさっぱりですね。
519:名無しさん＠お腹いっぱい。
09/02/13 13:23:23 .net
>>505
HPとSamsung（とAPI）が持っていると思われる権利をある程度買ってくれば
なんとかなるかもね
520:名無しさん＠お腹いっぱい。
09/02/13 13:30:58 .net
>>510
静的最適化の世代間互換を諦めていれば、性能はともかく
バイナリ互換は残せるので、もっと早く進歩できたと思うんだけどね。
最初に短いパイプラインで出してしまったので、それを前提にした静的
最適化の効果を残そうとすると、パイプラインを長くする事ができなくて、
クロックが伸び悩んだというのが躓き始めだと思う。
かといってOoO実行に走ると、そもそもEPICの意味がってなるしね。
521:名無しさん＠お腹いっぱい。
09/02/13 13:34:44 .net
Samsungへのライセンシングは終了してるんじゃないのかな。
522:名無しさん＠お腹いっぱい。
09/02/13 13:39:58 .net
>>515
「静的最適化の世代間互換」は、今から諦められないの?
要は、バイナリ互換だけど昔コンパイルしたバイナリは遅い、ってことよね?
まあ、そんな珍しい話でもないよね。程度もんだけど。
523:名無しさん＠お腹いっぱい。
09/02/13 13:42:57 .net
>>514
なんか、DECの残党かき集めたやつが勝ち、みたいな雰囲気感じるんだけど、
気のせい?w
524:名無しさん＠お腹いっぱい。
09/02/13 13:47:06 .net
>>517
マルチコア、マルチタスク環境下で混在すると、
うざいことこの上ない。
525:名無しさん＠お腹いっぱい。
09/02/13 13:53:01 .net
>>517
OoOプロセッサだと最適化世代が違ってもそれなりに動くが、
インオーダプロセッサだと性能の落ち方が大きいし、あとまあ
519の言うような事もあるだろうな。
ということでHPが嫌がって、アグレッシブプランは葬り去られた。
526:名無しさん＠お腹いっぱい。
09/02/13 13:58:53 .net
古いパイプラインのエミュレータを置けって事だからね。
iOにした利点の全てが吹っ飛ぶ。>>515と並行関係にある問題。
527:名無しさん＠お腹いっぱい。
09/02/13 16:13:01 .net
んじゃ、詰んでんじゃん。ダメじゃんww
528:名無しさん＠お腹いっぱい。
09/02/13 16:20:01 .net
やっぱ ISAは RISCで択一。
529:名無しさん＠お腹いっぱい。
09/02/13 16:30:33 .net
>>510
互換性のシガラミとしては、遅延スロットに比べればマシだろ。
>>511
酷いコンパイラを作っておいて、それを使ってパフォーマンスが出ないとか、もうね。
>>512
IA-64は糞だって表明したオープンソース界のカリスマもいたよ。
>>515
すでに、初代ItaniumとItanium2の間で、最適化の互換性を捨ててるよ。
それによって動作クロックが僅かしか上がらなかったのに実効性能は倍になったよ。
530:名無しさん＠お腹いっぱい。
09/02/13 16:34:06 .net
>>523
長期的に使うISAとしてはRISCは粒度が細かすぎる。
同じことをするのにも多くの命令を必要とすることは、
同じことをするのに多くの命令間の依存関係を調べる必要がある。
しかし、やりたい操作と命令が一対一対応していれば、調べる範囲が狭まる。
531:名無しさん＠お腹いっぱい。
09/02/13 16:41:58 .net
>>524
gccの吐いたコードの速度を基準にしていったわけじゃないのでしょう？
532:名無しさん＠お腹いっぱい。
09/02/13 16:48:45 .net
うわ。ホンモノっぽいの出てきたな。
別にコンパ�
533:Cラ作りようがない、って言ってたんじゃなくて、 作るのが難しい、この先保守もたいへん、って意味でしょ。 それで十分だし。ISAを否定するには。 それに、某カリスマ（なのかね、ほんとにww）が青筋たてて言ったことは これまでほとんど間違いばっかりだったから、気にするだけ損かとww
534:名無しさん＠お腹いっぱい。
09/02/13 17:07:10 .net
IA64は本当に糞だったのでは?
535:名無しさん＠お腹いっぱい。
09/02/13 17:11:15 .net
>>526
彼らにはgccしかなかった。
オープンソースで、GPL汚染されているコンパイラで、他に何かありました?
536:名無しさん＠お腹いっぱい。
09/02/13 17:11:42 .net
IBMと Sunがビビって賛同して、少し首つっこんだらすぐに離れたから、
そうじゃないかとは思ってた。
537:名無しさん＠お腹いっぱい。
09/02/13 17:12:44 .net
彼らが離れたのは、初代Itaniumがスケジュール遅延したからでしょ。
遅延した結果、自社で抱えているプロセッサのほうが性能が上になってしまった。
538:名無しさん＠お腹いっぱい。
09/02/13 17:16:45 .net
>>528
「x86を置き換えて、ノートPCあたりまで IA-64」とか当初の目標を達成する、という
意味では、十分に「クソ」です。
「x86をシミュレーションしてぜんぜん性能出ない」という意味でも、十分に「クソ」です。
ええ、つまり、＊クソ＊です。w
539:名無しさん＠お腹いっぱい。
09/02/13 17:17:13 .net
>>509は
> オープンソースな人たちはgccを使うわけだが、
> そのgccの生成するIA-64のコードが酷かった。
> さらに人間がバイナリレベルでデバッグするのが難しく、
> さらに、マシンチェック回りはアマチュアには無理。
> つーわけで、オープンソース方面ではIA-64バッシングが激しかったんだよ。
gcc基準でIA-64をバッシングしていたってソースはあるの？君の脳内以外に
540:名無しさん＠お腹いっぱい。
09/02/13 17:18:35 .net
>>531
それは違うと思うよ。そういうタイミングじゃなかった。
首つっこんで、なんか具体的なもん見た結果、ビビる必要はない、と判断したように
オレには見えた。
541:名無しさん＠お腹いっぱい。
09/02/13 17:26:17 .net
>>531
Sunが最後に表明したのは情報公開が足りないってことだった。
次期CPUとその足廻りの技術情報を出し惜しみしているから、
次のItaniumマシンの設計が出来ないと。
当時も言われていたけど、遅れていて出そうにも出せなかったんだね。
>>534
SunはItanuimのJDKさえも作っていて当時は結構乗り気だったよ。
一時HPよりもSolaris IA64機の話題の方が多かったくらい。
542:名無しさん＠お腹いっぱい。
09/02/13 17:44:55 .net
>>535
当時 Sunは MAJCやってたし、IBMも VLIWずっと研究してたから背景知識は
持ってたはず。で、実際 Solarisの CPU依存部分を実装してみて
「なんだこりゃ」ってなったんじゃないかと推測してる。
「なんか隠してるに違いない」と思ったのかどうだかは知らんが。
いずれにせよ、恐るるに足らん、という結論だろうな。
543:名無しさん＠お腹いっぱい。
09/02/13 17:57:14 .net
> 背景知識は持っていたはず
pgr
パソヲタじゃあるまいし当たり前
544:やんやん ◆yanyan72E.
09/02/13 21:33:54 ?2BP(0).net
流れきってすまん。
CRAY CX1ってこのスレ的にはどうなの?
545:名無しさん＠お腹いっぱい。
09/02/13 21:34:17 .net
>>532
スケジュールが遅延したからな。
本来ならPentium2のデビュー頃に市場に投入されるハズだったのだろう。
Pentium2 233MHzと初代Itaniumのx86命令の実行性能は同程度だというから。
546:名無しさん＠お腹いっぱい。
09/02/14 12:43:10 .net
Transmeta Crusoe…
547:名無しさん＠お腹いっぱい。
09/02/14 13:45:18 .net
>>538
どういう関連があるの？
548:名無しさん＠お腹いっぱい。
09/02/14 15:48:10 .net
IA64の方が高性能な互換プロセッサ簡単に作られちゃうとかあるんじゃないの？
549:名無しさん＠お腹いっぱい。
09/02/14 16:55:13 .net
SPARC以上に、命令セットとハードウェアが一体なので、どう作っても同じになっちゃう。
550:名無しさん＠お腹いっぱい。
09/02/14 18:59:01 .net
インテルとしてはx86のブラックボックスが一番都合がいいんじゃないの？
Itaniumでも同一命令グループをいかに効率よく実行するかというところで
知恵の働かせどころはあるけど
551:名無しさん＠お腹いっぱい。
09/02/14 23:46:10 .net
そんなに工夫の余地、あったかなぁ。
552:名無しさん＠お腹いっぱい。
09/02/19 16:11:55 .net
ARMきてるな。
Itaの連中も x86のテコ入れに駆り出されちゃってるじゃん。ホネぬ～き状態ねw
553:名無しさん＠お腹いっぱい。
09/02/20 22:01:45 .net
Unisys threatens Itanium with death
URLﾘﾝｸ(www.theregister.co.uk)
554:名無しさん＠お腹いっぱい。
09/02/23 04:59:40 .net
>>546
>Itaの連中も x86のテコ入れに駆り出されちゃってるじゃん。ホネぬ～き状態
いまさら何を・・・ここ1,2年はましな方。4年前はもっと酷かったぞｗ
555:名無しさん＠お腹いっぱい。
09/02/23 07:42:52 .net
Intelは、ItaniumやらずにSPARCとバイナリ互換のCPUを作るべきだったんだよ。
556:名無しさん＠お腹いっぱい。
09/02/23 17:42:58 .net
ISAが SPARCで内部実装が VLIWなら Dave Ditzel連れてくりゃすぐ作りそうだなww
だが Sunでそれをやらなかったのにはそれなりの理由があるかも。
557:名無しさん＠お腹いっぱい。
09/02/23 17:55:06 .net
>>550
SPARC時代にハードウェアによる互換性維持に嫌気がさしたからCodeMorphing。
けど今はIntelにいるからやるかもね。
URLﾘﾝｸ(www.theinquirer.net)
558:名無しさん＠お腹いっぱい。
09/02/23 20:44:34 .net
IA-32ELだろ?
559:名無しさん＠お腹いっぱい。
09/02/24 10:25:14 .net
知識ないんだな。
560:名無しさん＠お腹いっぱい。
09/02/24 10:40:39 .net
最近はマルチコアを有効に利用するための
バイナリ変換に取り組んでいるらしい。
561:名無しさん＠お腹いっぱい。
09/02/25 23:48:23 .net
へぇ
562:名無しさん＠お腹いっぱい。
09/02/28 21:24:35 .net
それ、何のFX!32？
563:名無しさん＠お腹いっぱい。
09/03/02 10:28:00 .net
FX!32はぜんぜん違うだろ何言ってんだかw
564:名無しさん＠お腹いっぱい。
09/03/02 10:49:10 .net
>>554
AppleがOpenGLスタックのIntel/PowerPC両対応のためにLLVM使っていたが、
ああいう実行時変換をx86→x86でやるんですかね。
EPICとはかなり方向違いですね。
565:名無しさん＠お腹いっぱい。
09/04/21 16:06:35 .net
Sun終了
Itanium始まったな
566:名無しさん＠お腹いっぱい。
09/04/21 17:25:15 .net
Tukwilaさえ出荷できてたら、確かにチャンスだったかも。
567:名無しさん＠お腹いっぱい。
09/04/21 17:29:13 .net
SPARCのハイエンド置き換えなら、そうすぐ乗り換えられる規模の
客じゃないから、今度こそ遅れずに今年中の出荷ができたら間に
合うんじゃね？
568:名無しさん＠お腹いっぱい。
09/04/21 17:35:14 .net
いったい誰にそんな「やる気」があるんだよww
Intel? HP? それとも、ふじつーかぁ??ww
たとえ作れてももう出さないかと。
569:名無しさん＠お腹いっぱい。
09/04/21 18:10:29 .net
AMDに 64bit化で追い詰められた末、Intel自身で Itaを葬るしか道はなかったわけだ。
amd64互換な x86石の性能を上げることによって。
けど、もっと遡って見れば単に宣言したような性能にまったく届かなかったから退場、
単にそれだけのことだけどね。x86を置き換えてしまうはずだったんだから。
「こんだけ条件ズタズタでもチカラワザでかつ条件付きならここまで挽回できまっせー」
....わかったわかった、もういいから無駄使いはやめてくれよ..
570:名無しさん＠お腹いっぱい。
09/04/21 18:19:30 .net
いや、Solaris/ia64なんてのが出るとは思って無いけど、
普通にSPARCのハイエンド機入れてるような顧客で、
大型UNIX機を使い続けたい所に、HP-UXのハイエンド機を
売り込んで行く事はあるだろうって意味でのチャンスだよ。
まあ、先行きのあまりない市場だけど。
571:名無しさん＠お腹いっぱい。
09/04/21 18:51:10 .net
HPは Nehalemだと RAS弱 & Linuxになっちゃうから客によっては Itaしかないか。
PA-RISC売るんじゃねーの? まだあるんだよなw
572:名無しさん＠お腹いっぱい。
09/04/22 02:36:16 .net
今更SPARCの置き換えにPA-RISC如何ですか？
なんて言ってくる奴がいたら、そいつは出入禁止にしてやるｗ
まあ、OracleにハイエンドSPARC続ける気があるとは思えないんだが、
富士通は続ける気がありそうというか。ここでSPARC買い取る位の
事をすれば、あのクソ会社も多少は浮かぶ（もしくは轟沈）と思うがね。