Major Section: PARALLELISM
Calls of parallelism primitives made explicitly in the ACL2 top-level loop, as opposed to inside function bodies, will never cause parallel evaluation. Such calls will either execute with serial evaluation or will cause an error; see set-parallel-evaluation.
Consider for example the following call of pargs in the ACL2
top-level loop. Instead of executing parge, ACL2 macroexpands away this
call, leaving us with serial evaluation of the arguments to the cons
call, or else causes an error (see set-parallel-evaluation). If there is no
error, then
(pargs (cons (expensive-fn-1 4) (expensive-fn-2 5)))expands into:
(cons (expensive-fn-1 4) (expensive-fn-2 5))
A trivial way to enable parallel evaluation of a form is to put it inside a function body. For example, consider the following definition.
(defun foo (x y) (declare (xargs :guard t)) (pargs (cons (expensive-fn-1 x) (expensive-fn-2 y))))Then in an executable image that supports parallel evaluation -- see parallelism-build for instructions on how to build such an executable -- submission of the form
(foo 4 5), even in the ACL2 top-level loop,
can cause parallel evaluation of (expensive-fn-1 4) and
(expensive-fn-2 5).
Note that guards need not be verified in order to obtain parallel
evaluation. The only restrictions on parallel evaluation are to use an
executable supporting it, to avoid calling parallelism primitives directly in
the top-level loop, to have sufficient resources (especially, threads)
available, and to avoid explicitly disabling parallel evaluation
see set-parallel-evaluation).