I think you develop a _"hmm, probably worth trying"_ sense for it too. The javascript/browser Canvas is a good bet, e.g.; here, Workers can do their best to update data for the next AnimationFrame (itself async and best-effort 60fps), but if they miss an update time point, the main / interactive thread doesn't have to hang (as it would if you tried calling out from the AF) and the browser stays responsive. Games that work fine in one thread on current phones then work on the (numerous, and actually likely to be multicore) hand-me-down's that are still out there worldwide.

It's one I made myself. Once I get some time to optimize it I'll post it up to the user files.

@@TheOpsCenterByMikeSolyom Great job! It looks great! I may need to try and make a Lackland one.

I took a quick screenshot of that part and posted it here: drive.google.com/file/d/1HnrBnjAUaVqzz0KVoQUXMV7Sx1Z1QG7g/view?usp=share_link

There's no way for anyone who doesn't have access to the source know where the biggest gains can be had. But you are right that dividing up the threads further will provide additional gains. In one of the newsletters ED did say that the two thread split was just the first iteration and more would be coming later. Hopefully, we won't have to wait years to see it.

@@TheOpsCenterByMikeSolyom fingers crossed, as ever 🤞

Thread is a logical concept and Core is a physical/hardware concept. A thread is an ordered list of tasks created by a program, and a core is the actual worker to do the tasks. In multiple cores setup, each core will be assigned a bunch of threads to work on. If there is only one thread for the given program, only one core can work on it. To parallel the program, you will need to logically divide the tasks (into multiple threads), and physically have multiple workers (multiple core).

Threads are part of cores. Each core has X amount of threads.

It depends on the application. In a truly single threaded app, yes the extra cores would be sitting idle. But since a lot of this channel's viewers are into DCS, let's use that as an example. Before this year's "multithreading" patch DCS actually did some work done on a separate thread. You'll hear people refer to it as the "sound thread". Now it was still pretty easy to overwhelm the entire DCS process because so much work was done in one overloaded thread. But the "multithreading" patch helped to split up that one mega thread and spread that load around. So in the case of DCS it would not have been a waste to use a multicore processor. It's just that it didn't help very much before the "multithreading" patch. A lot of DirectX games can also get a minor benefit as well since DirectX does some very limited automatic multithreading. But for a significant boost you need a purpose built multithreaded application. Hope that helps.

​​@@TheOpsCenterByMikeSolyomhow do you know all of these things together with all the rest of your knowledge? It's very impressive. Like im which field does one have to know abour radars, multi threading etc.

@@mYOwngUn I was a programmer in the USAF. That gave me the opportunity to see a lot of the neat things the Air Force has and then write software for it.

@@TheOpsCenterByMikeSolyom thats awesome! Thanks for letting me know