Is 2.5 now CPU multi-core?

I'm not convinced. I see 2 cores running, sometimes at 100% and the others only shows transients. More cores seems to come into play when it is loading assets. I think what you guys are seeing is those 2 threads jumping rapidly between cores, like they do, and it seems to show high usage. I'm still not seeing anyone provide actual proof, just anecdotal accounts. Show us some graphs so that we can see what you mean.

^^ until someone proves we aren't seeing the results of threads jumping around then no-one (apart from ED) can claim DCS 2.5 is properly multi-threaded.

I'm not convinced. I see 2 cores running, sometimes at 100% and the others only shows transients. More cores seems to come into play when it is loading assets. I think what you guys are seeing is those 2 threads jumping rapidly between cores, like they do, and it seems to show high usage. I'm still not seeing anyone provide actual proof, just anecdotal accounts. Show us some graphs so that we can see what you mean.

I have myself posted numerous screenshots that proof 6 real cores at hart work.

Through ProcessLasso DCS and DX11 are tied to physical cores and not HT-cores.

It heavily depends on your hardware if the CPU is needed that much ( fast GPU that wants to be fed ), a subsystem that can keep pace, the right mission, the right scene in that mission and a proper airframe that taxes the system.

No, DCS only uses 2 cores, that's right, but you ask the WRONG question imho, that's why you get wrong answers.

The real question is this: How many cores does my system need to run DCS and all processes that are tied to it ?

Now with DX11, we see a great step forward in more cores being engaged.

My screenshot that had 6 cores at heavy work wasnt even online, it was a dead simple Ka-50 free-flight mission.

Fly the same mission with the same settings with the same fps and smoothness with 2 cores working and all others sleeping. Until then I only believe what I have tested many times, always the same result.

If your CPU aint fast enough to feed the GPU..you wont see those 4 cores feeding the GPU at hard work, they will sppread the work across all extra cores and humm along.

Do the same with a machine that can feed properly, like my system or similar from others with same findings, and you will see that it can very well take more, if you obey the law of the chain..remember the weakest link is your strongest point.

My baseline, 6 cores or more, no less if you buy today. My 7700k was great, but I doubt that I would have the exact same performance with 2 cores less, impossible by math. Also the 8700k runs at 5.2G in DCS, 5G Desktop. 4x 5G = 20G vs. 6 x 5.2G = 31.2G: even if I substract the unused cycles from those cores not fully tilt, it was way more than 20G as a whole. You cannot squeeze that work in a tighter box. No way

^^ until someone proves we aren't seeing the results of threads jumping around then no-one (apart from ED) can claim DCS 2.5 is properly multi-threaded.

I have seen spikes up to 75% CPU usage with no loss in frame rate and steady 20 to 50% with my 4 physical core 8 logical system. You can't "fake" CPU usage. Threads jumping around wont show increased total usage. Looking at graphs it might be possible to misread, but the total usage is not affected by the distribution of tasks. 75% of 8 logical cores means it's using the equivalent of 6 logical cores.

1.5.8 never EVER caused my CPU usage to rise above 30% at most outside of the loading screen. Typically it was 12-24% which is 1 to 2 logical cores. 2.5 most certainly is multi-threaded, but that is not to say that a single core/process can't still bottleneck framerates. It is much better multi-threaded than 1.5.8.

Old version would CPU bottleneck to 40-50fps regularly with lots of AI activity (GPU not at full usage). Now on the rare occasion if it does bottleneck it is typically in the high 70s or 80s.

Here's a few screenshots. This is a fast mission with max AI. You can see that the GPU was being limited, but the framerates are not bad. Any spikes in CPU usage didn't affect the framerate.

Yeah. like I said, it looks like some asset loading is taking place in parallel. the game loop and graphics calls, AI, FMs are still single threaded i.e. more cores doesn't give more fps.

Sent from my iPhone using Tapatalk

I appreciate everyone'e anecdotes but without proof, it didn't happen.

I do believe SpeedTrees are running on another thread, at least it seems as such. I get literally no difference in framerate between 0-100%. It's pretty amazing. It's also likely one of the reasons people are seeing broader core utilization.

I must say, I'm really impressed with 2.5. Disregarding MP atm the sim is so much smoother with higher framerates, not to mention beautiful. Even VR runs better than ever! Now if they can just fix MP..

