Merge pull request #39 from opensolvers/site/benchmarks-blis-gromacs

Sync BLIS and GROMACS Force benchmarks

Author: hugomeiland

README.md

@@ -29,13 +29,14 @@ Each RISC-V board exposes several compute paths. We benchmark and tune them inde
 | **Custom** | Custom ISA extensions beyond standard RVV | X60 **IME** / **XsmtVdot** (`smt.vmadot`) int8 on [RV2](boards/RV2.html) / [F3](boards/F3.html); [ONNX Runtime](apps/onnx.html) int4 via MLAS |
 | **GPU** | Integrated Imagination GPUs (OpenCL / Vulkan) | **IMG BXE-4-32 MC1** on [VisionFive 2](boards/VisionFive2.html) (JH7110); **IMG BXE-2-32** on [RV2](boards/RV2.html) / [F3](boards/F3.html) (K1) — present on silicon, **GPGPU benchmarks not yet** |
 
-Recent highlights on the Orange Pi RV2 (SpaceMiT X60, RVV): fixing an OpenBLAS `gemv_n` bug restores correctness across [BLAS](scientific-libs/blas.html), [LAPACK](scientific-libs/lapack.html), [ELPA](scientific-libs/elpa.html), [ScaLAPACK](scientific-libs/scalapack.html), [HPL](apps/hpl.html), and [Quantum ESPRESSO](apps/qe.html). [FFTW `r5v`](scientific-libs/fftw.html) wins **1.06–1.60×** in isolation but **~0%** inside a real QE SCF (`FFTW_ESTIMATE`); [GROMACS](apps/gromacs.html) sees **1.23×** on isolated `PME 3D-FFT`. ONNX `accuracy_level=4` unlocks **9–10×** int4 decode — [ONNX Runtime](apps/onnx.html) / [MLAS](scientific-libs/mlas.html).
+Recent highlights on the Orange Pi RV2 (SpaceMiT X60, RVV): fixing an OpenBLAS `gemv_n` bug restores correctness across [BLAS](scientific-libs/blas.html), [LAPACK](scientific-libs/lapack.html), [ELPA](scientific-libs/elpa.html), [ScaLAPACK](scientific-libs/scalapack.html), [HPL](apps/hpl.html), and [Quantum ESPRESSO](apps/qe.html). [BLIS](scientific-libs/blis.html) RVV assembly beats patched OpenBLAS **~1.29×** on single-thread DGEMM (N=4096). [FFTW `r5v`](scientific-libs/fftw.html) wins **1.06–1.60×** in isolation but **~0%** inside a real QE SCF; [GROMACS](apps/gromacs.html) sees **1.23×** on isolated `PME 3D-FFT` and **3.31×** whole-app with a hand-written RVV `Force` backend. ONNX `accuracy_level=4` unlocks **9–10×** int4 decode — [ONNX Runtime](apps/onnx.html) / [MLAS](scientific-libs/mlas.html).
 
 ## Scientific libs
 
 Library-level probes — performance *and* numerical correctness:
 
 - **[BLAS](scientific-libs/blas.html)** — OpenBLAS improvements (U74 kernel, X60 `gemv_n` / TRSM fixes) and [`OpenBLAS/`](https://github.com/opensolvers/benchmarks/tree/main/OpenBLAS) verification (`bench_dgemm`, `difftest`, `verify_ctrsm`)
+- **[BLIS](scientific-libs/blis.html)** — FLAME BLIS `rv64iv` RVV vs patched OpenBLAS; **1.29×** DGEMM at N=4096 (1 thread)
 - **[NumPy](scientific-libs/numpy.html)** — `bench_blas.py` DGEMM and `eigvalsh` through the SciPy stack
 - **[LAPACK](scientific-libs/lapack.html)** — LAPACK path via NumPy `eigvalsh`
 - **[ELPA](scientific-libs/elpa.html)** — dense eigensolver (CP2K / VASP class workloads)
@@ -50,12 +51,12 @@ End-to-end application benchmarks on the same boards and EESSI toolchain:
 - **[HPL](apps/hpl.html)** — High Performance Linpack; cross-board summary and A/B configs from [opensolvers/benchmarks](https://github.com/opensolvers/benchmarks)
 - **[Quantum ESPRESSO](apps/qe.html)** — plane-wave DFT SCF (`pw.x`); whole-application BLAS backend A/B with per-routine timers
 - **[ONNX Runtime](apps/onnx.html)** — int4 `MatMulNBits` LLM decode; `accuracy_level=4` unlocks X60 IME (**9–10×**)
-- **[GROMACS](apps/gromacs.html)** — PME MD; FFT-axis A/B via `libfftw3f` `LD_PRELOAD` (**1.23×** on `PME 3D-FFT`)
+- **[GROMACS](apps/gromacs.html)** — PME MD; FFT-axis **1.23×** on `PME 3D-FFT`; RVV `Force` backend **3.31×** whole-app
 
 ## Boards
 
 - **[StarFive VisionFive 2](boards/VisionFive2.html)** — JH7110 SoC, 4× SiFive U74 (`rv64gc`). U74 OpenBLAS tuning: HPL **3.13 → 5.28 GFLOP/s**.
-- **[Orange Pi RV2](boards/RV2.html)** — SpaceMiT K1, 8× X60 (RVV). Fixed OpenBLAS: HPL **FAILED (`nan`) → 10.53 GFLOP/s**; ELPA **34.81 s** (vs 54.92 s scalar).
+- **[Orange Pi RV2](boards/RV2.html)** — SpaceMiT K1, 8× X60 (RVV). Fixed OpenBLAS: HPL **FAILED (`nan`) → 10.53 GFLOP/s**; BLIS DGEMM **1.29×** vs OpenBLAS; GROMACS Force **3.31×**; ELPA **34.81 s** (vs 54.92 s scalar).
 - **[Banana Pi F3](boards/F3.html)** — same K1 / X60 SoC, **3.7 GB RAM**. HPL **FAILED (`nan`) → 11.52 GFLOP/s**; NumPy DGEMM up to **17.51 GFLOP/s** on patched RVV.
 
 Use the menu above to jump to a board, app, or scientific lib page.

_config.yml

@@ -37,6 +37,8 @@ navigation_apps:
 navigation_scientific_libs:
   - title: BLAS
     url: /scientific-libs/blas.html
+  - title: BLIS
+    url: /scientific-libs/blis.html
   - title: NumPy
     url: /scientific-libs/numpy.html
   - title: LAPACK

apps/gromacs.md

@@ -1,63 +1,121 @@
 # GROMACS
 
-[GROMACS](https://www.gromacs.org/) `mdrun` PME molecular dynamics — a **whole-application FFT backend A/B**. Swaps only the single-precision FFTW library (`libfftw3f.so.3`) under one unchanged binary via `LD_PRELOAD`; GROMACS comes from the EESSI module (`GROMACS/2026.2-foss-2025b`).
+[GROMACS](https://www.gromacs.org/) `mdrun` PME molecular dynamics on the SpaceMiT X60 — two independent backend axes measured end-to-end:
 
-Benchmark source: [opensolvers/benchmarks/gromacs](https://github.com/opensolvers/benchmarks/tree/main/gromacs) — `gen-water-box.sh` and `run-gmx-fft-ab.sh`.
+1. **FFT axis** — swap single-precision `libfftw3f.so.3` via `LD_PRELOAD` (stock EESSI build, `SIMD: None`)
+2. **Force axis** — hand-written **`impl_riscv_rvv/`** SIMD backend (`SIMD: RISCV_RVV`) or upstream 2026.3 autovec 1×1 kernel
 
-This is the **FFT-axis** companion to [Quantum ESPRESSO](qe.html)'s BLAS-axis probe. FFT microbench numbers: [FFTW](../scientific-libs/fftw.html).
+Benchmark source: [opensolvers/benchmarks/gromacs](https://github.com/opensolvers/benchmarks/tree/main/gromacs) — `gen-water-box.sh`, `run-gmx-fft-ab.sh`, and [`rvv-backend/`](https://github.com/opensolvers/benchmarks/tree/main/gromacs/rvv-backend) (patch + `apply-and-build.sh`).
 
-## Why GROMACS as an FFT probe
+FFT microbench numbers: [FFTW](../scientific-libs/fftw.html). BLAS-axis counterpart: [Quantum ESPRESSO](qe.html).
 
-PME splits long-range electrostatics into a real-space **`Force`** term and a reciprocal-space **mesh** part whose cost is a pair of 3D FFTs per step. On this build GROMACS reports **`SIMD instructions: None`** — force kernels are scalar — so swapping `libfftw3f` moves only the `PME 3D-FFT` / `PME mesh` rows in GROMACS's cycle table; `Force`, neighbor search, and constraints are built-in controls.
+---
 
-## Correctness — RVV FFT reproduces scalar MD
+## FFT axis — PME 3D-FFT (`run-gmx-fft-ab.sh`)
 
-Same `mdrun`, same `md.tpr`, `libfftw3f` swapped (17.2k-atom SPC water, 2000 steps):
+Swaps only `libfftw3f` under one unchanged EESSI `GROMACS/2026.2-foss-2025b` binary. BLAS pinned to scalar OpenBLAS; serial (`-ntmpi 1 -ntomp 1`) by design to isolate FFT.
+
+On the stock build GROMACS reports **`SIMD instructions: None`** — force kernels are scalar, so `PME 3D-FFT` / `PME mesh` are the swapped rows; `Force` (90% of runtime) is the built-in control.
+
+### Correctness — RVV FFT reproduces scalar MD
+
+Same `mdrun`, same `md.tpr`, 17.2k-atom SPC water, 2000 steps:
 
 | FFT backend | Avg potential energy | Δ vs scalar |
 | ----------- | -------------------: | ----------: |
 | Scalar (`libfftw3f`, ~944 KB) | **−236755 kJ/mol** | — |
 | r5v / RVV (`libfftw3f`, ~14 MB, 282k RVV instr) | **−236592 kJ/mol** | **0.069%** |
 
-Physically the same trajectory — expected single-precision rounding between codelet sets.
+### Performance — isolated FFT step (Orange Pi RV2)
 
-## Performance — SPC water PME (Orange Pi RV2)
-
-Serial, 48×48×48 PME grid. BLAS pinned to scalar OpenBLAS via FlexiBLAS; only `LD_PRELOAD` swaps FFT:
+Serial, 48×48×48 PME grid. GROMACS cycle accounting (WALL):
 
 | Activity | Scalar | r5v (RVV) | Speedup | Kind |
 | -------- | -----: | --------: | ------: | ---- |
 | **`PME 3D-FFT`** | 21.095 s | 17.152 s | **1.23×** | **FFT (swapped axis)** |
 | `PME mesh` (total) | 73.281 s | 69.792 s | 1.05× | FFT + spread/gather/solve |
-| `PME solve Elec` | 9.116 s | 9.139 s | 1.00× | scalar (control) |
-| **`Force`** | 821.35 s | 819.97 s | 1.00× | **scalar kernels (90% of run)** |
-| `Neighbor search` | 6.731 s | 6.714 s | 1.00× | scalar (control) |
+| **`Force`** | 821.35 s | 819.97 s | 1.00× | scalar control (90%) |
+| `Neighbor search` | 6.731 s | 6.714 s | 1.00× | scalar control |
+
+RVV wins **~1.23×** on the isolated 3D-FFT step; **`Force` confirms the A/B** (821.35 vs 819.97 s, 0.17% noise). Whole-app effect is small because `Force` dominates.
+
+---
+
+## Force axis — RVV SIMD backend (`rvv-backend/`)
+
+The scalar `Force` term that dilutes the FFT swap is itself optimizable. [`rvv-backend/`](https://github.com/opensolvers/benchmarks/tree/main/gromacs/rvv-backend) ships a hand-written **`impl_riscv_rvv/`** backend for GROMACS **2026.2** (~1545 lines, float/mixed precision) — ARM SVE as the VLA template.
+
+Built on the X60 under EESSI GCC 14.3 with `GMX_SIMD=RISCV_RVV`. `gmx --version` reports **`SIMD instructions: RISCV_RVV`**; float SIMD unit tests **158/158** pass.
+
+Same serial protocol (SPC water PME, `md.tpr`, 2000 steps, `-ntmpi 1 -ntomp 1 -nb cpu -pme cpu`):
+
+| Metric | Scalar (`SIMD: None`) | RVV (`SIMD: RISCV_RVV`) | Speedup |
+| ------ | --------------------: | ------------------------: | ------: |
+| **`Force` wall** | 821.35 s | **187.37 s** | **4.38×** |
+| Total wall | 910.33 s | **275.40 s** | **3.31×** |
+| Performance | 0.380 ns/day | **1.256 ns/day** | **3.31×** |
+| Avg potential energy | −236755 kJ/mol | −236653 kJ/mol | Δ 0.043% (correct) |
 
-The **`Force` row confirms the A/B** — 821.35 vs 819.97 s (0.17%, noise). RVV wins **~1.23×** on the isolated 3D-FFT step, but `Force` dominates the whole run.
+**The profile inverts:** with `Force` cut ~4.4×, PME mesh becomes the leading cost (28% vs 8% of runtime) — so the FFT axis matters more after vectorizing `Force`.
 
-## Where GROMACS sits on the dilution spectrum
+Status: captured as a patch for reproduction; **no upstream PR yet**. Double precision not ported.
+
+---
+
+## Force axis — three levers compared
+
+All measured on Orange Pi RV2, same SPC water system, 2000 steps, 1 core (unless noted):
+
+| Force lever | GROMACS | Mechanism | `Force` wall | ns/day | vs scalar |
+| ----------- | ------- | --------- | -----------: | -----: | --------: |
+| Scalar 4×4 (baseline) | 2026.2 | none (`SIMD: None`) | 821.35 s | 0.380 | 1.00× |
+| GCC `-march=…v` 4×4 autovec | 2026.2 | compiler on 4×4 kernel | ~836 s* | 0.372 | **0.98× (slower)** |
+| **Upstream 1×1 autovec** | **2026.3** | clang `#pragma`, `GMX_NBNXN_PLAINC_1X1=1` | **480.14 s** | **0.543** | **1.43×** |
+| **Hand-written `impl_riscv_rvv/`** | **2026.2** | `GMX_SIMD=RISCV_RVV` | **187.37 s** | **1.256** | **3.31×** |
+
+<sub>*4×4 autovec Force scaled from 1000-step run; ns/day directly comparable.</sub>
+
+The **2026.3 autovec 1×1** path (clang ≥ 19, `GMX_ENABLE_NBNXM_CPU_VECTORIZATION=on`) is a real win — **1.74× whole-app** vs the same binary's default 4×4 — but the hand-written backend is still **2.31× faster** whole-app (1.256 vs 0.543 ns/day). Autovec is VLEN-agnostic and upstream-native; the dedicated backend targets fixed VLEN=256 (`-mrvv-vector-bits=zvl`).
+
+**Free lever:** threading — serial A/B wastes 7 of 8 cores. Same system at `-ntomp 8` reaches **~2.60 ns/day** (~6.9× vs serial baseline).
+
+---
+
+## Backend-dilution spectrum
 
 | Probe | Axis | Isolated speedup | Whole-app effect |
 | ----- | ---- | ---------------: | ---------------- |
 | [OpenBLAS verification](../scientific-libs/blas.html#verification) | BLAS | ~2.3× | (pure kernel) |
-| [QE](qe.html) (DFT SCF) | BLAS | ~1.5–2.0× on BLAS routines | ~1.2–1.3× (FFT half untouched) |
+| [BLIS](../scientific-libs/blis.html) vs OpenBLAS | BLAS | ~1.29× (1T, N=4096) | (microbench) |
+| [QE](qe.html) (DFT SCF) | BLAS | ~1.5–2.0× on BLAS routines | ~1.2–1.3× (FFT untouched) |
 | [QE + FFTW](../scientific-libs/fftw.html) | FFT | ~1.02× on `fftw` | **~0%** (`FFTW_ESTIMATE`) |
-| **GROMACS** (this page) | **FFT** | **~1.23× on `PME 3D-FFT`** | small (`Force` = 90%) |
+| **GROMACS FFT** (this page) | FFT | **~1.23× on `PME 3D-FFT`** | small (`Force` = 90%) |
+| **GROMACS Force** (`rvv-backend/`) | **SIMD** | **~4.38× on `Force`** | **~3.31×** |
 
-GROMACS is the mirror of QE: QE speeds up BLAS and is diluted by FFT; GROMACS speeds up FFT and is diluted by scalar force kernels.
+GROMACS FFT is the mirror of QE: QE speeds up BLAS and is diluted by FFT; the FFT swap is diluted by scalar `Force`. Vectorizing `Force` moves the whole app — then PME/FFT becomes the next target.
+
+---
 
 ## Gotchas
 
-- GROMACS mixed precision links **`libfftw3f.so.3`** (single precision), not the double-precision `libfftw3.so.3` from the QE/FFTW work.
+- GROMACS mixed precision links **`libfftw3f.so.3`** (single precision), not double-precision `libfftw3.so.3` from QE/FFTW work.
 - Fixed `-nsteps` keeps FFT call count identical between backends (4002 here).
 - RVV `libfftw3f` build is slow to compile (~2 h on one X60); scalar ~15 min.
+- GCC `-march=rv64gcv_zvl256b` on stock 4×4 `Force` emits 164k RVV instrs but runs **~2% slower** — gather-heavy kernel defeats autovec.
+- 2026.3 autovec 1×1 needs **clang ≥ 19** and runtime **`GMX_NBNXN_PLAINC_1X1=1`**; confirm via `Using plain-C-1x1` in `md.log`.
+- RVV-backend builds need GCC 14.3's `libstdc++` (`CXXABI_1.3.15`) on `LD_LIBRARY_PATH` at runtime.
 
 ## Reproduce
 
 ```bash
+# FFT axis
 module load GROMACS/2026.2-foss-2025b
 ./gen-water-box.sh
 bash run-gmx-fft-ab.sh v1
+
+# Force axis (hand-written RVV backend)
+cd gromacs/rvv-backend
+./apply-and-build.sh /path/to/gromacs-2026.2
 ```
 
 **Toolchain:** GROMACS 2026.2 / foss-2025b (EESSI), FFTW 3.3.10 `libfftw3f`, Orange Pi RV2 (SpaceMiT X60).

boards/RV2.md

@@ -52,9 +52,22 @@ The fix backports the upstream `gemv_n` correction from OpenBLAS ≥ 0.3.31 ([Op
 
 Full walkthrough: [EESSI/docs#819](https://github.com/EESSI/docs/pull/819) — *Chasing a NaN: correct RVV HPL on a RISC-V SpaceMiT X60 via EESSI*.
 
+## BLIS vs OpenBLAS
+
+See [BLIS](../scientific-libs/blis.html) — FLAME BLIS `rv64iv` with hand-written RVV assembly vs patched OpenBLAS on the same `bench_dgemm.c`. Single-thread DGEMM at N=4096: **2.95 vs 2.28 GFLOP/s** (**1.29×** BLIS); 8-thread OpenBLAS still leads at large N. TRSM: **2400 cases, 0 fails** on BLIS.
+
 ## FFTW RVV
 
-See [FFTW](../scientific-libs/fftw.html) — r5v wins **1.06–1.60×** in `tests/bench`, but **~0%** end-to-end in [Quantum ESPRESSO](../apps/qe.html) (`FFTW_ESTIMATE`). [GROMACS](../apps/gromacs.html) FFT swap: **1.23×** on isolated `PME 3D-FFT`.
+See [FFTW](../scientific-libs/fftw.html) — r5v wins **1.06–1.60×** in `tests/bench`, but **~0%** end-to-end in [Quantum ESPRESSO](../apps/qe.html) (`FFTW_ESTIMATE`).
+
+## GROMACS
+
+See [GROMACS](../apps/gromacs.html) — two axes on this board:
+
+| Axis | Result |
+| ---- | ------ |
+| **FFT** (`libfftw3f` swap) | **1.23×** on isolated `PME 3D-FFT`; ~0% whole-app (`Force` = 90%) |
+| **Force** (`rvv-backend/`, `SIMD: RISCV_RVV`) | **4.38×** on `Force`, **3.31×** whole-app (0.380 → **1.256 ns/day**) |
 
 ## ScaLAPACK
 

scientific-libs/blas.md

@@ -2,7 +2,7 @@
 
 Improvements to **OpenBLAS 0.3.30** on RISC-V boards — built via EasyBuild, deployed through [EESSI](https://www.eessi.io/) with **FlexiBLAS** runtime swapping.
 
-Verification microbenchmarks live in [opensolvers/benchmarks/OpenBLAS](https://github.com/opensolvers/benchmarks/tree/main/OpenBLAS) (`bench_dgemm`, `difftest`, `verify_ctrsm`). Stack probes: [NumPy](numpy.html) (`bench_blas.py`). Full repo: [opensolvers/benchmarks](https://github.com/opensolvers/benchmarks).
+Verification microbenchmarks live in [opensolvers/benchmarks/OpenBLAS](https://github.com/opensolvers/benchmarks/tree/main/OpenBLAS) (`bench_dgemm`, `difftest`, `verify_ctrsm`). **Alternative BLAS:** [BLIS](blis.html) RVV vs OpenBLAS DGEMM A/B on X60. Stack probes: [NumPy](numpy.html) (`bench_blas.py`). Full repo: [opensolvers/benchmarks](https://github.com/opensolvers/benchmarks).
 
 **Base stack:** GCC 14.3.0, OpenBLAS 0.3.30, EESSI `2025.06-001` ([`dev.eessi.io/riscv`](https://www.eessi.io/docs/repositories/dev.eessi.io-riscv/)).
 

scientific-libs/blis.md

@@ -0,0 +1,60 @@
+# BLIS
+
+[BLIS](https://github.com/flame/blis) (BLAS-like Library Instantiation Software, FLAME group) on RISC-V — a **vector-vs-vector** DGEMM comparison against patched RVV **OpenBLAS** on the SpaceMiT X60.
+
+BLIS ships hand-written RVV assembly level-3 microkernels under [`kernels/rviv/3/`](https://github.com/flame/blis/tree/master/kernels/rviv/3) (dynamic VLEN via `get_vlenb()`), selected by the **`rv64iv`** config target. This is not scalar-vs-vector — both libraries use RVV.
+
+Benchmark source: [opensolvers/benchmarks/BLIS](https://github.com/opensolvers/benchmarks/tree/main/BLIS) — `build-blis.sh`, `run-ab.sh`, shared `bench_dgemm.c`, `verify_ctrsm.c`.
+
+See also [BLAS (OpenBLAS)](blas.html) for the OpenBLAS fixes and verification suite that define the baseline here.
+
+## Why link, not FlexiBLAS
+
+Other BLAS-axis benchmarks ([HPL](../apps/hpl.html), [NumPy](numpy.html), [QE](../apps/qe.html)) swap backends at runtime via FlexiBLAS. **FlexiBLAS is not installed on the RV2**, so this A/B links the same unchanged `bench_dgemm.c` against each library in turn — still one variable (the BLAS implementation), identical `-O3 -march=rv64imafdcv_zvl256b`.
+
+## Build & run
+
+```bash
+./build-blis.sh                    # ~10–20 min native; installs to $HOME/blis-install
+BLIS_PREFIX=$HOME/blis-install \
+OPENBLAS_LIB=$HOME/trsm-pr5830/libopenblas.a \
+  ./run-ab.sh
+```
+
+Configure with **`rv64iv`** (RVV 1.0, dynamic VLEN=256) and **`--enable-threading=openmp`** — without OpenMP, DGEMM stays single-threaded (~2.7 GFLOP/s regardless of thread count). Do **not** use `sifive_rvv` (defaults to VLEN=128).
+
+**Toolchain:** EESSI GCC **14.3.0** forced ahead of compat GCC 13.4.0; link with `-L$GCC14/lib -B$GCC14/lib` (see benchmarks README for the `libgomp.spec` trap).
+
+## Correctness
+
+| Check | Result |
+| ----- | ------ |
+| `verify_ctrsm` (BLIS `rv64iv`) | **2400 cases, 0 fails**, worst residual **2.55×10⁻⁷** (1- and 8-thread) |
+| `C[0]` in DGEMM sweep | **245.24** identical for BLIS and OpenBLAS at every size — no NaN |
+
+BLIS TRSM passes cleanly on X60 — unlike the stock OpenBLAS `_rvv_v1` TRSM VLEN bug caught by [`verify_ctrsm` in OpenBLAS/](https://github.com/opensolvers/benchmarks/tree/main/OpenBLAS).
+
+## Performance — Orange Pi RV2 (X60, VLEN=256)
+
+BLIS `061c2eb` (`rv64iv`, OpenMP) vs patched RVV OpenBLAS `0.3.33.dev` (`zvl128bp`), EESSI GCC 14.3.0. Square DGEMM, 3 reps, best GFLOP/s:
+
+| Threads | N | BLIS | OpenBLAS | BLIS / OpenBLAS |
+| ------: | --: | ---: | -------: | --------------: |
+| 1 | 1024 | 1.99 | 2.13 | 0.93× |
+| 1 | 2048 | 2.73 | 2.25 | **1.21×** |
+| 1 | 4096 | 2.95 | 2.28 | **1.29×** |
+| 8 | 1024 | 8.93 | 10.13 | 0.88× |
+| 8 | 2048 | 9.60 | 10.83 | 0.89× |
+| 8 | 4096 | 9.55 | 11.94 | 0.80× |
+
+### Takeaways
+
+- **Single thread, large N:** BLIS's RVV assembly microkernel **beats OpenBLAS by ~20–30%** once packing is amortized (N ≥ 2048). At N=1024 the two are within noise.
+- **8 threads:** OpenBLAS scales slightly better (BLIS **0.80–0.89×**). Both get ~3.5–5× from 8 cores; BLIS's OpenMP path leaves headroom vs OpenBLAS threading.
+- **Correctness first:** both backends numerically identical on DGEMM; BLIS TRSM verified independently.
+
+## References
+
+- BLIS RISC-V config: [`config_registry`](https://github.com/flame/blis/blob/master/config_registry) (`rv64iv`, `sifive_rvv`)
+- RVV assembly kernels: [`kernels/rviv/3/`](https://github.com/flame/blis/tree/master/kernels/rviv/3)
+- Prior RISC-V BLIS work: PR [#737](https://github.com/flame/blis/pull/737) (X280), [#832](https://github.com/flame/blis/pull/832), [#868](https://github.com/flame/blis/pull/868) (SG2042)