ItaniumをUNIXで使うスレ

2008/07/14(月) 19:44:39
実際に使ってみた人、どうよ?

前スレ
ItaniumでUNIX!
http://pc11.2ch.net/test/read.cgi/unix/1140329582/
2009/01/07(水) 07:04:56
オペコードが人間が綺麗と感じるように割り当てられてることにどんな意味があるの？
2009/01/07(水) 10:43:16
> オペコードが人間が綺麗と感じるように

はいはい、意図的に誤解して架空の話を叩いて喜んでないで仕事しようね。
2009/01/07(水) 10:43:26
デコーダがシンプルになる...いまどきどうでもよいが。
将来の拡張の余地が広がる。これは大きい。
2009/01/07(水) 10:45:34
AVXでおk
2009/01/07(水) 10:54:44
AVX?

あれ長いよ。

たった1バイトしか短くならない・・・1バイトでも短くなることは重要ではあるし、
その次の拡張で長くならないことも重要なのだが、グダグダっしょ。
2009/01/08(木) 15:11:25
ほれ見ろ。オレがネタ投下してやんないとなんも出んがなw
2009/01/08(木) 15:13:49
安くて消費電力の少ないIta2マシンどっかに落ちてないかな
中古でいいよ
2009/01/10(土) 00:42:48
そんな製品がないんだから中古なんてなおさらあるわけないw
複雑化の原因はコンパイラにまかせてコアは単純化されてるはずだから
キャッシュ減らしたら電力食わないんだろ、きっと。そうに違いないwww
2009/01/10(土) 20:06:22
キチガイはスルーで
2009/01/10(土) 21:05:06
>>433
NASとCPUと言えば、AuspexがSPARCでやっていたのを、
廉価NAS構成に対向しようとx86に移行しようとして失敗沈没してﾜﾛﾀ
コントローラはSolaris for x86で問題なかったけど、
独自ファームのエンジンがどうにもならなかったみたい。
やっぱCPU移行は慎重にやらないとね。
本当にメリットがあるのかどうか。どのCPUでも。

>>452
AMDはそういう路線だからしかたないんじゃ？
コストかけて研究部門維持するわけにもいかないし。
2009/01/10(土) 21:23:58
AMDを責めてもしかたないわな。
水先案内人としての責任は、牽引する立場のIntelにある
2009/01/10(土) 21:28:21
市場を完全に制圧してからやるべきだったね
その辺Microsoftは賢い
2009/01/10(土) 21:33:14
AMDはIntelの失敗を修正する役割があると
2009/01/10(土) 21:36:05
>>452
Intelの最適化まぬあるによると増えたレジスタは使うなというｗ
2009/01/10(土) 21:38:25
あはははは
2009/01/10(土) 22:12:26
>>467
そのほうが消費者の利益になったとしても、独占ってだけで叩かれるぞ。
個人的にはAMDのIA-64実装を見てみたかった。

>>468
Intelを牽制する役割、だろうな。

>>469
IntelのCPUだと増えたレジスタを使った場合に、ガクンと遅くなるんだよな。
そりゃ、使うなと書いて当然だ。

こういう新しい命令セットってのは、互換性が重要なのよ。
最初にインプリしたCPUでは、速く実行できる必要はなくて、とにかく、正常に実行できることが重要。
その命令セットを実行できるCPUが市場に十分に出まわった時点で、本格的にソフトが使いはじめる。
この時点で、その命令セットを高速に実行できるCPUを市場に投入すればいいの。

まったく実行できない
と
遅いけど実行できる
というのでは、まるでインパクトが違う。

うまく移行するためには、早くから種まきしておかないと。
2009/01/10(土) 22:22:44
命令長伸ばしてレジスタ拡張なんて最近流行の電力効率に反する実装だからだよ
AVXの目的もそういうことだ
2009/01/10(土) 22:32:30
やっぱり、64ビット拡張するときに、OPコードを大胆に整理すべきだったんだよ。

モードによって違うのはデコーダのコストが増えるが、
しかし、
命令長が長いのに比べたらマシだと思うんだわ。

もったいないよ。使わない命令が短くて、使う命令が長いのは。
2009/01/14(水) 01:57:08
なんか自作板にTukwilaはDDR3サポートに変更になったとか書き込みがあった。
2009/01/14(水) 12:11:19
そうなればそうなるわな
2009/01/14(水) 12:58:33
以前からDDR3系のFB-DIMM2も対応予定に入ってなかったっけ？
それともFB-DIMM1のサポート無くしたという意味かな。
2009/01/14(水) 16:18:08
え?