DCS has been multicore all along. It uses two primarily, one for sound, and the other for everything else. Some CPUs may dynamically shift load between various cores on the fly, but that is not the same thing as using multiple cores simultaneously.

Also, it has been explained multiple times both here by ED, and in the Arma forums by BI (both games that use limited numbers of cores, and the community frequently asks for "multi-core support") WHY they are configured the way they are, how cores are utilised, and so forth. BI wrote an extensive article on it one time a couple years ago, around the time Apex launched, but I can't find it right at the moment :/

Basically both games have high levels of physics calculations, both are simulating a lot of background calculations related to the environment, ballistics, flight models, AI (the reason the AI is so flakey, for example, is because it has to be designed in very general terms so it can function in any situation at least to a basic degree... It can't have a lot of hardcoded functionality, because it wouldn't work in an "open world")...

BY THEIR NATURE, most of these calculations have to be performed on the same core, especially anything even remotely tied to physics. The flight model, the environement, ballistics, aircraft systems, etc, etc, ALL have to be on the same line together or it won't function. You'll get the physics equivalent of de-sync on your monitor causing screen tearing.

In DCS, there was the video recently of the tank zipping through the mountainside and rolling end over end after dropping 19,000ft, and Arma is absolutely famous(infamous?) for the sometimes bizarre behavior of vehicles. You know, they work just fine 99% of the time... but then there's that one moment where the physics engine just says "f this, I'm out". That is because the calculations get sideways with one another, for whatever reason, and it doesn't know what's happening anymore.

Keeping all those calculations on one core helps keep those occurrences down, in essence, and helps make the whole experience more fluid. You CAN split it up, but it's very difficult, especially in a dynamic environment, to do so properly and efficiently. And even if it DOES happen...

MOAR COARS is not a magic go button to make everything run 1000% faster. A comparable example, again referring to Arma (which, ultimately is the infantry equivalent of what DCS is to aircraft) were the demands for 64-bit support. The community generally acted like it was a cure all. Well, we finally got it last year, and as they told us along, it did indeed help with caching, memory leaks, etc. It enabled the more efficient use of resources, and more STABLE framerates, but it did NOT provide a substantial BOOST in framerates. The same basic notion applies to CPUs.

DCS, by it's nature, is extremely intensive on the CPU end. Utilisation of more cores might help with STABLE framerates where possible to use them, but is not necessarily going to result in some massive performance increase. Those calculations run the way do because they have to, and whether you've got 2 cores or 40 cores isn't going to change that.

As time goes on, especially as Combined Arms becomes a more central figure in the game, they'll inevitably have to improve the AI. When they do, you'll very possibly see AI functions split off to do their own thing so they aren't a burden on the other functions and can support.

A very common thread in most (not all) performance complaints revolves around people raging about online performance. There are two factors that must be kept in mind on this note:

#1 The server itself and ITS hardware. I played with some guys renting a relatively low power dual core, 2 something ghz server. Not surprisingly, it was "underwhelming". A more powerful server will yield better performance for everyone involved.

#2 The mission itself and ITS complexity. The more mods and scripts you add, the more background load there may be, particularly where you're relying on the competency of the person creating the mod or script in question.

I have seen 3d models with 60%+ of their geometry "hidden" inside itself, but of course the game still renders all that crap even if you can't see it. That's the fault of whoever designed the model, and the fault of whoever was stupid enough to put it on the server.

I have seen poorly written scripts. Do you REALLY need to ping the server 20-30 times a second?

I have seen overloaded missions to make them appear "alive". I played with a Arma clan that scattered hand placed, permanently active AI, even entire towns built from scratch all over the map. WE. NEVER. WENT THERE. All they did was drag the server down.

I could go on with more examples, but basically a poorly run server is apt to have one or more of those things, and probably some I didn't list. End result? Server runs like crap for you. No amount of cores, bits, hurtz, or anything else will save you if you're playing on a server run by an idiot.

DCS has been multicore all along. It uses two primarily, one for sound, and the other for everything else. Some CPUs may dynamically shift load between various cores on the fly, but that is not the same thing as using multiple cores simultaneously.

with all due respect, did you even take the time to read the thread? 8 threads under more or less equally high load, is NOT the result of windows dynamically shifting load around.

