Path: news.daimi.aau.dk!news.uni-c.dk!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!munnari.oz.au!news.uwa.edu.au!news.uwa!mafm From: mafm@cs.uwa.edu.au (Matthew McDonald) Newsgroups: comp.lang.beta,comp.lang.lisp Subject: Re: Comparison: Beta - Lisp Date: 16 Sep 1994 05:30:30 GMT Organization: Dept. Computer "Science", University of Western Australia. Lines: 78 Message-ID: References: <34n2qe$d74@nz12.rz.uni-karlsruhe.de> <34pfea$6ee@belfort.daimi.aau.dk> <354q47$60i@belfort.daimi.aau.dk> NNTP-Posting-Host: wambenger.cs.uwa.oz.au In-reply-to: jacobse@daimi.aau.dk's message of 13 Sep 1994 18:13:27 GMT Xref: news.daimi.aau.dk comp.lang.beta:54 comp.lang.lisp:13305 I know this is about beta rather than lisp, but what Jacob is saying about beta sounds a lot like what many people have been saying about lisp. jacobse@daimi.aau.dk (Jacob Seligmann) writes: [...] Here's my results (486/66; BETA compiler v5.0(2); gcc v2.5.8): gcc -O6 -fomit-frame-pointer 2.08 BETA -no-range-check 11.00 [Actually, the compiler currently do not have a -no-range-check option. The BETA figure was obtained by removing all boundl-instructions from the code by hand, and reassembling; this is the only way I could achieve a fair comparison.] As you can see, the ratio between state-of-the-art optimized C and BETA was 5.3, not 26.4 as above. [...] With a little bit of effort, there is absolutely no reason why the BETA compiler should not be able to perform the variable liveliness analysis itself (although currently it does not, and therefore pays the heavy price of using heap space instead of registers). Also, the linear array sweeps are simple enough that the compiler could recognize them and avoid the index calculations (again, it currently does not, and therefore pays the price at each lookup). "Some integer array hacking"-type programs are *exactly* what highly sophisticated C compilers excel at, but there are no intrinsic reasons why the BETA compiler should not to be able to produce comparable code. We're constantly working on it... What Jacob's saying is (a) Typical code written in c performs more than 5 times better than code in his favourite language using available implementations, and (b) there's no reason why his favourite language couldn't be implemented so it was competive. What lisp (and beta) advocates seem to often ignore is that quality of code generation really matters to most people. Telling people that a factor of 5 difference in run-time doesn't really matter doesn't encourage them to use your language. Neither does telling them that *in principle* or *some day in the future*, your language could be competitive. Unless you have competitive ports to x86, Sparc, Alpha, DEC & SG Mips, PA-RISC, and RS6k, few people are going to use a language. Not many people are going to bother explaining that performance matters to them, they're just going to ignore you when you try to tell them otherwise. Which is a pity, because competive compilers for sane languages like beta and lisp are obviously feasible. Paul Wilson was proposing a compiler for scheme+objects that would compete with C, CMU CL was great (although it now seems to be largely unsupported) and the ETH Oberon compilers are also wonderful (although the systems they're in don't co-operate with the rest of the universe.) At least Jacob's actually working on improving the beta implementation. As far as I can tell, the usual lisp advocate response to performance complaints is to either: (a) deny there's a problem, (b) say one day there won't be a problem, or (c) suggest you write code that looks like FORTRAN and manually weigh expression trees and other insanity. Perhaps Gwydion or Paul Wilson's scheme+objects compiler will save the world. -- Matthew McDonald mafm@cs.uwa.edu.au Nim's longest recorded utterance was the sixteen-sign declarative pronouncement, "Give orange me give eat orange me eat orange give me eat orange give me you."