Fortran vs. C for numerical work (SUMMARY)

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Wed Nov 28 17:04:10 AEST 1990


In article <7097 at lanl.gov> ttw at lanl.gov (Tony Warnock) writes:
> >I agree that this is a problem. However, the double-pointer solution
> >usually allows faster access than the standard method of storing arrays,
> >doesn't waste much memory, allows more flexibility, gets around the
> >memory management problems of some small architectures, and lets you use
> >a[i][j] for *(*(a + i) + j), all within current C. It is extremely
> >difficult to do this efficiently in Fortran, and it will continue to be.
>     What is it that Dan thinks is difficult? He uses only "this"
>     so it is not clear what he has in mind. Fortran has allowed
>     one to write a(i,j,k,l,m,n,p) for years.

Sorry. I said ``The double-pointer solution allows X, Y, Z, W, and A,
all within current C. It is extremely difficult to do this efficiently
in Fortran, and it will continue to be.'' By ``this'' I was referring to
the double-pointer solution, not to any of its particular features.

> If the subscripts
>     are chosed at random, how does having a pointer help: the
>     necessary offset must still be gotten somehow.

Huh? A double-pointer array, as we were discussing, is a
single-dimensional array of pointers to single-dimensional arrays. To
access a random element of the array takes two additions and two memory
references. In contrast, to access a random element of a flat array
takes two additions, a multiplication, and a memory reference. On most
widely used machines, a multiplication is quite a bit slower than a
memory reference, particularly a cached memory reference. That's why
double-pointer arrays are better than flat arrays for so many
applications.

Fortran can't deal with a double-pointer array efficiently because it
doesn't have pointers. Simulating pointers efficiently is what I was
calling difficult. Do you disagree?

---Dan



More information about the Comp.lang.c mailing list