Steamをインストール
ログイン
|
言語
简体中文(簡体字中国語)
繁體中文(繁体字中国語)
한국어 (韓国語)
ไทย (タイ語)
български (ブルガリア語)
Čeština(チェコ語)
Dansk (デンマーク語)
Deutsch (ドイツ語)
English (英語)
Español - España (スペイン語 - スペイン)
Español - Latinoamérica (スペイン語 - ラテンアメリカ)
Ελληνικά (ギリシャ語)
Français (フランス語)
Italiano (イタリア語)
Bahasa Indonesia(インドネシア語)
Magyar(ハンガリー語)
Nederlands (オランダ語)
Norsk (ノルウェー語)
Polski (ポーランド語)
Português(ポルトガル語-ポルトガル)
Português - Brasil (ポルトガル語 - ブラジル)
Română(ルーマニア語)
Русский (ロシア語)
Suomi (フィンランド語)
Svenska (スウェーデン語)
Türkçe (トルコ語)
Tiếng Việt (ベトナム語)
Українська (ウクライナ語)
翻訳の問題を報告
With a 32-bit version of (most recent) Microsoft Windows (XP, Vista, 7, I don't know about 8) operating system, an application is limited to using only 2GiB of virtual address space because the virtual memory address space is split to 2GiB for the application and 2GiB for the OS. With the switch enable you can access at least 3GiB of memory (assuming you have that much RAM, otherwise it is not recommended) for a single application.
For the most benefit, the 32-bit application needs to be Large Address Aware (LAA) which is simply a Win32 PE flag that needs to be enabled, to take advantage of this. In fact in older editions of The Elder Scrolls series (i.e. Morrowind and Oblivion[oblivion.nexusmods.com] perhaps) there are generic 3rd-party tools[www.ntcore.com] to enable LAA on the game's executable.
Your CPU needs to support PAE (Physical Address Extension) I believe for the above technique to work. Not all CPUs that are capable of running Windows 7 (or XP, Vista, etc.) will have this feature. You can use a free 3rd-party utility like CPU-Z[www.cpuid.com] to check to see if your CPU supports it.
So more details are available from Large Address Aware @ ACMer[www.zhihua-lai.com] and 4-Gigabyte Tuning[msdn.microsoft.com] (from Microsoft, but Windows Server oriented).
Users of 64-bit versions of MS Windows (Vista, 7) automatically have the larger virtual memory address space per process available, and so any LAA flagged 32-bit applications can be practically up to 4-GiB of RAM per process. In the case of 64-bit native applications on a 64-bit OS, there is no need for the LAA flag.
tl;dr: Most gamers will want to select a 64-bit OS version for their present or next PC system with lots of RAM, since its cheap (now).
NB: I do use the Mebibyte[en.wikipedia.org] abbreviation to clarify the power-of-twos relationship, as memory and storage are sometime quoted in decimal (power of ten) based for metric / SI Megabytes (one million == 10^6 bytes versus 1048576 bytes == 2^10) for advertising purposes to "inflate" the advertised values.
As a test I saved a game when SPM showed I had at least 2.5GB allocated. When I reloaded the save, SPM reported that Skyrim had only allocated some 600MB. The diference must have been deallocated memory that had not been released by the garbage collector. This would seem to be an oversight by Bethesda as .NET provides the ability to dispose of resources under program control rather than wait for the garbage collector.
From vague memory I believe many 32-bit systems end up only being theoretically able to utilize a maximum of 3.25 GiB per process as a limit due to BIOS and OS / driver overhead. So a 3.1 GiB in a real application limit is hardly worth being disappointed by. It is simply a limit to the PAE, which is in essence a hack.
AFAIK the Gamebryo engine and the scripting environment both are evolved from the versions Bethesda has used in earlier Elder Scroll titles (and I think Fallout 3 & New Vegas) from well before the creation of .NET. I believe you have the .NET GC confused with general application oriented (as opposed to OS-level MM) memory management.
Exactly as one would expect. And as soon as your character does something (i.e. move into another cell) those additional cells would need to be loaded and rendered as there is nothing other than the minimum required cached ("paged"). The trade-off is that Skyrim should not be too aggressive de-allocating memory, otherwise turning around or taking a step backwards could cause a large number of page faults, slowing down the game by suddenly needing to re-load / re-calculate everything it just discarded.
Think of it as loading a saved graphic image file in a paint program. You don't get the undo-redo buffer memory of the last session included when you reload the image when you restart the paint program. The idea of decreased file size and memory usage is similar.