

Optimizing Lisp Some More - gnosis
http://nklein.com/2009/06/optimizing-lisp-some-more/

======
ohyes
If he's really going for optimization, he might consider passing in the 'ret'
array rather than creating a new one each time. (Or even better, using
multiple-values return to pass them stack allocated).

It also might be good to use a macro or compiler macro to unroll the loops,
then you don't have to worry about manipulating 2 looping pointers. All you'd
end up with is a bunch of constant arefs and addition/multiplication.

He also might want to set debug to 0, although I don't have any way to test
that (or any of this) at the moment.

Then you get something that looks like this:

<http://paste.lisp.org/display/120946>

I haven't tested it (I don't even know if it works!), but the disassembly
looks faster...

/rampant speculation.

------
maximilianburke
The only difference between the SBCL decls + noopt version and the decls +
optimizations version, at least when I compiled it with SBCL 1.0.40.0, is the
number of generated nops used to align the beginning of the inner loop which
really shouldn't be noticeable at all. I'm guessing the 60ms difference
between the two is just noise rather than the appearance of a difference in
code generation.

------
gcv
I think the author can make the loops faster by adding (the ...) forms where
he adds and multiplies numbers. Also, he should declare the types of his loop
control variables. Just a theory, though: I haven't run the code or looked at
its disassembly output.

------
apgwoz
why is clisp so slow? design decisions? has development stagnated?

~~~
gigamonkey
Last I knew, CLISP was based on a bytecode VM while SBCL and Clozure generate
machine code. I think there may be some work on adding a JIT to CLISP but as
far as I know it's still experimental.

~~~
apgwoz
That would probably explain it. Seems like it might be a good use for GNU
Lightning.

~~~
mahmud
CLISP uses GNU Lightning in some superficial sense, but it's a compile-time
option not normally built into release binaries.