sure, some people don't see more than 2 cores utilized and that could be for various reasons, but even if you have 2 cores on high load on a modern intel cpu, than there is more going on than just sound-calculations.

from all the evidence in this and other threads, it is obvious, that DCS utilizes many cores for tasks related to the rendering-pipeline. an educated guess would be the fetching/preperation of speedtrees, but maybe even more.

it is highly unlikely that the high cpu-load some users experience is from bad code, as one would expect a fatal exception in such a case.

the reasons for NOT seeing high load or even load distribution however, could be a bug, that prevents multithreading to higher degrees. also the people that reportet only 2 cores being used, did not report a suspected bottleneck by the cpu, so it is possible, that there was no need to spread the load further, since the two active cores were feeding fast enough.

please also check the other threads about performance in 2.5 and don't argue against the facts, solely based on your system performance.

of course it would greatly help, if someone from ed could qhikcly chime in and tell us about the state of multithreading and what behaviour to expect. that would help in optimizing the game and could lead to better bug reports, if a systems poor performance was indeed caused by bad/buggy code.

Check out some of the thread's I posted in, back 1-2 yrs ago, not sure if it's still relevant tho, it was "2 cores" with only audio being on the second core, the gfx-draw

I'll redo my tests for 2.5 obviously, but I'm waiting for release version.

But you have the DCS community manager in one of the interviews a year ago saying "That will change" when being asked about multi-core - however that is still not clear whether he had Vulkan API in mind which is about taking the draw call load off the CPU, not necessairly using more CPU threads.

Since I was already somewhat into programming/hardware I made threads about this as well but then quickly realized that some tasks just can't be parallelized because of their nature by default, or they're just hard and if you do it, you would need linking across CPU cores and some people say that linking costs the benefits you get from parallelization so you get back to square one (not sure how much)

In those threads I made there were devs responding including other staff, I'm busy right now, I'll pull up those old thread later to mention when I post my new tests, but the new tests are going to be completley different setting, win10 and a SSD, no more HDD and win7 for anything DCS.

While Vulkan API would enable better multi-threading, DX11 has it but I've looked into it and people seemed to say it's half-assed. Whether DCS can use this is another question, most probably not, but what DCS would get is that the draw call and driver cost will go down on the existing threads it is using.

So Vulkan improves single-thread performance just by it self without you doing anything to the CPU code or the programmers having to do much engine optimizations around CPU.

Because it lower's the cost the CPU workload that has to be done to feed the GPU:

In this example, presented march 2017:

A bit higher Preparation

Lowers Drawing

No Driver Overhead

Very low Draw Call cost

But the performance of these bullet points depends on the effort put into it, because it's a new API, developers barely learning with it, let alone having well crafted optimizations ontop, so at first it may not be as fast as the hype out there sounds, but the hype is genuine because it's about the potential, not the transition period.

The biggest thing is draw call cost, because, you will not have FPS drops anymore from viewing all of those trees when flying low if you struggle now, and you won't have

Or have it another way, the amount of units (simple missiles/effects/debris/shells/birds/airplanes/structures/infantry/vehicles/smoke segments/clouds/trees/brush/weeds) on screen will have little effect on performance, if you have 80 FPS, you'll be keeping around 80 most of the time.

However, complicated computed things like sophisticated missile tracking/radar like S-300 AA should still equally take performance because of their physics simulation, Vulkan API won't make that part any better ofcourse, but that point of lag will be noticed a bit later so you would be able to use a bit more of them simultaneously, but not buy much, it's not comparable to draw calls, the amount of AA tracking missiles isn't even limited by draw calls in existing environment, it's limited by the simulation cost or the CPU -- With Vulkan you would recover FPS faster, you would notice the physics calculations in action and their end by firing some 100 S-300 missiles at a highly manouvering airplane and when one of the missiles destroys the target all the other missiles would lose lock and stop most of the hard calculating jobs which would make your FPS to spike back up, without Vulkan, the FPS spike would be smaller and variating in general as long as you would be viewing all those misslies and their smoke effects.

Now the guy behind that slide said that multi-threading would mean putting those sections in another thread, that helps, but you probably can't split the sections themselfs, the red one for example would still be on only one thread, now that's out of my league whether or not the red part is parallelizable at all in the known universe or if it's the nature of DCS being a simulator and might need to be non-parallelized in order to preserve realism accuracy.

