Custom Memory Allocator for engine since b85869

[Dwarden]

Since Arma 2 Operation Arrowhead build 85869 (1.60 beta) it is possible to provide custom memory allocators for the game.
The memory allocator is a very important component, which significantly affects both performance an stability of the game.
The purpose of this customization is to allow the allocator to be developed independently on the application,
allowing both Bohemia Interactive and community to fix bugs and improve performance without having to modify the core game files.

READ more @ BIKI: http://community.bistudio.com/wiki/A...mory_Allocator


this is followup to memalloc testing in earlier betas http://forums.bistudio.com/showthread.php?t=121455

note: this thread might be moved elsewhere when the beta is over, atm. feel free to discuss this news here ...

[[FRL]Myke]

Uhm, yeah, interesting. Would you mind to translate this into a "programming for dummies" language?

Don't get me wrong, really appreciate every improvement. It's just, it tells me nothing if and how i would/could benefit from that. Blame it on my stupidity.

[Dwarden]

i suggest read this http://en.wikipedia.org/wiki/Memory_management
and some other materials about memory allocators

advantages of this approach
- You may write own allocator for engine
- You may alter existing allocators for the engine and update them anytime You see fit

another plus, ability to use allocators which aren't used by us for various reasons
(e.g. impose licencing or rules we can't adopt, while they support free usage for home users , too complicated and so on)

list of some allocators for experimenting:
HOARD: http://plasma.cs.umass.edu/emery/hoard ( http://plasma.cs.umass.edu/emery/licensing-hoard )

[DBGB]

Nice... I guess...

This would really be a firstmover thing AFAIBelieve.

If the enduser could supply a commandline argument that would enable use of 'external' GPL/Commercial malloc implementations optimized for his/her's specific CPU/NUMA/RAM environment/topology.

So basically I dream BI could enable that the coreengine could hook into a whatever 'malloc' implementation the enduser wanted to use...

Is this the idea ?

[Would be nice if the community or BI could supply a script that would run through a benchmark that would help the enduser choose the malloc giving the best performance]

[Dwarden]

Nice... I guess...

This would really be a firstmover thing AFAIBelieve.

If the enduser could supply a commandline argument that would enable use of 'external' GPL/Commercial malloc implementations optimized for his/her's specific CPU/NUMA/RAM environment/topology.

So basically I dream BI could enable that the coreengine could hook into a whatever 'malloc' implementation the enduser wanted to use...

Is this the idea ?

[Would be nice if the community or BI could supply a script that would run through a benchmark that would help the enduser choose the malloc giving the best performance]

it's already possible, check Yourself todays beta build

read the BIKI page

by default You can use either windows memalloc (erase all other allocators DLL from \dll\ directory)
or choose use Intel TBB 3.0 or Intel TBB 4.0 allocators (which are included)

[alef]

Would you mind to translate this into a "programming for dummies" language?

Just think you need to fill or clean a room with solid objects.
And when you put something in the room, you can't move it later.
And you need to fill up using every little space of air.
And when you remove lot of little things, you may need to find space for a huge thing.

You may invent ideas like put big things on the right and little on the left.
Or put things that are big "2" near 2 things that are big "1" each, thightly packed.
Or put everything everywhere without care, starting from the door.
Or put blue stuff on the floor and red stuff hanging from the ceiling.
Or put important things on the front and never-used stuff on the back.
Or lay things aligned on black tiles and other on white ones.

Important is, when you need to put in the room that big object that suddendly comes, to have enough space free. And that fit its shape.

The room is your RAM, the objects are packs of bytes, the ideas are the allocators.

[DBGB]

Browsed through the links presented above - (interesting Hoard results).

Seems some testing is imminent with this beta.

I wonder if the Intel implementation (I have a quad-socket quad-core AMD Opteron setup in "Numa" mode) will invoke some kind of artificial throttling - or 'miss' some optimizations based upon CPU architecture.... (

Intel compiler controversy: http://www.agner.org/optimize/blog/read.php?i=49

That's why it would be NiceToHave some kind of malloc plugin benchmark interface that would help the casual user to decide the best malloc option to use (maybe even provide a compile option for 'custom' implementations)

[MavericK96]

The whole thing is a bit over my head but I'm hopeful that more skilled individuals will make good use of this.

[DBGB]

Just tested with the winhoard.dll x64 downloaded from here : http://plasma.cs.umass.edu/emery/download-hoard

I just made a backup of the dll folder (with tbb3malloc_bi and tbb4malloc_bi) only kept the winhoard.dll file there.

Is this the correct way to do test - or do I still need to specify the malloc option in the command line ? Please confirm.

Anyway - I tested Benchmark 2 (on chenaurus)

and got a "to many virtual blocks allocated" error.



It should be noted that I had this in my GFX options

.ArmA2OAProfile
version=2;
blood=1;
singleVoice=0;
shadingQuality=100;
shadowQuality=4;
maxSamplesPlayed=80;
anisoFilter=4;
TexQuality=3;
TexMemory=4;
...
sceneComplexity=1000000;
viewDistance=10000.001;
terrainGrid=6.25;


And this as my commandline:

Bohemia Interactive\Expansion\beta\arma2oa.exe" -nosplash -skipintro -cpucount=12 "-mod=expansion\beta;expansion\beta\expansion;@CBA;@ ACE;@ACEX;@ACEX_USNavy;@ACEX_SM;@ACEX_RU

My experience: LOOOOOL - everything was less than one frame pr. second in the beginning but later the frames and the sounds of shots began to come in sync - so it sounded like a drummer on a slave galley that gradually increased his BPM - as the amount of objects shown/calculated in scene became less and less.... I think I watched the benchmark for a few minutes...thinking daaaamn...this is slowmo...but getting better...and better...and...

.....WHAM CTD with this new wonderfull error message....

I'm gonna test with the other mallocs and 'regular' no ACE commandline.


And maybe a bit less ambitious viewdistance ;-)


2nd update: Funny thing happended when testing tbb4malloc_bi.dll

Note: I didn't change any gfx/cmd options -

The benchmark initially ran just as slow as the winhoard.dll but gradually the gunshots/shell shots began to get in sync with the framerate and get faster and faster untill it actually got into something that felt like a few frames per second...

Now the funny part....This benchmark run didn't crash - it also never ended... I alt-tabbed out to write this.

The camera just stops sometime after flying over the control tower and the/ some AI shilkas goes crazy on the flying targets which sometimes circles into view (or stays out of the scene, who to tell).

This is probably related to other beta (trigger) changes... but definitely a difference between the two malloc dll's so far.


3rd update

Ahh the benchmark is about to end... I was just impatient... the screen is fading to black....I'm waiting for the FPS score....will alt tab back again in a minute...10 maybe to tell result ;-) Nevermind...it must be less than 1 FPS..

Will now test the default malloc (empty dll folder)....1..2...3

4th update:

Default malloc (empty dll folder) - crashes to desktop with the same "to many virtual blocks allocated" error. Only seems to get about half into the benchmark

5th update:

Reset GFX to default in options (VD=2400) and used winhoard.dll - no crash but still benchmarks never shows FPS / ends - will now try without ACE cmdline.

Haven't paid attention to any cpu core affinity issues - but let the engine use 12 out of 16 cores on my rig in every benchmark.

6th update: Wooohooo got 8 FPS with VD=2400 and winhoard.dll - will make a table - give me 20 min.

7th update: Ran both intel/bi's 'beta' memallocators and the winhoard - and with empty dll folder - benchmark 2 - two runs each -> all hovered at the 8 or 9 FPS... default gfx options 1600x900 + VD=2400. (Radeon 5800+ latest drivers - server 2008 R2 x64)

So maybe I'm doing it wrong ? Or the benchmark / malloc / engine options combo won't show any big miracles.

[zyklone]

Mission designers starting to code memory allocators...
The end of the world is near...

Fun times