Theatre of War 2 & 3 optimization on newer CPUs

[bertie97]

Theatre of War 2 & 3
This may be beyond the scope of PL but I'd like any feedback or thoughts on what I can try to alter my lag & stutter problems.
I play the ToW series of games which has a notoriety for being Slooooowww on 'high end' systems.  It actually runs better on older hardware...
The game is very CPU intensive & suffers most during high activity - due to multiple intensive damage modelling calculations.  The CPU is the bottleneck for the calculations, & gfx 'tweaking' has little or no impact on final FPS.

As 'proof' of this I just upgraded from an AMD 955 to a AMD 1090 & my FPS has halved.   

I have tried gaming mode with PL & I have set  different affinity & IO to the high/critical where possible with only minimal impact.

I have learned the games executable process is both the .exe & the .bin - eg kursk1943.exe & kursk1943.bin  (I added both to the game process list & this had a positive impact but not enough to eliminate the problems).

Alteration of core, via the game - limiting to a single core or the first 2 cores has no positive effect.

I read that Intel i5 & i7 users have the same problems, so it is a question of how the game interacts with any new CPU I believe.

I would be very happy if anyone can offer me some pointers on remedying this problem as would pretty much all ToW players I think.
TiA

[Jeremy Collake]

Process Lasso is not going to make anything run faster - and don't believe any claim that any software will. The only thing it will help is in conditions where you have *other* stuff also running that would have otherwise interfered with the game. ProBalance's primary goal is to ensure the system remains responsive and doesn't suffer from micro-lags and the like. There's no magic potion to make a system whose bottleneck is the CPU go faster, I'm sad to say ;o. Perhaps this is overly honest, but I'm not that good a marketer, lol.

[bertie97]

Thanks for the fast response.
I find PL helps - obviously juggling priorities etc do have an effect on ToW.

My basic question is based on the assumption that older code which runs well on older CPUs should still be able to function properly on a newer CPU.
So my bottleneck could theoretically be reduced if the code would address the multiple cores better.
Hence I wondered if PL could help with that.

I guess I have to look at how the exe is addressing the ram & cpu & find a way of making it work.
It's possible to add \AFFINITY 0X3 to the command line to force an older 2x environment, so maybe there is some variant on that, (but I don't know where to look & I just don't know enough.). 
The authors unfortunately don't seem to be very helpful with this - big job or just focused elsewhere?

& Yes that kind of info is outside PLs remit...

[edkiefer]

It is very hard for most games to be truly multi-threaded , the reason is that most times they need the data output of first thread to continue with second and third threads . Its just the nature of how a game works .

I am not familiar with TOW , I guess it is possible that how it was optimized is not now good with modern CPU, though that really shouldn't be but sometimes they use fixed timers for things , these are set according the hardware of the time , so with 2x, 3x speed CPU that throws it off but again I have no idea if any of this is in TOW .

[bertie97]

Thanks for giving me a few things to think about.  I will continue playing around & hopefully find out where the trouble is. 

[Jeremy Collake]

There is one thing you can do to *possibly* help, if you have not tried it so far. That is to use the 'Hyperthreaded core avoidance'. However, it is unlikely to help because the Windows CPU Scheduler is also already aware that these are HyperThreaded (fake, if you will) cores. UPDATE: I see you essentially did just this with you affinity setting.

Ed is right that it is hard to make applications truly multi-threaded. That is the big challenge these days. As a developer, I get emails from Intel every month with their latest strategies on how to help developers write better parellel code. Still, most applications do most of their work in a single thread, as a linear operation... simply because, just like a math equation, you have to get the first part of it done before you can do the second part.

I will re-read again later and see if I have any suggestions.

[bertie97]

Thanks for the input.  It has helped me visualize the challenge a little better.  I had been thinking in terms of parallel commands to access cores, but hadn't understood how ToW2+ does this (given a linear stream based on the events in-game & the equations being calculated in real-time).
I did find a comment by a member of the dev team who said that the game focuses on core 0 then hands off extra tasks like pathfinding to a 2nd core if found.
This led me to experiment with forced affinity on different 'pairs' - PL appears to have given me a 5fps boost using this strategy.

I also followed an idea about altering the GFX control panel values, in this case nVidia.  No-one offering advice on this has previously suggested using VSync in the game (that I can find) & historically I have found VSync to be a major performance killer. 

That appears to have 'suddenly' changed for ToW on my hardware.  Switched to ON via the CP, VSync suddenly makes ToW2 Kursk run like it used to.  It has gone from <3fps under max load to <25fps; <40fps in other instances.
I find this odd but obviously something has changed in the way DX & the gfx driver/GPU are governing the games' output. 
The downside is that to get these frame-rates I must turn off some of the gfx effects.  Formerly I ran without vsync & had everything on max & got comparable performance.

Notably, using PL on the .bin + the gfx setting change means ToW2 Africa is now giving me up to 60+fps (from <20fps).

All in all it's a victory on FPS but not quite the outcome I ultimately want.   


I am therefore led to wonder if a Process Lasso-like prog can be made to modify the GPU queuing methods. 
I know a modern GPUs architecture runs quite differently to the CPU core but it raises some interesting possibilities. 

[bertie97]

It seems Process Lasso has saved the day after all.

In line with a post on the Steam forums this has appeared to be the cause of a lot of slowdowns -
windows dynamic thread priority boost

PL allows this to be easily switched on/off with dramatic effect on the game performance.
These were snapped whilst the game was running.


windows dynamic thread priority boost OFF


windows dynamic thread priority boost ON

With the boost set on for the exe the affinity settings are lost.     
That info & the gfx switches has given me back my performance.

So a "thank you" is in order to you guys! 

[Jeremy Collake]

Thanks for posting your results Bertie . I'm a little perplexed by the relationship between the thread priority boost setting and the CPU affinity setting (THEORY: the game may be doing this itself during runtime). You may wish to Reset All Defaults, then apply the dynamic thread boost adjustments as desired, just as a precautionary measure after doing so much experimenting - if you haven't already.

Anyway, that is what Process Lasso is for. Figure out what works for YOU, and automate it. Take control of YOUR processes, as every PC's 'executive environment' is different.

[DeadHead]

Most interesting!

Care to take a minute to explain what "windows dynamic thread priority boost" is, exactly?

[edkiefer]

Most interesting!

Care to take a minute to explain what "windows dynamic thread priority boost" is, exactly?

http://bitsum.com/docs/pl/faq.htm#should_foreground

""What is this 'thread boost' or 'Windows dynamic thread priority boosting' in the process priority setting?

When this is enabled for a process, Windows temporarily boosts the priority of threads for that process under certain conditions (when it leaves a wait state). For specific information, see this MSDN page about Windows dynamic thread priority boosting. Turning this off can severely impact the performance of applications that have a graphical user interface (a window). For background applications, this setting is not usually important. ""

http://msdn.microsoft.com/en-us/library/ms684828%28VS.85%29.aspx

[bertie97]

I will be interested to see if the exe is patched by the devs now this event has emerged.  (Not pointing any fingers just saying it would be nice if someone gave it a look.)

As PL has made it easy for me to watch & alter my OS environment I doubt my experimenting with PL is over