Re: Interesting loop problem

See below.

On Thu, Aug 6, 2015 at 10:23 AM, Raymond Toy <[email protected]> wrote:

> >>>>> "Blake" == Blake McBride <[email protected]> writes:
>
>     Blake> Greetings,
>     Blake> I was running some test code to (stupid) test the speed of
> various lisp
>     Blake> implementation including those other than CL.  The code I used
> is as
>     Blake> follows:
>
>     Blake> (defun count2 (n)
>     Blake> (prog ((i 0))
>     Blake> loop
>     Blake> (and (eql i n) (return))
>     Blake> (setq i (+ i 1))
>     Blake> (go loop)))
>
>     Blake> I know the code is terrible, but it was a bit more portable
> over various
>     Blake> lisp dialects.  It ran fine on CLISP, SBCL, ABCL, CCL, GCL,
> ECL, and
>     Blake> LISPF4, but not CMUCL.
>
>     Blake> CMUCL ran the code compiled but not interpreted.
>     Blake> Try this interpreted:  (count2 80000000) ; 80M
>
>     Blake> I get:
>
>     Blake> ; [GC threshold exceeded with 12,013,152 bytes in use.
> Commencing GC.]
>     Blake> ; [GC completed with 106,440 bytes retained and 11,906,712
> bytes freed.]
>     Blake> ; [GC will next occur when at least 12,106,440 bytes are in
> use.]
>     Blake> ; [GC threshold exceeded with 12,122,352 bytes in use.
> Commencing GC.]
>     Blake> ; [GC completed with 114,616 bytes retained and 12,007,736
> bytes freed.]
>     Blake> ; [GC will next occur when at least 12,114,616 bytes are in
> use.]
>     Blake> ; [GC threshold exceeded with 12,124,080 bytes in use.
> Commencing GC.]
>     Blake> .....
>
>     Blake> I am running 20F on Linux.
>
> And?


And:

1.  My machine finishes in 1:24 (one minute, 24 seconds) with CMUCL
interpreted.  On the same machine giving interpreted (where available)
numbers only:

LISPF4  0:22
CLISP   0:43
ABCL    0:24
GCL     0:34
ECL     0:10
CMUCL   1:24

So, CMUCL is, by very far, the slowest interpreter available.  That's a
problem.


2.  Why the GC's?  The program allocates no structures, no conses, no
recursion.  That's a problem.


3.  Prior to this, I was under the impression that CMUCL was one of the
more mature, efficient, and compliant CL's available.  Apparently I was
wrong.  That's a problem.

Does that help answer your question?

My impression is that CMUCL is needlessly allocating a lot of storage
causing the GC to kick off.  And the huge number of (unnecessary) GC's is
causing the delay.

Thanks.

Blake




> Are you saying it never finishes?  Are you complaining about the
> constant stream of GC messages?
>
> FWIW, on my Ubuntu machine, your example does finish. It takes a while
> though (64 sec).  The compiled (native) version takes .45 sec; the
> byte-compiled version takes 40 sec..  I guess the interpreter isn't
> very efficient in this case.
>
> --
> Ray
>
_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp