Multithreading slower than single threading - c++

Question

I writing a program that does heavy calculations for large arrays in real-time. The task can be split into several sub-arrays for multithreading. However, I cannot run this any faster using threads.
Here is a sample dummy code which was created for demonstration (same problem).
Two threads-version ends up lasting 39 seconds, which is couple of seconds longer if they were computed one after another(!). It doesn't matter if the arrays are global etc. I also tested using "thread constructors" only once, but with the same result.
I'm using XCode (5.1.1) and Macbook Air (2013 model, Core i5, Os X 10.8.5). Yes, this is old computer, I'm rarely programming...
So, could you find any mistake in the logic I have in the code or could it be somewhere in the settings of Xcode etc?
#include <ctime>
#include <iostream>
#include <thread>
class Value
{
public:
float a[3000000];
};
void cycle(Value *val)
{
int i;
for (i=0; i<3000000; i++)
{
val->a[i]=n;
n+=0.0001;
}
}
int main()
{
Value *val1=new Value, *val2=new Value;
clock_t start,stop;
start=clock();
for (int i=0; i<1000; i++)
{
thread first (cycle,val1);
thread second (cycle,val2);
first.join();
second.join();
}
stop=clock();
float tdiff=(((float)stop - (float)start) / 1000000.0F);
std::cout<<endl<<"This took "<<tdiff<<" seconds...";
return 0;
}
'''

Answer 1

There is a joke that goes something like that:
One programmer needs 1 day to finsish a program, how many days do 10 programmers need for the same? - 10 days.
The work in your code is done in this loop:
for (int i=0; i<1000; i++)
{
thread first (cycle,val1);
thread second (cycle,val2);
first.join();
second.join();
}
Now consider that spawning and joining threads is overhead. In total your parallel code does more than a sequential would have to do, in gerenal there is no way around that. And you are not creating and joining threads once, but 1000-times, ie you add 1000-times overhead.
Don't expect code to run faster by simply adding more threads to it. I refer you to Amdahl's law or Gustavson's Law (which basically states the same just a bit more positive).
I suggest you to experiment with sequential vs threaded but only one thread to get a feeling for the overhead. You can compare this:
for (int i=0; i<1000; i++)
{
thread first (cycle,val1);
first.join();
}
With a sequential version that does not use any threads. You will be surprised by the difference.
You get most out of multithreading when the threads do lots of work (cf Amdahl/Gustavson) and when there is no synchronisation between different threads. Your 1000 times joining the threads is basically a barrier, where second has to wait doing nothing until first is finished. Such barriers are best avoided.
Last but not least, as mentioned in a comment, your benchmark is rather questionable, because you are not using the result of the computations. That is, either you didn't turn on optimizations which makes the results rather meaningless, or you did turn on optimizations and the compiler might optimize things away without you noticing it. And actually I am not sure whether you are comparing two versions that do the same work, or if perhaps your parallel version is doing twice the work. Moreover, when measuring time you need to take care to measure wall clock time not cpu time, because cpu time adds times spend on multiple cores, while you want to compare wall clock time.
TL;DR: More threads != automatically less runtime.

Answer 2

If you read the documentation for clock, you might notice that it says that time can appear to go faster if the process executes on multiple cores; clock is a total CPU-use approximation, not "wall clock time", and one "CPU tick" on two cores in parallel is the same amount of "time" as two sequential "ticks" on one core.
(By the way: in order to get the time in seconds, you should be dividing by CLOCKS_PER_SEC.)
Using a more appropriate timer, like std::chrono::steady_clock, will show that the sequential variant takes almost twice as long as the multithreaded version.
The difference can be explained completely by the overhead of creating and destroying threads.

Answer 3

Unlike the other comments suggest, n is not the culprit, neither is the sequential joins.
Each thread performs the same operation cycle, so how could there be any improvement?
You have to manually split the workload between the two threads, so that each one works on half the data.