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