Installa Steam
Accedi
|
Lingua
简体中文 (cinese semplificato)
繁體中文 (cinese tradizionale)
日本語 (giapponese)
한국어 (coreano)
ไทย (tailandese)
Български (bulgaro)
Čeština (ceco)
Dansk (danese)
Deutsch (tedesco)
English (inglese)
Español - España (spagnolo - Spagna)
Español - Latinoamérica (spagnolo dell'America Latina)
Ελληνικά (greco)
Français (francese)
Indonesiano
Magyar (ungherese)
Nederlands (olandese)
Norsk (norvegese)
Polski (polacco)
Português (portoghese - Portogallo)
Português - Brasil (portoghese brasiliano)
Română (rumeno)
Русский (russo)
Suomi (finlandese)
Svenska (svedese)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraino)
Segnala un problema nella traduzione
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.