XLOG reads environment variables for tuning, debugging, and parity checking. The defaults are the production configuration — you do not need to set anything for correct results. Most non-default settings fall into two families. Tuning knobs trade memory for speed. Kill switches turn off one of XLOG’s fast execution routes and force the work back onto its slower baseline route, so you can run the same query both ways and compare the answers and timing (an A/B comparison). Two of those fast routes are named throughout this page. The worst-case-optimal join (WCOJ) computes multi-way graph patterns — triangles, cycles, cliques — directly, instead of building a large intermediate table first. Factorized execution represents intermediate results in a compressed form instead of listing every row. Boolean knobs generally accept 1/true to enable and 0/false to disable; per-variable parsing is noted where it differs.

​
Kernel artifacts and build

These control where XLOG finds its compiled GPU kernel files (the .cubin and .ptx binaries the CUDA code runs from) and how those kernels are compiled when you build from source. They are read by the xlog-cuda build script (crates/xlog-cuda/build.rs) at compile time, or by the kernel loader at startup.

​
Runtime and memory

Knobs for GPU memory budgeting and low-level debugging of the runtime. A CUDA stream is a GPU work queue. The XLOG_DEBUG_* probes are diagnostic aids for catching memory bugs and are off in normal use. One variable, XLOG_CDCL_TRACE, traces the GPU SAT solver (CDCL, conflict-driven clause learning — the search behind exact probabilistic inference) and exists only in debug builds. Three controls select how ordinary recursive programs use the resident conditional graph, which keeps recursive scan and filter dispatch inside one GPU-side control-flow graph. They are mutually exclusive: enabling more than one stops evaluation with a configuration error.

​
Join and optimizer knobs

Controls for how XLOG plans and executes joins — the operations that combine relations. Several apply to the worst-case-optimal join (WCOJ) routes for graph-shaped rules: triangle (three-node cycles), 4-cycle, and chain name the rule shapes each dispatch handles. A cost model estimates which route will be cheaper for a given rule, and a variable-order heuristic chooses the order in which join variables are bound. The 4-cycle controls in this table have been available since 0.7.0.

​
Factorized and WCOJ kill switches

These turn off one of XLOG’s fused or factorized fast routes and force the work back onto its plain baseline route, so the two can be run against each other for correctness (parity) and speed comparison. All default to the production fast route (switch off). Two route names appear below. Free Join is XLOG’s generalized multi-way join, which combines several relations at once rather than one pair at a time. The factorized delta is the compressed incremental step of a recursive rule: each round of a recursive query derives only the newly-available facts (the delta), and “factorized” keeps that step compressed instead of listing every row. The Free Join, factorized-delta, aggregate-fusion, and strict-mode controls below have been available since 0.10.0. The 4-cycle kill switch has been available since 0.7.0.
A WCOJ layout or kernel error never corrupts the relation store: by default it is counted, logged to stderr, and the rule falls back to the binary-join path. XLOG_WCOJ_STRICT=1 turns that decline into a hard error for diagnosis.

​
Probabilistic

Controls for XLOG’s two probabilistic-inference engines. A Monte Carlo engine estimates probabilities by random sampling, and an exact engine (D4) compiles the program to a logic circuit and counts its satisfying assignments. The exact engine works over Boolean formulas in CNF (conjunctive normal form — an AND of OR-clauses) and can check its own result with the built-in SAT solver; the size bounds below keep that step from overrunning GPU memory. The D4 compile and verification budget controls have been available since 0.10.0.

​
Rule induction

Controls for exact rule induction — learning logical rules from example data by scoring candidate rules on the GPU. These tune a shared-memory optimization for chain-shaped rules and gate an optional slow reference implementation used only for validation.

​
Device runtime (opt-in)

The recorded-launch device-runtime stack is an alternative GPU backend that records each operation once and replays it, rather than launching kernels the legacy way. It is opt-in: the legacy launch paths remain the production default until the runtime stack is certified end-to-end. The per-operator flags below parse as “set and non-empty and not 0” and each is also implied by the umbrella XLOG_USE_RECORDED_OPS.

​
Bench, test, and developer-tool variables

These variables are read only by test binaries, Criterion benchmarks, release validation, or one-off developer tools. None of them affects a normal xlog or pyxlog run, and none is a production knob. Release validation and determinism tests: XLOG_REQUIRE_CUDA=1 makes CUDA-initialization failures in the certification suite panic instead of skipping (exported by scripts/validate_release_gpu.sh so a CPU-only machine can never satisfy the release gate). The same script requires XLOG_PINNED_CORPUS_ROOT for its resident preparation, production, and scaling tests. XLOG_DETERMINISTIC, XLOG_CNF_OUTPUT_PATH, XLOG_GPU_HASH_OUTPUT_PATH, and the XLOG_A3/XLOG_A3A4 family drive cross-process determinism and stress tests.

​
Example scripts

The shipped CAVIAR example reads one variable, the same CAVIAR_XML_DIR its tests read. It is not part of the runtime.

​
See also

  • CLI reference — the CLI reads no environment variables of its own, though xlog run --wcoj sets two for the process
  • Probabilistic engines — exact and Monte Carlo inference