Comments on: Optimizing Lisp Some More

By: pat

pat — Tue, 07 Jul 2009 03:04:17 +0000

Indeed. That brought LispWorks down to 0.562 seconds and only 516 bytes allocated.

Thank you, very much.

By: malkia

malkia — Thu, 02 Jul 2009 20:52:10 +0000

For Lispworks you should make sure that you have this:

  (declare (optimize (speed 3) (safety 0) (space 0)
                   (debug 0) (compilation-speed 0)
                   #+lispworks (float 0)
                   #+lispworks (fixnum-safety 0)))

By: pat

pat — Thu, 25 Jun 2009 04:36:21 +0000

I do remember seeing the LispWorks thing about heap size, now that you mention it.

I’ve got to say though… it’s not a very promising way to get me to buy their product if the free edition is artificially slower. If their products turned out to be speedy enough to compete with the free implementations, I’d be much more inclined to shell out the money for them. As it is, I can’t really tell how competitive they are.

LispWorks 5-hour-per-session, no (save-image…), and non-commercial restrictions seem fine to me. The heap size restriction? that’s just running with a ball and chain around each ankle.

By: pat

pat — Thu, 25 Jun 2009 04:28:50 +0000

I tried moving the allocation out of that function. There is still something that is making Allegro and LispWorks allocate memory inside that function or inside the loop. I haven't looked at the assembly yet to try to figure out what they're doing that's causing them to chew through memory. As you can see in the table in this article, several implementations allocated zero bytes for the same code that caused other implementations to allocate anywhere from 120 bytes to 1,842 bytes per iteration.

By: Trying to Unconfound Lisp Speeds :: nklein software

Trying to Unconfound Lisp Speeds :: nklein software — Thu, 25 Jun 2009 04:23:50 +0000

[...] the original version of my Optimizing Lisp Some More article, I did a bad comparison between SBCL and Clozure. SBCL supports two different ways to [...]

By: pat

pat — Thu, 25 Jun 2009 01:33:59 +0000

Aha. My bad. I will rerun with the memory allocated outside the timer.

I didn’t get a heap warning, but I probably spent a whole lot of time garbage-collecting.

By: Justin Grant

Justin Grant — Thu, 25 Jun 2009 01:21:41 +0000

From the LW personal edition limitations :
http://www.lispworks.com/downloads/
“There is a heap size limit which, if exceeded, causes the image to exit. A warning is provided when the limit is approached. ”

Allegro CL Free Express edition :
http://www.franz.com/downloads/
“Limited heap size (60MB) ”

Would be interesting to see the code run on the full versions.

By: pat

pat — Thu, 25 Jun 2009 00:46:25 +0000

I agree. I was surprised by the difference. I am using the free LW and a trial Allegro. They don’t advertise heap limits, IIRC.

My next steps are to type the loop counter variables and to try a version where ‘ret’ is allocated outside the timing form. Then, if there is still a big difference, I will delve into the assembly.

By: Justin Grant

Justin Grant — Wed, 24 Jun 2009 22:35:14 +0000

The numbers for Allegro and Lispworks seem almost unbelievably bad in comparison to SBCL, CMUCL and Clozure. I’m wondering if the type decls required for those are also different (they should not be).

Also, are these limited versions that you’re using (with heap limits etc.) ?
If they are then the numbers would be invalid for comparison.

By: pat

pat — Tue, 23 Jun 2009 20:34:26 +0000

Fair enough. I included the other declarations. I will update the timing numbers in the original post.