FBってのは、DRAMチップのI/Fが変ってもOKっていう柔軟性も兼ね備えているんじゃないの?
2009/01/14(水) 16:39:30
2007年の時点で、
DDR3を使ったFB-DIMMの提供予定はない
っていう話だった。
2009/01/14(水) 16:40:48
FB-DIMMやめて直にDDR3のメモリコントローラを積むって話では?
480474
垢版 |
2009/01/14(水) 22:32:03
>>478
そのあとFB-DIMMのバッファチップをマザーボードに置くとかいう話が出てきた。
そうするとスロットに挿すメモリはDDR3だけどMCHのインターフェースはFB-DIMMになる。

>>479
うん、そんな感じだった。
2009/01/14(水) 23:08:59
へー、直結にするんか。
まあ、その方がレイテンシ短くできるだろうし、やるかどうか怪しいけど
Xeon-MPとのプラットフォーム共通化も進めやすいだろうし。

それで発売が遅れてるんだったら、まあ建設的な理由だな。
2009/01/15(木) 03:06:16
そもそもFB-DIMMって、
メモリコントローラをチップセットに持たせた時に、
大量のメモリを積むためのもの。
チップセット1つから、メモリのバスを12本とか出せないんでね。

ところが

QPIを導入した時点で、
CPUの数だけメモリコントローラを増やすことができる。

メモリのバスを3本もつCPUを4ソケット構成にすれば、
無理なく12本のメモリバスが得られる。
2009/01/15(木) 03:13:48
DDRのままではコア数はどんどん増えるのに帯域はあまり稼げないしピン数も爆発的に増える。
シリアルメモリは絶対必要。なのにFB-DIMMは死んでDDR4はどんどん先送りされている。
Nehalemでは痛みに耐えて3chにしたけど1年後には6コアのWestmereが来る。焼け石に水。
高速なローカルメモリの使えるLarrabeeでどうにかなるという読みなのかね。
484483
垢版 |
2009/01/15(木) 03:25:32
忘れていたが。。。Sandy Bridgeでon-package memoryとかいう噂もあったね。。。
SandyBridgeもNehalem同様processor coreのmicroarchitectureの変更は控えめでmemory回りの強化が主眼になる予感。
それでも十分new-architectureなのだけど。。。
ttp://www.intel.com/technology/itj/2007/v11i3/3-bandwidth/6-architectures.htm
これ、ItaniumでもPoulsonで採用されるのかな。コスト的なハードルはItaniumの方が低いと思うが。
2009/01/15(木) 09:06:15
>>483
Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。

>>484
それは大容量のL3やL4のキャッシュを乗せようという話だと思います。
486483=484
垢版 |
2009/01/15(木) 22:37:30
>>485
>Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
>少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
うん、それはわかっている。
帯域が必要な分野にはLarrabeeを充ててキャッシュでそこそこ何とかなるサーバー向けCPUはのんびりいくのかなと。
Montecitoなんか未だにFSB533MT/sだもんね。144bitバスとは言え。。。

>大容量のL3やL4のキャッシュを乗せようという話
IntelのスライドによるとSandyBridgeのon-package memoryの容量は512MBとかだから従来のキャッシュとは桁が違う感じ。
これだけ容量が大きくなると制御法も従来の延長では駄目で一工夫要ると思われる。。。要するにキャッシュになるのかわからない。
まあ古いスライドなので変更された可能性もあるんだが。。。


スレ違いなのでこの辺で。
2009/01/15(木) 22:45:35
FSBのデータバスの転送だけ速くしても、アドレスバスの処理能力が先にネックになったら無駄なわけで。
そのあたりは難しいよね。

データはとにかく転送すりゃいいんだけど、アドレスは処理しなきゃならないから。
2009/01/16(金) 13:59:49
NECのＡＣＯＳ使ってるけどやっぱ、古いよな？
2009/01/16(金) 14:01:15
それで済むならそれでいいじゃん
2009/01/16(金) 19:56:37
電気代考えると..
2009/01/16(金) 20:01:13
電気代の差額ｘこれからの使用年数　が導入費用と同じ桁になるなら考えてみれば
2009/01/16(金) 20:58:10
いや。所有者のコストじゃなくて地球のコスト。
2009/01/16(金) 21:11:36
新規導入しないほうがいい
2009/01/17(土) 13:11:38
移行に失敗したときのリスクも考えよう。

