Multithreaded application increases runtime with number of threads

Question

I am implementing a multithreaded solution of the Barnes-Hut algorithm for the N-Body problem.

Main class does the following

public void runSimulation() {
        for(int i = 0; i < numWorkers; i++) {
            new Thread(new Worker(i, this, gnumBodies, numSteps)).start();
        }
        try {
            startBarrier.await();
            stopBarrier.await();
        } catch (Exception e) {e.printStackTrace();}
}

The bh.stop- and bh.startBarrier are CyclicBarriers setting start- and stopTime to System.nanoTime(); when reached (barrier actions).

The workers run method:

public void run() {
    try {
        bh.startBarrier.await();

        for(int j = 0; j < numSteps; j++) {
            for(int i = wid; i < gnumBodies; i += bh.numWorkers) {
                bh.addForce(i);
                bh.moveBody(i);
            }
            bh.barrier.await();
        }
        bh.stopBarrier.await();
    } catch (Exception e) {e.printStackTrace();}
}

addForce(i) goes through a tree and does some calculations. It does not effect any shared variables, so no synchronization is used. O(NlogN).

moveBody(i) does calculations on one element and no synchronization is used. O(N).

When bh.barrier is reached, a tree with all bodies is built up (barrier action).

Now to the problem. The runtime increases linearly with the number of threads used. Runtimes for gnumBodies = 240, numSteps = 85000 and four cores:

• 1 thread = 0.763
• 2 threads = 0.952
• 3 threads = 1.261
• 4 threads = 1.563

Why isn't the runtime decreasing with the number of threads used?

edit: added hardware info

Answer 1

What hardware are you running it on? Running multiple threads has its overhead so it might not be worth while splitting your task into to small sub-task.

Also, try using an ExecutorService instead of thread. That way you can use a thread pool instead of creating an actual thread for each task. There is no use in having more threads that your hardware can handle.

It also look to me like each thread will do the same work. Can this be the case? when creating a worker you are using same parameters each time besides for i.

Answer 2

Multithreading does not increase the execution speed unless you also have multiple CPU cores.

Threads doing math calculations and can run full speed

If you have only one CPU core, it is all the same if you run a calculation in one thread or in multiple threads. Running in multiple threads gives no performance benefit, but comes with an overhead of thread switching, so actually the total performance will be a little worse.

If you have multiple available CPU cores, then the threads can run physically in parallel up to the number of cores. This means 4-8 threads may work well on nowadays desktop hardware.

Threads waiting for IO and getting suspended

Threads make sense if you don't do a mathematical calculation, but do something which involves slow I/O such as network, files, or databases. Instead of hogging the run of your program, while one thread waits for the IO, another thread can use the same CPU core. This is the reason why web servers and database solutions works with more threads than CPU cores.

Avoid unnecessary synchronization

Nevertheless, your measurement shows a synchonization mistake. I guess you shall remove all xxbarrier.await() from the thread code. I am unsure what is your goal with the xxBarriers vs. System nanotime, but any unnecessary synchornization can easily result slow performance. Instead of calculating, you're waiting on the xxxBarriers.

Answer 3

Your workers do the same job numWorker times, independently. The only shared object is your CyclicBarrier. await() waits all parities invoke await on this barrier. With the number of workers are increasing, it spends more time on await()

Answer 4

If you have multiple cores or if hyperthreading is available, then running multiple threads will take the benefit of underlying hardware.

If only one core is present, multi-threading can give a 'perceived' benefit if your application involves atleast one non CPU intensive work like interaction with human. Humans are very slow compared to modern day CPUs. Hence if your application requires to get multiple inputs from human and also process them, it makes sense to do separate the input and calculations in two threads. By the time human will provide an input, part of the calculation can be completed in another thread. Thus the overall improvement in time.

If you application must do calculations and multi-threading support in hardware is not present, it is better to use single thread. Your 'calculations' are already lined up in the pipeline back-to-back and CPU will already be running at (almost) max speed. Multi-threading would require context-switching time which will increase the time taken to do the calculations.

Answer 5

When i ran the application with a larger number of bodies an less steps, the application scaled as expected. So the problem was probably the overhead of the barrier(s)!