[cmucl-imp] Interesting loop problem
Greetings, I was running some test code to (stupid) test the speed of various lisp implementation including those other than CL. The code I used is as follows: (defun count2 (n) (prog ((i 0)) loop (and (eql i n) (return)) (setq i (+ i 1)) (go loop))) I know the code is terrible, but it was a bit more portable over various lisp dialects. It ran fine on CLISP, SBCL, ABCL, CCL, GCL, ECL, and LISPF4, but not CMUCL. CMUCL ran the code compiled but not interpreted. Try this interpreted: (count2 80000000) ; 80M I get: ; [GC threshold exceeded with 12,013,152 bytes in use. Commencing GC.] ; [GC completed with 106,440 bytes retained and 11,906,712 bytes freed.] ; [GC will next occur when at least 12,106,440 bytes are in use.] ; [GC threshold exceeded with 12,122,352 bytes in use. Commencing GC.] ; [GC completed with 114,616 bytes retained and 12,007,736 bytes freed.] ; [GC will next occur when at least 12,114,616 bytes are in use.] ; [GC threshold exceeded with 12,124,080 bytes in use. Commencing GC.] ..... I am running 20F on Linux. Thanks. Blake McBride
"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? 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
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
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
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
"Blake" == Blake McBride <blake1024@gmail.com> writes:
Blake> See below. Blake> On Thu, Aug 6, 2015 at 10:23 AM, Raymond Toy <toy.raymond@gmail.com> wrote: [snip] >> >> And? Blake> And: Blake> 1. My machine finishes in 1:24 (one minute, 24 seconds) with CMUCL Blake> interpreted. On the same machine giving interpreted (where available) Blake> numbers only: Blake> LISPF4 0:22 Blake> CLISP 0:43 Blake> ABCL 0:24 Blake> GCL 0:34 Blake> ECL 0:10 Blake> CMUCL 1:24 Blake> So, CMUCL is, by very far, the slowest interpreter available. That's a Blake> problem. Yeah, that's not great. Carl tells me that even on 18a it's slow, so the issue goes way back to the early days of cmucl. Blake> 2. Why the GC's? The program allocates no structures, no conses, no Blake> recursion. That's a problem. You ignore how cmucl runs the interpreter. I've never looked in this, but I can imagine all of the consing is coming from the interpreter running the code. If you byte-compile the function, the function doesn't cons. Still rather slow, but not inordinately slow. Blake> 3. Prior to this, I was under the impression that CMUCL was one of the Blake> more mature, efficient, and compliant CL's available. Apparently I was Blake> wrong. That's a problem. I suspect most of the effort was spent on the compiler not the interpreter. I think in that respect cmucl does well. I can imagine the "answer" to a slow interpreter is to just compile the function since the compiler is good. Blake> Does that help answer your question? Yes. -- Ray
participants (3)
-
Bharat Shetty -
Blake McBride -
Raymond Toy