DCS Newsletter discussion 2nd December 2022 - DCS 2.8 Multithreading | SATAL 2023

[trevoC]

1 hour ago, Dragon1-1 said:

I wouldn't say infinitely, but you're trying to distribute load across 8-16 cores of a gaming CPU, not a 64+ core threadripper. My friend has one of those (for heavy lifting in theoretical chemistry), but it's a giant, specialized piece of kit, a power hog and single core performance kind of sucks, anyway. Potential for scalability across cores is all over the place in AI (units "think" mostly independently), physics (each aircraft in flight is a largely isolated system) and graphics (many well-explored ways to scale that).

To be fair, the context I was responding to "infinitely" was within the obvious bounds of whatever processor you are using. This would obviously be the upper bound. I guessed infinitely was used to mean the entire processor and more cores if given.

[Dragon1-1]

11 minutes ago, trevoC said:

This would obviously be the upper bound. I guessed infinitely was used to mean the entire processor and more cores if given.

What I meant was that you're usually going to run out of cores before you run out of potential threads. There is a limit on how much things can be parallelized, so it won't just take an any number of cores you give it, like a server farm would, but it would comfortably give any reasonably sized gaming CPU enough to do.

[SkateZilla]

19 hours ago, trevoC said:

I agree with many of the items you have stated in your post skate, but unfortunately the definition of multi does not apply to multithreading which is actually one word.

Although I don't develop games (should say by trade as I have and do develop games for fun), I have been building multithreaded applications almost as long as I've been coding in general (over 30 years).

In this context, splitting logical pieces of codes (or their loops) into separate processes to run on separate processors is not multithreading. 

multithreading in the context of programming would be a single logical piece of code (the graphics loop as it was referred to for instance) being able to use multiple processors, allowing it to scale.

What DCS is doing now and looks like this announcement is mentioning is multiprocessing. Separate logical process executing on separate processors. Very different than multithreading because obviously you cannot scale any of these independent processes past 1 processor. The worst offending process will always be your bottleneck. Multithreading does not have this problem. A multithreaded process or application does not have the same type of bottlenecks. It does introduce a crap ton of problems and other issues, but I digress.

All of this is welcome, and noone is complaining from my end anyway, just discussing the difference and setting expectations.

As I have mentioned earlier in this thread, sending the draw calls direct to GPU (bypassing the CPU) with DX12 or vulcan will probably see more gains than multithreading anyhow.

That beings said, this was only an attempt to clear up the use of the word in this thread thus far.

Reflected's campaign is the one I was thinking of.

It will probably be the first campaign I will re-visit (I paused it after I think mission 5 because of the slideshow I was getting).

So yes, this change will be welcome for this scenario. 

 

 

Multithreaded Application: A program execution that allows for multiple threads to be created within a process, executing independently but concurrently sharing process resources.

