Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <19260:Nov1608:07:0790@kramden.acf.nyu.edu>
Date: 16 Nov 90 08:07:07 GMT
References: <1990Nov8.024049.9731@murdoch.acc.Virginia.EDU> <23461:Nov904:59:2290@kramden.acf.nyu.edu> <1990Nov16.042141.21130@murdoch.acc.Virginia.EDU>
Organization: IR
Lines: 88

In article <1990Nov16.042141.21130@murdoch.acc.Virginia.EDU> gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes:
> In article <23461:Nov904:59:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> [ I give an example where FORTRAN optimizes well, but C must be
>   hand-optimized. Dan claims "But look, I can get the same performance
>   by tweaking the code."]

I was just making a simple observation about the code example you
posted. I tried to avoid controversy there because I didn't want to
distract people from the following points:

1. The compiler can do quite a bit of aliasing analysis without taking
any hints from the programmer (and respecting separate compilation).
I've inspected several large Fortran programs, and in each one I observe
that this sort of analysis would suffice to detect the aliasing even if
aliasing weren't prohibited beforehand. In other words, C doesn't have a
huge disadvantage over Fortran just because it allows aliasing.

2. The compiler cannot optimize pointer-free code into pointer code in
all cases. Hence there are cases where a C array program using pointers
will be faster than a Fortran array program, no matter how good the
Fortran optimizer is. The language has to provide some form of pointer
arithmetic (i.e., array shifting). If I understand Jim correctly, the
new Fortran does exactly that, and so I'm willing to believe that it can
express array computations as efficiently as C in all cases.

Now returning to the side issue:

> >> Great, you've just doubled the # of lines of code. This is known as
> >> "creating a maintenance nightmare".
> >I thought we discussed this before? The way you maintain hand-optimized
> >code is to keep around the original, clean, algebraic version, as well
> >as the new, ugly, optimized version.
> I know how to maintain code.

I believe you.

> The point is that it is always more difficult to maintain hand-tweaked
> code.

Agreed, but hand optimization is still a viable technique. Sometimes
it's the only choice.

> He will tell
> you Fortran is maintinance hell because he doesn't know how to use
> IMPLICIT NONE or the portable equivalent.

There isn't any portable equivalent. On some machines, if I want to use
Fortran, I have to deal with Fortran IV compilers. I'd rather use Pascal
than deal with these syntactic problems.

> And, best of all, at the
> same time as I am demonstrating that there are cases in which C
> pointers cause big optimization problems he will claim in another
> thread that pointers are never less efficient than arrays. Sure, Dan,
> we all have lots of time to tweak code by hand when an optimizer can
> do it for us. Isn't that why HLL's were invented?

See, here's where you simply fail to pay attention to the main points of
the thread. A sufficiently smart compiler *can* do the job for C,
without *any* hand optimization. Current compilers happen not to be that
smart. Would you please stop misrepresenting my position?

Now I'd like everybody to notice something. Jim made exactly the same
argument about arrays as I've made in the above paragraph about
aliasing. He said that a sufficiently smart compiler can find the right
base to precompute for Fortran array references. He said that current
compilers happen not to be that smart.

The difference is that Jim didn't post the method that his sufficiently
smart compiler would use. I did the job. I showed what it would take to
deal with aliasing. Jim just waved his hands and made some vague
assertions about how arrays are always as efficient as pointers. And so,
as it turns out, he was completely wrong.

Of course, Greg hasn't even made the effort that Jim has to contribute
to the discussion. He has completely ignored my comments on how the
compiler can optimize C array code with no help from the programmer.
Instead he has focused on my offhand remark about his Fortran example.
Sigh.

> Sorry that nobody liked Dan's
> great theories on comp.theory,

Actually, some people already knew what I was talking about, and
commented upon the usefulness of the technique (as two people have done
in this group). Again you ignore the discussion.

---Dan