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

Itaniumは「風前の灯火？」 113

ストーリー by soara
Itaniumのニュースは2007年10月で途絶えているが… 部門より

insiderman 曰く、

ITmediaに「ハイエンドチップのゆくえ：Itaniumの将来は風前の灯か？」という記事が掲載されている。現状、クライアント向けやローエンド/ミッドレンジサーバー向けではCoreシリーズやXeonシリーズといったx86 CPUが一人勝ちの様相をしているが、ハイエンドサーバー向けサーバー市場を見ると、HPが推すItaniumやIBMのPOWER、富士通/Sun MicrosystemsのSPARCといったCPUが未だにシェア争いを続けているが、Itaniumは順調に性能向上が進むXeonに食われ、その地位を失うのではないか、という内容だ。

確かにここしばらくItaniumについてはニュースも少なく、Intelもサーバー向け製品としてはXeonに力を入れているように見えてしまう。日本は世界的にもItaniumの採用例が多い、という話も聞くが、現在、実際のところハイエンドサーバー市場ではどのCPUが人気なのだろうか？ 現場で働く方々のご意見を伺いたい。

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

Itaniumは「風前の灯火？」 More

  • ここでItaniumのアドバンテージをまとめとくか (スコア:5, 参考になる)

    by Anonymous Coward on 2008年09月29日 22時57分 (#1428573)
    ・Xeonは仕様上16wayまでだが、8way以上のシステムが組めるチップセットは供給されていない。
    Itaniumは最大64wayで、HPから最大64way、富士通から最大32wayのサーバが出荷済み。

    ・XeonはCPUを増やしてもリニアに処理性能が上がらない(どこかで頭打ちになる)。Itaniumは増やした分だけ処理性能が上がる。

    ・Xeonには、Itaniumに装備されているロックステップ(プロセッサ二重化)が装備されていない。

    ・Itaniumは扱える物理メモリ量がXeon(Intel64)よりも大きい(詳細数値は忘れた)

    と説明しています(笑)
    SMP(多プロセッサ環境)での性能頭打ちは公開ベンチでも結果に出てるようです。

    ただ、Itaniumの石１コでXeonのサーバが何台買えるか、を考えると、超ハイエンド領域除いてどうでもよくなってくる気がしますｗｗｗｗｗ

  • だって移行が大変だし (スコア:5, 興味深い)

    by ich84 (33072) on 2008年09月29日 23時20分 (#1428593)
    1年ほど前に、32bitシステムを64bitに移行する仕事をやりました。

    AMD64の場合は型の変更だけでほとんど何とかなったのですが、IA64の場合、データのミスアライメントが起きると致命的なので、データ構造から再設計するハメに。

    AMD64対応は（泣きそうでしたが）何とか完了したのですが、IA64対応は困難を極め、これ以上やってもペイしないという判断によりIA64のプロジェクトは途中で解散しました。どうせそんなに市場ないしね。

    昔のプログラム遺産がほとんど使えないのでItaniumはつらいと思います。

    • Re:だって移行が大変だし (スコア:2, 興味深い)

      by pz00 (10663) on 2008年09月30日 14時22分 (#1428900)

      2年前にPA-RISCからIA64という形で32bit→64bit移植を行いましたが、 HP-UXはコンパイラやライブラリのサポートが充実しているので、 そのまま動作させられましたよ。

      ミスアライメントで例外が発生した場合は、バイトアクセスして中断点復帰するので、 何も考えていないコードでもパフォーマンスを犠牲に出来れば動作させることは可能でした。

      本当に「そのまま」にしちゃうと例外発生時のペナルティが大きいので、 アライメント調整可能な部分は調整し、 どうにもならないところだけライブラリに救ってもらう事にしましたが。

      シェア
      親コメント

  • 広告サイトの記事らしく (スコア:4, 興味深い)

    by Anonymous Coward on 2008年09月29日 23時18分 (#1428590)
    > 企業ユーザーに正確な情報を提供する必要姓があるのではと考えた。

    考えただけで、その後の記事の内容は「正確な情報」とは言えない代物だが、
    スポンサーの意向でマーケティングを行う、広告サイトの記事だから、
    それは重要ではない。肝心なのは、この記事のスポンサーが誰か。

    Itaniumをやっていないメーカーなのか、
    Itaniumをやってきて、実は撤退したいのだが自分からは降りれないのでItaniumに終わって欲しいメーカーなのか、
    メーカー内のItaniumをやっている部門が邪魔なので潰したい他の部門なのか。

    Itaniumに関わっているすべてのメーカー・部門・人が、
    走り出してしまった以上、
    引くに引けないので誰かストップをかけてくれるのを待っている
    というような噂話もありますし、なかなか大変ですね。

  • 中小規模ではすでにCPUを気にしていない (スコア:3, 興味深い)

    by fukapon (4131) on 2008年09月29日 22時24分 (#1428549)
    一番安いXeonでも概ね問題ないから。普通のPCと同じく、CPUがどうのって話にはまずなりません。
    適当なラックマウントサーバを選び、メモリは2GBのままか（だいたいこれが標準提案構成）、4GBにでもして終了です。

    ちなみに、x64として使うことは未だに稀ですね。これも「32bitで困ってないから」という理由。

  • 20年前の議論 (スコア:3, 興味深い)

    by skobamoss (27007) on 2008年09月30日 0時27分 (#1428632)
    16bitの80286でも十分に速いし、メモリも足りているし。
    32bitっていっても何ギガもメモリ積めるわけじゃないし、スピードも80286と変わらないし80386って何なの？っていってたの思い出しました。あの時も80286が80386が必要な領域を侵しているから性能を上げないようにしているだのなんだのと。
    たぶん、そのうちItaniumの後継の後継あたりが主流になるのかも。
    • >16bitの80286でも十分に速いし、メモリも足りているし。
      >32bitっていっても何ギガもメモリ積めるわけじゃないし、スピードも80286と変わらないし80386って何なの？っていってたの思い出しました。

      真面目に話すと、i8086～i80286のアーキテクチャというのは、以下のような問題を抱えていました。

      ・プログラムから扱えるアドレス空間がMAX16MBだった
      ・セグメントとアドレッシングの制約で64KB(だったかな？)以上の大きさの空間を使おうとするとセグメントいじらなきゃいけなかった

      で、i80386以降の、今のia32アーキテクチャでは、この二つがこうなりました。

      ・アドレス空間がMAX4GBだった（あくまでも論理アドレス、アドレス線が全て出てる訳じゃない）
      ・セグメントとアドレッシングも4GBまで連続した空間を取れるようになったので、一回仮想記憶登録すればセグメントいじる必要がない

      皮肉な言い方をすれば、ソフトを書くときの制約の少なさの面で、i80386になってやっと（16bitである)MC68000系MPUと肩を並べられた。とも言える訳ですが…

      とにもかくにも、あの時のi80386論争というのは、i80386を、MS-DOSアプリで主流だったi80286互換モードで使っていたらパフォーマンスが悪いから32bitにする意味がないんじゃないかと言うお話で、それはDOS-EXTENDERの普及やLinuxの登場で決着が付いたと記憶していますが…

      ### ここから自分語り ###
      私自身はFM-Townsが初めてのDOSマシンで、れいのTOWNS-OSと言うのは、結局はDOSにPhar-Lap社のDOS-Extender(社名記憶いい加減)乗っけてアプリから全ての物理アドレスを触れるようにした代物で、結局はMS-DOS自体の制約である「640KBの壁」が付きまとっていたり、開発環境がCまで含めると十万近かったりしたので、遊べなかった。
      当時の安価なDOSの開発環境と言うとLSI-C試食版で、その内にgccをTowns-OSに移植し始める人たちが現れて、LinusがLinuxをMINIXの人と口喧嘩した勢いでPC/AT用に出したあたりでgccを使ってGNU TOOLSなどを32bit移植してた人たちの一部がLinuxをTownに移植しよう！ってぶち上げて、本当にできた。と言うのでNIFTYのダウンロードコーナー見たら10MB位は落とさないとだめじゃん…課金が何万かかるんだorz
      と言う人が続出して、結局は希望者を募って、南と北に「フロッピー回覧」なる物を行いました…最初のは確か20枚くらい。
      で、確か0.99.7あたりだったかをインストールしました。まともなインストーラなんかなくって、最低限のフロッピーをブートしてからFDDに入ったイメージをHDDにコピってtarballをHDDに展開していくという世界…
      で、立ち上げるとviもEmacsもXもちょっとConfigファイルいじれば、スワップしながらあれやこれやのソフトウェアが並行して動くという状況（確か6MBしか積めなかった)…特に仮想コンソールとXには感動した。と言うか、80年代半ばにカジュアルコピーで貰ったOS-9/6809でできてMS-DOSで出来なかったことが全て出来る上に沢山のプロセスを走らせてもストレスかからない…32bit＋マルチタスクであることの本当の意味を思い知らされました…で、今にいたる。
      ### 自分語りおしまい ###
      シェア
      親コメント

    • Re:20年前の議論 (スコア:2, 参考になる)

      by tomone (15592) on 2008年09月30日 0時50分 (#1428644) ホームページ
      いや、プログラム組む立場からすると int 32bit と int 16bit って全く違うよ。
      流石に 64bit は DB やビデオ編集くらいしか使い道思いつかないけど、
      6.5万や3.2万毎に桁上がり処理、64KB毎のデータ分割処理なんて想像したくもない。
      --
      TomOne
      シェア
      親コメント

      • Re:20年前の議論 (スコア:1)

        by cork (23590) on 2008年10月01日 0時08分 (#1429254)
        16bitOSのintで桁数が足りないならlongを使えばOK。
        それより問題は64KB境界の方ですね。nearとfarを使い分ける環境になんかもう戻りたくないです。

        ところで、64bitだと大容量ファイルをメモリにマップできるだけのアドレス空間があるのでちまちまとfread64やfseek64で読み出す必要がなくなって便利だな、とか思うわけですが（まさか16EBを超えることは…）
        64bitプログラミングに慣れた頃、32bitの不便さに気づくのではないかと思います。
        --
        愚かさによって説明できるものを悪意のせいにしてはならない
        シェア
        親コメント

    • Re:20年前の議論 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年09月30日 0時40分 (#1428638)
      x86の命令セットの持つデコードの負荷が性能向上の足かせになってしまった場合、
      案外ItaniumがServer系では主流になるかもね。いつ頃になるのか分かりませんが。
      あるいはその頃にはx86自体が、x86の命令セットを緩やかに捨て去っているのかも。
      シェア
      親コメント

  • 市場が違う (スコア:2, 参考になる)

    by Anonymous Coward on 2008年09月29日 22時40分 (#1428562)
    Itaniumはハイエンドサーバ市場を通り越して、エンタープライズサーバー市場を狙う方向性に変わったんだよ。
    銀行等の奥に未だ鎮座する汎用機の代替を目指しているのだから、XEONと比べる方が間違っている。

    • Re:市場が違う (スコア:4, 興味深い)

      by Pravda (33859) on 2008年09月29日 23時04分 (#1428575) 日記

      Itaniumはハイエンドサーバ市場を通り越して、エンタープライズサーバー市場を狙う方向性に変わったんだよ。
      同意です。Ando's Processor Information Pageの2008年9月20日分に、HotChipsでのTukwilaの発表 [geocities.jp] という解説記事があり、次世代Itaniumの“Tukwila”は、耐故障性の方向に確実に向かっているようですね。

      もっとも、「耐故障性」はOS、ミドルウェア、アプリを含めたシステムトータルな話ですので、それらがどうしようもないと、いくらIntelが頑張っても駄目なワケですけれど。

      ＃ 聞いた話では、金融関係以外にもラスベガスのカジノなどは、ものすごくIT化が進んでいるそうです。そういう所のシステムが突然落ちると困りますよね。たちまち暴動、つーか。

      シェア
      親コメント

  • 祇園精舎の鐘の声〜 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2008年09月29日 22時25分 (#1428550)
    「将来は風前の灯火か？」って不毛なタイトルだな…
    なんだって当てはまっちゃうじゃないか。
  • Itanium は2コア64ソケとかあるわけですし。
    Xeon だと6コア4ソケがMAXぐらいですしね。

  • だって遅いし (スコア:1, 興味深い)

    by Anonymous Coward on 2008年09月29日 22時50分 (#1428570)
    数値計算でもItanium2遅いし。
    モンテカルロ法みたいなひたすらCPUぶん回す計算は
    XeonやOpteronに遠く及ばないからねえ。
    メモリもx86-64で4GB以上積めればIA64要らん。

    メリットはソケット数多いくらいか？
    まあHPC市場からは退場なんじゃないかなあ。

    #流体なんかではIA64速いの…かも。

    • Re:だって遅いし (スコア:1, 興味深い)

      by Anonymous Coward on 2008年09月30日 1時51分 (#1428669)
      流体でも状況は同じです。
      わざわざIA64機にソース持っていってコンパイルしなおして計算するよりも
      手元のPCでそのまま計算したほうがよっぽど速いという不思議な状況になっています。
      シェア
      親コメント
    • 数値計算の種類にもよると思いますが、新しめのia64と新しめのicc/ifortと
      の組み合わせは、新しめのx86_64にくらべて、速いという印象を持っています。
      ただし、新しめのia64と新しめのifortとが高価なのと、ライセンスの管理が
      面倒くさいので、コストパフォーマンスが悪いです。

      ia64では１つのOSで数十（すでに数百も可能？）のcoreを管理できるのは
      とても楽なのですが。

      ぼくはgcc/gfortranとx86_64との組み合わせで十分幸せになれるみたいです。
      --
      love && peace && free_software
      t-nissie
      シェア
      親コメント

  • ライターからして釣り記事だと (スコア:1, 興味深い)

    by Anonymous Coward on 2008年09月30日 14時45分 (#1428919)
    これ書いてる伴 大作ってトンデモ記事書く人だと記憶しているので、この記事の信頼性などそもそもないのだと思うけど。
    めっきり干されたと思っていたらこんなところで書いていたんですね・・・
typodupeerror

最初のバージョンは常に打ち捨てられる。