Re: Interesting loop problem

>>>>> "Blake" == Blake McBride <[email protected]> writes:

    Blake> See below.
    Blake> On Thu, Aug 6, 2015 at 10:23 AM, Raymond Toy <[email protected]> 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

_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp