[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lisp performance was Re: problems with lisp
You can find several papers on Lisp performance her:
http://openmap.bbn.com/~kanderso/performance/
I'd be intersted in looking at your programs if you'd like.
Unfortunately, Common Lisp does not require tail call optimization, though things like tail calls are usually optimized. You'd see stack overflows if this was an issue.
First, I write Lisp straightforwardly. This version is often plenty fast enough. When its not, i profile (see for example, http://openmap.bbn.com/~kanderso/performance/postscript/courage-in-profiles.ps). I don't know if clisp or gcl have profilers however. Often a few relatively small changes can make a big difference. These may or may not require type declarations.
Going from OCaml to Lisp you may lose information that OCaml takes advantage of.
I agree that pattern maching makes the code cleaner.
k
At 04:40 PM 8/22/2003 +0100, Russ Ross wrote:
>Performance is still a bit of a sore spot, too. I hear that tuned
>lisp code runs as fast as C code, but I'm still sceptical. I
>recently implemented a fairly simple solution to the ILC programming
>contest in both CL and OCaml. I wrote it first in OCaml as an
>exercise to learn the language and then ported it to Lisp. It was
>a purely functional solution and I was careful to use tail calls
>when possible. The two solutions are almost identical in structure,
>but the lisp version is about 10x slower. I tried it with two lisp
>compilers (clisp and gcl) and they were about the same. I'm sure a
>more experienced lisp programmer could tune it up nicely, but I have
>much more lisp experience than OCaml experience and I was shocked
>by the result. I don't trust a language where the clean, simple
>approach is the slow one and requires careful annotations and
>program restructuring to work around the idiosyncrasies of the
>language. With Lisp it seems like there are two languages: the
>simple one you teach people and use to demonstrate its virtues, and
>the real one you use for high performance implementations. Can't
>Simple Lisp be the same as High Performance Lisp? So far it sure
>seems to work for OCaml. Pattern matching meant the OCaml code was
>much more transparent as well (and I'm saying this as a complete
>beginner with OCaml and ML in general).
Title: dice
dice
Storage allocation per Class
Cumulative % | Storage (bytes) | Count | Class |
84.29 | 43,535,834 | 234,811 | java.lang.String |
95.15 | 5,608,844 | 82,483 | com.bbn.notam.snarf.Notam |
98.98 | 1,979,592 | 82,483 | java.util.HashMap$Entry |
100.00 | 524,300 | 1 | [Ljava.util.HashMap$Entry; |
100.00 | 40 | 1 | java.util.HashMap |
100.00 | 36 | 1 | com.bbn.notam.snarf.NotamQueryResultSet |
100.00 | 12 | 1 | java.util.HashSet |
100.00 | 12 | 1 | java.util.HashMap$KeySet |
100.00 | 8 | 1 | java.lang.Object |
100.00 | 51,648,678 | 0 | Total |
Super Luzer
Last modified: Wed Aug 28 15:03:26 Eastern Daylight Time 2002