5 ms·

Lisp is not, by any reasonable stretch of the imagination, fast. The key is that most applications aren't CPU bound anymore. If speed is that important, use fo

by smanek 18y ago

Lisp is not, by any reasonable stretch of the imagination, fast. The key is that most applications aren't CPU bound anymore. If speed is that important, use foreign function calls (or, better yet, Haskell). And I say this as a long time CL coder who has written several highly perfomant lisp libraries. See, for example, polygon.lisp, color.lisp, and bitmap.lisp at http://github.com/smanek/ga/tree/master http://github.com/smanek/ga/tree/master. In order to get decent performance you have to give up many of CL's advantages (not using half of CLOS's features, providing type hints, bit twiddling, imperative style, etc).

triplefox 18y ago
Indeed, the article doesn't really address anything. It basically concludes on the "sufficiently smart compiler" fallacy. Compilers only get better after you throw tons of engineering resources on them, and that situation only occurs after a language gains tremendous popularity for other reasons. For example, both Python and Ruby have less-than-ideal implementations, and the avoidable flaws in their design are well known. Despite that, it's taken a long time to get to the point where anyone is even motivated to work on a reimplementation. And on the other hand, Lisp has had scores of implementations, but it still can't reliably earn the prized "equal/better to C" benchmark scores. This if nothing else should inform us that performance considerations definitely do come into play at the language-design level.
- jgrant27 18y ago
  You mention that the reason for lower performance of Lisp vs. C has to do with a lack of motivation. This couldn't be further from the truth. Have a look at the source repos for SBCL, Clozure or any other dozen Lisp implementations or dialects. In the next paragraph you state that because Lisp does not match C in performance this somehow proves that language-design directly effects the ability for a Lisp compiler to generate optimized code comparable to generated code from a C compiler. This is a bizarre conclusion. What is your reasoning for this ?
jgrant27 17y ago
Agreed

by smanek 18y ago

triplefox 18y ago

Indeed, the article doesn't really address anything. It basically concludes on the "sufficiently smart compiler" fallacy. Compilers only get better after you throw tons of engineering resources on them, and that situation only occurs after a language gains tremendous popularity for other reasons. For example, both Python and Ruby have less-than-ideal implementations, and the avoidable flaws in their design are well known. Despite that, it's taken a long time to get to the point where anyone is even motivated to work on a reimplementation. And on the other hand, Lisp has had scores of implementations, but it still can't reliably earn the prized "equal/better to C" benchmark scores. This if nothing else should inform us that performance considerations definitely do come into play at the language-design level.

jgrant27 18y ago
You mention that the reason for lower performance of Lisp vs. C has to do with a lack of motivation. This couldn't be further from the truth. Have a look at the source repos for SBCL, Clozure or any other dozen Lisp implementations or dialects. In the next paragraph you state that because Lisp does not match C in performance this somehow proves that language-design directly effects the ability for a Lisp compiler to generate optimized code comparable to generated code from a C compiler. This is a bizarre conclusion. What is your reasoning for this ?

jgrant27 17y ago

Agreed