# Julia Port Evaluation

Tracks evidence for and against porting the Deep CFR training pipeline
from Python/Cython to Julia. Plot/game/parity stays Python regardless;
the candidate scope is the training stack (traversal, networks,
inference).

## Why we are even considering this

`docs/performance.md` "Option A Bench Result and Structural Ceiling"
established that the current sync-blocking traversal in Python
multiprocessing caps realized batch size at `num_workers`. Escaping
that ceiling requires either restructuring traversal (Option B/C) or
moving to a runtime where threads can carry many concurrent traversals
in one process. Julia is the most credible candidate for the latter
(Mojo too immature, free-threaded CPython requires nogil-cleaning our
existing Cython — see `docs/reports/cost_*` triplet).

Decision criteria for going forward:

1. Single-thread compute parity with current Cython (or better).
2. GC behavior under tight CFR-shape recursion is acceptable (low
   pause time, low share).
3. Multi-thread scaling on the same CFR-shape pattern is near-linear,
   demonstrating the GIL-free promise actually holds.
4. ML stack (Flux.jl + CUDA.jl) covers our needs (MLP forward, AD,
   GPU). Our model is small and standard.
5. A real-game-state slice can be ported and compared head-to-head.

## Evidence so far

### 2026-05-07 — Safe heuristic single-thread parity (criterion 1)

Path: `experiments/julia_heuristic/`.

1,838 snapshots in 157.471 ms median (~85.6 μs/call). Action-sequence
parity vs Python. Same order of magnitude as the Cython port of the
same bot (Cython gives ~2.55× over original Python on a 200-game
eval).

**Verdict on criterion 1:** Pass for isolated single-call work.

### 2026-05-07 — CFR-shape recursion toy (criteria 1, 2)

Path: `experiments/julia_cfr_toy/`. See that directory's README for
the full table.

Headline: Julia ~1.9× faster than Cython, 0 MB allocation, 0% GC time
on the hot path. Root regret parity ε ≤ 1e-9.

**Verdict on criterion 1:** Pass. Julia matches or beats Cython on
the CFR-shape pattern.

**Verdict on criterion 2:** Strong pass. Type-stable code produces
zero heap traffic. The GC concern that was the main argument against
Julia adoption did not materialize here.

Caveats: Cython 21.3 MB alloc suggests room for tighter typing;
best-effort Cython could narrow the gap. Toy is not a game.

### 2026-05-07 — CFR-shape multi-thread scaling on the same toy (criterion 3)

Path: `experiments/julia_cfr_toy/` (`bench_cfr_threaded.jl`). Same
100 iters × 1000 traversals total work split across threads. Thread-
local trees, root regrets reduced at the end.

| threads | iter ms | speedup | efficiency |
| ---:    | ---:    | ---:    | ---:       |
| 1       | 0.223   | 1.00×   | 100%       |
| 2       | 0.130   | 1.71×   | 85%        |
| 4       | 0.097   | 2.29×   | 57%        |
| 8       | 0.093   | 2.40×   | 30%        |

The light workload is too small to settle the question: 1T iter time is
only ~0.2 ms, so thread dispatch overhead can dominate.

Heavy mode keeps the same tree and algorithm but increases traversals
per iteration from 1000 to 50000 (50× work). This raises 1T iter time
to 8.272 ms.

| threads | iter ms | speedup | efficiency |
| ---:    | ---:    | ---:    | ---:       |
| 1       | 8.272   | 1.00×   | 100%       |
| 2       | 5.058   | 1.64×   | 82%        |
| 4       | 2.602   | 3.18×   | 79%        |
| 8       | 1.739   | 4.76×   | 59%        |

**Verdict on criterion 3:** PARTIAL. Heavy 8T efficiency is 59%.
Dispatch overhead was a significant part of the light-mode result, but
the heavier workload still does not reach near-linear 8-thread scaling.
Julia delivers useful throughput scaling (4.76× at 8T), but this is not
the decisive PASS threshold for the threading criterion.

## Open evidence (criterion 5)

- **Real-game-state slice port.** Port `play_card` + scoring, run on a
  fixed corpus of game states, compare to current Cython. Criterion 5.
  Not started. Skipped for now because criterion 4 failed; per the
  decision rule, the full Julia port is no longer a GO candidate on the
  current evidence.

### 2026-05-07 — Flux.jl + CUDA.jl MLP forward (criterion 4)

Path: `experiments/julia_flux_mlp/`.

Same `DeepCFRMLP` shape as the current Deep CFR default MLP:
365→512→512→512→22, ReLU, identical PyTorch-exported weights loaded
into Flux. Output parity passed with max absolute difference
`5.215e-08`. Timing uses 10 warmup forwards, then 100 timed forwards,
with CUDA synchronized around the timed loop in both runtimes.

| backend | batch | forward ms | μs/state | ratio vs PyTorch |
| ---     | ---:  | ---:       | ---:     | ---:             |
| PyTorch | 1     | 0.0829     | 82.8755  | 1.00×            |
| Flux    | 1     | 0.1669     | 166.8867 | 2.01×            |
| PyTorch | 64    | 0.0927     | 1.4477   | 1.00×            |
| Flux    | 64    | 0.1909     | 2.9836   | 2.06×            |
| PyTorch | 256   | 0.0877     | 0.3427   | 1.00×            |
| Flux    | 256   | 0.1758     | 0.6867   | 2.00×            |

