自分がよく分からなかったので、分かりやすい訳になりませんでした。すみませんね。
でも遵ﾜpan醇Tl弟?さん的にはなんか重要なことを成し遂げたらしいですよ。
===========================
Breaking the 32 bit Barrier(32bitの壁を破ってます)
Written by Ond醇yej 遵ﾜpan醇Tl
Tuesday, 11 March 2008
原文: http://www.bistudio.com/developers-blog/breaking-the-32-bit-barrier_en.html
　
　メモリの最適なハンドリングを探す旅は、結末を迎えられそうか?
　
仮想アドレス空間の問題
　ArmA が発売されてからの最大の問題のひとつは、仮想アドレス空間が引き起こす安定性と互換性に関する問題でした。これは注目に値する多くがグラフィックボードのドライバが同時にシステムの他の部分が広大な仮想アドレス空間を同時に使用しながら、多数の仮想アドレスを使ってたくさんのデータを格納するゲームならではの問題です。この問題はArmAを発売する前から始まっていました。OFPの時を振り返ると、最初のグラフィックカードが256MBのRAMあるいはそれ以上を使用していました。同じシステムの上で稼動させた場合、OFPはArmAより安定性に優れているとは言えませんでした。これはメモリマッピングで使用されるファイルアクセスにその理由があります。素早く、手軽に使っている間は、メモリマッピングはたくさんの仮想領域を使用します。暫定回避策として、私達はこれらをマッピングすること無しにファイルにアクセスする手段を提供しました(-nomapとしてよく知られるあのコマンドラインのことです)。ArmAのために、私達はファイルへのアクセス方法を完全に設計しなおして、ファイルが全てに対してマッピングしない作りにしましたが、通常のファイルはAPIを実際には使用します。同時に私達は、私達がバックグラウンドでテクスチャとその他のリソースをロードできるようにするため、オーバーラップ I/Oに切り替えました。私達も、そしてみなさんも、これだけでは十分ではなかったと理解したと思います。　

　
空の限界?
　現在起きていることは、OSが各アプリケーションに対して割り当てるアドレス空間が2GBまでであることです。2GBと聞くと、その制限がどうしたのと思うかもしれませんが、実はあまりいいことではありません。何らかの方法でコンピューターはもっと多くのRAMを積んでいます。今、最も御知らせしたい重要なことは、メモリの物理サイズのことではなく、私達が言いたいのはアドレス空間のことです。アプリケーションは、2GBまでのアドレス空間の制限があり、たとえみなさんのPCが、物理メモリサイズとして512MBであれ4GB以上積んでいたとしても、それはここでは全く関係ないのです。
　
　2GB は、全てのアプリケーションが必要とするので、これらに使用されます。そして最近のグラフィックカードは、数百MB単位で食いつぶします。悪くならないように、大きなパーツを消費しないようにするシステムコンポーネントがありますが、しかしあちらこちらで消費してしまうと、小さな単位の複雑なフラグメントされた空間が発生します。私の経験では、システムが極端に不安定にならないようにするために、ゲームコードが割り当てる仮想空間は約700～900MB以上がないとほとんど不可能だと思っています、また隣接する大きな単位で割り当てなくてはならないというわけではなく、むしろ10～100MBサイズのチャンク(塊り)であれば良いと思っています。悪夢としないよう、ドライバーのプログラマーはリソースの中のアドレス空間の制限の事実を知らせようとはしないように見受けられます。そしてドライバーは、仮想割当の失敗をハンドリングしてくれるわけではありません。ゲームといものは、一旦、大き過ぎる仮想空間を割り当ててしまうと、画面上に三角形のゴミが散乱したり、時にはシステムがリブートを始めたりと、とても奇妙なことが起こり始めるのです。
　
将来、64ビットへ
　長い間、64ビットOSへの移行と64ビットアプリケーションとしてゲームをコンパイルがこの問題を解決すると考えられていました。このような問題解決は、 ArmAでは現実なものとして実現にはなりませんでした。なぜならばまだ多くの人に64ビットOSが普及していないこと、一方でこの変化にはリソースと時間が掛かり過ぎるからです。
私達は、いくつかのパッチ（このフォーラムトピックを見ても）を組み合わせた結果、様々な経験と最適化を遂行しています。しかし完全に動いているわけではなく、各ソリューションの性能や安定性はいくつかのシステムの上に被ってしまいました。ArmA2の開発を続けている間、私達はもっと多くのテクスチャとメモリを割り当ててやる必要が出てきました。そしてもっと強くこれらの制限を強く受けるようになり、ゲームはたくさんの異なる全てのシステム環境の上で安定して動作させることが出来ない時代に来てしまいました。
　
アドレスのないメモリ
　そしてある日、あるアイデアが、いつもと同じようにどこからともなくこんなアイデアが浮かびました。このようなアイデアが普段からも、実装されたあるシステムが、それはとても明確に見えましたし、しかし以前によく使ったものとして一度も聞いたことがない、付け加えるとそれは私が持ち合わせてことを誇りに思ったことがないものでした。私はこの技術を「ノン・アドレッサーブル・メモリ・ストア(アドレスのないメモリへの格納)」と名づけることにしました。
　
　この技術は、ファイルAPIマッピングの使い方を基礎としています。はい、みなさんも聞いたことがあるかもしれません。OFPでトラブルを引き起こしたのと同じAPIのことです。ですが、これはあの時とは異なる方法で使います。ファイルを読まないように使用しますが、メモリは割り当てるという使い方です:
　
　* ゲームを初期化する際、十分なメモリをファイルマッピングを作成するAPIに予約、占有することにします。物理メモリを消費しますが、アドレスは仮想のものです。

