Hi,
Dynamic allocating of 2 GB should work on 64-bit nodes if you are using
a proper 64-bit enabled compiler. However your core memory seems too
short with 2 GB. You have to fit in both the system, the applications,
and the matrix... Better to have set a large enough swap and be patient.
Are you sure also you have set up the appropriate 64-bit flags on gcc ?
However the hardware should not be a limitation. I am routinely running
8 GB jobs on a bi-Opteron under Solaris 10 with the Sun compilers (free
of charge for the academic community).
Pierre Valiron.
Neil Storer wrote:
> Hi,
>
> Similar to Brian's suggestion suggestion. You could try either:
>
> 1) Placing your matrix in "Blank common"
> e.g.
> COMMON big_matrix(16400,16400)
>
> Blank common is not stored in a BSS segment.
>
> or
>
> 2) Allocating your matrix dynamically (f90)
> e.g.
> REAL, DIMENSION(:), ALLOCATABLE :: big_matrix
> ALLOCATE(big_matrix(160400,16400), STAT=ierr)
> IF (ierr .NE. 0) THEN
> STOP 'Allocation failed'
> ENDIF
>
> These may work - no guarantees though.
>
> Regards
> Neil
> Brian Barrett wrote:
>
>> On Feb 22, 2005, at 4:32 PM, Srinivasa Prade Patri wrote:
>>
>>> Iam running LU decomposition algorithm on a 23 node
>>> cluster. Each node has 2GB of RAM. When iam trying to run the
>>> algorithm for single precision complex matrix of size
>>> 16400*16400,iam getting the following compilation errors.
>>>
>>> /tmp/ccmtcg1e.o(.text+0xa1): In function `MAIN__':
>>> : relocation truncated to fit: R_X86_64_32S .bss
>>
>>
>> <snip>
>>
>>> I know for such a big matrix the matrix
>>> size is more than 2GB (16400*16400*8 Bytes = 2.15GB). IS this the
>>> reason for the above compilation errors?
>>>
>>> If this is the case,do we have any
>>> techniques where i can run the algorithm for matrix sizes more than
>>> 16400*16400. Or the cluster iam using is limited for certain problem
>>> size (16384*16384).
>>
>>
>> Based on your error messages and some google searches, it looks like
>> you're tripping up a limitation in at least some versions of the GCC
>> suite on x86_64 machines. They don't seem to do well with large text
>> sections (anywhere they have to have hard coded addresses > 2GB in
>> size. I was unable to reproduce the problems on our Opteron
>> machines, but they are running a very recently installed version of
>> Gentoo, so maybe the bug was fixed along the way? Based on that,
>> upgrading might help.. The other option is to stick the large matrix
>> in the heap instead of the text or data section by making it
>> dynamically allocated. That should keep you from angering the linker
>> gods.
>>
>>
>> Hope this helps,
>>
>> Brian
>>
>
> --
>+-----------------+---------------------------------+------------------+
>| Neil Storer | Head: Systems S/W Section | Operations Dept. |
>+-----------------+---------------------------------+------------------+
>| ECMWF, | email: neil.storer_at_[hidden] <mailto:neil.storer_at_[hidden]> | //=\\ //=\\ |
>| Shinfield Park, | Tel: (+44 118) 9499353 | // \\// \\ |
>| Reading, | (+44 118) 9499000 x 2353 | ECMWF |
>| Berkshire, | Fax: (+44 118) 9869450 | ECMWF |
>| RG2 9AX, | | \\ //\\ // |
>| UK | URL: http://www.ecmwf.int/ | \\=// \\=// |
>+--+--------------+---------------------------------+----------------+-+
> | ECMWF is the European Centre for Medium-Range Weather Forecasts |
> +-----------------------------------------------------------------+
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
--
Soutenez le mouvement SAUVONS LA RECHERCHE :
http://recherche-en-danger.apinc.org/
_/_/_/_/ _/ _/ Dr. Pierre VALIRON
_/ _/ _/ _/ Laboratoire d'Astrophysique
_/ _/ _/ _/ Observatoire de Grenoble / UJF
_/_/_/_/ _/ _/ BP 53 F-38041 Grenoble Cedex 9 (France)
_/ _/ _/ http://www-laog.obs.ujf-grenoble.fr
_/ _/ _/ mail: Pierre.Valiron_at_[hidden]
_/ _/ _/ Phone: +33 4 7651 4787 Fax: +33 4 7644 8821
_/ _/_/
|
