What does ACL2 exit code 137 mean? The output reads like this:
Form: ( INCLUDE-BOOK "centaur/ubdds/param" ...)
Rules: NIL
Time: 0.00 seconds (prove: 0.00, print: 0.00, other: 0.00)
:REDUNDANT
Note: not introducing any A4VEC field bindings for A, since none of
its fields appear to be used.
Note: not introducing any MODSCOPE field bindings for SCOPE, since
none of its fields appear to be used.
;;; Starting full GC, 10,736,500,736 bytes allocated.
Exit code from ACL2 is 137
top.cert seems to be missing
Looks like "Linux OOM killer" killed your program.
Exit status 137 means program was terminated with singal 9 (SIGKILL) (See here):
When a command terminates on a fatal signal whose number is N, Bash uses the value 128+N as the exit status.
128+9=137
This message from the log tells us that your ACL2 proof consumed 10Gb of memory:
;;; Starting full GC, 10,736,500,736 bytes allocated.
Linux has a feature where it kills an offending process when the system is very low on memory. It is called OOM Killer: https://www.kernel.org/doc/gorman/html/understand/understand016.html
Such events are logged by kernel. You can immediately see them just to make sure:
$ dmesg |grep -i "killed process"
Mar 7 02:43:11 myhost kernel: Killed process 3841 (acl2) total-vm:128024kB, anon-rss:0kB, file-rss:0kB
There are two ACL2 calls : set-max-mem and maybe-wash-memory which you can use to control memory consumtion.
(include-book "centaur/misc/memory-mgmt" :dir :system) ;; adds ttag
(value-triple (set-max-mem (* 4 (expt 2 30)))) ;; 4 GB
Unfortunately these two calls do not guarantee that memory will be freed. Consider using a more powerful computer for your proof.
An exit code of 137 suggests that it has been killed by bash with -9
Reference: http://www.tldp.org/LDP/abs/html/exitcodes.html
Related
It's completely fine to run #'cl-state-machine-examples/tamagochi:run,
But generated executable signals SIMPLE-ERROR like this:
Built: https://github.com/ageldama/cl-state-machine/releases/tag/fail-sbcl-slot-value
And I get:
$ ./tamagochi.exe
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10005384C3}>:
When attempting to set the slot's value to 5 (SETF of SLOT-VALUE), the slot
MONEY is missing from the object
#<CL-STATE-MACHINE-EXAMPLES/TAMAGOCHI::TAMAGOCHI-STATUS {1001B7B9B3}>.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit from the current thread.
((:METHOD SLOT-MISSING (T T T T)) #<unused argument> #<CL-STATE-MACHINE-EXAMPLES/TAMAGOCHI::TAMAGOCHI-STATUS {1001B7B9B3}> MONEY SETF 5) [fast-method]
0]
using:
Uname -a : Linux arch-desktop 5.3.11-arch1-1 #1 SMP PREEMPT Tue, 12
Nov 2019 22:19:48 +0000 x86_64 GNU/Linux
https://github.com/ageldama/cl-state-machine/releases/tag/fail-sbcl-slot-value
Both for:
- sbcl-1.5.0-x86-64-linux AND sbcl-1.5.9-x86-64-linux/
Build log is:
This is SBCL 1.5.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
WARNING: redefining UIOP/PACKAGE:FIND-PACKAGE* in DEFUN
...CUT...
WARNING: redefining UIOP/BACKWARD-DRIVER:VERSION-COMPATIBLE-P in DEFUN
[undoing binding stack and other enclosing state... done]
[performing final GC... done]
[defragmenting immobile space... (fin,inst,fdefn,code,sym)=1062+946+18321+18719+25423... done]
[saving current Lisp image into /home/jhyun/P/cl-state-machine/tamagochi.exe:
writing 0 bytes from the read-only space at 0x50000000
writing 432 bytes from the static space at 0x50100000
writing 27852800 bytes from the dynamic space at 0x1000000000
writing 2011136 bytes from the immobile space at 0x50300000
writing 12144640 bytes from the immobile space at 0x52100000
done]
Thank you in advance!
My guess would be that your keyword->symbol function interns into the wrong package, because the read in there is executed from a different one:
(defun keyword->symbol (kw-or-symbol)
(with-input-from-string (s-in (string kw-or-symbol))
(read s-in)))
I'd use intern to create the symbol:
(defun keyword->symbol (kw-or-symbol)
(intern (symbol-name kw-or-symbol)
#.*package*))
The #.*package* construct gives the value of *package* at read time, i. e. when the function form above was read.
Since I’m interested in C++ as well as in Lisp, I tried to reproduce the benchmark presented here written by Guillaume Michel. The benchmark is basically a DAXPY BLAS Level 1 operation performed multiple times on big arrays. The full code was thankfully posted on github and is in both languages roughly one page.
Sadly, I discovered that it was not possible for me to reach the velocity of his calculations for lisp.
For Linux, he got similar results for C++ as well as Lisp:
Size | C++ | Common Lisp
100,000,000 | 181.73 | 183.9
The numbers differ (naturally) both on my PC:
Size | C++ | Common Lisp
100,000,000 | 195.41 | 3544.3
Since I wanted an additional measurement, I started both programs with the time command and got (shortened up):
$ time ./saxpy
real 0m7.381s
$ time ./saxpy_lisp
real 0m40.661s
I assumed different reasons for this blatant difference. I scanned through both code samples, but found no big algorithmic or numeric difference between the C++ and Lisp Version. Then I thought, the usage of buildapp created the delay, so I started the benchmark directly in the REPL. My last resort was to try another version of sbcl, so I downloaded the newest sbcl-1.3.11 and evaluated it there – still the (optimized) Lisp version needs much longer than it’s C++ counterpart.
What am I missing?
I cannot replicate your findings:
sylwester#pus:~/a/bench-saxpy:master$ sbcl --dynamic-space-size 14000
This is SBCL 1.3.1.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "saxpy.lisp")
; compiling file "/pussycat/natty-home/westerp/apps/bench-saxpy/saxpy.lisp" (written 06 NOV 2016 12:04:30 AM):
; compiling (DEFUN SAXPY ...)
; compiling (DEFUN DAXPY ...)
; compiling (DEFMACRO TIMING ...)
; compiling (DEFUN BENCH ...)
; compiling (DEFUN MAIN ...)
; /pussycat/natty-home/westerp/apps/bench-saxpy/saxpy.fasl written
; compilation finished in 0:00:00.038
#P"/pussycat/natty-home/westerp/apps/bench-saxpy/saxpy.fasl"
NIL
NIL
* (load "saxpy.fasl")
T
* (main t)
Size, Execution Time (ms)
10, 0.0
100, 0.0
1000, 0.0
10000, 0.1
100000, 0.49999997
1000000, 3.6
10000000, 39.2
100000000, 346.30002
(NIL NIL NIL NIL NIL NIL NIL NIL)
So on my machine it took 346ms (relatively old machine). The whole test took about 5 seconds but that is a series of many tests. Interesting that running from sbcl was faster than making an image and running it:
sylwester#pus:~/a/bench-saxpy:master$ make lisp
buildapp --output saxpy_lisp --entry main --load saxpy.lisp --dynamic-space-size 14000
;; loading file #P"/pussycat/natty-home/westerp/apps/bench-saxpy/saxpy.lisp"
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into saxpy_lisp:
writing 4944 bytes from the read-only space at 0x20000000
writing 3168 bytes from the static space at 0x20100000
writing 60522496 bytes from the dynamic space at 0x1000000000
done]
sylwester#pus:~/a/bench-saxpy:master$ ./saxpy_lisp
Size, Execution Time (ms)
10, 0.0
100, 0.0
1000, 0.0
10000, 0.0
100000, 0.4
1000000, 3.5
10000000, 40.2
100000000, 369.49997
In the C version I get:
100000000, 296.693634, 295.762695, 340.574860
It seems like the C version actually calculates the same in 3 different ways and reports the time it took. Using time wouldn't do it justice.
Over a remote ssh connection, I'm trying to cross-compile sbcl using clisp. The steps I've followed thus far are such:
I downloaded most recent sbcl source, (at this time sbcl-1.3.7), uncompressed it, and entered its source directory.
Then to build it:
root#remotehost:/sbcl-1.3.7# screen
root#remotehost:/sbcl-1.3.7# sh make.sh --prefix=/usr --dynamic-space-size=2Gb --xc-host='clisp -q'
root#remotehost:/sbcl-1.3.7# Ctrl-A Ctrl-D
[detached from 4486.pts-1.remotehost]r/fun-info-funs.fas
root#remotehost:/sbcl-1.3.7#
Over a second remote ssh connection to the same box, top reports cpu usage at 6%
nproc says I have 16 cores (this is google compute engine--no way could I afford something with 16 cores :)
MAKEFLAGS are set in my environment to -j16, but I guess clisp isn't aware of that. How can I get this build to make use of all 16 cores?
I reccomend you to use a parallism library, I really like lparallel library
It has pretty utilities to parallelize your code ammong all processors in your machine. This is an example for my macbook pro (4 cores) using SBCL. There are a great series of common lisp concurrence and parallelism here
But let's create a sample example using lparallel cognates, note that this example is not a well exercise of parallelism is only to show the power of leparallel and how easy is to use.
Let's consider a fibonacci tail recursive function from cliki:
(defun fib (n) "Tail-recursive computation of the nth element of the
Fibonacci sequence" (check-type n (integer 0 *)) (labels ((fib-aux
(n f1 f2)
(if (zerop n) f1
(fib-aux (1- n) f2 (+ f1 f2)))))
(fib-aux n 0 1)))
This will be the sample high computation cost algorithm. let's use it:
CL-USER> (time (progn (fib 1000000) nil))
Evaluation took:
17.833 seconds of real time
18.261164 seconds of total run time (16.154088 user, 2.107076 system)
[ Run times consist of 3.827 seconds GC time, and 14.435 seconds non-GC time. ]
102.40% CPU
53,379,077,025 processor cycles
43,367,543,984 bytes consed
NIL
this is the calculation for the 1000000th term of the fibonacci series on my computer.
Let's for example calculate a list of fibonnaci numbers using mapcar:
CL-USER> (time (progn (mapcar #'fib '(1000000 1000001 1000002 1000003)) nil))
Evaluation took:
71.455 seconds of real time
73.196391 seconds of total run time (64.662685 user, 8.533706 system)
[ Run times consist of 15.573 seconds GC time, and 57.624 seconds non-GC time. ]
102.44% CPU
213,883,959,679 processor cycles
173,470,577,888 bytes consed
NIL
Lparallell has cognates:
They return the same results as their CL counterparts except in cases
where parallelism must play a role. For instance premove behaves
essentially like its CL version, but por is slightly different. or
returns the result of the first form that evaluates to something
non-nil, while por may return the result of any such
non-nil-evaluating form.
first load lparallel:
CL-USER> (ql:quickload :lparallel)
To load "lparallel":
Load 1 ASDF system:
lparallel
; Loading "lparallel"
(:LPARALLEL)
So in our case, the only thing that you have to do is initially a kernel with the number of cores you have available:
CL-USER> (setf lparallel:*kernel* (lparallel:make-kernel 4 :name "fibonacci-kernel"))
#<LPARALLEL.KERNEL:KERNEL :NAME "fibonacci-kernel" :WORKER-COUNT 4 :USE-CALLER NIL :ALIVE T :SPIN-COUNT 2000 {1004E1E693}>
and then launch the cognates from the pmap family:
CL-USER> (time (progn (lparallel:pmapcar #'fib '(1000000 1000001 1000002 1000003)) nil))
Evaluation took:
58.016 seconds of real time
141.968723 seconds of total run time (107.336060 user, 34.632663 system)
[ Run times consist of 14.880 seconds GC time, and 127.089 seconds non-GC time. ]
244.71% CPU
173,655,268,162 processor cycles
172,916,698,640 bytes consed
NIL
You can see how easy is to parallelize this task, lparallel has a lot of resources that you can explore:
I also add a capture of the cpu usage from the first mapcar and pmapcar in my Mac:
SBCL cross compiling (aka bootstrapping) is done in 100% vanilla CL and there are nothing in the standard about threading or multiple processes.
Using a supplied SBCL binary for your machine might not use threading either even though I know SBCL does have thread support in the language.
You only need to do this if you have altered the source of SBCL as the latest supported version is usally precompiled already. I haven't compiled SBCL myself but i doubt it takes longer than my compilations of linux in the 90s that used less time than my nightly sleep.
When I run the following code:
(defun countdown (n)
(if (>= n 0)
(cons n (countdown (- n 1)))))
(countdown 100000)
I get the following message :
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution
debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "main thread" RUNNING {1002B03653}>:
Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.
PROCEED WITH CAUTION.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
How do I increase the stack space? I do not want to change the code above; I supplied it purely to illustrate stack exhaustion.
Calling sbcl with the --help option on the command line gives some useful common options, including an option for how to increase the stack space. You want to to use the --control-stack-size argument.
$ sbcl --help
Usage: sbcl [runtime-options] [toplevel-options] [user-options]
Common runtime options:
--help Print this message and exit.
--version Print version information and exit.
--core <filename> Use the specified core file instead of the default.
--dynamic-space-size <MiB> Size of reserved dynamic space in megabytes.
--control-stack-size <MiB> Size of reserved control stack in megabytes.
...
By specifying a bigger value there, we can run your code:
$ sbcl --control-stack-size 100000
* (defun countdown (n)
(if (>= n 0)
(cons n (countdown (- n 1)))))
;=> (100000 … 6 5 4 3 2 1 0)
Not exactly in time for the question at hand, but for anyone also wondering about the --control-stack-size:
From the SBCL manual section "3.3.1 Runtime Options" the default value for the --control-stack-size is 2 megabytes.
So for a list containing 100k 64bit-integers 7 megabyte sbcl --control-stack-size 7 should be sufficient!
As a reference:
CL-USER> (type-of 42)
(INTEGER 0 4611686018427387903)
CL-USER> (/ (* 64 100e3) (expt 2 20))
6.1035156
Sample code in page 144 of Touretzky's Lisp book causes error on my environment. Is anything wrong with how I run?
(defun price-change (old new)
(let* ((diff (- new old))
(proportion (/ diff old))
(percentage (* proportion 100.0)))
(list ’widgets ’changed ’by percentage
’percent))
)
Here's the error. I don't understand why string "widgets" is evaluated...
Break 5 [7]> (price-change 1.25 1.35)
*** - LET*: variable ’WIDGETS has no value
The following restarts are available:
USE-VALUE :R1 Input a value to be used instead of ’WIDGETS.
STORE-VALUE :R2 Input a new value for ’WIDGETS.
ABORT :R3 Abort debug loop
ABORT :R4 Abort debug loop
ABORT :R5 Abort debug loop
ABORT :R6 Abort debug loop
ABORT :R7 Abort debug loop
ABORT :R8 Abort main loop
Environment: Ubuntu 11.10, GNU CLISP 2.49
You need to use the quote character apostrophe: '. You did not. You have used a right quotation mark.