Environment variables

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. Runtime boolean knobs use one strict spelling set: 1/true/yes/on to enable and 0/false/no/off to disable, case-insensitively. An empty or unknown value is a typed configuration error. Per-variable parsing is noted where a build tool or measurement hook intentionally has a narrower contract.

​

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. Eligible ordinary query plans automatically select the resident conditional graph, which keeps recursive scan and filter dispatch inside one GPU-side control-flow graph. Two diagnostic controls override that default. They are mutually exclusive: enabling both 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.

​

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.

​

Recorded operator dispatch

Every CudaKernelProvider already owns the complete device-runtime resource graph. The flags below do not select another allocator or provider. They select recorded launch implementations for supported operators inside that same provider-owned runtime. Each uses the strict boolean contract above and 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, and XLOG_GPU_HASH_OUTPUT_PATH drive cross-process determinism tests. The cross-stream lifetime stress test uses XLOG_CROSS_STREAM_STRESS_BASE_SEED, XLOG_CROSS_STREAM_STRESS_CHILD, XLOG_CROSS_STREAM_STRESS_REFERENCE, and XLOG_PARALLEL_STRESS_FIXTURE_MODE; its child/reference variables are internal to the test harness.

​

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