Is it always good for performance to create a thread?

Viewed 229

I've recently started trying to use threads with std::thread, and I was wondering if there are any downsides to using threads (specifically, in c++). Are there situations where adding more threads would decrease performance? For example, if I'm creating multiple new threads that are meant to each run a server object listening for incoming data, is it bad (performance-wise) to create a new thread for each one of those server instances? Why/why not?

2 Answers

It can really hurt performance to create too many threads.

If, for example, you have a thread for each server instance, then you cannot do work for one server instance and then work for another server instance without switching threads. There is a cost associated with switching threads.

Another problem is when two or more threads try to access the same collection of information. This can cause contention which can slow the entire system down. Modern CPUs have multiple cores with limited inter-core resources. Threads fighting over the same objects can saturate those inter-core buses.

You definitely want to avoid designs that can't do "more work" without creating more threads. If you have three servers and each have a thread, that's fine. If you have hundreds of clients and have a pool of ten threads that serve them, that's fine. If you have a few special things to do (like monitor for clock changes) that are best done by their own thread, that's fine too.

But generally, a server with a lot of work to do should apportion that work over a fixed collection of threads. The number of threads in that collection should be based on things like the number of cores the system has, the number of I/Os that can usefully pend at the same time, and the amount of unexpected delays (such as hard page faults) expected.

  1. Creating a thread can be expensive. If you have very small amounts of work to do, it might not be worth it. This article's measurements show that creating a thread may take ~milliseconds.

  2. Threads are an abstraction over CPU cores, and while you can basically create as many threads as you want, the number of available cores is fixed. After a certain point, you will get no additional speedup because the hardware has no more to offer, and you may actually slow things down by introducing more bookkeeping and communication overhead.

  3. Even if you were not limited by hardware concurrency, most workloads are not completely parallelizable, and you'll be limited by the non-parallel parts of your problem. See: https://en.wikipedia.org/wiki/Amdahl%27s_law

Related