From ... Path: bga.com!news.sprintlink.net!uunet!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sunic!trane.uninett.no!nac.no!nntp-oslo.uninett.no!naggum.no!erik From: Erik Naggum Newsgroups: comp.lang.beta,comp.lang.lisp Subject: Re: Comparison: Beta - Lisp Date: 14 Sep 1994 00:02:28 UT Organization: UniNett Lines: 50 Message-ID: <19940914T000228Z.erik@naggum.no> References: <34n2qe$d74@nz12.rz.uni-karlsruhe.de> <34pfea$6ee@belfort.daimi.aau.dk> <354q47$60i@belfort.daimi.aau.dk> Xref: bga.com comp.lang.beta:40 comp.lang.lisp:3090 [Jacob Seligmann] | [As you can see below, the C implementation uses a lot of tricks I did | not care or was unable to use in the BETA port: in-lining (#define's), | hard-wired variable liveliness information (loads of blocks with local | variables, making the code very hard to read), code generation hints | (register ...), array pointers (*d++ = *s++), unstructured gotos, etc.] this is not benchmarking execution speeds of C or LISP or anything. this is benchmarking a programmer's willingness to write assembly language and to see how well his assembly language coding style fits various languages. I'll bet gcc -O6 does a better job on reasonably-written C than it does on this spaghetti code. I mean, writing your own version of memcpy because you think memcpy won't be fast enough is rather pathetic when there are CPU's out that have block move instruction idioms and good compilers that open-code them when calls to memcpy are requested. to paraphrase Richard Stallman from a response to a bug report for Emacs with a horribly convoluted fix: Unfortunately, the code you wrote looks like the intermediate stage of scheme compilation, and it's too hard for me to read. I can't even figure out what [it] does. and what's this about a semicolon _after_ the closing brace in blocks? such things worry me when I read other people's C code, because it tells me that they don't really program in C, but translate from something else into C. that's the feeling I got from the LISP code, too. is this really a good way to compare languages? I think not. are there any good ways to compare _languages_? I think programmer time spent and number of compilation runs required to solve a particular problem is a better indication. then, later, we can benchmark the compilers. I don't use LISP because of its outstanding speed, anyway. I use it because _I_ am faster in LISP than in anything else I know well enough to compare to. two days of my time translates to the cost of a CPU upgrade to my clients. so what if it runs five times slower and takes 100 instead of 20 milliseconds? with the upgraded CPU it'll only take 3 times more time, and if I need to come back to enhance the functionality, they can buy an even _faster_ CPU. we're not talking about more than constant factors in difference between these benchmarks here, right? BETA and LISP probably have a lot to tell us about optimal program design in their respective mind-sets and a comparison of their relative strengths and idiomatic expressiveness would be instructive. onwards, folks! # -- Microsoft is not the answer. Microsoft is the question. NO is the answer.