optimization (was Re: C vs. FORTRAN (efficiency))

[Earl H. Kinmonth]

In article <1989Aug20.024207.29079 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>Flint Pellett (flint%gistdev at uxc.cso.uiuc.edu) writes:
>
>Flint, have you ever used a punchcard-based batch environment with a
>turnaround measured in hours?  I have.  I'll take timesharing, thank you.
>And I'll take the fastest compiles I can get.

It's not quite that simple. I started programming in 1968 (yes, Bunky,
they had computers back in the dark ages). Sometimes the turnaround was
more than hours. A hardware failure could easily make it two or three
days. On the other hand, the usual two, three, or four hour turn around
was just right for a starving graduate student. I could honestly bill
the waiting time as part of my research assistantship at the same time
I was reading in my primary field (Japanese history).

With faster processors, but not really fast processors, waiting time
has dropped to the point where it is just about right for picking your
nose, but not for heavy weight intellectual activity such as reading a
chapter in a non-computer book.

I know that the faster the processor, the more prone I am to rely on
the compiler for syntax checking. When the turn around was in hours or
days, I really checked, and in the course of doing so, often found
logical errors.

I too dislike arguments that suggest that faster processors lead to
sloppy code. On the other hand, I would like to see some honest
research on the subject, so that it is not just a matter of rump
ideological assertions....