limitations of 64bit gfortran
in [Fortran]
|
Prev: Error LNK2019
Next: stack overflow
From: Jan Vorbrüggen on 2 Oct 2007 06:06 > what are differences between 32bit and 64bit mode fortran. > explicitly, I need to know what differences there are about their > limitations. One limitation not discussed so far is array indexing. Conceivably, you can have a program that allocates an array of, say, more than 4 billion elements - but you default integer that is used to index those elements is usually limited to 2^31-1. In such a case, you need to make sure that you use an integer type with a suitable range for the purpose. Jan
From: glen herrmannsfeldt on 2 Oct 2007 15:39 Jan Vorbr�ggen wrote: >> what are differences between 32bit and 64bit mode fortran. >> explicitly, I need to know what differences there are about their >> limitations. > One limitation not discussed so far is array indexing. Conceivably, you > can have a program that allocates an array of, say, more than 4 billion > elements - but you default integer that is used to index those elements > is usually limited to 2^31-1. In such a case, you need to make sure that > you use an integer type with a suitable range for the purpose. Even with 32 bit signed integers you can index arrays of 32 bit integer or real up to just below 8GB and 64 bit real to almost 16GB. (and 64 bit complex to almost 32GB.) For an array with more than one dimension, you can index many GB even with only 16 bit integers. A 64 bit implementation should do the index calculation in 64 bits even with 32 bit subscript variables. Since Fortran expects the default INTEGER and REAL to be the same size, it is not convenient to increase the default INTEGER to 64 bits. -- glen
From: Wade Ward on 2 Oct 2007 19:24 "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:0LCdnaVnDf4sEp_anZ2dnUVZ_qCgnZ2d(a)comcast.com... > Jan Vorbr�ggen wrote: > >>> what are differences between 32bit and 64bit mode fortran. >>> explicitly, I need to know what differences there are about their >>> limitations. > >> One limitation not discussed so far is array indexing. Conceivably, you >> can have a program that allocates an array of, say, more than 4 billion >> elements - but you default integer that is used to index those elements >> is usually limited to 2^31-1. In such a case, you need to make sure that >> you use an integer type with a suitable range for the purpose. > > Even with 32 bit signed integers you can index arrays of 32 bit integer > or real up to just below 8GB and 64 bit real to almost 16GB. > (and 64 bit complex to almost 32GB.) > For an array with more than one dimension, you can index many GB even > with only 16 bit integers. A 64 bit implementation should do the > index calculation in 64 bits even with 32 bit subscript variables. > > Since Fortran expects the default INTEGER and REAL to be the same > size, it is not convenient to increase the default INTEGER to 64 bits. Will you elaborate? In particular, I would like you to quantify what you mean with: > For an array with more than one dimension, =n. let n equals 1 to 6 be given. -- wade ward "The final irony is that cops and rodney king have the same IQ."
From: glen herrmannsfeldt on 3 Oct 2007 21:37 Wade Ward wrote: > "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote (snip) >>Since Fortran expects the default INTEGER and REAL to be the same >>size, it is not convenient to increase the default INTEGER to 64 bits. > Will you elaborate? INTEGER MM(1000000) REAL YY(1000000) EQUIVALENCE (MM(1),YY(1)) the standard expects that MM(1000000) is equivalenced with YY(1000000), which, for contiguous arrays, only happens if they elements are the same size. > In particular, I would like you to quantify what you mean with: >>For an array with more than one dimension, =n. > let n equals 1 to 6 be given. INTEGER MM(50,50,50,50,50,50) takes up over 50GB and each subscript would fit in an 8 bit integer. -- glen
From: Wade Ward on 4 Oct 2007 15:53
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:qLidnX_4T_aNqJnanZ2dnUVZ_r6rnZ2d(a)comcast.com... > Wade Ward wrote: >> "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote > (snip) > >>>Since Fortran expects the default INTEGER and REAL to be the same >>>size, it is not convenient to increase the default INTEGER to 64 bits. [reordered for thematic reasons] > the standard expects that MM(1000000) is equivalenced with YY(1000000), > which, for contiguous arrays, only happens if they elements are the > same size. > >> In particular, I would like you to quantify what you mean with: > >>>For an array with more than one dimension, =n. > >> let n equals 1 to 6 be given. > > INTEGER MM(> takes up over 50GB and each subscript would fit in an 8 > bit integer. I write in the free format style. I'm going to retype your points in lower case: integer mm(50,50 ;50,50,50,50,50,50) How big is this ^^ (exactly{I assume there is a closed form soln as a function of n alone. Looks like a hypercube to my eye.}), , and, what syntax error crops up from the swap from a comma to a semi-colon? >> Will you elaborate? > > INTEGER MM(1000000) > REAL YY(1000000) > EQUIVALENCE (MM(1),YY(1)) > integer mm(1000000) > real yy(1000000) > equivalence (mm(1),yy(1)) I think I got my keystrokes to happen. I have icy hot and mousse on my fingers and am doing a better job typing. The way to put your hands on the fast track to healing is to have them surrounded by a colloid of some type. Joy juice works, but who wants to have goo on his keyboard? The stuff that a good barber puts on your melon, after he's finished shaving your whitewalls but before the mini-massage, coats the fingers without turning your mouse into yuckiness. Can someone provide an instance of a toy program that uses the following in a meaninungful way: integer mm(1000000) real yy(1000000) equivalence (mm(1),yy(1)) , prfereably NOT in the manner that likely is upthread. -- wade ward "The final irony is that cops and rodney king have the same IQ." |