gomp - equivalence for threadprivate data
Tim Prince
TimothyPrince@sbcglobal.net
Mon Jan 26 13:38:00 GMT 2009
Matevz Tadel wrote:
> n8tm@aol.com wrote:
>>
>>
>>
>> -----Original Message-----
>> From: Matevz Tadel <matevz.tadel@cern.ch>
>> To: fortran@gcc.gnu.org
>> Cc: Federico Carminati <Federico.Carminati@cern.ch>
>> Sent: Thu, 22 Jan 2009 11:32 am
>> Subject: gomp - equivalence for threadprivate data
>>
>> Hello,
>> We are trying to parallelize a program that contains a legacy f77
>> project (GEANT3, ~200k loc). The code uses equivalence statements
>> between array elements and common members extensively, e.g.:
>> COMMON/GCPARM/IPARAM,PCUTGA,PCUTEL,PCUTNE,PCUTHA,PCUTMU +
>> ,NSPARA,MPSTAK,NPGENE REAL PACUTS(5) EQUIVALENCE (PACUTS(1),PCUTGA)
>> We are aware that OpenMP specification explicitly states that common
>> members and variables with the threadprivate specifier must not be
>> present in equivalence statements. However, as we want to use the
>> equivalence among variables that are all threadprivate within the same
>> compilation unit, the reason why this limitation could not be lifted
>> is not clear to us.
>> Thus, we would hope to get the following pragma to compile
>> successfully (for the above example)
>> !$omp threadprivate(/GCPARM/, PACUTS)
>> as the equivalnce simply needs to do what it would have done in a
>> non-parallel program (with the exception of mapping into the
>> thread-local data).
>> Is there an error in our reasoning?
>> We are willing to do most of the work needed for implementation of
>> such an extension but would defintely need some help and guidance.
>> In any case, even if there is no hope to get such an extension into
>> the official version, we would still like to bypass this issue as we
>> are trying to estimate if paralellization of our code makes any sense
>> at all due to possible issues with cache trashing and I/O bottlenecks.
>> Thanks in advance!
>> Best regards, Matevz
>> Currently we are using: gcc --version gcc (GCC) 4.3.3 20081110
>> (prerelease)
>> ___________________________________________-
>> For what it's worth, this is the one major obstacle I have run into in
>> the use of gfortran for compiling legacy applications. All commercial
>> compilers in my experience support the extension to the OpenMP
>> standard, in part because of the importance of this application. I
>> suppose the limits under which this is practical aren't well defined.
>> For example, I wouldn't expect it to work for cases where EQUIVALENCE
>> enlarges the data region.
>> Tim Prince
>
> Thanks for your reply.
>
> I tried with ifort but it reports the same error (the documentation
> doesn't mention anything about this). PGI fortran documentation
> explicitly states this is not allowed.
>
> Which compiler would you suggest to try?
>
> Best,
> Matevz
I have done very little work with geant, so I can't comment usefully, but
I would be surprised if it doesn't have provision to build with those
compilers. We do use ifort and pgf90 to build other applications which
violate OpenMP standard in this respect. I wasn't aware of a stated
limitation in pgf90 documentation, which would acknowledge that
EQUIVALENCE may present variations which can't be supported.
More information about the Fortran
mailing list