The last two weeks of lemonodor have been overflowing with robots, pleasantly architecture/planning/design-ariffic, and entirely lisp-less. I think it might be dangerous for everyone if I were to dive right back into hardcore original lisp content, so today I'll just mention a post of Bill Clementson's that I meant to link to weeks ago but never got around to.
Lisp is Slow (NOT!) summarizes a comp.lang.lisp thread in which some knucklehead said “lisp is slow”, and furthermore thatThe best known non-stupid (real problem, any algorithm) benchmark is probably the Coyote Gulch test. There are many languages that it has been translated into. If you can produce (write or find) and post a Lisp version that is within 10% of C performance, I will admit that #1 [lisp is slow] is incorrect.
Within a few days a collaborative programming and optimization effort paid off with a lisp version of the benchmark that was about 2% faster than the C version.
Posted by jjwiseman at March 22, 2004 10:10 AM...but if you look at the code that was written, it was pretty much C code in Lisp syntax.
It says something about a language if you have to use it like another language in order to make it run fast.
Posted by: Joe Lisp fan on March 23, 2004 08:43 AMSome people like to complain and are never happy. So, I must point out:
We all know that a small percent of almost all applications would have to be coded this way (to make it fast), leaving the power and expressiveness of Lisp to be used to full advantage in the rest of the application.
I look at it this way. A lot of the new, interesting software is being written in a combination of two languages; a high-level, dynamically typed language with good built-in data structures and an environment for rapid software development, and a statically typed, heavily optimized language for performance. For a Python programmer, these two languages are Python and C. For the Common Lisp programmer, the two languages are Common Lisp and Common Lisp.
Posted by: Ralph Richard Cook on March 23, 2004 09:23 PMIf you look at the original benchmark, which compares gcc and Intel's compiler, you'll see that gcc wasn't the fastest. Anyway, it's still very impressive that cmucl is as fast as c compiled with gcc.
I wish that "nobody" came fourth and admited he was wrong. :-)
Posted by: setf on March 25, 2004 04:13 AMThese benchmarks can be useful if they point out opportunities for improving lisp compilers. For example, we could probably benefit from better register allocation and instruction scheduling.
Posted by: Paul Dietz on April 1, 2004 06:11 PM