I have an application that accepts work on a queue and then spins that work off to be completed on independent threads. The number of threads is not massive, say up to 100, but
'Would getting smarter and managing the work load to keep the CPU below 100% get me further faster?'
Probably not.
As others have posted, 100 threads is too many for a threadpool if most of the tasks are CPU-intensive. It won't make much difference to performance on typical systems - with that much overload it will be bad with 4 threads and bad with 400.
How did you decide on 100 threads? Why not 16, say?
'The number of threads is not massive, say up to 100' - does it vary? Just create 16 at startup and stop managing them - just pass the queue to them and forget about them.
Horrible thought - you aren't creating a new thread for each task, are you?