Re: Interesting loop problem

would turning on optimisation on cmucl reduce the numbers ?

On Thu, Aug 6, 2015 at 9:23 PM, Blake McBride <[email protected]> wrote:

> 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
>
_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp