パスワードを忘れた？ アカウント作成
Close
208840 story

Microsoft が Itanium 向け開発終了を宣言 67

ストーリー by reo
結局 Itanium に触れたことがない 部門より

gurt 曰く、

Microsoft が Intel の Itanium プロセッサ向けの製品の開発をやめることにしたそうです (ITpro no 記事より) 。

先日、富士通も基幹 IA サーバを Itanium から Xeon に切り替え、今後 Itanium は使わないという発表を行ったばかりですが (@IT の記事) 、このままじわじわと Itanium は消滅していくことになるんでしょうかね。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Microsoft が Itanium 向け開発終了を宣言 More

  • MicrosoftにとってItaniumは良い踏み台だった (スコア:2, 興味深い)

    by Anonymous Coward on 2010年04月07日 12時29分 (#1744819)

    マイクロソフトにとってのItaniumの最大の価値は、スケールアップのアップグレードパスの存在を客に示せるということにあったと思う。

    客は夢見がちで、すぐにx86 + SQL Serverでは処理しきれないほど急成長するリスクに備えたがる。そういうときに、Itanium + SQL Serverがあるから大丈夫と言えたことが大きい。
    ほとんどの客はx86サーバの性能向上のスピードを上まわる急成長はしないし、急成長したらサーバのハードウェアのスケールアップだけでは対処できない。

    AMD64が軌道に乗るまでのあいだ、Itaniumは見せ玉として本当によくタダ働きしてくれました。

    • Re:MicrosoftにとってItaniumは良い踏み台だった (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2010年04月07日 13時06分 (#1744864)

      ＞AMD64が軌道に乗るまでのあいだ、Itaniumは見せ玉として本当によくタダ働きしてくれました。

      タダじゃないだろ。むしろ見せ球としては高くつきすぎたのでは。

      シェア
      親コメント

      • Re:MicrosoftにとってItaniumは良い踏み台だった (スコア:2, 参考になる)

        by Anonymous Coward on 2010年04月07日 14時16分 (#1744914)
        見せギョク、ね。
        シェア
        親コメント

        • Re: (スコア:0)

          by Anonymous Coward
          野球用語で「見せ球」ありますよ。一応ね。
          本命が別にあるという意味では正しいかも。

      • Re: (スコア:0)

        by Anonymous Coward

        存在そのものが安心感となって保険として働き、
        実際に顧客が買わないで済んだのだから結果的にコストダウンには貢献しているよ。
        MSは自社製品の採用を増やせたんだから文句ないだろう。

        Intelの用意したIA-64という豪華な階段は、いつのまにか吹き晒しの非常階段レベルの扱いになり、
        次いで吹けば飛びそうな梯子がかけてあるだけの状態になって、今回はロープが結んであるだけになった。
        きっとそのうちこのロープも切れるに違いない。

        • Re: (スコア:0)

          by Anonymous Coward

          >存在そのものが安心感となって保険として働き、
          >実際に顧客が買わないで済んだのだから結果的にコストダウンには貢献しているよ。
          その為に開発費が１ライン分必要だった訳ですが。

          • Re: (スコア:0)

            by Anonymous Coward
            マイクロソフトにとっては研究開発費として許容できる範囲だと思いますよ。
            Itanium版Windowsの採用事例からのフィードバックが得られたことや、サーバのメーカーと協力して色々やったことは、x86版やx64版にも何らかの形で役に立っていると思う。

        • Re: (スコア:0)

          by Anonymous Coward
          > きっとそのうちこのロープも切れるに違いない。

          東証のことか。

  • 64bit版Windowsのタコな仕様はItaniumのせい (スコア:2, 興味深い)

    by Anonymous Coward on 2010年04月07日 13時28分 (#1744879)

    x64版Windowsで64bitコード←→32bitコード間の呼び出しができない（thunkがない）のは、Itanium版Windowsの仕様に合わせたから。
    そのせいで64bitコードと32bitコードをシームレスに実行できるAMD64のメリットがWindowsにおいては全く生かされていない。

    言わばItaniumの負の遺産。
    後方互換性にこだわるMicrosoftのことだから、128bit版Windowsが出るまでこの仕様に悩まされそうorz

    • Re:64bit版Windowsのタコな仕様はItaniumのせい (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年04月07日 14時34分 (#1744923)
      デタラメを言ってるように見えます。

      もう少し具体的に説明してくれませんか? あるいは、外部のソースを。
      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        なんで誰でも分かってる様な調べりゃすぐ出てくる既出なことを説明せにゃならんのだね
        それをすることで我々にどんなメリットがありますか？

        ＃しかも、あなたは多分説明しても分からないレベルでしょうに

        • Re:64bit版Windowsのタコな仕様はItaniumのせい (スコア:1, 興味深い)

          by Anonymous Coward on 2010年04月07日 22時34分 (#1745183)
          デタラメを言う人ほど説明を嫌がって逃げますね。

          AMD64なら32bitと64bitのコードがシームレスに実行できるといっても、現実的には64bitModeとCompatibilityModeの切り換えは必要なので、同一OSインスタンス上で32bitのプロセスと64bitのプロセスが同居できるという意味です。
          (64bitModeのまま従来の32bitのコードを実行できるといっても、CPUが命令をデコードして実行できるだけであって、プログラマが望むような動作をするわけではありません。)

          64bitのEXEから32bitのDLLを呼び出せない、32bitのEXEから64bitのDLLを呼び出せないという仕様は当然です。Win32APIのDLLならExportしているプロシージャの引数の仕様が明らかですからthunkを作ることができてWOW64がそうしていますが、しかし、サードパーティのDLLのためのthunkはマイクロソフトには作れません。サードパーティがthunkを提供するなら64bit版のDLLをビルドして提供したほうがいいでしょう。
          シェア
          親コメント

        • Re: (スコア:0)

          by Anonymous Coward

          巷に出回る多くの説明が間違っていると言うことを認識出来ないかわいそうな人だな
          ほとんどの人がわかっちゃいない

    • Re: (スコア:0)

      by Anonymous Coward

      Windows NTでセグメントが使えない(少なくともユーザーモードのCプログラムから隠蔽されている)のがRISCプロセッサの負の遺産だとは思わないけどなあ。
      それは今だから言えることかもしれないけど、128bit版Windowsが出る頃になったらWOW64の仕様についてもやっぱり同じような感想を持つんじゃないかな。

      • Re: (スコア:0)

        by Anonymous Coward
        セグメントの有用性は昔から明らかで、ItaniumにもPOWERにもあります。
        現在でもグーグルのNaClなどで活用されていますから、RISCプロセッサというよりもセグメントのないOSつまりUNIXの負の遺産ですね。
        8086で、セグメントについての無知ゆえの勘違い思い込みからトラウマになった人が影響力を持ったからかもしれない。MSは一役買ってるな。DRとインテルは無罪。

        • いや, UNIXはセグメントありますよ. 例えば初期のVAX-11 [roguelife.org]のころからセグメンテーション機構を利用していますし, セグメンテーションバイオレーションなんてエラーはセグメント機構を使ったメモリ保護が無ければ出ようがないでしょう.

          それに, セグメントの評判を落としたことにインテルの責が無いとは言えないでしょう. 386登場以前は1セグメントで取り扱えるアドレス空間が64k(16bit)に限られていて, ちょっとプログラムの規模が大きくなるとプロセス内でセグメントを動的に設定しなおすというアクロバティックなことをしなければならなかったのですから. これが, セグメント単位がハード的なアドレス幅と同じ20bitとか, あるいはせめて18bit程度だったら評価は全く違っていたと思います. まあ, 当時のハードウェアの性能とかコストとかの兼ね合いで16bit幅のセグメントにしたんだろうことは理解はできますが. 言い方は悪いですが, こうしたハード側の手抜きをソフト側でカバーさせようとするのは, IA64でも同じだったのかと思います.

          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward
            PDP11ハードウェアはセグメンテーション機構を備えておりUNIX 7もそれを利用した仮想記憶を実装していましたが(スワップ)、
            VAXなどでページング機構が導入されるとそちらを使いセグメンテーションは捨てていますね。

            8086は最初からミッドレンジのアプリケーションプロセッサでマニュアルにも明記されていました。ハイエンドではないですね。
            あなたも軽トラに10t載せたがるタイプですか？やっぱりトラウマで目が曇っているとしか。

            • Re: (スコア:0)

              by Anonymous Coward

              80286は?
              それこそ80286でせめてセグメントサイズ1MBにできればよかったんですが。
              別にハイエンドでもない68000は16MBリニアアクセスできましたし。

              • Re: (スコア:0)

                by Anonymous Coward
                80286はハイエンドではありません。iAPX432がハイエンドです。
                68000はハイエンドですね。6809がミッドレンジです。

              • Re: (スコア:0)

                by Anonymous Coward
                私も以前は286でセグメントサイズを大きく出来ていればと考えたこともありますが、
                現在は「無理だった」と考えています。

                まず、セグメント内のアドレッシングが16bitで足りなくなります。
                となると、命令セットを作り直しですね。
                分岐命令やデータアクセス関係のアドレス指定はビット数の拡張が必要。
                インデックスレジスタの幅も拡張しないといけないし、その拡張した17bit以上の
                幅を持つレジスタに一発で値をセットできる命令も必要でしょう。
                （8086のMOV命令は16bitデータまでしか転送できない）

                もともと286はリング保護のプロテクトモードを拡張するためだけに作られたような
                CPUですから、基本の命令に手を入れるのはやっぱり386を待つ必要があったでしょう。

          • Re: (スコア:0)

            by Anonymous Coward

            少々極論が過ぎるんじゃないかな。Itaniumが企画された当時、ハードウェアによる
            命令実行の並列性の向上はいずれ限界が来るだろうという予測はまあまあ妥当で、
            それを打開するためにVLIW、その改良であるEPICの採用に踏み切ったのは技術的に
            チャレンジだったと言えるでしょう。
            コストや8ビットのハード＆ソフト互換性などの制約から、やむなく64k/セグメントを
            採用した8086とは質的にかなり違う。互換性をかなぐり捨てて、あまり例のない
            アーキテクチャを採用したわけですしね。
            残念ながら成功したとはいえないものの、それは結果論で、チャレンジがなければ
            EPICやそれに類するアーキテクチャの限界も見えてこなかったわけだから
            その点だけでも意味無しとは言えんと思いますが。

    • Re: (スコア:0)

      by Anonymous Coward
      64bit云々より
      Intel IA64 と Intel x64(EM64) では根本的にアーキテクチャが違いますよね?

      AMD64 と互換性がある(というか渋々真似した)のは Intel x64(EM64)な訳で、
      今回のIA64のItaniumとは関係ない話の様な気がするのですが…。
      IA64が駄目だからx64用も駄目で行くよー、という話だったんですか?

      そもそもIA64(Itanium)用のWindowsってリリースされてたんですね。

      まあ、何にしてもいいかげんWindowsには完全64bit環境に移行して欲しい…。

  • HP-UXとHP Integrity Serverがある限り続くんじゃ (スコア:1, 参考になる)

    by Anonymous Coward on 2010年04月07日 12時41分 (#1744835)

    ItaniumにおけるMSの存在感はすでにないですからね。
    もはやItaniumはHPのものじゃないのかという気も。

    エンタープライズ分野におけるHPのサーバの存在感はまだそこそこ
    大きいんで、それが続く限りItaniumも続くんじゃないですかね。
    いずれXeonなりに置き換わるかもしれないが、まだしばらくは大丈夫でしょう。
    新しいXeonが出るたびにItaniumどうしたみたいなことを言い出す人は多いけど、
    見る場所が違う気も。

  • ところで、今までこの手の話題が出てきた場合

    「アーキテクチャ的には素晴らしかったが、商売としては失敗したね」

    ……と言った声が、多少は出るものなのですが。
    Itaniumに関しては、アーキテクチャ的に惜しむ声を余り(と言うか全く)聞きませんね。

    かなり今更な話になるのですが、純粋に技術面から見たItaniumってどうだったのでしょうか？

    • 他の人からはクソみそに言われるでしょうから、5年ぐらい IA-64 と付き合った者として餞別代りに Itanium を擁護してみます。

      個人的な感想としては IA-64 は「はまったコードは非常に速いが、外れたコードは非常に遅い」アーキです。
      ただ「はまったコード」」を生成するには icc のような最適化コンパイラが必須です。
      また最適化コンパイラがあっても、「はまったコード」にコンパイルできないアプリも多いです。gcc とか perl のようなのが特に苦手。

      命令アーキテクチャとしては、尖った機構がふんだんに存在しています。

      • IA-64 は VLIW 的な 3 命令組の「バンドル」を持つが、このバンドルを前後に組み合わせて「命令グループ」が実行単位になる。ハード資源が許せば1命令グループは最大1サイクルで実行可能で、命令グループ内のバンドル数に制限はない。理論上は何十命令でも並列実行可能。ただし Itanium2 は最大2バンドル6命令まで。
      • 整数レジスタと浮動小数点レジスタが約 128 本使える。レジスタが不足することはまずない。
      • 整数・浮動小数点レジスタのうち 96 本(r32-r127) は stack-register で、これは関数呼び出しの前後のレジスタスピルコードをほとんど不用にしてくれる。C 関数で言うと第一引数が r32 に割り付けられ、関数の call/return に応じて配置が変わる。
        SPARC の register-window に似ているがあちらは物理レジスタが不足した時にソフト割り込みが懸って OS が処理する必要がある。IA-64 は CPU 内の Register-Stack-Engine が stack-register をメモリに自動的にロード・ストアしてくれる。そのため関数呼び出しが非常に高速。
      • Register rotation と呼ばれる機構があり、ソフトウェアパイプライニングをハードサポートしてくれる。数値計算系は高速実行可能。
      • プレディケートがある。実質全ての命令がプレディケート修飾可能で、コンパイラ最適化の IF-変換が効率よく実現できる。そのため条件分岐を極限まで減らすことが可能。
      • 条件分岐命令毎に動的分岐予測を使う否かの指定が可能。分岐方向ヒントも埋め込める。分岐予測の精度が上がる。
      • ループ専用分岐命令があり、効率よく使うと分岐ミスペナルティがなくなる。
      • 投機ロード(load.s)や先行ロード(load.a)によって制御投機やデータ投機をソフト的に記述可能。例えば先行ロードは、本来ロードの位置より先行して発行し、真のロード位置に専用のチェック命令を実行する。CPU が先行ロードからチェックの間にメモリ内容に変更がないことを監視しており、書き替えがなければそのまま実行が続く。大胆にメモリレイテンシを縮小可能。
      • ビット操作が得意。
      • 多方向に分岐が可能。Itanium2 なら1サイクルで 4 方向(taken:3, not-taken:1) に飛べる。switch 文みたいなのがうまくコンパイルできる。
      • 仮想記憶機構が素晴らしくリッチで、他の CPU の特徴をほとんど包含している。エミュレーターを書くには便利。

      あと Itanium2 としての特徴ですが、

      • 分岐履歴情報なしの間接分岐予測を持っている。うまくコードを書くと分岐予測ミスペナルティを 0 にできる。
      • メモリアクセス能力が高い。1サイクルにロード2回、ストア2回を同時発行可能。

      良いのか悪いのか分からない点としては、

      • メモリアクセスのオーダーリングが著しく緩い。通常のロード・ストア命令は実行順序に制約がない(release-consistency)。メモリアクセスの順序を付けるには特殊なロード・ストア命令を使う必要がある。

        CPU から見ると高速化が可能。プログラマーとしては非常に困った性質で、C 言語だと volatile を付けないと通常のロード・ストア命令が生成されるので、他のアーキ用に書かれたマルチプロセッサ用のソースコードが容赦なく異常動作する。

      悪い点は、やっぱり Out-of-Order 実行がない点ですね。命令グループに命令をそんなに詰め込めないし、ロード命令がウェイトすると後続命令は実行できないので、結局性能が上がりません。OoO を導入するには論理レジスタ数が多すぎることがネックになると思います。

      --
      コンタミは発見の母
      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      部門名につきるのでしょう。

    • Re: (スコア:0)

      by Anonymous Coward
      Itaniumにつていてば、設計時点の技術トレンドを読み違えたということに尽きるのでは。

      ItaniumはRISCの処理能力（クロック周波数）が頭打ちになるという想定で設計された。
      VLIWとか豊富なページサイズのサポートとかいかに周波数以外のところで速度を稼ぐか
      という思想で設計されてる。（クロックチックを縮められないなら1クロックでできる
      ことを増やそうという発想）

      けど、実際はそうはならず、プロセッサの周波数は4GHzにも達しようという勢いで、
      8とか12とかのマルチコアなわけです。こんなもの一個のOSでは役不足なんですが、
      計算能力の需要が頭打ちなら仮想化しよう。そのためにはメモリ積めるだけ積もう。
      ページテーブルキャッシュすれば4Kページで128GBも夢じゃない。？！
      てなシステムが現在の主流です。

      どうみても不利なわけです。この上さらにIO仮想化とかつけてくれといわれる前に逃げ
      出すのが企業としては正解だと思う。

      • Itaniumにつていてば、設計時点の技術トレンドを読み違えたということに尽きるのでは。

        いや，開発ロードマップ通りに行かずに出遅れたことに尽きるでしょう

        当初の Intel+HP連合軍(1994～)による開発ロードマップ(取らぬ狸の計画)では，

        1. 1998,9年前後(?)には実戦投入を予定
        2. その投入予定時点での予想されるx86系を(圧倒的に)越える性能を実現
        3. (結果的に評判の悪かった)IA-32 エミュレーションも IA-64 の"圧倒的高性能"で， ソフトウェアエミュレーションでも十分に「既存 x86並」程度は実現できるはずだった
        4. 価格も Intel の力で PC-MPU(x86) なみの生産体制で パソコンとして手が届くレベル(高くてもせいぜいXeon程度)の値段

        計画された1990年代前半は PC用x86CPUと WS用CPU(AlphaAXP,Sparc,PA-RISC,POWER)軍団との 間には結構な性能差がありました(浮動小数点は圧倒的な差で，整数演算でも倍程度は違った気がする)． Pentium投入時点でもまだRISC陣営とは結構差がありました． その時代に，Intel が将来のWS系の市場を制覇するためにHPと連合を組んだわけです． WS用CPUのパワーを持ってすれば，市場投入予定時点のPC用x86なんて楽勝で越えられるはずでした． またエミュレーションにしてもその圧倒的(以下略)． 最後の点は微妙な推測かも知れませんが…．

        ただ，開発が難航しているうちに，x86がAMD(+NexGen Nx686) K6～K7との競争で， 整数演算ではWS用RISC系に追い付く状況になる(1GHz競争のころ)なかで， 初代 merced が登場したときには x86処理に弱いIA-64CPU はPC用としての芽がなくなってしまいました． 実際Mercedの開発が遅れまくった証しとして，Merced 登場(2001)後1年程度で 早くも IA-64 2世代目の McKinley が出ています(2002)．

        いざ生まれてみたら住むところがほとんどなくなっていたという， 今にしてみれば可哀想なCPUだと思ってます． (まあ，「予定された性能を叩き出せなかったCPU」とか「不幸な運命をしょったCPU」なんて 他にも籠から溢れるくらいありますけどね…)

        シェア
        親コメント

      • Re: (スコア:0)

        by Anonymous Coward
        違います。設計時点では命令並列度を引き出すための論理の複雑度を落とそう、従って同程度の命令並列度をハードウェアで引き出しているマシンよりはクロックを上げよう、という考えでした。現実には演算器が回るように設計できなかったのも事実ですが、その時点のトレンドの話よりは少し後 (そう、2003 年ぐらいか) のトレンドの話です。何が悪かったかというと、…… なんとなく見当付くけど。

        ＃ま、いちおう AC にします。

  • x86版バイナリが600K位なのに同じソースをIA64向けにコンパイルすると2M越えになってびびったのが懐かしいです。
    2003年9月でした。
    それから待てど暮らせど、一般に降りてこないし、Itaniumは速くならないし、.NET 1.1の64bit版もない。
    そのうえでx86エミュレーションが遅いと。
    その状況だと、.NET 1.1で書いたものをItaniumで走らすより、x86系CPUのほうが速いし安いということになりかねない。
    (たぶん)その後、.NET2.0で64bitもできるようになったら、AMD64がでてきて安いし .NET1.1 32bit, .NET 2.0 32/64bit 全部普通の速度で走る。
    WIN64ネイティブアプリは対応製品がない。64bitに対応したと思ったらAMD64版だけだったとかもありそう。
    ItaniumはOracle専用マシンならHP-UXでいいきがするし、どっち向いてもWindowsの出番があんまりなさそう。
    kb924449 [microsoft.com]の MSのコンパイラが吐くコードがおかしい問題だって、話題にならなかったみたいだから、ほとんど誰も使ってないということでしょう。
    こんな感じに情報だけ拾い続け、結局クロスコンパイルするだけで、私は実行することが一度もないまま消えていくのですね。

    #ハイエンドサーバー系は完全に外野なので突っ込み歓迎

  • 百五銀行の担当者が真っ青 (スコア:0)

    by Anonymous Coward on 2010年04月07日 23時39分 (#1745214)
    XeonにRASが実装されたといっても、Itaniumほどではないみたい。

    そうすると、数年前にWindowsで勘定系を稼働させた百五銀行は、
    将来的にはハードウェア更改のパスが無くなることを意味する。

    RAS装備とはいえ、Itaniumより信頼性が落ちる新生Xeonを使うか、それとも・・・・

    やはり、Windowsなんかを勘定系に採用なんかしちゃうからこんなことになるんだよ。
    メインフレームを捨てるとき、せめてUNIXにしておけば、いろいろ手段はあったのにね。

    • Re: (スコア:0)

      by Anonymous Coward

      問題をすり替えてWindowsを貶める流説ですか
      「みたい」とか、ほどじゃない所挙げて言い切れよ
      あとなんで将来に今現在のXeon使うんだよ

      • Re: (スコア:0)

        by Anonymous Coward

        ??? Windowsを使っている限りにおいてハードウェア更改パスがなくなったことは事実ですよね。
        「みたい」がついているのはRASのことであってWindowsを貶す文脈じゃないですね。

        もうちょっと地に足のついた反論をしてくださいな。

typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家