Jul 1, 2026

Eric, we looked at the horizontal-table -> vertical-chunk rewrite question. Short version: I don’t think we should pipeline the rewrite through the GPU as a standalone step. The direct C++ engine surface is already column-native, so no engine/API change is needed. If libbitcoin keeps horizontal mmap storage, the rotation is a storage-layer staging cost, not an engine integration issue. Local microbench numbers on this machine: - ECDSA CPU full AoS->SoA rewrite: ~22.9 GB/s, about 39s projected over 3.5B tuples. - Best CPU chunk size was ~1024 rows: ~29.1 GB/s, about 31s projected over 3.5B tuples. - Schnorr was similar: ~30s projected at best chunk size. - Multithreading did not help; throughput stayed around ~20-23 GB/s, so one core is basically saturating the write path. - GPU staging on RTX 5060 Ti was PCIe-bound: pinned H2D ~19.9 GB/s, and H2D + deinterleave kernel projected around ~40s. So my recommendation is: 1. Keep the direct column API as the engine boundary. 2. If storage stays horizontal, do CPU chunk rotation, preferably fused with the existing read/staging path and overlapped with verification. 3. Don’t offload only the row->column rewrite to GPU; the PCIe transfer cost removes the benefit. 4. Treat vertical mmap aggregation as an end-to-end libbitcoin storage experiment. It may still win if the mmap aggregation change eliminates the contention you’re seeing, but the engine does not need a different interface for that. No C ABI, shim, or bridge is needed for this path.