

Ask HN: Why does Lisp need to be slower than c? - blintson

It's easy to program in an imperative style in lisp. I can't think of any language feature C has that can't be used by lisp. Why can't lisp become as fast as C by using only a fast subset of a given lisp dialect?*<p>*I know, if you only use C features you're writing C. There's must be advantages to having lisp all the way down though. Having a fast C-esque lisp subset would make going from prototype code to performance-intensive code much, much easier.
======
Yaa101
Because C is not really a higher level language, C is very close to it's
assembly core and often C and Assembly are combined in functions. Also don't
forget that modern C compilers are very good in optimizing for speed AND size,
if you see the generated assembly from the compile job there is hardly to none
optimizing to be done by assembly specialists.

Down side of C is that every little algorithm or pattern needs to be made from
scratch as there is almost none functionality in the language itself. What
people see as C is most often the nowadays immense library of solutions.
Upside is it's proven flexibility, C can do almost anything and is to be found
on every platform out there.

Lisp is mainly about a certain functionality, that is list processing, so you
are comparing a general purpose language with a specialist one. In other
words, you are comparing apples and pears.

------
jws
The premise is only mostly true.

See: How to make LISP go faster than C,
[http://docs.google.com/gview?a=v&q=cache:pJg0zHyA8s8J:ww...](http://docs.google.com/gview?a=v&q=cache:pJg0zHyA8s8J:www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf+lisp+faster+than+c&hl=en&gl=us&sig=AFQjCNHLVC-
I-RoHNFuPCOemUhyUYfrpHg)

As an example, consider C pointers. The compiler never knows if two objects
passed by reference are going to overlap in memory, so it can't do certain
optimizations that seem obvious to a human that "knows" the pointers won't
overlap.

------
wglb
Lisp executables are fast based on good compilers. You can usually tailor your
Lisp program with declarations and speed/safety trade-offs to get very good
code. There is a benchmark site called Shootout that shows how well pretty
much any language compares for execution time.

And if you discover that you have the wrong approach, it is much easier to
change a Lisp program than a C or a C++ program. That is my primary definition
of fast.

Speed of program execution is often (not always) overrated.

------
notaddicted
Assuming: you can generate any sequence of instructions you want with C.

1\. The fastest possible implementation is possible in C.

2\. Lisp will never "be faster" (the limited meaning of "be faster" we are
considering in this context) than C because that is impossible.

3\. Any difference however minor, will cause Lisp to be slower.

Thus it is highly likely that lisp will be slower.

NOTE: commenter rejects your notion of slower.

~~~
wmf
This assumes unlimited development effort. In reality, writing the fastest
possible code may require many more lines of code in C than in Lisp, with
correspondingly larger development cost.

------
kroger
How to make Lisp go faster than C

www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

[http://www.foldr.org/~michaelw/log/programming/lisp/reverse-...](http://www.foldr.org/~michaelw/log/programming/lisp/reverse-
complement-benchmark)

And there are more papers on the subject (google for it)

------
jws
We have now barraged the original poster with papers and assertions that his
premise is wrong.

How about a new premise: _Why do LISP programmers write slow programs?_ , and
if that premise gets shot to pieces, how about _Why do people think LISP
programmers write slow programs?_.

~~~
blintson
It's turtles all the way down! The next step would be _Why do people think
people think lisp programmers write slow programs?_

------
sjs
It doesn't. CL allows you to specify types and have your code optimized. This
is an oft-cited feature of it.

