Hacker News new | comments | show | ask | jobs | submit login
I want to believe (in Lisp vs C performance) (imagine27.com)
20 points by jgrant27 2885 days ago | hide | past | web | 19 comments | favorite



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 :(


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.


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


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.


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 ?


Agreed


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


!most != any IANALP


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

"system maintenance" for the url that you posted.



Does it have anything comparable to Lisp macros ?


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 :-)


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.


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


Io has runtime macros. Messages are evaluated by the receiver and which can do whatever it wants with the message arguments (evaluate them, tear them apart and create new messages ... etc)

list(1, 2, 3, 4) select(isEven) map(+(1)) ==> list(3, 5)

isEven and +(1) are messages that select and map evaluate.

Also see:

http://hackety.org/2008/01/05/ioHasAVeryCleanMirror.html


Reader macros?


everything looks better on a log-scale


exactly and this is clearly stated in the article.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: