ItaniumをUNIXで使うスレ
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2008/07/14(月) 19:44:39前スレ
ItaniumでUNIX!
http://pc11.2ch.net/test/read.cgi/unix/1140329582/
0160名無しさん＠お腹いっぱい。
2008/09/12(金) 18:59:01どんどん穴深くなってんのたいがい悟れよwww
レクチャーね。そんなんできるんなら、もっとまともなこと上で言えてるわな ..www
0161名無しさん＠お腹いっぱい。
2008/09/12(金) 19:15:25段階的に64ビット化されて、最初はけっこう32ビットのモジュールが残っていたような。
0162名無しさん＠お腹いっぱい。
2008/09/12(金) 20:29:280163名無しさん＠お腹いっぱい。
2008/09/12(金) 20:48:44互換性はないよ。
その代わり、
PA-RISCからのバイナリトランスレータを作りやすいように、
PA-RISCからのバイナリトランスレータでパフォーマンスが出やすいように、
IA-64命令セットがPA-RISCに似たものになってる。
IA-64単体で見たとき、それは負の遺産だと思う。
0164名無しさん＠お腹いっぱい。
2008/09/12(金) 22:17:140165名無しさん＠お腹いっぱい。
2008/09/12(金) 22:34:10中身が何だろうと、あんまり関係ないんだよね。
0166名無しさん＠お腹いっぱい。
2008/09/12(金) 22:35:43そういうのはItaniumネイティブで提供されてるっしょ。
CDEをネイティブにしろなんてアホ言ってるのは、
趣味的なキボンヌを口に出すガキだけ。
0167名無しさん＠お腹いっぱい。
2008/09/16(火) 09:38:03それらのバイナリーが動くのは当然。そいつらもネイティブ。
IA64 の仕様でもない PA-RISC バイナリーが動くってのとは違うよね。
つまり「標準」連発してるけど、IA64の実装（現状いっこしかないけど）に
よっては HP-UX は動かない。
手抜きつーか、みじめつーか、みっともなさ過ぎだろ。
0168名無しさん＠お腹いっぱい。
2008/09/16(火) 10:23:41あいかわらず何が問題なのか理解できてませんね。
再コンパイルすることが問題なのです。
たとえ、コードを全くレビューせず、修正が必要な箇所もなく、コンパイルしたものが1発で動いたとしても、
再コンパイルすることで結構なコストが発生するのです。
0169名無しさん＠お腹いっぱい。
2008/09/16(火) 10:36:15んじゃあ x86へポートなんて夢のまた夢だな? CDEの動作確認コストで企画オジャンだwwwwww
0170名無しさん＠お腹いっぱい。
2008/09/16(火) 11:46:350171名無しさん＠お腹いっぱい。
2008/09/17(水) 17:15:500172名無しさん＠お腹いっぱい。
2008/09/17(水) 18:58:420173名無しさん＠お腹いっぱい。
2008/09/17(水) 19:09:39...中身ない、って言われちゃいますよ?
0174名無しさん＠お腹いっぱい。
2008/09/17(水) 19:12:090175名無しさん＠お腹いっぱい。
2008/09/17(水) 19:50:190176名無しさん＠お腹いっぱい。
2008/09/17(水) 20:46:35脳空洞なんだろな。こんなエンジニア来た日にゃ、トラブルまっしぐらだね。
オレは初見で追い帰すぜ、こんなクズは。なんの説明にもなっとらん。
まあ、最初から説明なんかできないのがミエミエだけどな。
利口なやつなら首つっこまんわなwwww
0177名無しさん＠お腹いっぱい。
2008/09/17(水) 20:51:35自分が遊ばれているのがわかってないらしい。
0178名無しさん＠お腹いっぱい。
2008/09/17(水) 21:10:270179名無しさん＠お腹いっぱい。
2008/09/17(水) 21:13:070180名無しさん＠お腹いっぱい。
2008/09/19(金) 23:22:150181名無しさん＠お腹いっぱい。
2008/09/20(土) 05:22:32そんな趣味レベルで使うようなものじゃないし。
0182名無しさん＠お腹いっぱい。
2008/09/20(土) 17:06:10しかもまるで懲りてない。使えん。エンジニアじゃないことを祈るのみ。迷惑千万。
0183名無しさん＠お腹いっぱい。
2008/09/20(土) 18:33:19釈迦に説法って知ってる?
0184名無しさん＠お腹いっぱい。
2008/09/21(日) 02:45:090185名無しさん＠お腹いっぱい。
2008/09/21(日) 04:39:57カマッテチャンが必死になってる
0186名無しさん＠お腹いっぱい。
2008/09/22(月) 00:03:490187名無しさん＠お腹いっぱい。
2008/09/22(月) 01:22:35そして反応したのが186。
0188名無しさん＠お腹いっぱい。
2008/09/22(月) 09:06:39あーきしょー
0189名無しさん＠お腹いっぱい。
2008/09/22(月) 16:23:150190名無しさん＠お腹いっぱい。
2008/09/22(月) 21:09:310191名無しさん＠お腹いっぱい。
2008/09/22(月) 23:11:060192名無しさん＠お腹いっぱい。
2008/09/24(水) 19:09:160193名無しさん＠お腹いっぱい。
2008/10/01(水) 15:38:430194名無しさん＠お腹いっぱい。
2008/10/01(水) 22:26:26買ってはないが、
Windows + SQL Serverは32ビットで、将来的に規模拡大したときのアップグレードパスがない
っていう人に対して、Itanium版があるから安心しろって言えるだけで、十分に価値があった。
おっと、ここはUNIX板だったな。
0195名無しさん＠お腹いっぱい。
2008/10/01(水) 22:34:490196名無しさん＠お腹いっぱい。
2008/10/02(木) 03:07:02興味ない人は来るなよ。
0197名無しさん＠お腹いっぱい。
2008/10/02(木) 11:08:13MS の SQL Serverは amd64で 64bitになっちゃったの?
0198名無しさん＠お腹いっぱい。
2008/10/02(木) 11:37:270199名無しさん＠お腹いっぱい。
2008/10/02(木) 14:09:340200名無しさん＠お腹いっぱい。
2008/10/02(木) 14:10:190201名無しさん＠お腹いっぱい。
2008/10/02(木) 14:47:020202名無しさん＠お腹いっぱい。
2008/10/02(木) 14:55:170203名無しさん＠お腹いっぱい。
2008/10/02(木) 16:10:24Athlonの部隊には DEC出の同僚がたくさん居るみたいだし。
最適化の手法が Alphaと同じでイケるとかなんとか。
仕方ないわな。
0204名無しさん＠お腹いっぱい。
2008/10/03(金) 05:20:03マルチスレッド化してマルチプロセッサでスケールする
というのがあったので、
シングルスレッド性能を追求するあまりに効率の劇悪な
IA-64というのはアホらしかったのだろう。
0205名無しさん＠お腹いっぱい。
2008/10/03(金) 09:57:30固執（よく言えば自負）なんじゃないかと思ってるがww
DECにはそういう社風あったそうだし。社外技術を見下す姿勢。
EPICは HPから出たもんだから。
0206名無しさん＠お腹いっぱい。
2008/10/03(金) 12:56:360207名無しさん＠お腹いっぱい。
2008/10/03(金) 13:10:080208名無しさん＠お腹いっぱい。
2008/10/03(金) 16:16:260209名無しさん＠お腹いっぱい。
2008/10/03(金) 19:35:020210名無しさん＠お腹いっぱい。
2008/10/04(土) 23:20:180211名無しさん＠お腹いっぱい。
2008/10/16(木) 13:29:39イマイチ図が小さすぎてよく見えんが。NX7700iが何台だろ?
0212名無しさん＠お腹いっぱい。
2008/10/18(土) 02:33:240213名無しさん＠お腹いっぱい。
2008/11/16(日) 11:11:57亀レスだが。
ネイティブだろうがエミュだろうが、同じバージョンである以上その中身が変わることは
まずいんでないの？特に商用利用では。
(パッチによるバグ修正は除く)
HP-UXに関しては、逆にパフォーマンスに関わる部分はネイティブ化してあるって
ことなんだろうさ。
0214名無しさん＠お腹いっぱい。
2008/11/19(水) 01:54:25EM64T, x86_64を合計すると85%
0215名無しさん＠お腹いっぱい。
2008/11/19(水) 11:18:06ま、その可能性は低いと思うがw
0216名無しさん＠お腹いっぱい。
2008/11/27(木) 09:37:41だから何?
むしろ1.8%も残っていることのほうが驚きだよ。
>>215
はいはい、Sunスレから出張で荒らしに来て、おつかれさん。
6コアXeonの4ソケットが出た時点で、速度面では、もう終わってるよ。
それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。
まぁ限られてると思いますけどね。
0217名無しさん＠お腹いっぱい。
2008/11/27(木) 10:30:5724コアを「バス」で主記憶に接続して、まともに性能出るわけがない。
キャッシュに収まる特殊用途除いて、な。あんた次元低すぎるんだよ。
なんでわざわざインターコネクトの名前あげてるかぐらい考えてよね。
考えても書かなくていいけどww
> それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。
そんな用途で実績のかけらもないアーキを使う意味なんかないでしょ。
企業判断的にチョンボして行き詰まってる「事情」があるとこ以外には
無価値と思うが。
0218名無しさん＠お腹いっぱい。
2008/11/27(木) 11:12:53あなたの脳内では、まともに性能が出ないそうだが、
各社がサーバ作って出してるんだよねぇ。
0219名無しさん＠お腹いっぱい。
2008/11/27(木) 11:20:420220名無しさん＠お腹いっぱい。
2008/11/27(木) 18:55:12ttp://www.geocities.jp/andosprocinfo/wadai02/20020511.htm
| コモンバス方式は追加のハードも少なく一番簡単ですが、
| ...多数のプロセサを使うシステムでは性能が飽和してしまいます。
超入門者向け 1980年代の基礎知識だけどな。MP評価する立場ならこんなん知らんと
話にならん。
0221名無しさん＠お腹いっぱい。
2008/11/28(金) 05:09:470222名無しさん＠お腹いっぱい。
2008/11/28(金) 09:38:14ろくに検証もしないから問題にもならない、とw
0223名無しさん＠お腹いっぱい。
2008/11/28(金) 12:41:06しかも現実が見えてないですからね。
0224名無しさん＠お腹いっぱい。
2008/11/28(金) 18:41:160225名無しさん＠お腹いっぱい。
2008/11/29(土) 02:33:55あれれ、脳内妄想で評価している人が、そんなこと言いますか?
0226名無しさん＠お腹いっぱい。
2008/11/29(土) 07:01:00Opteron 8wayとItanium 4wayでOpteronの方が性能が上で価格も数分の一となれば
Opteron選ぶよねえ。うちでItanium入れたのなんてsuper domeくらいだ。
x86だとDL785の8CPUが上限だから、それ以上欲しいときはItanium/SPARCを
検討する。2CPUや4CPUで十分なサーバーにはx86しか入れない。
0227名無しさん＠お腹いっぱい。
2008/11/29(土) 07:36:58お客様は夢見がちで、現時点でWindows鯖で十分なことは理解していても、
将来の業務拡大にハードウェアのアップグレードで追い付けないことを心配されます。
そのときにItaniumにアップグレード可能だと説明すれば、だいたい納得されます。
実際にはx86ベースのシステムの性能向上のペースを上まわって成長した事例はなく、
Itaniumは見せ玉のまま終わっています。
x86 & Linuxの案件でも、Itaniumは見せ玉として使えませんか?
0228名無しさん＠お腹いっぱい。
2008/11/29(土) 07:59:50そんなに気にしない。台数少ないにこしたことはないけどね。管理も楽だし。
DBはOracle RACいれてとりあえずノード追加で対応できて将来はまた
新しいH/W出てますから、って言う。まあDBはOracleさえ走ればLinuxでも
Solarisでもhp-uxでもいいから見せ玉使う事もないけど。
0229名無しさん＠お腹いっぱい。
2008/11/29(土) 09:28:31SQL ServerはWindowsのみなので、Itaniumには頭が上がりません。
0230名無しさん＠お腹いっぱい。
2008/11/29(土) 09:52:28それ以前の「バス」はだめだよ「バス」は。お話にならん。
なんでこうおバカが多いのか。踊らされてほんとにアワレなこった。
0231名無しさん＠お腹いっぱい。
2008/11/29(土) 10:00:08妄想はいいから自分で実機で検証してからホザきなさい。
0232名無しさん＠お腹いっぱい。
2008/11/29(土) 10:06:27スケールするという記事でも探してこい。
「商品が出てる」で証明になんかなるかボケ。
ちなみにオレはクソおそい 80386のMP機は触ったことあるぞ。
単発の 80386パソコンの何倍も遅かったが、製品だった。
まーーーーったく売れなかったと聞いてるww
0233名無しさん＠お腹いっぱい。
2008/11/29(土) 10:11:29その他には経験がないわけですねw
誇らしい経験をお持ちで良かったです。
>>227
皺々なんで見せるの恥ずかしいです（＞＜）
0234名無しさん＠お腹いっぱい。
2008/11/29(土) 10:36:13で、記事かなんか提示しろや。自分で買ってベンチしたのでもいいぞ。
ま、そんな知識じゃ SMPの評価なんてどうやったらいいかわからんだろうがなwwwwwww
0235名無しさん＠お腹いっぱい。
2008/11/29(土) 11:40:00Windows売るのにItaniumを見せ玉にってのは良く聞くな
でも、Becktonが出たらItaniumの役目も終わりだろ
Linuxで拡張性に不安って人は最初からUNIXに行くんじゃね？
0236名無しさん＠お腹いっぱい。
2008/11/30(日) 02:41:38置き換えられるようになるのはまだまだかかるんじゃないかな
0237名無しさん＠お腹いっぱい。
2008/11/30(日) 04:51:36退場。
0238名無しさん＠お腹いっぱい。
2008/12/01(月) 10:28:180239名無しさん＠お腹いっぱい。
2008/12/01(月) 14:40:06いいかげんにしろ。
0240名無しさん＠お腹いっぱい。
2008/12/01(月) 15:35:140241名無しさん＠お腹いっぱい。
2008/12/01(月) 15:46:110242名無しさん＠お腹いっぱい。
2008/12/01(月) 16:58:43自己矛盾君。
0243名無しさん＠お腹いっぱい。
2008/12/01(月) 17:15:46ま、もうゴミでも撒かなきゃ話題もないんだけどww
0244名無しさん＠お腹いっぱい。
2008/12/01(月) 17:32:53ttp://pc.watch.impress.co.jp/docs/2007/1113/hot515.htm
| ...このアライアンスを母体に新しく事業会社を起こし、そこにIA-64の設計や
| 開発を分離するのはどうだろう。...Tukwilaが完成し、QPIベースの
| プラットフォームが確立したら、タイミング的には頃合いだと思うのだが。
0245名無しさん＠お腹いっぱい。
2008/12/01(月) 17:41:480246名無しさん＠お腹いっぱい。
2008/12/01(月) 17:43:51国際イタニウム株式会社
0247名無しさん＠お腹いっぱい。
2008/12/02(火) 07:46:30これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
そして、Xeon 7300や7400の4プロセッサ向けのチップセットではFSBが4本あり、
4つのプロセッサがFSBを共有せず、スヌープキャッシュによって、ほぼ独立している。
これらと2つの独立したメモリコントローラが、チップ上で密に結合されている。
これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
いまのXeonがSMPで性能が出ないというのなら、
かつてのSun FireのSMPも性能が出ないという話になる。
プロセッサ数あるいはコア数が倍になっても、性能は倍にはならないが、
それは、Sun Fireでも同じ。
0248名無しさん＠お腹いっぱい。
2008/12/02(火) 10:18:11バスなんか使ってないですが。直クロスバーですぜ。
んで、その Xeonの構成で、メインメモリはどこにつながってるの?
チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
んで、メインメモリへのアクセスは競合しないの?
バスが「飽和する」って、意味わかってる?
> これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
> これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
> かつてのSun FireのSMPも性能が出ないという話になる。
> それは、Sun Fireでも同じ。
まぁーーーーーーっったく、違いますが。いっしょにしないでくれる?w
んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
一体なんの関係があるわけ?
チャネル数増やして（見かけ上の）アクセス速度上げると、
バスは _余計に飽和_ しやすくなるけど?
バスが「飽和する」って、意味わかってる? （念の為 2回め）
0249名無しさん＠お腹いっぱい。
2008/12/02(火) 11:06:450250名無しさん＠お腹いっぱい。
2008/12/02(火) 11:35:16> Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、
> バスなんか使ってないですが。直クロスバーですぜ。
データはクロスバーだけど、アドレスは実質的にバスだよ。
> んで、その Xeonの構成で、メインメモリはどこにつながってるの?
> チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
バスですよ。
> んで、メインメモリへのアクセスは競合しないの?
競合するよ。
メモリアクセスを開始できるのは同時に2つまで。
アドレスが実質的にバスのSun Fireも同じだよ。
メモリアクセスを開始できるのは同時に1つだけ。
> バスが「飽和する」って、意味わかってる?
アイドルサイクルがない状態が飽和、でしょう。
> んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
> 一体なんの関係があるわけ?
独立して動作するメモリバスが2本あれば、
2つのコアのメモリアクセス要求を同時に処理できるので、
飽和した状態で処理できるメモリアクセスが増える。
0251名無しさん＠お腹いっぱい。
2008/12/02(火) 11:35:53いま自宅でRHEL3使ってるんだが、ぼちぼち入れ替えたい所。
ia64対応しているフリーのディストリで、今だったらどれがオススメ？
centosはいつまで経っても5系でないし、何かdebian位しかメンテされているのがない気がする。
0252名無しさん＠お腹いっぱい。
2008/12/02(火) 11:48:09> アドレスが実質的にバスのSun Fireも同じだよ。
おいおい。トンデモな言い訳はよしてくれや。
じゃ、バスに対するクロスバーの利点はなんだよ?
アドレスがバスだからクロスバーの利点は帳消しになるとでも? ふざけてんのか??
0253名無しさん＠お腹いっぱい。
2008/12/02(火) 12:10:34> おいおい。トンデモな言い訳はよしてくれや。
>>220のリンク先に書いてあることですが?
> じゃ、バスに対するクロスバーの利点はなんだよ?
クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
もしSun Fireをバスにした場合、512bit幅でバスを配線しなくてはいけない。
クロスバーなら、発着が別の場合に、1つ前のメモリアクセスで生じた転送が終わる前に
次のメモリアクセスで生じる転送を開始できるので、つまり、転送をゆっくり行うことができる。
そのためSun Fireは128bit幅で4クロックに分けて転送してる。
0254名無しさん＠お腹いっぱい。
2008/12/02(火) 12:11:40いっそFreeBSDいってくれ。
0255名無しさん＠お腹いっぱい。
2008/12/02(火) 12:19:26使うだけならそのままRHEL3をEOL迄使いつづけたら？
開発に参加するならFedora9を入れるとか。
ttp://fedoraproject.org/wiki/Architectures/IA64
0256名無しさん＠お腹いっぱい。
2008/12/02(火) 12:19:54FreeBSD/ia64だとXが使えないのが苦しい所だな。
0257名無しさん＠お腹いっぱい。
2008/12/02(火) 12:28:22まさに使うだけだったからRHEL3で間に合ってたのだけど、
作業環境としては要らなくなったので、気分転換しようかと。
実験環境としてはdebianだと保守的すぎてつまらないし、
Fedora9で良さそうね。
0258名無しさん＠お腹いっぱい。
2008/12/02(火) 13:18:51> クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
はぁ〜。どーしよーもねーな。
まあ、その程度じゃなきゃ共有バスで SMP性能が出るなんて思わんわな。
Wikipedia の「バス（コンピューター）のとこでも読んでみれ。話にならん。
| ...スター型トポロジとなるクロスバースイッチ（クロスバーバス）が
| ワークステーション等に採用されている。これは複数のCPU・メモリ間で
| 多対多の転送（通信）を同時に行えるようにしたもので、...
多対多で同時ね。は〜、疲れるわ。
0259名無しさん＠お腹いっぱい。
2008/12/02(火) 16:09:09こっちのほうが疲れるぞ。
思いっきり単純化して、スヌープとか調停とか端折りまくって説明するとだな。
■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
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に向けてデータ転送終了
0260名無しさん＠お腹いっぱい。
2008/12/02(火) 16:10:4464バイトの転送を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クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
■ このスレッドは過去ログ倉庫に格納されています