🚀 go-pugleaf

In article <1990Nov8.024049.9731@murdoch.acc.Virginia.EDU> gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes:
> In article <2440:Nov607:32:5890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
    [ a[i] = b[i] / c[i]; d[i] = b[i] * c[i] ]
> >Hmmm. I would almost automatically optimize the above into
> >  {
> >   register double bi = b[i];
> >   register double ci = c[i];
> >   a[i] = bi / ci;
> >   d[i] = bi * ci;
> >  }
> 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. Whenever the original, clean,
algebraic version is changed, the new, ugly, optimized version must be
rewritten. You do the same thing with automated source-code optimizers.

> Now take one of my real loops, with 3 lines of code referencing a
> dozen or so array elements, including things like a[i], a[i-2], etc.
> How do you pick the names? How do you keep the programmer from making
> a mistake when they modify one of the lines?

I pick the names by very logical conventions: ai, aim2, etc. It's *very*
easy to remember. As for maintenance, see above.

> I don't see why Dan thinks I should use a hard-to-optimize language
> for numerical programming, which requires the programmer to do common
> sub-expression elimination, when I can use a simple and fast language
> instead.

I don't recommend that you switch from Fortran to C, unless you need
something that the latter provides. I don't use Fortran simply because I
can't stand the maintenance hell when I mistype a variable name. But if
you don't mind that occasional problem, and if you don't need the system
services or dynamic allocation of C, certainly stick to Fortran.

> By the way, this code has loops which can be unrolled 3 or 5 times and
> keep loaded array values from previous iterations for future
> iterations.

Array unrolling is so mechanical that I would trust the compiler to do
it (and I wish optimizer writers would concentrate on taking hints from
the programmer and doing this well, rather than complex optimizations
that humans still do a much better job with!)

> Writing this out by hand is a nightmare when you have to
> permute the temporary register variables.

It isn't that bad. I regularly unroll loops several times. The secret is
macros. Only one of the compilers I use actually understands unrolling,
and I often get 30% improvements on the others with very little work.

---Dan