Shivansps said:
No, i got it right, if the game needs to identify anything means its not using the new model of "just create threads and forget about them", creating threads and letting the O.S. scheduler do its job, thats the new and current model. If you do that its the same if is 4, 8, 16 or 128 cores, or if it runs on Window,s Linux, Android or console, your code should aways run right, as long you dont run intro main thread bottleneck. If you need to idenfity CPU then you are doing it the old way.
The games does not need to read ANYTHING AT ALL. Just create the threads you need and keep on going, is the O.S. job to do load balancing and thread affinity.
If it needs to read core count thats because it runs on a outdated programing model.
This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly, and i think you will have a hard time finding the "first check how many cores you have at runtime" on any programing guide. F1 2016 is using old style programing if it needs to know how many cores it has avalible. /period
This is wrong, and you've repeated this misinformation multiple times across multiple pages.
Threads aren't free. If you have more threads scheduled to run than processors that can run them, the OS has to context switch, where it has to stop the thread, save the memory that it's using, evict the registers and cache that it's using, load a new thread, and so on. All of this takes CPU cycles away from processing the workload.
In addition to context switches, threaded workloads typically have some type of shared memory where writes to it need to be controlled (so one thread doesn't overwrite the work done by another). This is generally done with some type of lock, which has to be coordinated among all of the threads. The more threads sharing a data structure, the more cycles the OS has to spend managing access to those data structures.
Every programming language that supports multiprocessing has some type of function or method to discover at runtime how many processing cores the machine has,
specifically so that the application can assign an appropriate number of threads. This has been the case for as long as SMP systems have existed, and it continues to be the case today.
But hey, if you have a technique that allows an application to spawn an arbitrarily large number of compute-bound threads on a machine with finite processors/memory without consequence, please publish it and collect your Noble prize.
Shivansps said:
If you have any doubt open the resource manager and take a closer look at the number of threads a game starts howdays.
The dozens of threads that an application spawns are primarily threads to manage I/O operations (e.g., file access, listening for events from inputs devices, network access, sound, etc.). These are spun off into their own threads so that the main thread doesn't block waiting for I/O. It doesn't really matter how many of these threads there are (within reason) because they spend most of their time waiting, and the OS can schedule other threads to run in the meantime.
You wouldn't run compute-intensive threads in this manner for the reasons that I described above.