Newsgroups: comp.lang.beta,comp.lang.lisp Path: news.daimi.aau.dk!news.uni-c.dk!sunic!pipex!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!ames!ncar!csn!gw1.att.com!nntpa!nntpa.cb.att.com!lgm From: lgm@polaris.ih.att.com (Lawrence G. Mayka) Subject: Re: Comparison: Beta - Lisp In-Reply-To: mafm@cs.uwa.edu.au's message of 16 Sep 1994 05:30:30 GMT Message-ID: Sender: news@nntpa.cb.att.com (Netnews Administration) Nntp-Posting-Host: polaris.ih.att.com Organization: AT&T Bell Laboratories, Naperville, Illinois, USA References: <34n2qe$d74@nz12.rz.uni-karlsruhe.de> <34pfea$6ee@belfort.daimi.aau.dk> <354q47$60i@belfort.daimi.aau.dk> Date: Sun, 18 Sep 1994 20:46:03 GMT Lines: 65 Xref: news.daimi.aau.dk comp.lang.beta:68 comp.lang.lisp:13330 In article mafm@cs.uwa.edu.au (Matthew McDonald) writes: 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. ... 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 For Common Lisp (LispWorks and CMU, at least), the factor was 2, not 5. Moreover, I certainly disagree that this small numerical-analysis benchmark is a typical C program. It's certainly not typical of, say, telecommunications switching systems. Nevertheless, I agree that the potential difference in efficiency of generated code between CL and (the best) C compilers remains an obstacle to broadening CL's market. 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. I agree that "in principle" is a weak argument; "can be fixed by the vendor within n months/years" is a somewhat better argument (if true!). 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 Common Lisp has all these. 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, I don't deny the existence of a problem. (b) say one day there won't be a problem, or I think a concerted effort by vendors could substantially solve the problem--i.e., make the best Common Lisp compilers generate code substantially competitive with the code generated by the best C compilers--within a reasonably short time period (perhaps 1-2 years). Presumably, this will occur only if/when CL users raise its priority above that of other new features and quality improvements. (c) suggest you write code that looks like FORTRAN and manually weigh expression trees and other insanity. Ideally, code should "look like" the abstract solution to the problem at hand. If the problem is numerical analysis, then shuffling vector elements is precisely the =correct= abstraction of the solution--mathematician have no abstraction higher-level than that. If you want to say that the ideal compiler would deduce all datatypes so that explicit type declarations would be unnecessary, I agree; but I don't see how you can hold this lack of type inferencing against Common Lisp when C does no such thing either. -- Lawrence G. Mayka AT&T Bell Laboratories lgm@ieain.att.com Standard disclaimer.