File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes Why is there this weird timing difference Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Why is there this weird timing difference" Watch "Why is there this weird timing difference" New topic

Why is there this weird timing difference

Armand van der Walt

Joined: Aug 04, 2010
Posts: 5
Hi, I'm comparing the time of running a quicksort algorithm sequentiality and parallel.

I would like to know why the time of the parallel is slower than the sequential, this does not make sense since as far I know it should be the other way around?

This is the output:
Thread 1 starting class ParalQuickSort
Thread 2 starting class ParalQuickSort
Normal starting class SeqQuickSort
Normal Traditional Stopwatch Time: 65340898 nanoseconds
Thread 2 Traditional Stopwatch Time: 5134718157 nanoseconds
Thread 1 Traditional Stopwatch Time: 5336746244 nanoseconds

Where I call the parallel:

Forking of the parallel:

Where I time the parallel:

Where I start the sequential thread:

The timing works the same for both cases.
Steve Luke

Joined: Jan 28, 2003
Posts: 4181

I don't think the code you posted is enough to be sure of an answer. You should post the complete code that shows what is going on. There are way too many variables to take into account when you can't see it.

Some things to think about:
Assuming a task will run faster in multiple threads than on a single thread is a bad idea. You can only gain speed if there is processor time left waiting to be used. If you have just one processor, and the single threaded run pegs the processors (puts it at 100% usage) for the entire work cycle, then there is no need to go to multiple threads and doing so will only slow things down.

For tasks where all steps need to be performed sequentially to maintain the integrity of the data, splitting the task into multiple threads can lead only to higher cost in making sure the steps are done in a safe manner. For example, if you have an algorithm where the order needs to be A->B->A->B->A->B->C, where none of any A step can be done at the same time as a B step or C step, and vice-versa, then there is no real gain of splitting the tasks into multiple threads. You add the cost of signaling between threads to ensure serialized execution - something you get for free when you run the task in a single thread. A hint as to when this might be a problem? If your entire execution code is in synchronized blocks you are probably falling into this bad habit.

My guess is that one or both of these problems are happening in your code. Though it could be more than that (for example if you don't properly synchronize the tasks then the two threads could be consistently battling each other, re-arranging the array and undoing/redoing each others work, or one of a dozen other problems impossible to see with the code you left out).

Armand van der Walt

Joined: Aug 04, 2010
Posts: 5
Hi thanks for the response.

I checked mt processor none of the cores go over 12% so its definitely not that I burn out my processor with my threads, it might be my lock() though?
But even without the lock I get the same times

Here is the complete code.

Ireneusz Kordal
Ranch Hand

Joined: Jun 21, 2008
Posts: 423

does not compile - there is no >< operator in Java.

I tried to change >< into != , but I got an exception:
Armand van der Walt

Joined: Aug 04, 2010
Posts: 5

should be

sorry my mistake that.
I agree. Here's the link:
subject: Why is there this weird timing difference
It's not a secret anymore!