Major Section: PARALLELISM
This documentation topic relates to the experimental extension of ACL2 supporting parallel evaluation and proof; see 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 pargs
, 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))
One trivial way to enable parallel evaluation of a form is to surround it with a call to macro top-level. Consider the following example.
(top-level (pargs (cons (expensive-fn-1 4) (expensive-fn-2 5))))Then in an executable image that supports parallel evaluation -- see compiling-acl2p for instructions on how to build such an executable --
(expensive-fn-1 4)
and (expensive-fn-2 5)
can evaluate in
parallel.A second way to enable parallel evaluation of a form is to place it inside a function body. For example, consider the following definition.
(defun foo (x y) (pargs (cons (expensive-fn-1 x) (expensive-fn-2 y))))Then in an executable image that supports parallel evaluation, submission of the form
(foo 4 5)
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).