Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!macrakis
From: macrakis@harvard.ARPA (Stavros Macrakis)
Newsgroups: net.ai
Subject: Re: Thus spake the DoD ... (really - Lisp performance, etc.)
Message-ID: <462@harvard.ARPA>
Date: Tue, 12-Mar-85 13:03:14 EST
Article-I.D.: harvard.462
Posted: Tue Mar 12 13:03:14 1985
Date-Received: Fri, 15-Mar-85 01:44:38 EST
References: <153@clan.UUCP>
Distribution: net.lang.lisp,net.lang.ada
Organization: Aiken Comp. Lab., Harvard
Lines: 24

> Following are some results of a quick comparison using the standard,
> stupid recursive Fibonacci calculation, in 4 popular languages (yes,
> even Fortran!).  I know that this is not terribly relevant, ...

Yes, well, it is probably a good measurement of procedure call overhead
on the implementations you tested.  Presumably some programs spend a
significant amount of time doing something other than procedure calling.
It is never surprising to find that a program written in one programming
idiom (Lisp: heavily recursive; Fortran: nested iterations; APL: all the
work in the operators) does better in its native language than if
translated naively into another, not because the language necessarily
`is better' in some abstract sense for that sort of problem, but rather
that the implementation effort has been concentrated on efficient
implementation of those features considered central.  How many Lisp
compilers can compile "do 10 i=1,10; do 10 j=1,10; 10 a(i,j)=2*x; into
something efficient?  Probably none; of course they <could>, but no one
has bothered to worry about those cases.  By the way, the VERY FIRST
Fortran compiler (1958?) both extracted the 2*x from the loop and
expanded this into a single loop....

As for the Critical Path calculations, good!  Nice to get a useful
result quickly.  I'm not sure what it proves, though.

	-s