CPU VS RAM Performance & CPU Threading Benchmarked

[jumpinghubert 48]

i see your running at 4.8ghz...how does A3 run for you? and have you compared 4.8

vs stock?

I raised all gpu-related graphic settings and reduced all cpu-related settings so i have constantly 99% gpu-usage and a good amount of cpu power for the AI plus good min fps (not below 39fps). Go from 3,8 to 4,8 GHZ boost the min fps in ai-intensive scenarios drastically. I invested in good watercooling and cpu to compensate the ressource-weakness of this game.

And I avoid weak servers and/or with tons of AI and prefer small sp-scenarios and PvP.

P.S. The only games I play are arma series and Cliffs of Dover :-)...no alternatives for me..

Edited April 24, 2013 by JumpingHubert

[ric 1]

So for you it would make sense to have which minimum requirements? Actual gaming-machine for 1200€ ? Did you take only one minute to think about BIS is also about to make some economical gain? They are aready in a quite small niche of interested parties. Now they shall additionally aim to enthusiast gamers, too?

Who has 6 or even 8 cores running towards 4GHZ? (No enthusiast gamer will buy a Bulldozer these days). Which percentage has cards with dual GPUs ?

So how they would aim to 0,1% of the millions gamers ? This is just nonsense.

I have a 5 year old system and can play A3 just fine, for sure with limited grahical pleasure, but happy about it. I guess Iam not alone...

1200 quid?? rubbish, I am not saying we have to have super rigs, but anything that can run on a dual core but not take full advantage of a quad core is not a "next" gen engine. there "recommended" should have been the minimum....you can get a 965BE for $95 and for another $50 a micro ATX board and $20 for 4gb of ram reuse all your old equipment and that's a $170 upgrade to bring you from dual to quad.

---------- Post added at 13:52 ---------- Previous post was at 13:50 ----------

I raised all gpu-related graphic settings and reduced all cpu-related settings so i have constantly 99% gpu-usage and a good amount of cpu power for the AI plus good min fps (not below 39fps). Go from 3,8 to 4,8 GHZ boost the min fps in ai-intensive scenarios drastically. I invested in good watercooling and cpu to compensate the ressource-weakness of this game.

And I avoid weak servers and/or with tons of AI and prefer small sp-scenarios and PvP.

P.S. The only games I play are arma series and Cliffs of Dover :-)...no alternatives for me..

cheers :) 109 jockey?

[dnk 13]

It largely depends on the size of the program you're running and the size of the instructions being performed as well as the amount of instructions there could be.

Right, I'm not being exact in my wording. The point is that if you only have to read the FSM to get the instruction set for the AI routines once per simulation step, you only have to read from RAM that one time for the instructions from that file, which shouldn't cause many issues and wouldn't increase latency in itself when scaling up the amount of AI running. I would assume this is what happens at the least (if not that the instructions are being kept permanently in L3, moving to L2/1 as the engine switches from other threads/instructions to the AI execution).

The FSM's being an addon would make no difference

You didn't understand my point. Making them an addon allows you to be able to monitor their reads, while keeping them packed in a PBO doesn't allow processmon or other programs to keep track of when they're read from disk as it will only say that "characters.pbo" was read or whatever file it is. That said, I haven't seen mass reading from that or any AI-related PBOs, so it seems they get loaded at least just to RAM at game start and stay there.

Also larger texture files and models and the graphical stuff that generally takes the most space, would preferably be stored in RAM or mostly all in RAM because the disk access would be ungodly if it wasn't.

Then what's with millisecond-lag pop-in and the constant reads from the models/textures files? They are being read from disk regularly during gameplay, as my own monitoring has shown. In ~15min gameplay, I had 1200 reads from just the structures PBOs. I had 2300 reads in another 15 min of play from an addon's environmental sounds (which did add a large %age of extra I/O).

So it's basically like a very very fast game of musical chairs with 3,000 chairs and 6-7,000 people.

Yes, my point as well. What "optimizations" are going to change this to drastically improve performance (well, 64-bit RAM usage could help a lot)? It might be they haven't implemented everything, and BIS has never been a graphics/rendering-focused developer (the simulation is the core of their engine and military contracting business) so that might just be the case.

[Vigil Vindex 64]

My own take on it is that the AI in the engine is out of control. I have been learning to code missions, and my experience is that when you start to use any meaningful number of AI the whole thing just grinds to a halt, where the AI seems to act "dumb" and the game seems to slow while also using less resources. There are all sorts of voodoo you can do to try and use as little AI as possible so you can fake having large numbers of AI over a large area of the map, but it's still a hack and the problem still exists, and adds more complexity to the mission code and design.

I fear for when Altis arrives, as it is a much larger map and will require more AI to fill it and make it a believable place to play in. The performance problems with the AI have discouraged me from working as much as I would like to with Arma 3. It just feels like it isn't going to get fixed any time soon. Documentation on how the threading and processes of the game engine and AI is non-existent and I suspect even the devs have trouble navigating how it all fits together. The fact we don't have devs openly discussing the architecture of the process and thread handling for the AI tells a lot.

