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

Windows XP Professional x64 Edition Customer Preview Program 140

ストーリー by Oliver
Linuxだともうお手軽に現実 部門より

llm 曰く、 "64bitコンピューティングの世界の最新ニュースで、マイクロソフトがWindows XP Professional x64 Edition Customer Preview Programをはじめましたと言う記事がありました。 英語版(ページも全て英語)ですが、CDの郵送かisoイメージのダウンロードが選択できます。早速490メガバイトあるisoイメージをダウンロードしました。 先日Windows XP SP2 の開発が終わり、リリースが発表されたことでいよいよ AMD64/EM-64T対応のWindowsXP Professionalの開発に鞭が入るのではと期待されます。とりあえず早くAthlon64の真の実力が知りたいのですけど・・・。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2004年08月20日 11時31分 (#607923)
     その昔、386のころ。15年くらい前か。98シリーズをはじめとする殆どの386搭載機は16bitのDOSだった。要するに速い8086としてしか使用してなかったんだな。16bitは一般的な使用法、例えば一太郎なんかでも限界がきていて、メモリ面ではEMSだとかのアクロバティックで様々な意味でコストのかかるアドホックが存在した。そこまでしたところで、処理速度はとうてい32bitには及ばなかった。
     漏れはそれがイヤで、FM-TOWNSという迷機を買って、High-Cという迷コンパイラで32bit環境を楽しんでいた(メモリモデルがないとかfarの出番がほとんどないとか)。

     翻って、現在。多くの64bitプロセッサは32bitのOSで動いているわけで、これは15年前の状況と同じだな。けれど、あのころのように、どうしても64bitにしたい!という気分になれないのは、我々は
    まだ32bitを使いきってないからなんだろうな。多くのユーザにとって、32bitの限界はまだ見えていない。
    • メモリ空間が広がるのは、すごく助かるんですが、こういうユーザってあまりいないのでしょうか。
      すぐに限界を見せてくれるアプリケーションが登場して、移行を促すようになると思います。
      親コメント
      • 私もメモリ空間が広がると嬉しい人ですが、仮想メモリのページサイズが気になっています。

        Platform SDK の ドキュメント [microsoft.com] を読むと、x64/Windows は互換性を重視して仮想メモリのページサイズは 4KB / page で行くようです。 広いメモリ空間をじゃかじゃか使うプログラムを書くと TLB ミスが足を引っ張って性能の出し切るのが難しそうですね。
        # 4KB/page は細かすぎるよ。

        IA-64 の Windows 2003 はデフォルトが 8KB/page で、Advanced Server (AS) 以上では 16MB/page への変更が可能でした。おそらく x64 でもページサイズの変更が可能になるのは、2003 AS 以上になるのではないでしょうか?
        --
        コンタミは発見の母
        親コメント
        • Mac は以前から、仮想メモリ off 運用とかもありましたし
          HPC でもスワップしないようにとか。
          ギガのメモリモジュールでいっぱいに。
          親コメント
          • すでにお調べかもしれませんが、仮想メモリのページサイズはスワップとあまり関係がないです。そして「ギガのメモリモジュールでいっぱいに」なった時にこそページサイズが問題になってきます。

            触りだけを簡単に言うと、
            仮想メモリのページサイズは論理アドレス空間に物理メモリを何バイトづつ割り当てるかという単位です。ページサイズが小さくなると同じサイズのメモリも細かく分割することになり、ページ数が増えます。
            ページ数が増えると論理アドレスから物理アドレスへの変換表が大きくなります。アドレス変換表はメインメモリ上に構成されるのですが、CPU は TLB と呼ばれる機構に変換表の一部をキャッシュします。IA-32 系の CPU だと TLB は 64 ~ 512 エントリぐらいです (1エントリが1ページ分の変換ルールを記憶できる)。ページサイズが小さいと扱うページ数が増え、TLB ミスが増大します。そして、TLB のミスヒットは、メモリキャッシュのミスヒットよりもペナルティが大きいです。

            広大な実メモリを積んだシステム、たとえば 64GB のメモリがある場合、ページサイズが 4KB/page なら 16,777,216 ページあります(しかもプロセス毎に変換表はある)。TLB はミスしまくりは必至です。これが仮想メモリのページサイズが 16MB/page ぐらいになると、ページ数は 4,096 ページと減り、TLB もヒットしやすくなります。

            無論、仮想メモリを使わなければこのオーバーヘッドは解決すると思いますが、HPC 分野でも仮想メモリを使わないというのは難しいのではないでしょうか?
            # 通信ライブラリの内部とか例外チェックの効率化とかで仮想メモリの仕組みを使っているかもしれない。

            <おふとぴ>MacOS 9 の仮想メモリは 論理アドレス空間がシステムに 1 つしかなく、プロセス(インスタンス?)単位のメモリ保護がない機構だったはず。</おふとぴ>
            --
            コンタミは発見の母
            親コメント
      • メモリ空間が広がるのは、すごく助かるんですが、こういうユーザってあまりいないのでしょうか。
        いないでしょうねぇ。今のところ1プロセス2GB以上のメモリを必要とするのはRDBMSぐらいです。

        逆に言うと、そういう大型アプリケーションがPCの世界に降りてきたがために、一般ユーザーがまだ32bitに不足を感じないうちから64bitを用意しなければならないようになったということでしょう。それだけx86は多くの分野に浸透したというわけですね。

        親コメント
        • いないでしょうねぇ。今のところ1プロセス2GB以上のメモリを必要とするのはRDBMSぐらいです。

          必要なのは、物理メモリの容量じゃなくて仮想メモリ空間ですよ。

          今時、2GBを超える容量のファイルなんて、マルチメディア系データでは普通にあるので、これをメモリ空間にマップできるだけで、コーディングがどれだけ楽になって、性能が上がることか。

          32bitまでの世界では、ファイルサイズに比べて仮想メモリ空間が狭い。OSにどうしてファイルI/OのためのAPIがあるかというと、この狭い仮想空間に、巨大なファイルの一部だけを読み込む必要があるからです。仮想メモリ空間が64bitになると、ファイルをそのまま仮想メモリにマップできますので、ファイルI/OのAPIが不要になります。その結果、ファイルI/Oは全て配列へのアクセスとしてコーディングできるようになります。ファイルI/OのAPIの処理より、仮想メモリの処理の方が圧倒的に軽い処理なので、ファイルI/Oの性能が劇的に改善されます。

          親コメント
          • > 必要なのは、物理メモリの容量じゃなくて仮想メモリ空間ですよ。

            どっちもあったほうがいいと思うけど。
            親コメント
        • >RDBMSぐらいです

          Gaussianとか.
          これだけのためにG5を買う人がいるとか.
          親コメント
        • > 今のところ1プロセス2GB以上のメモリを必要とするのはRDBMSぐらいです。

          一般的にはそうでしょうね。
          別の例を挙げるとすれば、RDB派生でないOLAPとかデータマイニングとかのシステムなど。全文検索エンジンのインデックスファイルをメモリ上に展開、とかね。ま、世に富豪的プログラミング [pitecan.com]のタネは尽きまじ、ってとこですよ。
          親コメント
      • 欲しい64bitアプリ

            - シートの大きさ(特に行数)制限がないExcel
            - 10進16桁整数を入力しても桁落ちしないExcel

        ふだんExcelばかりなので,Excelした思いつかん.
        親コメント
    • FM-TOWNS は迷機じゃないもん名機だもんっ…と信じてる…いや、「信じていたい」者です。(^^;

      それはともかく。
      限界が遠いように見えるうちから切り替えるというのも、またよいではないかと思います。
      誰の目にも明らかに状況が苦しくなったというのに面倒がってグズグズして、
      ようやく重い腰を上げたら今度はもう慌てて切り替えなくちゃいけない、なんてよりは、ね。

      # 先見の明と言ってもタイミングが難しい。
      # 早すぎても遅すぎても失敗する。
      親コメント
    • つい最近まで、Windows用のシステムで
      通信ログのようなものをファイルに保存して、
      その内容を画面上で表示・検索するプログラムを
      改造したことがあります。

      で、クセ物だったのがそのファイル。

      ・ファイルは単なるバイナリ形式
      ・サイズの限界は規定していない。
          (どのくらいのデータ量になるか見積もれない)
      ・リストボックスを使用して、
          全データの一括表示・一括検索を可能とする。
          (ついでに範囲選択でコピー・ペーストもしたい)
       
      予算の都合上、新規に作り変えることが出来ず、
      保守作業での修正を繰り返してきたなれの果てです。
      作業そのものにあまり手間(工数)をかけられませんし、
      ましてやデータベース導入などという
      究極の切り札など、夢のまた夢。

      どうしても64ビットにしたい!
      という気分になりました。

      # 今思えば、
      # 「いずれ64ビットWindowsが出てくるので
      # それまでじっと耐えて待つこと」を選んだ
      # 先見の明があった・・・
      # と言いたいやら、言いたくないやら。
      親コメント
    • by Anonymous Coward on 2004年08月20日 13時54分 (#608022)
      そうだそうだ
      88SRなんて何度「限界を超えた」ことか
      親コメント
    • 論理レジスタ32本にしてくれたら32bitでもいいです。
      親コメント
  • 64bit級OS (スコア:2, おもしろおかしい)

    by Inetpub (20077) on 2004年08月20日 11時56分 (#607939)
    内部でWindowsXPが2つ動いているだけだったりして。
  • 早速cdimage落としてみました。
    w2k3sp1_????_usa_x64fre_pro.iso
    あれれ?Windows 2003 SP1ベースですか?
    そりゃまたしかに2003 SP1ってXP SP2と同じ物を含むはずですが…(^^;;)
    --
    # rm -rf ./.
  • オフトピですが、ちょうどAthlon64マシンを組もうか(or買おうか)
    考えているところなので、有識者にコメントいただければ...

    Athlon64プラットホームでは、メモリがSocket754のシングルチャネルと、
    Scoket939/940のデュアルチャネルがありますけど、メモリアクセス以外で
    そんなに有為な差があるようなベンチマーク結果が見当たらないみたいです。
    で、OSやアプリケーションを64bit版にすると、メモリの帯域差は
    より見えてくるものなのでしょうか?
    それとも、変わらない?

    そりゃ少なくともデュアル買っとけば間違いないと思いますけど、現状では高すぎですし...
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...