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