現状のランニングコストと導入コストが一緒だから、
タダでシステムが新しくなりますよ?
なんていうセールスはアヤシイ
2009/02/02(月) 12:06:16
「ＸＸなんていうセールスはアヤシイですよ」っていうやつがもっとアヤシイ。
2009/02/05(木) 01:02:27
Intel delays Itanium upgrade to add new capabilities
http://www.networkworld.com/news/2009/020409-intel-delays-itanium-upgrade-to.html
2009/02/09(月) 04:41:33
>>496
Sunの広告が表示されるページの内容なんて・・・
2009/02/09(月) 07:03:05
あははははは
広告って効果的だね！
2009/02/11(水) 19:42:05
Tukwila、もう出ないんｼﾞｬﾏｲｶ。
http://www.atmarkit.co.jp/news/200902/09/intel.html
2009/02/12(木) 10:51:40
いよいよ i960が 64bit、QPIになって復活します。
2009/02/13(金) 10:55:34
次世代 ISAのために HPと組む、というのはもう失敗したので、
次どっかと組む必要ありだろうな。
ARMは捨てちゃったし。Alpha買ってくる、とかw
いずれにせよ、もう新しい ISAを定義する必要はない。
POWER対抗、という軸で考えると、SPARCという選択肢もあるかもw?
2009/02/13(金) 11:07:16
SPARCみたいな変態アーキ使うくらいだったら、
素直にそのままIA64で続行してても大して変わらないし、
SPARCのインストールベースを狙いたいんだったら、
x86でItaniumクラスのCPU作る方が遙かに良いだろ。
2009/02/13(金) 11:56:34
IA-64はオープンソース方面がぜんぜん関心示さないのが致命的でしょ。
性能出せるコンパイラーが CPU開発してる近辺からしか入手できないという
ことだと、利用が拡がらない。
2009/02/13(金) 12:27:42
しかし、それを言い出すとやっぱりx86 ISA最強になってしまうだろう。
それにこのクラスのCPU使う所って、そんなにオープンソース使うか？
エンプラに限らず、ハイエンドから組み込みまで狙うっていう話だったら
別だけどね。

そのエンプラでさえIA64が流行らない最大の理由はintelのやる気の
なさにつきるだろう。
POWERだって一時はイマイチだったけど、POWER4あたりからの
IBMの気合いの入れっぷりを見て皆ついて行って、成功したんだし。
2〜3年に1回、ライバルに対して半世代遅れな性能の製品しか出て
こない様では誰もついて行かないよ。
2009/02/13(金) 12:30:06
>>501
AlphaってHPじゃんw

そもそもItaniumみたいなVLIWならともかく、
古典的なISAをまた始める意味は全くないでしょ。
箱ごと売っているSPARCとPOWER以外は死滅したわけだし。
2009/02/13(金) 12:32:05
>>504
やる気はあったけど、うまくいかなかったんだよね。
なにしろSunまでItanium Solaris出してたんだから。
507504
垢版 |
2009/02/13(金) 12:40:26
>>506

Solaris/ia64は計画段階でやめたんじゃ無かった？

intelもMadisonだした直後くらいまではやる気あったと思うけど、
その頃からx86でAMDに押されまくって、IA64なんて言ってる
騒ぎじゃなくなってからの放置っぷりが酷すぎる。

んで、Core MA出てからは、もうサーバーもこれで良いんじゃないという
流れになって、ますますやる気ナッシングに。
そして、今度出るNehalem-EXとか見るとRASもかなり意識していて、
もうIA64やる気無いだろうと思ってしまう訳で。
508504
垢版 |
2009/02/13(金) 12:45:20
あとは個人的妄想だけど、NECと共同出資で富士通あたりが引き取れば
いいのにとか思ってしまう。
レジスタウィンドウもどき持っている辺り、SPARC 64と同じ変態系だしなｗ
2009/02/13(金) 13:10:24
>>503
オープンソースな人たちはgccを使うわけだが、そのgccの生成するIA-64のコードが酷かった。
さらに人間がバイナリレベルでデバッグするのが難しく、さらに、マシンチェック回りはアマチュアには無理。
つーわけで、オープンソース方面ではIA-64バッシングが激しかったんだよ。
2009/02/13(金) 13:15:59
>>505
> そもそもItaniumみたいなVLIWならともかく、

いやいや、VLIWがやっぱり長期互換性の必要な ISAとしてはダメってことを
証明したんでしょ、Itaniumがさ。

> 古典的なISAをまた始める意味は全くないでしょ。

RISC最強w
2009/02/13(金) 13:17:17
>>509
つまりそれは「バッシング」じゃなくて、「正しい見解」、じゃんか。
しごくまっとうな言い分だと思うけど。
2009/02/13(金) 13:19:12
>>509
最後の一行は君の妄想だと思うw
2009/02/13(金) 13:23:17
>>510
いえいえ、x86最強でしょう。

