Recent hot topic:
[youtube]AxSk_26otRM[/youtube]
Alt link: - YouTube
Details:
What do you guys think? 
Meh, according to benchmarks ive seen so far, the performance gain is pretty minimal, and in some cases the performance actually drops. For some reason the current implementation of the 64-bit client still uses a pretty large page file on the hard drive despite having more than enough free unallocated space on the RAM. Once they manage to fix this, however, i expect the performance boost will be awesome.
It’s not a big whoop (yet), they still use the WINAPI file mapping functions instead of memory allocation, so basically nothing has changed except the bitness. I assume they won’t leave it at that, though. Still - don’t expect miracles; anything CPU-bound (most things in Arma) won’t magically improve.
What’s the difference between WINAPI mapping functions and memory allocation?
What’s a WINAPI mapping function?
Look at the date of the post, the statement is not true anymore, they changed the way they use the allocator in the v1.68 stable version (I was using devbranch back then).
Yeah, but… what’s the difference?
WINAPI is, well, an API provided by libraries on MS Windows, shipped by Microsoft. For example stuff in kernel32.dll (AFAIK, I’m not exactly a windows guy). This API contains functions that do what mmap() does on linux, ie. uses a shared page cache (though much smaller than on linux) to map virtual memory ranges into any file ranges. Whenever your process accesses the memory, the pages are swapped in and you can read the data. This allows you, in a way, to combat the 32bit address space limitation, because you’re only mapping one or few files at a time, unmapping them after you’re done reading. The benefit comes from the OS doing the caching, outside of your 32bit VA space. In theory.
In contrast, a larger address space (64bit) allows you to never unmap the files, which would work well on linux, which uses all available and free memory to cache those pages, but windows has something like 16MB cache, so a better course of action is to just get a few gigabytes of anonymous memory (not backed by a file) and do the caching yourself, reading files fully into memory the usual way.
Which seems to be what v1.68 stable does, as its memory usage increases to even 9GB when you load all models/textures/etc. from our modpack at the same time and the majority of it is in anonymous pages.
(Not sure if this answer helped, but I don’t have much time to do a full "how memory works" intro. There are some great articles on google, though, if you’re interested.)
Thank you, Freghar.
I’m studying memory hierarchy atm and that’s gonna come in handy.