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

marti@inf.ethz.ch
Thu, 21 Jun 90 03:30:44 GMT

          From comp.compilers

Related articles
[8 earlier articles]
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)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) kend%mrloog.wr.tek.com@RELAY.CS.NET (Ken Dickey) (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chittamu@dino.cs.umass.edu (1990-06-22)
Re: Unsafe Optimizations (formerly Compiler Design in C...) harrison@necssd.NEC.COM (1990-06-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: marti@inf.ethz.ch
References: <1990Jun15.033356.2061@esegue.segue.boston.ma.us> <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun14.152612.2374@esegue.segue.boston.ma.us>
Date: Thu, 21 Jun 90 03:30:44 GMT
Organization: Compilers Central
Keywords: compiler design, C, unsafe optimizations

an earlier posting from me:


> >> 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.


First off, Mr. Holub hasn't really answered my question: What is a slow
(or fast) language? If there's a (more or less) scientific definition
of the speed of a language, I'd definitely like to hear it!


Similarly, what is your definition of the power of a language? One way
to measure the power of a language is whether it is equivalent to a Turing
machine, another -- used in the world of logic programming and databases
-- whether it is equivalent to 1st order logic. Yet another way might be
to measure the length of the source code required to accomplish a particular
task.


You seem to define power in terms of "being able to access things like
machine registers and the like". While I recognize that doing this
kind of low level programming is important for many things, I wouldn't
use it as a basis for the definition of the power of a language.


As for nroff: I was under the impression that we were discussing languages
such as the huge family of Algol descendants (including C and Modula-2,
to name just two of them), and judging from another posting in this group,
I am not the only one ...




> 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.


While I agree with this, it only means that on today's typical hardware
architectures with todays typical LISP compiler/interpreter technology, LISP
program is very likely to be slower than an equivalent (whatever that exactly
means) C program. Moreover, having garbage collection saves you from doing
your own memory management, so the average LISP program will turn out to be
shorter. Hence, you might call LISP a slower, but more powerful language.


> C++ takes time to do the indirection implicit in a virtual-function
> call. [ ... ] 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.


The above comments on the "power" as measured by program length applies
to C++ vs C as well. Moreover, you only pay for the overhead of virtual
functions when you use them. And finally, for a certain class of problems,
you might just end up implementing the virtual function mechanism all by
yourself. (Admittedly, for special cases you might be able to do this
a little more efficiently than a compiler which has to deal with the
general case.)


> As for power, has Mr. Marti ever tried to write an operating system or a
> compiler in IBM/PC BASIC or in Pascal?


I find the reference to BASIC a cheap shot. However, yes, I did write
several compilers in Pascal. I thought it was very easy to do.


> Mr. Marti also writes:
>[something rude -John]


I admit that I was being a little harsh here. My apologies for this.
In particular, I have never seen any of Mr. Holub's code. However,
I question the sense of talking about the speed and power of a
language without a definition. It does remind me of using a
variable (or calling a function) without declaring them. So maybe,
just maybe, the "compiler fascists", as you call them, do have a
point every now and then ...


--
Robert Marti Phone: +41 1 254 72 60
Institut fur Informationssysteme
ETH-Zentrum Internet: marti@inf.ethz.ch
CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
--


Post a followup to this message

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