In the current SOB 2029.1 play through, I've encountered a massive slow down when a mixture of USN SM-6s and PRC AShMs/ASBMs are in the air. Until this point, the scenario had been running smoothly in terms of performance. However, once USN SAMs began to be launched, the game slowed to the point where 1 second of scen time takes 20+ seconds of real time.
The background to the issue is that USN air defences were not firing until I switched "Engage Opportunity Targets" on; once I toggled that, dozens of SM-6s then launched against the PRC AShMs, instantly slowing the game down. I've confirmed that this happened on both my gaming PC, and my much less powerful laptop. In terms of the latter, the CPU usage rockets up to 100%.
At the starting point of the save, as well as the SM-6s and incoming AShMs (mostly YJ-100s), there is also a salvo of x36 DF-26 ASBMs inbound for the Ford CSG. These have not yet been detected by the Coalition side, but are visible on God Mode to the east of Hainan Island. These could also be contributing to the slow down, but even if I delete those, the performance didn't seem to increase noticeably.
20240211 - CMO SOB 2029.1 Missile Barrage CPU Usage.jpg (151.9 KiB) Viewed 609 times
20240211 - CMO SOB 2029.1 Missile Barrage Slow Down.jpg (539.88 KiB) Viewed 609 times
No, it's an entirely different thing. We looked at this earlier today.
The root cause is that some weapons (such as the SM-6s) had their WRA-range set to "NEZ". This forced the salvo creation to do a DLZ calculation each time it evaluated them for firing, regardless of other factors that may (or may not) block them from being used.
Fixed for the next update by restructuring the related code so that this DLZ/NEZ check is not made, and when they are indeed made they are cached as long as possible.
As a temporary workaround until the update, you should be able to resolve the problem by setting the culprit weapons' WRA-range to a value other than NEZ.
Dimitris wrote: Mon Feb 12, 2024 4:05 pm
No, it's an entirely different thing. We looked at this earlier today.
The root cause is that some weapons (such as the SM-6s) had their WRA-range set to "NEZ". This forced the salvo creation to do a DLZ calculation each time it evaluated them for firing, regardless of other factors that may (or may not) block them from being used.
Fixed for the next update by restructuring the related code so that this DLZ/NEZ check is not made, and when they are indeed made they are cached as long as possible.
As a temporary workaround until the update, you should be able to resolve the problem by setting the culprit weapons' WRA-range to a value other than NEZ.
This post from the MSFS Beta 15 thread I found interesting just around the multi-core discussion.
"I say this pretty much every time this topic comes up, but the sim is never going to max out all your cores. There isn’t some hidden reservoir of potential power that is untapped. Multi-core processors were designed to do multiple things simultaneously, not one thing faster. That kind of generational performance uplift went out with Moore’s Law, I’m afraid.
The multi-core design suits the average load for a PC, which is multiple processes running under an OS like Windows. For a single program like a game, you can only take advantage of multiple cores if you can split the work to be done up in such a way that it can be assigned to many cores simultaneously, and place each workload on a separate thread running on the least loaded core at any given moment.
Splitting the work up in the first place is the hard problem. Many computations rely on the results of previous computations in order to run. So you can put them on different threads, but computation 2 still can’t start until computation 1 has finished and its results are available. These tasks are sequential. They cannot be parallelised, so there is no performance gain to be realised from running them on separate cores.
The question is, to what extent is it possible to split up the work of running the simulation, generating each frame etc, in such a way that these individual tasks are non-sequential and so can be run on different cores simultaneously. I cannot answer that for MSFS with any accuracy, nor can I speculate on what the devs may or may not have done for 2024 (they specifically mentioned moving the aerodynamics simulation onto a different thread, but that’s all I’ve heard so far). However, I’m pretty sure that many tasks within the simulation will always need to be sequential, or at least partially sequential (you could do work on a different thread to save time on the main thread, but the result would still have to wait for the main thread to be ready, so you can still get bogged down on the main thread). We will likely see an improvement in 2024. We know they’re making performance a priority, and the devs have had time to re-design parts of the simulation to make them more amenable to being run non-sequentially. We may see a significant improvement on modern CPUs. But we’re not going to see a x10 improvement.
For 2020, I doubt any further truly significant performance improvement is possible, and AIUI SU15’s improvements are supposed to be with memory allocation and management, not multi-core use."
And thats with a multi-million dollar investment and hundreds of people programming. While MS gives a dev libraries to make the job a little easier, going to true all-out multi-core/thread is a VERY significant move. The move to 64-bit is most likely just a step.
