Fortran vs. C for numerical work (SUMMARY)

[Tony Warnock]

Dan Bernstein answers [correctly]:
 
>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.
 
 
    Thanks, I didn't get the idea from your first posting.
 
    With respect to speed, almost all machines that I have used during
    the last 25 or so years have had faster multiplications than
    memory accesses. (I have been doing mostly scientific stuff.) For
    most scientific stuff, I think that the scales are tipped in favor
    of array-hood because of the rarity of accessing an arbitrary
    element. Most computations access an array along one of its
    dimensions, holding the others constant. In this case, there is
    only one addition and one memory access whatever the
    dimensionality of the array. There is also no storage overhead
    associated with keeping arrays of pointers. For multi-dimensional
    problems, this overhead could be quite large. Again, for
    scientific problems, there is usually no left over room as the
    entire memory will be taken up by arrays. It doesn't matter how
    much memory is available, my problems will easily fill it and
    still be at too coarse a granularity to be nice.
 
    Anyway, Dan's answer points out the performance differences in the
    array versus pointer access stuff. Personally I just don't user
    pointers much because my problems don't call for them. If I had to
    access multi-dimensional arrays in random fashion very often, the
    pointer solution might be acceptable.
 
    On a slightly different issue: often it is necessary to do row or
    column accesses (or whatever you call them in 3 or more
    dimensions) in the same code. How does one set up a pointer array
    for allowing easy access along each dimension (for example in a
    typical 5-dimensional array)? I use 5 dimensions as typical
    because a physical grid usually is indexed by x,y,z, and time
    indices and also by variable type. That is each point in x,y,z,t
    space has an array of variable present (on bad days it has arrays
    of matrices.)