Integer 4 or integer 8?

[ivanpribec]

@PierU

And F202Y will make it simpler, by allowing to define what should be the default integer/real/logical/character in each programming unit.

Is this just for literal values?

@PierU

In practice, I almost never need more than the default 32 bits integers, although I am regularly manipulating arrays with 10**10 elements or more, but they are multi-D arrays, and each dimension is much less than what a 32 bits integer can handle.

When I posted yesterday, I similar thought crossed my mind, that using N-d arrays can help raise ceiling of what you can effectively address with 32-bit signed integers. Also array expressions could help avoid loops, but not always. However size(a) would still overflow, unless you include the kind argument - size(a,kind=long_int).

Coincidentally, I noticed that one of the citing works of the ACM article I linked above, proposes using a two-dimensional virtual address space:

Pierre Michaud. What about a two-dimensional virtual address space?. RR-9563, Inria. 2024, pp.27. ⟨hal-04816363⟩

In Section 6.1 the author discusses multi-dimensional arrays and how a 2-d address space can solve the the array-of-struct vs. struct-of-array dilemma. It’s interesting to note w.r.t to this point, that by using the assumed-shape array abstraction in Fortran, you can write algorithms, which support both contiguous and strided layouts with just “half” the programming effort.

And with parameterized derived types, you can switch between layouts (it was @Reinhold_Bader that showed me this),

type :: soa_or_aos(n)
    integer, len :: n
    real :: x(n), y(n), z(n)
end type

type(soa_or_aos(:)), allocatable :: points(:)

! Struct of Arrays
allocate(soa_or_aos(n) :: points(1))

! Array of Structs
allocate(soa_or_aos(1) :: points(n))

! Array of Struct of Arrays
allocate(soa_or_aos(8) :: points(n/8))

Admittedly, the nested arrays kill the elegance of array referencing in the AoS and AoSoA cases. Also compilers still suffer from abstraction penalty.

---

@JohnCampbell

If this is not fit for purpose for 64-bit memory addresses, then the Standard should be updated, rather than constrain Fortran’s future use.

While I understand the convenience of good defaults and the frustration when these get in the way; I think a proposal to change this would be hard to motivate without compelling examples beyond size(). As @PierU already explained, the standard provides the mechanism using kind specifiers. Vendors provide flags like -fdefault-integer-8 but this is a heavy hammer.

In the linked ACM article there is an interesting anecdote,

SGI (Silicon Graphics). Starting in early 1992, all new SGI products used only 64/32-bit chips, but at first they still ran a 32-bit operating system. In late 1994, a 64/32-bit operating system and compilers were introduced for large servers, able to support both 32-bit and 64-bit user programs. This software worked its way down the product line. A few customers quickly bought more than 4 GB of memory and within a day had recompiled programs to use it, in some cases merely by changing one Fortran parameter. [emphasis added]

Either this was a change from integer*4 → integer*8, the addition of a compiler flag, or a change to the integer(kind=...) specifier, I can’t say.

In the other article I linked, written by DEC, HP, IBM, Intel and others, found the opposite to be true:

A significant number of applications use C and FORTRAN together – either calling each other or sharing files. Such applications have been amongst the quickest to find reason to move to 64-bit environments. Experience has shown that it is usually easier to modify the data sizes/types on the C side than the FORTRAN side [emphasis added] of such applications, and we expect that such applications would require a 32-bit integer data type in C regardless of the size of the int datatype.

In C I imagine, you would use a tool to replace all int with myint and place a typedef at the top of your main:

typedef intptr_t myint;

The problem is that this is a cascading change, that needs to be propagated through all (third-party) libraries and build scripts. In some places you may need to rewrite the code if it silently relied on the assumption that int was 32-bit.

This reminds of a chapter from the novel The Goal by E. Goldratt. The protagonist is on a hike with his son’s group of boy scouts. Due to his weight, one of the boys, Herbie, is a slow walker. The troop of boys has to finish the hike, but they can’t finish unless Herbie finishes. To finish the hike, they need to help Herbie finish. This is the central analogy in the book which introduces the concept of bottlenecks.

As long as there is software around that relies on 32-bit int (and long and pointers), it will be hard to move on. For instance, Intel only deprecated the IA-32 compiler last year: Intel Fortran Compiler (version 2025.0.0) - #2 by johnalx, and there is a long tail of users. At the end of the day, there is a reason we call it software, because it is meant to be reprogrammed if needed.