This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgomp: Thread creation failed: Invalid argument
On Tue, 15 Aug 2006, Asher Langton wrote:
> On 8/15/06, Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> > On Tue, 15 Aug 2006, Asher Langton wrote:
> > > Are you using a lot of threadprivate variables? Try setting the
> > > GOMP_STACKSIZE environment variable to a large value (in kB) and see
> > > if the problem persists.
> >
> > That's it!
> > Yes, I do use a large set of threadprivate variables.
> >
> > I tried different settings of GOMP_STACKSIZE before. However, I somehow
> > didn't hit a working setting as I didn't know it was measured in kB.
> > The program now works on x86_64 with SETENV GOMP_STACKSIZE 1048576.
> > On i686 I do not find a working stacksize, as for too large stacksizes the
> > program dies with a segfault. Wonder how PGI and ifort deal with the
> > limited address space.
>
> Ifort has a similar environment variable, but I found that I didn't
> actually need it.
>
> On a side note: I just posted a patch on the fortran list that
> implements threadprivate without using Thread Local Storage (so that
> it works on Darwin, AIX, etc.). One unintended result was that I no
> longer needed to set GOMP_STACKSIZE to compile programs with lots of
> threadprivates. Would you mind trying your code against this patch,
> and letting me know if it works (at all), and whether you still need
> to set GOMP_STACKSIZE?
>
> http://gcc.gnu.org/ml/fortran/2006-08/msg00191.html
Yes, with the patched compiler my program runs even without touching
GOMP_STACKSIZE. And, as a bonus, the amount of virtual address space as
shown by top seems to be cut to roughly half the amount previously needed!
Now it is similar to that of the executables compiled with pgf90 or ifort.
With the reduced amount of address space needed, I was hoping that my
program might even run on i686 (as it does with ifort or pgf90), but that
turned out not to be the case. But address space is cheap since AMD's k8,
so I don't really care.
On a different side node, my program seems to run roughly 50% faster on an
8-way k8 system with (unpatched) gfortran than with the other compilers.
gfortran/gomp seems to reduce the synchronization losses to the amount I
was expecting (performance on a single CPU is comparable to the other
compilers). I am really impressed!
Thank you very much to the gomp and gfortran developers!
Tim