v0.4.2 — application on slices of large states; benchmarks that measure what C++QED does

No breaking changes. Results agree with v0.4.1 up to rounding.

Application: operator() now applies one diagonal at a time to contiguous slices of up to 512 amplitudes of a state that doesn't fit in cache, i.e. whose storage (the view's dataView) holds at least 2^18 amplitudes. There the row shape's speed depends on where the arrays lie within their pages, by up to 2.6×, because in some placements the hardware prefetcher covers less of the stream; one diagonal at a time doesn't (#27). kernels.cc case I measured the crossover over 15 placements per configuration: out of cache the new choice is 1.04–2.1× faster at the median up to 512 amplitudes. For states that fit in cache, and for views that are a whole array, the choice is unchanged.

Huge pages (#26): on transparent huge pages set to "always", input and output arrays that nearly coincide modulo 1 MiB, as arrays of a power-of-two size allocated back to back do, make application up to 3× slower (case H), and C++QED's jc_qjmc about 20% slower. StorageType is unchanged: jemalloc, which starts large allocations at varying offsets within a page, avoids the effect, and C++QED links it when installed. Both benchmark executables gain --no-thp, and out-of-cache figures are now measured on 4 KB pages.

Benchmarks (#5): picture1 measures the library (the operator updated, then operator()). Its earlier "0.95–1.01×" for one phase per diagonal compared two hand-written loops and is withdrawn. The new slices3 applies a term slice by slice against a CSR matrix of the term's own space, with and without the interaction picture; there the picture costs at most 2%. constructJC is checked against a dense matrix, and plot.py draws the cost of the picture the right way up.

The performance page (benchmarks/performance.md) also records the instruction set: all figures there need AVX2; on the x86-64 baseline the library is typically 1.4–1.7× slower.