Why stay with lisp when there are python and perl?

Pascal Costanza pc at p-cos.net
Fri May 4 06:04:30 EDT 2007


Jon Harrop wrote:

> It is worth noting that eager, statically-typed languages like OCaml and F#
> are many times faster than the other languages at this task. This is
> precisely the forte of OCaml and F#, manipulating trees and graphs.

Here is a page that sums up some important observations about 
benchmarks: http://www.ccs.neu.edu/home/will/Twobit/bmcrock.temp.html

Especially:

- "With modern superscalar architectures, 5-level memory hierarchies, 
and wide data paths, changing the alignment of instructions and data can 
easily change the performance of a program by 20% or more, and Hans 
Boehm has witnessed a spectacular 100% variation in user CPU time while 
holding the executable file constant. Since much of this alignment is 
determined by the linker, loader, and garbage collector, most individual 
compiler optimizations are in the noise. To evaluate a compiler 
properly, one must often look at the code that it generates, not the 
timings."

- "The execution time of a program is often dominated by the time spent 
in very small pieces of code. If an optimizing compiler happens to do a 
particularly good job of optimizing these hot spots, then the program 
will run quickly. If a compiler happens to do an unusually poor job of 
optimizing one or more of these hot spots, then the program will run 
slowly."

- "If the hot spots occur within library routines, then a compiler may 
not affect the performance of the program very much. Its performance may 
be determined by those library routines."

- "The performance of a benchmark, even if it is derived from a real 
program, may not help to predict the performance of similar programs 
that have different hot spots."



Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/



More information about the Python-list mailing list