[cmucl-imp] Interesting loop problem

[Blake McBride]

Well, compiling the code gets rid of the problem.  The point is that the
default interpreter shouldn't be allocating storage unnecessarily.

On Thu, Aug 6, 2015 at 11:01 AM, Bharat Shetty <bshetty at gmail.com> wrote:

> would turning on optimisation on cmucl reduce the numbers ?
>
> On Thu, Aug 6, 2015 at 9:23 PM, Blake McBride <blake1024 at gmail.com> wrote:
>
>> See below.
>>
>> On Thu, Aug 6, 2015 at 10:23 AM, Raymond Toy <toy.raymond at gmail.com>
>> wrote:
>>
>> > >>>>> "Blake" == Blake McBride <blake1024 at gmail.com> 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
>> cmucl-imp at cmucl.cons.org
>> http://lists.zs64.net/mailman/listinfo/cmucl-imp
>>
>
>