My experience (on Linux) is that: - if you have lots of short-lived cpu-intensive tasks then a pool with one or two threads per cpu core (depending on how SMT

My experience (on Linux) is that: - if you have lots of short-lived cpu-intensive tasks then a pool with one or two threads per cpu core (depending on how SMT works for you on your hardware) works well - if you have lots of long-lived cpu-intensive tasks then just give each task a thread and let the OS schedule them - if you have lots of io tasks, don't use threads; async io is a massive win - if you have lots of io tasks on aws then you have to have high core counts even if they all sit idle because of the way credits are divvied up; even with massive brought iops you don't get good io on aws compared to, say, the cheap laptop you do dev on ;) I am so so so tempted to go into a particular mysql storage engine that my day job often relies upon and move it from one-thread-per-core to async io. Obviously that's a pipe-dream but the wins would be massive (on linux, on aws blah blah) Having made this list I can see there are so many cravats that I'm not sure generalizations get anyone very far, sadly. Its like the same server software has really different performance characteristics on different cloud providers vs dedicated hardware etc etc.