nx_membw.nx
buildroot/runtime/nx_membw.nx
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
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
structs
| none |
consts
| 13 | const MB: i64 = 1048576 |
functions
| 15 | func mb_nl() -> i64 { fmt_puts("\n" as *u8); return 0 } |
| 17 | func main() -> i64 |