Arma3 and the /LARGEADDRESSAWARE flag (memory allocation > 2GB)

[fred41 42]

... since this thread is now clearly related to tbbmalloc, an experimental custom memory allocator for arma, i will rewrite this initial post ...

(please notice, the /LARGEADDRESSAWARE flag is set correctly for all current arma editions, this old topic just can't be edited now)

The current version of 'tbbmalloc for arma', including a short description, can be found here:

https://github.com/fred41/tbbmalloc_arma

(Note: to get a file from github, you can ether: download the full repository (Download ZIP) and extract the needed files locally OR download one specific file by selecting the file and click RAW button)

The following improvements are currently implemented in 'tbbmalloc for arma':

- supports the use of 'large pages' (if correctly configured and available), which results in ~ 25% better memory access performance for all read/write operations to allocator memory

- some internal optimizations are improving the overall allocation performance

(please check your malloc_xxxx.log file and verify that large pages are available and used correctly, 'Alloc LP').

If your OS version don't have secpol.msc, you can use GMF.exe tool in the tool folder in tbbmalloc github repository. See readme.txt for usage details.

Please let me know your results,

Fred41

BTW:

Did you know, that mapping a3 image file to large page memory region, significantly accelerate execution performance?

Look for 'GimmeMoreFrames' in my github repository, for a very simple, but powerful registry tweak.

If you already have the 'Lock pages in memory' privilege set correctly, it is a very simple tweak.

https://github.com/fred41/GimmeMoarFrames

Edited June 14, 2014 by Fred41
rewrite

[das attorney 858]

Hi Fred41, thanks for your work on this.

As a user with little knowledge of how memory allocators work, what kind of things are we looking for? (Increased system memory usage for example)

[fred41 42]

Hi Das,

some basics about the BIS custom memory allocator are explained here:

http://community.bistudio.com/wiki/ArmA_2:_Custom_Memory_Allocator

In short, the memory allocator is the interface library for allocating/freeing pieces of memory indirectly from/to available system memory.

Especially the intel tbb_malloc is a well known, fast and solid allocator, used by BIS in version 4.0.

Meanwhile there are some bugs fixed and some features added by intel, so the current version 4.2 is a bit more improved.

The LARGEADDRESSAWARE flag, on the other hand, is a flag which is introduced by microsoft,

to allow 32 bit applications to indicate, that they are able to use memory addresses above 2GB in a correct way.

So i offer here a newer memory allocator library for testing.

Maybe we can help BIS this way, to circle the current memory issues.

Greets,

Fred41

Hi Fred41, thanks for your work on this.

As a user with little knowledge of how memory allocators work, what kind of things are we looking for? (Increased system memory usage for example)

Edited September 15, 2013 by Fred41

[das attorney 858]

Cool, thanks for the reply.

I'll check it when I get in from work and see how the game runs with it compared to the default allocator. I remember when they first introduced the memory allocators in Arma 2 beta. I didn't have much variation in performance apart from a couple of them that would crash the game (nedmalloc and jemalloc) on my system if I recall correctly.

[bakerman 247]

Thanks for this info!

I quickly extracted a LAA module I coded a while back into a tiny application you can use to check and enable LAA on a file if needed.

https://dl.dropboxusercontent.com/u/63047178/Baked_Large_Address_Aware.exe

[fred41 42]

Hi Bakerman,

thanks for your offer to help here.

tbbmalloc.dll is already linked with the /LARGEADDRESSAWARE flag set, so there is no need to change the binary later.

Please try the new custom malloc (on server or client) and let me know your results,

Fred41

Thanks for this info!

I quickly extracted a LAA module I coded a while back into a tiny application you can use to check and enable LAA on a file if needed.

https://dl.dropboxusercontent.com/u/63047178/Baked_Large_Address_Aware.exe

[das attorney 858]

Just a quick bit of feedback - just tried your malloc in editor mission and it seemed to use slightly more RAM (half a gig or so). Couldn't tell any difference in framerate (may have been a touch faster, but could have been placebo effect).

No crashes though! :)

[fred41 42]

Hi Das,

thanks for testing.

The difference should be observable, at the point where armas memory allocation is near 2GB.

On altis map, this point can be reached very quickly (1/2 - 2 hours, depends of your mission).

With the original tbb4malloc_bi.dll, trouble starts for me at 1.8-1.9GB memory on client (pure fps, <10 instead of 40-50 before).

I set maxmem=3072, used the new tbbmalloc.dll and have no problems now, at around 2.2 GB (didnt tested longer).

Fred41

