Chunked dual transpose

[fishidaho]

Regroup a chunk at a time for the misaligned matmul direction

What's wrong

_get_dual (src/vsparse/_vcs_matmul.py) built a full opposite-format copy of the array the first time a normalized-view matmul needed the direction the storage isn't aligned for:

def_get_dual(nview):
ifnview._dual_arrisNone:
nview._dual_arr=nview._arr._transpose_major()
returnnview._dual_arr

A second complete copy of the dataset, allocated silently inside a matmul.

What this changes

The regrouping doesn't have to happen all at once. Delta @ B splits over the contracted axis (sum of Delta[:, C] @ B[C, :] over column chunks), and B @ Delta splits the same way over row chunks. So a contiguous range of major slices is transposed on its own, fed to the same major-aligned kernel, accumulated into the shared output, and dropped. Peak memory becomes one chunk's regrouping — set by a byte budget — instead of the whole array's.

_VCSBase._major_range(start, stop) is the new chunking primitive. A contiguous major range is already contiguous in every stored array, so values/indices come back as views (no copy) and only the two small pointer arrays are rebuilt. That's what makes per-chunk work cheap enough to be the default.

Dead code removed: _matmul_vcsr/_rmatmul_vcsc were thin wrappers that only existed to allocate the output the entry points now own.

The trade-off here

Chunking is not a free win in every regime. Measured on 72M nonzeros (30000×3000, VCSC, self @ B):

	first call	peak RSS	steady-state per call
chunked (new default)	10.30s	+0 MB	9.83s
pinned full dual (old behavior)	14.83s	+851 MB	0.12s

Max absolute difference between the two: 1.9e-14.

So the new default is faster to a first result and costs no extra memory, but repeated misaligned products against a cached dual are ~55× faster, because chunking redoes the regrouping every call. Power-iteration workloads (PCA, parafac2) hit exactly that pattern.

Two things address it:

1. An array whose entire regrouping already fits inside one chunk's budget is still cached automatically. Transposing it per call would allocate exactly that much anyway, so keeping it costs no additional peak memory.

2. view.pin_dual() is the explicit opt-in past that point, for callers who will run many misaligned products and know the memory is affordable.

Net effect, verified at both ends:

small (fits one chunk) nnz= 0.5M dual cached: True +RSS 0 MB
large (multi-chunk) nnz= 72.0M dual cached: False +RSS 0 MB

The budget is one module constant (_CHUNK_BUDGET_BYTES, 128 MiB) plus a deliberately generous bytes-per-nonzero estimate for transpose_major's transient sort arrays. Both are judgement calls that would be best introduced by creating a
user-facing memory budget.