Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Declarative languages, efficiency [was:Re: Teaching Assembler]
Message-ID: <4635@utah-cs.UUCP>
Date: Sat, 6-Jun-87 17:54:56 EDT
Article-I.D.: utah-cs.4635
Posted: Sat Jun  6 17:54:56 1987
Date-Received: Sun, 7-Jun-87 10:32:56 EDT
References: <7401@boring.cwi.nl> <2046@a.cs.okstate.edu> <4625@utah-cs.UUCP> <1753@megaron.arizona.edu>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 66
Xref: utgpu comp.edu:382 comp.lang.misc:423

In article <1753@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:

>Recently announced Prolog systems include one from Belgium
>that's claimed to do 200,000 LIPS on a Sun-3/200, and a system by Mike
>Newton of Caltech that gets over 900,000 LIPS on an IBM 3090 ("LIPS" --
>"Logical Inferences per Second" -- is a measure commonly used to benchmark
>Prolog systems.  C-Prolog does about 1500 LIPS on a Sun-3).  Such systems
>look like they'd be competitive with current implementations of procedural
>languages, but of course they typically cost big bucks, so students don't
>see them, and the old, outdated biases live on.

Amen!  Perhaps language outfits should consider gifts to universities of
the sort that hardware types have profited from for years...

On a tangent here: I wish the use of LIPS would die out.  Nobody seems to
have produced a formula relating LIPS to program performance, that is,
how fast an FFT goes or how long it takes to compute all the possible
first moves in chess, given only the rules of the game.

>(I don't know much about the speeds of the latest Lisp systems: got any
>numbers, Stan?)

Lisp systems don't use FCPS (Function Calls Per Second - add 'u's for
entertainment), but Dick Gabriel's Lisp benchmark book does have a list
of various languages running the trivial but highly recursive TAK program.
The list goes from micros to Crays with speeds ranging over three orders
of magnitude.  It includes Franz with small number arithmetic beating C
on a VAX 780 by about 20%, PSL on a 750 being almost twice as fast as C
(Franz being less impressive), and PSL beating C on 68000s as well.  None
of the languages did better than machine code, though some came close
(TAK is about one page in machine language, so easy to optimize).
The Orbit folks at Yale have also presented some impressive results
for Scheme compilation in their 1986 Compiler Conference paper, although
I don't quite believe that good closure analysis is the reason.
Finally, there are some rumors to the effect that Lucid's compiler
is within a few percent of good floating-point Fortran code, but I
haven't seen any details.  The status seems to be that people know
what to do to get the performance, but proprietary code is the only
way to get the money/time to do it.  Also, Joe Student's program is
still going to be slow, because you have to add declarations, set obscure
flags, redefine functions, and do other strange things to get that
good performance (a detail often glossed over by implementors).

>The other complaint I've heard about languages like Lisp and Prolog is that
>they use gobs of memory, and spend a lot of time collecting garbage.  But
>even that isn't entirely valid any more, since recent work by Paul Hudak
>(for applicative languages) and Maurice Bruynooghe (for logic languages)
>shows that a smart compiler can replace a lot of data structure copying by
>code with destructive assignment, and drastically reduce the amount of
>garbage generated.

This is where Lisp is revealed to be lower-level than one might like.
Much generation of garbage can be avoided by using a C-like style, but
of course that misses the whole point of using Lisp in the first place...
I believe the new techniques are somewhat limited in their applicability
and could be defeated.  To repeat a point touched on earlier,  it's not
enough to show good speed on carefully selected problems; the students
should not have to take performance hits just because they didn't use
some strange declaration.  For instance, Hewlett-Packard's Common Lisp
has a "downward-funarg" declaration that makes all closures stack-allocated.
Fortunately, I've never had to explain that declaration to sophomores!

>Saumya Debray		CS Department, University of Arizona, Tucson

							stan shebs
							shebs@cs.utah.edu