Just a quick bit of feedback - just tried your malloc in editor mission and it seemed to use slightly more RAM (half a gig or so). Couldn't tell any difference in framerate (may have been a touch faster, but could have been placebo effect).

No crashes though! :)

[pawelkpl 29]

Thx Fred41, It is very interesting, I will check it on my server and client and post results.

[windies 11]

I will give this a try. Also as a warning, if you change the name of this to TBB4Malloc_bi.dll to replace the one currently in the directory, it will be rewritten every game update with the one supplied from BI, thanks to Steam auto update and integrity verification. So I suggest that you just use the command line to specify this one rather than trying to replace the current TBB4Malloc_bi.dll and use it that way.

[giorgygr 61]

There is no conflict for me.

I got no overwrite alert message.

[dazhbog 10]

There is no conflict for me.

I got no overwrite alert message.

As Windies says it should get overwritten during updates so supplying it with the command line param would be better.

---------- Post added at 08:09 ---------- Previous post was at 08:07 ----------

Hi Das,

thanks for testing.

The difference should be observable, at the point where armas memory allocation is near 2GB.

On altis map, this point can be reached very quickly (1/2 - 2 hours, depends of your mission).

With the original tbb4malloc_bi.dll, trouble starts for me at 1.8-1.9GB memory on client (pure fps, <10 instead of 40-50 before).

I set maxmem=3072, used the new tbbmalloc.dll and have no problems now, at around 2.2 GB (didnt tested longer).

Fred41

Is this on 32bit system or 64bit? If 32bit is it with the 3GB workaround? Also, have you tried maxmem=3072 with the original allocator?

[tonygrunt 10]

Is this on 32bit system or 64bit? If 32bit is it with the 3GB workaround? Also, have you tried maxmem=3072 with the original allocator?

Can you confirm that maxmem can take values greater than 2047?

Because I was under the impression till now that values greater than 2047 would default to 2047 (BI wiki, previous info from devs).

[Dwarden 1125]

ye the -maxmem= is softcoded to 2047, more (e.g. 3071) wasn't yet added ... (at least i'm not aware of that)

2.2-2.5 GB usage is normally possible with older TBB we use now (we plan to update to 4.2 sometime soon)

as engine adds more for dynamic allocations, variables and libraries next to these 2GB (or in future 3 GB) you set via maxmem

i push to increase the maxMEM & maxVRAM frontier from 2GB to 3GB (on 64bit OS with 4 or more GB memory) but no ETA on this

[tonygrunt 10]

Thank you Dwarden for the info.

More video ram usage would be most welcomed, with my 4GB gfx cards when the engine reaches the memory limit (2GB-2.5GB depending on settings) it would drop down about 600-700MB producing some momentary stutter and discarding what is behind you (look behind you and terrain is a blur and more stuttering till it loads).

[das attorney 858]

As far as I'm aware, the MAXvram parameter can be set to whatever you want.

I've got 4Gb VRAM and have set mine to 3900Mb (allowing 196Mb spare).

Readout indicates that the VRAM used goes well over 2Gb (and culls back down when I move to an area with less textures), so no issues there.

Would be nice to see the maxMem worked on to allow higher RAM allocation for Arma.

[dazhbog 10]

Can you confirm that maxmem can take values greater than 2047?

Because I was under the impression till now that values greater than 2047 would default to 2047 (BI wiki, previous info from devs).

Ahh, my apologies, I have simply copy pasted it. The limit is 2047 but it's also a little bit more complex - see here for more details: http://forums.bistudio.com/showthread.php?152866-Development-branch-discussion&p=2481817&viewfull=1#post2481817

[fred41 42]

Hi dazhbog,

i use windows7/64bit.

I changed from maxmem=2048 to 3072, just to make sure this is not limiting

and i did it already before i tried the newer tbbmalloc.dll, based on intels current source code version 4.2.

(there was at least a chance, that maxmem range is already extended, because we are in the DEV branch ...)

If i understand this: http://forums.bistudio.com/showthrea...=1#post2481817 correctly,

the recommendation for a modern system with 64bit OS and 8+GB RAM is:

"dont use maxmem and let arma 3 change internal limits automatically" ???

If so, i will try to reproduce the problems, without maxmem set, and compare the performance with both, the 4.0 and 4.2 malloc .dll's.

Greets,

Fred41

As Windies says it should get overwritten during updates so supplying it with the command line param would be better.

---------- Post added at 08:09 ---------- Previous post was at 08:07 ----------

Is this on 32bit system or 64bit? If 32bit is it with the 3GB workaround? Also, have you tried maxmem=3072 with the original allocator?

