Re: Writing fast compilers... (Henry Spencer)
Tue, 20 Aug 1991 22:41:44 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Writing fast compilers... (1991-08-13)
Re: Writing fast compilers... (1991-08-14)
Re: Writing fast compilers... (1991-08-16)
Re: Writing fast compilers... (1991-08-16)
Re: Writing fast compilers... blenko-tom@CS.YALE.EDU (1991-08-16)
Re: Writing fast compilers... (1991-08-18)
Re: Writing fast compilers... (1991-08-20)
Re: Writing fast compilers... andy@DEC-Lite.Stanford.EDU (1991-08-21)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Henry Spencer)
Keywords: design, performance
Organization: U of Toronto Zoology
References: <> <> <> 91-08-079
Date: Tue, 20 Aug 1991 22:41:44 GMT

In article 91-08-079 (Dan Bernstein) writes:
>> ... In an ideal world, these are things you *would* want to leave to
>> the compiler, so that your code would run well on any machine, rather
>> than well on one and poorly on others.
>I disagree, for two reasons. First, current optimizers are incompetent.
>[It's not clear what the second reason is but it seems to be similar.]

Dan appears to have overlooked the "in an ideal world" part of my posting.
Clearly an ideal world includes competent compilers.

>If you follow Henry's advice...
>Chances are your code will work poorly on most machines. If, on the
>other hand, you provide a switch to choose between different versions,
>your code will work well on all machines.

Actually, better yet is to find a way of expressing what you want to say that
runs reasonably well on all machines, and then hope that the compiler will
cope with any highly machine-specific optimizations. Doing this can be
difficult but is typically rewarding. Switches very often get set wrong,
unless the audience for your software is experts only. Machine-specific
optimizations, even under the control of #ifdef, should be a last resort only;
portability is just too important nowadays, and maintaining multiple copies of
the "same" code is tedious and error-prone.

(Incidentally, the statements in the preceding paragraph are from often-
bitter experience with C News, which is noted for being portably fast on a
huge variety of machines. Someday there may be a paper on our experiences
with it.)

My point was that one should distinguish such pragmatic strategies, aimed at
coping with the current unsatisfactory situation, from the way things ought to
be. Many of the more-or-less portable optimizations people talk about are, on
closer inspection, somewhat machine-dependent; they *are* often worthwhile in
a pragmatic sense, but we should not kid ourselves about their nature, or stop
pestering our compiler vendors to make some of them unnecessary.
Henry Spencer @ U of Toronto Zoology utzoo!henry

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.