[cromwellian]

🛠️ Codex

Keep complete SQL training steps and optimizer state on GPU. TrainingSession owns finite rectangular state, reuses the primal already computed by ddx, compiles gradient/clipping/AdamW stages with explicit mutable inputs, and atomically publishes state after validation. Bounded integer domains enable GPU token gathers and embedding-gradient scatter. Explicit seed/step dropout keys and NPZ checkpoints support deterministic resume; ordinary query input/snapshot behavior is preserved.

Add real Shakespeare character training matching native nanoGPT: 10,745,088 parameters, batch 12/context 256, 6 layers/heads, width 384, exact GELU, dropout .2, clipped AdamW, original learning-rate/evaluation schedule. --steps 5 performs exactly five updates without shortening the schedule. An independent original-model/PyTorch oracle checks every loss, raw gradient, weight and optimizer moment outside the timer.

Depends on compact SQL execution #303, EinFold #157, and ddx #256/#257. Incremental review: cromwellian/xarray-sql@codex/compact-sql-execution...codex/resident-sql-training . The upstream fork PR's default diff contains predecessors until they merge.

Measured resident GPU: 101.3 ms mean over updates 2–100, versus the earlier Arrow GPU path's 2.024 s (19.98×). Native PyTorch MPS measured 27.0 ms; SQL remains 3.76× slower. A separate fully checked five-step run measured 145.9 ms warm. All 100 timed resident steps exported zero arrays and read zero array bytes, while each read a validation flag and loss scalar. There was one whole-step compilation. Batch upload, evaluation, oracle exports and checkpoint I/O are outside the timer; startup caches were not isolated. The performance/evidence PR provides complete scope and raw records.

Validation: 714 non-integration tests passed against rebuilt dependency wheels, including ownership, failure atomicity, changed compiled tokens/LR, loss snapshots and checkpoint/resume. Changed-file Ruff and Rust formatting passed. The optional builders pin separately maintained dependency commits instead of carrying copied patches.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[alxmrs]

🌀 Claude: Thank you. A complete nanoGPT training step in SQL, with AdamW, clipping and dropout, gradients from ddx, and state kept on the GPU, at 101 ms against PyTorch MPS's 27 ms, is a remarkable result. Checking every loss, gradient, weight and optimizer moment against nanoGPT's own model.py and PyTorch's AdamW is exactly the standard the demos need.

Strengths

• Demo 3 (03_shakespeare.py) is valuable on its own. It follows nanoGPT's character-level Shakespeare recipe faithfully, and is checked against PyTorch step by step.
• The state handling is careful. Updates are published atomically, a failed step keeps the old state, dropout is seeded per step, and training resumes from a checkpoint.
• The timing is honest. The 3.76× gap is reported plainly, along with what's outside the timer.

Concerns

• TrainingSession (700 lines) is a training framework. It holds state on the device, compiles the whole step, publishes updates and writes checkpoints. That's outside xarray-sql's scope as an adapter between xarray and SQL. Where should shared CTE execution, compact arrays and GPU-resident training live? #307 proposes a separate package on public APIs.
• Private imports. training.py imports twelve private names from einfold.dense_program, and three from xarray_sql.dense.
• Unreleased dependencies. accelerators/ddx_math/build.py clones a personal fork of ddx. Once ddx#256 and Keep missing values in ClickHouse float columns #257 are released, a version pin can replace it, and xarray_sql/math.py could register erf for any user.
• The README. The new top-level section points readers to experimental, fork-built paths. I'd wait for those to be released before advertising them.

A suggested path: land demo 3 on the public APIs first, perhaps with the eager or plain path for now. The resident path can follow once #307 decides where TrainingSession lives.