in reply to Re^2: Why is this code so much slower than the same algorithm in C?
in thread Why is this code so much slower than the same algorithm in C?

> A few existing dynamic languages that have good compilers (some need hinted with type declarations at the tight portions of code - which may be cheating, but good Common Lisp implementations use it, and AFAIK they don't even use a JIT compiler), can already come really close to C's speed.

thanx for the insight... well another good reason to overcome my parens-allergy ; )

... maybe starting with elisp.

Cheers Rolf

PS: I suppose the dynamic structure of lisp (data == code) enforces a late compiling (comparable to JIT) and therefore the potential to high optimization ...

  • Comment on Re^3: Why is this code so much slower than the same algorithm in C?

Replies are listed 'Best First'.
Re^4: Why is this code so much slower than the same algorithm in C?
by Joost (Canon) on Dec 10, 2008 at 23:28 UTC
    Actually the code = data does not particularly enforce late compiling - it just means you can have a more efficient means to a] talk to the compiler and b] pre-process code before it reaches the compiler (since you can process structured data instead of strings). Being able to talk to the compiler from running code at all (using eval for example) is of course a good reason to optimize for all kinds of compiling speed-ups.

    Anyway elisp is OK (if fairly slow), but it's quite archaic compared to scheme, common lisp and other "modern" lisps (basically any serious lisp created/standardized since the 80's). Most of the details are fairly easy to overcome, but the lack of true built-in support for lexical scoping (and closures) is probably the most annoying.