using #pragma omp parallel for make the program slower

Question

My C++ program takes about 300 s to run. Inside my program I need to cwis divide my vectors. VS analyzer tells this takes about 15% of running time. here is the code:

template <class T> myVector<T> cWisDivide(myVector<T> &vec1, 

myVector<T> &vec2)
{
    try
    {
        if (vec1._rows == vec2._rows)
        {
            myVector<T> result(vec1._rows);
            //#pragma omp parallel for 
            for (int r = 1; r <= vec1._rows; r++)
            {
                if (vec2(r) != 0)
                {
                    result(r) = vec1(r) / vec2(r);
                }
                else
                {
                    throw std::runtime_error("");
                }
            }
            return result;
        }
    }
    catch (const exception &e)
    {
        ....
    }
}

this function is called many time. If I use #pragma ... before the loop, the cpu usage sticks 100% for about 350 s. which is more than the time taken to run program sequentially.

I would appreciate if any one could help me on the issue.

r in for loop should be defined before for itself. Like this: int r; #pragma.... for(r = 1...) — Michał Walenciak
Try to work out the parallel region further outwards. If you are calling the functions many times, you are paying as well for the initialization each time you call it — Chiel
@MichałWalenciak Um, no, for a parallel for putting the loop variable outside the loop means it's 'last' value has to be preserved by omp. This is an extra overhead and will slow it down. (a little). — user3710044
@javad, You're on Windows right? Taskman on Windows says 25% for one core on a 4 core machine. Really dumb question here ... you are using a multi-core machine aren't you ? — user3710044

Marcus Müller Marcus Müller · Accepted Answer · 2015-02-08T20:10:42

This can go wrong in a number of ways:

without knowing the type of result, it's possible that barriers have to be built in to avoid a race condition when modifying it -- you could avoid that by having parallel result vectors that you merge afterwards.
copy overhead for the vec1 and vec2 vectors might be bigger than performance reward.

all in all, this is a question about parallelizable vector types -- refer to your openMP documentation of choice to learn more about parallely accessible types.

using #pragma omp parallel for make the program slower

2 Answers