The long and short of my post is, I think the gpu/cpu utilization problem are linked to the AI, as when no AI are present the game is smooth and uses resources fine.

I would love to read Dwarden's (or any other dev, preferably the original author) technical and complete description of the code for the AI and how it all fits together within the games other processes.

Edited April 24, 2013 by ssechaud

[Insanatrix 0]

Right, I'm not being exact in my wording. The point is that if you only have to read the FSM to get the instruction set for the AI routines once per simulation step, you only have to read from RAM that one time for the instructions from that file, which shouldn't cause many issues and wouldn't increase latency in itself when scaling up the amount of AI running. I would assume this is what happens at the least (if not that the instructions are being kept permanently in L3, moving to L2/1 as the engine switches from other threads/instructions to the AI execution).

Assuming the FSM is in RAM. Like I said, what if it has been paged? then when a miss is called it has to pull it out of page and into RAM. RAM is full though. From the second you load the game, the 3gb addressing window is full. So then when you need to pull something else in, you have to unload something. That's the constant musical chairs thing I was talking about. You can try to structure it, but the fact it's there is a static limitation to what you can do and how well your program can run once it exceeds that limit. All of this takes time and is very dependent on transfer latencies. The longer it takes, the longer your CPU is waiting to finish it's calculation.

You didn't understand my point. Making them an addon allows you to be able to monitor their reads, while keeping them packed in a PBO doesn't allow processmon or other programs to keep track of when they're read from disk as it will only say that "characters.pbo" was read or whatever file it is. That said, I haven't seen mass reading from that or any AI-related PBOs, so it seems they get loaded at least just to RAM at game start and stay there.

I understand it. What I'm talking about is the pagefile. That is where everything that is swapped in and out of RAM resides. It's only read once because it HAS to reside in RAM because it is a critical component, it's not constantly read from that Characters.pbo sitting in your ArmA 3 folder. That's why you see it getting loaded once and staying there. Just because it's in RAM though doesn't mean that it's not residing on disk in the pagefile. The problem is that you would have to dissect your pagefile and analyze it in realtime to see what is being swapped in and out of RAM. So whether you make a file an addon or not, when it's being used it will reside in RAM and it will not be read from the ArmA 3 directory but rather the pagefile.

Then what's with millisecond-lag pop-in and the constant reads from the models/textures files? They are being read from disk regularly during gameplay, as my own monitoring has shown. In ~15min gameplay, I had 1200 reads from just the structures PBOs. I had 2300 reads in another 15 min of play from an addon's environmental sounds (which did add a large %age of extra I/O).

We come back to the fact that you have a 3gb addressing window and you can't sit and catalog everything that goes in to RAM and assign what gets paged and what doesn't. So you pull non essential files in as you need them so as not to create a large bloat of unneeded files in RAM. Files that wouldn't stall the threads if they're read from the Disk Drive. Like you said in another post, Low poly models and low quality texture's are loaded into RAM while higher quality stuff is streamed. That sounds like exactly what is happening here. The engine would be able to continue on with the low poly model until the high poly model is streamed in, same thing with texture's.

This explains why you only see some .pbo's loaded once, and others that are constantly accessed. Once it's in Virtual Memory and therefor either in Physical RAM or the pagefile, the file doesn't need to be loaded from the disk. But if it's in the pagefile, it still resides on disk, just in a different place and you would never know how many times it's paged in or paged out and how many times it's accessed.

Yes, my point as well. What "optimizations" are going to change this to drastically improve performance (well, 64-bit RAM usage could help a lot)? It might be they haven't implemented everything, and BIS has never been a graphics/rendering-focused developer (the simulation is the core of their engine and military contracting business) so that might just be the case.

Honestly, I don't know. I mean you can keep scaling back how much is pre-cached in Virtual Memory on load and try to cut down on the amount of streaming that's needed to be done by trying to catalog and shape the flow of data that goes in to Virtual Memory. Most optimizations I believe have to do with creating shorter ways to execute code and that definitely cuts down on processing cycles and execution time. The problem is that we are not seeing a very high usage of processing time, which is what CPU Usage represents. So while optimizations like that can help, the larger problem is what's bottlenecking the threads from being able to fully utilize the processor's time.

That is where I/O operations become the bigger factor. I/O operations are things like paging in and out of RAM or RAM to Cache Latency and so forth. This is where trying to buffer crucial data that needs to be in RAM for that fast RAM to Cache latency on a Hard Disk creates a HUGE bottleneck. You can keep trying to optimize it, but you are still limited by the very simple fact that it's a Hard Drive and not RAM. Also you have to think about this in terms of Multi-Threading and Parallel Processing. You're not just trying to feed 1 logical cpu with data, but 4 logical cpu's with data. That's like trying to use 1 conveyor belt to keep 4 workers, working. Sure if the conveyor belt is fast enough, it could give those 4 workers enough data to keep working. Slow that conveyer belt down though, and you get wait times before each worker can complete it's task or do something. This is something you see reflected by the CPU usage of the Engine.

Edited April 25, 2013 by Insanatrix

[dnk 13]

