code wiki / (root) / nx_membw.nx

nx_membw.nx

buildroot/runtime/nx_membw.nx

2405 B65 linesdepth 3pulls 3 transitivereach 0 importersview sourcekind tool
docsdependenciesstructsconstsfunctions

about

nx_membw.nx -- resolves the open question: is the decode matmul's ~5 GB/s (nx_q8_coldwarm COLD) a HARD memory-bandwidth cap (=> AVX2/prefetch WON'T help, the ~3.5-7x llama.cpp gap is environmental/WSL) or is the SSE kernel LEAVING BANDWIDTH ON THE TABLE (=> a wider kernel WOULD help)? Measures the RAW achievable sequential-read bandwidth of this process: allocate a >>LLC buffer, commit it, then stream-sum it (hardware prefetcher engaged). If raw ~5 GB/s -> bandwidth-capped (matmul is at the floor). If raw >>5 GB/s -> the matmul kernel is the limiter (AVX2 pays). expect_exit: 0

dependencies 3 imports · 0 importers

nx_syscalls.nx nx_tier.nx nx_fmt.nx nx_membw.nx

imports: nx_syscalls.nxnx_tier.nxnx_fmt.nx

imported by: nobody (leaf or entry point)

call flow from main pre-order; caps 40 nodes / depth 6 declared; ↻ = already shown

main sys_mmap sys_now_us sys_mmap ↻ sys_clock_gettime_mono fmt_puts fmt_puts_fd sys_write fmt_putn fmt_putn_fd sys_write ↻ mb_nl fmt_puts ↻

structs

none

consts

13const MB: i64 = 1048576

functions

15func mb_nl() -> i64 { fmt_puts("\n" as *u8); return 0 }
called by 1: main calls 1: fmt_puts
17func main() -> i64