Everything Else

Hi LISP gurus

Was playing with Lisp on my WinXP and was wondering why this large difference of performance.

I got GNU Emacs and CLISP on my WinXP laptop. I run these following codes respectively:







For emacs, the result is 10 seconds if using interpreter, then 3 seconds if using byte-code.

But for CLISP interpreter, it’s a horrible 48 seconds, I was wondering what’s the difference? And why such a large gap? Maybe CLISP VM is stack-based while emacs is something maybe register-based?

Thanks in advance, ciao!

could you recommend a great book/pdf to learn emacs' implementation of lisp? Or maybe better, sbcl or any other "advanced" clisp?

What are you using for the argument? Too large a number won't be representable as a fixnum.

hi mia, sorry but i usually use the net to search specific commands, also did use the emacs tutorial inside emacs too.. but for a Lisp pdf, now im reading Practical Lisp also i mentioned that video from MIT but i just know it was Scheme that they taught hehe but still useful

hi robes! geez silly me i forgot to put it here, thanks its:



today i will try compile it on CLISP byte-code to see the difference..

some update. i was able to compile it on CLISP and here is the result:



compiler = 7 secs
interpreter = 47 secs

compared to emcas lisp:
compiler = 3 secs
interpreter = 10 secs

all on the same machine, does it mean the VM is the difference?

has anyone managed to compile sbcl on irix?

when the code is interpreted, there is no VM; the interpreter simulates the effect of running the code by means of its own data structures, called "environment objects". To reference a variable, it will make several function calls: to locate the symbol in the current environment, get its value cell, and access the value. In addition, the interpreter is self-recursive, and calls itself on every subform that it evaluates. So your function that loops 50 million times could (on one implementation here) result in calling the interpreter 350 million times.

A CL interpreter has more to do, since there can be symbol-macros and handlers and restarts and things that need to be managed. Those always need to be checked, even if the code doesn't use them. For these and other reasons, most developers always compile their code before running it. (Compiling also lets you see warnings about mistakes in your code!)

so does it mean emacs interpreter only manage a few things that's why it was faster?

but how about the compiled byte-code, byte-codes should run on VM's right? what i know is CLISP use a stack-based VM for their byte-code while im not sure for emacs. but comparing the compiled performance, emacs still has beaten CLISP many folds so i wonder how emacs lisp did this, is it the VM design they use? btw please correct me, all byte code generated by LISP compilers will be run by their own VM's right? not the interpreter?

hmm maybe Oskar knows? or he also looking for this

Never actually tried, because I found cmucl (today a.k.a. Clozure CL) quite OK.

http://www.pmsf.de/pub/cmucl/release/18e/

18e is very old, and is unsupported by several common packages like ASDF.

Indeed, it's very old. Perhaps we should look at making a nekoware tardist of a recent CCL or SBCL.

I've never really understood Lisp, probably because I've been using RPL for 20+ years and the fact that operators are placed prior to the operands confuses me. I understand Haskell much better though, subsequently I ask. Is there anything Lisp has to offer over other *reputable* functional languages such as Haskell?

Funnily enough, John Carmack talked some about this at this year's superlong quakecon talk. Relevant video part: https://www.youtube.com/watch?v=1PhArSujR_A

Keep in mind that his point of view is 3d gaming.

As somebody who doesn't use Lisp or know much about it I still see the value in it. The syntax is very straightforward. People know how to implement it and get good performance out of it since it's been around a long time. Other functional languages are too ugly and wierd and have problems with performance and garbage collection for edge-cases. Maybe in the future that will improve. Lisp is something old school that's proved itself. I tend to like old stuff.

SBCL on IRIX would require a port, since it has never run on that flavor of Unix. Maybe a month's work?
The MIPS compiler backend would also benefit from an update to 64-bit, which might be easier, and allow some version of CMUCL to link to modern N32 libraries.