Hacker News new | ask | show | jobs
by Zak 4862 days ago
The creators of Common Lisp knew what Alex is talking about. Lisp is, of course just as dynamic as Ruby, Python or Javascript, but it exposes lower-level details about data structures and memory allocation iff the programmer wants them.

Features that come to mind include preallocated vectors (fixed-size or growable), non-consing versions of the standard list functions and the ability to bang on most any piece of data in place. There are fairly few situations in which a CL program can't come within a factor of 2 or 3 of the performance of C.
1 comments
pjmlp 4861 days ago
In the early 80's there was a time Lisp compilers could even beat FORTRAN for floating point computations.

http://www.cs.berkeley.edu/~fateman/papers/lispfloat.pdf

link
cliffbean 4861 days ago
From the discussion of their most relevant benchmark (Singular value decomposition):

  The Allegro CL 4.1 times of 3.9 seconds beat the f77 time of 4.8 [seconds];
Nice!

  setting on optimization for f77 brought its time down to 0.45 seconds.

  Thus for this system, the [LISP] compiled code can have quite comparable speed to
  that of the corresponding unoptimized Fortran in this case as well.
Oh really.
link
pjmlp 4861 days ago
It's been a few decades since I have read the paper, so it seems my memory is a bit fuzzy on that regard.

On the other hand, given that C always had issues to beat even unoptimized Fortran, due to the optimization restrictions before C99, it is quite commendable that Lisp achieves such results.

link
cliffbean 4860 days ago
It's not obvious how optimized C in the '80s wouldn't have been as fast as unoptimized Fortran 77, even with whatever optimization restriction you might be thinking of.

The way the authors of that paper talk about unoptimized code in that paper gives the impression that they don't know what they're talking about. Your comments here begin to put you at risk of a similar appearance.

link