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/ -- http://mail.python.org/mailman/listinfo/python-list
