response to cpu thread scaling
You do realize it's impossible for all code to be run at the same time(efficiently) so by splitting it to multiple threads it is implied separate code is running on a new thread but they still report back to the main thread right? The whole idea behind multi threading is to offload jobs to separate threads because the first thread needs help.
1.You have five jobs to do. You need to start working on all of them right now.
2. Each job is a thread.
3. You are the processor.
4. Spend a little bit of time working on each job and then move to the next one, making sure you give attention to all of them.
5. If you have more people, a job can only be worked on by one person at a time.
Since each person can work on a different job, more people can get all the work done faster, if you have more than one job.
In case you don't understand how it works, and yes I pulled this off the stackexchange... to tired to think of an example.
Using task manager is fine. It's not the most accurate as using the IDE to report in real time but it's close enough to show it's doing something.
I'm very aware of how CPU's work including multi-threading and hyperthreading. What I'm disagreeing with is the comment about how "well threaded" the game was because it supposedly can use 16 CPU threads.
The only evidence to back that up between 6-core and 8-core usage is a jump between 61 and 66FPS on the minimums with no average FPS increase. And again a 6% FPS increase between 4-core and 8-cores.
If jumping from 6C/12T to 8C/16T had caused an average FPS jump then I would have agreed it can benefit from 16 threads in theory (though I'd still disable SMT to see if 8C/8T then showed the same result).
Two separate branches of code do not inherently run better if they end up on two separate CPU cores BTW. You can get the EXACT same results if both threads run on the same core. Or not. It simply depends on the software and CPU combo in play. Including the OS.
And no it is not "implied" that separate code branches end up on separate CPU threads. The program (i.e. game) and OS would need to work together intentionally to ensure that's the case... in fact, since isolating the main game CODE THREAD to its own CPU core while not allowing any other code from the OS or same game on it (including via hyperthreading) is still not common I can only assume thread management still leaves much to be desired.
*back to the first part of your statement "You do realize it's impossible for all code to be run at the same time(efficiently)" which I've mostly answered you've actually CONTRADICTED yourself... if two branches of code were running at the "same time" they would need to run separately on two DIFFERENT cores. The alternative is that they run on the same core and that the CPU just jumps between the code of each thread.
(I'm nitpicking but "same time" means same moment in time. You appear to have meant "on the same core" but it's not the same thing as a core can only run one branch of code in a specific moment regardless of hyperthreading capability)
Again there's absolutely no inherent reason that running two threads of code on two, separate cores is faster than the same two threads of code on the same CPU. There are situations where it's BETTER they both run on the same core and situations where it's better to run on separate cores. (an example of "better" can include disabling an entire CCX to force all threads to run on the four cores in the same CCX).
I'm a bit off topic but realistically the best way to analyze THREAD UTILIZATION is to run tests which they did which again showed very little difference between 6 and 8 cores. If you want to say jumping from 61FPS to 66FPS in the minimum FPS shows the game can take advantage of 16 threads then fine.
My main point initially was to discuss how TASK MANAGER showing all threads being utilized doesn't mean a program can actually take advantage of them. Even a single-threaded program might thread migrate across 16 threads showing maybe 10% average CPU usage (add a few percent for OS usage).