ARM - x86 - POWER(SPARC)の棲み分けでいいんじゃないでしょうか。

しかしIntelは、x86の省消費電力で出遅れたり、
経営戦略の方がさっぱりですね。
2009/02/13(金) 13:23:23
>>505
HPとSamsung（とAPI）が持っていると思われる権利をある程度買ってくれば
なんとかなるかもね
2009/02/13(金) 13:30:58
>>510
静的最適化の世代間互換を諦めていれば、性能はともかく
バイナリ互換は残せるので、もっと早く進歩できたと思うんだけどね。

最初に短いパイプラインで出してしまったので、それを前提にした静的
最適化の効果を残そうとすると、パイプラインを長くする事ができなくて、
クロックが伸び悩んだというのが躓き始めだと思う。
かといってOoO実行に走ると、そもそもEPICの意味がってなるしね。
2009/02/13(金) 13:34:44
Samsungへのライセンシングは終了してるんじゃないのかな。
2009/02/13(金) 13:39:58
>>515
「静的最適化の世代間互換」は、今から諦められないの?
要は、バイナリ互換だけど昔コンパイルしたバイナリは遅い、ってことよね?
まあ、そんな珍しい話でもないよね。程度もんだけど。
2009/02/13(金) 13:42:57
>>514
なんか、DECの残党かき集めたやつが勝ち、みたいな雰囲気感じるんだけど、
気のせい?w
2009/02/13(金) 13:47:06
>>517
マルチコア、マルチタスク環境下で混在すると、
うざいことこの上ない。
2009/02/13(金) 13:53:01
>>517

OoOプロセッサだと最適化世代が違ってもそれなりに動くが、
インオーダプロセッサだと性能の落ち方が大きいし、あとまあ
519の言うような事もあるだろうな。
ということでHPが嫌がって、アグレッシブプランは葬り去られた。
2009/02/13(金) 13:58:53
古いパイプラインのエミュレータを置けって事だからね。
iOにした利点の全てが吹っ飛ぶ。>>515と並行関係にある問題。
2009/02/13(金) 16:13:01
んじゃ、詰んでんじゃん。ダメじゃんww
2009/02/13(金) 16:20:01
やっぱ ISAは RISCで択一。
2009/02/13(金) 16:30:33
>>510
互換性のシガラミとしては、遅延スロットに比べればマシだろ。

>>511
酷いコンパイラを作っておいて、それを使ってパフォーマンスが出ないとか、もうね。

>>512
IA-64は糞だって表明したオープンソース界のカリスマもいたよ。

>>515
すでに、初代ItaniumとItanium2の間で、最適化の互換性を捨ててるよ。
それによって動作クロックが僅かしか上がらなかったのに実効性能は倍になったよ。
2009/02/13(金) 16:34:06
>>523
長期的に使うISAとしてはRISCは粒度が細かすぎる。

同じことをするのにも多くの命令を必要とすることは、
同じことをするのに多くの命令間の依存関係を調べる必要がある。

しかし、やりたい操作と命令が一対一対応していれば、調べる範囲が狭まる。
2009/02/13(金) 16:41:58
>>524
gccの吐いたコードの速度を基準にしていったわけじゃないのでしょう？
2009/02/13(金) 16:48:45
うわ。ホンモノっぽいの出てきたな。
別にコンパイラ作りようがない、って言ってたんじゃなくて、
作るのが難しい、この先保守もたいへん、って意味でしょ。
それで十分だし。ISAを否定するには。
それに、某カリスマ（なのかね、ほんとにww）が青筋たてて言ったことは
これまでほとんど間違いばっかりだったから、気にするだけ損かとww
2009/02/13(金) 17:07:10
IA64は本当に糞だったのでは?
2009/02/13(金) 17:11:15
>>526
彼らにはgccしかなかった。

オープンソースで、GPL汚染されているコンパイラで、他に何かありました?
2009/02/13(金) 17:11:42
IBMと Sunがビビって賛同して、少し首つっこんだらすぐに離れたから、
そうじゃないかとは思ってた。
2009/02/13(金) 17:12:44
彼らが離れたのは、初代Itaniumがスケジュール遅延したからでしょ。
遅延した結果、自社で抱えているプロセッサのほうが性能が上になってしまった。
2009/02/13(金) 17:16:45
>>528
「x86を置き換えて、ノートPCあたりまで IA-64」とか当初の目標を達成する、という
意味では、十分に「クソ」です。

