[cl-faq] whence "Lisp is slow" myth? one possible answer

[Gary Klimowicz]

I think this is an interesting explanation, but I think the original "Lisp
is slow" sentiment comes from quite a few possible other (more primary)
impressions people have (and truths about Lisp). Some of these are based on
ancient history, but I think that's where the folklore about Lisp being slow
began.

For one, the first implementations of Lisp that many people were exposed to
were interpreters, not compilers. The interpreters ran much more slowly than
compiled code, partly because the state of the art of interpreters
themselves back in the olden days (70s and 80s) was not so good.

Another reason is the one cited in the old FAQ: Lisp is not statically
typed, and often requires run-time checks to understand which operator (like
+) was being applied. Then add the run-time bounds and value checking we now
take for granted in modern languages. Regardless of the compiled or
interpretive nature of the implementation, this added overhead that many
other compilers did not suffer. For Lisp, though, the underlying safety of
the running code was more important than this false "efficiency".

But wait, there's more. Lisp pioneered dynamic memory management with its
trivial ability to create dynamic memory (CONS), and its garbage collection
facility. Since these had no native counterpart in most other languages at
the time (again, the 70s and 80s), it was never a fair comparison. Each C
programmer generally had to manage their own memory allocation and
deallocation, quite specifically for the problem at hand. Lisp's facilities
here were much more general, and consequently, slower. Couple that with the
original stop-everything-and-collect-garbage model of the original
implementations, one could easily believe that Lisp was just inherently
slow.

The emergence of Lisp-specific hardware then gave the impression that Lisp
could not be made to perform well with the standard hardware of the time.

Today, virtually all of the above "reasons" are false, but it takes a lot of
time and evidence to kill a myth.

With type-inferring compiled implementations of Lisp, the native speed of
Lisp code can be quite good. Many of the modern languages (like Java) do the
same kind of run-time validity checking that Lisp started with, evening the
perception of the playing field. With advances in incremental and
generational garbage collecting techniques (and in our ability to monitor
and manage our garbage creation), the memory management issue is a non-issue
as well.

Lisp implementations are fast now to the point that almost no one thinks we
need to build special-purpose hardware to make Lisp performance acceptable.
(Well, I know one person who wants to build one, but my friend Frank is just
wired that way.)

Lisp isn't slow. It's just powerful and prescient. The techniques we've
learned to make Lisp fast on stock hardware keep Lisp performance and power
ahead of virtually all other modern languages. For the balance of power and
performance, there are not many language environments that compete with the
commercial and free implementations of Lisp.

(Sorry if this sounds like a rant, but this one really gets me...)



On 11/20/06, Larry Clapp <larry at theclapp.org> wrote:
>
> Reading PAIP.  Got to the section on the General Problem Solver
> ("GPS") and the blocks world.  Haven't read it in detail yet, so I may
> have the wrong impression, but the exact problem doesn't matter, so
> here goes:
>
> I get the impression that to solve a problem, Norvig runs the GPS
> against all permutations of its goals, so as to make sure that the GPS
> doesn't fail to find an answer due to the order if its goals.
>
> As I said, I may have the *wrong* impression, but it doesn't matter,
> because that was just the springboard to this conjecture: one of the
> origins of the "Lisp is slow" myth may've come from AI, which usually
> tries to solve very hard problems, some of them NP-complete and/or
> require searching large problem spaces, and so regardless of the
> language in use the algorithm will take a long time.
>
> Thus:
>
> Lisp is used a lot in AI
> AI must solve difficult problems
> Solving difficult problems takes a long time
> ergo Lisp programs take a long time
> ergo Lisp is slow
>
> Any thoughts?  Is this even a new take on the question?
>
> -- Larry
>
>
> _______________________________________________
> cl-faq mailing list
> cl-faq at lispniks.com
> http://www.lispniks.com/mailman/listinfo/cl-faq
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lispniks.com/pipermail/cl-faq/attachments/20061120/b0b10cb9/attachment.html