4
omp_set_num_threads( 8 );
#pragma omp parallel for
for( int tx = 0; tx < numThread; tx++ )
{
    cout<<"\nThread :"<<omp_get_num_threads()<<"\n";

}

My understanding is that the above code is supposed to print 8. But the output I am getting is 

Thread :1

Thread :1

Thread :1

Thread :1

Thread :1

Thread :1

Thread :1

Thread :1

Please let me know what is going wrong here. I am beginner to openmp and so I am quite sure i must have made some stupid mistake.

Thanks in advance

leeor
  • 17,041
  • 6
  • 34
  • 60
Johns Paul
  • 633
  • 6
  • 22

1 Answers1

1

I'm not sure what's happening here.

It can be the case that you compiled with a stub OpenMP library, which provides all the OpenMP library API, but only acting as if sequential mode (see this link for example for the corresponding Intel compiler switch).

Another possibility is that the OMP_THREAD_LIMIT environment variable is set to 1 in your environment. See for example this code:

#include <iostream>
#include <omp.h>

int main() {
    omp_set_num_threads(8);
    #pragma omp parallel
    #pragma omp single
    std::cout << "Number of threads in the current parallel region is " << omp_get_num_threads() << std::endl;

    return 0;
}

When compiled with OpenMP support and run, it gives me:

$ g++ -fopenmp nbthreads.cc -o nbthreads
$ ./nbthreads 
Number of threads in the current parallel region is 8
$ OMP_THREAD_LIMIT=1 ./nbthreads 
Number of threads in the current parallel region is 1

Aside from these two possibilities, I've no idea.

Edit: thanks to Z boson's comment, I'm pretty sure I've got the key of the mystery.

With the very same code as the hereabove one, here is what I've got:

$ g++ -o nbthreads nbthreads.cc -lgomp
$ ./nbthreads 
Number of threads in the current parallel region is 1

So you simply mistakenly used -lgomp instead of -fopenmp while compiling / linking your code. This gives you an OpenMP code equivalent to having only 1 thread, even if you explicitly ask for more.

Community
  • 1
  • 1
Gilles
  • 9,269
  • 4
  • 34
  • 53
  • He says he's using GCC. There is no way, unfortunately, to only use the stub functions with GCC: it's all or nothing. You can do this with ICC and MSVC not not GCC. – Z boson Oct 16 '15 at 10:49
  • That's interesting. Maybe I'm wrong then? If you only link with `-lgomp` you get the stubs only? Or at least you get no threads? – Z boson Oct 16 '15 at 10:59
  • @Zboson I suspect you simply resolve the OpenMP runtime library functions, but since you don't have any `parallel` region, they all give you a sequential answer. This is actually very similar to a stub. – Gilles Oct 16 '15 at 11:01
  • Probably one should look at the assembly still just to make sure. Actually I think one could check the binaries with and without the `pragma omp`. If the binaries are the same then it means it's only using the stub function. – Z boson Oct 16 '15 at 11:55
  • I just checked. They are the same. So I am wrong. I am happy to be wrong. But that means there are few answers on SO that need to be corrected. Thanks for showing me this!!! – Z boson Oct 16 '15 at 13:25
  • [This answer is wrong](http://stackoverflow.com/a/17104343/2542702). Go ahead and give a correct answer. You earned it. – Z boson Oct 16 '15 at 13:27
  • 1
    I used changed to -fooenmp and it solved my issue. Thanks a lot – Johns Paul Oct 17 '15 at 04:12
  • I should have thought of this. Using `-Wall` with `-lgomp` but without `-fopenmp` shows that the omp pragmas are ignored. So you get the stub functions only. – Z boson Oct 17 '15 at 09:36