「x86をシミュレーションしてぜんぜん性能出ない」という意味でも、十分に「クソ」です。

ええ、つまり、＊クソ＊です。w
2009/02/13(金) 17:17:13
>>509は
> オープンソースな人たちはgccを使うわけだが、
> そのgccの生成するIA-64のコードが酷かった。
> さらに人間がバイナリレベルでデバッグするのが難しく、
> さらに、マシンチェック回りはアマチュアには無理。
> つーわけで、オープンソース方面ではIA-64バッシングが激しかったんだよ。

gcc基準でIA-64をバッシングしていたってソースはあるの？君の脳内以外に

2009/02/13(金) 17:18:35
>>531
それは違うと思うよ。そういうタイミングじゃなかった。
首つっこんで、なんか具体的なもん見た結果、ビビる必要はない、と判断したように
オレには見えた。
2009/02/13(金) 17:26:17
>>531
Sunが最後に表明したのは情報公開が足りないってことだった。
次期CPUとその足廻りの技術情報を出し惜しみしているから、
次のItaniumマシンの設計が出来ないと。
当時も言われていたけど、遅れていて出そうにも出せなかったんだね。

>>534
SunはItanuimのJDKさえも作っていて当時は結構乗り気だったよ。
一時HPよりもSolaris IA64機の話題の方が多かったくらい。
2009/02/13(金) 17:44:55
>>535
当時 Sunは MAJCやってたし、IBMも VLIWずっと研究してたから背景知識は
持ってたはず。で、実際 Solarisの CPU依存部分を実装してみて
「なんだこりゃ」ってなったんじゃないかと推測してる。
「なんか隠してるに違いない」と思ったのかどうだかは知らんが。
いずれにせよ、恐るるに足らん、という結論だろうな。
2009/02/13(金) 17:57:14
> 背景知識は持っていたはず

pgr
パソヲタじゃあるまいし当たり前
NGNG?2BP(0)
流れきってすまん。
CRAY CX1ってこのスレ的にはどうなの?
2009/02/13(金) 21:34:17
>>532
スケジュールが遅延したからな。

本来ならPentium2のデビュー頃に市場に投入されるハズだったのだろう。
Pentium2 233MHzと初代Itaniumのx86命令の実行性能は同程度だというから。
2009/02/14(土) 12:43:10
Transmeta Crusoe…
2009/02/14(土) 13:45:18
>>538
どういう関連があるの？
2009/02/14(土) 15:48:10
IA64の方が高性能な互換プロセッサ簡単に作られちゃうとかあるんじゃないの？
2009/02/14(土) 16:55:13
SPARC以上に、命令セットとハードウェアが一体なので、どう作っても同じになっちゃう。
2009/02/14(土) 18:59:01
インテルとしてはx86のブラックボックスが一番都合がいいんじゃないの？
Itaniumでも同一命令グループをいかに効率よく実行するかというところで
知恵の働かせどころはあるけど
2009/02/14(土) 23:46:10
そんなに工夫の余地、あったかなぁ。
2009/02/19(木) 16:11:55
ARMきてるな。
Itaの連中も x86のテコ入れに駆り出されちゃってるじゃん。ホネぬ〜き状態ねw
2009/02/20(金) 22:01:45
Unisys threatens Itanium with death
http://www.theregister.co.uk/2009/02/19/unisys_xeon_unisys/
2009/02/23(月) 04:59:40
>>546
>Itaの連中も x86のテコ入れに駆り出されちゃってるじゃん。ホネぬ〜き状態
いまさら何を・・・ここ1,2年はましな方。4年前はもっと酷かったぞｗ
2009/02/23(月) 07:42:52
Intelは、ItaniumやらずにSPARCとバイナリ互換のCPUを作るべきだったんだよ。

2009/02/23(月) 17:42:58
ISAが SPARCで内部実装が VLIWなら Dave Ditzel連れてくりゃすぐ作りそうだなww
だが Sunでそれをやらなかったのにはそれなりの理由があるかも。
2009/02/23(月) 17:55:06
>>550
SPARC時代にハードウェアによる互換性維持に嫌気がさしたからCodeMorphing。
けど今はIntelにいるからやるかもね。
http://www.theinquirer.net/inquirer/news/264/1017264/dave-ditzel-joins-intel
2009/02/23(月) 20:44:34
IA-32ELだろ?
2009/02/24(火) 10:25:14
知識ないんだな。
2009/02/24(火) 10:40:39
最近はマルチコアを有効に利用するための
バイナリ変換に取り組んでいるらしい。
2009/02/25(水) 23:48:23
へぇ
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況