🚀 go-pugleaf

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 reply:
>> 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.

The point is that it is always more difficult to maintain hand-tweaked
code. And the reason that C sucks rocks for that code sequence is
because of aliasing.

This is the fun part of "talking" to Dan. He will quibble until the
cows come home. He will tell you "It's ok if I have to unroll 10,000
loops by hand and do common sub-expression elimination by hand, C is
still a great language for expression array routines." He will tell
you Fortran is maintinance hell because he doesn't know how to use
IMPLICIT NONE or the portable equivalent. 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?

Well, I think I'm joining Jim Giles. Sorry that nobody liked Dan's
great theories on comp.theory, looks like comp.lang.misc has a similar
opinion.

Bye.