From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA01107 for caml-redistribution; Tue, 12 Oct 1999 15:45:26 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA32046 for ; Tue, 12 Oct 1999 01:30:50 +0200 (MET DST) Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id BAA00394 for ; Tue, 12 Oct 1999 01:30:49 +0200 (MET DST) Received: from ice.darmstadt.netsurf.de (board-17.darmstadt.netsurf.de [194.163.86.145]) by beach.frankfurt.netsurf.de (8.8.5/8.8.5) with ESMTP id BAA15632; Tue, 12 Oct 1999 01:30:47 +0200 (MET DST) Received: from localhost (localhost [[UNIX: localhost]]) by ice.darmstadt.netsurf.de (8.9.3/8.9.3) id BAA17852; Tue, 12 Oct 1999 01:30:30 +0200 From: Gerd Stolpmann Reply-To: Gerd.Stolpmann@darmstadt.netsurf.de Organization: privat To: William Chesters Subject: Re: speed versus C Date: Mon, 11 Oct 1999 22:50:17 +0200 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <24949.199910102048@buckie> Cc: caml-list@inria.fr MIME-Version: 1.0 Message-Id: <99101201303001.12255@ice> Content-Transfer-Encoding: 8bit Sender: weis 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 ----------------------------------------------------------------------------