[tannevaled]

Float32 results now come from the Workspace, and the AVX2 log kernel's range check is cheaper. This also corrects a README claim made in v0.34.0.

What was wrong: through the API, float32 Log was 1.25× NumPy at 16 Ki on Zen 3, although its kernel was at parity. The README said it ran "as fast as NumPy".

• The gap was the result's allocation: make alone costs 4.1 µs at 16 Ki and 130 µs at 1 Mi on that core (a large span from the heap, zeroed). Kernel plus allocation adds up to the API time at both sizes.
• The data was not the cause: on the API benchmark's data the kernel hands back 0 blocks (new handed-blocks/op metric).
• The Workspace, the library's answer to allocation, only handed out float64, so a Float32 result went to the heap even inside one.

Changes:

• Workspace.alloc32 carves float32 storage from the same blocks: two per float64 element, 64-byte aligned, cap = len. It is used by Exp, Log, the other float32 ufuncs, arithmetic, Power, Clip and the float32 GEMM (zeroed there, because it accumulates).
• TestWorkspace32MatchesHeap holds every site to the heap result bit for bit, including on an arena filled with NaN bits. Making the GEMM's allocation unzeroed makes it fail (checked). TestWorkspaceAlloc32Shape checks length, cap, alignment and zeroing; TestWorkspace32Allocates checks the allocation count.
• log32CRAVX2 rejects lanes that are not positive normals at the end of the block. One wrapping add and one compare (ux + 0x7f800000 ≤ −0x01000001 as int32, exact because adding a constant mod 2³² is a bijection) replace five instructions and a branch. That is −2.4% (abbench, 8 rounds, p ≤ 0.03 on three of four sizes).
• Re-proven on Zen 3: TestLog32CorrectlyRounded over all 2³² inputs finds 0 incorrectly rounded.

float32, one Zen 3 core, load ≤ 4.2	16 Ki	1 Mi
Exp in a Workspace	19.4 µs	1.23 ms
NumPy 2.5.4 np.exp	22.0–22.3 µs	1.37–1.47 ms
Log, allocating (v0.34.0: 35.5 µs)	34.5 µs	2.06 ms
Log in a Workspace	29.9 µs	1.90 ms
NumPy 2.5.4 np.log	28.1–28.8 µs	1.77–1.82 ms

In a Workspace, Exp is about 12% faster than NumPy and Log about 5% slower. The README and docs/perf.md now say exactly that. Coverage of the package stays at 100%. SECURITY.md has the audit entry for the unsafe.Slice in alloc32.

🤖 Generated with Claude Code