nx_dequant_bench.nx source
↩ module page · 35 lines · 1531 B
1// nx_dequant_bench.nx -- pure dequant throughput measurement.
2//
3// Earns its own numbers, claims nothing about other frameworks. Per
4// the no-strawman-perf-comparisons feedback (2026-05-19): any "Nx
5// faster" or "ratio" claim requires running BOTH sides on the same
6// workload + hardware. This bench measures OUR Q4_K / Q8_0 / F32
7// dequant kernels. Comparing to llama.cpp / ggml requires running
8// llama.cpp on the same hardware (deferred to Task #8).
9//
10// What this bench measures:
11// * ns per dequantized value (avg over K runs)
12// * MB/s input throughput (bytes-of-quantized-data / second)
13// * Sanity check: output values not stuck at NX_GL_Q10_INF_SAT
14// (catches catastrophic overflow / NaN propagation)
15//
16// Hardware caveat: this runs on qemu-riscv64-static (emulated RV64
17// on an x86_64 host). Numbers will be 5-20x slower than native
18// because qemu user-mode dynamic translation costs overhead. Native
19// RV64 silicon would be faster; native x86_64 (the actual deployment
20// target) faster still. Report the qemu number AS the qemu number,
21// not as "Nishi performance".
22//
23// genealogy_id: standard_microbench_harness + ggml_q4k_dequant_ref
24// lineage_id: substrate_dequant_bench_v1
25
26import "nx_syscalls.nx"
27import "nx_tier.nx"
28import "nx_le.nx"
29import "nx_strconv.nx"
30import "nx_gguf.nx"
31import "nx_gguf_load.nx"
32
33// Workload size knobs.
34const NX_DB_N_BLOCKS: i64 = 64 // Q4_K super-blocks per run (= 16384 values)
35const NX_DB_K_RUNS: i64 = 32 // benchmark iterations