From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: William Chesters <williamc@dai.ed.ac.uk>
Subject: Re: speed versus C
Date: Mon, 11 Oct 1999 22:50:17 +0200
Message-Id: <99101201303001.12255@ice>
On Sun, 10 Oct 1999, William Chesters wrote:
> My point was simply that nearly every* feature of ocaml, however
>abstract in appearance, compiles directly, and compositionally, onto
>an idiom which one might well use in C or even assembler---give or
>take some amount of sugar. Looking at this fact one way round, I
>observe that the reason ocaml is so fast is that it mostly* stays
>within the framework of the traditional computer model; looking at it
>from the other direction, I note that the constructs which ocaml maps
>onto the various different C idioms illuminate the "deeper meaning" of
>the latter in terms of a much more abstract semantics.
Perhaps I have a too traditional understanding of C idioms, I think they first
reflect what is simple to write in the context of the language. Of course,
there is the wish of the users of the language who want to express their ideas,
i.e. the conceptual side of abstraction. These wishes are really an interesting
field, they are driven by several motives. On the one hand, there is often a
technical need to use abstraction, e.g. to make the program structure simpler.
I think your Linux example falls into this category. On the other hand,
abstractions are the basis how we think about programs, because they instruct us
which thoughts are considered reasonable and which not. If you, for example,
study functional languages and then read your old C programs again, you might
detect some deeper meaning in it. I do not want to judge if there is really
deepness, but I think the more interesting point is that your way of thinking
about programs has changed in the meantime, and you can interpret the idioms of
the language in a different context. I still do not accept that the Linux
closure example has all aspects I expect from a closure, but I admit that you
can find many aspects of a closure in it (perhaps 90%), i.e. it can be
interpreted on this background.
The point is that although there is a technical (operational) meaning of a
programming construct this is not the whole truth. Since I program in Caml I
have learned to think with closures, i.e. I always consider to create an ad-hoc
function which refers to the current value of the variables. I would never do
so when programming in C unless because of a strong requirement; it would be too
much work. (And the aspect that closures often have an "ad hoc nature" is
completely lost.)
There are much more drastical examples where a computational model is simulated
by a different one. Ever seen a grammar working like a Turing machine? This is
not only of theoretical interest, because both models stress important aspects
of EVERY computational model, and by studying them you can get more insight
into them. For example, a grammar is by definition non-deterministic, and by
studying them you can learn what it really means that there is no specific
order how the instructions are executed. This lesson may be instructive if you
are going to program with lazy evaluation (which has an order, but impossible
to survey).
The relationship between C and Caml is similar because both have a different
"history of semantics", and each may illuminate the other. Of course, both
share that it must be possible to run the programs efficiently on real
hardware, and this makes the discussion so controversial.
> Compare this with lazy languages, with which the whole discussion
>started: they must necessarily use the traditional CPU in a pretty
>contorted way to implement a basically foreign computational model.
>(Graph reduction, or however you like to present it.) Compare it too
>with SML/NJ, which supports continuations and therefore has to
>allocate its stack frames on the heap---crazy, because continuations
>aren't all that useful (corresponding most closely to a non-local
>JMP), and noone seems to believe their protestations that this
>implementation carries 0 performance penalty.
I still think that the computational models of the CPU and Caml are very
different, and that it is a lucky result that lambda-calculus with strict
evaluation can be implemented on the CPU very efficiently. This is not a design
decision somewhere in the middle of the development, I think it is a starting
point. Lazy evaluation is a different starting point; you cannot really discuss
whether they are sensible or not, you can only discuss how well the resulting
language is applicable to your problem. I think continuations are different,
because they are not in the center of the language.
> I contend that on the one hand stepping distinctly outside the
>traditional model means slowness, and on the other that the
>traditional model is not a bad one to think in, as long as your
>understanding of it is enriched by experiencing and preferably using a
>language like ocaml (and/or C++).
I was surprised by Caml when I tried it because it was not so slow than I
expected. My point is that there are even some practically useful constructs in
Caml which are faster than the construct a programmer would typically choose in
the same situation in the "traditional" language. I can even imagine that
functional languages are some day faster than traditional ones because medium-
and high-level optimizations are better applicable. But this is only a dream.
Gerd
-- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:27 MET