parallelism¶
How much of the machine Pelorus is allowed to use. It also decides between the single-core and the multi-core implementation of each pipeline stage.
| Option | Default | Starter |
|---|---|---|
num_threads |
3 |
yes |
cpu_only |
false |
|
execution_mode |
Auto |
yes |
pipelining |
Pipelined |
|
decision_threshold_stddevs |
2.0 |
|
decision_samples_per_mode |
20 |
parallelism.num_threads¶
Upper bound on the CPU threads used for parallel processing. all uses every available core. Pelorus is meant to leave room for whatever else runs on the machine, so raising this trades headroom for latency.
Part of the starter configuration.
parallelism.cpu_only¶
Force CPU-only processing regardless of available GPU backends.
Type: boolean.
parallelism.execution_mode¶
How each pipeline stage picks between the single-core and the rayon implementation. Auto measures both at runtime and keeps whichever wins. Pick one of the other two when the execution path has to stay fixed, for example when reporting runtime figures in a paper.
this to SingleCore is what actually takes rayon out of the path.
Accepted values: auto, singlecore, rayon, single_core, single-core
Accepted values are case-insensitive.
Part of the starter configuration.
parallelism.pipelining¶
Pipelined receives input, preprocesses, synchronizes and registers on separate threads, so consecutive scans overlap. Sequential receives all input on one thread in arrival order and processes each scan there before taking the next message, which keeps the processing order fixed.
Accepted values: pipelined, sequential
Accepted values are case-insensitive.
parallelism.decision_threshold_stddevs¶
Number of standard errors by which one CPU execution mode must beat the other before Pelorus decides the execution mode for the next phase.
Type: number.
Minimum: 0 (inclusive).
parallelism.decision_samples_per_mode¶
Number of measurements collected for each mode before a decision is allowed.
Type: integer.
Minimum: 1 (inclusive).