パスワードを忘れた? アカウント作成
5471 story

Microsoftがやっとx86-64への対応を発表、Sunは可能性を示唆 54

ストーリー by Oliver
IA-64かx86-64か 部門より

dseg 曰く、 "米Microsoftは9日、WindowsXP/Windows Server 2003 でAMDの64bitプロセッサであるOpteronAthlon 64に対応すると発表した。WindowsXP/Windows Server 2003に64bitサポートを盛り込むという。β版は本年6月頃登場のようだ。また、The Inquirerの記事によると、Opteronに対応した64bitバージョンのMicrosoft SQL Serverの開発も進んでいるという。
Intelに配慮してか、対応の発表こそOpteronの登場直前と遅れたものの、MSは着々と64bit環境への準備を進めているようだ。"

また、同じくdseg 曰く、 "CNET Japanの記事より。SunはAMDの64bitプロセッサであるOpteronについて、「自社の製品への採用はありえる」と述べた。同社の製品にはPentium IIIを採用したサーバ機、LX50があり、この製品の次期モデルへの採用を検討しているようだ。サーバ関連で大きなシェアを持つSunがOpteronに対し興味を示した事の意味は小さくないだろう。こちらは対応する本家のストーリー。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 一番乗りは誰だ (スコア:2, 参考になる)

    by nobuhiro (5244) on 2003年04月10日 15時52分 (#296086) ホームページ
    本家のBSD セクションにはFreeBSD はブートに成功 [slashdot.org]なんてものあって、x86-64 への対応は急速に進んでるみたいですね。

    AMD の狙いは、現状の 32ビットアーキテクチャと連続性を持たせ、しばらくは高性能な x86 として素早く普及を図りつつ、搭載した 64ビットアーキテクチャの性能を引き出すソフトの充実を待つ、と言ったところでしょうから、かなり目論見通り展開しているように見えます。

    %% 早く普及価格帯に降りて来てくれないかなぁ。

    --
    • by zeissmania (3689) on 2003年04月11日 0時02分 (#296378)
      画像処理とか動画処理だと、メモリが4GBでは足りない、というのが切実な問題ですから、その手の方面のソフトが真っ先に充実するんじゃないでしょうか?
      ファイル容量も64bit長で管理するのが既に当たり前ですが、このファイルI/O周りが高速化されるなら、DB関係などには非常に恩恵があるでしょうね。特にOracleみたいにRAW I/O使ってると、検索速度の高速化に効きそう。
      親コメント
    • by chi (11062) on 2003年04月10日 16時08分 (#296096) 日記
      個人的には64ビットという響きを聞くと、わくわくしてしまいますが。実際のパフォーマンスでは、32ビットも64ビットも差がない気がするのですが、どうでしょう。

      64ビット化すると、恩恵の出るアプリは除外してっ事ですけどね。
      親コメント
      • Re:一番乗りは誰だ (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2003年04月10日 16時24分 (#296108)
        >64ビット化すると、恩恵の出るアプリは除外してっ事ですけどね。

        それって除外しすぎて意味の無い比較になってますよ。

        実際のスピードでは軽自動車もフェラーリも差が無い気がするのですが、どうでしょう。
        60km/h以上出せる道は除外してって事ですけどね。

        というようなもんで、差が無いという実感は正しいけど、その条件下で比較する意味は無い。

        親コメント
      • by Y.. (7829) on 2003年04月10日 18時27分 (#296195) 日記
        ん~
        身近なところで文字列のコピーなんかは普通に高速化できそう
        体感できるかどうかは微妙だけど
        恩恵のでないアプリはなさそうですよね
        親コメント
        • by Anonymous Coward
          memcpyは速くなるだろうけど、strcpyは変わらない(orより遅くなる)んじゃないかな?
          もちろんアルゴリズムとかCPU内部でのcharの取り回しのアーキテクチャに拠るだろうし、体感できるほど差は無いだろうけど。
          • by chi (11062) on 2003年04月10日 19時12分 (#296218) 日記
            そうですね。
            memcpyは早くなるな。

            元々言いたかったのは、16ビットから32ビットに以降したときの様な、必然性は感じられないって事。
            でもmemcpyが早くなるなら、やっぱりわくわくするかも。
            親コメント
            • by ed-beta (4425) on 2003年04月10日 19時48分 (#296234)
              SSE2なら128ビット長長整数レジスタが使えます。
              やったことないので分かりませんが、SSEのレジスタを
              ごそっと使ってmemcpyすると結構、速いかもです。
              親コメント
              • by Anonymous Coward
                それと同じことをやって高速化を図っているのがWinXPですね。

                プログラム起動時のメモリクリアに使用中。
            • by babie (6656) on 2003年04月10日 20時05分 (#296245)
              せっかく速くなるんだから
              memcpyからmemmoveに乗り換えましょう:-)
              親コメント
            • by Anonymous Coward
              16→32の時は、プロテクトモードが付いたとか16ビット時代に既にアドレッシング可能なメモリの限界いっぱいまで使っていて、アドレスバス幅も増えたとか、そういう単なるデータバス幅の倍加以外のメリットがありましたからね。

              それと、32bit-intは使うことが多いので1opで実行できる事がメリットとなりましたが、64bit-intってあんまり使う事が無

            • by Anonymous Coward
              メモリの複写・初期化くらい、DMAとかでガーッとやれるアーキテクチャになってくれないのだろうかと思うんだけど、どうなんだろう?
              #CPUの話からは外れるけど
              • by 505 (12538) on 2003年04月11日 16時48分 (#296805)
                上でもかかれてますが、NULL文字を判定してそこまで転送…といったような、転送データの内容によって転送条件があったりすると、一般的なDMA(転送元/転送先/転送ワード数程度の設定しかできない)だと対応できないっすよね。

                ん~ ENDマーク自己認識機能きDMAコントローラか… こんどのシステムボードのFPGAの隙間(^^;)におしこんでテストしてみるかな…(^^;)

                親コメント
              • by 505 (12538) on 2003年04月16日 18時50分 (#299638)
                不勉強でもうしわけありません。
                私がいままで使ったことのあるDMAは、そのような機能をもったものがないので、具体的なメーカー名と型番を教えていただければありがたいです。よろしくお願いいたします。
                親コメント
          • by 505 (12538) on 2003年04月10日 22時02分 (#296307)
            >memcpyは速くなるだろうけど、strcpyは変わらない(orより遅くなる)んじゃないかな?
            実際のライブラリがどのような処理をしているかはわかりませんが…
            ハード的にはただのメモリ間データ転送ですよね?
            であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと…
            で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…
            親コメント
            • by Anonymous Coward

              ハード的にはただのメモリ間データ転送ですよね?
              であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと…
              で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…

              ん? んん?
              何の話? OpteronはメモリコントローラをCPUに内臓してるから、FSBがどうたらとか無関係ではないの

              • すでに現在でも、20万円も出せば64bit CPUを積んだ新品のワークステーションが買えますよ。ご自身で確かめられては?(ニヤリ)

                >んで、ここでの話題は物理的なメモリ速度なんか全然関係無くて、CPU内部での論理的なメモリ操作の話をしているのではないかなと。

                少なくとも普通のプログラム(SSEやVISみたいなSIMD命令群がメインで動かないようなプログラム)では、 64bitアドレス空間で動かしたほうがポインタのサイズが大きくなったり、 ページテーブルのキャッシュミスが増えたりするため、実行速度は遅くなります。

                参考程度ですが、メモリコピーを行うプログラムを同一マシン上で 32/64bitアドレス空間それぞれで動かしたので、 結果を張り付けておきます [srad.jp]。

                親コメント
              • by 505 (12538) on 2003年04月11日 16時54分 (#296809)
                あぁ~そうか、NULL文字とかを判定しながら転送とかしてるから、単なるDMAとはちがいますもんね。
                親コメント
              • by chi (11062) on 2003年04月11日 21時12分 (#296963) 日記
                結果拝見しました。
                最適化を掛けていないので、memcpyとmemmoveの差がでない様な気がするのですが、いかがですか?

                gccで下手に最適化掛けると、確かmemcpyとかはインライン展開されてしまうので、inline抑制有/無で結果出していただけるとありがたいです。

                #お前がやれって?
                #ごもっとも
                親コメント
              • 最適化・inline化を切り替えて やってみましたが [srad.jp]、特に変化なしです。 コード見ても律儀にライブラリを呼び出しているだけで、 inline化するための条件を満たしていないみたいです。

                まあいずれにしろ、inline化したところで変化するのは関数コールのオーバヘッドの分だけのような気がするので、元々のメモリ転送速度の話とは切り放して考える必要があると思います。

                親コメント
              • by chi (11062) on 2003年04月12日 12時56分 (#297314) 日記
                結果拝見しました。
                有意な差は出ていないようですね。

                ありがとうございました。
                親コメント
          • by Anonymous Coward
            え、なんで?
            #本当にわからないのでAC
            • by SteppingWind (2654) on 2003年04月11日 1時36分 (#296436)

              strcpyだと末尾の'\0'を判断して, その先は送り先側にはコピーしないようにするので, 何も工夫していないプログラムでは1バイト毎の転送となってしまい, 8バイト分の幅がある64bitバスの有効性が活かせない. 下手をすると1バイト単位という特殊なアクセスの為, 効率が極端に落ちるのではないか. ということだと思います.

              ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.そのため, ほとんど全ての文字列の長さが8バイト未満というような場合を除き, 効率は上がると考えて良いと思います.

              親コメント
              • by Anonymous Coward

                ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.

                glibcなんかはi586以上はsysdependなコードがありますが、i386は無いので「おばかなインプリメント」がされています。
                Linuxの多くのディストリビューション

              • by Anonymous Coward
                訂正:
                誤:IA64用のコード
                正:x86-64用のコード
        • とりあえず、リソーク空間は広がってMSプログラムの
          リソース不足によるトラブルがなくなる事を期待したい。

          大量のデレクトリとかファイルとかエクスプローラで扱おうとすると
          リソース食って遅くなったり、不安定になったりするからね。
      • なので、64Bit化して搭載メモリ上限を増やしたい事じゃないですか。
        普通の方はメモリの上限が迫ってるって意識されていませんので、遅い64BitCPUより速い32BitCPUを支持し、いつまでたっても64Bit化が進まない今ままでの状況が続くと思います。
        親コメント
        • PC分野では割と無視されてるのですが、Pentium Pro(P6)以降、
          x86の物理メモリアドレスは36ビットです。通常は4GB止まり
          (32ビット)で使われていますがLinuxやWin2K/XPは36ビットアドレス
          に対応済みですね。
          ですので今すぐ限界がくる、という言い方は不正確かと。
          この手法で物理メモリ空間を拡大することも不可能ではないです。
          あまり効率は良くありませんがね。

          元ネタの後藤さんは分かって書いておられるようなので問題ないん
          ですけど。
          親コメント
          • P6以降は36ビット…という話は聞いていますが、具体的にはどのようにメモリマップされているのか、もしよろしければ教えて下さい。

            現状のメインメモリが1Gや2Gバイトまでのマシンの場合、低位アドレス側にはメインメモリがそのまま見えますよね? それを超えると、PCIバス空間(AGPなど含む)にアクセスしに行きますよね?
            例えば4G以上のメモリを積める場合は、PCIメモリ空間はどこにマッピングされるんでしょうか?
            (PCIメモリ空間のアドレッシング能力も、一般的には32ビットですし…)

            親コメント
            • PSE-36とPEA-36という2つの方法が用意されています。
              PSE-36はページサイズを拡張して36ビットアドレスを参照します。
              一方、PAE-36はページディレクトリテーブルを使ってアドレスを
              拡張します。
              リニアアドレスは32ビットのままで、36ビットの物理アドレス空間
              に32ビット仮想アドレス空間がマッピングされているという風にイメー
              ジすればわかりやすいと思います。

              詳しくはインテルが出しているマニュアルを参照してください。
              たしか日本語版もPDFでダウンロードできます。
              親コメント
            • またまたFreeBSD-CURRENTの話になっちゃうのですが, 丁度本家の記事 [slashdot.org]でも4GB越えの実装が行われたことについて取り上げられています.

              まあ4GB越えと言っても単一プロセス内では32bitアドレスのままなので, 科学計算等の用途ではmmap等を使ってアクロバティックなプログラミングをすることにならざるをえないと思いますが.

              親コメント
              • 見ていないうちに流れてしまったトピックスですのでレスしてもアレかも
                しれませんが・・

                >アクロバティックなプログラミングをすることにならざるをえないと思いますが.
                おっしゃる通りです。仮想アドレスは32ビットのままですから。
                なにやらWindows 3.1時代を彷彿とさせますね。
                関連してPCIのアドレス等は物理アドレス的には下位4GBにマップされます。
                これも実は「いつか来た道」で、ISAバスのDMAやISAバスのバスマスタデバイスは
                4GBの下位16MBにしかアクセスできませんでした。
                親コメント
    • by Anonymous Coward
      > x86-64 への対応は急速に進んでるみたいですね。

      すでに x86-64 が NetBSD 1.6 のサポートアーキテクチャの中に
      入ってたりするくらいには急速ですな。

      基本的に IA32 のすなおな拡張なので、新しいことやりたがりの
      INTEL よりは手っ取り早く実用的なのかもしれず。
      巧遅は拙速にしかず。
  • 欲しいモノ (スコア:2, 参考になる)

    by Pooh (4850) on 2003年04月10日 21時19分 (#296282)
    64bitっていって欲しいのは巨大Matrixでしょう。
    MatLab for x86-64とか。

    個人的にはDelphi for x86-64希望。
    でもWindows XPの対応ってどういう内容なんでしょう?

    intel Math Kernel for x86-64なんかは出ないですよねー、、、
    • by 505 (12538) on 2003年04月10日 22時39分 (#296323)
      >64bitっていって欲しいのは巨大Matrixでしょう。
      3次元、4次元の配列なんて使ってて、
       「Z軸の要素もう1個増やしたいんだけど…」
      と増やして一晩走らせても、次の日の朝まだ終わってねぇ~
      …ってこともなく、さくさく作業がすすめられるかな?
      親コメント
  • by SteppingWind (2654) on 2003年04月10日 16時10分 (#296097)

    同じx86-64つながりで, FreeBSD-CURRENTでもbootに成功した [freebsd.org]らしいです.

    やはり最近はメモリの値段も安くなってきましたし, x86-64は2GB超のリニアなアドレスが必要になる数値計算用途でのAlpha代替という形で広がっていくのでしょうかね.

  • by Anonymous Coward on 2003年04月10日 16時15分 (#296102)
    IA32チップを高速化するだけではAMDに対抗するのは難しい? 噂ではIntel版x86-64を開発中と言う。
    「IntelがIA-32の64bit拡張「Yamhill」を開発している理由」 [impress.co.jp]
    • リンク先の記事は初めて見ましたが、x86-64の事を知ってからこっち、やってなきゃウソでしょと思ってました。

      私には、革新より、今の環境がちょっと良くなる方を選ぶ人の方が(Intelの思惑より)多いように思えるのです。

      IBMが、PC/ATからPS/2に移行しようとして、高性能化したAT互換機のせいでPS/2のシェアが伸びなかった故事を思い出しません?(ISAとPCIとMCA、の方が正確かも)。

      とゆーか、まさにAMDのK6シリーズのせいで(他にもSocket7CPUはありましたが)、Socket7がIntelの手を離れて延命された事とかもありますよね。
      あのとき、IntelがMMX-Pentiumの高クロック版を投入していれば、今のAMDはなかったかも。
      親コメント
      • by ed-beta (4425) on 2003年04月10日 18時24分 (#296194)
        >革新より今の環境がちょっと良くなる方

        命令アーキテクチャに関してはItaniumのような目新しさはない
        ですけど、ハードは十分に革新的ですよ。
        ご存じでしょうがメモリコントローラをCPU内部に持ち、
        バスはHyperTransport。
        少なくともPentium4/Xeonなんかよりは目新しいです。
        性能も相当に高く米国では予想を超える反響を呼んでいるとか。
        期待したいですね。
        親コメント
        • HyperTransportと従来のNorthBridgeの統合はひょっとしたら64bit化よりも大きなインパクトが有るかもしれませんね. タイミング的にPCI-ng等のシステムアーキテクチャの大きな変更が重なりそうなので, 個人的にはそのあたりが落ち着くまでは待ちを決め込もうかと考えています.

          親コメント
    •  現状でも、2GB分のメモリが(512MBのDDR-SDRAM×4枚として)2万円台~(実際にはregisteredだともう少し高い)なことを考えると、ハイエンドのPCでは、この記事の予想よりも早く4GB超のメモリが積まれる時代が来そうな気がします。
       特殊な数値計算分野だけでなく、画像処理なども含め、恩恵を受ける人はそれなりにいそうですし。
       まして、Opteron/Athlon64では当たり前のようにできるとなれば。
      親コメント
    • by Anonymous Coward
      この間でたPentium-MはPentium4-MともstrongARMともやり方が異なるので
      ItaniumにIA-32を載せるための部分のテストも兼ねているのではないかと見ていますけど。
  • さて、どうしてもつきもののhotfix(セキュリティか否かを問わず)ですけど、どうするんでしょうね。

    XPだと32bit版(x86)と64bit版(ia64)を分けていたけど、AMDのx86-64はどう表記されるかが既に気になっています。
    amd64、とでもするのかな? それとも機能を活かして32bit版を包含したものにでもしてしまうんだろうか?

    # 窓2000ですが、nec98、なんてものがいまだにメンテされていることに素直に拍手。
    • by Anonymous Coward
      いえいえ、NT 4.0 だってメンテしてますから
  • by Anonymous Coward on 2003年04月10日 17時07分 (#296149)
    googleしても見つかるのはプレスリリースばかり。
    どこでどなたが使っているのでしょうか???

    # iAPX432のように歴史から抹殺されるのか???
    • by 505 (12538) on 2003年04月10日 22時19分 (#296318)
      えぇ、某社の某部署は、IA-64部隊を解散しましたし…
      そりゃそうか、日本でIA-64を“まじめ”にやってる客(会社)って、いくつあるんだよ…
      (“まじめ”ってのは、チップセットを自社開発するとか…)

      某/某じゃぜんぜんわかんないのでID(^^;)

      親コメント
      • > 日本でIA-64を“まじめ”にやってる客(会社)って、いくつあるんだよ…

        日本じゃNECのAsAmAぐらいじゃないでしょうか. あれもHP-UX, Linux, Windows Serverの3種類のOSが動くんで, ローエンド側は鼻から相手にしていないっぽいんですが. まだ予定ですが, こんなシステム [osakafu-u.ac.jp]の導入予定があるみたいです.

        親コメント
      • えーっとさわっていますが…
        いや、早いですよ。ええ。
        ソフトがほとんどないだけで。
        でも価格性能比を考えるとp690とかわらんので以下略。
        #スケーラビリティも入れるとp690だろ…
    • by chiba-f (6867) on 2003年04月11日 13時19分 (#296692)
      ジャンクでItanium 1が秋葉原で売られています。ハード/ソフトの開発に使われていたもの?マザーボード等他は別途手に入れなくてはならないようなので、トータルで安いのか高いのか分かりませぬ。例えば、以下参照:
      秋葉原エレクトリックパーツ [akiele.com]
      親コメント
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...