Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.lang.c Subject: Re: C vs. FORTRAN (efficiency) Message-ID: <1613@mcgill-vision.UUCP> Date: 15 Aug 89 08:25:47 GMT References: <3288@ohstpy.mps.ohio-state.edu> <225800204@uxe.cso.uiuc.edu> <14523@bfmny0.UUCP> Organization: McGill University, Montreal Lines: 57 In article <14523@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > In article <225800204@uxe.cso.uiuc.edu> mcdonald@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. >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@larry.mcrcim.mcgill.edu