test content
Logo
What is the Arc Client?
Install Arc
STO only uses 2GB of memory on 64bit windows, linker issue
ucalegon
Member Posts: 0 Arc User
I'm unsure how to reach a STO developer or someone in charge of its build chain, so I'll just post this here and hope someone at PW/Cryptic finds it.
I'm using a 64-bit edition of Windows, and I have 4GB of ram. STO is never claiming more than 2GB of memory even though there is nearly one free gigabyte of it. Given the load delays I guess the game could use the free gigabyte to keep more stuff in memory, and avoid having to reload stuff from disk all the time.
Having had the same type of issue on other 32-bit memory hungry games, I looked if the game was linked with the proper option (ie: the one which sets the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on the executable image).
It's not there, so either PW/Cryptic isn't aware the option exists, or the STO code can't handle signed pointers properly. If the latter is false, as it is with most recent programs, enabling that option on the linker would safely allow people running 64-bit windows to give STO at most 4GB of application address space, which is twice what it currently can use on such systems, assuming there is enough free memory available.
To see if the option is active you need a tool which can inspect the linker flags of an executable. I use DUMPBIN which is included with Microsoft's Visual Studio Express. Example on a program which was linked with the proper option (Civilization V):
For STO the line "Application can handle large (>2GB) addresses" doesn't show up, so the flag hasn't been set.
To change this you can either set an option on your linker, or use another tool from VSE after the program is completely built:
This won't work from my end since the game auto-patcher restores the executable to it's previous 2GB-limited self before starting the game. I've of course only tried it on the testing shard (Tribble) in case anything happened.
That technique works nicely for many games, so I hope you'll be able to add the flag either to your linker, or add that tool somewhere in your build chain to release executables which can take advantage of more of the memory we have installed.
I don't know what brand of compiler/linker you use, but since this is only a flag in the PE header any linker should support it.
References:
MSDN, PE Header spec: http://msdn.microsoft.com/library/windows/hardware/gg463125
MSDN, /LARGEADDRESSAWARE linker option: http://msdn.microsoft.com/en-us/library/wz223b1z%28v=vs.100%29.aspx
The old new thing: http://blogs.msdn.com/b/oldnewthing/archive/2005/06/01/423817.aspx
Some other game describing the same tip: http://www.gidhome.com/gid3gb/index.html
I'm using a 64-bit edition of Windows, and I have 4GB of ram. STO is never claiming more than 2GB of memory even though there is nearly one free gigabyte of it. Given the load delays I guess the game could use the free gigabyte to keep more stuff in memory, and avoid having to reload stuff from disk all the time.
Having had the same type of issue on other 32-bit memory hungry games, I looked if the game was linked with the proper option (ie: the one which sets the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on the executable image).
It's not there, so either PW/Cryptic isn't aware the option exists, or the STO code can't handle signed pointers properly. If the latter is false, as it is with most recent programs, enabling that option on the linker would safely allow people running 64-bit windows to give STO at most 4GB of application address space, which is twice what it currently can use on such systems, assuming there is enough free memory available.
To see if the option is active you need a tool which can inspect the linker flags of an executable. I use DUMPBIN which is included with Microsoft's Visual Studio Express. Example on a program which was linked with the proper option (Civilization V):
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>dumpbin /HEADERS "C:\Program Files (x86)\Steam\steamapps\common\sid meier's civilization v\CivilizationV.
exe"
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\Program Files (x86)\Steam\steamapps\common\sid meier's civilization v\CivilizationV.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
8 number of sections
4EE9BEC8 time date stamp Thu Dec 15 10:32:56 2011
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
123 characteristics
Relocations stripped
Executable
Application can handle large (>2GB) addresses
32 bit word machine
For STO the line "Application can handle large (>2GB) addresses" doesn't show up, so the flag hasn't been set.
To change this you can either set an option on your linker, or use another tool from VSE after the program is completely built:
EDITBIN /LARGEADDRESSAWARE "path_to_program"
This won't work from my end since the game auto-patcher restores the executable to it's previous 2GB-limited self before starting the game. I've of course only tried it on the testing shard (Tribble) in case anything happened.
That technique works nicely for many games, so I hope you'll be able to add the flag either to your linker, or add that tool somewhere in your build chain to release executables which can take advantage of more of the memory we have installed.
I don't know what brand of compiler/linker you use, but since this is only a flag in the PE header any linker should support it.
References:
MSDN, PE Header spec: http://msdn.microsoft.com/library/windows/hardware/gg463125
MSDN, /LARGEADDRESSAWARE linker option: http://msdn.microsoft.com/en-us/library/wz223b1z%28v=vs.100%29.aspx
The old new thing: http://blogs.msdn.com/b/oldnewthing/archive/2005/06/01/423817.aspx
Some other game describing the same tip: http://www.gidhome.com/gid3gb/index.html
Post edited by ucalegon on
0
This discussion has been closed.
Comments
Updating the method of linking on an executable can have long-reaching implications on an install base that extends back to that very time. Given the current list of problems they have solving things that have nothing to do with the external environment... I would have to bet that updating the executable environment to the modern paging system is far from a considered feature.
I also have to question the efficiency of a game that pages >2GB of system ram... and assume its making little use of the dedicated graphics memory and processing, and is doing very little caching of rendered textures. While the same argument holds true for a game that is hitting the 2GB peak to begin with... consuming all that memory will only drag down everything around it.
How do they know what to cache in memory? How do they know if you will be visiting (or doing) the same places/things several times in a gaming session?
Another problem is ... even with increased ram caching, first time loading from disk to ram will still be slow.
I suggest buying a solid-state drive. It will speed up all loading times in all games.
I have 4GB ram and a SSD. I prefer that STO not use all my available ram. From my experience playing planetside 2 (a game which easily uses up to 4GB ram), my frame rate starts to decrease after 1-3 hours of gameplay and brief pauses/stutter will happen.
STO runs perfectly smooth for me. no frame rate decrease during long gaming sessions. no stutter. Only serious complaint I have is "server not responding" during loading screens.