Thread Subject: OMP_NUM_THREADS - change in Matlab behavior

Hi there,

I am currently investigating the following and was wondering
if somebody has encountered the same issue. This is using
R2007b on Linux x86-64.

Basically, the issue is that Matlab seems to change the
environment variable OMP_NUM_THREADS on startup.

So when I say

> export OMP_NUM_THREADS=2
> matlab -nojvm

and then, directly after Matlab has started,

>> getenv OMP_NUM_THREADS

ans =

1

(Of course, "!echo $OMP_NUM_THREADS" also returns 1.)

For me, this is a problem as I would like to run mex-files
that are parallelized using OpenMP from Matlab.

Has anybody else seen this (undocumented) compatibility
issue? In previous versions, Matlab didn't change this
environment variable. And how to deal with it, preferably
without changing code (to maintain backwards compatibility)?

Thanks for any comments,

Joachim

Fixed and submitted for R2008a (geck 398321).

> . And how to deal with it, preferably
> > without changing code (to maintain backwards compatibility)?

As a temporary workaround the user needs to manually reset the environment
variable OMP_NUM_THREADS from MATLAB command prompt (or MATLAB startup file)
before starting MEX file:

>> setenv('OMP_NUM_THREADS', '2');

"Joachim " <a@b.com> wrote in message
news:feuhss$pmv$1@fred.mathworks.com...
> Hi there,
>
> I am currently investigating the following and was wondering
> if somebody has encountered the same issue. This is using
> R2007b on Linux x86-64.
>
> Basically, the issue is that Matlab seems to change the
> environment variable OMP_NUM_THREADS on startup.
>
> So when I say
>
>> export OMP_NUM_THREADS=2
>> matlab -nojvm
>
> and then, directly after Matlab has started,
>
>>> getenv OMP_NUM_THREADS
>
> ans =
>
> 1
>
> (Of course, "!echo $OMP_NUM_THREADS" also returns 1.)
>
> For me, this is a problem as I would like to run mex-files
> that are parallelized using OpenMP from Matlab.
>
> Has anybody else seen this (undocumented) compatibility
> issue? In previous versions, Matlab didn't change this
> environment variable. And how to deal with it, preferably
> without changing code (to maintain backwards compatibility)?
>
> Thanks for any comments,
>
> Joachim

"Boris Furman" <bfurman@mathworks.com> wrote
>
> As a temporary workaround the user needs to manually reset
the environment
> variable OMP_NUM_THREADS from MATLAB command prompt (or
MATLAB startup file)
> before starting MEX file:
>
> >> setenv('OMP_NUM_THREADS', '2');

Unfortunately, this does not resolve the problem. The
mex-file still runs single-threaded. I wrote the little test
program below and run it on two SMP servers (both Linux
x86-64) I have access to, the first with R2006b and the
other with R2007b.

On the first, opening Matlab, setting
>> setenv('OMP_NUM_THREADS', '2');
and calling
>> test

returns
                                                           
   total no of threads is 2
>>

On the R2007b machine, opening Matlab, setting again
OMP_NUM_THREADS to 2 as before, and calling test returns

total no of threads is 1

In other words, the mex file appears to see only one thread
despite the change in environment from within Matlab. The
small program called test.f90 is below (the subroutine test
works as expected on both systems when called from outside
Matlab--of course, the mexprintf needs to be replaced by
usual write to stdout).

subroutine mexfunction(nlhs,plhs,nrhs,prhs)

implicit none

integer :: nlhs,nrhs
integer(8), dimension(*) :: plhs
integer(8), dimension(*) :: prhs

call test()

end subroutine mexfunction


subroutine test

implicit none

integer(8) :: mexprintf

integer :: num,tid,trash
integer :: omp_get_thread_num,omp_get_num_threads

character(len=100) :: msg

!$OMP PARALLEL DEFAULT(PRIVATE)

tid=omp_get_thread_num()

