Ask HN: Why does Lisp need to be slower than c? | Hacker News Reader

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

5 pointsblintson9 comments

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?*

*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.

View on HN

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.

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...

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.

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.

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.

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.

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-...

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

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?.

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

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

Reply on news.ycombinator.com