

I want to believe (in Lisp vs C performance) - jgrant27
http://www.imagine27.com/articles/2009-05-03-195227_i_want_to_believe_in_lisp_performance.html
This essay will not focus on Lisp's powerful abstractions but on another practical concern of all programmers : performance, specifically compared with C.
======
tumult
I had typed a reasonably long criticism, but Safari crashed and I lost it (and
I thought it had become safe to actually start writing in browsers.)

Anyway: The graph is useless (don't use a log scale, please choose a better
range)

The code is somewhat frightening (C implementation totally naïve, and I'm not
much of a Lisper, but the nesting level there scares me)

 _It's 'bizarre' syntax, it's alleged ability to ... facing it's almost
vertical cliff face of ..._ (I hope English isn't your native language; you
should be using its, the possessive form)

 _Lisp being an implementation of Lambda Calculus_ (what?)

 _and a functional language_ (no?)

 _To sum it all up : The small factor in difference between C and Lisp really
does not matter. As the Lisp compilers improve in the code that they generate
over the coming years the gap will close without much work on the Lisp
hacker's part._

Conclusion: [some banality]

Now, pretend I had written the above more eloquently and inefficiently, and
I'll pretend Safari didn't die. Oh well :(

~~~
jgrant27
Relax and don't be afraid (your language is safe) and always will be.

The C version is not fully optimized (yes it's naive) and this was intentional
and stated in the article (perhaps not clearly enough).

A fully optimized C version would run in under 5 seconds for the 1000x1000
board on the same hardware using all the 'idiomatic' tricks using bit masks
etc. A similarly optimized Lisp version would also run faster using different
data structures and/or algorithms. You've missed the point.

Learn to read logarithmic graphs without prejudice, you may discover much
useful information around you that you assumed was 'useless'.

Yes Lisp is an implementation of Lambda Calculus : horrific isn't it ?
<http://en.wikipedia.org/wiki/Lisp_(programming_language)>

I don't know how many times I have to say this : Lisp is a functional language
but also allows for imperative programming.

You're only valid point was the misuse of "it's" instead of "its". Good job.

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

------
richcollins
"Such abstractions simply don't exist in most other languages, specifically
the imperitave kind."

wrong

<http://iolanguage.com/>

Also, Lisps are imperative. setf, setq and the like.

~~~
jgrant27
Yes yes but they are optionally imperative but were first functional.

"system maintenance" for the url that you posted.

~~~
joechung
<http://iolanguage.com> perhaps?

~~~
jgrant27
Does it have anything comparable to Lisp macros ?

~~~
mahmud
Io ~= Self. It should be looked at as an Smalltalk dialect.

When one says "imperative", one hardly means "an smalltalk influenced, pure
object oriented language", but more like a statically-typed Algol variant,
usually a derivative of C, Fortran, Pascal or Ada.

I don't think the Io counter-example is valid, just as an Icon counter-example
would be valid (yes, Icon is "imperative", but it's also an Snobol derivative
with goal-oriented execution, generators and perl-like text processing prowess
:-)

~~~
fhars
If someone with a functional programming background says "imperative", it
usually includes all the Algol descendants and their cousins like Simula,
Java, C++, Smalltalk, Python, Ruby etc. because they don't add much to the
game, they are all structured around mutable state. They just put fancier
labels on the same dirty stuff.

~~~
mahmud
You just spoke of Smalltalk in that trollish tone. Hope you're happy.

------
signa11
everything looks better on a log-scale

~~~
jgrant27
exactly and this is clearly stated in the article.

------
erlanger
And now, the rest of the story.

[http://www.reddit.com/r/programming/comments/8hlls/i_want_to...](http://www.reddit.com/r/programming/comments/8hlls/i_want_to_believe_in_lisp_vs_c_performance/c09b77i)

