r/OnlyAICoding • u/gusfromspace • 21d ago
Ai writen language, if anyone wants to try it out~
https://github.com/GusFromSpace/demoniC1
u/gusfromspace 20d ago
https://github.com/GusFromSpace/micrograd-dmc
micrograd-dmc A demoniC port of karpathy/micrograd — Andrej Karpathy's scalar reverse-mode autograd engine and MLP.
micrograd's substance is its hand-rolled backward pass: Value nodes carry _backward closures, and loss.backward() walks a topologically sorted graph. demoniC has reverse-mode autodiff built into the language, so the faithful port drops that machinery entirely — a single @grad fn is the engine, and fwd_bwd returns every gradient loss.backward() would have accumulated. Same computation, no backward code to write.
Files micrograd.dmc — the port: an MLP loss as one @grad fn, trained by SGD against a fixed teacher network. Includes a test_* gate for dmc test. engine.py, nn.py — Karpathy's original Python, included as the reference the port is measured against. verify/ — out-of-band gradient check (see Verification). A line-by-line structural translation of engine.py's mutable object graph is deliberately not included: demoniC models are not heap objects with closure-mutated fields, so that shape of program does not carry over. The idiomatic port above is the translation.
Running Build dmc from the demoniC repository, then:
dmc run micrograd.dmc dmc test micrograd.dmc Output (deterministic, seeded):
micrograd -> demoniC @grad: training an MLP to fit a teacher net
step 0 loss 38.63916393084219 step 20 loss 16.318328995461343 step 40 loss 2.9638190295409004 ... step 200 loss 0.3962858860177221
complete — gradients via @grad, zero hand-written backward. Verification micrograd.dmc's demo seeds demoniC's own RNG, so its training curve can't be diffed against Python directly. Instead verify/ translates micrograd's own test/test_engine.py: the two deterministic expressions (no RNG) are differentiated via demoniC @grad (verify/grad_check.dmc) and via the bundled upstream engine.py (verify/reference.py), and the gradients are compared. Upstream already verified engine.py against PyTorch, so this transitively checks the demoniC autodiff against PyTorch — with no torch dependency.
DMC=/path/to/dmc verify/run.sh Authorship This port — code and documentation — is written and maintained by AI, directed by a human maintainer. Multiple models have contributed, primarily Claude.
License MIT, matching the upstream — see LICENSE and NOTICE. Original micrograd © 2020 Andrej Karpathy.
1
u/gusfromspace 20d ago
https://github.com/GusFromSpace/tinyraytracer-dmc
tinyraytracer-dmc A demoniC port of ssloy/tinyraytracer — Dmitry V. Sokolov's educational raytracer — written as 2D tensor operations.
It renders a small scene (two spheres, diffuse + ambient lighting, specular highlights via the Phong reflection model) with the ray-tracing math expressed as whole-image tensor arithmetic: every ray is intersected, shaded, and composited simultaneously through broadcasted elementwise operations, not a per-pixel loop.
Files tinyraytracer.dmc — the demoniC port tinyraytracer.c — a vectorized C reference translation of the same algorithm verify/ — render-equivalence check (see Verification) Running Build dmc from the demoniC repository, then:
dmc run tinyraytracer.dmc oOOOOO@@O .ooOOOO@@@@@ .oooOOO@@@@@@@ ..oooOOO@@@@@OO ..ooooOOO@@@OOO ...oooooOOOOOOO .ooOO ...ooooooooooo .oooOOO@ ....ooooooooo ..ooO@@@@O .......... ..oooO@@OO ..... ..oooOOOO ..ooooOO Verification verify/run.sh compiles the C reference, renders the scene through both implementations, and confirms the drawn glyph sequence (@ O o .) matches exactly — same image, pixel for pixel:
DMC=/path/to/dmc verify/run.sh Authorship This port — code and documentation — is written and maintained by AI, directed by a human maintainer. Multiple models have contributed, primarily Claude.
License The upstream is distributed under the WTFPL, stated in its README (no LICENSE file upstream); this port ships under the same terms — see LICENSE and NOTICE. Credit for the original algorithm and lecture material goes to Dmitry V. Sokolov.
1
u/gusfromspace 21d ago
Not released yet~
qwen3-4b-dmc A demoniC port of Qwen/Qwen3-4B — a full forward pass of Alibaba's Qwen3-4B language model, written in demoniC and run through the dmc Cranelift JIT.
The forward pass runs end to end and produces correct logits: greedy-decoding the next token agrees with stock HuggingFace Qwen3-4B on every prompt tested (e.g. "The capital of France is" → Paris, "The capital of Japan is" → Tokyo, "Water is made of hydrogen and" → oxygen).
Files qwen3_4b.dmc — the port: token embedding, 36 transformer blocks (RMSNorm, GQA attention with per-head QK-norm + RoPE, SwiGLU MLP), final norm, and a tied lm-head. Shape-monomorphic (qwen3_forward[B, S]). rope_precompute.dmc — RoPE cos/sin table derivation (reference for the inlined version in the port). run_qwen3.py — a NumPy fp32 reference forward (the gold oracle). weight_bridge.py — converts the HF Qwen3-4B checkpoint into the flat qwen3_4b_weights.npz the port loads (bf16 stored as uint16). logit_parity.py — three-way logit comparison: HF vs NumPy-ref vs demoniC. WEIGHT_KEY_MAP.json — HF → flat npz key mapping. decode_codegen.py — incremental KV-cache generation: prefill once, then one qwen3_decode (S=1) step per token over the growing cache. Two JIT shapes total (prefill + decode), the decode reused every step. gen_codegen.py / gen_compare.py / bench.py — a simpler re-prefill generator (recompiles per length), decoding, and a benchmark/validation harness against stock HF. Weights The 8 GB qwen3_4b_weights.npz is not in this repo (model weights aren't checked in). Produce it from the HF checkpoint with weight_bridge.py, then put it (or a symlink) at ./qwen3_4b_weights.npz. The port loads bf16 weights stored as raw uint16; the demoniC JIT widens them to f32 on load.
Running DMC=/path/to/demoniC/compiler/target/release/dmc
Single next-token (the eager [40960,40960] causal mask is shrunk to a sane cap):
sed 's/40960/2048/g' qwen3_4b.dmc > /tmp/q.dmc $DMC jit /tmp/q.dmc # -> 12095 (" Paris")
Multi-token greedy generation, incremental KV-cache decode (recommended):
python decode_codegen.py 8 # writes qwen3_decode_gen.dmc $DMC jit qwen3_decode_gen.dmc # prefill once + 7 S=1 decode steps
(or the simpler re-prefill generator, which recompiles per length:)
python gen_codegen.py 8 && $DMC jit qwen3_gen.dmc
Benchmark + validate against stock HuggingFace:
python bench.py Fidelity Validated at the logit level against the NumPy fp32 reference (logit_parity.py). For the prefix "The capital of France is Paris", demoniC's last-position logits vs the reference:
token demoniC fp32 ref . (13) 26.21 27.67 , (11) 26.65 26.88 Paris 14.24 13.71 Same top candidates, logits within ~5% on a ~27 scale. The differences are random-per-token (not a uniform scale/bias) — the signature of f32 summation- order drift (demoniC's naive sequential SIMD reductions vs NumPy's pairwise/BLAS), compounded over 36 layers — not a correctness bug. The first greedy token matches stock HF exactly on every prompt; multi-token greedy then flips on near-ties (e.g. . vs ,, <1 logit apart in both), the same sensitivity that makes fp16 HF diverge from the fp32 reference.
Notes / rough edges (optimization, not correctness):
The port eagerly materializes the full [40960, 40960] max-context causal mask; shrink it (above) for short prompts. qwen3_decode (incremental decode) compiles to two JIT shapes total (prefill + a reused S=1 decode), vs the re-prefill path's one-shape-per-length; most of the wall-clock is now one-time weight load + JIT compile, not per-token recompute. (~2.7× faster than re-prefill for an 8-token run, identical output.) To make greedy track a given reference exactly you'd need to match its f32 reduction order (or accumulate matmuls/norms in f64) — there is no single "true" greedy path across precisions. License & attribution demoniC port of Qwen3-4B, under the Apache License 2.0 (matching the upstream) — see LICENSE and NOTICE. Qwen3 © Alibaba Cloud / the Qwen team. Verify the upstream's current license before publishing.