jiltedjock

A 32 Bit executable can use 4GB of address space on 64 Bit Windows.

There is nothing in Haswell that will make it run better than on Sandybridge.

The other solution - if you have a quad core or greater - is to play your missions as multiplayer missions on a dedicated server instance running on your box, so that the AI is offloaded to the server executable instead (and thus is processed on a core not being used by your client).

I would expect the AI to be able to reverse a vehicle or use a building for cover in next gen Arma. Is next gen hardware going to be single core CPUs running at 7 or 8 Ghz? Because that is what Arma 4 will need to run well, because the engine will basically be Arma 3 plus 4 years of patches.

Also recommended for anyone with a good quad core to run a dedicated server and client on the same box. Export your missions as multiplayer and play them as single player, the AI will now be offloaded to the server and you'll get better, more stable FPS on your client.

http://forums.bistudio.com/showthread.php?163640-Arma3-and-the-LARGEADDRESSAWARE-flag-(memory-allocation-gt-2GB) http://forums.bistudio.com/showthread.php?177454-a-simple-registry-tweak-for-increased-performance these two combined have given me the highest, most stable FPS I've had in Arma (x64, 16GB RAM)

Fred41's large pages malloc certainly seems to result in higher, more stable FPS, I am using it to good effect in Arma 2.

Especially since they have been doing it this way since OFP.

After 320, having the frame limit set in the Nvidia profiler stops vsync from working, and vice versa. this is by design, as apparently the fps limiter was interfering with vsync, however I never noticed this in any of the earlier drivers where I would sometimes limit frames below 60 to keep GPU temps down or to prevent spikes

Isn't it obvious that this is caused by AI simulation being downgraded during fast forward? => less CPU work => more FPS.

Any 32Bit app can use up to 4GB on x64 Windows, and up to 3GB on 32 bit OS with the /3GB switch, as long as the application is Large Address Aware (which Arma 3 is).

You are full of it. Where did I say the code is not optimized? I said the application architecture is not optimal' date=' and offered the example of moving the AI processing to a spare core, which [b']does[/b] improve the client performance. And with Fred's changes, I have not seen anyone report worse performance whereas some users are seeing 10 or 15% more FPS. You are saying, definitively, that the code is optimized. With what evidence do you say this? Are you a programmer? Do you have access to the source code? To be frank, I don't even know what you think you mean by optimized. Do you mean you don't think the code can get any better? On what evidence? Throughout this thread you have not accepted anyone offering the opinion that the code is not optimized, unless they have access to the source code. Well the reverse is true too - how can you say it is optimized, without access to the source code? Wouldn't it, in fact, be better if you just stuck to saying that you are satisfied with performance on your PC and leave it at that?

None of his symptoms suggested issues with his BIOS, it was clearly his config. Say you have a problem, you update everything, you still have a problem. Or, worse, you have a new problem. Where does that leave you? That is not the right approach - read the changelogs before you update critical components. My BIOS is on version 5, 9 is the latest. Nothing has changed in the meantime that makes it worth the risk, however small, of updating, or the ball ache of configuring the new BIOS overclocks, voltages etc. If you are updating your BIOS via a Windows app, you are going to experience problems at some point, guaranteed.

Necessary in about 0.01% of cases (I work with huge server farms).

Do not update your BIOS to try and fix this. Are you having any issues in any of your other software? No. Whereas if you screw up an unnecessary BIOS flashing, you will be in a world of pain. Find your config files, make sure they are not Read Only. Check your Windows Event Viewer - any new, unexpected, events? The latest Nvidia Beta drivers for the 680 are good - try them.

It was mind blowing. I upgraded to an AGP Geforce MX2 from a 3dfx card on the back of that demo. I think it had 32MB of VRAM! I created missions from the demo mission as people on the OFP forums started to discover the various unit names.

Garbage. He shared the concerns that people might have using an exe, and so told them how to do it manually. what gives you the impression that no-one knows how to undo the change? It would be as simple as removing the registry entry. This isn't "messing around" if you know anything about how your PC's OS works. If you don't, you probably shouldn't be reading - or commenting on - this thread.

This won't do anything, cpucount 4 and exthreads 7 is the max, on all CPUs. If you enter 6 and 6, it will revert to autodetect. Which will probably work perfectly and has done since at least Arma 2 1.59 exthreads can have values of 0,1,3,5,7 . These are not the numbers of extra threads, they are values that define which row in the extra threads table is used. 0 = zero extra threads 1 = 1 file ops extra thread 3 = 1 file ops and 1 texture loading 5 = 1 geometry loading and 1 file ops 7 = 1 geometry, 1 texture, 1 file ops

you have no idea what the effort is as you demonstrably know nothing about programming. why do you refuse to address any of the posts about moving the AI processing to spare client cores?

No, I'm not mistaken. I already do this in Single Player by running a dedicated server instance on my PC, which all the AI is local to (except the AI in my group), and running my missions as multiplayer (with me as the only player). My client runs on the same PC. So now, instead of the AI processing taking place in any of the client threads, it is completely decoupled and running on an otherwise unused core. If I had a hexacore I would probably run a HC too and set some of the AI locality to that. The point is, that Arma already supports decoupling the AI processing from the client threads. So what I am suggesting is that they build this into the client exe, so that in Single Player the AI is processed on a separate core from those used by client simulation threads. The result of this is that when there is a lot of AI processing going on, there is little impact on client frame rates. It is not the golden fix that everyone is looking for, but it is better than the current client architecture.

So what were your thoughts on the benefits of moving the AI thread to different cores as per my earlier posts. I told you it would be a straightforward change to the client - straightforward relative to re-writing the simulation thread to be more multi threaded - as the architecture already exists (client/server AI locality), you questioned my credentials, I provided some detail but re-iterated that it wasn't really important as the architecture already exists and the benefits are proven by anyone who offloads the AI using a dedi server. Do you, or do you not, think there would be a benefit to BIS specifying quad core and moving the AI processing to extra threads?

Which interface did you connect it to?