parallel evaluation in the ACL2 top-level loop
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).