Yeah, but I just don't see my pagefile being read all that much. 10 minutes of intense gameplay over 1km with a 2700m VD resulted in 434/691 reads/writes, for a total of 13MB read and 723MB written (obv, a lot is being written, likely at game start, though I had other programs running in the background, including Firefox, so it could've been W7 moving their RAM files onto the pagefile). Immediately after stopping play and resuming the other programs, I got a ton of new reads (10k+ for over 200MB in 4min), which sort of supports my idea that a lot of those writes were moving lower-priority stuff out of the way, not moving game-related files around during play.

By comparison, reading of the "anims_f_data.pbo" was at 1600 with 44MB read; "sounds_f.pbo_" had 1370 reads for 47MB; "map_stratis.pbo" was 1333 for 27MB. The pagefile just isn't being read that much compared to the disk, and I severely doubt the game or Windows is placing such extremely highly used data like that in the FSM on the pagefile and reading it from there often. If it was, it would be reading it every frame, perhaps multiple times, which would have over 10,000 reads in 10min. Same goes for textures/models being referenced every frame or every few seconds. I don't know how much time needs to elapse between when they are last used and W7 shoves them off to the pagefile, but it can't account for frame-by-frame low performance when your view isn't changing that much. That's more likely the latency/bandwidth between main RAM and the GPU or CPU.

Additionally, the game is only using about 1.4GB of 2.5 available, so the Prius is hardly full even with a 2GB limit.

Edited April 25, 2013 by DNK

[Insanatrix 0]

Yeah, but I just don't see my pagefile being read all that much. 10 minutes of intense gameplay over 1km with a 2700m VD resulted in 434/691 reads/writes, for a total of 13MB read and 723MB written (obv, a lot is being written, likely at game start, though I had other programs running in the background, including Firefox, so it could've been W7 moving their RAM files onto the pagefile). Immediately after stopping play and resuming the other programs, I got a ton of new reads (10k+ for over 200MB in 4min), which sort of supports my idea that a lot of those writes were moving lower-priority stuff out of the way, not moving game-related files around during play.

By comparison, reading of the "anims_f_data.pbo" was at 1600 with 44MB read; "sounds_f.pbo_" had 1370 reads for 47MB; "map_stratis.pbo" was 1333 for 27MB. The pagefile just isn't being read that much compared to the disk, and I severely doubt the game or Windows is placing such extremely highly used data like that in the FSM on the pagefile and reading it from there often. If it was, it would be reading it every frame, perhaps multiple times, which would have over 10,000 reads in 10min. Same goes for textures/models being referenced every frame or every few seconds. I don't know how much time needs to elapse between when they are last used and W7 shoves them off to the pagefile, but it can't account for frame-by-frame low performance when your view isn't changing that much. That's more likely the latency/bandwidth between main RAM and the GPU or CPU.

Additionally, the game is only using about 1.4GB of 2.5 available, so the Prius is hardly full even with a 2GB limit.

I see a total of 5gb memory usage, you see 1.4gb. Who knows. Like I said, it's just what I think. I'm probably wrong.

Honestly I can't figure out what would be causing the decreased utilization. I sat with ArmA 3 in windowed mode running the same rendering resolution as I normally run, just in a smaller 1024x768 window, with both a hardware monitor and the performance monitor up reading page in's and page out's and page faults per second. Had 8 sqauds fighting each other for about 10 minutes. I mean you're right, there is very little page file access, but there are a lot of soft page faults per second as well as some hard page faults and it tends to spike every couple of seconds. It did peak roughly at 64,000 page faults a couple times, but most of the time it was spiking 6,000-24,000.

http://en.wikipedia.org/wiki/Page_fault

Still I would run into situations where the usage would drop for no reason and FPS would simply dive with it.

Edited April 25, 2013 by Insanatrix

[Leon86 13]

your right it made no difference to average fps

same benchmark but used fraps to record from start to finish

i added another 2x4g kit for 16g total made a 8g ramdrive and put the entire arma install on it

this is at 4.7GHz DDR1600

blue line is hdd+ssd cache red lines is the ramdisk

yeah, might get rid of some stutters on a fresh start, but overall not worth the effort.

[rebelvg 281]

Can someone test this in Arma 2 as well?

[fred41 42]

The long and short of my post is, I think the gpu/cpu utilization problem are linked to the AI, as when no AI are present the game is smooth and uses resources fine.

... yes, the AI and the underlayed old script processing design (not changed much since arma 2).

The main problem seems that script execution in the non scheduled environment (calls from eventhandlers) is still mixed with the script execution in the scheduled environment (spawn, execVM, FSM condition evaluation) in ONE SINGLE THREAD, what means all script processing can never use more then one core.

A very important point is that the execution time of scheduled scripts currently depends from the number of scripts concurrently running (AI-FSM conditions, etc), that makes AI so slow responding if you have more of them.

see here for script processing details:

http://community.bistudio.com/wiki/Code_Optimisation (look in threads).

I really wish that BIS will make here the next step.

Of course it will not be easy, but it is time to do it ...

Edited May 2, 2013 by Fred41