C vs. FORTRAN (efficiency)

[der Mouse]

In article <14523 at bfmny0.UUCP>, tneff at bfmny0.UUCP (Tom Neff) writes:
> In article <225800204 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>>> The odds are pretty good that somebody asking about relative code
>>> efficiency is worrying about the wrong issues in choosing a
>>> programming language.

>> Somebody serious about relative code efficiency (and mentioning
>> Fortran) probably has a big program.  [...] $20000 of cpu time in
>> one language instead of $40000 in another.  [...300 microseconds in
>> one language, 600 in another, with a 400 microsecond requirement...]

> Yes - they MIGHT.

> More likely, in my experience, they just like the *idea* of efficient
> code, whether or not they can demonstrate just what DEGREE of
> efficiency their application requires.

This is not entirely silly; it pays off big when said person has to
write something where efficiency *is* important for a change.

Of course, it can be (and too often is) carried to excess.

> <Burp> The fact is that every extra hour the applications wonk spends
> trying to get the #*$&@# compiler or linker or OS loader to work, or
> on the phone to some consultant, is worth billions of instructions on
> any processor of his choice.

Yeah, so what?  If I can shave 10% off of my compiles, that's a lot of
time.  Suppose it takes me a week to save that 10%: then after I spend
a total of nine weeks waiting for compiles, I've broken even: that
would have been ten weeks.  After that it's clear gain.

It would take *me* a long time to build up nine weeks of
waiting-for-compile time.  But if the compiler is in use by nine
people, that's *one* week of waiting time per person.  Sixty-three
people and it's a day of waiting time, which might be a week of working
time.

Now, if the compiler is sold to eight thousand customers...I'll let you
work out the arithmetic for yourself. :-)

> Software that works right, and early, is more important that a shaved
> MIP.

*Almost* always.  (I remember a wonderful sentence from somewhere or
other: "Presumably this means it is important to get the wrong answers
quickly."  I do not recall the context or source, but it certainly
sounds good.)

Being able to tell whether a given situation is such that speed is
worth spending effort on is part of what makes a good programmer.
The world needs more good programmers.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu