Does it make sense to consider the hardware number of threads in a game engine?

Question

Programming

I am writing a game engine.
In short, there are modules, and modules have workers, this can be the calculation of bots or other game logic, interaction with the server, etc.
Some of these workers can be parallelized (on the CPU).
Does it make sense to take into account the number of hardware-supported threads (for example, this value is en.cppreference.com/w/cpp/thread/thread/hardware_c... ) or do they make as many as you can and rely on the OS?
Will there be a big overhead when switching contexts?

Answer 1

The default thread pool contains a number of threads equal to the number of hardware thread cores . This pool has an input queue (lock-free) where incoming tasks are submitted. When the CPU is underloaded, the queue is empty. When all threads are busy, the queue grows.
This is a recipe for maximum performance, except for the case when, according to the conditions of the task, it is critical that a large number of tasks be executed in real parallel (for example, the tasks themselves are long, and there is no possibility or desire to split them into subtasks), then all tasks should be decomposed into separate OS threads .
Incidentally, the task queue on the thread pool is exactly how multitasking is implemented internally by the OS. Only here the OS threads themselves are tasks that are queued. The difference in performance is explained by the fact that switching tasks in userspace is easier (hence faster) than switching OS threads.