benchmarks: build ggml with the tinyBLAS GEMM path (GGML_LLAMAFILE) llama.cpp enables by default

[codspeed-hq]

What

benchmarks/CMakeLists.txt builds ggml standalone via add_subdirectory(../ggml), so it never sees the override in the root llama.cpp/CMakeLists.txt:

# change the default for these ggml options
if (NOT DEFINED GGML_LLAMAFILE)
    set(GGML_LLAMAFILE_DEFAULT ON)
endif()

Verified locally before the change: GGML_LLAMAFILE:BOOL=OFF in the benchmark CMakeCache.txt, and llamafile_sgemm was absent from the benchmark binary. Every ggml_compute_forward_mul_mat() call therefore skipped the tiled tinyBLAS GEMM and fell back to the per-(row, column) ggml_vec_dot_*() loop — a path production llama.cpp CPU inference never takes.

This PR mirrors the same three lines in benchmarks/CMakeLists.txt so the benchmark build matches how llama.cpp is actually built. After the change: GGML_LLAMAFILE:BOOL=ON and llamafile_sgemm is present in the binary (checked with nm), in both the simulation and walltime configurations.

Why this is the right path to measure

mul_mat dominates the benchmarked work (ggml_vec_dot_f32 was 99.1% of ffn_swiglu and of mul_mat[f32]; ggml_vec_dot_f16 75.9% of lm_head[f16]). tinyBLAS replaces the 2-loads-per-FMA dot-product loop with register-blocked tiles, cutting both instruction count and cache traffic:

Benchmark	Instr. share before → after	Cache share before → after
ffn_swiglu	76.1% → 84.6%	12.4% → 7.4%
mul_mat[f32]	78.5% → 84.7%	9.9% → 7.4%

The change is architecture neutral — tinyBLAS ships NEON kernels as well as AVX/AVX2/AVX-512 — so the aarch64 codspeed-macro walltime job benefits too. mul_mat[q4_k] is unchanged because tinyBLAS has no Q4_K kernel (it covers F32, BF16, F16, Q8_0, Q4_0, Q5_0, IQ4_NL); llamafile_sgemm() returns false and the existing loop runs, so unsupported types and shapes are unaffected.

Measured impact (CodSpeed CPU simulation, micro suite)

Status	Benchmark	Base	Head	Change
⚡	ffn_swiglu	1,069.7 ms	776.6 ms	+37.74%
⚡	mul_mat[f32]	347.0 ms	258.6 ms	+34.17%
⚡	mul_mat[q4_0]	101.9 ms	90.0 ms	+13.17%

The other 12 benchmarks are unchanged — no regressions.

Scope and caveats

• This does not make the ggml kernels themselves faster. It stops the benchmark harness from measuring a slower fallback than the one real inference uses. The CI numbers drop once, and future kernel work is then measured against the path that actually ships.
• No library source is touched: the change is confined to the benchmark project's CMake configuration, so no llama.cpp/ggml build or test behaviour outside benchmarks/ changes.
• Numerics: Q8_0, Q4_0, Q4_K and the GEMV (n_tokens = 1) cases are bit-identical; F32/F16 differ by ~1 ulp on a checksum due to the tile accumulation order — the same arithmetic every llama.cpp release already performs.
• Both benchmark targets were configured and built locally in this change's configuration (simulation and walltime) and executed successfully.

[codspeed-hq]

Merging this PR will regress 1 benchmark

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 4 improved benchmarks
❌ 1 regressed benchmark
✅ 23 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	prompt_layer[f32]	247.1 ms	296.6 ms	-16.69%
⚡	Simulation	ffn_swiglu	1,067.7 ms	776.8 ms	+37.46%
⚡	Simulation	mul_mat[f32]	346.1 ms	258.7 ms	+33.81%
⚡	WallTime	lm_head[f16]	60.6 ms	52.5 ms	+15.26%
⚡	Simulation	mul_mat[q4_0]	102 ms	90 ms	+13.24%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing codspeed-optim-build-the-benchmarked-ggml-with-the-tinyblas-gemm-1785422569683 (d862814) with master (46819c9)}