32 to 64? 1

[JohannesRS]

Hi all.

I'm having some serious doubts about the porting code from 32-bits to 64-bits subject.

Basically, since all the documentation about such a subject that I find is clearly directed to C and C++ useres, it becomes useless for me.

I would like to know when, where and how some pieces of fortran (specially 90 and 95) shall be modified in order to get it having appropriate use of the 64-bit capabilities.

Moreover, I would like to ask whether or whether not there will be significance in using "float" instead of "double precision" in such machines.

Thanks a lot in advance,

Sincerally yours,

Jones

 

[xwb]

If you tend to use declarations like

INTEGER*2
INTEGER*4
INTEGER*8
REAL*8
REAL*4

whatever you're working in, whether it be 16, 32, 48 or 64 won't make any difference since you've specified the storage. If however, you use declarations like

INTEGER
REAL

it makes a lot of difference since the integer is based on a machine word. It could be 32 bits on a 32 bit machine and 64 bits on a 64 bit machine. The bit that will need some thinking is types.

type::Interleave
   character*1:: id
   integer*4:: idnum
   character*3:: title
   integer*4:: count
end type Interleave

type::Aligned
   integer*4:: idnum
   integer*4:: count
   character*1:: id
   character*3:: title
end type Aligned

The first declaration will take up more space than the second since the members cannot by packed into words.

 

[JohannesRS]

Thanks, xwb.

Just asking a bit more: the second piece of the aswer is a only way to "boost" a fortran program, not considering the 64 or 32 bits, correct? Is there anything that I'm not noticing that could make explicit use of the 64 bits to accelerate a fortran code?

About the first piece: yes, I've always been a very bad programmer... All my codes do not define explicitly the precision of the integers and reals. No problems while locked in 32 bits, Problems now with the transition. Am I wrong, or a proper transition now means that I should explicit write REAL *8 instead of REAL, and INTEGER*4 instead of just INTEGER, in order to get the exact same results?

 

[xwb]

Other than telling the compiler that you want 64 bit compilation, I can't think of anything that will make explicit use of 64 bits.

64 bit code can be slower as well as faster, depending on what you're doing. On 64 bits, INTEGER*8 will operate faster than INTEGER*4. INTEGER should default to INTEGER*8 but that depends on the compiler.

Yes, if you tell the compilers exactly what you want like INTEGER*4, you should get the same results. It may run faster or slower than the 32bit version.

 

[JohannesRS]

Thanks a lot, xwb!

Just a bit more: In case of reals, real in a 32 bits system should be specified as a real*8 in a 64 bits machine, while real*16 and double precision would mean the same in both 32 and 64 bits machines, correct?

Also, about aligning, it just concerns about derived types, correct? Also, how can I know the proper ordering in that case?

Thanks a lot again!

 

[xwb]

I think it is the same on both 32 and 64 bits but this tends to be vendor specific.

real = real*4 - normally IEEE S_floating
double precision = real*8 normally IEEE T_floating
There is no real*16

It may be that some vendors have both real and dp the same.

It is very difficult to find out about alignment in Fortran because the standard has made it so tight on casting. In the old days, you just equivalence two different types, say a char array and a real, set the char array to say all As and then assign the real to a value, dump out the char array and see how much got filled. You just can't do that in F90/95. The only thing I can think of is to write the derived type to a binary file and then use a binary editor (hexedit is a good one on windows or od on linux/unix) to look at it. It will also tell you the endianess of the machine. Note that implementation again is vendor specific. The derived type members may be stored back to front like on some C compilers.