Re: Unsafe Optimizations (formerly Compiler Design in C...)

holub@violet.Berkeley.EDU ()
Fri, 15 Jun 90 03:33:56 GMT

          From comp.compilers

Related articles
Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-12)
Re: Unsafe Optimizations (formerly Compiler Design in C...) moss@cs.umass.edu (1990-06-13)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) larus@primost.cs.wisc.edu (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grover@brahmand.Eng.Sun.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) barmar@Think.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) henry@zoo.toronto.edu (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) dan@kfw.com (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chip@tct.uucp (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grunwald@foobar.Colorado.EDU (Dirk Grunwald) (1990-06-20)
[5 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: holub@violet.Berkeley.EDU ()
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun14.152612.2374@esegue.segue.boston.ma.us>
Date: Fri, 15 Jun 90 03:33:56 GMT
Organization: University of California, Berkeley
Keywords: compiler design, C, unsafe optimizations

In article <1990Jun14.152612.2374@esegue.segue.boston.ma.us>
marti@inf.ethz.ch writes:


> I'm curious just exactly what a slow (or fast) language is.
> Or a more or less powerful language, for that matter.
> I thought that speed was a matter of a particular *implementation*
> of a language. But then what do I know ...


        Though implementation details, of course, control the speed of two
compilers that implement the same language, some languages are intrinsicly
slower or faster than others. Inherently interpretive languages are slower
than compiled ones. Nroff provides a case in point. Nroff lets you assemble a
variable name in a string at run time, and then access the variable through
that string. A compiled version of nroff would have to keep the symbol table
around at run time--and do the symbol-table lookup at run time--to handle
this case. Other examples: LISP usually has to do garbage collection whether
or not it's compiled, and all LISP programs are not compilable since LISP
code can be self modifying. Nroff and vanilla LISP both have to do loops with
recursion (and nroff has to use global variables as loop counters, so
optimization is difficult there). C++ takes time to do the indirection
implicit in a virtual-function call. The examples are legion. Of course, all
of the slower languages have features that often make up for the speed trade
offs, but if you don't need these features, there's no point in programming
in a language that has them.
        As for power, has Mr. Marti ever tried to write an operating system or a
compiler in IBM/PC BASIC or in Pascal? It may be possible, but it takes some
work. I have to admit that the slower languages are often the more powerful
ones, but I think that my comments about programmer control of optimization
strategies are still valid.


Mr. Marti also writes:


> ... the only problem is that, as a consequence, your programs might make
> about as much sense as your comments above.


I think that both my comments and my code make perfect sense. It seems to me
that the net is no place for insulting language. If Mr. Marti wants to
criticize my code, fine--I'm always happy improve my code through both
discussion and constructive criticism, and I think that everyone can benefit
from this sort of discussion. But he should mention specifics, not throw out
general disparagement.


-Allen Holub
  holub@violet.berkeley.edu
[I usually return messages with ad-hominem comments, my mistake for not
catching that one. But as far as compilability goes, I've seen enough
whiz bang compilers to be sceptical of claims that some languages are
inherently inefficient. -John]
--


Post a followup to this message

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