Re: Why C is much slower than Fortran

On 30 Apr 1999, Daniel Barker wrote:


> void f(unsigned int *ip, int lim, size_t *used, unsigned char byte_val)
> /* for each element i of the lim-element array whose first element is
> * pointed to by ip, set the first used[i] bytes to byte_val and the
> * remaining bytes to zero; used[i] must lie in the interval
> * [0, sizeof(unsigned int)]; the resulting value of ip[i] is
> * implementation-defined */
> {


[snip]


> }


(As someone has kindly pointed out, the action of the function did not
match this comment. Apologies.)


[snip]


> [C lets you alias anything to anything, and that does indeed cause
> optimization problems. The C9X draft has a "restrict" keyword that lets
> you assure the compiler that a pointer doesn't have aliasing problems.
> I presume the MIPS hack says that only data of the same type can be
> aliased, sort of the same thing here. -John]


Might a mechanism to specify independence of loop iterations (for whatever
reason) have been more useful than a mechanism to restrict pointers?


For example, consider this code, using permutation vectors:


    /* ... */


    int a[LIM]; /* array of scalars */
    int b[LIM]; /* array of scalars */


    int ac[LIM]; /* array of cursors to a */
    int bc[LIM]; /* array of cursors to b */


    int i; /* loop counter */


    /* ... set all elements of "a" and "b"; set each element of "ac" to a
      * different value in the interval [0.."LIM"-1]; set each element of
      * "bc" to a different value in the interval [0.."LIM"-1]; and then ...
      */


    for (i = 0; i < LIM; i++)
        a[ac[i]] = a[ac[i]] * b[bc[i]];


Array "a" is only accessed through a single (implied) pointer and array
"b" is only accessed through a single (implied) pointer. But this says
nothing about whether the iterations of this loop are independent. I do
not see how C9x's "restrict" could help much here. It could inform the
compiler that the arrays in question, "a", "ac", "b" and "bc", do not
overlap. However, if the array definitions are visible (e.g.,
function-scope within the function including the loop), the compiler could
already deduce this without "restrict".


Permutations also a present a problem for optimized FORTRAN 77
compilation, though there exist implementation-dependent ways around the
problem in either C or FORTRAN. (I do not know enough Fortran 90 to say
where that lies.)


Another area a more general "independence" directive would be useful is if
there is a function call in a loop:


    int f(int i)
    /* a "pure" function, relying on nothing external, static or
      * I/O-related */
    {
        return i * i;
    }


    /* ... */


    for (i = 0; i < LIM; i++)
      a[i] = f(a[i]);


If f() is compiled separately from the function including the loop, it
might be useful for the programmer to tell the compiler that all calls of
f() are independent, and may be performed in parallel. It would be
possible to specify this in the interface to f(). However, specifying it
at the loop would allow the same mechanism to be used as with the above
code using permutations.


If neither C9x nor ANSI C++ has a standard "independence" directive, this
is a shame, and I hope one is added in the next standard along the line.


Daniel Barker.
[I believe that you could declare restricted pointers within the loop to
give the compiler the required hint. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.