They are indeed split into threads, not processors (or Processes if that's what you meant)..

Currently:
DCS.EXE would be the process, and the code paths for SIM-Calculations and SIM-Render Instructions use the same CPU Address Space, with DCS-Sound having it's own., 

DCS MT would change this to:
DCS.EXE would be the process, and the Code Paths for SIM-Calculations and Sim-Render Instructions use separate and exclusive CPU Address Space, along with DCS-Sound Having it's own.

So the code paths are separated into separate threads,
meaning 1 thread does not have to wait for the other to complete before sending commands to DX11 API.
If you have 4,000 off screen AI Commands to process, it should not hold up Render instructions to DX11 and the GPU,
This is what's happening in LARGE missions.

There's definitely sync points and controllers/interposers between the threads to make sure they all stay synced, but a majority of the time, the Calculations of out of sight objects, Physics or AI Decisions do not effect the Render Instructions to DX11, and vise versa.

Having them each on their own Address Spaces eliminates the bottle neck of SIM-Calculations having to process before moving onto SIM-Render Instructions.

There's also no limit to how many different threads the SIM-Calculations would be divided into, The Newsletter says Main Threads, the SIM-Calculations thread, will likely be divided into Address Spaces of it's own for specific things, so again, one would not have to wait for another.

To which processors or cores those threads are assigned to remains up to either Windows Scheduler or the CPU Scheduler.
the Scheduler can put them both on the some CPU Core or split them, and it's up to the Scheduler and interposer function to keep them synced.

A Single Processor Core can process more than 1 thread per CPU cycle, even now at windows idle you're likely running 200+ Processes with around 3000 Threads total, depending on age of windows install.

Edited December 6, 2022 by SkateZilla

[Seabiscuit1985]

So we will have multithreading in 2025, great news 

[SkateZilla]

2 minutes ago, Seabiscuit1985 said:

So we will have multithreading in 2025, great news 

The Article clearly said 2023

[trevoC]

46 minutes ago, SkateZilla said:

They are indeed split into threads, not processors (or Processes if that's what you meant)..
30 Years ago, Multi-Core Processors didn't exist in mainstream, the First Dual Core CPUs debuted in 2005.

I've built Systems Starting from 286 16MHz to Current Tech.

I never said anything about multi-core Processors. I stated I've been working on multithreading my entire career (almost). That idea was around long before my work in posix and mainframe computers. (it wasn't a new idea when I learnt about it in books). I'm guessing multithreading pre-dates my work on my first computer by longer than I've been using computers.

A 286 16 (sounds like an IBM ps/2) was a pretty nice machine from where I started. In fact having a math co-processor was nice once upon a time in consumer pcs. Not sure that has anything to do with anything though. Sounds like we've both been around for a while. I remember being the envy on the block with an 8088 and a 4-color monitor. I believe that was my 3'rd computer and first that wasn't a hand me down.

Even in personal PC's Dual Pentiums were available before the dual Cores arrived. I had plenty of dual chips on board back in the day. (before 2005) Off the top of my head I believe 2000's era was Dual Pentiums. (I remember dual 386's I believe but never used one, dual or quad etc... processors go way farther back though, just not on the same m/b, multi-bus connectors connected multiple computers together for penalization. I never saw these outside mainframes. In my era, the dual pentium 4's were the explosion of cheap office servers that were not considered dedicated server hardware within the industry. Every office in town no matter the size were buying these.)

A program that can use multiple cores does not necessarily make any of the processes multithreaded. In fact its usually not the case as targeting different cores with different loops or processes (not running processes as you have alluded I meant just for the record.) is much easier than creating a multithreaded application that can scale across any available threads.

DCS at present and as advertised in the announcement is the former as far as I can tell from the limited information. You could split an application up to use 40 threads if you like and still not have the scalability that multithreading offers. How many threads your CPU offers per core is irrelevant.

I think the use of certain words and the context in which I am using them is being mixed up.

Edited December 6, 2022 by trevoC

[SkateZilla]

4 minutes ago, trevoC said:

I never said anything about multi-core Processors. I stated I've been working on multithreading my entire career (almost). That idea was around long before my work in posix and mainframe computers. (it wasn't a new idea when I learnt about it in books). I'm guessing multithreading pre-dates my work on my first computer by longer than I've been using computers.

mis-read that part, which is why it was removed from my post.
I did have Dual Pentium II board at one point, But it had stability issues so I sold it and never went back to Dual CPU boards.
Even then Dual CPU vs Dual Core isn't the same, as they are on different substrate packages, and both have their own separate memory bank addresses vs Dual CORE has both on the same substrate and both have access to the same memory bank.
 

[trevoC]

2 minutes ago, SkateZilla said:

Even then Dual CPU vs Dual Core isn't the same.
 

I didn't say they were. Again, this entire conversation has digressed from a point I never mentioned.

[Seabiscuit1985]

3 hours ago, SkateZilla said:

The Article clearly said 2023

It's an inside joke among fans of ED, no offense. 

[freehand]

10 hours ago, Seabiscuit1985 said:

It's an inside joke among fans of ED, no offense. 

You have no need to apologize. 

[draconus]

On 12/4/2022 at 7:13 PM, SkateZilla said:

DCS as a Whole has 2 Main Bottle Necks: Sim-Calculations and DirectX11 API CPU Overhead, Which are very apparent in 2 Scenarios:
A. Large Scripted Missions with a lot of sim-calculations
B. Large Scenes w/ a lot of objects being rendered.

Would that put trees, Vegas, Marianas islands and SC (with crew) on the B case?

[schurem]

Yes

[TKu]

I think trees are already gpu & gpu accelerated

[5ephir0th]

1 hour ago, TKu said:

I think trees are already gpu & gpu accelerated

Of course are gpu "acelerated", the limitation on trees or buildings its not about its if both of them are or note a gpu thing, its due to a DX11 drawcalls limitation

[TKu]

vor einer Stunde schrieb 5ephir0th:

DX11 drawcalls limitation

I'm not familiar with DX11, but I think there should be some kind of instantiation implemented.

[USA_Recon]

On 12/2/2022 at 4:10 PM, NineLine said:

We really cant win, people demand news about stuff we give them news then they don't want news until its ready. There is no pleasing everyone, but we try.

We will not give out dates until its closer, so we didnt. We wanted to share progress news so we did. 

Why even give estimates that are this vague and open ended - that is what I’m saying - just leave it at giving status updates .  The progress report is a great news item - I’m not saying don’t give status updates.  If I’m not mistaken last year it was 4Q of this year - so …

Ie . Internal testing - so how is it going ? Are you seeing improved performance ? Better frame rates ? Ability to turn up settings with better performance ? Fixes the flashing loading screens ? Allows for objects drawn without pausing ?

That would be inspiring news to be worthy of making the newsletter 

“Next year” is a meaningless phrase that becomes a joke - anyone in this product knows this

[Dragon1-1]

FYI, the flashing loading screens is a SteamVR bug, not confined to DCS. Switch to OpenXR and it goes away.