Re: Interesting loop problem

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 <[email protected]> wrote:

> 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