Twistking, BitMaster, since your machines shows this effect and some (like mine) doesn't, maybe you can do us a favour and do an experiment. Take a mission that shows all your cores working hard and fly around a bit in it, then save the track. Run a monitoring app like afterburner and save the graph (not a screenshot of FPS or usage, we need to see a time series for each of your cores)

Now, change your CPU affinity for DCS such that there are 2 fewer cores and replay that same track and continue to do so until you're left with 2 cores only. Share all the graphs with us. You'll end up giving us graphs of 8 cores, 6 cores, 4 cores and 2 cores. So I guess the useful things to see would be Framerate, GPU usage, CPU1-8 usage. Allow the 2 core option to use any cores but core 0 as that's for windows and it will interfere and give bad results if DCS is forced onto it only.

Null hypothesis: Higher framerate and higher GPU usage as you allow for more cores.

Alternate Hypothesis: Negligible difference between 2, 4, 6 and 8 cores on GPU usage and framerate.

How about it?

My 8600 without hyperthreading gives great performance and 2 ccores are utilised between 80-95% and the others up to 50% so I guess something is making the other 4 processes work.

But yes unless someone comes up with a way to measure it all we say is anecdotal, one thing that is apparent is DCS loves fast processors :)

Twistking, BitMaster, since your machines shows this effect and some (like mine) doesn't, maybe you can do us a favour and do an experiment...

i can't unfortuantely, because i don't have 2.5 yet (waiting for stable). i refer to other user's experience though. both in this thread, and others.

f.e.: https://forums.eagle.ru/showpost.php?p=3381225&postcount=11

also my point is, that 2.5 caucasus has "better multi-threading" a.k.a. better load distribution than 1.5 caucasus and even your system shows this. i am pretty sure, that in 1.5 you would not have two cores at high load, but only one with the second doing some minor work.

i would not argue, that people should buy hexa- or octacore-cpus now, i'm just trying to understand how dcs utilizes multi-core since 2.5 (specifically on new caucasus), to better help people who struggle with system performance.

i myself run an old i7-860@3,8 ghz, which has surprisingly low single thread performance due to its age and despite the high oc. however it has no problem pushing the most demanding, modern games, as long as they are at least decently multi-threaded. so, it will be very interesting to see, how my systems handles 2.5.

1.5 caucasus runs well, but my fps are clearly limited by the cpu, who has one core at 99% and the the others doing close to nothing...

C'mon ED! This is obviously a very popular topic - look at the interest. It's so easy to provide an answer, the devs know what the situation is. Put us out of our misery please!

Twistking, BitMaster, since your machines shows this effect and some (like mine) doesn't, maybe you can do us a favour and do an experiment. Take a mission that shows all your cores working hard and fly around a bit in it, then save the track. Run a monitoring app like afterburner and save the graph (not a screenshot of FPS or usage, we need to see a time series for each of your cores)

 

Now, change your CPU affinity for DCS such that there are 2 fewer cores and replay that same track and continue to do so until you're left with 2 cores only. Share all the graphs with us. You'll end up giving us graphs of 8 cores, 6 cores, 4 cores and 2 cores. So I guess the useful things to see would be Framerate, GPU usage, CPU1-8 usage. Allow the 2 core option to use any cores but core 0 as that's for windows and it will interfere and give bad results if DCS is forced onto it only.

 

 

Null hypothesis: Higher framerate and higher GPU usage as you allow for more cores.

Alternate Hypothesis: Negligible difference between 2, 4, 6 and 8 cores on GPU usage and framerate.

 

 

How about it?

A: I do not have that much time to do all those tests, I have 4 kids.

B: I have done this before, I just did not record it but posted the screenshots in here last week or so.

C: by pure logic, how do you want to squeeze that much work into a lot less cores and expect the same outcome. Sorry, that is wasted time. The result of that test is somehow weaved into many threads in here were people get far less performance with the same 1080Ti.

Last night I finetuned my 2D settings, DS + 8xMSAA, visibility ultra, all maxed out. No less than 73fps, usually well in the 80s up to 90s, not above 100, but very very smoothj.

And oh boy, Caucasus looks really nice with these settings. Trees have zero flicker as far as you can see, lights...1 side of the mountain is bright and blinding, the other slope is real dark and shadowed. It really does make a huge difference in looks, that much that I keep 8xMSAA on for now.