**Verdict on criterion 4:** FAIL. bs=64 is ~2.06× slower than
PyTorch, outside the ±20% PASS band. bs=1 and bs=256 are also ~2×
slower, outside the ±30% bands. Criterion 5 was not run after this
FAIL because the full Julia-port decision rule is already blocked.

### 2026-05-07 — Torch.jl MLP forward retry (criterion 4)

Path: `experiments/julia_torch_mlp/`.

Torch.jl was tested as a possible replacement for Flux/CUDA on the same
DeepCFRMLP forward benchmark. The measurement could not start because
Torch.jl v0.1.3 fails during package load/precompile on this Julia
1.11.9 environment:

```text
UndefVarError: libtorch_c_api not defined in Torch.Wrapper
```

This occurs before model construction or timing, so there is no
Torch.jl forward result to compare against PyTorch.

**Verdict on criterion 4 after Torch.jl retry:** unchanged FAIL. Flux.jl
misses the performance threshold, and Torch.jl is blocked by package
load failure rather than providing a successful re-measurement.

## Pass/fail thresholds (decided in advance)

These are explicit so that the moment a measurement lands, the decision
is automatic. No re-deliberation, no "let's discuss it." If a result
sits on a boundary, treat it as the pessimistic side.

**Criterion 3 (multi-thread scaling)** — already measured on the toy:

- PASS: 8T efficiency ≥ 80%.
- PARTIAL: 50–80%. (Current toy result: 59%.)
- FAIL: < 50%.

Re-measure on the real-game-state slice (criterion 5) when that lands.
The toy figure is informative but not authoritative; real workloads have
more compute per traversal and may scale better.

**Criterion 4 (Flux.jl + CUDA.jl MLP forward)**:

- PASS: bs=64 forward time within ±20% of PyTorch on the same GPU and
  same `DeepCFRMLP` shape (input_dim=365, hidden=512, layers=3,
  output_dim=22). Both bs=1 and bs=256 must also be within ±30% (single-
  state and large-batch matter for traversal-time and eval-time
  respectively).
- FAIL: any of the three batch sizes regresses by more than the band
  above. Single PASS at one batch size is not sufficient.

Methodology: 100-iter timing with 10-iter warm-up, `inference_mode`
equivalent on both sides. Identical weights (export from PyTorch, load
into Flux). Compare per-state latency (μs/state).

**Criterion 5 (real-game-state slice)**:

- Scope: a Julia port of a single representative slice of the Lost
  Cities engine — at minimum `legal_actions` + `apply_action` + scoring
  for end-of-game, against a fixed corpus of ≥1000 game states exported
  from the current Cython engine.
- Action-equivalence requirement: byte-identical `legal_actions` set
  and post-action state for every corpus entry. ε = 0; this is a
  correctness gate, not a numerical one.
- PASS: single-thread per-state cost within ±25% of current Cython, AND
  re-running the heavy threaded benchmark on this slice (1/2/4/8T)
  yields 8T efficiency ≥ 75%. Both conditions required.
- FAIL: single-thread regresses > 50% vs Cython, OR 8T efficiency
  < 60% on the real slice.
- BORDERLINE: between FAIL and PASS — flag in the doc, do not start a
  port; consider whether a different scoping (port traversal recursion
  only, leave game engine in Cython) clears the threshold instead.

## Decision rule

After all of criteria 3 (re-measured on real slice), 4, 5 land:

- All three PASS → start a port plan. Deferred Option A re-enable, AMP,
  compile, TensorRT all get re-evaluated under the new runtime.
- Criterion 5 PASS but criterion 4 FAIL → consider a hybrid: keep
  PyTorch for networks via PythonCall.jl/PyCall, port traversal to
  Julia. Re-evaluate IPC/FFI cost separately.
- Any criterion FAIL beyond the borderline → **stay on Python/Cython,
  pursue Option B (per-worker interleaved traversal)** as the
  GIL-escape path instead. Document the FAIL result, close this thread.
- Criterion 5 BORDERLINE → reduce port scope (recursion-only) and
  re-test.

Cost-of-being-wrong asymmetry: a port is months of work; staying is
zero work but caps us at the current ceiling. So the bar to GO is
deliberately set above 50%; the bar to STAY is permissive. This is on
purpose.

## Decision posture

No full Julia port on the current evidence. The completed benchmarks
remove the main risk (GC under recursion) and confirm compute parity,
but criterion 3 is only PARTIAL and criterion 4 is FAIL. The Torch.jl
retry did not reverse criterion 4 because Torch.jl failed to load in
this Julia environment. Per the decision rule, a full port would spend
months to replace a PyTorch GPU path that is already ~2× faster than
Flux for the exact model shape we use.

Recommended next path: stay on Python/Cython and pursue Option B
(per-worker interleaved traversal) as the GIL-escape path. A narrower
Julia experiment could still be considered later for traversal-only
logic, but it would need an explicit hybrid plan that keeps PyTorch for
networks and separately proves PythonCall/PyCall overhead is acceptable.
For the traversal bottleneck clarification and Option B speedup envelope,
see `docs/performance.md` "Clarifying the traversal bottleneck: sync
policy boundary, not SIMD."

Criterion 5 remains unrun because criterion 4 already blocks the full
port decision.
