I recently started working with C++ again and wrote a simple test application that finds the best path through a matrix of integer values. To improve the performance of this application I implemented multi-threading using C++11 std::thread.
unsigned int threadCount = std::thread::hardware_concurrency();
std::vector<std::thread> threads;
for (unsigned int threadIndex = 0; threadIndex < threadCount; threadIndex++) {
threads.push_back(std::thread(&AltitudeMapPath::bestPath, this, threadCount, threadIndex));
}
for (auto& thread : threads) {
thread.join();
}
As of right now I simply determine the total number of available threads and execute my test for each thread. This has worked fantastic but it got me thinking...
Is it bad practice to try and use all available threads for a given system? Beyond just this simple example do production level applications, that are multi-threaded, try to grab as many threads as they can (or as the problem will allow) or should I not be so greedy?
Thanks,
Thus software threads tend to evict each other's data, and the cache fighting from too many threads can hurt performance. A similar overhead, at a different level, is thrashing virtual memory. Most computers use virtual memory. Virtual memory resides on disk, and the frequently used portions are kept in real memory.
We are familiar with the types of problems that arise from using threads: mutal exclusion, deadlocks, priority inversion, and blocking inappropriately. We have developed tools to work around these problems, but we have been unable to eliminate these problems from our software.
A single CPU core can have up-to 2 threads per core. For example, if a CPU is dual core (i.e., 2 cores) it will have 4 threads. And if a CPU is Octal core (i.e., 8 core) it will have 16 threads and vice-versa.
Increasing the number of threads doesn't increase performance capacity (as you pointed out) but it also drains CPU time by giving the kernel more work to do. Basically, there are diminishing returns on threading and doing too much causes performance retrograde.
I don't think there is a single correct best practice, how many cores an application should use depends on the user's preference. There will be cases where a user wants an application to run as quickly as possible, and there will be cases where a user would prefer to multitask and not have an application bog down the machine.
I faced a similar problem and decided to make the number of threads configurable so that the user could choose between speed and cpu resource availability. I can think of at least one application that uses a similar configuration, so I don't think it is uncommon to let the user choose.
If you are forced to pick for the user, I would suggest using the number of hardware cores - 1 to free up a thread for the user to perform other work on.
Also keep in mind that std::thread::hardware_concurrency()
is intended to be a hint and is allowed to return 0 if it can't make a determination.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With