C vs. FORTRAN

Cleve Ashcraft clevea at bcsaic.UUCP
Thu Aug 17 00:11:30 AEST 1989


In article <14017 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>
>From article <517 at chem.ucsd.EDU>, by tps at chem.ucsd.edu (Tom Stockfisch):
>
>> Sparse matrices are also easier in C.
>
>I've heard this claim before, but I've never seen any advantage of either
>language for this.  In either case, the programmer must code a lot of index
>calculations - the only difference is whether the calculated index is
>added to a pointer or used as a subscript - big deal.
>

as someone who works with sparse matrices, i will agree with the
first statement, with the following qualification. just about
any numerical work on sparse matrices uses the following kernels,
quoted in C syntax.

daxpy :
for ( i = 0 ; i < size ; i++ )
   x[i] += alpha * y[i] ;

daxpyi :
for ( i = 0 ; i < size ; i++ )
   x[indices[i]] += alpha * y[i] ;

ddot :
for ( i = 0, sum = 0. ; i < size ; i++ )
   sum += x[i] * y[i] ;
return sum ;

ddoti :
for ( i = 0, sum = 0. ; i < size ; i++ )
   sum += x[i] * y[indices[i]] ;
return sum ;

in general, these kernels do not have their vector arguments
overlapped, and thus can be vectorized. some type of compiler
directive should be made available to generate good code on
vector machines. however, C has no advantage over Fortran for
these kernels.

where C does have an advantage is found in the ordering of
sparse matrices, the setting up of higher level graph structures,
and the dynamic storage allocation. sparse matrix algorithms
have gone a long way past the simple general sparse algorithm.
references on request.

i switched over to C about 18 months ago, and the productivity
benefits have made it worth it.

cleve ashcraft
clevea at atc.boeing.com



More information about the Comp.lang.c mailing list