mash@mips.UUCP (03/26/87)
In article <739@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >In article <2910@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >>K&R's forcing things to double precision, as well as not having a >>reasonable way (I know, use temporary variables; that's not >>reasonable!) to force order of evaluation made it almost completely >>unsuitable for doing number crunching. ANSI has fixed both of those >>(or made it possible for compiler writers to fix them). > >Mike, > Not a flame at you, but C was an ugly language to begin with... > _bizarre_ precedence results. Adding the unary plus, which, > to anyone taught mathematics, is a no-op, and making that the > way to control the order of evaluation, just makes an ugly > language uglier. Code that needs to be _that_ fast should > be done in assembly..... > I just can't be very sympathetic, in a time of ever increasing > computer speeds and memory, to optimizing the code at the > expense of the coder. The latter is the big expense item > these days, and has been for over ten years now. I'd be the last one to suggest optimizing the code at the expense of the coder, but the comment seems to be an example of the "unknown domain" problem that often occurs on the net, i.e., someone makes a strong statement like: X just isn't important, and anybody who thinks so is a turkey, because surely my experience is representative of everyone's. when what they really mean is: In MY experience, X just isn't important, and I don't understand the uses of X. A lot of arguments keep going forever in the vein "X is important" ... "No, it isn't", when the argument should be: "in problem domains A,B, and C X is important", but in domain D, it isn't. At least that way, you can have rational discussions [like: in domain A, we disagree about X, or we disagree about the relative importance of domains B and D, or something useful.] To address the comment directly: I'd be the last person to suggest that one should ignore the programming leverage of writing in the highest level language possible [I've spent too much of my professional life preaching otherwise]. However, there are problem domains where your comments are just 100% wrong, i.e., computationally expensive problems, like scientific and CAD software. I've seen optimizing compilers be able to get 2X performance improvements in large programs, and you do NOT want to write those things in assembler, believe me. On the other hand, if all it takes is to assure correct operation is to insert a few pluses, I know large numbers of people who would be delighted to write more things in C. Bottom-line: optimizing C compilers are getting to be available; ANSI is doing exactly the right thing in tweaking the language to allow optimizers to get you the performance most of the time, while allowing you to keep control in those few cases needed. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086