15

Im using a thread pool to execute tasks , that are mostly cpu based with a bit of I/O, of size one larger than the number of cpus.

Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() + 1)

Assuming case of simple program that submits all its tasks to this executor and does little else I assume having a thread pool any larger would slow things because the OS would have to timeslice it cpus more often chance to give each thread in the threadpool a chance to run.

Is that correct, and if so is this a real problem or mostly theoretical, i.e if I increased threadpool size to 1000 would I notice a massive difference.

Paul Taylor
  • 13,411
  • 42
  • 184
  • 351
  • 1
    There is no such thing as a generalized 'optimum thread pool size', or an optimum anything else either. You have to try it and see. Test and measure. Not a real question. – user207421 Oct 18 '12 at 09:24
  • 2
    I knew someone would say that, but I think Ive clearly specified the usecase and Im trying to establish a feature of how thread pools work, the answers given below are more useful. – Paul Taylor Oct 18 '12 at 09:35
  • 1
    See these previous answers http://stackoverflow.com/questions/4049498/how-to-find-out-the-optimal-amount-of-threads/4050341#4050341 – Toby Oct 22 '12 at 08:39
  • 1
    See these previous answers http://stackoverflow.com/questions/4049498/how-to-find-out-the-optimal-amount-of-threads/4050341#4050341 – Toby Oct 22 '12 at 08:40

2 Answers2

11

If you have CPU bound tasks, as you increase the number of threads you get increasing overhead and slower performances. Note: having more threads than waiting tasks is just a waste of resources, but may not slow down the tasks so much.

I would use a multiple (e.g. 1 or 2) of the number of cpus rather than adding just one as having one too many threads can have a surprising amount of overhead.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks but don't understand your last line, surely using a multiple rather than just adding one would give more threads and hence more overhead. – Paul Taylor Oct 18 '12 at 09:36
  • 1
    if you have 9 tasks and 8 cpus, to get a fair scheduling, every cpu needs to be interrupted with a different task, or you get one cpu which has two tasks meaning the total time to complete them all is doubled. If you have 16 tasks, you can get fair use of 8 cpus by having a pair of tasks per cpu which leads to less disruption of the caches and a worse case time is not much different. – Peter Lawrey Oct 18 '12 at 09:42
  • Okay, in my case i probably have many more tasks than cpus, lets assume 1000, does this case still hold ? – Paul Taylor Oct 18 '12 at 10:50
  • Its not the number of tasks which matters by the number of active threads it has to schedule fairly between your cpus. – Peter Lawrey Oct 18 '12 at 10:51
  • sorry of course, right so i can see scheduling looks fairer, are you saying that in the implementation a particular is thread always tied to particular cpu, so once thread 9 has been run once on cpu x then cpux will always run thread 9 and whatever thread it ran first. – Paul Taylor Oct 18 '12 at 11:00
  • To minimise overhead you want threads to context switch as little as possible. – Peter Lawrey Oct 18 '12 at 11:02
  • Okay, and that is minimized by having a multiple of no of cpus, thanks Ill take your word for it although this question http://stackoverflow.com/questions/1223072/how-do-i-optimize-for-multi-core-and-multi-cpu-computers-in-java implies that java doesnt automtically make use of multiple cpus in the way you suggest. – Paul Taylor Oct 18 '12 at 11:47
  • Java uses native threads and its up to the OS decide what to do with those threads. On Linux and Windows it has appeared to me that a small multiple of the number of CPUs yields the best results. YMMV. – Peter Lawrey Oct 18 '12 at 12:02
9

For reference, check this description.

http://codeidol.com/java/java-concurrency/Applying-Thread-Pools/Sizing-Thread-Pools/

In short, what you have (No. CPU + 1) is optimal on average.

Saurabh P Bhandari
  • 6,014
  • 1
  • 19
  • 50
Alan J Liu
  • 324
  • 1
  • 7