File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes Difference between multithreading with and without Executor Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Difference between multithreading with and without Executor" Watch "Difference between multithreading with and without Executor" New topic
Author

Difference between multithreading with and without Executor

pravin gate
Greenhorn

Joined: Feb 20, 2012
Posts: 10
I am trying to find out about the performance difference between normal multithreading and multithreading using executor (to maintain a thread pool).

The below are code examples for both.

Without Executor Code (with multithreading):



With executor (multithreading):



For sample output please see attached image.


When I run both programs, it turns out the executor is more expensive than normal multithreading. why is this so?

And given this, what is the use of executor exactly? We use the executor to manage thread pools.

I would have expected the executor to give better results than normal multithreading.

Basically I'm doing this as I need to handle millions of clients using socket programming with multithreading.

Any suggestions will be helpful.



[Thumbnail for Output.png]

Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2414
    
  28

Yes, starting infinite number of threads will perform much better than using a thread pool when all your threads are doing is sleeping

However, realistically, your threads won't be sleeping all the time. They will be using memory and CPU. Change your demo to make your Runnables do some work that simulates the real work been done

ALso, a ThreadPool doesn't really give you performance. What it gives you is better failover. Let's consider a scenarion where your task is CPU bound.

Let's assume that in a real life scenario, each "task" runs for 10 seconds and spends 50% of the time using the CPU and 50% in IO. Let's say you have 4 cores. Now, let's say you have 200 tasks. Using your first solution, you will start 200 threads, all of which will be trying to fight for the CPU. Since you have 4 cores, it comes to 50 threads per core. The core can only execute one thread at a time. So basically, it will be constantly switching contexts between threads. So, the time taken to execute 200 tasks is

t = threads per core*execution time per thread*percentage of CPU time + contextswitchingoverhead for 200 threads
= 50*10s*0.5 + contextswitchingoverhead(200)
= 250s + contextswitchingoverhead(200)


Now, let's see how long it takes with a thread pool. Let's say you put 8 threads in your thread pool. Each thread has 25 tasks

t = tasks per thread * execution time per thread + context switching overhead for 8 threads
= 25*10s + contextswitchingoverhead(8)
= 250s + contextswitchingoverhead(8)

Note that contextswitching becomes exponentially worse as the number of threads increase. contextswitching between 200 threads is going to be much much worse than context switching.

The thread pool is not really giving you performance; ie; when you have low number of tasks, it will give you same performance as starting threads, but when your number of tasks are much greater than the resources in the system, the thread pool guarantees that you don't overwhelm the CPU with too many threads.
pravin gate
Greenhorn

Joined: Feb 20, 2012
Posts: 10
Thanks jayesh for providing such useful guidence.

Jayesh A Lalwani wrote:Yes, starting infinite number of threads will perform much better than using a thread pool when all your threads are doing is sleeping

However, realistically, your threads won't be sleeping all the time. They will be using memory and CPU. Change your demo to make your Runnables do some work that simulates the real work been done

ALso, a ThreadPool doesn't really give you performance. What it gives you is better failover. Let's consider a scenarion where your task is CPU bound.

Let's assume that in a real life scenario, each "task" runs for 10 seconds and spends 50% of the time using the CPU and 50% in IO. Let's say you have 4 cores. Now, let's say you have 200 tasks. Using your first solution, you will start 200 threads, all of which will be trying to fight for the CPU. Since you have 4 cores, it comes to 50 threads per core. The core can only execute one thread at a time. So basically, it will be constantly switching contexts between threads. So, the time taken to execute 200 tasks is

t = threads per core*execution time per thread*percentage of CPU time + contextswitchingoverhead for 200 threads
= 50*10s*0.5 + contextswitchingoverhead(200)
= 250s + contextswitchingoverhead(200)


Now, let's see how long it takes with a thread pool. Let's say you put 8 threads in your thread pool. Each thread has 25 tasks

t = tasks per thread * execution time per thread + context switching overhead for 8 threads
= 25*10s + contextswitchingoverhead(8)
= 250s + contextswitchingoverhead(8)

Note that contextswitching becomes exponentially worse as the number of threads increase. contextswitching between 200 threads is going to be much much worse than context switching.

The thread pool is not really giving you performance; ie; when you have low number of tasks, it will give you same performance as starting threads, but when your number of tasks are much greater than the resources in the system, the thread pool guarantees that you don't overwhelm the CPU with too many threads.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Difference between multithreading with and without Executor