GitHub user x-at-01 added a comment to the discussion: Sharing benchmark observations on decimal floating-point compression in IoT time-series: comparing integer mapping with Gorilla/Chimp
Here is the follow-up with the committed benchmark suite overhaul, the exact diff, and the updated 37-dataset comparative results addressing your technical feedback on workload equivalence and measurement rigor: Commit diff: https://github.com/webc-site/wedb_embed/commit/63ddb9b Full benchmark harness: https://github.com/webc-site/wedb_embed/blob/main/fastalp/examples/bench_all_codecs.rs Summary of benchmark refactorings implemented in commit 63ddb9b: 1. Workload denominator alignment: In Graupel (Chimp128 and Gorilla), the input is a composite Point(i64 timestamp, f64 value), which is 16 bytes per point. The raw byte denominator is now set to points.len() * 16 (size_of::<Point>()), eliminating the previous denominator undercounting. The display name is labeled as (ts+val) to reflect composite point encoding. 2. Cold vs warm encoding separation: fastalp is now measured in two distinct pipelines: - fastalp (sampled): runs dynamic parameter exploration and bit-width search from scratch on every invocation. - fastalp (cached): reuses established parameters without re-sampling (pure vector kernel). 3. Memory allocation alignment: For Zstd and Snappy, buffer-to-buffer APIs (compress_to_buffer and Encoder::compress into preallocated slices) are used to remove per-iteration heap allocation noise. 4. Bounded expansion verification: Added a microbenchmark on high-entropy random data (f64::from_bits) to confirm that fallback blocks incur at most 1 byte of header overhead (8,192 bytes become 8,193 bytes, bounded at +0.012%). 5. Full 37 dataset coverage: All 37 standard time-series datasets (31 paper datasets + 6 industrial scenario datasets) are evaluated in the automated runner. Full 37-dataset benchmark results on Apple Silicon (12-core, macOS, Rust 1.91, -O3): | Algorithm | Category | 37 Datasets Ratio | Bits per Value/Point | Sampled Enc (GB/s) | Cached Enc (GB/s) | Dec (GB/s) | Allocation Model | | :--- | :--- | :---: | :---: | :---: | :---: | :---: | :--- | | fastalp (Rust) | Specialized Float | 3.23x | 19.83 | 4.69 | 6.68 | 31.17 | Preallocated slice | | C++ ALP (Reference) | Specialized Float | 2.89x | 22.12 | 0.80 | 5.69 | 19.14 | Preallocated slice | | Pcodec (pco level 3) | Specialized Float | 3.60x | 17.75 | 0.22 | 0.22 | 1.89 | Allocating | | Chimp128 (ts+val) | Specialized Time-Series | 4.37x | 29.30 (per point) | 1.07 | 1.07 | 0.90 | Allocating (16B points) | | Gorilla (ts+val) | Specialized Time-Series | 3.09x | 41.47 (per point) | 2.36 | 2.36 | 1.39 | Allocating (16B points) | | Zstandard (level 3) | General Bytes | 1.35x | 47.46 | 0.58 | 0.58 | 3.32 | Preallocated slice | | Snappy (snap) | General Bytes | 1.12x | 57.06 | 2.82 | 2.82 | 4.22 | Preallocated slice | | LZ4 (lz4_flex) | General Bytes | 1.06x | 60.18 | 3.57 | 3.57 | 5.12 | Allocating | Honest observations on codec trade-offs: - On pure floating-point compression ratio, fastalp (3.23x) is not the highest: Pcodec achieves 3.60x (17.75 bits/val) by employing entropy coding and range searching, at the expense of lower encoding (0.22 GB/s) and decoding (1.89 GB/s) speeds. - For time-series points including timestamps, Chimp128 achieves 4.37x on 16-byte Point(ts, val) structures because consecutive integer timestamps compress very effectively under Delta-of-delta. - fastalp's primary advantage is its throughput-to-ratio efficiency: it provides 31.17 GB/s SIMD decompression and 4.69 GB/s cold end-to-end encoding (6.68 GB/s warm cached kernel) while retaining a 3.23x ratio. To reproduce these results, anyone can run: cargo run --release --example bench_all_codecs in the [fastalp](https://github.com/webc-site/wedb_embed/tree/main/fastalp) repository. The crate is published at [crates.io](https://crates.io/crates/fastalp). GitHub link: https://github.com/apache/iotdb/discussions/18581#discussioncomment-18280523 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
