setup_SerialExecution: Set up a 'SerialExecutionConfig'

View source: R/050_ExecutionConfig.R

setup_SerialExecutionR Documentation

Set up a SerialExecutionConfig

Description

Execution in the calling process: nothing is dispatched to a worker. Takes no n_workers and no future_plan, neither of which a serial run can act on.

Usage

setup_SerialExecution(
  n_workers_algorithm = NULL,
  device = NULL,
  on_error = c("continue", "stop", "stop_outer"),
  seed = NULL,
  shared_memory = c("auto", "none", "always")
)

Arguments

n_workers_algorithm

Optional Integer [1, Inf): Threads for a self-parallelizing algorithm, overriding the automatic assignment.

device

Optional DeviceConfig: Compute device, as a type name – "cpu", "cuda", "mps" (the Apple silicon GPU) or "opencl" (a LightGBM GPU build) – or setup_CUDA to name which GPUs. NULL selects one per algorithm: "cuda" where the machine has it and the algorithm can use it, else the CPU. An algorithm that cannot use the requested device runs on the CPU, and the run's resources line says so; a device the machine lacks is an error when an algorithm tries to use it. "mps" is never selected automatically: in rtemis benchmarks on an Apple M5 the CPU was faster for every network narrower than about 1024 units or trained in batches smaller than about 2048 cases, often by 2 to 5 times, and "mps" was faster by up to about 25% only with both and thousands of features. It also slows down across many fits in one R session, and a seed does not reach dropout on it.

on_error

Character {"continue", "stop", "stop_outer"}: Failure policy. "continue" makes grid cells and unscorable hyperparameter combinations non-fatal (recorded, warned, and excluded), failing only when nothing is scorable or the final model fails; "stop" aborts on any error; "stop_outer" tolerates grid-cell failures but aborts on an outer-fold failure.

seed

Optional Integer [0, Inf): Master seed for the run's computation RNG, from which one independent substream per parallel task is derived. Left NULL, a seed is drawn from the current RNG stream and recorded on the returned object, so every run is reproducible and the seed it used is auditable. Distinct from a ResamplerConfig seed, which governs how the data is split.

shared_memory

Character {"none", "auto", "always"}: Whether to hand workers the training data through OS shared memory instead of serializing a copy to each. "auto" is the default: it shares whenever it can – workers parallel and on this machine, mori installed – and quietly does not when it cannot, falling back to the ordinary transport. "none" disables it. "always" is a demand: it shares even when the run is sequential, so a run can be compared against its own shared counterpart, and raises an error when the request cannot be met, for a caller relying on sharing to stay inside a memory budget.

Details

n_workers_algorithm still applies: it is threads within the calling process, not worker processes, so a self-parallelizing algorithm runs multi-threaded under a serial config.

See setup_FutureExecution for how the run's seed is resolved.

Value

SerialExecutionConfig object.

Author(s)

EDG

Examples

setup_SerialExecution()

rtemis documentation built on Oct. 20, 2026, 1:06 a.m.