if(tid==0) then
  num=omp_get_num_threads()
  write(unit=msg,fmt='(a,i4)') 'total no of threads is ',num
  trash=mexPrintf(trim(msg//char(13)))
endif

!$OMP END PARALLEL

end subroutine test



> "Joachim " <a@b.com> wrote
> >
> > For me, this is a problem as I would like to run mex-files
> > that are parallelized using OpenMP from Matlab.
> >
> > Has anybody else seen this (undocumented) compatibility
> > issue? In previous versions, Matlab didn't change this
> > environment variable. And how to deal with it, preferably
> > without changing code (to maintain backwards compatibility)?
> >
> > Thanks for any comments,
> >
> > Joachim
>
>

> Unfortunately, this does not resolve the problem. The
> mex-file still runs single-threaded.

Okay, sorry for the lame self-reply. It seems on R2007b I
need to call both setenv('OMP_NUM_THREADS','2') and
maxNumCompThreads(2) for the mex to run multi-threaded.

I tried your solution with matlab2007a. There seems no
maxNumCompThreads there. Is there any workaround for
matlab2007a.
Thanks
"Joachim " <a@b.com> wrote in message
<ff09dc$l1m$1@fred.mathworks.com>...
> > Unfortunately, this does not resolve the problem. The
> > mex-file still runs single-threaded.
>
> Okay, sorry for the lame self-reply. It seems on R2007b I
> need to call both setenv('OMP_NUM_THREADS','2') and
> maxNumCompThreads(2) for the mex to run multi-threaded.

Hi Everybody,
I am using Matlab R2007a, to make sure that you can actually use openmp
calls through MEX calls... But, how do you setup your 'opts.sh' mex file?.
 
I am using gfortran with 'FFLAGS = -fopenmp -DMX_COMPAT_32 -fno-
common', and although it seems to compile&link fine, when I run your 'test'.
Matlab crashes and exists:

>>
>> test
dyld: lazy symbol binding failed: Symbol not found: _GOMP_parallel_start
  Referenced from: ~/test.mexmaci
  Expected in: flat namespace

dyld: Symbol not found: _GOMP_parallel_start
  Referenced from: ~/test.mexmaci
  Expected in: flat namespace

/usr/local/bin/matlab_terminal: line 2: 302 Trace/BPT trap

??

I also tried with ifort with 'FFLAGS = -openmp -fPIC -u -w95 -132 -warn all'
, but I have some issues with the linking stage:

-> ifort -c -I/Applications/MATLAB74/extern/include -
I/Applications/MATLAB74/simulink/include -openmp -fPIC -u -w95 -132 -
warn all -DMX_COMPAT_32 -O2 test.f90

fortcom: Info: test.f90, line 1: This variable has not been used. [NLHS]
subroutine mexfunction(nlhs,plhs,nrhs,prhs)
-----------------------^
fortcom: Info: test.f90, line 1: This variable has not been used. [PLHS]
subroutine mexfunction(nlhs,plhs,nrhs,prhs)
----------------------------^
fortcom: Info: test.f90, line 1: This variable has not been used. [NRHS]
subroutine mexfunction(nlhs,plhs,nrhs,prhs)
---------------------------------^
fortcom: Info: test.f90, line 1: This variable has not been used. [PRHS]
subroutine mexfunction(nlhs,plhs,nrhs,prhs)
--------------------------------------^
test.f90(21): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
test.f90(8): (col. 6) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
-> gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-
exported_symbols_list,/Applications/MATLAB74/extern/lib/maci/fexport.ma
p -o test.mexmaci test.o
/Applications/MATLAB74/extern/lib/maci/version4.o $RPATH $MLIBS -
L/opt/intel/fce/10.0.016/lib -lm

/usr/bin/ld: symbols names listed in -exported_symbols_list:
/Applications/MATLAB74/extern/lib/maci/fexport.map not in linked objects
_mexfunction_
collect2: ld returned 1 exit status

    mex: link of 'test.mexmaci' failed.

??? Error using ==> mex at 206
Unable to complete successfully.

>>


I could not try 'g95' since it does not seem to support 'openmp', yet.
I am deeply desperate, any ideas?

Thanks a lot, in advance!





"Joachim " <a@b.com> wrote in message
<ff09dc$l1m$1@fred.mathworks.com>...
> > Unfortunately, this does not resolve the problem. The
> > mex-file still runs single-threaded.
>
> Okay, sorry for the lame self-reply. It seems on R2007b I
> need to call both setenv('OMP_NUM_THREADS','2') and
> maxNumCompThreads(2) for the mex to run multi-threaded.

"Ibon " <bustinduy8.nospam@yahoo.es> wrote in message
<fi3kpg$cv9$1@fred.mathworks.com>...
> Hi Everybody,
> I am using Matlab R2007a, to make sure that you can actually use openmp
> calls through MEX calls... But, how do you setup your 'opts.sh' mex file?.
>
> I am using gfortran with 'FFLAGS = -fopenmp -DMX_COMPAT_32 -fno-
> common', and although it seems to compile&link fine, when I run your
'test'.
> Matlab crashes and exists:
>
> >>
> >> test
> dyld: lazy symbol binding failed: Symbol not found: _GOMP_parallel_start
> Referenced from: ~/test.mexmaci
> Expected in: flat namespace
>
> dyld: Symbol not found: _GOMP_parallel_start
> Referenced from: ~/test.mexmaci
> Expected in: flat namespace
>
> /usr/local/bin/matlab_terminal: line 2: 302 Trace/BPT trap
>
> ??
>
> I also tried with ifort with 'FFLAGS = -openmp -fPIC -u -w95 -132 -warn
all'
> , but I have some issues with the linking stage:
>
> -> ifort -c -I/Applications/MATLAB74/extern/include -
> I/Applications/MATLAB74/simulink/include -openmp -fPIC -u -w95 -132
-
> warn all -DMX_COMPAT_32 -O2 test.f90
>
> fortcom: Info: test.f90, line 1: This variable has not been used. [NLHS]
> subroutine mexfunction(nlhs,plhs,nrhs,prhs)
> -----------------------^
> fortcom: Info: test.f90, line 1: This variable has not been used. [PLHS]
> subroutine mexfunction(nlhs,plhs,nrhs,prhs)
> ----------------------------^
> fortcom: Info: test.f90, line 1: This variable has not been used. [NRHS]
> subroutine mexfunction(nlhs,plhs,nrhs,prhs)
> ---------------------------------^
> fortcom: Info: test.f90, line 1: This variable has not been used. [PRHS]
> subroutine mexfunction(nlhs,plhs,nrhs,prhs)
> --------------------------------------^
> test.f90(21): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
> test.f90(8): (col. 6) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
> -> gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-
>
exported_symbols_list,/Applications/MATLAB74/extern/lib/maci/fexport.ma
> p -o test.mexmaci test.o
> /Applications/MATLAB74/extern/lib/maci/version4.o $RPATH $MLIBS -
> L/opt/intel/fce/10.0.016/lib -lm
>
> /usr/bin/ld: symbols names listed in -exported_symbols_list:
> /Applications/MATLAB74/extern/lib/maci/fexport.map not in linked
objects
> _mexfunction_
> collect2: ld returned 1 exit status
>
> mex: link of 'test.mexmaci' failed.
>
> ??? Error using ==> mex at 206
> Unable to complete successfully.
>
> >>
>
>
> I could not try 'g95' since it does not seem to support 'openmp', yet.
> I am deeply desperate, any ideas?
>
> Thanks a lot, in advance!
>
>
>
>
>
> "Joachim " <a@b.com> wrote in message
> <ff09dc$l1m$1@fred.mathworks.com>...
> > > Unfortunately, this does not resolve the problem. The
> > > mex-file still runs single-threaded.
> >
> > Okay, sorry for the lame self-reply. It seems on R2007b I
> > need to call both setenv('OMP_NUM_THREADS','2') and
> > maxNumCompThreads(2) for the mex to run multi-threaded.
>
>

What seemed to do the trick in my case was to link the library libgomb.a
while combiling in matlab (at least the program runs without crashing, and
uses both cores on my MacBook Pro). That is:

mex -L /..libgompLocation../libgomp.a testOpenMP.c

Hopefully this will also work in fortran.

Regards
Jon

Thank you very much indeed Jon,

It seems to be THE SOLUTION in the case of gfortran as my friend Michael
Brown noticed me. However, with the ifort compiler, altough it seems to
compile it correctly:

>> mex -L /usr/local/lib/libgomp.a test.f90
test.f90(21): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
test.f90(8): (col. 6) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
>>
>>
 
When I try to run it:

>> test


Segmentation violation occurred within signal handler.
Unable to complete stack trace (stack was probably corrupted)

This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.
dyld: lazy symbol binding failed: Symbol not found: _for_write_int_fmt
  Referenced from: test.mexmaci
  Expected in: flat namespace

dyld: Symbol not found: _for_write_int_fmt
  Referenced from: test.mexmaci
  Expected in: flat namespace

This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.


Any Ideas?


"Jon Saetrom" <ion@organizer.net> wrote in message
> What seemed to do the trick in my case was to link the library libgomb.a
> while combiling in matlab (at least the program runs without crashing, and
> uses both cores on my MacBook Pro). That is:
>
> mex -L /..libgompLocation../libgomp.a testOpenMP.c
>
> Hopefully this will also work in fortran.
>
> Regards
> Jon

Unfortunately I am a bit of newbie in this field, and do not have access to the
ifort compiler. But it seems that you have include a link to the missing library.
The only clue I can give you to which library can be found on this webpage:

http://softwarecommunity.intel.com/isn/Community/en-
US/forums/thread/111580.aspx

I am sorry that I could not be more helpful.

Regards
Jon


"Ibon " <bustinduy8.nospam@yahoo.es> wrote in message
<fpgsqv$hpf$1@fred.mathworks.com>...
> Thank you very much indeed Jon,
>
> It seems to be THE SOLUTION in the case of gfortran as my friend Michael
> Brown noticed me. However, with the ifort compiler, altough it seems to
> compile it correctly:
>
> >> mex -L /usr/local/lib/libgomp.a test.f90
> test.f90(21): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
> test.f90(8): (col. 6) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
> >>
> >>
>
> When I try to run it:
>
> >> test
>
>
> Segmentation violation occurred within signal handler.
> Unable to complete stack trace (stack was probably corrupted)
>
> This error was detected while a MEX-file was running. If the MEX-file
> is not an official MathWorks function, please examine its source code
> for errors. Please consult the External Interfaces Guide for information
> on debugging MEX-files.
> dyld: lazy symbol binding failed: Symbol not found: _for_write_int_fmt
> Referenced from: test.mexmaci
> Expected in: flat namespace
>
> dyld: Symbol not found: _for_write_int_fmt
> Referenced from: test.mexmaci
> Expected in: flat namespace
>
> This error was detected while a MEX-file was running. If the MEX-file
> is not an official MathWorks function, please examine its source code
> for errors. Please consult the External Interfaces Guide for information
> on debugging MEX-files.
>
>
> Any Ideas?
>
>
> "Jon Saetrom" <ion@organizer.net> wrote in message
> > What seemed to do the trick in my case was to link the library libgomb.a
> > while combiling in matlab (at least the program runs without crashing,
and
> > uses both cores on my MacBook Pro). That is:
> >
> > mex -L /..libgompLocation../libgomp.a testOpenMP.c
> >
> > Hopefully this will also work in fortran.
> >
> > Regards
> > Jon
>
>