Edited September 12, 2013 by Fred41

[ramius86 13]

I've switched in dev during lunch pause and I've made very few tests...

You know a method to get the normal ( with standard tbb ) ram usage near 2 gb? I've downloaded several mission from workshop but nothing.. only 1,75 max.. Ill retry this night with editor ..

I've always launched A3 since march with custom parameter and obvliously maxmem at 8 gb but never see usage more than 2 gb

[Dwarden 1125]

@Fred41 using 2048 or 3072 doesn't matter as the engine treats any value over 2047 as 2047 in maxmem param ...

so if you see any change it could be just change in dev branch or the TBB version

anyway for me it's normal to get A3 on 2.2GB mark ... sometimes even 2.5GB spike

[windies 11]

I see a total memory footprint from ArmA 3 of 4gb. I test it by opening up Performance monitor and adding the % total committed bytes in use counter, take the measurement before loading ArmA, take a reading after loading ArmA, take a reading after loading Altis in the editor and then take the maximum after flying around Altis in a Jet.

I have 14gb of virtual memory, between paged and non paged, I'm at 13.5% committed before launching ArmA, I'm at 25% committed after launching ArmA, I'm at 33% committed after loading Altis in the editor and I'm at 44% committed while flying around Altis. Subtracting the base 13.5% from the increasing total, that works out to 1.61gb at the title screen, 2.73gb in the editor, and 4.27gb while flying around Altis with all of the stutters.

FYI, if you want to test it yourself you can add the "committed bytes" counter and it's easier to see exactly how many bytes you're using rather than having to calculate percentages. I just find it easier to calculate the percentage of a static total so you don't have to do a bunch of figuring with large numbers.

Here's a screenshot showing both Task Manager and Performance Monitor with the total commit charge counter highlighted.

http://i41.tinypic.com/2qulous.png (556 kB)

You can see that Task manager only shows 1.5gb in use, but that's only the Private Working Set, so that's only physical memory allocated. Then you see the total commit charge in Performance Monitor and you see it's at 6.6gb and the big red bar shows 43% of my total commit charge in use. So ArmA 3 does use at least 4gb of memory and does fill the entire 32 bit addressing space.

This is also only me in a jet, with no other assets on the map and a view distance of 2km and object view distance of 1km and it's already exceeding the architectural bounds of 32 bit addressing.

Edited September 12, 2013 by Windies

[fred41 42]

@ramius,

reaching the 2GB border with altis map should really not be a problem.

Empty mission starts with 1.1GB (client), small missions starts with ~1.3GB, and dependend of the mission and player number it

normally slowly grows to above 2GB (max. seen by me 2.4GB). I use processexplorer from sysinternals for measuring.

@Windies,

lets hope for real 64bit arma in the near future ...

@Dwarden,

yes, thats exactly what i have to assume now.

I tested yesterday with both tbb 4.0 and tbb 4.2, more than 1 hour each (maxmem not used/set).

Both runs with perfect FPS normally between 40 and 50 (vsync on).

Max. memory ~2.2 for each of both tests (BECTI 0.9 on altis).

Also, there is no important difference between 4.0 and 4.2, maybe 4.2 is a tick better (just a feeling).

The difference i observed in the last days (problems disappear), seems to be only caused by improvements/changes in the engine (DEV branch).

PRELIMINARY CONCLUSIONS:

tbb4malloc_bi.dll works well enough, currently

dont use maxmem without a need (64bit OS, enough physical RAM)

Greets and a HAPPY RELEASE :)

Fred41

Edited September 12, 2013 by Fred41

[Dwarden 1125]

4.2 has definitely lot of fixes and code optimizing / cleaning ... so it shall run lil better ... especially on lot of memory ops and it shall be more stable

[John Kozak 14]

Edit: sorry, mix up of terms was here. Task manager and Process Explorer treat things differently.

------------------------------

Setting LAA on a DLL shouldn't have an effect, at least some guys on MSDN say so...

Hope this internal limit gets raised, it's a pity to not use additional 2GB available.

Edited September 12, 2013 by DarkWanderer

[ramius86 13]

I will retry this evening but yesterday I've tried spawn AI around the map without nonsense and 1.80 gb used!

The only strange thing it's that I've put all video and viewdistance to ipermegaultra and there are freezes ... not fps drops... also terrain texture are 50% white and then they get textured... Arma 3 stop responding and then it restart working.. It's seems it has problem in allocate ram in my system... gpu ram usage was around 1,7-1,8

I've forgot processexplorer!! ill retry

Edited September 12, 2013 by ramius86