When to Turn on ⎕PARALLEL in Dyalog APL: A Practical Decision Guide

Problem & Takeaway

You have a computationally intensive loop in Dyalog APL and want to know if turning on the built‑in parallel execution (⎕PARALLEL) will actually give you a measurable speed‑up without breaking your code. The key takeaway: enable ⎕PARALLEL only when the workload is embarrassingly parallel, the data set is large enough to amortise thread‑pool overhead, and the code is thread‑safe.

Decision Context

When you set ⎕PARALLEL←n (where n is the number of worker threads or 1 for auto‑detect), Dyalog creates a thread‑pool. Every APL expression that can be executed in parallel is automatically distributed across the workers. This feature is available only in the commercial Dyalog APL distribution that includes the Parallel license.

Key constraints to consider:

• License must support parallel execution.
• Code must be thread‑safe: no mutable shared state unless protected.
• Memory per worker can be high; monitor with ⎕STAT or external tools.
• Debugging is harder; use ⎕PARALLELDEBUG←1 for tracing.
• Overhead can outweigh benefits for small or memory‑bound tasks.

Options Table

Option	Performance	Memory Footprint	Determinism	Debugging Complexity
Single‑threaded (⎕PARALLEL←0)	Baseline – no parallel overhead	Minimal – one process only	Deterministic – order of execution fixed	Simple – no thread context to trace
Parallel (⎕PARALLEL←⎕NCPU or explicit count)	Potentially up to n× faster on CPU‑bound, large‑data workloads	Higher – each worker may allocate its own buffers	Deterministic if code is thread‑safe; otherwise nondeterministic	More complex – need to enable ⎕PARALLELDEBUG and handle worker traces

Trade‑Offs

• Speed‑up vs. Overhead: Thread‑pool creation and context switching add latency. For n ≈ 10 M elements, the overhead is negligible, but for n ≈ 10 K it can dominate.
• Determinism: Parallel execution serialises any side‑effecting expression (e.g., ⎕←) automatically, but still requires careful design of shared data structures.
• Memory: Each worker may copy the input array or allocate its own buffers. Monitor with ⎕STAT[⎕STAT'PROC'] to see per‑process memory.
• Debugging: Use ⎕PARALLELDEBUG←1 to see worker IDs and execution order, but this adds runtime cost.
• License: The Parallel feature is only available in the commercial edition; trial versions may not support it.

Concrete Implementation & Validation

Below is a minimal example that multiplies two large vectors element‑wise. The same code runs in single‑threaded and parallel modes; you can compare elapsed times with ⎕TIME and verify that the result is identical.

⍝--- Setup -----------------------------------------------------
⎕PARALLEL←0          ⍝ Start in single‑threaded mode
⎕NCPU←⎕NCPU          ⍝ Number of CPU cores (available in Dyalog)

⍝ Create two large vectors (10 M elements)
size←10 000 000
A←⍳size            ⍝ 1 2 3 ... size
B←size-⍳size        ⍝ size size-1 ... 1

⍝--- Single‑threaded run -----------------------------------
⎕PARALLEL←0
⎕TIME
C1←A×B            ⍝ Element‑wise multiplication

⍝--- Parallel run ----------------------------------------------
⎕PARALLEL←⎕NCPU   ⍝ Enable parallel execution with all cores
⎕TIME
C2←A×B

⍝--- Validation -----------------------------------------------
⎕←'Results equal? ',(C1=C2)⍎'⍴'⍝ Should print 1

⍝--- Check worker processes -----------------------------------
⎕STAT[⎕STAT'PROC']⍝ Shows the number of active processes

Explanation of key steps:

• ⎕PARALLEL←⎕NCPU tells Dyalog to create a pool with one worker per core.
• The expression A×B is an element‑wise operation that Dyalog automatically splits across workers.
• Running ⎕TIME before each assignment gives the elapsed time; the difference indicates the speed‑up.
• Comparing C1 and C2 ensures the parallel run is deterministic and correct.
• Calling ⎕STAT[⎕STAT'PROC'] confirms that multiple worker processes are active during the parallel run.

**Caution**: If the code contains side‑effects (e.g., writing to the console or modifying global variables), Dyalog will implicitly serialise those parts, potentially negating the performance benefit. Keep side‑effects outside the parallel region or protect shared state with locks.

Summary

Enable ⎕PARALLEL when you have a large, CPU‑bound, embarrassingly parallel workload and your code is thread‑safe. Validate by comparing single‑threaded and parallel runs, checking determinism, and monitoring memory usage. If the speed‑up is marginal or the workload is memory‑bound, stay with single‑threaded execution to avoid unnecessary overhead.