Re: Is Fortran still faster than C for math applications?

Janne Blomqvist wrote:

glen herrmannsfeldt wrote: 

In many cases it might be true.  C tends to be a lower level language,
which in many cases will result in smaller, faster code.


I'm not so sure about that. Surely a Fortran binary will be slightly
larger than the corresponding C program, since it needs to link in the
runtime library (in addition to libc), init it and start the main
program etc. But, unless your computing experience consists of hello
world or equally trivial programs I have a hard time imagining that
the above might actually make any significant difference.


Are you disagreeing that the C code will be smaller?  In any case,
independent of the amount of library code linked in the real question
is how much is executed.

This is likely to be more true for character 

Might be. I guess most Fortran implementations keep the length around
somewhere (although I guess in many cases, it can be determined at
compile time). That'll waste some space compared to the C way, but
then again you don't need to iterate over the string to find the
length.


In some cases the C way is better, in others the Fortran way.
Generating a long string with strcat() in a loop will certainly show
the advantage of keeping the length around.

As most numerical (number crunching) algorithms require a reasonable
amount of fixed point operations, such as array indexing, it might be
that C would be faster in those cases.


Hmm, I would be surprised if Fortran compilers did something
substantially suboptimal wrt array index calculations. I guess you
could do essentially the same in C with a rank 1 array, and having
macros to do the index calculations (different macros for different
rank access, special casing stride 1, etc.). Then again, if you did
the array of pointers to arrays thing in C you could end up with
something quite slow, I guess again mainly due to our old friend
aliasing.


It is likely system dependent whether Fortran calculated offsets are
faster than the usual C array of pointers method.

Considering aliasing, though, I am not sure it slows down C so much
as it would Fortran.  Consider Fortran code such as:

      SUBROUTINE X(A,B)
      REAL A(100),B(100)
      A=A+B(10)
      RETURN
      END

Now, the compiler doesn't have to worry about aliasing because
the language disallows it.  Consider the similar C code:

void x(a,b) {
   float *a,*b;
   int i;
   for(i=0;i<100;i++) a[i] += b[10];
   }

The compiler again doesn't have to worry about aliasing because
C makes no claim regarding b[10] not changing in the loop.
Well, C pretty much requires b[10] to be refetched each iteration.
If one wanted to avoid that, and the possible change in b[10],
one would code:

void x(a,b) {
   float *a,*b,c;
   int i;
   c=b[10];
   for(i=0;i<100;i++) a[i] += c;
   }

As a lower level language, C leaves it up to the programmer to
write what is actually needed.

On the other hand, that isn't a very common operation.  More likely
one would pass (by value) a scalar variable to be added, or pass an
array to be added:

void y(a,b) {
   float *a,*b;
   int i;
   for(i=0;i<100;i++) a[i] += b[i];
   }

The compiler will have to fetch each element of a and b before
storing an element of a, though that is the most likely implementation.
It could be called with partially overlapping arrays.

Because of Fortran requirements on array operators, if aliasing were
allowed a temporary array would be needed.

-- glen

.

Relevant Pages

  • Re: "free space" with declared type
    ... As for aliasing, I think it is reasonable to assume that no nasal ... I think it would be Standard-compliant if pointers ... a case discussed before on aliasing int aarray, ...
    (comp.lang.c)
  • Re: gdb not catching out-of-bounds pointer
    ... that, for example, accesses one array from a pointer to another is ... fundamental for any type of general memory managment. ... Then you are using the term 'aliasing' in a way unfamiliar to ...
    (comp.unix.programmer)
  • Re: FORTH levels
    ... procedure copy_ints(var src, dest: array of longint); ... Pointers can be compared in c if they point into the same array. ... So src can only be smaller than dest if you are essentially passing ... If you are not aliasing, ...
    (comp.lang.forth)
  • Re: contiguity of arrays
    ... >>not applicable to aliasing as array of some other type. ... It's an open question whether the special dispensation for dynamically ... be possible to infer such a principle from the description in 7.20.3: ...
    (comp.lang.c)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)