Xuanwo commented on issue #157: URL: https://github.com/apache/datasketches-rust/issues/157#issuecomment-5043246462
I ran the benchmark requested here against `ee6e1cc` (the current `origin/main` at the time of measurement). Environment: - Apple M4 Max (`aarch64-apple-darwin`), connected to AC power - `rustc 1.86.0 (05f9846f8 2025-03-31)`, LLVM 19.1.7 - Release profile - Three warmups, alternating table/bits execution order, paired geometric-mean comparison, and bootstrap 95% confidence intervals - All checksums were identical; the two implementations were also checked for bitwise equality over the complete `u8` domain Positive changes below mean that constructing the bits was slower than the lookup table. | Workload | Bits vs. table | 95% CI | | --- | ---: | ---: | | Isolated `inv_pow2` | **-6.60%** | -9.54% to -2.56% | | `update_kxq` with realistic accepted register transitions | **+1.04%** | +0.21% to +2.05% | | Complete HIP estimator update, including the division | +0.41% | -0.56% to +1.40% | | Hll4 `update_with_coupon` | **+3.17%** | +2.21% to +4.20% | | Hll6 `update_with_coupon` | **+3.70%** | +3.07% to +4.37% | | Hll8 `update_with_coupon` | **+1.56%** | +0.91% to +2.34% | The isolated and estimator benchmarks used 51 paired samples. The end-to-end benchmarks used 41 paired samples with `lg_k = 12`, a 4,096-coupon prefill, and 32,768 precomputed coupons applied to 1,024 cloned sketches per sample (33,554,432 calls per sample), so hashing and setup were outside the timed region. I also rebuilt with a single codegen unit to check whether binary layout was driving the end-to-end result. Hll4 was statistically tied at +0.62% (-0.08% to +1.36%), while Hll6 and Hll8 remained slower at +1.95% and +1.80%, respectively. Removing the HLL copy of the table reduced `__TEXT,__const` by exactly 2,048 bytes. The final Mach-O file only shrank by 96–272 bytes because of section/segment alignment. On this machine, the bit construction is faster in isolation, but that advantage does not survive the estimator's floating-point dependency chain and does not improve the public HLL update path. I would therefore not justify this replacement as a performance optimization based on these results. If we still prefer it for code or read-only-data simplification, I think it should be framed that way, and an x86_64 benchmark would still be useful before drawing a cross-architecture conclusion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
