"Blake" == Blake McBride <blake1024@gmail.com> writes:
Blake> See below. Blake> On Thu, Aug 6, 2015 at 10:23 AM, Raymond Toy <toy.raymond@gmail.com> wrote: [snip] >> >> And? Blake> And: Blake> 1. My machine finishes in 1:24 (one minute, 24 seconds) with CMUCL Blake> interpreted. On the same machine giving interpreted (where available) Blake> numbers only: Blake> LISPF4 0:22 Blake> CLISP 0:43 Blake> ABCL 0:24 Blake> GCL 0:34 Blake> ECL 0:10 Blake> CMUCL 1:24 Blake> So, CMUCL is, by very far, the slowest interpreter available. That's a Blake> problem. Yeah, that's not great. Carl tells me that even on 18a it's slow, so the issue goes way back to the early days of cmucl. Blake> 2. Why the GC's? The program allocates no structures, no conses, no Blake> recursion. That's a problem. You ignore how cmucl runs the interpreter. I've never looked in this, but I can imagine all of the consing is coming from the interpreter running the code. If you byte-compile the function, the function doesn't cons. Still rather slow, but not inordinately slow. Blake> 3. Prior to this, I was under the impression that CMUCL was one of the Blake> more mature, efficient, and compliant CL's available. Apparently I was Blake> wrong. That's a problem. I suspect most of the effort was spent on the compiler not the interpreter. I think in that respect cmucl does well. I can imagine the "answer" to a slow interpreter is to just compile the function since the compiler is good. Blake> Does that help answer your question? Yes. -- Ray