Frametime benefits from more cores. You rather have 4 cores doing 50% then 2 cores doing 100%. 4 cores need exactly half the time to do the work, the data is available in half the time vs. 2 cores that need a full 1sec at xGHz to do the same work. There is no magic or believ in this, this is elementry school math.

DCS takes 2, DX11 afaik can take up to 4 ( maybe more ? ), so this fits just nice. Put more work on it like VR-API, Streaming, Recording, etc.. and you directly impact your DCS throughput. If it matters is a different story and does depend on how much you add to a certain given load in relation to max capability. Knowing that max capability will let your frametime suffer.

I wish this CPU had same speed just 2 cores more, as a reserve. Imho, 6 cores are no waste for DCS, I would really consider 8 if they were available at those 5+G.

Yeah. like I said, it looks like some asset loading is taking place in parallel. the game loop and graphics calls, AI, FMs are still single threaded i.e. more cores doesn't give more fps.

 

 

Sent from my iPhone using Tapatalk

I hope the asset loading thing would stop interfeering the engine, if the asset can't be retrieved in time it should just load a fallback dummy in order to avoid stuttering, can retry loading that asset on a later call.

Or at least it won't be noticable on my refreshed setup with a fresh Win10 and a new mid-level SSD (mid level these days is now pretty much max Sata3, comparing to all those NVMe's)

On another note, did any of you people have power saving features disabled in BIOS? You should try disabling all of them to prevent possible CPU clock from jumping up and down in the middle of the game.

i can't unfortuantely, because i don't have 2.5 yet (waiting for stable). i refer to other user's experience though. both in this thread, and others.

f.e.: https://forums.eagle.ru/showpost.php?p=3381225&postcount=11

 

also my point is, that 2.5 caucasus has "better multi-threading" a.k.a. better load distribution than 1.5 caucasus and even your system shows this. i am pretty sure, that in 1.5 you would not have two cores at high load, but only one with the second doing some minor work.

 

i would not argue, that people should buy hexa- or octacore-cpus now, i'm just trying to understand how dcs utilizes multi-core since 2.5 (specifically on new caucasus), to better help people who struggle with system performance.

i myself run an old i7-860@3,8 ghz, which has surprisingly low single thread performance due to its age and despite the high oc. however it has no problem pushing the most demanding, modern games, as long as they are at least decently multi-threaded. so, it will be very interesting to see, how my systems handles 2.5.

1.5 caucasus runs well, but my fps are clearly limited by the cpu, who has one core at 99% and the the others doing close to nothing...

Yes I used to see that as well, I am not sure why but latter 2.2 and now 2.5 seems to use more cores. This could be anything from wishful thinking to DCS code and drivers/oculus software for me. however DCS seems to use mostly 2 real cores at low utilisation and one virtual core to 90 to 100%

Frametime benefits from more cores. You rather have 4 cores doing 50% then 2 cores doing 100%. 4 cores need exactly half the time to do the work, the data is available in half the time vs. 2 cores that need a full 1sec at xGHz to do the same work. There is no magic or believ in this, this is elementry school math.

See, this is where your assumption is wrong. If all the things that had to be done between frames could be done faster on multiple threads, then this would be true, but it isn't. Look up Ahmdal's Law, it gives you the maximum speedup for parallel calculations. Effectively, the speedup is limited by what percentage of the work can be done in parallel, and in DCS there's a lot of things that can not be done so. However, I don't dispute that a lot of things should be possible and currently is not.

I would look at some of your other assumptions too, they are also in error. Parallel software is not quite as simple as you may think.

On another note, did any of you people have power saving features disabled in BIOS? You should try disabling all of them to prevent possible CPU clock from jumping up and down in the middle of the game.

Can the same be achieved by setting 'Minimum processor state' in the 'Processor power management' section of the power plan options to 100%?

No. You need to disable:

• Intel Enhanced Halt C1E
  
