Benchmark Results

This page is a snapshot of benchmark results recorded on a specific machine. For methodology, flags, and how to re-run, see Benchmarks.

Note: Timing and throughput are machine-specific. Compression ratios, sizes, and fidelity metrics are determined by the codec and are reproducible.

Run metadata

Codec Matrix

16 million float64 values (122 MiB). The test data is a synthetic smooth scientific-like field with values in the range 250–310 (a profile that also matches real temperature grids and other bounded-range physical measurements).

How fidelity is measured

After each encode→decode round-trip, the decoded values are compared to the original. Three error norms are reported, all absolute in the same units as the input:

• Linf — the largest error for any single value. Answers: “what is the worst case?”
• L1 — the average error across all values. Answers: “how far off are values on average?”
• L2 (RMSE) — root mean square error. Like L1 but penalizes large outliers more heavily. Answers: “how large are the typical errors, weighted toward the worst ones?”

For lossless codecs all three are zero.

Lossless compressors on raw floats

No encoding step — raw 64-bit floats compressed directly. Decoded values are bit-identical to the original.

Raw 64-bit floats have high entropy, so most lossless compressors cannot reduce their size. LZ4 and szip slightly expand the data. Blosc2 is the exception — its byte-shuffle step exposes compressible patterns (75%).

SimplePacking (quantization) + lossless compressors

Values are quantized to N bits, then compressed. Fidelity depends only on the bit width, not on the compressor — see the fidelity table below.

Fidelity by bit width

For context: with input values around 280, a Linf of 1.9 × 10⁻⁶ means the worst-case relative error at 24 bits is roughly 7 parts per billion.

Lossy floating-point compressors

These operate directly on raw f64 bytes without quantization.

Fidelity by lossy codec

Notable observations

• 16-bit + szip achieves the best compression ratio (14.6%) among the SimplePacking combinations.
• SZ3 achieves the smallest output overall (6.5%) with a max error of 0.01. If your application tolerates that error bound, this gives the best compression in this benchmark.
• In this benchmark, higher ZFP rates gave proportionally smaller errors. ZFP fixed-rate modes always hit their target ratio exactly (25% / 37.5% / 50%).

Reference Comparison: ecCodes GRIB Encoding

GRIB is a binary format widely used in operational weather forecasting, and ecCodes (from ECMWF) is a common implementation. Comparing against it gives a concrete, reproducible reference point for Tensogram’s quantisation + entropy-coding pipeline.

This benchmark runs Tensogram’s 24-bit SimplePacking + szip and ecCodes’ built-in packing methods on the same input. Both sides are timed end-to-end: from a float64 array to serialised compressed bytes (encode), and back (decode).

10 million float64 values (76 MiB), 24-bit packing. Different dataset size from the codec matrix above.

All three methods produce identical fidelity: Linf = 1.9 × 10⁻⁶, L1 = 9.5 × 10⁻⁷, L2 = 1.1 × 10⁻⁶.

Notable observations

• Tensogram and ecCodes CCSDS achieve nearly identical compression (27.4% vs 27.2%) and identical fidelity at 24 bits.
• Tensogram encode is now slightly faster than ecCodes CCSDS (43.7 vs 47.9 ms) on this machine; decode is comparable (80.4 vs 84.8 ms).
• ecCodes simple packing decodes fastest (7.9 ms) but produces a larger file (37.5% vs 27%).

Threading Scaling

The v0.13.0 multi-threaded coding pipeline lets callers spend a threads budget on encode/decode work. Results here show the effect of sweeping threads ∈ {0, 1, 2, 4, 8} on 16M f64 values (122 MiB) for seven representative codec combinations. threads=0 is the sequential baseline; speedups are measured against it.

Reminder: Transparent codecs (no codec, simple_packing, szip, lz4, zfp, sz3, shuffle) produce byte-identical encoded payloads across thread counts. Opaque codecs (blosc2, zstd with nb_workers > 0) may produce different compressed bytes while always round-tripping losslessly.

Lossless (no encoding)

SimplePacking + compression

Notable observations

• Memory-bound baselines (none+none, none+lz4) do not scale. The parallel dispatch overhead outweighs any gain when the work per task is already at memory bandwidth. none+lz4 actually regresses — leave threads=0 for lz4-only workloads.
• blosc2 scales best. Encoding with blosc2+lz4 reaches 2.8× on 8 threads; the sp(24)+blosc2 combination reaches 2.7× on encode and 1.3× on decode.
• zstd scales ~2.4× on encode at 4 threads via libzstd’s NbWorkers. Beyond 4 threads the benefit plateaus on this CPU.
• simple_packing decode is 2.3× faster at 2+ threads — the internal chunk-parallel scatter saturates memory bandwidth quickly.
• szip is single-threaded. The marginal gains shown for sp(24)+szip come from parallelising the simple_packing stage only; szip itself runs sequentially in v0.13.0.

The raw numbers above were produced by the threads-scaling binary in rust/benchmarks. Re-run locally with:

cargo build --release -p tensogram-benchmarks
./target/release/threads-scaling \
    --num-points 16000000 \
    --iterations 5 \
    --warmup 2 \
    --threads 0,1,2,4,8