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
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
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