pycauset 0.6.2.dev8__tar.gz → 0.6.2.dev9__tar.gz

{pycauset-0.6.2.dev8 → pycauset-0.6.2.dev9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: pycauset
-Version: 0.6.2.dev8
+Version: 0.6.2.dev9
 Summary: High-performance Causal Set matrix operations using memory-mapped files
 Author: Bror Hjemgaard
 License: MIT

{pycauset-0.6.2.dev8 → pycauset-0.6.2.dev9}/documentation/project/plans/R2_ROADMAP.md

@@ -507,7 +507,7 @@ DoD: zero undocumented public API; zero untested public behavior; every node's i
 
 ### R2_PERF — NumPy Parity (≥ 0.90×)
 
-Status: - [ ] (in progress: a canonical `benchmarks/r2_parity.py` gate landed; current baseline (n=1024) — `solve` 0.96×, `eigh` 0.98×, `dot` 2.13× at parity; `matmul` 0.66×, `add` 0.09×, `multiply` 0.84× below parity. Verified `matmul` hits OpenBLAS `cblas_dgemm` (not a naive loop); measured the residual is a **bundled-OpenBLAS build/tuning difference** vs NumPy's OpenBLAS (same thread count, still ~1.66× slower) — fixable only by rebuilding the bundled OpenBLAS. `add` is the lazy-materialization gap (reverted a routing fix that overran — see R2_CPU). See `documentation/dev/R2_PERF_FINDINGS.md`)
+Status: - [ ] (in progress: `benchmarks/r2_parity.py` gate landed; current baseline (n=1024) — **7/8 at parity** (`add` ~1.1×, `solve` ~0.96×, `invert` ~1.1×, `dot` ~2×, `multiply` ~0.93×, `determinant` ~1.24×, `eigh` ~0.98×). `matmul` hovers just under the bar (~0.87×): the raw `cblas_dgemm` is already faster than NumPy (0.0044s vs 0.0060s at 20 threads), the residual is per-call wrapper cost (fresh-result VirtualAlloc + `create_matrix`/MemoryGovernor + Python IO-planning). Landed in R2.2: (1) LAPACK determinant, (2) fair invert/determinant cache-clearing in the benchmark, (3) add-flakiness root-cause (stale-binary namespace merge — `native.py` now loads from `__file__`), (4) AVX2 f64 sub/mul/div + full-span hardening, (5) OpenBLAS 0.3.28 rebuilt DYNAMIC_ARCH+threaded, (6) `:memory:` backing switched to `VirtualAlloc` (the add/multiply win), (7) CPU dgemm no longer pins operands, (8) GEMM bumps to 20 threads. See `documentation/dev/R2_PERF_FINDINGS.md`)
 
 Goal: every op is at least 0.90× NumPy throughput in the regimes PyCauset claims, or is an
 explicitly-documented out-of-scope case / performance bug. Per-op status lives in

{pycauset-0.6.2.dev8 → pycauset-0.6.2.dev9}/python/pycauset/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.6.2.dev8'
-__version_tuple__ = version_tuple = (0, 6, 2, 'dev8')
+__version__ = version = '0.6.2.dev9'
+__version_tuple__ = version_tuple = (0, 6, 2, 'dev9')
 
-__commit_id__ = commit_id = 'g73eee96f3'
+__commit_id__ = commit_id = 'g6e4c13b57'