Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!think!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uiucdcsp!johnson From: johnson@uiucdcsp.UUCP Newsgroups: comp.lang.smalltalk Subject: Re: Translating Smalltalk Message-ID: <80500006@uiucdcsp> Date: Fri, 12-Jun-87 10:55:00 EDT Article-I.D.: uiucdcsp.80500006 Posted: Fri Jun 12 10:55:00 1987 Date-Received: Sun, 14-Jun-87 04:01:50 EDT References: <245100008@orstcs> Lines: 54 Nf-ID: #R:orstcs:245100008:uiucdcsp:80500006:000:2921 Nf-From: uiucdcsp.cs.uiuc.edu!johnson Jun 12 09:55:00 1987 Blocks are not what makes Smalltalk slow. Evaluating a block is fairly fast, and creating it is not all that bad, either. Blocks slow down Smalltalk in two ways: contexts have to be allocated on the heap instead of on a stack and it is hard for the compiler to detect and optimize loops. (The compiler does a good job of optimizing IF statements.) The first problem can be reduced by allocating contexts on a stack and converting them into heap-based objects only when required. PS does this. It is certainly feasible to eliminate blocks, since Trellis/Owl shows how it can be done. However, blocks are nice, and I like the ability to invent my own control structures. Method lookup is not what makes Smalltalk slow, either. Most Smalltalk systems use various caching schemes to eliminate method lookup. PS uses in-line caching to achieve a very high hit rate (95%) at a low cost, i.e. only a few 68000 instructions per message send. Dave Ungar's analysis of SOAR revealed that 75% of the time was spent in the primitives. Thus, one could argue that the reason why Smalltalk is slow is that primitives are too slow. My explanation of this is that each primitive has to check its arguments and to do some little calculations that the next primitive will probably redo. What is really needed is an optimizing compiler that optimizes over a group of primitives. My students and I are in the process of writing such a compiler here at Illinois. The language is not 100% Smalltalk, because we have had to introduce types. If the compiler could perform type inference then the compiler would accept normal Smalltalk programs, but as it is, the programmer must enter the declarations. However, we are trying hard to maintain the interactive programming and rapid-prototyping features of Smalltalk, so we try to support most normal Smalltalk programming practices. I am confident that we will be able to generate efficient code, but I am less confident that we will not damage the programming environment. Since primitives are what take the time, it might make sense to build hardware that executes them fast. On the other hand, special purpose hardware is always more expensive than general purpose hardware, and people who already have computers will prefer not to have buy another just to run a particular programming language. Thus, a software solution has many advantages over a hardware solution. (And in any case, I'm not a hardware person!) PS is described in a paper by Deutsch and Schiffman in the 1984 POPL. Ungar's thesis is coming out as one of the Distinguished Theses series from MIT press. If you write to me, I can send you some tech reports on my work. My e-mail address is johnson@p.cs.uiuc.edu (internet) or {ihnp4, ...}!uiucdcs!johnson. My U.S. mail address is Ralph Johnson Department of Computer Science 240 Digital Computer Lab 1304 West Springfield Ave. Urbana IL 61801