Intrinsicaly fast/slow languages (WAS: Unsafe Optimizations (formerly Compiler Design in C...))

pardo@june.cs.washington.edu (David Keppel)
Fri, 15 Jun 90 17:22:11 GMT

          From comp.compilers

Related articles
Intrinsicaly fast/slow languages (WAS: Unsafe Optimizations (formerly pardo@june.cs.washington.edu (1990-06-15)
| List of all articles for this month |
Newsgroups: comp.compilers
From: pardo@june.cs.washington.edu (David Keppel)
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun14.152612.2374@esegue.segue.boston.ma.us> <1990Jun15.033356.2061@esegue.segue.boston.ma.us>
Date: Fri, 15 Jun 90 17:22:11 GMT
Organization: University of Washington, Computer Science, Seattle
Keywords: compiler design, C, unsafe optimizations

holub@violet.Berkeley.EDU (Allen Holub) writes:
>[Some languages are intrinsically faster or slower.]
>[For instance LISP, nroff, ...]


If you believe that everything maps to a Turing Machine, then you should also
believe that a ``perfect'' optimizer can produce identical code for versions
of a program written in different source languages. (Of course if you
beilieve in a ``perfect'' optimizer, you should also believe that the halting
problem is solvable :-)


The claim that I've heard, then, is that for many languages if you use the
``FORTRAN subset of the language'' you get performance similar to that of
FORTRAN. If you use the sophisticated, powerful, etc., features, then you
win easy programing and lose performance.


This is patently false for a wide variety of compilers, but it seems like a
laudable goal, and I'm willing to belive that some systems achieve it. For
example, I belive that an Eiffel program that doesn't use any O-O
``features'' runs as fast as C/FORTRAN.


>[All LISP programs are not compilable since some are self-modifying]


Back to the Turing machine argument, I can write an equivalent program in
FORTRAN, and that the FORTRAN program can be compiled statically. The
FORTRAN program will, of course, have all of the ``hidden'' LISP list
operations, bytecode interpreter, etc., open-coded where the programmer has
to look at them.


I claim, then, that the issue is whether there is a *straightforward*
implementation of the language that gives good performance. As compiler
technology matures, the definition of `straightforward' changes as well.


;-D on ( All the world is not a RISC ) Pardo
--
pardo@cs.washington.edu
        {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
--


Post a followup to this message

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