3 ms·

Optimizing Lisp Some More

32 points by gnosis 16y ago

maximilianburke 16y ago
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.
apgwoz 16y ago
why is clisp so slow? design decisions? has development stagnated?
- gigamonkey 16y ago
  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 16y ago
    That would probably explain it. Seems like it might be a good use for GNU Lightning.
    - mahmud 16y ago
      CLISP uses GNU Lightning in some superficial sense, but it's a compile-time option not normally built into release binaries.
  - deleted 16y ago
    [deleted]
ohyes 16y ago
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 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.
gcv 16y ago
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.

32 points by gnosis 16y ago

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.

apgwoz 16y ago

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

gigamonkey 16y ago
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 16y ago
  That would probably explain it. Seems like it might be a good use for GNU Lightning.
  - mahmud 16y ago
    CLISP uses GNU Lightning in some superficial sense, but it's a compile-time option not normally built into release binaries.
- deleted 16y ago
  [deleted]

ohyes 16y ago

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

gcv 16y ago

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.