　* ページデータを格納または参照する際に、一度アクセスが完了したものが再び破壊されたMapViewOfFileを使用して、一時的なビューが作成されます。これは64KBというとても小さな仮想空間を使用します。形式的に、いくつかのページのみがメモリにマッピングされ、これを同時に使用します。
　
　Windows は、このパターンのハンドリングに適していて、空間がページファイルをバックアップしている間に、ページファイルの書き換え量が0になって、全ての情報が物理メモリの中だけでハンドリングされたことにより、使用可能な物理メモリが十分にありさえすれば、実際にそのような方法で動作します。この格納タイプにおける確保されたメモリは、仮想アドレス全てに対してマッピングされることなはく、実際のマッピングされたファイルのオフセットによって識別されるのです。各アドレスは、キャッシュの中身を詠みに行く時だけ、一時的に割り当てられます。これは独立した位置(何らポイント情報は何ら含もうとしない)にあるファイルキャッシュの中にデータが格納されていた事実が可能にしたことに感謝をしています。
　
バリアは破られた

　テクノロジーの常識では、32bitアプリケーションが使用するメモリは32bitのアドレス空間に限定するのが普通です。このサイズは、フリーなRAMとファイルをマッピングするサイズの限界によってのみ制限されます、よって32bitOSでは管理可能なデータは約3GBまでで、64bitOSの場合はそれ以上ということになります。これは私達がやっているArmAでのことではありませんが、とても小さな改良をすることで512mb以上のキャッシュファイルを持ったのをみた体験があります。ですが、私達がやみくみにさくさんのデータを読みこんだりしないように、他のアプリケーションのためのオプション機能を付けるかもしれません。ファイルのキャッシングに制限はありませんが、格納すべきコンテンツには限界があります。もうひとつ重要な限界があって－ポインターは一度アンマップされたメモリは無効になるのと同じように、通常は永続的なポインターとしての使い方で、アプリケーションというものは決してポイントの中にメモリを割り当てることはしません。
　
　ArmAに持ってきたのは、あなたの所有するPCの搭載RAMに依存した100から 500MBのサイズの内部ファイルキャッシュであり（-maxmemコマンドで指定する量も設定できます）、これはほとんど仮想的な空間を使いません。数百MBをシステム用に残すようにしとけば、だいたい十分であると言えます。既に修正されたものとして有名な「Cannot allocate system memory surface(システムメモリを割り当てることが出来ません)」のように、ほとんどすべてのシステムにおいてゲームによって使用されるメモリに制限がないことを確かめるテストを行いました。
　
近日のパッチで使用可能になります
　そして、このメモリのハンドリング方法は、1.11のパッチでリリースされるでしょう。みなさんも気に入ってもらえればなと思ってます。