• Intel EIST (Enhanced Intel Speed Step) (AFAIK this one is not required as long as OS powerplan is set to 100% and doesn't change)
  
• Intel Thermal Monitor (TM,TM2,TM3)
  
• Intel C-States
  
• AMD Cool & Quiet
  

Motherboard:

• ASUS TPU
  
• ASUS EPU
  

If you have Turbo Boost gimmick, you can disable it and manually "overclock" to the Turbo Boost clock.

All of these functions ontop of each other being default settings produced erratic behavior in the clocks on my PC under Win7, at least that's what CPU-Z and other utilities reported, definitely didn't look healthy.

I think I still have IntelSpeedStep enabled, it doesn't do anything by it self, it enabled support for OS powerplan configuration, which I set manually when I go idle, otherwise full power.

EDIT: Now that I'm thinking about it, It's true I don't know if IntelSpeedStep option really does something on it's own behind scenes, it only means it doesn't affect the main clock that you get to see, as long as you keep OS from doing anything with the powerplan, setting minimum to 100 and max to 100 turns of OS automation.

Ofcourse, the power draw isn't the same as if you loaded the , the amperes it takes is much lower when a CPU or any PC component is idle even if it's running the same clock all the time, lowering clock and/or voltage is going to decrease power consumption further, the whole power consumption thing is a huge marketing fad so don't fall for it as they're making it seem like it's some huge thing.

I metered everything with a power meter, the watts for the whole PC were down to 150W when idle from 350W with maximum CPU core clocks, then I lowered the CPU down to 30% via OS powerplan (not sure in which C-State the CPU fallen to) and the Clock was around 1100 MHz from 4000 MHz, and the watts only came down to something like 120W, 30-40 watts, not that much at all, well below my expectations.

I use batch files to do this on Win7 ... probably doesn't work for Win10 ... Forgot to update these, good that this thread reminded me now.

@echo off
echo.
echo.
echo.
echo ///////////////////////////////////////////////// [color=Red]WIN7 ONLY[/color]
echo ********* Setting CPU Speed to 30% *************
echo /////////////////////////////////////////////////
echo.
echo.
powercfg -setacvalueindex 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c 54533251-82be-4824-96c1-47b60b740d00 893dee8e-2bef-41e0-89c6-b55d0929964c 30
echo ****** Minimum set ..
echo.
powercfg -setacvalueindex 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c 54533251-82be-4824-96c1-47b60b740d00 bc5038f7-23e0-4960-96da-33abaf5935ec 30
echo ****** Maximum set ..
echo.
powercfg -s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
echo.
echo.
echo //////////////////////////////////////////////////
echo ***************** Finished ! *********************
echo.
echo.
timeout 2
exit

EDIT: This could work on Win10 since it doesn't use guids: http://fireswordblog.blogspot.si/2013/04/making-bat-files-to-switch-fullreduced.html

EDIT2: CORRECTION - NOT C-STATES - BUT IT'S THE INTEL SPEEDSTEP THAT ENABLES OS-POWERPLAN TO CONTROL CLOCKS

[url=http://fireswordblog.blogspot.si/2013/04/making-bat-files-to-switch-fullreduced.html][/url]

see this image. Barely using the 8 other CPU threads.

 

this guy "complains", that load distribution is not even enough, while some others still insist on DCS being single-threaded for rendering...

His graph shows one core working hard and the rest not, which supports the single threaded hypothesis. You and bitmaster claim that rendering is happening in parallel so its up to you to prove it. I told you exactly how to do it. BitMaster copped out of the experiment so now its up to you to prove you are right.

His graph shows one core working hard and the rest not, which supports the single threaded hypothesis. You and bitmaster claim that rendering is happening in parallel so its up to you to prove it. I told you exactly how to do it. BitMaster copped out of the experiment so now its up to you to prove you are right.

oh, i never claimed rendering being parallel. i don't think that you would need to split the main rendering pipeline in multiple threads just to call it "multi-threaded".

my guess has always been, that the speed-tree preperation was multi-threaded. i could also imagine that data-streaming is seperated...

oh, i never claimed rendering being parallel. i don't think that you would need to split the main rendering pipeline in multiple threads just to call it "multi-threaded".

 

my guess has always been, that the speed-tree preperation was multi-threaded. i could also imagine that data-streaming is seperated...

That would make a LOT of sense, i.e. that a sub-section of the game (e.g. the part controlling the flight mechanics) might be running on a single core, whilst maybe the graphics are now spread across cores and/or threads.

I did find the graph interesting regarding how roughly half of the threads were running a "bit" higher than the others, almost as though the workload is more optimised for cores, rather than threads.

Ref the Speedtrees tech, do we have enough info from comparing CPU loads within firstly say Normandy to the Cauc to conclude that the performance in 2.5 appears to be similar or dissimilar? My own experiences on comparing results across different maps were that they were similar.

For all of the above, it's a bit of a moot point as we're (well certainly I) are/am not game graphical developers, and we're unlikely to influence it.

It is however an interesting point to understand, as it has significant implications for the optimum future hardware choices for DCS, ie. do we go for the fastest clocked CPU (Intel at the moment), or the most cores (AMD at the moment)? Based upon the limited understanding we have right now, feels like the ball might best sit with AMD right now with one of their 8 core CPUs.

I use Project Lasso and set it to single core, get a much smoother better performance at 4K, micro hitching when shooting down KA-50's is gone which is awesome.

Setting it to CPU affinity tanks performance.

Quick Tutorial:

Load the software while in game, alt-tab to 'Active Applications in Lasso and right click on DCS and set the priorities and cores there, it then boots when you load Windows automatically and runs at those new settings, think I will purchase it to support the devs.

Basically both games have high levels of physics calculations, both are simulating a lot of background calculations related to the environment, ballistics, flight models, AI (the reason the AI is so flakey, for example, is because it has to be designed in very general terms so it can function in any situation at least to a basic degree... It can't have a lot of hardcoded functionality, because it wouldn't work in an "open world")...

 

BY THEIR NATURE, most of these calculations have to be performed on the same core, especially anything even remotely tied to physics. The flight model, the environement, ballistics, aircraft systems, etc, etc, ALL have to be on the same line together or it won't function. You'll get the physics equivalent of de-sync on your monitor causing screen tearing.

You are talking complete and utter bullshit, please stop trying to repeat the half remembered ramblings of excuses from Bohemia Interactive.

Physics is NOT a good example for potential multi-threading speed ups, its THE example potential for multi-threading speedups. The same reasons we compute polygon transforms for rendering your games on the GPU (For sake of this point, you can consider them a multi-thousand core processor) is the same reason hardcore physics calculations, like used in movies, science applications etc are all done on the GPU, or more to the point multiple GPUs, which are basically what supercomputers are primarily made of these days.

Physics calculations are multiple, straightforward non-branching logic math solutions which have little to no potential to encounter the race conditions and data locking problems (that is the justification for why games cannot be multi-threaded) because they are just expressions of Force = A * B^C - D, as long as don't depending on trying to update that outcome for use in *THIS* frame, and only use the updated value *next* frame.

Considering games generally process the world in frames, usually only using the previous frames data for calculations, the data is static, you don't consider anything that happened during the execution of the current frame because than you'd need to worry about order of execution, just like in multi-core execution even if your only using 1, it'd massive headache. So you take the physics force being calculated like speed and you apply your forces like drag, acceleration, you move on, and you do this a couple thousand? Hundred thousand? Million times? You do this in parallel. You can do this in parallel a couple thousand times over on a modern GPU if you want to, because it you don't need the "if this then do that" logic that the CPU can provide, you just doing A * B^C - D and writing the outcome to a new location.

But if you do need to do this on a CPU, and even in a existing older designed application like DCS (Don't get me wrong, rewriting a old code base to FULLY integrate threading isn't something to be taken lightly...) you can be single threaded all you want, hit your physics part, and then go "I have 100,000 physics calculations to do, and 4 threads to do them on" 100,000 divide by 4, core 0 does 1-249,999 core 2 does 250,000 to 499,999 etc... Everyone report back when you've done your share and we'll continue in the main thread after wards.

And to be honest I'd be VERY surprised if this isnt already done this way in DCS already because I don't think you understand the scale and absurdity of what you're suggesting how things operate... AI is another example of a workload that can be divided, assigned, processed, and then collected back into a single thread.

This kind of wide, narrow, wide, narrow, design isn't really desirable because its bottle necking, and a single core has to prepare the work and handle the completion of many, and its very possible DCS is hitting these kinds of bottlenecks. But for a existing application where the complete rewrite necessary for a 'down to the inner core' threading support, it offers perhaps the only way of achieving any kind of comparison in terms of performance.

PS. To the guy above me praising Process Lasso, fun fact as of the last time I was naive enough to be using on my old dual core Althon64 a decade ago. All project lasso does is set CPU affinity and process priority, and close applications/services for you... Hate to break it to you but applications really don't and shouldn't have level of authority over other applications, its handled at the OS level ... So they don't...